From exim@www1.ietf.org Tue Jul 1 04:23:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02658 for ; Tue, 1 Jul 2003 04:23:58 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h618NVL26975 for sipping-archive@odin.ietf.org; Tue, 1 Jul 2003 04:23:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XGQF-000710-RM for sipping-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 04:23: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 EAA02644 for ; Tue, 1 Jul 2003 04:23:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XGQB-0000wZ-00 for sipping-web-archive@ietf.org; Tue, 01 Jul 2003 04:23:27 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XGQ5-0000wK-00 for sipping-web-archive@ietf.org; Tue, 01 Jul 2003 04:23:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XGPl-0006xp-S6; Tue, 01 Jul 2003 04: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 19XGOy-0006ui-70 for sipping@optimus.ietf.org; Tue, 01 Jul 2003 04:22: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 EAA02609 for ; Tue, 1 Jul 2003 04:22:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XGOs-0000vs-00 for sipping@ietf.org; Tue, 01 Jul 2003 04:22:06 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19XGOe-0000vb-00 for sipping@ietf.org; Tue, 01 Jul 2003 04:21:53 -0400 Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h618L7iB002301; Tue, 1 Jul 2003 04:21:08 -0400 (EDT) Message-ID: <3F01446E.60805@dynamicsoft.com> Date: Tue, 01 Jul 2003 04:21:02 -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: seancolson@yahoo.com CC: "'Rosen, Brian'" , sipping@ietf.org Subject: Re: [Sipping] Dialog event package and conferences References: <016e01c33b92$0fd272a0$6801a8c0@cranberry> In-Reply-To: <016e01c33b92$0fd272a0$6801a8c0@cranberry> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The "isfocus" parameter is actually one of several parameters which can indicate capabilities of a UA: http://www.ietf.org/internet-drafts/draft-ietf-sip-callee-caps-00.txt I would prefer to define a and element, and allow their children to contain capability descriptions for the local and remote sides: TRUE TRUE This is better than using local-target, IMHO. I think local-target should be exactly the same type as remote-target, and remote-target just contains a name-addr. I also think this is outside the scope of the current dialog event package, and would be more appropriate as part of an extension (i.e., Sean's recent I-D). Thanks, Jonathan R. Sean Olson wrote: > Yes, exactly! :-) > What about placing this Contact: info in a element within the > dialog-info payload? > > Sean > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Wednesday, June 25, 2003 8:50 AM > To: 'Sean Olson'; sipping@ietf.org > Subject: RE: [Sipping] Dialog event package and conferences > > > Aah, interesting. > > You want the "IsFocus" parameter from the Contact header, but you don't > seem to get it. > > I agree, you need it. > > Brian > > > >>-----Original Message----- >>From: Sean Olson [mailto:seancolson@yahoo.com] >>Sent: Wednesday, June 25, 2003 10:11 AM >>To: sipping@ietf.org >>Subject: [Sipping] Dialog event package and conferences >> >> >>I was wondering how do you tell that a dialog reported through a >>dialog event NOTIFY is actually just one leg of a larger conference? >>Or to flip it around another way, is there a way to determine which >>conferences a user is currently in? >> >> >> >>__________________________________ >>Do you Yahoo!? >>SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.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 > -- 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 Tue Jul 1 10:08:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00862 for ; Tue, 1 Jul 2003 10:08:48 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h61E8I923792 for sipping-archive@odin.ietf.org; Tue, 1 Jul 2003 10:08:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XLnu-0006Bf-Iq for sipping-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 10:08: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 KAA00762 for ; Tue, 1 Jul 2003 10:08:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XLnp-0004sZ-00 for sipping-web-archive@ietf.org; Tue, 01 Jul 2003 10:08:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XLnj-0004sP-00 for sipping-web-archive@ietf.org; Tue, 01 Jul 2003 10:08:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XLng-00067j-ME; Tue, 01 Jul 2003 10:08:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XGEc-0006Yd-9y for sipping@optimus.ietf.org; Tue, 01 Jul 2003 04:11: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 EAA02435 for ; Tue, 1 Jul 2003 04:11:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XGEW-0000r6-00 for sipping@ietf.org; Tue, 01 Jul 2003 04:11:24 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19XGEL-0000qN-00 for sipping@ietf.org; Tue, 01 Jul 2003 04:11:13 -0400 Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6188QiB002297; Tue, 1 Jul 2003 04:08:27 -0400 (EDT) Message-ID: <3F014176.3000401@dynamicsoft.com> Date: Tue, 01 Jul 2003 04:08: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: Paul Kyzivat CC: Michael Hammer , seancolson@yahoo.com, "'Rosen, Brian'" , hisham.khartabil@nokia.com, jason@azatel.com, rohan@cisco.com, drage@lucent.com, alan.johnston@wcom.com, sipping@ietf.org Subject: Re: [Sipping] proposed enhancement to dialog package References: <009101c330fb$3bd894c0$6801a8c0@cranberry> <4.3.2.7.2.20030619095945.00b2cd10@cia.cisco.com> <3EF1CFE1.1020105@cisco.com> In-Reply-To: <3EF1CFE1.1020105@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 Paul Kyzivat wrote: > > > As this relates to Rohan's proposal, I think what I have described as > attending to media is similar to what Rohan is calling participation. > The primary difference seems to be that Rohan is applying this property > to the dialog as a whole rather than to a media stream. > > It is convenient to have this as a property of the dialog. The question > is whether the typical UA knows this. For UAs that support only a single > medium the distinction is irrelevant. There isn't nearly as much > experience with multimedia UAs, and I suspect there hasn't been time for > management of such devices to reach defacto standardization. I dont think this is a property of the dialog at all. Keith commented on this previously within this thread, and I agree. This notion of "participation" is a very high level application issue, and it can manifest itself in SIP-terms in many ways - suspended media streams, media on hold, etc. For some applications, the notion of participation may, in fact, be applicable to a media stream at a time, and for others, its all of them. There are certainly other "states" of a telephony-like application residing on SIP. "Muted" has also been discussed in this thread. Generally, muted is a purely local operation, and doesnt manifest itself within SIP signaling in any way. As such, I dont think the dialog package is the right place for this information. Its much closer to presence, in fact. Indeed, Jon and I recently submitted an I-D that proposed a bunch of PIDF extensions to reflect status of phones, including application-level type of state: http://www.ietf.org/internet-drafts/draft-rosenberg-peterson-simple-pidf-phone-00.txt My gut feeling is that this might be a more appropriate place for these states. -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 Tue Jul 1 10:08:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00860 for ; Tue, 1 Jul 2003 10:08:48 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h61E8Ku23810 for sipping-archive@odin.ietf.org; Tue, 1 Jul 2003 10:08:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XLnw-0006Bw-1h for sipping-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 10:08: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 KAA00767 for ; Tue, 1 Jul 2003 10:08:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XLnq-0004sc-00 for sipping-web-archive@ietf.org; Tue, 01 Jul 2003 10:08:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XLnj-0004sT-00 for sipping-web-archive@ietf.org; Tue, 01 Jul 2003 10:08:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XLnf-00066m-2V; Tue, 01 Jul 2003 10:08:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X3hH-0001Tk-1N for sipping@optimus.ietf.org; Mon, 30 Jun 2003 14:48: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 OAA10487 for ; Mon, 30 Jun 2003 14:48:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X3hD-0003Uk-00 for sipping@ietf.org; Mon, 30 Jun 2003 14:48:11 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19X3h2-0003UZ-00 for sipping@ietf.org; Mon, 30 Jun 2003 14:48:00 -0400 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h5UIkfpp012280; Mon, 30 Jun 2003 11:46:41 -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 AFL38611; Mon, 30 Jun 2003 11:46:38 -0700 (PDT) Message-Id: <4.3.2.7.2.20030630143043.00b31760@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 30 Jun 2003 14:46:37 -0400 To: =?us-ascii?Q?Gunnar_Hellstrom?= From: Michael Hammer Subject: Re: [Sipping] Sipdev, incoming call alert (ring signal equivalents) Cc: "'Sipping@Ietf. Org'" , , "'Mike Spanner'" , "'James Hamlin'" , , , , , "'Guido Gybels'" , , "'Judy Harkins'" , "'Trefor Davies'" , "Henry Sinnreich" , , , , In-Reply-To: References: <000501c3398d$79bae7d0$d86932a6@hsinnreich2> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_19993158==_.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: , --=====================_19993158==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Gunnar, In writing this requirement, if you are going to detail possible solutions, could you also add the possibility that a SIP INVITE message could be forked to separate devices providing the enhanced alerting (visual or louder audio) over the SIP device's existing data networking environment (Wired LAN, Bluetooth, Wi-Fi, etc). Thus the phone device solution may be software-oriented and re-using hardware that may be separately located on a home LAN. Thanks. Mike At 06:55 PM 6/23/2003 +0200, =?us-ascii?Q?Gunnar_Hellstrom?= wrote: >In the discussion about the sipdev spec, > >http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-01.txt , I >had earlier got positive reactions on a proposal: > >In 4.9 Ringer Behaviour : add the section below for the >purpose of people in the garden, in noisy >locations, and for the use by deaf, hearing impaired, deaf-blind people. > >"SIP Telephony devices MUST provide an external interface to >an external alerting system." > >I cannot find much from that proposal in the new wording, so I repeat the >proposal a bit more elaborated: > >Such external interfaces were normal in the PSTN era. It was easy to buy an >extra ringer to place in the garden or in the garage. It was easy to find >strong flashing light alerters to place in the factory. > >Such features must be remembered and available also in the SIP era. In PSTN, >the alerters were connected directly to the phone network. Now, it is >instead the SIP phone itself that knows if it is called. Therefore it must >be specified in the SIP device spec. > >Currently there are two kinds of electrical interfaces to alerting systems. > >Both are simple two wire interfaces. > >One is resistance oriented. It has a high resistance ( 1 Mohm) until the >alert is wanted. Then the resistance is low ( below 50 ohm ). It can sustain >a voltage of at least 50 V in the inactivated state, and a current of 200 mA >in the activated state. > >The other is voltage oriented. A voltage over the interface triggers the >alerting. 12 V direct or alternating is common. > >Since both usually are available on alerting systems, I suggest that it can >be sufficient to provide the resistance oriented one on SIP phones. > >I would also suggest an extension with a Bluetooth interface. Using the >serial port profile, and giving an AT command response "RING" as the basic >standard. It might be suitable to have extensions from this basic version >into variants where you can specify some characteristics of the alert. > >So, my proposal is to change from: >.....................................Current >writing.......................................... >4.9 Ringer Behavior > > The manner in which a user is alerted to an incoming call (visually, > audibly or possibly both) MAY be used by the device. This includes > the different volumes and MAY point to a file that contains the > melody for the ringer alert. > > Ringer sound files MAY be specified for the following types of > incoming calls normal, high priority, internal and external. > > Different ringer sound files MAY also be associated with different > lines. > > The location of a call MAY also be indicated. This allows using the > phone by hearing-impaired or in noisy environments where external > speakers are used to render the sound. The location of the call is > also useful for paging by speakerphones. >:::::::::::::::::::End of current >writing::::::::::::::::::::::::::::::::::::::::::::::::::::::: > >To: >::::::::::::::::::New >proposal::::::::::::::::::::::::::::::::::::::::::::::: >4.9 Ringer Behavior > > The manner in which a user is alerted to an incoming call (visually, > audibly or possibly both) MAY be configured in the device. This includes > different volumes and the configuration MAY point to a file that contains >a > melody for the ringer alert. > > Ringer sound files MAY be specified for the following types of > incoming calls: normal, high priority, internal and external. > > Different ringer sound files MAY also be associated with different > lines. > > The location of a call MAY also be indicated. This allows using the > phone by hearing-impaired or in noisy environments where external > speakers are used to render the sound. The location of the call is > also useful for paging by speakerphones. > > SIP Telephony devices MUST provide an external interface to > an external alerting system. This allows free positioning and selection >of an alerting > system that may be visual, audible or tactile or any combination of these >modes. > An external interface MAY be a two-pole electrical interface offering > low resistance (<50 ohm) during ring signals, and high resistance ( > 1 >Mohm ) between > ring indications. > It MAY also be a Bluetooth inteface with the serial profile sending the >"RING" > message at each ring signal. >-------------------------------------End of modified >proposal------------------------------ > > >Agree? > > >Gunnar Hellstrom >------------------------------------------- >Gunnar Hellstrom, Omnitor, Renathvagen 2 >SE 121 37 Johanneshov, SWEDEN >Tel: +46 8 556 002 03 Mob: +46 708204288 >e-mail: gunnar.hellstrom@omnitor.se >web: www.omnitor.se > > > > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP --=====================_19993158==_.ALT Content-Type: text/html; charset="us-ascii" Gunnar,

In writing this requirement, if you are going to detail possible solutions, could you also add the possibility that a SIP INVITE message could be forked to separate devices providing the enhanced alerting (visual or louder audio) over the SIP device's existing data networking environment (Wired LAN, Bluetooth, Wi-Fi, etc).  Thus the phone device solution may be software-oriented and re-using hardware that may be separately located on a home LAN.

Thanks.
Mike


At 06:55 PM 6/23/2003 +0200, =?us-ascii?Q?Gunnar_Hellstrom?= wrote:
In the discussion about the sipdev spec,

http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-01.txt , I
had earlier got positive reactions on a proposal:

In 4.9 Ringer Behaviour  : add the section below for the
purpose of people in the garden, in noisy
locations, and for the use by deaf, hearing impaired, deaf-blind people.

"SIP Telephony devices MUST provide an external interface to
an external alerting system."

I cannot find much from that proposal in the new wording, so I repeat the
proposal a bit more elaborated:

Such external interfaces were normal in the PSTN era. It was easy to buy an
extra ringer to place in the garden or in the garage. It was easy to find
strong flashing light alerters to place in the factory.

Such features must be remembered and available also in the SIP era. In PSTN,
the alerters were connected directly to the phone network. Now, it is
instead the SIP phone itself that knows if it is called. Therefore it must
be specified in the SIP device spec.

Currently there are two kinds of electrical interfaces to alerting systems.

Both are simple two wire interfaces.

One is resistance oriented. It has a high resistance ( 1 Mohm) until the
alert is wanted. Then the resistance is low ( below 50 ohm ). It can sustain
a voltage of at least 50 V in the inactivated state, and a current of 200 mA
in the activated state.

The other is voltage oriented. A voltage over the interface triggers the
alerting. 12 V direct or alternating is common.

Since both usually are available on alerting systems, I suggest that it can
be sufficient to provide the resistance oriented one on SIP phones.

I would also suggest an extension with a Bluetooth interface. Using the
serial port profile, and giving an AT command response "RING" as the basic
standard. It might be suitable to have extensions from this basic version
into variants where you can specify some characteristics of the alert.

So, my proposal is to change from:
.....................................Current
writing..........................................
4.9 Ringer Behavior

   The manner in which a user is alerted to an incoming call (visually,
   audibly or possibly both) MAY be used by the device. This includes
   the different volumes and MAY point to a file that contains the
   melody for the ringer alert.

   Ringer sound files MAY be specified for the following types of
   incoming calls normal, high priority, internal and external.

   Different ringer sound files MAY also be associated with different
   lines.

   The location of a call MAY also be indicated. This allows using the
   phone by hearing-impaired or in noisy environments where external
   speakers are used to render the sound. The location of the call is
   also useful for paging by speakerphones.
:::::::::::::::::::End of current
writing:::::::::::::::::::::::::::::::::::::::::::::::::::::::

To:
::::::::::::::::::New
proposal:::::::::::::::::::::::::::::::::::::::::::::::
4.9 Ringer Behavior

   The manner in which a user is alerted to an incoming call (visually,
   audibly or possibly both) MAY be configured in the device. This includes
   different volumes and the configuration MAY point to a file that contains
a
   melody for the ringer alert.

   Ringer sound files MAY be specified for the following types of
   incoming calls: normal, high priority, internal and external.

   Different ringer sound files MAY also be associated with different
   lines.

   The location of a call MAY also be indicated. This allows using the
   phone by hearing-impaired or in noisy environments where external
   speakers are used to render the sound. The location of the call is
   also useful for paging by speakerphones.

   SIP Telephony devices MUST provide an external interface to
   an external alerting system. This allows free positioning and selection
of an alerting
   system that may be visual, audible or tactile or any combination of these
modes.
   An external interface MAY be a two-pole electrical interface offering
   low resistance (<50 ohm) during ring signals, and high resistance ( > 1
Mohm ) between
   ring indications.
   It MAY also be a Bluetooth inteface with the serial profile sending the
"RING"
   message at each ring signal.
-------------------------------------End of modified
proposal------------------------------


Agree?


Gunnar Hellstrom
-------------------------------------------
Gunnar Hellstrom, Omnitor, Renathvagen 2
SE 121 37 Johanneshov, SWEDEN
Tel: +46 8 556 002 03  Mob: +46 708204288
e-mail: gunnar.hellstrom@omnitor.se
web: www.omnitor.se




_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP
--=====================_19993158==_.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 Tue Jul 1 10:09:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00997 for ; Tue, 1 Jul 2003 10:09:33 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h61E96I24925 for sipping-archive@odin.ietf.org; Tue, 1 Jul 2003 10: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 19XLoG-0006LF-V8 for sipping-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 10:08:42 -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 KAA00836 for ; Tue, 1 Jul 2003 10:08: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 19XLne-00066N-AQ; Tue, 01 Jul 2003 10:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wqqr-0006hx-31 for sipping@optimus.ietf.org; Mon, 30 Jun 2003 01:06: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 BAA17947 for ; Mon, 30 Jun 2003 01:05:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WqqZ-0003Pe-00 for sipping@ietf.org; Mon, 30 Jun 2003 01:04:59 -0400 Received: from mail3.pi.se ([195.7.64.137]) by ietf-mx with esmtp (Exim 4.12) id 19WqqO-0003PX-00 for sipping@ietf.org; Mon, 30 Jun 2003 01:04:48 -0400 Received: from VAIOMHP (h158n2fls31o265.telia.com [217.208.189.158]) (authenticated) by mail3.pi.se (8.11.2/8.11.2) with ESMTP id h5U54PQ20402; Mon, 30 Jun 2003 07:04:25 +0200 (CEST) From: =?us-ascii?Q?Gunnar_Hellstrom?= To: "Henry Sinnreich" , "'Sipping@Ietf. Org'" , , "'Mike Spanner'" , "'James Hamlin'" , , , , , "'Guido Gybels'" , , "'Judy Harkins'" , "'Trefor Davies'" Cc: , , , Subject: SV: [Sipping] Sipdev, incoming call alert (ring signal equivalents) Date: Mon, 30 Jun 2003 07:04:14 +0200 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <000601c33e8f$9deebc60$a59832a6@hsinnreich2> 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, It is not the external alerting devices themselves that are part of the spec, it is just the signal to them from the sip device. The need is valid in business as well as other environments. A question: There is a sentence in the original sipdev-01 spec about the location of the call that I do not understand, please explain. "> The location of a call MAY also be indicated." Further answers below. Gunnar ------------------------------------------- Gunnar Hellstrom, Omnitor, Renathvagen 2 SE 121 37 Johanneshov, SWEDEN Tel: +46 8 556 002 03 Mob: +46 708204288 e-mail: gunnar.hellstrom@omnitor.se web: www.omnitor.se > -----Ursprungligt meddelande----- > Fran: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com] > Skickat: den 30 juni 2003 00:42 > Till: 'Gunnar Hellstrom'; 'Sipping@Ietf. Org'; A.vWijk@viataal.nl; 'Mike > Spanner'; 'James Hamlin'; paulej@packetizer.com; > Erik.Zetterstrom@omnitor.se; andreas.piirimets@omnitor.se; > barry.dingle@bigfoot.com.au; 'Guido Gybels'; gv@trace.wisc.edu; 'Judy > Harkins'; 'Trefor Davies'; 'Henry Sinnreich' > Kopia: trefor@trefor.plus.com; jorgen.bjorkner@hotsip.com; > marcelo@envilogg.se; rkumar@cisco.com > Amne: RE: [Sipping] Sipdev, incoming call alert (ring signal > equivalents) > > > > Such external interfaces were normal in the PSTN era. It was > > easy to buy an extra ringer to place in the garden or in the > > garage. It was easy to find strong flashing light alerters to > > place in the factory. > > There are now other options, such as cordless phone, alerting devices, > 802.11 SIP phones and one imagine also alerting devices that are optical > and wireless. Yes, that is what I proposed to require - interfaces to external alerting devices, wired or wireless. > > -Do you really want to propagate the those from the PSTN era? Yes, the human need to be alerted on calls persists. > > -Should this really be specified for all SIP phones? Yes, you never know what installation environment they end up in. > > -What about the SIP business phones? (Related I-D) Same need. > > Henry > > > -----Original Message----- > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > On Behalf Of Gunnar Hellstrom > > Sent: Monday, June 23, 2003 11:56 AM > > To: 'Sipping@Ietf. Org'; A.vWijk@viataal.nl; 'Mike Spanner'; > > 'James Hamlin'; paulej@packetizer.com; > > Erik.Zetterstrom@omnitor.se; andreas.piirimets@omnitor.se; > > barry.dingle@bigfoot.com.au; 'Guido Gybels'; > > gv@trace.wisc.edu; 'Judy Harkins'; 'Trefor Davies'; Henry Sinnreich > > Cc: trefor@trefor.plus.com; jorgen.bjorkner@hotsip.com; > > marcelo@envilogg.se; rkumar@cisco.com > > Subject: [Sipping] Sipdev, incoming call alert (ring signal > > equivalents) > > > > > > In the discussion about the sipdev spec, > > > > http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req > > -01.txt , I had earlier got positive reactions on a proposal: > > > > In 4.9 Ringer Behaviour : add the section below for the > > purpose of people in the garden, in noisy locations, and for > > the use by deaf, hearing impaired, deaf-blind people. > > > > "SIP Telephony devices MUST provide an external interface to > > an external alerting system." > > > > I cannot find much from that proposal in the new wording, so > > I repeat the proposal a bit more elaborated: > > > > Such external interfaces were normal in the PSTN era. It was > > easy to buy an extra ringer to place in the garden or in the > > garage. It was easy to find strong flashing light alerters to > > place in the factory. > > > > Such features must be remembered and available also in the > > SIP era. In PSTN, the alerters were connected directly to the > > phone network. Now, it is instead the SIP phone itself that > > knows if it is called. Therefore it must be specified in the > > SIP device spec. > > > > Currently there are two kinds of electrical interfaces to > > alerting systems. > > > > Both are simple two wire interfaces. > > > > One is resistance oriented. It has a high resistance ( 1 > > Mohm) until the alert is wanted. Then the resistance is low ( > > below 50 ohm ). It can sustain a voltage of at least 50 V in > > the inactivated state, and a current of 200 mA in the activated state. > > > > The other is voltage oriented. A voltage over the interface > > triggers the alerting. 12 V direct or alternating is common. > > > > Since both usually are available on alerting systems, I > > suggest that it can be sufficient to provide the resistance > > oriented one on SIP phones. > > > > I would also suggest an extension with a Bluetooth interface. > > Using the serial port profile, and giving an AT command > > response "RING" as the basic standard. It might be suitable > > to have extensions from this basic version into variants > > where you can specify some characteristics of the alert. > > > > So, my proposal is to change from: > > .....................................Current > > writing.......................................... > > 4.9 Ringer Behavior > > > > The manner in which a user is alerted to an incoming call > > (visually, > > audibly or possibly both) MAY be used by the device. This includes > > the different volumes and MAY point to a file that contains the > > melody for the ringer alert. > > > > Ringer sound files MAY be specified for the following types of > > incoming calls normal, high priority, internal and external. > > > > Different ringer sound files MAY also be associated with different > > lines. > > > > The location of a call MAY also be indicated. This allows using the > > phone by hearing-impaired or in noisy environments where external > > speakers are used to render the sound. The location of the call is > > also useful for paging by speakerphones. > > :::::::::::::::::::End of current > > writing::::::::::::::::::::::::::::::::::::::::::::::::::::::: > > > > To: > > ::::::::::::::::::New > > proposal::::::::::::::::::::::::::::::::::::::::::::::: > > 4.9 Ringer Behavior > > > > The manner in which a user is alerted to an incoming call > > (visually, > > audibly or possibly both) MAY be configured in the device. > > This includes > > different volumes and the configuration MAY point to a > > file that contains a > > melody for the ringer alert. > > > > Ringer sound files MAY be specified for the following types of > > incoming calls: normal, high priority, internal and external. > > > > Different ringer sound files MAY also be associated with different > > lines. > > > > The location of a call MAY also be indicated. This allows using the > > phone by hearing-impaired or in noisy environments where external > > speakers are used to render the sound. The location of the call is > > also useful for paging by speakerphones. > > > > SIP Telephony devices MUST provide an external interface to > > an external alerting system. This allows free positioning > > and selection of an alerting > > system that may be visual, audible or tactile or any > > combination of these modes. > > An external interface MAY be a two-pole electrical > > interface offering > > low resistance (<50 ohm) during ring signals, and high > > resistance ( > 1 Mohm ) between > > ring indications. > > It MAY also be a Bluetooth inteface with the serial > > profile sending the "RING" > > message at each ring signal. > > -------------------------------------End of modified > > proposal------------------------------ > > > > > > Agree? > > > > > > Gunnar Hellstrom > > ------------------------------------------- > > Gunnar Hellstrom, Omnitor, Renathvagen 2 > > SE 121 37 Johanneshov, SWEDEN > > Tel: +46 8 556 002 03 Mob: +46 708204288 > > e-mail: gunnar.hellstrom@omnitor.se > > web: www.omnitor.se > > > > > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the 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 Jul 1 10:54:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00859 for ; Tue, 1 Jul 2003 10:08:48 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h61E8Hf23775 for sipping-archive@odin.ietf.org; Tue, 1 Jul 2003 10:08:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XLnt-0006BO-Lf for sipping-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 10:08: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 KAA00763 for ; Tue, 1 Jul 2003 10:08:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XLnp-0004sX-00 for sipping-web-archive@ietf.org; Tue, 01 Jul 2003 10:08:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XLnj-0004sO-00 for sipping-web-archive@ietf.org; Tue, 01 Jul 2003 10:08:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XLnf-00067J-Ut; Tue, 01 Jul 2003 10:08:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XExj-0001uG-Qj for sipping@optimus.ietf.org; Tue, 01 Jul 2003 02:50: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 CAA16080 for ; Tue, 1 Jul 2003 02:49:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XExa-00008m-00 for sipping@ietf.org; Tue, 01 Jul 2003 02:49:50 -0400 Received: from bbs.izone.net.au ([202.160.128.31]) by ietf-mx with esmtp (Exim 4.12) id 19XExA-00008Z-00 for sipping@ietf.org; Tue, 01 Jul 2003 02:49:25 -0400 Received: from bazza (dialup-204.54.194.203.acc04-dryb-mel.comindico.com.au [203.194.54.204]) by bbs.izone.net.au (8.11.2/8.11.2) with SMTP id h616N7E31093; Tue, 1 Jul 2003 16:23:07 +1000 Message-ID: <007301c33f9d$141bfde0$cc36c2cb@bazza> From: "Barry Dingle" To: "SIPPING" Cc: , , , , , , , , , , , , , , , "A vWijk" , "Rajesh Kumar" , "Barry Dingle" References: <004f01c33f9b$ac69c700$cc36c2cb@bazza> Date: Tue, 1 Jul 2003 16:50:31 +1000 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Subject: [Sipping] Rationale for the support of RFC2793/T.140 in SIP Telephone Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 all, Following discussions on a side email group, I have tried to provide some background information about some of the thinking behind the RFC2793/T.140 issue that will be raised at SIPPING in Vienna. /Barry DINGLE Project Manager - ACIF Any-to-Any Text Connectivity Options WG Telecommunications Consultant Fellow of the University of Melbourne barry.dingle@bigfoot.com.au Mob: +61 41 911 7578 Fixed: +61 3 9725 3937 ================================== Purpose -------------- Enable real-time text communication services on SIP Telephones for general purpose use and for use by people who are deaf or have hearing and/or speech impairments. Background ----------------- Real-time Text communication services are very useful for people with hearing and/or speech impairments as well as for any person who wants to converse in text mode eg. to transfer precise details (eg. money amounts, email addresses). About 5% of the population has hearing problems [3GPP]. The population is aging so hearing related communication problems are likely to increase. In some countries, there are Regulatory requirements for 'mainstream' telephone networks to support "equivalent" service for people with disabilities for accessing emergency services - usually implemented real-time Text services. Real-time text communication is a service provided on the PSTN and now on mobile/cellular telephone networks using TTYs and Textphones to enable people who are deaf or have hearing or speech impairment to communicate. Some countries are actively considering how to remove the TTY - over time - because of the problems that are experienced by the networks and the restricted terminal options that a 'special' device causes. One of the main problems that has restricted the provision of real-time Text service in the PSTN to the hearing and speech impaired has been the use of different Textphone specifications making development of new services very difficult. The ITU-T V.18 specification defines both interworking between different Textphone devices and a new, multimedia aligned Textphone specification. That new Textphone specification is based on the T.140 presentation protocol. T.140 is a very simple protocol that is defined for use by Text services in Video telephony/conferencing (ISDN, H.323, SIP based). (The details of T.140 are contained in 5 ITU-T pages!) T.140 specifies the use of UTF-8 transmission. << T.140 is an integral part of the 'Total Conversation' concept used by ITU-T , ETSI, IETF and 3GPP - incorporating text, speech and video. (See F.703, WISDOM project, RFC3351 and 3GPP 22.226.) >> RFC2793 defines the use of T.140 with RTP to support text services. It also has an optional redundancy capability to further improve the text transfer reliability. SIP is a session initiation protocol that facilitates the establishment of multimedia communication between two entities, including voice, video, and text communication. SIP allows true real-time text communication services to be supported consistently across many technologies. Next Generation Networks (NGNs) is actively looking at providing equivalent PSTN/ISDN services over IP technology. The requirements of PSTN will be carried into the IP environment particularly where Regulations are service based and not technology based. Messaging is a related, similar service. The non-real-time nature can be a problem in some communication situations - including regulatory. Interworking between real-time text services and Messaging services is desirable. A consistent approach to real-time text services will assist the interworking. Rationale ------------- 1. There is growing interest in providing for text communication services as 'mainstream' instead of an 'added extra' - to benefit users, suppliers and carriers. 2. The work towards Next Generation Networks is looking at replacing PSTN networks (over time) with IP-based networks. The key to the success of such activity is the provision of at least equivalent services. Migration of telephone calls from PSTN to IP-based networks will be facilitated if the legacy services are supported. 3. T.140 is very simple and is important in providing a smooth interface between legacy text services in the PSTN/ISDN and IP-based real-time text services whilst minimising gateway functionality. 4. SIP should support equivalent TTY service - but not be forced to ONLY support ancient TTYs and their non-standard modems over IP. (Comment - assumes that the support of TTY/Textphone over IP ie. carriage of TTY-type modem tones, is only be a fallback call case.) 5. Support of RFC2793 in SIP terminals would provide an indication to terminal suppliers, networks, servers, gateways that support for text services is required. (Any breakdown in the end-to-end capability will remove the end-to-end service.) Recommendation ------------------------- All SIP Telephones MUST support RFC2793 in order that legacy text services and interworking with TTY/Textphones can be supported in an IP-friendly manner. ======================== _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 1 10:54:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00861 for ; Tue, 1 Jul 2003 10:08:48 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h61E8K623826 for sipping-archive@odin.ietf.org; Tue, 1 Jul 2003 10:08:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XLnw-0006By-4V for sipping-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 10:08: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 KAA00752 for ; Tue, 1 Jul 2003 10:08:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XLno-0004sS-00 for sipping-web-archive@ietf.org; Tue, 01 Jul 2003 10:08:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XLnj-0004sN-00 for sipping-web-archive@ietf.org; Tue, 01 Jul 2003 10:08:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XLnd-00065y-K9; Tue, 01 Jul 2003 10: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 19Wlj5-0002xD-SS for sipping@optimus.ietf.org; Sun, 29 Jun 2003 19:38: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 SAA10147 for ; Sun, 29 Jun 2003 18:43:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Wksw-0006vE-00 for sipping@ietf.org; Sun, 29 Jun 2003 18:43:02 -0400 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by ietf-mx with esmtp (Exim 4.12) id 19Wksl-0006u6-00 for sipping@ietf.org; Sun, 29 Jun 2003 18:42:51 -0400 Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HH900C6GLPMFF@firewall.wcom.com> for sipping@ietf.org; Sun, 29 Jun 2003 22:41:46 +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 <0HH900001LPM9P@dgismtp04.wcomnet.com>; Sun, 29 Jun 2003 22:41:46 +0000 (GMT) Received: from hsinnreich2 ([166.50.152.165]) by dgismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HH90000BLPJ3W@dgismtp04.wcomnet.com>; Sun, 29 Jun 2003 22:41:45 +0000 (GMT) Date: Sun, 29 Jun 2003 17:41:42 -0500 From: Henry Sinnreich Subject: RE: [Sipping] Sipdev, incoming call alert (ring signal equivalents) In-reply-to: To: "'Gunnar Hellstrom'" , "'Sipping@Ietf. Org'" , A.vWijk@viataal.nl, "'Mike Spanner'" , "'James Hamlin'" , paulej@packetizer.com, Erik.Zetterstrom@omnitor.se, andreas.piirimets@omnitor.se, barry.dingle@bigfoot.com.au, "'Guido Gybels'" , gv@trace.wisc.edu, "'Judy Harkins'" , "'Trefor Davies'" , "'Henry Sinnreich'" Cc: trefor@trefor.plus.com, jorgen.bjorkner@hotsip.com, marcelo@envilogg.se, rkumar@cisco.com Message-id: <000601c33e8f$9deebc60$a59832a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 > Such external interfaces were normal in the PSTN era. It was > easy to buy an extra ringer to place in the garden or in the > garage. It was easy to find strong flashing light alerters to > place in the factory. There are now other options, such as cordless phone, alerting devices, 802.11 SIP phones and one imagine also alerting devices that are optical and wireless. -Do you really want to propagate the those from the PSTN era? -Should this really be specified for all SIP phones? -What about the SIP business phones? (Related I-D) Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of Gunnar Hellstrom > Sent: Monday, June 23, 2003 11:56 AM > To: 'Sipping@Ietf. Org'; A.vWijk@viataal.nl; 'Mike Spanner'; > 'James Hamlin'; paulej@packetizer.com; > Erik.Zetterstrom@omnitor.se; andreas.piirimets@omnitor.se; > barry.dingle@bigfoot.com.au; 'Guido Gybels'; > gv@trace.wisc.edu; 'Judy Harkins'; 'Trefor Davies'; Henry Sinnreich > Cc: trefor@trefor.plus.com; jorgen.bjorkner@hotsip.com; > marcelo@envilogg.se; rkumar@cisco.com > Subject: [Sipping] Sipdev, incoming call alert (ring signal > equivalents) > > > In the discussion about the sipdev spec, > > http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req > -01.txt , I had earlier got positive reactions on a proposal: > > In 4.9 Ringer Behaviour : add the section below for the > purpose of people in the garden, in noisy locations, and for > the use by deaf, hearing impaired, deaf-blind people. > > "SIP Telephony devices MUST provide an external interface to > an external alerting system." > > I cannot find much from that proposal in the new wording, so > I repeat the proposal a bit more elaborated: > > Such external interfaces were normal in the PSTN era. It was > easy to buy an extra ringer to place in the garden or in the > garage. It was easy to find strong flashing light alerters to > place in the factory. > > Such features must be remembered and available also in the > SIP era. In PSTN, the alerters were connected directly to the > phone network. Now, it is instead the SIP phone itself that > knows if it is called. Therefore it must be specified in the > SIP device spec. > > Currently there are two kinds of electrical interfaces to > alerting systems. > > Both are simple two wire interfaces. > > One is resistance oriented. It has a high resistance ( 1 > Mohm) until the alert is wanted. Then the resistance is low ( > below 50 ohm ). It can sustain a voltage of at least 50 V in > the inactivated state, and a current of 200 mA in the activated state. > > The other is voltage oriented. A voltage over the interface > triggers the alerting. 12 V direct or alternating is common. > > Since both usually are available on alerting systems, I > suggest that it can be sufficient to provide the resistance > oriented one on SIP phones. > > I would also suggest an extension with a Bluetooth interface. > Using the serial port profile, and giving an AT command > response "RING" as the basic standard. It might be suitable > to have extensions from this basic version into variants > where you can specify some characteristics of the alert. > > So, my proposal is to change from: > .....................................Current > writing.......................................... > 4.9 Ringer Behavior > > The manner in which a user is alerted to an incoming call > (visually, > audibly or possibly both) MAY be used by the device. This includes > the different volumes and MAY point to a file that contains the > melody for the ringer alert. > > Ringer sound files MAY be specified for the following types of > incoming calls normal, high priority, internal and external. > > Different ringer sound files MAY also be associated with different > lines. > > The location of a call MAY also be indicated. This allows using the > phone by hearing-impaired or in noisy environments where external > speakers are used to render the sound. The location of the call is > also useful for paging by speakerphones. > :::::::::::::::::::End of current > writing::::::::::::::::::::::::::::::::::::::::::::::::::::::: > > To: > ::::::::::::::::::New > proposal::::::::::::::::::::::::::::::::::::::::::::::: > 4.9 Ringer Behavior > > The manner in which a user is alerted to an incoming call > (visually, > audibly or possibly both) MAY be configured in the device. > This includes > different volumes and the configuration MAY point to a > file that contains a > melody for the ringer alert. > > Ringer sound files MAY be specified for the following types of > incoming calls: normal, high priority, internal and external. > > Different ringer sound files MAY also be associated with different > lines. > > The location of a call MAY also be indicated. This allows using the > phone by hearing-impaired or in noisy environments where external > speakers are used to render the sound. The location of the call is > also useful for paging by speakerphones. > > SIP Telephony devices MUST provide an external interface to > an external alerting system. This allows free positioning > and selection of an alerting > system that may be visual, audible or tactile or any > combination of these modes. > An external interface MAY be a two-pole electrical > interface offering > low resistance (<50 ohm) during ring signals, and high > resistance ( > 1 Mohm ) between > ring indications. > It MAY also be a Bluetooth inteface with the serial > profile sending the "RING" > message at each ring signal. > -------------------------------------End of modified > proposal------------------------------ > > > Agree? > > > Gunnar Hellstrom > ------------------------------------------- > Gunnar Hellstrom, Omnitor, Renathvagen 2 > SE 121 37 Johanneshov, SWEDEN > Tel: +46 8 556 002 03 Mob: +46 708204288 > e-mail: gunnar.hellstrom@omnitor.se > web: www.omnitor.se > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 Jul 1 13:48:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08639 for ; Tue, 1 Jul 2003 13:48:34 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RIOS623301 for sipping-archive@odin.ietf.org; Fri, 27 Jun 2003 14:24:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VxtZ-00062j-W7 for sipping-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 14:24:26 -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 OAA09644 for ; Fri, 27 Jun 2003 14:24: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 19VxrS-0004qj-MM; Fri, 27 Jun 2003 14:22:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VuTW-0002NW-25 for sipping@optimus.ietf.org; Fri, 27 Jun 2003 10:45:18 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22505; Fri, 27 Jun 2003 07:33:41 -0400 (EDT) Message-Id: <200306271133.HAA22505@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, 27 Jun 2003 07:33:40 -0400 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-session-policy-req-00.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : Requirements for Session Policy for the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-sipping-session-policy-req-00.txt Pages : 15 Date : 2003-6-26 The proxy server plays a central role as an intermediary in the establishment of sessions in the Session Initiation Protocol (SIP). In that role, they can define and impact policies on call routing, rendezvous, and other call features. However, there is no standard means by which proxies can have any influence on session policies, such as the codecs that are to be used. As such, ad-hoc and non-conformant techniques have been deployed to allow for such policy mechanisms. There is a need for a standards-based and complete mechanism for session policies. This document defines a set of requirements for such a mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-session-policy-req-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sipping-session-policy-req-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sipping-session-policy-req-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-27074958.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-session-policy-req-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-session-policy-req-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-27074958.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 Jul 2 01: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 BAA28108 for ; Wed, 2 Jul 2003 01: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 19Xa2P-0006Hd-R1 for sipping-archive@odin.ietf.org; Wed, 02 Jul 2003 01:20:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h625KDs9024149 for sipping-archive@odin.ietf.org; Wed, 2 Jul 2003 01:20:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xa2P-0006HQ-Nv for sipping-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 01:20: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 BAA28104 for ; Wed, 2 Jul 2003 01:20:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xa2M-0005kR-00 for sipping-web-archive@ietf.org; Wed, 02 Jul 2003 01:20:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Xa2M-0005kO-00 for sipping-web-archive@ietf.org; Wed, 02 Jul 2003 01: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 19Xa2E-0006GJ-5G; Wed, 02 Jul 2003 01: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 19Xa1g-0006FQ-Ow for sipping@optimus.ietf.org; Wed, 02 Jul 2003 01:19: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 BAA28096 for ; Wed, 2 Jul 2003 01:19:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xa1d-0005k7-00 for sipping@ietf.org; Wed, 02 Jul 2003 01:19:25 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19Xa1c-0005jl-00 for sipping@ietf.org; Wed, 02 Jul 2003 01:19:25 -0400 Received: from dynamicsoft.com ([63.113.46.115]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h625IriB002677 for ; Wed, 2 Jul 2003 01:18:54 -0400 (EDT) Message-ID: <3F026B35.4030607@dynamicsoft.com> Date: Wed, 02 Jul 2003 01:18:45 -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: sipping Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] RTP denial of service Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 Folks, I'd like to draw your attention to the following I-D that I submitted recently: http://www.ietf.org/internet-drafts/draft-rosenberg-mmusic-rtp-denialofservice-00.txt This draft describes a denial-of-service attack using RTP. This attack can be launched using any protocol that uses an offer/answer-like SDP exchange, including SIP and RTSP. The attack is particularly troublesome in sip, as it is easy to launch and has excellent amplification properties. The draft proposes ICE (http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-ice-00.txt) as a solution to the problem. I posted a similar note to mmusic. Discussion should probably happen there, but I felt this topic would be of interest to folks in sipping who may not subscribe to mmusic. Comments 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 From exim@www1.ietf.org Wed Jul 2 06: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 GAA01925 for ; Wed, 2 Jul 2003 06: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 19XfDc-0002Go-TF for sipping-archive@odin.ietf.org; Wed, 02 Jul 2003 06:52:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62Aq8Zr008716 for sipping-archive@odin.ietf.org; Wed, 2 Jul 2003 06:52:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XfDc-0002GU-Pq for sipping-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 06: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 GAA01818 for ; Wed, 2 Jul 2003 06:52:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XfDY-00013G-00 for sipping-web-archive@ietf.org; Wed, 02 Jul 2003 06:52:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XfDX-00013A-00 for sipping-web-archive@ietf.org; Wed, 02 Jul 2003 06: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 19XfDU-0002EG-IB; Wed, 02 Jul 2003 06: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 19XfCi-00021C-OA for sipping@optimus.ietf.org; Wed, 02 Jul 2003 06:51:12 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01546; Wed, 2 Jul 2003 06:51:07 -0400 (EDT) Message-Id: <200307021051.GAA01546@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, 02 Jul 2003 06:51:07 -0400 Subject: [Sipping] I-D ACTION:draft-jennings-sipping-certs-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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Certificate Discover for SIP Author(s) : C. Jennings Filename : draft-jennings-sipping-certs-01.txt Pages : 11 Date : 2003-7-1 This draft describes a scheme in which a SIP user agent can create self signed certificate for use with the SIP S/MIME mechanism and can store the certificate on a web server associated with the address of record (AOR) for the user. Other user agents that want to call that AOR can retrieve these certificates from the web server. The result of this system is that, with no extra expense or effort for the end user, it is possible to have a reasonable degree of confidence about the identities of the parties in a SIP session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jennings-sipping-certs-01.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-jennings-sipping-certs-01.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-jennings-sipping-certs-01.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-7-1133651.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-jennings-sipping-certs-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-jennings-sipping-certs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-1133651.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 Jul 2 06: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 GAA01928 for ; Wed, 2 Jul 2003 06: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 19XfDc-0002Gz-U3 for sipping-archive@odin.ietf.org; Wed, 02 Jul 2003 06:52:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62Aq8VJ008722 for sipping-archive@odin.ietf.org; Wed, 2 Jul 2003 06:52:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XfDc-0002GV-Qe for sipping-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 06: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 GAA01820 for ; Wed, 2 Jul 2003 06:52:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XfDY-00013J-00 for sipping-web-archive@ietf.org; Wed, 02 Jul 2003 06:52:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XfDX-00013B-00 for sipping-web-archive@ietf.org; Wed, 02 Jul 2003 06: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 19XfDV-0002EV-C7; Wed, 02 Jul 2003 06: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 19XfD3-00022Q-6B for sipping@optimus.ietf.org; Wed, 02 Jul 2003 06:51:33 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01615; Wed, 2 Jul 2003 06:51:26 -0400 (EDT) Message-Id: <200307021051.GAA01615@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sipping@ietf.org, ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 02 Jul 2003 06:51:26 -0400 Subject: [Sipping] I-D ACTION:draft-mahy-sipping-smime-vs-digest-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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Discussion of suitability: S/MIME instead of Digest Authentication in the Session Initiation Protocol (SIP) Author(s) : R. Mahy Filename : draft-mahy-sipping-smime-vs-digest-01.txt Pages : 11 Date : 2003-7-1 Digest authentication (as defined in RFC2617) is used in SIP (RFC3261) for user authentication, and less frequently for message integrity of MIME bodies carried in SIP. Various members of the IETF security community have periodically suggested that Digest should be deprecated in favor of the SIP use of S/MIME (RFC2633), support for which was recently introduced in RFC3261. The author seeks clarity from the IETF security community on behalf of the SIP community about the feasibility and possible benefits of using S/MIME instead of Digest in one or both of these applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mahy-sipping-smime-vs-digest-01.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-mahy-sipping-smime-vs-digest-01.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-mahy-sipping-smime-vs-digest-01.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-7-1133733.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mahy-sipping-smime-vs-digest-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-mahy-sipping-smime-vs-digest-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-1133733.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 Jul 2 06:58: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 GAA03516 for ; Wed, 2 Jul 2003 06:58: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 19XfJP-0003TH-M4 for sipping-archive@odin.ietf.org; Wed, 02 Jul 2003 06:58:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62Aw7eN013312 for sipping-archive@odin.ietf.org; Wed, 2 Jul 2003 06: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 19XfJP-0003SZ-0s for sipping-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 06:58: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 GAA03421 for ; Wed, 2 Jul 2003 06:58:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XfJK-0001DJ-00 for sipping-web-archive@ietf.org; Wed, 02 Jul 2003 06:58:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XfJJ-0001DC-00 for sipping-web-archive@ietf.org; Wed, 02 Jul 2003 06: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 19XfJJ-0003Oi-Uj; Wed, 02 Jul 2003 06: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 19XfIQ-00030n-WE for sipping@optimus.ietf.org; Wed, 02 Jul 2003 06:57:07 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03139; Wed, 2 Jul 2003 06:57:03 -0400 (EDT) Message-Id: <200307021057.GAA03139@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, 02 Jul 2003 06:57:03 -0400 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-mwi-03.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP) Author(s) : R. Mahy Filename : draft-ietf-sipping-mwi-03.txt Pages : 22 Date : 2003-7-1 This draft proposes a SIP event package to carry message waiting status and message summaries from a messaging system to an interested User Agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-mwi-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sipping-mwi-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sipping-mwi-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-1134928.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-mwi-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-mwi-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-1134928.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 Jul 2 07:44: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 GAA03517 for ; Wed, 2 Jul 2003 06:58: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 19XfJP-0003TI-MI for sipping-archive@odin.ietf.org; Wed, 02 Jul 2003 06:58:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62Aw7lu013325 for sipping-archive@odin.ietf.org; Wed, 2 Jul 2003 06: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 19XfJP-0003Sh-5A for sipping-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 06:58: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 GAA03422 for ; Wed, 2 Jul 2003 06:58:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XfJK-0001DF-00 for sipping-web-archive@ietf.org; Wed, 02 Jul 2003 06:58:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XfJJ-0001DB-00 for sipping-web-archive@ietf.org; Wed, 02 Jul 2003 06: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 19XfJK-0003P9-TG; Wed, 02 Jul 2003 06: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 19XfIW-0003D7-Kb for sipping@optimus.ietf.org; Wed, 02 Jul 2003 06:57:12 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03161; Wed, 2 Jul 2003 06:57:08 -0400 (EDT) Message-Id: <200307021057.GAA03161@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, 02 Jul 2003 06:57:08 -0400 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-cc-conferencing-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: , --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 : Session Initiation Protocol Call Control - Conferencing for User Agents Author(s) : A. Johnston, O. Levin Filename : draft-ietf-sipping-cc-conferencing-01.txt Pages : 26 Date : 2003-7-1 This document defines conferencing call control features for the Session Initiation Protocol (SIP). This document builds on the Conferencing Requirements and Framework documents to define how a tightly coupled SIP conference works. The approach is explored from different user agent (UA) types perspective: conference-unaware, conference-aware and focus UAs. The use of URIs in conferencing, OPTIONS for capabilities discovery, and call control using REFER are covered in detail with example call flow diagrams. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-conferencing-01.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-cc-conferencing-01.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-cc-conferencing-01.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-7-1134939.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-cc-conferencing-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-cc-conferencing-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-1134939.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 Jul 2 11:45: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 LAA27531 for ; Wed, 2 Jul 2003 11:45: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 19XjnJ-0008Al-BW for sipping-archive@odin.ietf.org; Wed, 02 Jul 2003 11:45:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62FjHmx031415 for sipping-archive@odin.ietf.org; Wed, 2 Jul 2003 11:45:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xhhq-00013n-4K for sipping-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 09:31: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 JAA17130 for ; Wed, 2 Jul 2003 09:31:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xhho-0006HM-00 for sipping-web-archive@ietf.org; Wed, 02 Jul 2003 09:31:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Xhhn-0006HI-00 for sipping-web-archive@ietf.org; Wed, 02 Jul 2003 09:31:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XhhN-000127-Jh; Wed, 02 Jul 2003 09:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xhgs-00010H-54 for sipping@optimus.ietf.org; Wed, 02 Jul 2003 09:30: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 JAA17051 for ; Wed, 2 Jul 2003 09:30:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xhgq-0006Ez-00 for sipping@ietf.org; Wed, 02 Jul 2003 09:30:28 -0400 Received: from wiproecmx2.wipro.com ([164.164.31.6]) by ietf-mx with esmtp (Exim 4.12) id 19Xhgo-0006DI-00 for sipping@ietf.org; Wed, 02 Jul 2003 09:30:27 -0400 Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiproecmx2.wipro.com (8.12.9/8.12.9) with SMTP id h62DTdYw024809 for ; Wed, 2 Jul 2003 18:59:39 +0530 (IST) Received: from blr-ec-msg01.wipro.com ([10.200.50.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 2 Jul 2003 18:59:52 +0530 Received: from RANJITHEC ([10.200.8.116]) by blr-ec-msg01.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 2 Jul 2003 18:59:51 +0530 Reply-To: From: "Ranjith Mukundan" To: Date: Wed, 2 Jul 2003 19:00:32 +0530 Organization: Wipro Technologies Message-ID: <02a201c3409e$1ca60a80$7408c80a@RANJITHEC> 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.2627 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal X-OriginalArrivalTime: 02 Jul 2003 13:29:51.0909 (UTC) FILETIME=[0462A550:01C3409E] Content-Transfer-Encoding: 7bit Subject: [Sipping] DPNSS MIME I-D .02 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 folks, We've submitted .02 of the DPNSS MIME draft (see below). We've also requested for an agenda slot at Vienna to Present this draft and elicit your views on progressing this as a WG I-D. The changes from .01 to .02 are all basically to incorporate inputs that we received on this list; which are: 1-- Changing the Reference to Oftel's ND1301:2001/03 from BTNR 188 2-- Explicit Statment of DPNSS as private-NNI. 3-- Reference to the similarity of the semantics of DPNSS signalling messages to SIP messages. 4-- Restricting the Buffering option to segmented DPNSS messages alone. 5-- Rationale for retention of Buffering as an option rather than as a mandatory requirement. 6-- Correcting the example that illustrates the buffering options (221 octets instead of 225). 7-- Reference to Indication Field and Selection Field as part of the buffering option explation. 8-- Reference to a Segmentation Timer for realizing the buffering option. 9-- Additional clarifications in the section on Buffering. 10-- A new Section mandating the functioning of the SIP-DPNSS gateway as a 'Transit DPNSS PBX'. 11-- A new Section explicitly stating carraige of one DPNSS call per SIP dialogue. 12-- Explicity Reference to the Content-Disposition Header defined in RFC3204 instead of defining a new one. 13-- Inclusion of version 7.00 in the Version parameter description. 14-- Updating the description of the Version parameter description (e.g., reference to decimal instead of floating point etc; removal of phrases like "contiguously incrementing"). 15-- Rationale for inclusing of the version parameter. 16-- Updating the Reference Section to include Oftel's ND1301:2001/03. 17-- Updating the Acknowledgement section. Cheers, -- ranjith.. >-----Original Message----- >From: owner-ietf-announce@ietf.org >[mailto:owner-ietf-announce@ietf.org] On Behalf Of >Internet-Drafts@ietf.org >Sent: Wednesday, July 02, 2003 4:23 PM >To: IETF-Announce: >Subject: I-D ACTION:draft-mukundan-sipping-dpnss-02.txt > > >A New Internet-Draft is available from the on-line >Internet-Drafts directories. > > > Title : MIME media types for DPNSS Objects > Author(s) : R. Mukundan et al. > Filename : draft-mukundan-sipping-dpnss-02.txt > Pages : 11 > Date : 2003-7-1 > >This document describes Multipart Internet Mail Extensions >(MIME) type for application/Digital Private Network Signaling >System (DPNSS) objects for use in Session Initiation Protocol >(SIP) applications, according to the rules defined in RFC >2048. These types can be used to identify Digital Private >Network Signaling System 1 (DPNSS 1) objects within a SIP >message such as INVITE or INFO, as might be implemented when >using SIP in an environment where part of the call involves >interworking to DPNSS 1 based Private Networks. RFC 3204 >addresses a similar need for Integrated Service Digital >Network User Part (ISUP) and Q Signaling (QSIG). > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft->mukundan-sipping-dpnss-02.tx t > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of >the message. > >Internet-Drafts are also available by anonymous FTP. Login >with the username "anonymous" and a password of your e-mail >address. After logging in, type "cd internet-drafts" and then > "get draft-mukundan-sipping-dpnss-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-mukundan-sipping-dpnss-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 Wed Jul 2 11:47: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 LAA27926 for ; Wed, 2 Jul 2003 11:47: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 19Xjp3-0000S9-Fy for sipping-archive@odin.ietf.org; Wed, 02 Jul 2003 11:47:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62Fl5O7001735 for sipping-archive@odin.ietf.org; Wed, 2 Jul 2003 11:47:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xjp3-0000Ru-Bm for sipping-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 11:47: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 LAA27835 for ; Wed, 2 Jul 2003 11:47:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xjp2-0002cu-00 for sipping-web-archive@ietf.org; Wed, 02 Jul 2003 11:47:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Xjp1-0002cr-00 for sipping-web-archive@ietf.org; Wed, 02 Jul 2003 11:47:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xjo9-0008Nv-Iw; Wed, 02 Jul 2003 11: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 19XQln-0003P7-LZ for sipping@optimus.ietf.org; Tue, 01 Jul 2003 15:26:27 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10274; Tue, 1 Jul 2003 14:34:27 -0400 (EDT) Message-Id: <200307011834.OAA10274@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , sipping@ietf.org From: The IESG Date: Tue, 01 Jul 2003 14:34:27 -0400 Subject: [Sipping] Protocol Action: ISUP to SIP Mapping to Proposed Standard Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 IESG has approved publication of the following Internet-Drafts as Proposed Standards: o Mapping of ISUP Overlap Signaling to the Session Initiation Protocol This document is the product of the Session Initiation Proposal Investigation Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. Technical Summary The "ISUP to SIP Mapping" document takes into consideration ISUP en-bloc signalling, which means sending the complete telephone number of the callee in the first signalling message. Although modern switches always use en-bloc signalling, some parts of the PSTN still use overlap signalling, and this is the subject of the second document, "Mapping of ISUP Overlap Signaling to the Session Initial Protocol." Overlap signalling consists of sending just some digits of the callee's number in the first signalling message. Further digits are sent in subsequent signalling messages. Working Group Summary The current version of the document reflects the issues raised during the IETF Last Call. Protocol Quality This document was reviewed for the IESG by Allison Mankin. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 2 11: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 LAA28195 for ; Wed, 2 Jul 2003 11: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 19Xjtu-00011B-5E for sipping-archive@odin.ietf.org; Wed, 02 Jul 2003 11:52:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62Fq6Kp003907 for sipping-archive@odin.ietf.org; Wed, 2 Jul 2003 11:52:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xjtu-00010w-07 for sipping-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 11: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 LAA28107 for ; Wed, 2 Jul 2003 11:52:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xjtt-0002kB-00 for sipping-web-archive@ietf.org; Wed, 02 Jul 2003 11:52:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Xjts-0002k8-00 for sipping-web-archive@ietf.org; Wed, 02 Jul 2003 11: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 19Xjtp-0000yx-Mp; Wed, 02 Jul 2003 11: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 19Xjst-0000xi-Kz for sipping@optimus.ietf.org; Wed, 02 Jul 2003 11:51: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 LAA28091 for ; Wed, 2 Jul 2003 11:51:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xjss-0002j6-00 for sipping@ietf.org; Wed, 02 Jul 2003 11:51:02 -0400 Received: from tomts8.bellnexxia.net ([209.226.175.52] helo=tomts8-srv.bellnexxia.net) by ietf-mx with esmtp (Exim 4.12) id 19Xjsr-0002iz-00 for sipping@ietf.org; Wed, 02 Jul 2003 11:51:02 -0400 Received: from Shulin ([199.243.90.234]) by tomts8-srv.bellnexxia.net (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20030702155100.IALS24417.tomts8-srv.bellnexxia.net@Shulin> for ; Wed, 2 Jul 2003 11:51:00 -0400 From: "Shu-Lin CHen" To: Date: Wed, 2 Jul 2003 11:50:57 -0400 Message-ID: <005701c340b1$bc2bec10$390aa8c0@blueslicemtl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0058_01C34090.351A4C10" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <025801c339f1$a6db0920$2b1013ac@cn.utstar.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [Sipping] question re INIVITE client transaction on page 127 of RFC3261 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0058_01C34090.351A4C10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi: Re Figure 5 on page 127 of RFC3261, what will happen if final response is never received when transaction is in Proceeding state? Thanks. shu-lin ------=_NextPart_000_0058_01C34090.351A4C10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi:
 
Re Figure 5 on=20 page 127 of RFC3261, what will happen if final response is never = received when=20 transaction is in
Proceeding=20 state?
 
Thanks.
 
shu-lin
 
------=_NextPart_000_0058_01C34090.351A4C10-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 2 13:56: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 NAA04151 for ; Wed, 2 Jul 2003 13:56: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 19Xlpx-0002Mh-Ew for sipping-archive@odin.ietf.org; Wed, 02 Jul 2003 13:56:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62Hu9ul009087 for sipping-archive@odin.ietf.org; Wed, 2 Jul 2003 13:56:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xlpx-0002MU-Bp for sipping-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 13:56: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 NAA04123 for ; Wed, 2 Jul 2003 13:56:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xlpv-0004zq-00 for sipping-web-archive@ietf.org; Wed, 02 Jul 2003 13:56:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Xlpu-0004zn-00 for sipping-web-archive@ietf.org; Wed, 02 Jul 2003 13:56:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xlpq-0002Kg-Qy; Wed, 02 Jul 2003 13:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XlpX-0002KN-F6 for sipping@optimus.ietf.org; Wed, 02 Jul 2003 13:55: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 NAA04109 for ; Wed, 2 Jul 2003 13:55:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XlpV-0004zM-00 for sipping@ietf.org; Wed, 02 Jul 2003 13:55:41 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19XlpU-0004z5-00 for sipping@ietf.org; Wed, 02 Jul 2003 13:55:40 -0400 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by hoemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h62Ht7A16352 for ; Wed, 2 Jul 2003 12:55:07 -0500 (CDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2656.59) id <3CKZJHR9>; Wed, 2 Jul 2003 12:55:06 -0500 Message-ID: From: "Ejzak, Richard P (Richard)" To: "'Gonzalo Camarillo Gonzalez (LMF)'" , "'sipping@ietf.org'" Subject: RE: [Sipping] Last Call for early media use cases Date: Wed, 2 Jul 2003 12:55:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) 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: , Gonzalo, I sent an early media use case to the sipping exploder about 6 weeks ago, within a week of your email request (below). I have not seen anything on the exploder regarding an updated early media draft. Please provide some status. Thanks, Richard -----Original Message----- From: Gonzalo Camarillo Gonzalez (LMF) [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: Wednesday, May 14, 2003 2:13 AM To: 'sipping@ietf.org' Cc: Jon Peterson (E-mail); Rohan Mahy (E-mail); Dean Willis (E-mail) Subject: [Sipping] Last Call for early media use cases Folks, in the last IETF meeting, we requested early media use cases that show the need of a "media coming" flag. So far, we have not received anything. We intend to release a new version of the early media draft in a week or so. So, that is the time you have to send me your use cases. Thanks, Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Jul 2 16:04: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 QAA10460 for ; Wed, 2 Jul 2003 16:04: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 19Xnpq-0008Qz-5f for sipping-archive@odin.ietf.org; Wed, 02 Jul 2003 16:04:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62K4AV2032417 for sipping-archive@odin.ietf.org; Wed, 2 Jul 2003 16:04:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xnpq-0008Qm-2V for sipping-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 16:04: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 QAA10435 for ; Wed, 2 Jul 2003 16:04:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xnpm-0006ip-00 for sipping-web-archive@ietf.org; Wed, 02 Jul 2003 16:04:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Xnpm-0006im-00 for sipping-web-archive@ietf.org; Wed, 02 Jul 2003 16:04:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xnph-0008Pd-Rq; Wed, 02 Jul 2003 16: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 19XnpX-0008PF-02 for sipping@optimus.ietf.org; Wed, 02 Jul 2003 16:03: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 QAA10423 for ; Wed, 2 Jul 2003 16:03:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XnpT-0006iI-00 for sipping@ietf.org; Wed, 02 Jul 2003 16:03:47 -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 19XnpT-0006hU-00 for sipping@ietf.org; Wed, 02 Jul 2003 16:03:47 -0400 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h62K3F7F009290 for ; Wed, 2 Jul 2003 13:03:15 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA09588 for ; Wed, 2 Jul 2003 13:03:14 -0700 (PDT) Message-Id: <4.3.2.7.2.20030702144938.021a6e50@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 02 Jul 2003 15:03:15 -0500 To: sipping@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Sipping] New ID for Location Conveyance in 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: , There has been an Internet Draft posted for the conveyance of location of a UAC within a SIP message. Part of the requirements within this ID are included for the location information to be placed in a message body providing adherence to Geopriv's privacy and security concerns are addressed. Part of the requirements are calling for an extension to SIP to create a Location Header (or headers) when proper call routing requires knowledge of where the UAC is. The following is the document's abstract" Abstract This document presents the requirements for an extension to the Session Initiation Protocol (SIP) [1] for conveyance of user location information from one Session Initiation Protocol (SIP) User Agent to another SIP User Agent. The idea that in some cases the UAC's location could affect proper routing of the SIP message is explored as well. http://www.ietf.org/internet-drafts/draft-polk-sipping-location-requirements-00.txt comments are encouraged cheers, James ******************* The answer is "42", what's the question? _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 2 16: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 QAA12469 for ; Wed, 2 Jul 2003 16: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 19XoFv-0002IR-U1 for sipping-archive@odin.ietf.org; Wed, 02 Jul 2003 16:31:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62KV7Hk008824 for sipping-archive@odin.ietf.org; Wed, 2 Jul 2003 16:31:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoFv-0002IF-RA for sipping-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 16:31: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 QAA12357 for ; Wed, 2 Jul 2003 16:31:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XoFs-0007F3-00 for sipping-web-archive@ietf.org; Wed, 02 Jul 2003 16:31:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XoFr-0007F0-00 for sipping-web-archive@ietf.org; Wed, 02 Jul 2003 16:31:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoFp-0002FG-GG; Wed, 02 Jul 2003 16:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoFg-0002CP-Ky for sipping@optimus.ietf.org; Wed, 02 Jul 2003 16:30:52 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12239; Wed, 2 Jul 2003 16:30:47 -0400 (EDT) Message-Id: <200307022030.QAA12239@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, 02 Jul 2003 16:30:46 -0400 Subject: [Sipping] I-D ACTION:draft-polk-sipping-mlpp-reqs-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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multilevel Precedence and Preemption in the Session Initiation Protocol Author(s) : J. Polk Filename : draft-polk-sipping-mlpp-reqs-01.txt Pages : 17 Date : 2003-7-2 This document proposes considerations and requirements for the extension of the Session Initiation Protocol (SIP) [1] to support Multi-Level Precedence and Preemption (MLPP) functionality originally set forth in [2&3]. This document will be limited in scope to the requirements of the SIP Protocol; MLPP within the IETF, utilizing other IETF Protocols, is left to other documents, therefore is considered out of scope here - although there is a general explanation of how MLPP functions currently within private circuit switched networks to give the necessary operational background for these requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-polk-sipping-mlpp-reqs-01.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-polk-sipping-mlpp-reqs-01.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-polk-sipping-mlpp-reqs-01.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-7-2161234.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-polk-sipping-mlpp-reqs-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-polk-sipping-mlpp-reqs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2161234.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 Jul 2 16:35: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 QAA13687 for ; Wed, 2 Jul 2003 16:35: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 19XoJU-0003FY-0R for sipping-archive@odin.ietf.org; Wed, 02 Jul 2003 16:34:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62KYlKl012491 for sipping-archive@odin.ietf.org; Wed, 2 Jul 2003 16:34:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoJT-0003FO-Tc for sipping-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 16:34:47 -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 QAA13497 for ; Wed, 2 Jul 2003 16:34: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 19XoIn-0002wh-0x; Wed, 02 Jul 2003 16:34:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoId-0002uJ-EI for sipping@optimus.ietf.org; Wed, 02 Jul 2003 16:33:55 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13206; Wed, 2 Jul 2003 16:33:50 -0400 (EDT) Message-Id: <200307022033.QAA13206@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, 02 Jul 2003 16:33:49 -0400 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : Using ENUM for SIP Applications Author(s) : J. Peterson, H. Liu, J. Yu, B. Campbell Filename : draft-ietf-sipping-e164-03.txt Pages : 22 Date : 2003-7-2 Although SIP was one of the primary applications for which ENUM was created, there is nevertheless a need to define procedures for integrating ENUM with SIP implementations. This document illustrates how the two protocols might work in concert, and clarifies the authoring and processing of ENUM records for SIP applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-e164-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sipping-e164-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sipping-e164-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-2161907.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-e164-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-e164-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2161907.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 Jul 2 18:12: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 SAA24250 for ; Wed, 2 Jul 2003 18:12: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 19Xppi-00017c-Az for sipping-archive@odin.ietf.org; Wed, 02 Jul 2003 18:12:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62MCAld004308 for sipping-archive@odin.ietf.org; Wed, 2 Jul 2003 18: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 19Xppi-00017P-84 for sipping-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 18: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 SAA24143 for ; Wed, 2 Jul 2003 18:12:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xppd-0002nU-00 for sipping-web-archive@ietf.org; Wed, 02 Jul 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 19Xppd-0002nR-00 for sipping-web-archive@ietf.org; Wed, 02 Jul 2003 18:12:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XppZ-00012p-UB; Wed, 02 Jul 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 19Xpon-0000xV-RC for sipping@optimus.ietf.org; Wed, 02 Jul 2003 18:11:13 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23953; Wed, 2 Jul 2003 18:11:07 -0400 (EDT) Message-Id: <200307022211.SAA23953@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, 02 Jul 2003 18:11:06 -0400 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-callerprefs-usecases-00.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : Guidelines for Usage of the Session Initiation Protocol (SIP) Caller Preferences Extension Author(s) : J. Rosenberg, P. Kyzivat Filename : draft-ietf-sipping-callerprefs-usecases-00.txt Pages : 45 Date : 2003-7-2 This document contains guidelines for usage of the Caller Preferences Extension to the Session Initiation Protocol (SIP). It motivates the benefits of caller preferences with specific example applications, provides use cases to show proper operation, provides guidance on the applicability of the registered feature tags, and describes a straightforward implementation of the matching algorithm. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-callerprefs-usecases-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sipping-callerprefs-usecases-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sipping-callerprefs-usecases-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-7-2181924.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-callerprefs-usecases-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-callerprefs-usecases-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2181924.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 Thu Jul 3 00:41: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 AAA14854 for ; Thu, 3 Jul 2003 00:41: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 19Xvu7-00054U-9s for sipping-archive@odin.ietf.org; Thu, 03 Jul 2003 00:41:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h634f7Vl019492 for sipping-archive@odin.ietf.org; Thu, 3 Jul 2003 00:41:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xvu7-00054J-4U for sipping-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 00:41: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 AAA14850 for ; Thu, 3 Jul 2003 00:41:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xvu4-0002cB-00 for sipping-web-archive@ietf.org; Thu, 03 Jul 2003 00:41:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Xvu4-0002c8-00 for sipping-web-archive@ietf.org; Thu, 03 Jul 2003 00:41:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xvu2-00053I-L0; Thu, 03 Jul 2003 00:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xvtt-00052n-G5 for sipping@optimus.ietf.org; Thu, 03 Jul 2003 00:40: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 AAA14837 for ; Thu, 3 Jul 2003 00:40:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xvtq-0002bs-00 for sipping@ietf.org; Thu, 03 Jul 2003 00:40:51 -0400 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 19Xvtp-0002bp-00 for sipping@ietf.org; Thu, 03 Jul 2003 00:40:49 -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 h634ek1R021024; Thu, 3 Jul 2003 13:40:46 +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 h634ej8E029617; Thu, 3 Jul 2003 13:40:45 +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 h634ejeH002604; Thu, 3 Jul 2003 13:40:45 +0900 (JST) Received: from imj.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 NAA00738; Thu, 3 Jul 2003 13:40:44 +0900 (JST) Received: from morita-vaiodtop.lab.ntt.co.jp by imj.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id NAA00669; Thu, 3 Jul 2003 13:40:44 +0900 (JST) Message-Id: <5.1.1.9.2.20030703132201.04aa6708@imj.m.ecl.ntt.co.jp> X-Sender: nm014@imj.m.ecl.ntt.co.jp (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr3 Date: Thu, 03 Jul 2003 13:39:43 +0900 To: "Beck01, Wolfgang" , sipping@ietf.org From: "MORITA, Naotaka" Subject: RE: [Sipping] Priority Promotion Scheme In-Reply-To: <8730C545389BD7118BCE000347055E66334CA7@G9JNV.mgb01.telekom .de> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; 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 Wolfgang, At 17:23 03/06/30 +0200, Beck01, Wolfgang wrote: >Hello Naotaka, > >you wrote > > From: MORITA, Naotaka [mailto:morita.naotaka@lab.ntt.co.jp] > > Sent: Monday, June 30, 2003 1:36 PM > > > 1) The effectiveness of endpoint admission control. > > This is the matter whether the measurement based approach > > is valid or not. >At least it will prevent well behaved but unresponsive flows >from flooding hopelessly congested paths. > > > This issue will be discussed at the TSVWG on Friday. >Thank for this information. > > > > > 2) Interaction to edge routers > > [..] > > Are there any way to control edge routers by SIP proxies? >I don't think proxies should do that. What happens if an >application does not need SIP but wants to implement >endpoint admission control? As I write in the draft, SIP is an example, but the proposed Priority Promotion Scheme(PPS) is quite well suitable for the Interactive Multimedia services typically controlled by SIP, I believe. Even if I limit the scope of PPS with SIP, there are two possibilities how to control edge routers; driven by SIP proxies and driven by the terminals. If I choose the first one, it is possbible now by implementing edge-router control function at SIP proxy using CLI, COPS, SNMP etc. But if I choose the second one, we have to really create a new protocol such as RSVP and wait for being implemented in routers. Naotaka >-- >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 ---------------------------------- Naotaka MORITA, Senior Research Engineer, Supervisor Network Service Systems Laboratories Information Sharing Laboratory Group NTT 3-9-11, Midori-Cho, Musashino-Shi, Tokyo 180-8585 JAPAN Tel. +81-422-59-7464, ISDN-Fax +81-422-60-4012 E-mail: morita.naotaka@lab.ntt.co.jp MSN messenger: moritanaotaka@hotmail.com NTT home page: http://www.ntt.co.jp/about/e/index.html _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 3 02:19: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 CAA29517 for ; Thu, 3 Jul 2003 02:19: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 19XxQx-0000cn-CN for sipping-archive@odin.ietf.org; Thu, 03 Jul 2003 02:19:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h636J7Pk002400 for sipping-archive@odin.ietf.org; Thu, 3 Jul 2003 02:19:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XxQx-0000cc-6L for sipping-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 02:19: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 CAA29459 for ; Thu, 3 Jul 2003 02:19:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XxQt-0003XW-00 for sipping-web-archive@ietf.org; Thu, 03 Jul 2003 02:19:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XxQt-0003XR-00 for sipping-web-archive@ietf.org; Thu, 03 Jul 2003 02:19:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XxQs-0000aW-SL; Thu, 03 Jul 2003 02:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XxQF-0000Z1-Ox for sipping@optimus.ietf.org; Thu, 03 Jul 2003 02:18: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 CAA29345 for ; Thu, 3 Jul 2003 02:18:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XxQC-0003WL-00 for sipping@ietf.org; Thu, 03 Jul 2003 02:18:20 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19XxQB-0003WI-00 for sipping@ietf.org; Thu, 03 Jul 2003 02:18:19 -0400 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h636IJGJ021897; Thu, 3 Jul 2003 08:18:19 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id NW44VVMP; Thu, 3 Jul 2003 08:18:19 +0200 Received: from lmf.ericsson.se (EFKUM000L5C7100.lmf.ericsson.se [131.160.31.74]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h636IISZ001393; Thu, 3 Jul 2003 09:18:18 +0300 (EET DST) Message-ID: <3F03CAA4.30D4EA81@lmf.ericsson.se> Date: Thu, 03 Jul 2003 09:18:12 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Ejzak, Richard P (Richard)" CC: "'sipping@ietf.org'" Subject: Re: [Sipping] Last Call for early media use cases References: 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 Richard, yes, I got your mail and read thru it before releasing the new version of the draft. Until it appears in the archives, you may want to fetch it from: http://standards.ericsson.net/gonzalo/papers/draft-camarillo-sipping-early-media-02.txt I have summarized the discussions about the parameter so far in a Section. Gonzalo "Ejzak, Richard P (Richard)" wrote: > > Gonzalo, > I sent an early media use case to the sipping exploder about 6 weeks ago, within a week of your email request (below). I have not seen anything on the exploder regarding an updated early media draft. Please provide some status. > > Thanks, > Richard > > -----Original Message----- > From: Gonzalo Camarillo Gonzalez (LMF) > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Wednesday, May 14, 2003 2:13 AM > To: 'sipping@ietf.org' > Cc: Jon Peterson (E-mail); Rohan Mahy (E-mail); Dean Willis (E-mail) > Subject: [Sipping] Last Call for early media use cases > > Folks, > > in the last IETF meeting, we requested early media use cases that show the need of a "media coming" flag. So far, we have not received anything. > > We intend to release a new version of the early media draft in a week or so. So, that is the time you have to send me your use cases. > > Thanks, > > Gonzalo > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP -- 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 Thu Jul 3 10:36: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 KAA13655 for ; Thu, 3 Jul 2003 10:36: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 19Y5Bt-0006OL-7q for sipping-archive@odin.ietf.org; Thu, 03 Jul 2003 10:36:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63Ea5Ox024565 for sipping-archive@odin.ietf.org; Thu, 3 Jul 2003 10:36:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y5Bt-0006O8-3C for sipping-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 10:36: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 KAA13638 for ; Thu, 3 Jul 2003 10:36:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y5Bq-0007Gb-00 for sipping-web-archive@ietf.org; Thu, 03 Jul 2003 10:36:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y5Bq-0007GX-00 for sipping-web-archive@ietf.org; Thu, 03 Jul 2003 10:36:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y5Bp-0006My-4A; Thu, 03 Jul 2003 10: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 19Y5BA-0006MJ-Lz for sipping@optimus.ietf.org; Thu, 03 Jul 2003 10:35: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 KAA13616 for ; Thu, 3 Jul 2003 10:35:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y5B8-0007Fl-00 for sipping@ietf.org; Thu, 03 Jul 2003 10:35:18 -0400 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 19Y5B7-0007FG-00 for sipping@ietf.org; Thu, 03 Jul 2003 10:35:17 -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 h63EcHF24707 for ; Thu, 3 Jul 2003 07:38:17 -0700 Message-Id: <5.2.0.9.2.20030703102917.0338b630@popd.ix.netcom.com> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 03 Jul 2003 10:31:02 -0400 To: sipping@ietf.org From: Richard Shockey Subject: Fwd: RE: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt 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: , DISCLAIMER: I was asked to cross this posting from the ENUM WG list here.... >From: Stastny Richard >To: Richard Shockey , enum@ietf.org >Subject: RE: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t > xt >Date: Thu, 3 Jul 2003 06:46:58 -0400 >X-Mailer: Internet Mail Service (5.5.2653.19) > > >Hi all, > >I have some comments and also some serious problems with this draft. > >General comment: > >It may be a dogma in the religion of SIP, but SIP is not the center of >the world ;-) > >General comment: what kind of RFC this will be? > >The good news first: it is nice to hear that "the most widespread >application for >SIP today is voice", or "the most common application in SIP is >telephony" and >that "in most cases, these are request for a telephone session (voice >communication)" > >Comment: > >I am getting a bit tired to be lectured permanently without asking for >it that there is two >types of SIP URIs (if this is such a problem, then why not put a >parameter or create >a sipL: URI) and no contact addresses should appear in ENUM. As far as I >know from >praxis, nobody ever tried to do this. > > "SIP URIs in ENUM do not convey capability information. SIP has > its own methods for negotiating capability information between > user agents (see SDP [13], the use of Require/Supported to > negotiate extensions in RFC3261, and callee capabilities [11]); > providing more limited capability information within ENUM is at > best redundant and at worst potentially misleading to SIP's > negotiation system. Also, addresses-of-record do not have > capabilities (only devices registered under an address-of-record > have actual capabilities), and putting contact addresses in ENUM > is not recommended." > >Amen, btw, a tel URI is also an address-of-record (better: a name) and >does not >convey any cabability information. On the other hand, if an "author" >want to put capability >information in ENUM, it is his problem > >Comment: >"Only one SIP URI appears in an ENUM record set ..." >This is up to the ENUM subscriber, is it necessary for them to read this >document? >See also section 5. Authoring of NAPTR records > >Comment: 5.1 >"It is strongly RECOMMENDED that authors of NAPTR records use the >'E2U+sip' >service field whenever the regexp contains a SIP address-of-record URI." > >Are we doing commercials in IETF drafts?. If another enumservice with >sip URI >is registered with IANA the "authors" may use, if not, not. > >Major problem: 5.2 >5.2 Flags in NAPTR RR > >"Authors of NAPTR records MUST use the terminal "u" flag when >'E2U+sip' is specified as a Service field." > >Why?, and if this is so, it must go into the draft-ietf-enum-sip IANA >registration. > >Major problem: 5.3 >"Authors of > records intended to be used for SIP applications SHOULD always use a > greedy regexp; no use-cases have been identified today in which a > different antecedent is necessary." > >I strongly object this. >First, the use of regular expessions is a feature in ENUM and DDDS, >second, there are use cases (e.g. in wildcards) and >third, if there is no-use cases, why is are regular expression there in >the first place? > >Comment: 5.4 >"NAPTR records that > are intended to be used for session initiation (including SIP > telephony) SHOULD use a SIP URI." > >"It is RECOMMENDED that authors of ENUM records should always use the > SIP or SIPS URI scheme when the service field is 'E2U+sip', and the > URIs in question MUST be addresses-of-record, not contact addresses." > >Another commercial? > >Comment: 5.4 > >'E2IPv4+sip' > >What is this? > >Comment: 5.6 > >"$ORIGIN 0.0.6.2.3.3.5.2.0.2.1.e164.arpa. > IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:user@example.com!" >. > IN NAPTR 100 20 "u" "E2U+mailto" "!^.*$!mailto:info@example.com!" >." > >? >I am glad that at least "email:mailto" is allowed beside SIP ;-) No spam >problem? > >Comment: 5. > >"These guidelines do not by any means exhaustively describe the NAPTR > algorithm or the processing of NAPTR records; implementers should > familiarize themselves with the DDDS algorithm and ENUM before > reviewing this section." > >MM will like to hear this one ;-) > >Richard > > > -----Original Message----- > > From: Richard Shockey [mailto:rich.shockey@neustar.biz] > > Sent: Wednesday, July 02, 2003 10:39 PM > > To: enum@ietf.org > > Subject: [Enum] Fwd: [Sipping] I-D > > ACTION:draft-ietf-sipping-e164-03.txt > > > > > > > > FYI > > > > >To: IETF-Announce: ; > > >Cc: sipping@ietf.org > > >From: Internet-Drafts@ietf.org > > >Reply-to: Internet-Drafts@ietf.org > > >Date: Wed, 02 Jul 2003 16:33:49 -0400 > > >Subject: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.txt > > >Sender: 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: , > > > > > > > > > > > >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 : Using ENUM for SIP Applications > > > Author(s) : J. Peterson, H. Liu, J. Yu, B. Campbell > > > Filename : draft-ietf-sipping-e164-03.txt > > > Pages : 22 > > > Date : 2003-7-2 > > > > > >Although SIP was one of the primary applications for which ENUM was > > >created, there is nevertheless a need to define procedures for > > >integrating ENUM with SIP implementations. This document > > illustrates > > >how the two protocols might work in concert, and clarifies the > > >authoring and processing of ENUM records for SIP applications. > > > > > >A URL for this Internet-Draft is: > > >http://www.ietf.org/internet-drafts/draft-ietf-sipping-e164-03.txt > > > > > >To remove yourself from the IETF Announcement list, send a > > message to > > >ietf-announce-request with the word unsubscribe in the body of the > > >message. > > > > > >Internet-Drafts are also available by anonymous FTP. Login with the > > >username "anonymous" and a password of your e-mail address. After > > >logging in, type "cd internet-drafts" and then > > > "get draft-ietf-sipping-e164-03.txt". > > > > > >A list of Internet-Drafts directories can be found in > > >http://www.ietf.org/shadow.html or > > >ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > >Internet-Drafts can also be obtained by e-mail. > > > > > >Send a message to: > > > mailserv@ietf.org. > > >In the body type: > > > "FILE /internet-drafts/draft-ietf-sipping-e164-03.txt". > > > > > >NOTE: The mail server at ietf.org can return the document in > > > MIME-encoded form by using the "mpack" utility. To use this > > > feature, insert the command "ENCODING mime" before > > the "FILE" > > > command. To decode the response(s), you will need > > "munpack" or > > > a MIME-compliant mail reader. Different > > MIME-compliant mail readers > > > exhibit different behavior, especially when dealing with > > > "multipart" MIME messages (i.e. documents which > > have been split > > > up into multiple messages), so check your local > > documentation on > > > how to manipulate these messages. > > > > > > > > >Below is the data which will enable a MIME compliant mail reader > > >implementation to automatically retrieve the ASCII version of the > > >Internet-Draft. > > >Content-Type: text/plain > > >Content-ID: <2003-7-2161907.I-D@ietf.org> > > > > > >ENCODING mime > > >FILE /internet-drafts/draft-ietf-sipping-e164-03.txt > > > > > > > > > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 3 11:30: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 LAA16192 for ; Thu, 3 Jul 2003 11:30: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 19Y62F-0001Df-RB for sipping-archive@odin.ietf.org; Thu, 03 Jul 2003 11:30:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63FUBVs004681 for sipping-archive@odin.ietf.org; Thu, 3 Jul 2003 11:30:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y62F-0001DQ-No for sipping-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 11:30: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 LAA16017 for ; Thu, 3 Jul 2003 11:30:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y62E-0000Eu-00 for sipping-web-archive@ietf.org; Thu, 03 Jul 2003 11:30:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y62E-0000Er-00 for sipping-web-archive@ietf.org; Thu, 03 Jul 2003 11: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 19Y627-00016q-0y; Thu, 03 Jul 2003 11:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y61u-000140-5a for sipping@optimus.ietf.org; Thu, 03 Jul 2003 11:29:50 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15901; Thu, 3 Jul 2003 11:29:47 -0400 (EDT) Message-Id: <200307031529.LAA15901@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 03 Jul 2003 11:29:47 -0400 Subject: [Sipping] I-D ACTION:draft-niemi-sipping-event-throttle-reqs-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. Title : Requirements for Limiting the Rate of Event Notifications Author(s) : A. Niemi Filename : draft-niemi-sipping-event-throttle-reqs-02.txt Pages : 10 Date : 2003-7-3 All event packages are required to specify a maximum rate at which event notifications are generated by a single notifier. Such a limit is provided in order to reduce network congestion. In addition to the fixed limits introduced by specific event packages, further mechanisms for limiting the rate of event notification are also allowed to be defined by event package specifications but none have been specified so far. This memo discusses the requirements for a throttle mechanism that allows a subscriber to further limit the rate of event notification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-niemi-sipping-event-throttle-reqs-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-niemi-sipping-event-throttle-reqs-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-niemi-sipping-event-throttle-reqs-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-7-3111642.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-niemi-sipping-event-throttle-reqs-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-niemi-sipping-event-throttle-reqs-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-3111642.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 Thu Jul 3 11:33: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 LAA17138 for ; Thu, 3 Jul 2003 11:33: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 19Y653-00029d-04 for sipping-archive@odin.ietf.org; Thu, 03 Jul 2003 11:33:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63FX43b008272 for sipping-archive@odin.ietf.org; Thu, 3 Jul 2003 11: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 19Y652-00029I-PP for sipping-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 11:33: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 LAA16993 for ; Thu, 3 Jul 2003 11:33:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y651-0000N7-00 for sipping-web-archive@ietf.org; Thu, 03 Jul 2003 11:33:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y650-0000N3-00 for sipping-web-archive@ietf.org; Thu, 03 Jul 2003 11: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 19Y650-00025x-Qj; Thu, 03 Jul 2003 11: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 19Y64L-0001vO-L1 for sipping@optimus.ietf.org; Thu, 03 Jul 2003 11:32:21 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16746; Thu, 3 Jul 2003 11:32:19 -0400 (EDT) Message-Id: <200307031532.LAA16746@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 03 Jul 2003 11:32:18 -0400 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-dialog-package-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 : An INVITE Inititiated Dialog Event Package for the Session Initiation Protocol (SIP Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-sipping-dialog-package-02.txt Pages : 30 Date : 2003-7-3 This document defines a dialog event package for the SIP Events architecture, along with a data format used in notifications for this package. The dialog package allows users to subscribe to another user, an receive notifications about the changes in state of INVITE initiated dialogs that the user is involved in. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialog-package-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-dialog-package-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-dialog-package-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-7-3112305.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-dialog-package-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-dialog-package-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-3112305.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 Thu Jul 3 11:33: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 LAA17166 for ; Thu, 3 Jul 2003 11: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 19Y654-0002B8-HH for sipping-archive@odin.ietf.org; Thu, 03 Jul 2003 11:33:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63FX62r008370 for sipping-archive@odin.ietf.org; Thu, 3 Jul 2003 11: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 19Y654-0002Av-ED for sipping-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 11: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 LAA17001 for ; Thu, 3 Jul 2003 11:33:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y653-0000NL-00 for sipping-web-archive@ietf.org; Thu, 03 Jul 2003 11:33:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y652-0000NI-00 for sipping-web-archive@ietf.org; Thu, 03 Jul 2003 11: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 19Y652-00028f-3A; Thu, 03 Jul 2003 11: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 19Y64R-0001xo-QC for sipping@optimus.ietf.org; Thu, 03 Jul 2003 11:32:27 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16772; Thu, 3 Jul 2003 11:32:24 -0400 (EDT) Message-Id: <200307031532.LAA16772@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 03 Jul 2003 11:32:24 -0400 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-3pcc-04.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --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 : Best Current Practices for Third Party Call Control in the Session Initiation Protocol Author(s) : J. Rosenberg, J. Peterson, H. Schulzrinne, G. Camarillo Filename : draft-ietf-sipping-3pcc-04.txt Pages : 40 Date : 2003-7-3 Third party call control refers to the ability of one entity to create a call in which communications is actually between other parties. Third party call control is possible using the mechanisms specified within the Session Initiation Protocol (SIP). However, there are several possible approaches, each with different benefits and drawbacks. This document discusses best current practices for the usage of the SIP for third party call control. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-3pcc-04.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-3pcc-04.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-3pcc-04.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-7-3112315.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-3pcc-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-3pcc-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-3112315.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 Thu Jul 3 12:10: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 MAA20580 for ; Thu, 3 Jul 2003 12:10: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 19Y6ex-0005jI-FS for sipping-archive@odin.ietf.org; Thu, 03 Jul 2003 12:10:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63GAB2f022025 for sipping-archive@odin.ietf.org; Thu, 3 Jul 2003 12:10:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y6ex-0005jA-99 for sipping-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 12:10: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 MAA20558 for ; Thu, 3 Jul 2003 12:10:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y6ev-0001Zi-00 for sipping-web-archive@ietf.org; Thu, 03 Jul 2003 12:10:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y6eu-0001Zf-00 for sipping-web-archive@ietf.org; Thu, 03 Jul 2003 12:10:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y6eo-0005iG-56; Thu, 03 Jul 2003 12: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 19Y6e9-0005fp-Px for sipping@optimus.ietf.org; Thu, 03 Jul 2003 12:09: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 MAA20499 for ; Thu, 3 Jul 2003 12:09:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y6e8-0001YU-00 for sipping@ietf.org; Thu, 03 Jul 2003 12:09:20 -0400 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 19Y6e7-0001YR-00 for sipping@ietf.org; Thu, 03 Jul 2003 12:09: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 h63G9G1R012378 for ; Fri, 4 Jul 2003 01:09:16 +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 h63G9F8E029228 for ; Fri, 4 Jul 2003 01:09:15 +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 h63G9FeH017345 for ; Fri, 4 Jul 2003 01:09:15 +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 BAA13514; Fri, 4 Jul 2003 01:09:14 +0900 (JST) Received: from Annika.lab.ntt.co.jp by img.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id BAA17296; Fri, 4 Jul 2003 01:09:13 +0900 (JST) Message-Id: <5.1.1.9.2.20030704005824.04917298@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: Fri, 04 Jul 2003 01:08:52 +0900 To: sipping@ietf.org From: Kumiko Ono Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] End-to-middle security Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 all, I would like to draw your attention to the following draft that I submitted: http://www.ietf.org/internet-drafts/draft-ono-sipping-end2middle-security-00.txt First let me apologize for not separating the requirements and the mechanism in the proposal. This draft describes end-to-middle security using S/MIME, and proposes two following methods: 1) A SIP UA gives a selected proxy a permission to inspect message body while preserving the confidentiality/integrity of these bodies to other proxies. 2) A SIP UA designates and shares a key that will be reused as a content-encryption-key for bidirectional exchanges of S/MIME-secured messages. I think the first method is an alternative approach to some similar use cases to Jonathan's session-policy draft (draft-ietf-sipping- session-policy-req-00). The first method can be a solution for the problem of how a UA expresses its acceptance of a session policy that is required by a Proxy. I would try to clarify what makes my end2middle draft different from that. Jonathan's session-policy draft enables proxies to express their requests to a UA and the UA to express the acceptance of the request. In my draft, it is the UA that requests a certain behavior from a policy in a S/MIME-secured message. I would appreciate comments on it from the SIP community. Thanks, Kumiko ----------------------------------- Kumiko Ono NTT Network Service Systems Labs. Tel +81 422 59 4508/Fax +81 422 60 4012 e-mail ono.kumiko@lab.ntt.co.jp ----------------------------------- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 3 12:19: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 LAA17136 for ; Thu, 3 Jul 2003 11:33: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 19Y652-00028s-6f for sipping-archive@odin.ietf.org; Thu, 03 Jul 2003 11:33:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63FX44m008231 for sipping-archive@odin.ietf.org; Thu, 3 Jul 2003 11: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 19Y652-00028d-22 for sipping-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 11:33: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 LAA16989 for ; Thu, 3 Jul 2003 11:33:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y651-0000N2-00 for sipping-web-archive@ietf.org; Thu, 03 Jul 2003 11:33:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y650-0000My-00 for sipping-web-archive@ietf.org; Thu, 03 Jul 2003 11: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 19Y64z-00024t-Sv; Thu, 03 Jul 2003 11: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 19Y64G-0001v3-M7 for sipping@optimus.ietf.org; Thu, 03 Jul 2003 11:32:16 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16718; Thu, 3 Jul 2003 11:32:14 -0400 (EDT) Message-Id: <200307031532.LAA16718@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 03 Jul 2003 11:32:13 -0400 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-conference-package-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: , --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 : A Session Initiation Protocol (SIP) Event Package for Conference State Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-sipping-conference-package-01.txt Pages : 25 Date : 2003-7-3 This document defines a conference event package for the Session Initiation Protocol (SIP) Events framework, along with a data format used in notifications for this package. The conference package allows users to subscribe to a conference URI. Notifications are sent about changes in the membership of this conference, the state of the dialogs that compose the conference, and general information about the conference. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-conference-package-01.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-conference-package-01.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-conference-package-01.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-7-3112254.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-conference-package-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-conference-package-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-3112254.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 Thu Jul 3 13:41: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 NAA27724 for ; Thu, 3 Jul 2003 13:41: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 19Y84v-0001cq-64 for sipping-archive@odin.ietf.org; Thu, 03 Jul 2003 13:41:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63Hf5HC006238 for sipping-archive@odin.ietf.org; Thu, 3 Jul 2003 13: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 19Y84v-0001cX-2x for sipping-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 13: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 NAA27683 for ; Thu, 3 Jul 2003 13:41:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y84s-0004aS-00 for sipping-web-archive@ietf.org; Thu, 03 Jul 2003 13:41:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y84s-0004aP-00 for sipping-web-archive@ietf.org; Thu, 03 Jul 2003 13:41:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y84r-0001bP-HI; Thu, 03 Jul 2003 13: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 19Y840-0001Zr-BE for sipping@optimus.ietf.org; Thu, 03 Jul 2003 13:40: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 NAA27601 for ; Thu, 3 Jul 2003 13:40:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y83y-0004Z1-00 for sipping@ietf.org; Thu, 03 Jul 2003 13:40:06 -0400 Received: from tomts12.bellnexxia.net ([209.226.175.56] helo=tomts12-srv.bellnexxia.net) by ietf-mx with esmtp (Exim 4.12) id 19Y83x-0004Yr-00 for sipping@ietf.org; Thu, 03 Jul 2003 13:40:05 -0400 Received: from Shulin ([199.243.90.234]) by tomts12-srv.bellnexxia.net (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20030703174001.KPNE27314.tomts12-srv.bellnexxia.net@Shulin> for ; Thu, 3 Jul 2003 13:40:01 -0400 From: "Shu-Lin CHen" To: Date: Thu, 3 Jul 2003 13:40:03 -0400 Message-ID: <000001c3418a$224d7620$390aa8c0@blueslicemtl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C34168.9B3E2010" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [Sipping] High Availability for 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: , This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C34168.9B3E2010 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi: Is there any document related to High Availability of SIP servers (Redirect, Transaction Staful/Stateless Proxy, Registrar)? Normally the objective of high availability is to protect stable calls. Not sure if this is also applicable to SIP servers? Thanks. shu-lin ------=_NextPart_000_0001_01C34168.9B3E2010 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi:
 
Is=20 there any document related to High Availability of SIP servers = (Redirect,=20 Transaction Staful/Stateless Proxy, Registrar)?
Normally the objective of high availability is to protect = stable calls.=20 Not sure if this is also applicable
to SIP=20 servers?
 
Thanks.
 
shu-lin
 
------=_NextPart_000_0001_01C34168.9B3E2010-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 4 01:02: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 BAA04011 for ; Fri, 4 Jul 2003 01:02: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 19YIi0-0001ol-Kh for sipping-archive@odin.ietf.org; Fri, 04 Jul 2003 01:02:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h64528Sk006983 for sipping-archive@odin.ietf.org; Fri, 4 Jul 2003 01:02:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YIi0-0001oY-HL for sipping-web-archive@optimus.ietf.org; Fri, 04 Jul 2003 01:02: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 BAA04008 for ; Fri, 4 Jul 2003 01:02:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YIhx-00025h-00 for sipping-web-archive@ietf.org; Fri, 04 Jul 2003 01:02:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YIhx-00025e-00 for sipping-web-archive@ietf.org; Fri, 04 Jul 2003 01:02:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YIht-0001nI-6U; Fri, 04 Jul 2003 01:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YIh0-0001mf-QQ for sipping@optimus.ietf.org; Fri, 04 Jul 2003 01:01: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 BAA03979 for ; Fri, 4 Jul 2003 01:01:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YIgx-00024i-00 for sipping@ietf.org; Fri, 04 Jul 2003 01:01:03 -0400 Received: from [206.176.144.210] (helo=kevlar.softarmor.com) by ietf-mx with esmtp (Exim 4.12) id 19YIgw-00024T-00 for sipping@ietf.org; Fri, 04 Jul 2003 01:01:02 -0400 Received: from localhost (kevlar.softarmor.com [127.0.0.1]) by kevlar.softarmor.com (8.12.8/8.12.8) with ESMTP id h6450IT1014551; Fri, 4 Jul 2003 00:00:19 -0500 From: Dean Willis To: sipping@ietf.org Cc: rohan@cisco.com Content-Type: text/plain Message-Id: <1057294818.14417.14.camel@kevlar.softarmor.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 04 Jul 2003 00:00:18 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] SIPPING Initial Agenda Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The initial SIPPING agenda, prepared by Rohan, follows. A pretty hyperlinked version is available at: http://www.softarmor.com/sipping/meets/ietf57/agenda.html Since Rohan is going offline until the meeting starts (wouldn't that be cool?), please send any issues to me and I'll do what I can. Rohan thinks that there will be new versions of a couple of these drafts popping out in the archive, so I'll try and get the links updated next week. Initial Agenda, SIPPING, IETF 57 Monday, July 14, 2003, 1930-2200 Hall F1 1930 Agenda Bash Chairs 1935 Status of Work Chairs With RFC editor draft-ietf-sipping-basic-call-flows draft-ietf-sipping-pstn-call-flows draft-ietf-sipping-overlap IESG/AD Reviews draft-ietf-sipping-3pcc draft-ietf-sipping-aaa-req draft-ietf-sipping-mwi draft-ietf-sipping-3gpp-r5-requirements WGLCs draft-ietf-sipping-e164 draft-ietf-sipping-dialog-package (discussed separately) draft-ietf-sipping-qsig2sip (discussed separately) Short Status of other WG docs draft-ietf-sipping-service-examples draft-ietf-sipping-cc-transfer draft-ietf-sipping-cc-framework draft-ietf-sipping-realtimefax draft-ietf-sipping-torture-tests draft-ietf-sipping-req-history 1955 SIP to QSIG Mapping Open Issues draft-ietf-sipping-qsig2sip 2005 Dialog Package Open Issues Jonathan Rosenberg draft-ietf-sipping-dialog-package 2020 Discussion of Configuration Issues draft-ietf-sipping-config-framework draft-ietf-sipping-ua-prof-framewk-reqs draft-ietf-simple-xcap-package 2055 Discussion of Session Policy and Middle Box Issues draft-ietf-sipping-session-policy-req-00.txt draft-rosenberg-sipping-lease-00.txt draft-rosenberg-sipping-ice-00.txt draft-audet-sipping-add-realm-00.txt 2125 Open Issues from Conferencing Design Team Orit Levin draft-ietf-sipping-conferencing-requirements draft-ietf-sipping-conferencing-framework draft-ietf-sipping-cc-conferencing draft-ietf-sipping-conference-package 2140 Open Issues from Transcoding/Deaf Design Team Gonzalo Camarillo [draft-camarillo-sip-deaf-02.txt] 2150 Report from Energency Calling Design Team Gonzalo Camarillo 2155 Padding Thursday, July 17, 2003, 1300-1500 Hall F1 1300 Open Issues from Application Interaction Design Team Jonathan Rosenberg draft-rosenberg-sipping-app-interaction-framework-00 draft-jennings-sip-app-info-01 [draft-burger-sipping-kpml-02 1320 Discussion of Media-related Issues draft-camarillo-sipping-early-media-02.txt draft-mahy-sipping-tones-00.txt draft-burger-sipping-netann-06 1350 Discussion of Event Filtering and Throttling Aki Niemi draft-niemi-sipping-event-throttle-reqs-01.txt 1400 Discussion of DPNSS to SIP interworking Ranjith Mukundan draft-mukundan-sipping-dpnss-02.txt 1410 Discussion of End-to-middle Security Kumiko Ono draft-ono-sipping-end2middle-security-00.txt 1435 Discussion on Phone-related Status and Presence Jonathan Rosenberg draft-rosenberg-peterson-simple-pidf-phone 1450 Discussion of Diagnostics in SIP Alan Johnston draft-johnston-sipping-rtcp-summary-00.txt _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 4 02: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 CAA16532 for ; Fri, 4 Jul 2003 02: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 19YJnj-0006ug-6R for sipping-archive@odin.ietf.org; Fri, 04 Jul 2003 02:12:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h646C7Lm026568 for sipping-archive@odin.ietf.org; Fri, 4 Jul 2003 02:12:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YJni-0006uN-O3 for sipping-web-archive@optimus.ietf.org; Fri, 04 Jul 2003 02:12: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 CAA16475 for ; Fri, 4 Jul 2003 02:12:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YJnf-0002Rf-00 for sipping-web-archive@ietf.org; Fri, 04 Jul 2003 02:12:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YJne-0002Rc-00 for sipping-web-archive@ietf.org; Fri, 04 Jul 2003 02:12:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YJne-0006tQ-3k; Fri, 04 Jul 2003 02:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YJnD-0006pQ-HV for sipping@optimus.ietf.org; Fri, 04 Jul 2003 02:11: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 CAA16417 for ; Fri, 4 Jul 2003 02:11:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YJnA-0002RG-00 for sipping@ietf.org; Fri, 04 Jul 2003 02:11:32 -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 19YJn9-0002RD-00 for sipping@ietf.org; Fri, 04 Jul 2003 02:11:31 -0400 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 h646B0Qr022089 for ; Thu, 3 Jul 2003 23:11:00 -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.3-GR) with ESMTP id AIU62540; Thu, 3 Jul 2003 23:02:41 -0700 (PDT) Date: Thu, 3 Jul 2003 23:12:34 -0700 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Rohan Mahy To: "'sipping@ietf.org'" Content-Transfer-Encoding: 7bit Message-Id: <80CFA10C-ADE6-11D7-9589-0003938AF740@cisco.com> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Sipping] SIP conferencing and XCON Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 Everyone, I wanted to inform all of you that the SIPPING conferencing design team has generated a number of contributions to the XCON BOF (tightly-coupled conferencing). For more information, so the XCON agenda: http://www.ietf.org/ietf/03jul/xcon.txt 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 Fri Jul 4 07:14: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 HAA23418 for ; Fri, 4 Jul 2003 07:14: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 19YOVy-0002mv-HU for sipping-archive@odin.ietf.org; Fri, 04 Jul 2003 07:14:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h64BE6p4010713 for sipping-archive@odin.ietf.org; Fri, 4 Jul 2003 07: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 19YOVy-0002mh-EB for sipping-web-archive@optimus.ietf.org; Fri, 04 Jul 2003 07: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 HAA23398 for ; Fri, 4 Jul 2003 07:14:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YOVx-0004IO-00 for sipping-web-archive@ietf.org; Fri, 04 Jul 2003 07:14:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YOVx-0004IL-00 for sipping-web-archive@ietf.org; Fri, 04 Jul 2003 07:14:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YOVt-0002lk-IP; Fri, 04 Jul 2003 07: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 19YOUy-0002ac-Ve for sipping@optimus.ietf.org; Fri, 04 Jul 2003 07:13: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 HAA23379 for ; Fri, 4 Jul 2003 07:13:04 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YOUy-0004Hk-00 for sipping@ietf.org; Fri, 04 Jul 2003 07:13:04 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19YOUx-0004Hh-00 for sipping@ietf.org; Fri, 04 Jul 2003 07:13:03 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h64BD2a07353 for ; Fri, 4 Jul 2003 14:13:02 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 4 Jul 2003 14:13:02 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 4 Jul 2003 14:13:01 +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 Date: Fri, 4 Jul 2003 14:13:01 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796EC4@esebe019.ntc.nokia.com> Thread-Topic: Comment on I-D ACTION:draft-niemi-sipping-event-throttle-reqs-02.tx Thread-Index: AcNCHTqzu3u+Yqi4RtedKKgy11SOgQ== To: Cc: X-OriginalArrivalTime: 04 Jul 2003 11:13:01.0389 (UTC) FILETIME=[3B5C37D0:01C3421D] Content-Transfer-Encoding: quoted-printable Subject: [Sipping] Comment on I-D ACTION:draft-niemi-sipping-event-throttle-reqs-02.tx Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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, I have a comment on the model section rather than the requirements :) I was ok with the model until I looked at the example. I don't like the = idea of delayed notification, especially in the case of presence. I much = prefer to receive up to date limited info (lossy model) rather than = stale info. I.e. buffer size of 1. Others might have a different preference depending on the type of event. = Example is geoloc; I might want to see the towns/cities you are driving = through while crossing Europe by car. Delayed notifications in this case = are ok. Example where the lossy model is favourable is message waiting = indication where I don't want to receive notification every time I have = a new message in my inbox, but I want to receive notifications on hourly = basis telling me how many messaging I now have waiting.=20 Perhaps this is a subscriber option and a requirement is needed to = address it: A subscribe SHOULD? be able to choose the model associated = with the subscription. Unrelated: Have you considered a model where the trigger is just the timer and not = timer + whatever is in the buffer. Continuing your trip through Europe: = I want to receive notifications of your geoloc every hour regardless of = your position (if it has changed or not). So I set the throttle to one = hour and notifications are sent every hour, even if the buffer is empty. Regards, Hisham _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 4 08:41: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 IAA24869 for ; Fri, 4 Jul 2003 08:41: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 19YPsF-0008EF-08 for sipping-archive@odin.ietf.org; Fri, 04 Jul 2003 08:41:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h64CfAPH031632 for sipping-archive@odin.ietf.org; Fri, 4 Jul 2003 08:41:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YPsE-0008E7-S0 for sipping-web-archive@optimus.ietf.org; Fri, 04 Jul 2003 08:41: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 IAA24854 for ; Fri, 4 Jul 2003 08:41:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YPsD-0004rX-00 for sipping-web-archive@ietf.org; Fri, 04 Jul 2003 08:41:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YPsB-0004rR-00 for sipping-web-archive@ietf.org; Fri, 04 Jul 2003 08:41:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YPs8-0008Ae-C3; Fri, 04 Jul 2003 08:41:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y14F-0006hN-5d for sipping@optimus.ietf.org; Thu, 03 Jul 2003 06:11: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 GAA04814 for ; Thu, 3 Jul 2003 06:11:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y14B-0004uY-00 for sipping@ietf.org; Thu, 03 Jul 2003 06:11:51 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19Y14A-0004uV-00 for sipping@ietf.org; Thu, 03 Jul 2003 06:11:50 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h63ABnIi029914; Thu, 3 Jul 2003 12:11:49 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 3 Jul 2003 12:12:18 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Shu-Lin CHen'" , sipping@ietf.org Subject: RE: [Sipping] question re INIVITE client transaction on page 127 of RFC3261 Date: Thu, 3 Jul 2003 12:11:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3414B.640F7160" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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_01C3414B.640F7160 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Hi, =20 Please have a look at http://bugs.sipit.net/sipwg/show_bug.cgi?id=3D706 = =20 =20 ...and the "Stuck in proceeding after CANCEL" thread. =20 Regards, =20 Christer Holmberg Ericsson Finland =20 -----Original Message----- From: Shu-Lin CHen [mailto:shulin@blueslice.com] Sent: 2. hein=E4kuuta 2003 18:51 To: sipping@ietf.org Subject: [Sipping] question re INIVITE client transaction on page 127 = of RFC3261 Hi: =20 Re Figure 5 on page 127 of RFC3261, what will happen if final response = is never received when transaction is in Proceeding state? =20 Thanks. =20 shu-lin =20 ------_=_NextPart_001_01C3414B.640F7160 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
 
Hi,
 
Please=20 have a look at http://bugs.s= ipit.net/sipwg/show_bug.cgi?id=3D706
 
...and=20 the "Stuck in proceeding after CANCEL" thread.
 
Regards,
 
Christer Holmberg
Ericsson Finland
 
-----Original Message-----
From: Shu-Lin CHen=20 [mailto:shulin@blueslice.com]
Sent: 2. hein=E4kuuta 2003=20 18:51
To: sipping@ietf.org
Subject: [Sipping] = question re=20 INIVITE client transaction on page 127 of = RFC3261

Hi:
 
Re Figure 5 on=20 page 127 of RFC3261, what will happen if final response is never = received when=20 transaction is in
Proceeding=20 state?
 
Thanks.
 
shu-lin
 
------_=_NextPart_001_01C3414B.640F7160-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 4 08:41: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 IAA24884 for ; Fri, 4 Jul 2003 08:41: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 19YPsF-0008Eb-KB for sipping-archive@odin.ietf.org; Fri, 04 Jul 2003 08:41:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h64CfB50031648 for sipping-archive@odin.ietf.org; Fri, 4 Jul 2003 08:41:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YPsF-0008EN-H7 for sipping-web-archive@optimus.ietf.org; Fri, 04 Jul 2003 08:41: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 IAA24851 for ; Fri, 4 Jul 2003 08:41:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YPsD-0004rW-00 for sipping-web-archive@ietf.org; Fri, 04 Jul 2003 08:41:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YPsB-0004rN-00 for sipping-web-archive@ietf.org; Fri, 04 Jul 2003 08:41:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YPs5-00089B-W1; Fri, 04 Jul 2003 08: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 19XQCK-0001OP-Aq for sipping@optimus.ietf.org; Tue, 01 Jul 2003 14:50: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 OAA10639 for ; Tue, 1 Jul 2003 14:49:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XQCF-00070G-00 for sipping@ietf.org; Tue, 01 Jul 2003 14:49:43 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19XQCE-000706-00 for sipping@ietf.org; Tue, 01 Jul 2003 14:49:42 -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 h61ImqIn025071; Tue, 1 Jul 2003 11:48:53 -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.3-GR) with ESMTP id AIR94566; Tue, 1 Jul 2003 11:40:55 -0700 (PDT) Date: Tue, 1 Jul 2003 11:50:18 -0700 Subject: Re: [Sipping] proposed enhancement to dialog package Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Paul Kyzivat , Michael Hammer , seancolson@yahoo.com, "'Rosen, Brian'" , hisham.khartabil@nokia.com, jason@azatel.com, drage@lucent.com, alan.johnston@wcom.com, sipping@ietf.org To: Jonathan Rosenberg From: Rohan Mahy In-Reply-To: <3F014176.3000401@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 Tuesday, July 1, 2003, at 01:08 AM, Jonathan Rosenberg wrote: > > > Paul Kyzivat wrote: > > >> As this relates to Rohan's proposal, I think what I have described as >> attending to media is similar to what Rohan is calling participation. >> The primary difference seems to be that Rohan is applying this >> property to the dialog as a whole rather than to a media stream. >> It is convenient to have this as a property of the dialog. The >> question is whether the typical UA knows this. For UAs that support >> only a single medium the distinction is irrelevant. There isn't >> nearly as much experience with multimedia UAs, and I suspect there >> hasn't been time for management of such devices to reach defacto >> standardization. > > I dont think this is a property of the dialog at all. Keith commented > on this previously within this thread, and I agree. This notion of > "participation" is a very high level application issue, and it can > manifest itself in SIP-terms in many ways - suspended media streams, > media on hold, etc. For some applications, the notion of participation > may, in fact, be applicable to a media stream at a time, and for > others, its all of them. no, the notion of participation is not per-stream. there is no precedent for participation to be a stream thing. There may be additional *attributes* of your participation which are per-stream, but the participation itself is not per-stream. > There are certainly other "states" of a telephony-like application > residing on SIP. "Muted" has also been discussed in this thread. > Generally, muted is a purely local operation, and doesnt manifest > itself within SIP signaling in any way. > > As such, I dont think the dialog package is the right place for this > information. Its much closer to presence, in fact. Indeed, Jon and I > recently submitted an I-D that proposed a bunch of PIDF extensions to > reflect status of phones, including application-level type of state: > > http://www.ietf.org/internet-drafts/draft-rosenberg-peterson-simple- > pidf-phone-00.txt i don't buy it. thanks, -rohan > My gut feeling is that this might be a more appropriate place for > these states. > > > -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 Jul 4 08:41:47 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 IAA24897 for ; Fri, 4 Jul 2003 08:41: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 19YPsJ-0008FA-HS for sipping-archive@odin.ietf.org; Fri, 04 Jul 2003 08:41:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h64CfFv2031676 for sipping-archive@odin.ietf.org; Fri, 4 Jul 2003 08:41:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YPsJ-0008En-C8 for sipping-web-archive@optimus.ietf.org; Fri, 04 Jul 2003 08: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 IAA24847 for ; Fri, 4 Jul 2003 08:41:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YPsC-0004rM-00 for sipping-web-archive@ietf.org; Fri, 04 Jul 2003 08:41:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YPsB-0004rF-00 for sipping-web-archive@ietf.org; Fri, 04 Jul 2003 08:41:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YPs6-00089p-Q9; Fri, 04 Jul 2003 08:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XS4g-0007Dl-SN for sipping@optimus.ietf.org; Tue, 01 Jul 2003 16:50: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 QAA15918 for ; Tue, 1 Jul 2003 16:49:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XS4e-0000ah-00 for sipping@ietf.org; Tue, 01 Jul 2003 16:50:00 -0400 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by ietf-mx with esmtp (Exim 4.12) id 19XS4d-0000aX-00 for sipping@ietf.org; Tue, 01 Jul 2003 16:49:59 -0400 Received: from dgismtp06.wcomnet.com ([166.38.58.89]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HHD00CAV5S4WE@firewall.wcom.com> for sipping@ietf.org; Tue, 01 Jul 2003 20:48:05 +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 <0HHD004015QEDA@dgismtp06.wcomnet.com>; Tue, 01 Jul 2003 20:48:04 +0000 (GMT) Received: from hsinnreich2 ([166.50.131.18]) by dgismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HHD002D75RQTJ@dgismtp06.wcomnet.com>; Tue, 01 Jul 2003 20:47:52 +0000 (GMT) Date: Tue, 01 Jul 2003 15:47:50 -0500 From: Henry Sinnreich Subject: RE: [Sipping] Rationale for the support of RFC2793/T.140 in SIP Telephone In-reply-to: <007301c33f9d$141bfde0$cc36c2cb@bazza> To: "'Barry Dingle'" , "'SIPPING'" Cc: Henry.Sinnreich@mci.com, hwildfeu@cisco.com, mgarakan@cisco.com, oran@cisco.com, rohan@cisco.com, marcelo@envilogg.se, jorgen.bjorkner@hotsip.com, andreas.piirimets@omnitor.se, Erik.Zetterstrom@omnitor.se, gunnar.hellstrom@omnitor.se, Guido.Gybels@rnid.org.uk, james.hamlin@rnid.org.uk, mike.spanner@rnid.org.uk, gv@trace.wisc.edu, trefor@trefor.plus.com, "'A vWijk'" , "'Rajesh Kumar'" Message-id: <000e01c34012$0a4ccc20$616932a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 Barry, I like your summary, but have to take exception in the IETF context to >Next Generation Networks (NGNs) The NGN is the Internet and it is not "next generation", but here today, for 'our generation" and to stay. Unless you want to define it technically NGN as IP v.6 ;-) Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of Barry Dingle > Sent: Tuesday, July 01, 2003 1:51 AM > To: SIPPING > Cc: Henry.Sinnreich@mci.com; hwildfeu@cisco.com; > mgarakan@cisco.com; oran@cisco.com; rohan@cisco.com; > marcelo@envilogg.se; jorgen.bjorkner@hotsip.com; > andreas.piirimets@omnitor.se; Erik.Zetterstrom@omnitor.se; > gunnar.hellstrom@omnitor.se; Guido.Gybels@rnid.org.uk; > james.hamlin@rnid.org.uk; mike.spanner@rnid.org.uk; > gv@trace.wisc.edu; trefor@trefor.plus.com; A vWijk; Rajesh > Kumar; Barry Dingle > Subject: [Sipping] Rationale for the support of RFC2793/T.140 > in SIP Telephone > > > > Hi all, > > Following discussions on a side email group, I have tried to > provide some background information about some of the > thinking behind the RFC2793/T.140 issue that will be raised > at SIPPING in Vienna. > > /Barry DINGLE > Project Manager - ACIF Any-to-Any Text Connectivity Options > WG Telecommunications Consultant Fellow of the University of Melbourne > > barry.dingle@bigfoot.com.au > > Mob: +61 41 911 7578 > Fixed: +61 3 9725 3937 > > > ================================== > > > Purpose > -------------- > Enable real-time text communication services on SIP > Telephones for general purpose use and for use by people who > are deaf or have hearing and/or speech impairments. > > Background > ----------------- > Real-time Text communication services are very useful for > people with hearing and/or speech impairments as well as for > any person who wants to converse in text mode eg. to transfer > precise details (eg. money amounts, email addresses). > > About 5% of the population has hearing problems [3GPP]. The > population is aging so hearing related communication problems > are likely to increase. In some countries, there are > Regulatory requirements for 'mainstream' telephone networks > to support "equivalent" service for people with disabilities > for accessing emergency services - usually implemented > real-time Text services. > > Real-time text communication is a service provided on the > PSTN and now on mobile/cellular telephone networks using TTYs > and Textphones to enable people who are deaf or have hearing > or speech impairment to communicate. > > Some countries are actively considering how to remove the TTY > - over time - because of the problems that are experienced by > the networks and the restricted terminal options that a > 'special' device causes. > > One of the main problems that has restricted the provision > of real-time Text service in the PSTN to the hearing and > speech impaired has been the use of different Textphone > specifications making development of new services very > difficult. The ITU-T V.18 specification defines both > interworking between different Textphone devices and a new, > multimedia aligned Textphone specification. That new > Textphone specification is based on the T.140 presentation protocol. > > T.140 is a very simple protocol that is defined for use by > Text services in Video telephony/conferencing (ISDN, H.323, > SIP based). (The details of T.140 are contained in 5 ITU-T > pages!) T.140 specifies the use of UTF-8 transmission. > > << T.140 is an integral part of the 'Total Conversation' > concept used by ITU-T , ETSI, IETF and 3GPP - incorporating > text, speech and video. (See F.703, WISDOM project, RFC3351 > and 3GPP 22.226.) >> > > RFC2793 defines the use of T.140 with RTP to support text > services. It also has an optional redundancy capability to > further improve the text transfer reliability. > > SIP is a session initiation protocol that facilitates the > establishment of multimedia communication between two > entities, including voice, video, and text communication. SIP > allows true real-time text communication services to be > supported consistently across many technologies. > > Next Generation Networks (NGNs) is actively looking at > providing equivalent PSTN/ISDN services over IP technology. > The requirements of PSTN will be carried into the IP > environment particularly where Regulations are service based > and not technology based. > > Messaging is a related, similar service. The non-real-time > nature can be a problem in some communication situations - > including regulatory. Interworking between real-time text > services and Messaging services is desirable. A consistent > approach to real-time text services will assist the interworking. > > > Rationale > ------------- > 1. There is growing interest in providing for text > communication services as 'mainstream' instead of an 'added > extra' - to benefit users, suppliers and carriers. > > 2. The work towards Next Generation Networks is looking at > replacing PSTN networks (over time) with IP-based networks. > The key to the success of such activity is the provision of > at least equivalent services. Migration of telephone calls > from PSTN to IP-based networks will be facilitated if the > legacy services are supported. > > 3. T.140 is very simple and is important in providing a > smooth interface between legacy text services in the > PSTN/ISDN and IP-based real-time text services whilst > minimising gateway functionality. > > 4. SIP should support equivalent TTY service - but not be > forced to ONLY support ancient TTYs and their non-standard > modems over IP. (Comment - assumes that the support of > TTY/Textphone over IP ie. carriage of TTY-type modem tones, > is only be a fallback call case.) > > 5. Support of RFC2793 in SIP terminals would provide an > indication to terminal suppliers, networks, servers, gateways > that support for text services is required. (Any breakdown in > the end-to-end capability will remove the end-to-end service.) > > Recommendation > ------------------------- > > All SIP Telephones MUST support RFC2793 in order that legacy > text services and interworking with TTY/Textphones can be > supported in an IP-friendly manner. > > ======================== > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 Jul 4 08:41:47 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 IAA24898 for ; Fri, 4 Jul 2003 08:41: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 19YPsJ-0008FY-JW for sipping-archive@odin.ietf.org; Fri, 04 Jul 2003 08:41:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h64CfFSW031693 for sipping-archive@odin.ietf.org; Fri, 4 Jul 2003 08:41:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YPsJ-0008Ep-Cr for sipping-web-archive@optimus.ietf.org; Fri, 04 Jul 2003 08: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 IAA24846 for ; Fri, 4 Jul 2003 08:41:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YPsC-0004rQ-00 for sipping-web-archive@ietf.org; Fri, 04 Jul 2003 08:41:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YPsB-0004rJ-00 for sipping-web-archive@ietf.org; Fri, 04 Jul 2003 08:41:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YPs7-0008AE-Id; Fri, 04 Jul 2003 08: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 19XUj5-0004ZQ-8u for sipping@optimus.ietf.org; Tue, 01 Jul 2003 19:39: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 TAA20699 for ; Tue, 1 Jul 2003 19:39:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XUj3-0002Hs-00 for sipping@ietf.org; Tue, 01 Jul 2003 19:39:53 -0400 Received: from bbs.izone.net.au ([202.160.128.31]) by ietf-mx with esmtp (Exim 4.12) id 19XUj1-0002Hm-00 for sipping@ietf.org; Tue, 01 Jul 2003 19:39:52 -0400 Received: from bazza (dialup-148.83.220.203.acc06-dryb-mel.comindico.com.au [203.220.83.148]) by bbs.izone.net.au (8.11.2/8.11.2) with SMTP id h61NDQW10111; Wed, 2 Jul 2003 09:13:26 +1000 Message-ID: <003a01c3402a$3e570400$9453dccb@bazza> From: "Barry Dingle" To: "Henry Sinnreich" , "'SIPPING'" Cc: , , , , , , , , , , , , , , "'A vWijk'" , "'Rajesh Kumar'" , "Barry Dingle" References: <000e01c34012$0a4ccc20$616932a6@hsinnreich2> Subject: Re: [Sipping] Rationale for the support of RFC2793/T.140 in SIP Telephone Date: Wed, 2 Jul 2003 09:40:56 +1000 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 Henry, I agree that the Internet is the next generation network. However the capitalised "Next Generation Networks" (NGN) is a term used by TIA, ATMF, 3GPP, ITU-T, ETSI and many others to refer to the migration of legacy PSTN/ISDN networks to a full service network. Almost everyone agrees that this network will use IP technology with improved QoS and PSTN-similar services so facilitate service migration. SIP is seen by most to be a key protocol in the NGN. Cheers, /Barry DINGLE Project Manager - Any-to-Any Text Connectivity Options WG Telecommunications Consultant Fellow of the University of Melbourne barry.dingle@bigfoot.com.au Mob: 041 911 7578 Fixed: 03 9725 3937 ----- Original Message ----- From: "Henry Sinnreich" To: "'Barry Dingle'" ; "'SIPPING'" Cc: ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; "'A vWijk'" ; "'Rajesh Kumar'" Sent: Wednesday, July 02, 2003 6:47 AM Subject: RE: [Sipping] Rationale for the support of RFC2793/T.140 in SIP Telephone > Barry, I like your summary, but have to take exception in the IETF > context to > > >Next Generation Networks (NGNs) > > The NGN is the Internet and it is not "next generation", but here today, > for 'our generation" and to stay. Unless you want to define it > technically NGN as IP v.6 ;-) > > Henry > > > -----Original Message----- > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > On Behalf Of Barry Dingle > > Sent: Tuesday, July 01, 2003 1:51 AM > > To: SIPPING > > Cc: Henry.Sinnreich@mci.com; hwildfeu@cisco.com; > > mgarakan@cisco.com; oran@cisco.com; rohan@cisco.com; > > marcelo@envilogg.se; jorgen.bjorkner@hotsip.com; > > andreas.piirimets@omnitor.se; Erik.Zetterstrom@omnitor.se; > > gunnar.hellstrom@omnitor.se; Guido.Gybels@rnid.org.uk; > > james.hamlin@rnid.org.uk; mike.spanner@rnid.org.uk; > > gv@trace.wisc.edu; trefor@trefor.plus.com; A vWijk; Rajesh > > Kumar; Barry Dingle > > Subject: [Sipping] Rationale for the support of RFC2793/T.140 > > in SIP Telephone > > > > > > > > Hi all, > > > > Following discussions on a side email group, I have tried to > > provide some background information about some of the > > thinking behind the RFC2793/T.140 issue that will be raised > > at SIPPING in Vienna. > > > > /Barry DINGLE > > Project Manager - ACIF Any-to-Any Text Connectivity Options > > WG Telecommunications Consultant Fellow of the University of Melbourne > > > > barry.dingle@bigfoot.com.au > > > > Mob: +61 41 911 7578 > > Fixed: +61 3 9725 3937 > > > > > > ================================== > > > > > > Purpose > > -------------- > > Enable real-time text communication services on SIP > > Telephones for general purpose use and for use by people who > > are deaf or have hearing and/or speech impairments. > > > > Background > > ----------------- > > Real-time Text communication services are very useful for > > people with hearing and/or speech impairments as well as for > > any person who wants to converse in text mode eg. to transfer > > precise details (eg. money amounts, email addresses). > > > > About 5% of the population has hearing problems [3GPP]. The > > population is aging so hearing related communication problems > > are likely to increase. In some countries, there are > > Regulatory requirements for 'mainstream' telephone networks > > to support "equivalent" service for people with disabilities > > for accessing emergency services - usually implemented > > real-time Text services. > > > > Real-time text communication is a service provided on the > > PSTN and now on mobile/cellular telephone networks using TTYs > > and Textphones to enable people who are deaf or have hearing > > or speech impairment to communicate. > > > > Some countries are actively considering how to remove the TTY > > - over time - because of the problems that are experienced by > > the networks and the restricted terminal options that a > > 'special' device causes. > > > > One of the main problems that has restricted the provision > > of real-time Text service in the PSTN to the hearing and > > speech impaired has been the use of different Textphone > > specifications making development of new services very > > difficult. The ITU-T V.18 specification defines both > > interworking between different Textphone devices and a new, > > multimedia aligned Textphone specification. That new > > Textphone specification is based on the T.140 presentation protocol. > > > > T.140 is a very simple protocol that is defined for use by > > Text services in Video telephony/conferencing (ISDN, H.323, > > SIP based). (The details of T.140 are contained in 5 ITU-T > > pages!) T.140 specifies the use of UTF-8 transmission. > > > > << T.140 is an integral part of the 'Total Conversation' > > concept used by ITU-T , ETSI, IETF and 3GPP - incorporating > > text, speech and video. (See F.703, WISDOM project, RFC3351 > > and 3GPP 22.226.) >> > > > > RFC2793 defines the use of T.140 with RTP to support text > > services. It also has an optional redundancy capability to > > further improve the text transfer reliability. > > > > SIP is a session initiation protocol that facilitates the > > establishment of multimedia communication between two > > entities, including voice, video, and text communication. SIP > > allows true real-time text communication services to be > > supported consistently across many technologies. > > > > Next Generation Networks (NGNs) is actively looking at > > providing equivalent PSTN/ISDN services over IP technology. > > The requirements of PSTN will be carried into the IP > > environment particularly where Regulations are service based > > and not technology based. > > > > Messaging is a related, similar service. The non-real-time > > nature can be a problem in some communication situations - > > including regulatory. Interworking between real-time text > > services and Messaging services is desirable. A consistent > > approach to real-time text services will assist the interworking. > > > > > > Rationale > > ------------- > > 1. There is growing interest in providing for text > > communication services as 'mainstream' instead of an 'added > > extra' - to benefit users, suppliers and carriers. > > > > 2. The work towards Next Generation Networks is looking at > > replacing PSTN networks (over time) with IP-based networks. > > The key to the success of such activity is the provision of > > at least equivalent services. Migration of telephone calls > > from PSTN to IP-based networks will be facilitated if the > > legacy services are supported. > > > > 3. T.140 is very simple and is important in providing a > > smooth interface between legacy text services in the > > PSTN/ISDN and IP-based real-time text services whilst > > minimising gateway functionality. > > > > 4. SIP should support equivalent TTY service - but not be > > forced to ONLY support ancient TTYs and their non-standard > > modems over IP. (Comment - assumes that the support of > > TTY/Textphone over IP ie. carriage of TTY-type modem tones, > > is only be a fallback call case.) > > > > 5. Support of RFC2793 in SIP terminals would provide an > > indication to terminal suppliers, networks, servers, gateways > > that support for text services is required. (Any breakdown in > > the end-to-end capability will remove the end-to-end service.) > > > > Recommendation > > ------------------------- > > > > All SIP Telephones MUST support RFC2793 in order that legacy > > text services and interworking with TTY/Textphones can be > > supported in an IP-friendly manner. > > > > ======================== > > > > > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the 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 Jul 4 09:29: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 IAA24896 for ; Fri, 4 Jul 2003 08:41: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 19YPsJ-0008FN-Ib for sipping-archive@odin.ietf.org; Fri, 04 Jul 2003 08:41:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h64CfFhE031682 for sipping-archive@odin.ietf.org; Fri, 4 Jul 2003 08:41:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YPsJ-0008Eo-Cp for sipping-web-archive@optimus.ietf.org; Fri, 04 Jul 2003 08: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 IAA24842 for ; Fri, 4 Jul 2003 08:41:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YPsC-0004rI-00 for sipping-web-archive@ietf.org; Fri, 04 Jul 2003 08:41:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YPsA-0004rE-00 for sipping-web-archive@ietf.org; Fri, 04 Jul 2003 08:41:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YPs5-000891-6o; Fri, 04 Jul 2003 08: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 19XM7K-0007VX-LX for sipping@optimus.ietf.org; Tue, 01 Jul 2003 10:28: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 KAA02519 for ; Tue, 1 Jul 2003 10:28:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XM7I-00052b-00 for sipping@ietf.org; Tue, 01 Jul 2003 10:28:20 -0400 Received: from marionberry.cc.columbia.edu ([128.59.59.100] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19XM72-00052H-00 for sipping@ietf.org; Tue, 01 Jul 2003 10:28:04 -0400 Received: from cs.columbia.edu (dyn-wireless-246-119.dyn.columbia.edu [160.39.246.119]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h61EQof9027720 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 1 Jul 2003 10:26:51 -0400 (EDT) Message-ID: <3F019A1F.1000400@cs.columbia.edu> Date: Tue, 01 Jul 2003 10:26:39 -0400 From: Henning Schulzrinne 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: Gunnar Hellstrom CC: Henry Sinnreich , "'Sipping@Ietf. Org'" , A.vWijk@viataal.nl, "'Mike Spanner'" , "'James Hamlin'" , paulej@packetizer.com, Erik.Zetterstrom@omnitor.se, andreas.piirimets@omnitor.se, barry.dingle@bigfoot.com.au, "'Guido Gybels'" , gv@trace.wisc.edu, "'Judy Harkins'" , "'Trefor Davies'" , trefor@trefor.plus.com, jorgen.bjorkner@hotsip.com, marcelo@envilogg.se, rkumar@cisco.com Subject: Re: SV: [Sipping] Sipdev, incoming call alert (ring signal equivalents) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit There are pure SIP approaches for external ringing. For example, we have built an X-10-to/from-SIP gateway that is event-triggered. Thus, you can have the ringer device subscribe to call state and ring, flash, or, if you like, start the sprinkler if the phone rings. (The latter mechanism is particularly appropriate when the callee is lounging on their deck.) This requires no additional end device capability, but is clearly a bit more complicated than a wire, but also a lot more flexible, since you are not constrained by distance. (I'm not affiliated with X10.com; there are multiple vendors building equipment to that 'standard.') Gunnar Hellstrom wrote: > Henry, > It is not the external alerting devices themselves that are part of the > spec, it is just the signal to them from the sip device. > > The need is valid in business as well as other environments. > > A question: > There is a sentence in the original sipdev-01 spec about the location of the > call that I do not understand, please explain. > "> The location of a call MAY also be indicated." > >>-Do you really want to propagate the those from the PSTN era? > > Yes, the human need to be alerted on calls persists. > >>-Should this really be specified for all SIP phones? > > Yes, you never know what installation environment they end up in. > >>-What about the SIP business phones? (Related I-D) > > Same need. > >>Henry >> > > >>>-----Original Message----- >>>From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] >>>On Behalf Of Gunnar Hellstrom >>>Sent: Monday, June 23, 2003 11:56 AM >>>To: 'Sipping@Ietf. Org'; A.vWijk@viataal.nl; 'Mike Spanner'; >>>'James Hamlin'; paulej@packetizer.com; >>>Erik.Zetterstrom@omnitor.se; andreas.piirimets@omnitor.se; >>>barry.dingle@bigfoot.com.au; 'Guido Gybels'; >>>gv@trace.wisc.edu; 'Judy Harkins'; 'Trefor Davies'; Henry Sinnreich >>>Cc: trefor@trefor.plus.com; jorgen.bjorkner@hotsip.com; >>>marcelo@envilogg.se; rkumar@cisco.com >>>Subject: [Sipping] Sipdev, incoming call alert (ring signal >>>equivalents) >>> >>> >>>In the discussion about the sipdev spec, >>> >>>http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req >>>-01.txt , I had earlier got positive reactions on a proposal: >>> >>>In 4.9 Ringer Behaviour : add the section below for the >>>purpose of people in the garden, in noisy locations, and for >>>the use by deaf, hearing impaired, deaf-blind people. >>> >>>"SIP Telephony devices MUST provide an external interface to >>>an external alerting system." >>> >>>I cannot find much from that proposal in the new wording, so >>>I repeat the proposal a bit more elaborated: >>> >>>Such external interfaces were normal in the PSTN era. It was >>>easy to buy an extra ringer to place in the garden or in the >>>garage. It was easy to find strong flashing light alerters to >>>place in the factory. >>> >>>Such features must be remembered and available also in the >>>SIP era. In PSTN, the alerters were connected directly to the >>>phone network. Now, it is instead the SIP phone itself that >>>knows if it is called. Therefore it must be specified in the >>>SIP device spec. >>> >>>Currently there are two kinds of electrical interfaces to >>>alerting systems. >>> >>>Both are simple two wire interfaces. >>> >>>One is resistance oriented. It has a high resistance ( 1 >>>Mohm) until the alert is wanted. Then the resistance is low ( >>>below 50 ohm ). It can sustain a voltage of at least 50 V in >>>the inactivated state, and a current of 200 mA in the activated state. >>> >>>The other is voltage oriented. A voltage over the interface >>>triggers the alerting. 12 V direct or alternating is common. >>> >>>Since both usually are available on alerting systems, I >>>suggest that it can be sufficient to provide the resistance >>>oriented one on SIP phones. >>> >>>I would also suggest an extension with a Bluetooth interface. >>>Using the serial port profile, and giving an AT command >>>response "RING" as the basic standard. It might be suitable >>>to have extensions from this basic version into variants >>>where you can specify some characteristics of the alert. >>> >>>So, my proposal is to change from: >>>.....................................Current >>>writing.......................................... >>>4.9 Ringer Behavior >>> >>> The manner in which a user is alerted to an incoming call >>>(visually, >>> audibly or possibly both) MAY be used by the device. This includes >>> the different volumes and MAY point to a file that contains the >>> melody for the ringer alert. >>> >>> Ringer sound files MAY be specified for the following types of >>> incoming calls normal, high priority, internal and external. >>> >>> Different ringer sound files MAY also be associated with different >>> lines. >>> >>> The location of a call MAY also be indicated. This allows using the >>> phone by hearing-impaired or in noisy environments where external >>> speakers are used to render the sound. The location of the call is >>> also useful for paging by speakerphones. >>>:::::::::::::::::::End of current >>>writing::::::::::::::::::::::::::::::::::::::::::::::::::::::: >>> >>>To: >>>::::::::::::::::::New >>>proposal::::::::::::::::::::::::::::::::::::::::::::::: >>>4.9 Ringer Behavior >>> >>> The manner in which a user is alerted to an incoming call >>>(visually, >>> audibly or possibly both) MAY be configured in the device. >>>This includes >>> different volumes and the configuration MAY point to a >>>file that contains a >>> melody for the ringer alert. >>> >>> Ringer sound files MAY be specified for the following types of >>> incoming calls: normal, high priority, internal and external. >>> >>> Different ringer sound files MAY also be associated with different >>> lines. >>> >>> The location of a call MAY also be indicated. This allows using the >>> phone by hearing-impaired or in noisy environments where external >>> speakers are used to render the sound. The location of the call is >>> also useful for paging by speakerphones. >>> >>> SIP Telephony devices MUST provide an external interface to >>> an external alerting system. This allows free positioning >>>and selection of an alerting >>> system that may be visual, audible or tactile or any >>>combination of these modes. >>> An external interface MAY be a two-pole electrical >>>interface offering >>> low resistance (<50 ohm) during ring signals, and high >>>resistance ( > 1 Mohm ) between >>> ring indications. >>> It MAY also be a Bluetooth inteface with the serial >>>profile sending the "RING" >>> message at each ring signal. >>>-------------------------------------End of modified >>>proposal------------------------------ >>> >>> >>>Agree? >>> >>> >>>Gunnar Hellstrom >>>------------------------------------------- >>>Gunnar Hellstrom, Omnitor, Renathvagen 2 >>>SE 121 37 Johanneshov, SWEDEN >>>Tel: +46 8 556 002 03 Mob: +46 708204288 >>>e-mail: gunnar.hellstrom@omnitor.se >>>web: www.omnitor.se >>> >>> >>> >>> >>>_______________________________________________ >>>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>>This list is for NEW development of the 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 Jul 4 14:06: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 OAA03413 for ; Fri, 4 Jul 2003 14:06: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 19YUwn-0001l8-Ii for sipping-archive@odin.ietf.org; Fri, 04 Jul 2003 14:06:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h64I6DAK006758 for sipping-archive@odin.ietf.org; Fri, 4 Jul 2003 14:06:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YUwn-0001kv-EW for sipping-web-archive@optimus.ietf.org; Fri, 04 Jul 2003 14: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 OAA03398 for ; Fri, 4 Jul 2003 14:06:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YUwl-0000bn-00 for sipping-web-archive@ietf.org; Fri, 04 Jul 2003 14:06:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YUwk-0000bj-00 for sipping-web-archive@ietf.org; Fri, 04 Jul 2003 14:06:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YUwc-0001jS-6U; Fri, 04 Jul 2003 14: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 19YUwN-0001j2-FS for sipping@optimus.ietf.org; Fri, 04 Jul 2003 14:05: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 OAA03384; Fri, 4 Jul 2003 14:05:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YUwK-0000bS-00; Fri, 04 Jul 2003 14:05:44 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx with esmtp (Exim 4.12) id 19YUwJ-0000bF-00; Fri, 04 Jul 2003 14:05:44 -0400 Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h64I5BC29454; Fri, 4 Jul 2003 18:05:11 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jul 2003 14:06:08 -0400 Message-ID: <0449D80A0E9B614A83FA9031B07E8D3B257C68@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Stastny Richard'" , "Shockey, Richard" , enum@ietf.org, "'sipping@ietf.org'" Subject: RE: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Date: Fri, 4 Jul 2003 14:05:57 -0400 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: , Since the original mail was cross-posted between SIPPING and ENUM, I'll send this reply to both. > > General comment: > > It may be a dogma in the religion of SIP, but SIP is not the center of > the world ;-) If you sent an ENUM WG item to another WG, I can imagine someone making a similar comment - "why does this document talk about ENUM all the time, this is a WG about xyz". This document is a SIPPING WG item, not an ENUM WG item. For this document, SIP is effectively the center of the world, yes. I imagine other protocols might similarly describe their relationship to ENUM. But also note that our document talks about more than just ENUM - it also discusses what you might do as a SIP UA when you can't use ENUM, and so on. It also happens to more fully specify ENUM behavior, since we hope that the use of ENUM will be the common case for handling telephone numbers in SIP. > > Comment: > > I am getting a bit tired to be lectured permanently without asking for > it that there is two > types of SIP URIs (if this is such a problem, then why not put a > parameter or create > a sipL: URI) and no contact addresses should appear in ENUM. > As far as I know from praxis, nobody ever tried to do this. > > "SIP URIs in ENUM do not convey capability information. SIP has > its own methods for negotiating capability information between > user agents (see SDP [13], the use of Require/Supported to > negotiate extensions in RFC3261, and callee capabilities [11]); > providing more limited capability information within ENUM is at > best redundant and at worst potentially misleading to SIP's > negotiation system. Also, addresses-of-record do not have > capabilities (only devices registered under an address-of-record > have actual capabilities), and putting contact addresses in ENUM > is not recommended." > > Amen, btw, a tel URI is also an address-of-record (better: a name) and does not > convey any cabability information. On the other hand, if an "author" > want to put capability information in ENUM, it is his problem > Well, I'm sure everyone on the ENUM mailing list has had an earful of these arguments before, agreed. But the products of the IETF are intended for more general consumption than just the participants of any particular WG. SIP/PING WG folk, even, might not have followed these ENUM threads. So maybe there are people out there who, unlike yourself, have not yet grasped this point. It was formerly a subject of confusion, and it might become one again. I hope it isn't too annoying to have this sort of text in the document. > Comment: > "Only one SIP URI appears in an ENUM record set ..." > This is up to the ENUM subscriber, is it necessary for them to read this document? > See also section 5. Authoring of NAPTR records > Well, these do aspire to be guidelines for authors of ENUM NAPTR records for SIP, so yes, we do hope to advise ENUM subscribers, or whomever provisions NAPTR records on their behalf. Obviously, subscribers can read/follow our document or not, as they wish. > Comment: 5.1 > "It is strongly RECOMMENDED that authors of NAPTR records use the 'E2U+sip' > service field whenever the regexp contains a SIP address-of-record URI." > > Are we doing commercials in IETF drafts?. If another enumservice with sip URI > is registered with IANA the "authors" may use, if not, not. I don't really look on this instance (or the others you point out in 5.4) as "commercials" - they are showing a RECOMMENDation from the SIPPING WG on how the documents in the ENUM WG can be used to assist SIP services. If there were multiple possible options for SIP enumservices, surely for consistency it makes sense for the SIPPING WG to make a recommendation? This kind of recommendation is made all the time in IETF documents. Authors of NAPTR records can, of course, reject our advice, and new I-Ds can be authored that teach alternative approaches to authoring. And agreed, another ENUM service might become an RFC and accordingly be registered with the IANA. If you want to argue further that the "E2U+sip" enumservice should not be recommended (and note that it is just RECOMMENDED, not REQUIRED, and then only with the caveat that this enumservice is applicable solely to addresses-of-record), I'd suggest pursuing this directly on the SIPPING list. As far as I know, the consensus of the SIPPING mailing list is that the "E2U+sip" enumservice is sufficient. > Major problem: 5.2 > 5.2 Flags in NAPTR RR > > "Authors of NAPTR records MUST use the terminal "u" flag when > 'E2U+sip' is specified as a Service field." > > Why?, and if this is so, it must go into the draft-ietf-enum-sip IANA > registration. > Good catch - although I'm not sure that I read in rfc2916bis's enumservice registration template that one must specify flags that are meaningful for enumservices within enumservice registrations. But still, my text is really left over from course corrections necessary based on ol' RFC2916 - Section 2.4.1 of RFC2916bis does specify that only the "u" flag is currently defined for ENUM. So I agree with you, Section 5.2 doesn't need to be in the SIPPING document - 2916bis covers this adequately. I'll take it out. > Major problem: 5.3 > "Authors of > records intended to be used for SIP applications SHOULD always use a > greedy regexp; no use-cases have been identified today in which a > different antecedent is necessary." > > I strongly object this. > First, the use of regular expessions is a feature in ENUM and DDDS, > second, there are use cases (e.g. in wildcards) and > third, if there is no-use cases, why is are regular > expression there in > the first place? I agree this is an important issue. While I acknowledge that "wildcards" are possible according to the syntax, what's the use-case that motivates wildcards for ENUM? This is a question I've posed many times, and I've never gotten a good answer to. You'll note that the example from RFC2916 that showed a wildcard has not been repeated in rfc2916bis. The old example showed a record set for 6.4.e164.arpa, and the antecedent of the regexp contained "!^+46(.*)$!". The point I raised about the example was that the "+46*" regexp antecedent didn't do anything - if delegation to 6.4.e164.arpa got you to this record, then of course the regexp was going to match with a leading "+46*". There's no question that regexps are valuable for other DDDS applications - but most DDDS applications don't have anything like ENUM's telephone number resolution system to narrow selection down to a specific record set as a part of DNS operations. The regular expression is there, for example, to match against URN components in order to determine which substitutions are valid - I'd look at examples 5.2 and 5.3 in RFC3404 to see how it would be used. It isn't at all clear that a comparable function is necessary or useful for ENUM - I'm not saying that I'm sure it's not useful, but I am saying that clearly ENUM works without it, and to my knowledge there are no existing use-cases for supplying a regexp antecedent for ENUM NAPTR records. Also, note that the wildcard example begs questions about partial numbers that we're trying to pass over in silence, at least in the current version of RFC2916bis. If you can provide a meaningful use case that doesn't involve partial numbers and/or gateway location that uses wildcards, I'll happily relax this language. > > Comment: 5.4 > > 'E2IPv4+sip' > > What is this? A rhetorical example, as the surrounding context hopefully indicates. It's not meant to be a real enumservice, but is rather a theoretical enumservice that one might invent if one's underlying assumptions were different. Again, I think that is well substantiated by the text of the end of 5.4. > > Comment: 5.6 > > "$ORIGIN 0.0.6.2.3.3.5.2.0.2.1.e164.arpa. > IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:user@example.com!" . > IN NAPTR 100 20 "u" "E2U+mailto" "!^.*$!mailto:info@example.com!"." > > ? > I am glad that at least "email:mailto" is allowed beside SIP ;-) No spam > problem? > Heh. > Comment: 5. > > "These guidelines do not by any means exhaustively describe the NAPTR > algorithm or the processing of NAPTR records; implementers should > familiarize themselves with the DDDS algorithm and ENUM before > reviewing this section." > > MM will like to hear this one ;-) > Yes, no desire here to regurgitate the base standard. Jon Peterson NeuStar, Inc. > Richard > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 4 14:45: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 OAA04284 for ; Fri, 4 Jul 2003 14:45: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 19YVYQ-0005dL-HF for sipping-archive@odin.ietf.org; Fri, 04 Jul 2003 14:45:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h64Ij6OD021648 for sipping-archive@odin.ietf.org; Fri, 4 Jul 2003 14:45:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YVYQ-0005d5-E7 for sipping-web-archive@optimus.ietf.org; Fri, 04 Jul 2003 14:45: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 OAA04260 for ; Fri, 4 Jul 2003 14:45:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YVYN-00012O-00 for sipping-web-archive@ietf.org; Fri, 04 Jul 2003 14:45:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YVYN-00012L-00 for sipping-web-archive@ietf.org; Fri, 04 Jul 2003 14:45:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YVYM-0005bJ-8Z; Fri, 04 Jul 2003 14: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 19YVYF-0005aD-IV for sipping@optimus.ietf.org; Fri, 04 Jul 2003 14:44: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 OAA04248 for ; Fri, 4 Jul 2003 14:44:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YVYC-00011w-00 for sipping@ietf.org; Fri, 04 Jul 2003 14:44:52 -0400 Received: from dirty.research.bell-labs.com ([204.178.16.6]) by ietf-mx with esmtp (Exim 4.12) id 19YVYB-00011t-00 for sipping@ietf.org; Fri, 04 Jul 2003 14:44:51 -0400 Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h64IigHa067144; Fri, 4 Jul 2003 14:44:43 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h64IiV1u018202; Fri, 4 Jul 2003 14:44:32 -0400 (EDT) Received: from bell-labs.com (guard.research.bell-labs.com [135.104.2.9] (may be forged)) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h64IiRQ4013266; Fri, 4 Jul 2003 14:44:28 -0400 (EDT) Message-ID: <3F05CB0B.7060008@bell-labs.com> Date: Fri, 04 Jul 2003 14:44:27 -0400 From: Volker Hilt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg , "Miguel A. Garcia" , sipping@ietf.org Subject: Re: [Sipping] Comments on draft-ietf-sipping-session-policy-req-00 References: <3F000692.9000109@ericsson.com> In-Reply-To: <3F000692.9000109@ericsson.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, Miguel, Miguel A. Garcia wrote: > First, I am missing a general requirement that describes the general > mechanism that we want. If you consider the General Requirements, > there are many of them explaining different aspects of the solution, > but none that describes generally what is needed. I would expect > something on these lines: > > "A mechanism that provides SIP proxies with the ability to convey > session related policies to SIP User Agents". The goals of the policy draft have been motivated quite nicely with a number of very convincing examples. The requirements for these examples are reflected in some of the Policy Requirements (examples are REQ-POL-4, REQ-POL-5 and REQ-POL-7 to REQ-POL-13). I was wondering if it is possible to separate the requirements specific to these examples (e.g. requesting the use of a different codec, different media addresses, firewalls, QoS) from requirements of the general policy mechanism (the mechanism needed to exchange policy information between UAC, proxies and UAS). This mechanism could be defined independent of a certain use. It could enable a proxy to request the modification of any aspect of a session description. The requirements for certain use cases of the session policy mechanism could then be defined in a separate section/document. This separation seems to be more extendible than combining the requirements of the policy exchange mechanism and use cases. > The thing is that I don't foresee dynamic changes in policies, > depending on the traffic in the network. One could do it, of course, > but requires some extra administration or having some sort of monitor > that acts upon thresholds. How do you envision the proxy to change policies within an active call? This sounds a little like re-INVITEs send out by the proxy (something a proxy can't do!). > Instead I foresee another scenario where the administrator has > certain fixed policies that do not change often. For instance, an > administrator could permanently disallow the G.711 codec because of > the high bandwidth. I think this is an important issue to discuss, > because the solution may go in one or another direction depending on > the rate of the changes in policy. I would suggest to add a > requirement regarding the expected changes in the policies. The session policies will probably not depend on highly dynamic factors such a load (congestion control comes to mind here) but more on things like network configuration and user preferences. These issues can easily be considered by a proxy on a call to call basis. Thanks, Volker -- Volker Hilt Bell Labs / Lucent Technologies phone: +1 732 332 6432 101 Crawfords Corner Rd email: volkerh@bell-labs.com Holmdel, NJ 07733 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 4 19:22: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 TAA12241 for ; Fri, 4 Jul 2003 19:22: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 19YZsc-0002c6-Mj for sipping-archive@odin.ietf.org; Fri, 04 Jul 2003 19:22:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h64NMEYZ010040 for sipping-archive@odin.ietf.org; Fri, 4 Jul 2003 19:22:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YZsc-0002br-IU for sipping-web-archive@optimus.ietf.org; Fri, 04 Jul 2003 19:22: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 TAA12235 for ; Fri, 4 Jul 2003 19:22:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YZsb-0003vV-00 for sipping-web-archive@ietf.org; Fri, 04 Jul 2003 19:22:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YZsa-0003vS-00 for sipping-web-archive@ietf.org; Fri, 04 Jul 2003 19:22:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YZsP-0002bA-Fq; Fri, 04 Jul 2003 19: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 19YZri-0002T0-F0 for sipping@optimus.ietf.org; Fri, 04 Jul 2003 19:21:18 -0400 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12232 for ; Fri, 4 Jul 2003 19:21:15 -0400 (EDT) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 19YZqc-0007Rg-Ej; Fri, 04 Jul 2003 19:20:10 -0400 To: IETF-Announce :; Cc: sipping@ietf.org From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Fri, 04 Jul 2003 19:20:10 -0400 Subject: [Sipping] Last Call: A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP) to a Proposed Standard Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 IESG has received a request from the Session Initiation Proposal Investigation WG to consider A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP) as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-07-24. File(s) can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sipping-mwi-03.txt _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 5 06:06: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 GAA04392 for ; Sat, 5 Jul 2003 06:06: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 19Yjvo-0007kL-CQ for sipping-archive@odin.ietf.org; Sat, 05 Jul 2003 06:06:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h65A6C9a029777 for sipping-archive@odin.ietf.org; Sat, 5 Jul 2003 06:06:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Yjvo-0007kC-89 for sipping-web-archive@optimus.ietf.org; Sat, 05 Jul 2003 06:06: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 GAA04375 for ; Sat, 5 Jul 2003 06:06:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Yjvk-00009p-00 for sipping-web-archive@ietf.org; Sat, 05 Jul 2003 06:06:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Yjvj-00009m-00 for sipping-web-archive@ietf.org; Sat, 05 Jul 2003 06:06:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Yjvd-0007iy-Mg; Sat, 05 Jul 2003 06:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Yjuf-0007hz-3c for sipping@optimus.ietf.org; Sat, 05 Jul 2003 06:05: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 GAA04337; Sat, 5 Jul 2003 06:04:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Yjub-000096-00; Sat, 05 Jul 2003 06:04:57 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx with smtp (Exim 4.12) id 19YjuZ-000092-00; Sat, 05 Jul 2003 06:04:56 -0400 content-class: urn:content-classes:message Subject: AW: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Sat, 5 Jul 2003 12:08:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <06CF906FE3998C4E944213062009F162233712@oefeg-s02.oefeg.loc> Thread-Topic: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Thread-Index: AcNCpDIkgMmCUmfAQjCStselWm3GWQANeech From: "Stastny Richard" To: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= , "Peterson, Jon" , Cc: "Shockey, Richard" , , Content-Transfer-Encoding: base64 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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: base64 Content-Transfer-Encoding: base64 U2VlIGJlbG93DQoNCgktLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tIA0KCVZvbjog UGF0cmlrIEbDpGx0c3Ryw7ZtIFttYWlsdG86cGFmQGNpc2NvLmNvbV0gDQoJR2VzZW5kZXQ6IFNh IDA1LjA3LjIwMDMgMDU6MTQgDQoJQW46IFBldGVyc29uLCBKb24gDQoJQ2M6IFN0YXN0bnkgUmlj aGFyZDsgU2hvY2tleSwgUmljaGFyZDsgZW51bUBpZXRmLm9yZzsgJ3NpcHBpbmdAaWV0Zi5vcmcn IA0KCUJldHJlZmY6IFJlOiBbRW51bV0gRndkOiBbU2lwcGluZ10gSS1EIEFDVElPTjpkcmFmdC1p ZXRmLXNpcHBpbmctZTE2NC0wMy50IHh0DQoJDQoJDQoNCglPbiBmcmVkYWcsIGp1bCA0LCAyMDAz LCBhdCAyMDowNSBFdXJvcGUvU3RvY2tob2xtLCBQZXRlcnNvbiwgSm9uIHdyb3RlOg0KCQ0KCT4g SSBhZ3JlZSB0aGlzIGlzIGFuIGltcG9ydGFudCBpc3N1ZS4gV2hpbGUgSSBhY2tub3dsZWRnZSB0 aGF0DQoJPiAid2lsZGNhcmRzIiBhcmUNCgk+IHBvc3NpYmxlIGFjY29yZGluZyB0byB0aGUgc3lu dGF4LCB3aGF0J3MgdGhlIHVzZS1jYXNlIHRoYXQgbW90aXZhdGVzDQoJPiB3aWxkY2FyZHMgZm9y IEVOVU0/DQoJDQoJQmVjYXVzZSBzdXBwb3J0IGZvciB3aWxkY2FyZHMgaXMgYSBNVVNUIHdoZW4g eW91IGltcGxlbWVudCB0aGUgTkFQVFINCglyZWNvcmQsIHdoaWNoIEVOVU0gaW5oZXJpdHMgZnJv bSB0aGUgREREUyBhcHBsaWNhdGlvbi4gSWYgeW91IGRvbid0DQoJaW1wbGVtZW50IGl0LCB5b3Ug bG9vc2UuIFlvdSBkb24ndCBoYXZlIGEgREREUyBjb21wbGlhbnQgaW1wbGVtZW50YXRpb24uDQoJ DQoJU28sIEkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgeW91IGRvIHRoaXMgcmVjb21tZW5kYXRpb24u IFdoYXQgaXMgaXQNCglzdXBwb3NlZCB0byBoZWxwIHdpdCwgYXMgaW1wbGVtZW50YXRpb25zIHN0 aWxsIGhhdmUgdG8gaW1wbGVtZW50IHRoZQ0KCXJlZ2V4cCBhY2NvcmRpbmcgdG8gdGhlIE5BUFRS IHNwZWNpZmljYXRpb24uDQoJDQoJICAgICBwYWYNCgktLS0tLS0tDQoNCglUbyB3aGljaCBJIHJl cGx5IHRvIEpvbiBhbmQgUGF0cmlrOg0KDQoJTWFydGluIFN0cmVsbGVyIGdhdmUgYWxyZWFkeSBv bmUgZXhhbXBsZS4gDQoNCglpdCBpcyB1c2VkIGZvciBwb2ludGluZyB0byB3aG9sZSByYW5nZSBv ZiBwYXJ0aWFsIG51bWJlcnMgb2YgYSBQQlguIFRoZSB0ZXJtICJQYXJ0aWFsIG51bWJlcnMiIGlz IHVzZWQgaGVyZSBpbiB0aGUgY29udGV4dCBvZiBFLjE2NCBBbm5leCBCLiBXaGF0IHlvdSBjYWxs IHBhcnRpYWwgbnVtYmVycyBJIGNhbGwgaW5jb21wbGV0ZSBudW1iZXJzLg0KDQoJSSBoYXZlIHRv IGFkbWl0IHRoYXQgYWxzbyB3aXRoaW4gb3VyIHRyYWlscyB0aGVyZSBhcmUgdHdvIHNjaG9vbHMg b2YgdGhvdWdodDogT25lIHByb3Bvc2luZyB0aGUgdXNlIG9mIHdpbGRjYXJkcyBhbmQgcmVnZXhw IGZvciB0aGlzLCB0aGUgb3RoZXJzIChtb3N0bHkgRE5TIHBlb3BsZSBoYXZpbmcgYW4gaG9ycm9y IG9mIHdpbGRjYXJkcykgYXJlIHByb3Bvc2luZyBqdXN0IHRvIGdlbmVyYXRlIHpvbmUgZW50cmll cyBmb3IgZWFjaCBmdWxsIG51bWJlci4NCg0KCVRoZSBmaXJzdCBhcHByb2FjaCBoYXMgdGhlIGRy YXdiYWNrIHRoYXQgaXQgb25seSB3b3JrcyBpZiBhbGwgZW50aWVzIGFyZSBzaW1pbGFyIGFuZCBh bHNvIGlmIHRoZXJlIGlzIG9ubHkgb25lIE5BUFRSIHBlciBudW1iZXIgcG9pbnRpbmcgdG8gdGhl IHNhbWUgc2VydmljZSAoZS5nLiBzaXApLiBFc3BlY2lhbGx5IHlvdSBzaG91bGQgbGlrZSB0aGlz IDstKQ0KDQoJVGhlIG90aGVyIGV4YW1wbGUgaXMgdGhlIGV2ZW4gbW9yZSBnZW5lcmljIGFwcHJv YWNoIFBhdHJpayB3YXMgdGFsa2luZyBhYm91dCBhbmQgd2h5IHdlIHdhbnRlZCB0aGUgZW51bS1V Ukkgb3IgdGhlICJhbGwiIG9yICIqIiBlbnVtc2VydmljZTogSXRzIHRoZSBjb2RlLXNwbGl0IGV4 YW1wbGUsIGUuZyBpZiB5b3UgaGF2ZSB0d28gZGlmZmVyZW50IGFyZWEgY29kZXMgcnVubmluZyBw YXJhbGxlbC4gQlRXIFBhdHJpaywgSSBkbyBub3QgdW5kZXJzdGFuZCBxdWl0ZSB5b3VyIGV4YW1w bGUuDQoNCglUaGVyZSBtYXkgYmUgbW9yZSBleGFtcGxlcy4NCg0KCUp1c3Qgb25lIGNvbW1lbnQg dG8geW91ciBkcmFmdCANCg0KCWluIGdlbmVyYWw6IEkgYWxzbyBjb25zaWRlciBpdCBuZWNlc3Nh cnkgdG8gaGF2ZSBzYW1lIGtpbmQgb2YgQkNQIG9uIGVudW0sIGJ1dCBJTUhPIGl0IGlzIHN0aWxs IHRvbyBlYXJseSB0byBkbyB0aGlzLiBXZSBuZWVkIG1vcmUgcHJhY3RpY2FsIGV4cGVyaWVuY2Ug c3RpbGwuIEFuZCBpdCBzaG91bGQgYmUgZG9uZSBieSB0aGUgZW51bSBXRywgbWF5YmUgd2l0aCBp bnB1dHMgZnJvbSBvdGhlciBncm91cHMuDQoNCglyZWdhcmRzDQoNCglSaWNoYXJkDQoNCg== _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 5 20:25: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 UAA20736 for ; Sat, 5 Jul 2003 20:25: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 19YxL4-0005rT-Fp for sipping-archive@odin.ietf.org; Sat, 05 Jul 2003 20:25:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h660PA4T022527 for sipping-archive@odin.ietf.org; Sat, 5 Jul 2003 20:25:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YxL4-0005rG-CT for sipping-web-archive@optimus.ietf.org; Sat, 05 Jul 2003 20:25: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 UAA20719 for ; Sat, 5 Jul 2003 20:25:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YxL2-0006Y4-00 for sipping-web-archive@ietf.org; Sat, 05 Jul 2003 20:25:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YxL1-0006Xw-00 for sipping-web-archive@ietf.org; Sat, 05 Jul 2003 20:25:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YxKv-0005o7-Mx; Sat, 05 Jul 2003 20:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YxKe-0005mk-SZ for sipping@optimus.ietf.org; Sat, 05 Jul 2003 20:24: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 UAA20701; Sat, 5 Jul 2003 20:24:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YxKa-0006Xj-00; Sat, 05 Jul 2003 20:24:40 -0400 Received: from pine.neustar.com ([209.173.57.70]) by ietf-mx with esmtp (Exim 4.12) id 19YxKZ-0006Xf-00; Sat, 05 Jul 2003 20:24:39 -0400 Received: from chiimc01.npac.com ([10.32.90.4]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id h660NZN02677; Sun, 6 Jul 2003 00:23:35 GMT Received: by CHIIMC01 with Internet Mail Service (5.5.2653.19) id ; Sat, 5 Jul 2003 19:26:18 -0500 Message-ID: <0449D80A0E9B614A83FA9031B07E8D3B257C72@stntexch2.va.neustar.com> From: "Peterson, Jon" To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= Cc: "'Stastny Richard'" , "Shockey, Richard" , enum@ietf.org, "'sipping@ietf.org'" Subject: RE: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Date: Sat, 5 Jul 2003 19:24:30 -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: , > > Because support for wildcards is a MUST when you implement the NAPTR > record, which ENUM inherits from the DDDS application. If you don't > implement it, you loose. You don't have a DDDS compliant > implementation. > I'm not suggesting that clients refuse to process records with more complex regexp antecedents if they happen to receive them - this is in a section of advice for authors of NAPTR records, not a specification of resolver behavior. Nothing (I hope) in our document breaks DDDS or RFC2916bis compliance in any way. [from another mail] > You can have something like this (I think, straight from my head): > > 1.2.3.4.e164.arpa. IN CNAME 4.e164.arpa. > 2.2.3.4.e164.arpa. IN CNAME 4.e164.arpa. > 3.2.3.4.e164.arpa. IN CNAME 4.e164.arpa. > > 4.e164.arpa. IN NAPTR .... "!^+4(.*)$!sip:9876\1@example.com!" I had thought that the reason that the reason such examples were removed from rfc2916bis is that we wanted to pass over this issue of partial E.164 numbers in silence. The restriction in the sipping-e164 document basically reinforces this (at a RECOMMENDED level, not as a mandatory statement), but given that this seems to be a controversial matter, perhaps it would be best if we passed over this in silence in the SIPPING document as well. Wildcarding is, I agree, a separable issue. But I guess I am also a little unclear, given the example above, how delegation from 4.e164.arpa to the subdomains works - would there be additional records under 4.e164.arpa besides that NAPTR that indicate delegation? Many of the partial number cases (including the one Martin showed us) do entail some wildcarding, anyway. Jon Peterson NeuStar, 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 Sun Jul 6 04: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 EAA09270 for ; Sun, 6 Jul 2003 04: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 19Z570-0006u0-0v for sipping-archive@odin.ietf.org; Sun, 06 Jul 2003 04:43:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h668hA0c026530 for sipping-archive@odin.ietf.org; Sun, 6 Jul 2003 04: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 19Z56z-0006to-Ra for sipping-web-archive@optimus.ietf.org; Sun, 06 Jul 2003 04:43: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 EAA09247 for ; Sun, 6 Jul 2003 04:43:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Z56w-0000nw-00 for sipping-web-archive@ietf.org; Sun, 06 Jul 2003 04:43:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Z56w-0000nt-00 for sipping-web-archive@ietf.org; Sun, 06 Jul 2003 04: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 19Z56s-0006su-ML; Sun, 06 Jul 2003 04: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 19Z56k-0006sA-37 for sipping@optimus.ietf.org; Sun, 06 Jul 2003 04:42: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 EAA09240; Sun, 6 Jul 2003 04:42:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Z56h-0000nj-00; Sun, 06 Jul 2003 04:42:51 -0400 Received: from us.svf.stuba.sk ([147.175.16.9]) by ietf-mx with esmtp (Exim 4.12) id 19Z56g-0000nc-00; Sun, 06 Jul 2003 04:42:50 -0400 Received: from us.svf.stuba.sk (localhost [127.0.0.1]) by us.svf.stuba.sk (8.12.9/8.12.9) with ESMTP id h668gjb2047952; Sun, 6 Jul 2003 10:42:45 +0200 (CEST) (envelope-from md@us.svf.stuba.sk) Received: (from md@localhost) by us.svf.stuba.sk (8.12.9/8.12.9/Submit) id h668geVd047951; Sun, 6 Jul 2003 10:42:40 +0200 (CEST) Date: Sun, 6 Jul 2003 10:42:40 +0200 From: Marian Durkovic To: enum@ietf.org, sipping@ietf.org Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Message-ID: <20030706104240.A47655@us.svf.stuba.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , > Major problem: 5.3 > "Authors of > records intended to be used for SIP applications SHOULD always use a > greedy regexp; no use-cases have been identified today in which a > different antecedent is necessary." > > I strongly object this. > First, the use of regular expessions is a feature in ENUM and DDDS, > second, there are use cases (e.g. in wildcards) and > third, if there is no-use cases, why is are regular > expression there in > the first place? Hi all, we're heavily using the wildcards in Slovak ENUM trial for pointing all the numbers behind a PBX to the VoIP gateway attached to this PBX. Here is the example: the PBX prefix +421-55555-xxx (number not real) The DNS: $ORIGIN 5.5.5.5.5.1.2.4.e164.arpa. * IN NAPTR 100 10 "u" "E2U+sip" "!^\\+42155555(.*)$!sip:1\\1@foo.sk!" . Thus when one calls +421-55555-777 the above rule replaces it with sip:1777@foo.sk I really refuse to put 1000 NAPTR records into DNS just to get the same functionality. If someone wants to arrange things in a different way, the exact NAPTR record can still be put into DNS and it overrides the wildcard one. I've seen similar examples in Swedish ENUM trial, so I fully support the objection against the requirement for greedy regexpr. With kind regards, M. -------------------------------------------------------------------------- ---- ---- ---- Marian Durkovic network manager ---- ---- ---- ---- Slovak Technical University Tel: +421 2 524 51 301 ---- ---- Computer Centre, Nam. Slobody 17 Fax: +421 2 524 94 351 ---- ---- 812 43 Bratislava, Slovak Republic E-mail: md@bts.sk ---- ---- ---- -------------------------------------------------------------------------- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 6 12: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 MAA16435 for ; Sun, 6 Jul 2003 12:11: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 19ZC6Y-0001fB-Go for sipping-archive@odin.ietf.org; Sun, 06 Jul 2003 12:11:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h66GBA3m006389 for sipping-archive@odin.ietf.org; Sun, 6 Jul 2003 12:11:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZC6Y-0001ey-D0 for sipping-web-archive@optimus.ietf.org; Sun, 06 Jul 2003 12:11: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 MAA16402 for ; Sun, 6 Jul 2003 12:11:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZC6W-0003Kr-00 for sipping-web-archive@ietf.org; Sun, 06 Jul 2003 12:11:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZC6W-0003Kn-00 for sipping-web-archive@ietf.org; Sun, 06 Jul 2003 12: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 19ZC6Q-0001bc-L3; Sun, 06 Jul 2003 12: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 19ZC5t-0001az-1a for sipping@optimus.ietf.org; Sun, 06 Jul 2003 12:10: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 MAA16388; Sun, 6 Jul 2003 12:10:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZC5r-0003Kg-00; Sun, 06 Jul 2003 12:10:27 -0400 Received: from us.svf.stuba.sk ([147.175.16.9]) by ietf-mx with esmtp (Exim 4.12) id 19ZC5q-0003KW-00; Sun, 06 Jul 2003 12:10:26 -0400 Received: from us.svf.stuba.sk (localhost [127.0.0.1]) by us.svf.stuba.sk (8.12.9/8.12.9) with ESMTP id h66GAAb2051961; Sun, 6 Jul 2003 18:10:10 +0200 (CEST) (envelope-from md@us.svf.stuba.sk) Received: (from md@localhost) by us.svf.stuba.sk (8.12.9/8.12.9/Submit) id h66GA4sZ051960; Sun, 6 Jul 2003 18:10:04 +0200 (CEST) Date: Sun, 6 Jul 2003 18:10:04 +0200 From: Marian Durkovic To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: enum@ietf.org, sipping@ietf.org Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Message-ID: <20030706181004.A51884@us.svf.stuba.sk> References: <20030706104240.A47655@us.svf.stuba.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from paf@cisco.com on Sun, Jul 06, 2003 at 03:01:42PM +0200 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by us.svf.stuba.sk id h66GAAb2051961 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 On Sun, Jul 06, 2003 at 03:01:42PM +0200, Patrik F=E4ltstr=F6m wrote: > Can we please keep the discussions about the wildcard in DNS separate =20 > from the regular expression in NAPTR as separate as possible? >=20 > paf I don't think this is fully possible. If you want to use wildcard in DNS, you must use non-greedy regular expression with a subpattern ( ) to extra= ct and reuse the digits matched by the wildcard: $ORIGIN 5.5.5.5.5.1.2.4.e164.arpa. * IN NAPTR 100 10 "u" "E2U+sip" "!^\\+42155555(.*)$!sip:1\\1@foo.sk!"= . With kind regards, M. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 6 16:21: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 QAA21622 for ; Sun, 6 Jul 2003 16:21: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 19ZG0V-0001Ca-5x for sipping-archive@odin.ietf.org; Sun, 06 Jul 2003 16:21:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h66KLB2w004616 for sipping-archive@odin.ietf.org; Sun, 6 Jul 2003 16:21:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZG0V-0001CN-2g for sipping-web-archive@optimus.ietf.org; Sun, 06 Jul 2003 16:21: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 QAA21609 for ; Sun, 6 Jul 2003 16:21:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZG0T-0004Tb-00 for sipping-web-archive@ietf.org; Sun, 06 Jul 2003 16:21:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZG0R-0004TW-00 for sipping-web-archive@ietf.org; Sun, 06 Jul 2003 16:21:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZG0L-0001Al-Nd; Sun, 06 Jul 2003 16: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 19ZFzP-0001A6-Sq for sipping@optimus.ietf.org; Sun, 06 Jul 2003 16: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 QAA21583 for ; Sun, 6 Jul 2003 16:19:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZFzO-0004T7-00 for sipping@ietf.org; Sun, 06 Jul 2003 16:20:02 -0400 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by ietf-mx with esmtp (Exim 4.12) id 19ZFzN-0004Su-00 for sipping@ietf.org; Sun, 06 Jul 2003 16:20:01 -0400 Received: from dgismtp05.wcomnet.com ([166.38.58.88]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HHM00HK3DQW0T@firewall.wcom.com> for sipping@ietf.org; Sun, 06 Jul 2003 20:18:32 +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 <0HHM00L01DQWB4@dgismtp05.wcomnet.com>; Sun, 06 Jul 2003 20:18:32 +0000 (GMT) Received: from hsinnreich2 ([166.50.126.193]) by dgismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HHM00I6VDQS2P@dgismtp05.wcomnet.com>; Sun, 06 Jul 2003 20:18:32 +0000 (GMT) Date: Sun, 06 Jul 2003 15:18:28 -0500 From: Henry Sinnreich Subject: RE: [Sipping] I-D ACTION:draft-sharath-sipb-requirements-00.txt In-reply-to: <79FEAA5FABA7D411BF580001023D1BBD02AB03F5@mailserver.sylantro.com> To: "'Mike Chack'" , sipping@ietf.org, "'Sharath Rajasekar'" Cc: =?iso-8859-1?Q?J=F6rgen_Bj=F6rkner?= , Edward Keegan , Trefor Davies Message-id: <000801c343fb$c3ea9990$c17e32a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Specific requirements for SIP business phones may be a good idea, if properly written, so as not to inhibit innovation. Also, since the SIPPING chair has explained why this may not be a SIPPING WG item, it would be very welcome in industry organizations, such as the SIP Forum http://www.sipforum.org/ Please contact us off-line on this - the people CC:'d here. Mike Chack debates the notion that > business phone profile for SIP is not a "cool" use of the sip > protocol. Sharath Rajasekar also writes: >We understand your concern about varying requirements for differing >businesses. However, we believe that the minimal requirements for what >a business phone's feature set must be, is not only independent of the >environment of its use but also does not preclude a vendor from >implementing additional features to address/fulfill the context of >its use. Thus this draft, in no way limits or curtails innovation. 1. One can argue that PCs can act as the highest quality and most versatile business phones for certain types of business users. Besides support also for video, apps, etc. Special applications, such as the agent workstation are cearly better suited for a PC. 2. The combination of PC and desktop SIP phones, where call selection and managemnt is done in a user friendly and powerful fashion from the PC is also a powerful business application. 3. PDA's can have powerful SIP phones - I happen to test two of them right now. 4. Combination of PDA and SIP phone as shown at tradeshows - another poweful application. Given all this variety of what a "SIP business phone" is, do you intend to include all such cases, or just restrict to PBX-like phones? (I hope not) Just legitimizing PSTN-like desktop phones in the IETF at the expense of all the above does not seem to be fair, I believe, nor does it make sense for users. If however a more general meaning of "business phone" can be defined, that would be of interest IMHO, inluding for those vendors that make PC, laptop and PDA based phones or PC assisted phones. Thanks, Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of Mike Chack > Sent: Friday, June 27, 2003 7:40 AM > To: sipping@ietf.org > Subject: RE: [Sipping] I-D > ACTION:draft-sharath-sipb-requirements-00.txt > > > Henry, > > It is obivous that there are many innovative products in the > marketplace. That is not the point. No one is trying to make > the point that the business phone is the end-all-be-all > communication platform. But business phones have a set of > features and usability which are prevalent in the marketplace > today and probably will not disappear overnight. Business > phones are not obsolete and neither is the pstn. There is a > market opportunity here that will drive revenue. As far as I > know most of the individuals contributing to this forum work > for companies whose main goals is to make money. Let's not > discourage dialogue and discourse because you feel that a > business phone profile for SIP is not a "cool" use of the sip > protocol. The US Postal service isn't cool either but > NetFlix has succeeded in using it as an alternative broadband > (high latency !) delivery mechanism for residential video on demand. > > Mike Chack > Sylantro Systems > > > -----Original Message----- > From: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com] > Sent: Thursday, June 26, 2003 8:59 AM > To: SIP Mailing List > Subject: RE: [Sipping] I-D > ACTION:draft-sharath-sipb-requirements-00.txt > > > Venkataramanan, folks, > > I would like to draw your attention to SIP "telephony" > devices integrated into such emerging products as Microsoft > Office 2003, Siemens OpenScape and IBM Sametime. Looking at > them makes you aware the notion of "business phone" is > completely obsolete, IMHO. My apology to countless other > vendors having or developing similar innovative > communications/application platforms for not mentioning here > or not knowing about them. > > As such, "business phone" standards would be in conflict with > innovation. My two cents. > > BTW: I work for neither of the above companies. > > Henry > > Henry Sinnreich > MCI > 400 International Parkway > Richardson, Texas 75081 > USA > > Have you disconnected the PBX? > > > > -----Original Message----- > > From: Sharath Rajasekar [mailto:Sharath.Rajasekar@sylantro.com] > > Sent: Wednesday, June 25, 2003 10:53 PM > > To: 'Henry.Sinnreich@mci.com'; 'sipping@ietf.org' > > Cc: Venkatesh Venkataramanan > > Subject: RE: [Sipping] I-D > > ACTION:draft-sharath-sipb-requirements-00.txt > > > > > > > > Henry, > > > > The draft you have indicated in this email attempts to standardize > > device configuration procedures and physical device requirements > > (with a mention of a small subset of features which really > > contradicts your comment about "Just buy and plug it in" > > requirements). We in our draft however, have focused on a broad set > > of "features/applications" that are most commonly implemented or > > desired in phones used in a variety of business environments. Thus, > > the two drafts address different sets of needs. > > > > We understand your concern about varying requirements for differing > > businesses. However, we believe that the minimal requirements for > > what a business phone's feature set must be, is not only independent > > of the environment of its use but also does not preclude a vendor > > from implementing additional features to address/fulfill the context > > of its use. Thus this draft, in no way limits or curtails > > innovation. > > > > While what our draft defines in terms of "MUST", "SHOULD" and "MAY", > > are still open to debate, we fully believe in the applicability of > > our draft in todays context. > > > > Regards > > Sharath > > > > > > -- -----Original Message----- > > -- From: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com] > > -- Sent: Wednesday, June 25, 2003 6:19 PM > > -- To: SIP Mailing List > > -- Subject: RE: [Sipping] I-D > > -- ACTION:draft-sharath-sipb-requirements-00.txt > > -- > > -- > > -- Venkatesh, > > -- > > -- I tend to agree with Brian. It is not quite clear to me > > -- what a "business > > -- phone" is today, given that different business users have > > -- very different > > -- requirements: > > -- > > -- -person in the mail room: the lowest cost phone, no display, > > -- > > -- -person in the storage area: cordless 802.11x SIP phone, > > -- > > -- -executive desk: high quality speakerphone with > rollodex and color > > -- display, > > -- > > -- -secretary, receptionist, agent: agent workstation = PC > > -- > > -- -cubicle dweller with headset: PC > > -- > > -- -travelling employee: laptop or PDA > > -- > > -- -nurse in hospital: tablet PC with softclient, etc., etc. > > -- > > -- Under these circumstances, what matters is how/what SIP > telephony > > -- devices speak across the wire, auto-configuration > > process and data > > -- format examples, so that users should not worry how to > install and > > -- configure them. The acoustic properties and codecs can be > > -- mentioned in > > -- references to TIA and other documents that deal with > > -- desktop phones, but > > -- for the reasons shown, I doubt we want to block innovation. > > -- Any device > > -- can behave like a phone, even my copy machine/fax - this is > > -- not a cute > > -- joke... > > -- > > -- In conclusion, I believe "business" phones MUST not be > > -- standardized, but > > -- only how they communicate and how they are configured > > automatically. > > -- > > -- If there are missing aspects in the I-D on SIP telephony > > -- devices, the > > -- authors will be happy to include your contributions, if > > -- they fall into > > -- the scope mentioned: "Just buy and plug it in". Please send any > > -- contributions to the authors and I believe they should also > > -- be copied to > > -- the list, so we can discuss. > > -- > > -- We respectfully reserve however the right to stick to what > > -- we believe is > > -- required to meet the objectives specified in our I-D, since they > > -- represent deployment eperience of large numbers of SIP > > -- phones in a large > > -- number of networks. > > -- > > -- Henry > > -- > > -- > -----Original Message----- > > -- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > -- > On Behalf Of Venkatesh Venkataramanan > > -- > Sent: Tuesday, June 24, 2003 2:17 PM > > -- > To: 'Rosen, Brian'; sipping@ietf.org > > -- > Cc: Sharath Rajasekar > > -- > Subject: RE: [Sipping] I-D > > -- > ACTION:draft-sharath-sipb-requirements-00.txt > > -- > > > -- > > > -- > Hi: > > -- > > > -- > We are very interested in making this a SIPPING WG action > > -- > item as well. > > -- > > > -- > DND in the true sense rejects any incoming call from being > > -- > offerred on to the end device. It is a terminal state like > > -- > you have indicated in this email. A presence based > > -- > implementation that allows calls selectively like you have > > -- > indicated could be thought of as a call screening type of > > -- > application rather than DND? > > -- > > > -- > Venkatesh > > -- > > > -- > -----Original Message----- > > -- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > -- > Sent: Tuesday, June 24, 2003 6:01 AM > > -- > To: sipping@ietf.org > > -- > Subject: RE: [Sipping] I-D > > -- > ACTION:draft-sharath-sipb-requirements-00.txt > > -- > > > -- > > > -- > While there is a lot to like about this draft, I think I > > -- > could spend a couple hours poking holes in it. Let me give > > -- > you a "for instance": > > -- > DS-6: All SIP business phones MUST support DND. The > > -- DND feature, > > -- > when activated, MUST reject any incoming call meant > > -- for the phone > > -- > with a 486 Busy response code or MAY redirect the call > > -- to voice > > -- > mail. > > -- > > > -- > A presence based implementation of DND might selectively > > -- > reject calls based on who is calling. My wife and possibly > > -- > my boss might be able to ring through, most other callers > > -- > could not. If I implemented a phone this way, it would not > > -- > be compliant with DS-6. > > -- > > > -- > Forwarding for DND might best be done at the proxy server, > > -- > since you want it to work if the phone is "down". > > -- > > > -- > I also object to the language "meant for the phone". A call > > -- > to our phones is "meant for the user", since we require a > > -- > login. We have VERY little phones state, basically just IP > > -- > addressing things. Everything else is user based, not phone > > -- > based. I wouldn't want to make it a requirement that DND was > > -- > phone state. I would want it to be possible to have a phone > > -- > that two users were logged into > > -- > simultaneously, one of which was DND. > > -- > > > -- > I'll do the review work, but first I want to ask if this > > -- > draft is going to be the basis of work in the sipping group. > > -- > I note that there are other efforts along similar lines, > > -- > although this draft is specific to a "business" phone, if > > -- > that actually matters. So, I guess I'm asking two questions: > > -- > Is sipping going to undertake what I would > > suggest is best > > -- > cast as a BCP on business telephones? > > -- > Is this draft the basis for that work? > > -- > > > -- > I personally think that starting from the work Henry et. al. > > -- > did is a better path. Adding "business" profiles to that > > -- > would be one way. > > -- > > > -- > Brian > > -- > > > -- > > -----Original Message----- > > -- > > From: Internet-Drafts@ietf.org > > [mailto:Internet-Drafts@ietf.org] > > -- > > Sent: Tuesday, June 24, 2003 6:57 AM > > -- > > To: @IETF-Announce.{MARCONI} > > -- > > Cc: sipping@ietf.org > > -- > > Subject: [Sipping] I-D > > -- ACTION:draft-sharath-sipb-requirements-00.txt > > -- > > > > -- > > > > -- > > A New Internet-Draft is available from the on-line > > -- > > Internet-Drafts directories. > > -- > > > > -- > > > > -- > > Title : SIP-B: SIP for Business Phones > > -- > > Requirements for > > -- > > Implementing Business Telephony > > -- > > Features on SIP > > -- > > Endpoints > > -- > > Author(s) : V. Venkataramanan, S. Rajasekar > > -- > > Filename : draft-sharath-sipb-requirements-00.txt > > -- > > Pages : 16 > > -- > > Date : 2003-6-23 > > -- > > > > -- > > This informational internet draft describes the > > -- requirements for a > > -- > > standard business telephone based on the Session Initiation > > -- > Protocol > > -- > > (SIP). The objective of this document is to provide a > > -- > minimum set of > > -- > > requirements for implementing business features on SIP > > -- endpoints. > > -- > > This draft is intended to serve as a requirements > > document for > > -- > > vendors implementing business features on > > -- > SIP based > > -- > > devices/entities. Details of how each capability or > > -- feature is best > > -- > > implemented in SIP, is beyond the scope of this > > -- document and may be > > -- > > tracked through the working group draft submissions. > > -- > > > > -- > > A URL for this Internet-Draft is: > > -- > > > http://www.ietf.org/internet-drafts/draft-sharath-sipb-require > > -- > ments-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-sharath-sipb-requirements-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-sharath-sipb-requirements-00.txt". > > -- > > > -- > NOTE: The mail server at ietf.org can return the document in > > -- > MIME-encoded form by using the "mpack" utility. > > To use this > > -- > feature, insert the command "ENCODING mime" > > before the "FILE" > > -- > command. To decode the response(s), you will > > need "munpack" or > > -- > a MIME-compliant mail reader. Different MIME-compliant > > -- > mail readers > > -- > exhibit different behavior, especially when dealing with > > -- > "multipart" MIME messages (i.e. documents which > > have been split > > -- > up into multiple messages), so check your local > > documentation on > > -- > how to manipulate these messages. > > -- > > > -- > > > -- > Below is the data which will enable a MIME compliant mail > > -- > reader implementation to automatically retrieve the ASCII > > -- > version of the Internet-Draft. > > -- > > > -- > _______________________________________________ > > -- > Sipping mailing list > > -- https://www1.ietf.org/mailman/listinfo/sipping > > -- > This list is for NEW development of the application of SIP > > -- > Use sip-implementors@cs.columbia.edu for questions on current > > -- > sip Use sip@ietf.org for new developments of core SIP > > -- > > > -- > > > -- > _______________________________________________ > > -- > Sipping mailing list > > -- https://www1.ietf.org/mailman/listinfo/sipping > > -- > This list is for NEW development of the 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/listi> nfo/sipping > > -- This list > > is for NEW development of the > > 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 Sun Jul 6 18:19: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 SAA24705 for ; Sun, 6 Jul 2003 18:19: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 19ZHqJ-0004Ra-O7 for sipping-archive@odin.ietf.org; Sun, 06 Jul 2003 18:18:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h66MIlEI017083 for sipping-archive@odin.ietf.org; Sun, 6 Jul 2003 18:18:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZHqJ-0004RS-L0 for sipping-web-archive@optimus.ietf.org; Sun, 06 Jul 2003 18:18: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 SAA24679 for ; Sun, 6 Jul 2003 18:18:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZHqG-0004zb-00 for sipping-web-archive@ietf.org; Sun, 06 Jul 2003 18:18:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZHqG-0004zY-00 for sipping-web-archive@ietf.org; Sun, 06 Jul 2003 18:18:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZHpa-0004HM-Ny; Sun, 06 Jul 2003 18: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 19ZHpN-0004GG-J8 for sipping@optimus.ietf.org; Sun, 06 Jul 2003 18:17: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 SAA24633; Sun, 6 Jul 2003 18:17:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZHpK-0004yh-00; Sun, 06 Jul 2003 18:17:46 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19ZHpJ-0004yX-00; Sun, 06 Jul 2003 18:17:45 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Sun, 6 Jul 2003 23:16:33 +0100 Received: from orion.roke.co.uk ([193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NFGCA24B; Sun, 6 Jul 2003 23:16:24 +0100 From: "Conroy, Lawrence (SMTP)" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Marian Durkovic Cc: enum@ietf.org, sipping@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <56D1CF00-AFCF-11D7-BE0E-000A959CF516@cisco.com> References: <56D1CF00-AFCF-11D7-BE0E-000A959CF516@cisco.com> Date: Sun, 6 Jul 2003 23:16:20 +0100 Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" 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 At 6:31 pm +0200 6/7/03, Patrik F=E4ltstr=F6m wrote: >On s=F6ndag, jul 6, 2003, at 18:10 Europe/Stockholm, Marian Durkovic = wrote: > >>On Sun, Jul 06, 2003 at 03:01:42PM +0200, Patrik F=E4ltstr=F6m wrote: >>>Can we please keep the discussions about the wildcard in DNS = separate >>>from the regular expression in NAPTR as separate as possible? >> >>I don't think this is fully possible. If you want to use wildcard in = DNS, >>you must use non-greedy regular expression with a subpattern ( ) to = extract >>and reuse the digits matched by the wildcard: >> >>$ORIGIN 5.5.5.5.5.1.2.4.e164.arpa. >>* IN NAPTR 100 10 "u" "E2U+sip" = "!^\\+42155555(.*)$!sip:1\\1@foo.sk!" . > >Yes, you are absolutely correct. And one can say dependencies exists=20 >in the other direction as well. > >BUT, today I still see a large number of arguments (especially when=20 >looking at DNSSEC) from a pure DNS perspective to _not_ use=20 >wildcards in DNS. > >My point is that that is not enough as an argument for removing the=20 >regular expression in the NAPTR for ENUM. It is needed anyway, and I=20 >gave an example. > >You say you don't want a million NAPTR records in your DNS server,=20 >and I can understand that given the most common provisioning=20 >mechanisms which exists. > >The IETF do though concentrate on what goes on the wire between=20 >hosts, and not so much of how things are inside the host itself. > >I.e. you might have some DNS software that you can configure given=20 >some kind of wildcard, BUT, it will not be a wildcard from a DNS=20 >perspective. That is a very very big difference. The wildcard in DNS=20 >have many side effects -- most of them today felt being negative. > > paf > Hi Patrik, Marian, folks, I'll have one more try. I *did* reset the thread name. Folk must have missed the "Use of=20 Wildcards in ENUM"; this topic is not specific to using ENUM in sip, but...Hey ho. Re. DNS Wildcards - these can exist and can be used, albeit they are = dangerous. What goes over the wire should be a standard DNS response message *as = if the DNS request* had matched the query domain as requested, with several=20 big gotchas to make life interesting. Using a DNS Wildcard is NOT the same as provisioning a whole raft of = similar entries into the DNS server using some sensible software, IMHO; the = effect may be the same, or may not, depending on other entries - that's one reason = why DNS wildcards are risky. Listing the caveats in DNS wildcard use for ENUM seems like a good idea = to me, as, at first, they look like they are very useful. This means that = there WILL be these in ENUM DNS server configurations, so at least a "here's some = hints on detecting and debugging problems with these" would be useful. Yes, it's a standard DNS issue and should be in the FAQ, but they look = like a natural for ENUM with number ranges being reflected as sub-domains, = so I suspect they WILL be an issue that ENUM folk will hit more than most. BTW, I will have a range that directs to an attendant, and so could be = done with a DNS wildcard *without* a non-greedy regexp - these ARE separable = issues. all the best, Lawrence --=20 ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is = not : intended to create any contractual or legal : relationship. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 7 08:52: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 IAA23345 for ; Mon, 7 Jul 2003 08:52: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 19ZVTT-0007aj-6q for sipping-archive@odin.ietf.org; Mon, 07 Jul 2003 08:52:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67Cq7ee029175 for sipping-archive@odin.ietf.org; Mon, 7 Jul 2003 08: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 19ZVTT-0007aU-3V for sipping-web-archive@optimus.ietf.org; Mon, 07 Jul 2003 08:52: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 IAA23323 for ; Mon, 7 Jul 2003 08:52:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZVTR-0003ti-00 for sipping-web-archive@ietf.org; Mon, 07 Jul 2003 08:52:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZVTR-0003te-00 for sipping-web-archive@ietf.org; Mon, 07 Jul 2003 08:52:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZVTN-0007Zb-NE; Mon, 07 Jul 2003 08: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 19ZVT0-0007Yj-WE for sipping@optimus.ietf.org; Mon, 07 Jul 2003 08:51: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 IAA23314; Mon, 7 Jul 2003 08:51:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZVSz-0003tV-00; Mon, 07 Jul 2003 08:51:37 -0400 Received: from us.svf.stuba.sk ([147.175.16.9]) by ietf-mx with esmtp (Exim 4.12) id 19ZVSy-0003se-00; Mon, 07 Jul 2003 08:51:36 -0400 Received: from us.svf.stuba.sk (localhost [127.0.0.1]) by us.svf.stuba.sk (8.12.9/8.12.9) with ESMTP id h67CpIb2077472; Mon, 7 Jul 2003 14:51:18 +0200 (CEST) (envelope-from md@us.svf.stuba.sk) Received: (from md@localhost) by us.svf.stuba.sk (8.12.9/8.12.9/Submit) id h67CpDZC077471; Mon, 7 Jul 2003 14:51:13 +0200 (CEST) Date: Mon, 7 Jul 2003 14:51:13 +0200 From: Marian Durkovic To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: enum@ietf.org, sipping@ietf.org Subject: Re: AW: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Message-ID: <20030707145113.A75121@us.svf.stuba.sk> References: <0E6CC1D4D38A5742930CE896A653477A1813CC@inno-exchange.innovaphone.com> <4CF9C507-B05E-11D7-BE0E-000A959CF516@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <4CF9C507-B05E-11D7-BE0E-000A959CF516@cisco.com>; from paf@cisco.com on Mon, Jul 07, 2003 at 11:35:09AM +0200 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by us.svf.stuba.sk id h67CpIb2077472 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 OK, but all this still translates to me as "use with care" and not as=20 "don't use at all". Sure the DNS admins should be aware of the issues described in RFC1912. Regarding the DNSSEC, ENUM could perhaps apply the=20 attitude described in draft-ietf-dnsext-dns-threats-03.txt: ...since the alternative of giving up wildcards entirely is not=20 practical due to widespread use, we are going to have to live with=20 wildcards, and the question just becomes one of whether or not the=20 proposed optimizations would make DNSSEC's wildcard proof mechanisms= =20 more or less fragile. Anyway, the original topic was, that we all should always use a greedy regexpr which is (not only but also) due to possible use in wildcards and/or in synthesizing DNS servers certainly not a good idea. With kind regards, M. =20 On Mon, Jul 07, 2003 at 11:35:09AM +0200, Patrik F=E4ltstr=F6m wrote: > On m=E5ndag, jul 7, 2003, at 10:42 Europe/Stockholm, Martin Streller=20 > wrote: >=20 > >> The wildcard in DNS > >> have many side effects -- most of them today felt being negative. > > > > you may admit such a statement is a bit vague and nebulous. > > > > Given an example like Marian's or mine - what are the definite > > side effects that you feel negative about ? >=20 > (1) If you have an owner which have a CNAME, you can not have any other= =20 > RR with the same owner. Many many people fail on this (for example,=20 > they add an MX record). > (2) The implications with DNSSEC is not known in enough detail.=20 > Especially when looking at negative caching. Yes, compared to some 6-12= =20 > months ago, there are ideas on how it might work, but the proposal is=20 > still to run wildcards in either a delegated zone which is not secure,=20 > or you synthesize your records, which in turn means you need to have=20 > the private key online. > (3) It is easy to forget the wildcard when you later need to delegate=20 > something, and understand the implications (together with (1) above). >=20 > But, the largest problems are with (1) and (2). >=20 > As DNSSEC is important for ENUM, I rather stay away from wildcards. The= =20 > wildcards _can_ be simulated by either generating many records, or by=20 > having a DNS server which synthesizes the records. >=20 > Another problem when you do ENUM is that there will be responses if=20 > someone query for for example: >=20 > NAN.1.2.3.4.6.4.e164.arpa. + IN + NAPTR >=20 > and in the DNS I have >=20 > *.1.2.3.4.6.4.e164.arpa. IN NAPTR .... >=20 > I don't like that. You might want to store other RR types with similar=20 > names in the same hierarchy, for example SRV records (which Microsoft=20 > Active Directory uses heavily) or whatever. >=20 > paf >=20 >=20 > > > > Martin > > > > -----Urspr=FCngliche Nachricht----- > > Von: Patrik F=E4ltstr=F6m [mailto:paf@cisco.com] > > Gesendet: Sonntag, 6. Juli 2003 18:32 > > An: Marian Durkovic > > Cc: enum@ietf.org; sipping@ietf.org > > Betreff: Re: [Enum] Fwd: [Sipping] I-D > > ACTION:draft-ietf-sipping-e164-03.t xt > > > > > > On s=F6ndag, jul 6, 2003, at 18:10 Europe/Stockholm, Marian Durkovic > > wrote: > > > >> On Sun, Jul 06, 2003 at 03:01:42PM +0200, Patrik F=E4ltstr=F6m wrote= : > >>> Can we please keep the discussions about the wildcard in DNS separa= te > >>> from the regular expression in NAPTR as separate as possible? > >> > >> I don't think this is fully possible. If you want to use wildcard in > >> DNS, > >> you must use non-greedy regular expression with a subpattern ( ) to > >> extract > >> and reuse the digits matched by the wildcard: > >> > >> $ORIGIN 5.5.5.5.5.1.2.4.e164.arpa. > >> * IN NAPTR 100 10 "u" "E2U+sip" > >> "!^\\+42155555(.*)$!sip:1\\1@foo.sk!" . > > > > Yes, you are absolutely correct. And one can say dependencies exists = in > > the other direction as well. > > > > BUT, today I still see a large number of arguments (especially when > > looking at DNSSEC) from a pure DNS perspective to _not_ use wildcards > > in DNS. > > > > My point is that that is not enough as an argument for removing the > > regular expression in the NAPTR for ENUM. It is needed anyway, and I > > gave an example. > > > > You say you don't want a million NAPTR records in your DNS server, an= d > > I can understand that given the most common provisioning mechanisms > > which exists. > > > > The IETF do though concentrate on what goes on the wire between hosts= , > > and not so much of how things are inside the host itself. > > > > I.e. you might have some DNS software that you can configure given so= me > > kind of wildcard, BUT, it will not be a wildcard from a DNS > > perspective. That is a very very big difference. The wildcard in DNS > > have many side effects -- most of them today felt being negative. > > > > paf > > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 7 14:27: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 OAA06453 for ; Mon, 7 Jul 2003 14:27: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 19Zahj-0002hZ-4V for sipping-archive@odin.ietf.org; Mon, 07 Jul 2003 14:27:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67IRB0d010382 for sipping-archive@odin.ietf.org; Mon, 7 Jul 2003 14:27:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zahi-0002hN-Th for sipping-web-archive@optimus.ietf.org; Mon, 07 Jul 2003 14:27: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 OAA06429 for ; Mon, 7 Jul 2003 14:27:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zahg-0000K0-00 for sipping-web-archive@ietf.org; Mon, 07 Jul 2003 14:27:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Zahf-0000Jx-00 for sipping-web-archive@ietf.org; Mon, 07 Jul 2003 14:27:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZahZ-0002gR-Jn; Mon, 07 Jul 2003 14: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 19ZahS-0002fd-TV for sipping@optimus.ietf.org; Mon, 07 Jul 2003 14:26: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 OAA06422 for ; Mon, 7 Jul 2003 14:26:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZahQ-0000Jc-00 for sipping@ietf.org; Mon, 07 Jul 2003 14:26: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 19ZahP-0000J5-00 for sipping@ietf.org; Mon, 07 Jul 2003 14:26:51 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 07 Jul 2003 11:28:49 -0700 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h67IQJMr001123 for ; Mon, 7 Jul 2003 11:26:19 -0700 (PDT) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA13634 for ; Mon, 7 Jul 2003 11:26:18 -0700 (PDT) Message-Id: <4.3.2.7.2.20030707131547.0230da70@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 07 Jul 2003 13:26:22 -0500 To: sipping@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Sipping] Updated Reqs ID for MLPP in 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: , I'd like to call attention to those interested in MLPP to the following updated requirements ID at: http://www.ietf.org/internet-drafts/draft-polk-sipping-mlpp-reqs-01.txt I do not plan on presenting/reviewing this ID during the SIPPING meetings in Vienna, therefore I am soliciting comments to this list The following is the abstract: This document proposes considerations and requirements for the extension of the Session Initiation Protocol (SIP) [1] to support Multi-Level Precedence and Preemption (MLPP) functionality originally set forth in [2&3]. This document will be limited in scope to the requirements of the SIP Protocol; MLPP within the IETF, utilizing other IETF Protocols, is left to other documents, therefore is considered out of scope here - although there is a general explanation of how MLPP functions currently within private circuit switched networks to give the necessary operational background for these requirements. cheers, James ******************* The answer is "42", what's the question? _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 7 15:56: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 PAA12054 for ; Mon, 7 Jul 2003 15:56: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 19Zc5p-0000Oa-TK for sipping-archive@odin.ietf.org; Mon, 07 Jul 2003 15:56:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67Ju9ZN001516 for sipping-archive@odin.ietf.org; Mon, 7 Jul 2003 15:56:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zc5p-0000ON-QO for sipping-web-archive@optimus.ietf.org; Mon, 07 Jul 2003 15:56: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 PAA12007 for ; Mon, 7 Jul 2003 15:56:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zc5o-0001r2-00 for sipping-web-archive@ietf.org; Mon, 07 Jul 2003 15:56:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Zc5n-0001qz-00 for sipping-web-archive@ietf.org; Mon, 07 Jul 2003 15:56:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zc5h-0000MI-LQ; Mon, 07 Jul 2003 15: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 19Zc5F-0000LB-VT for sipping@optimus.ietf.org; Mon, 07 Jul 2003 15:55: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 PAA11994 for ; Mon, 7 Jul 2003 15:55:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zc5E-0001qg-00 for sipping@ietf.org; Mon, 07 Jul 2003 15:55:32 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19Zc5D-0001qA-00 for sipping@ietf.org; Mon, 07 Jul 2003 15:55:31 -0400 Received: from dynamicsoft.com ([63.113.46.11]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h67JskiB005319; Mon, 7 Jul 2003 15:54:48 -0400 (EDT) Message-ID: <3F09D001.8060308@dynamicsoft.com> Date: Mon, 07 Jul 2003 15:54:41 -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: Francois Audet CC: "'sipping@ietf.org'" References: <2F1FC1DEA077D5119FAD00508BCFD6D2086BCFBC@zsc3c030.us.nortel.com> In-Reply-To: <2F1FC1DEA077D5119FAD00508BCFD6D2086BCFBC@zsc3c030.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: Questions and comments on draft-rosenberg-sipping-ice-00 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 Better late than never for a reply, I guess.... Thanks a lot for sending some comments and questions. Replies inline. Francois Audet wrote: > Hi Jonathan, > > Better late than never I guess. I have a few questions/comments on > draft-rosenberg-sipping-ice-00.html. > > - Section 2 (the overview) says that the UAC should attempt to derive > IP addresses with STUN, TURN, RSIP and VPN servers and place all of > these addresses in the offer SDP. Sections 3, 5.1 and 5.4 confirm this > procedure. In the case of STUN, it means a dedicated STUN server as > opposed to the peer-to-peer UA STUN server used at call setup. However, > section 12.3 may lead the reader to believe that a dedicated STUN > server) is "simply not used" and that instead the peer-to-peer UA STUN > servers are sufficient. The wording should be re-done to clarify that > what is not used is the NAT classification process (the derivation of > the IP address using a dedicated STUN server is indeed used). At least, > I think this is what 12.3 is saying. Yes, I agree this is confusing. I was able to submit a revised version of ICE in time for the deadlines. I updated this text to clarify. If there was an example 9.3, > similar to 9.2 but where B calls A, I assume that B would include both > LTA2 and PDTA2 in the offer, and that PDTA2 would be marked as > derived. Is this correct? Yes. > Since the 2 examples of section 9 do NOT have > a STUN-derived address for the calling party, it is even more confusing. The examples in -00 were not so good. THe big thing that I did in this rev of ICE is basically incorporate the scenarios of draft-ietf-sipping-nat-scenarios, to show how ICE would work in residential, enterprise, and centrex configurations. There are several cases now which show peer derived transport addresses. > > - Section 7.2 says that the derived-attribute refer to transport addresses > "learned from the entity to whom the SDP is being sent (referred to > as the peer)". Right. > This is the same issues as the previous one. I don't think > this is correct. It is the transport address learned from the STUN > query: in the initial offer, that address is NOT learned from the > "peer" but from the dedicated STUN server. Correct? No. The STUN address in the initial offer is indeed learned from the dedicated STUN server. However, it would not use the derived attribute, because the intent is indeed to cover only STUN addresses derived from a peer. > In the answer or in > a second round of offer (in an UPDATE), then is is indeed learned from > the peer. Is this correct? Yes. > > - In examples 9.1 and 9.2, A only has one address, a local IPv4 address. > The qvalue is set to 1.0 in the offer in both examples. According to > the rules 5.3, shouldn't the qvalue in the offer been set to 0.8 > instead? The q-values were just suggested. I removed any suggested values from the spec in the rev. Q-values, by their nature, are ordinal, and thats the behavior I want. Suggesting values may make people think they are cardinal with well defined values, which is both misleading and may result in subtle interop problems. > > - In example 9.1, can't we skip the whole peer-to-peer STUN query since > both A and B know that no NATs are involved from their previous STUN > query to the dedicated STUN servers? I mean, when B receives A's > offer, it sees only one address (non-derived), and it knows that > itself has only a non-derived IP address. You could, but in the case where there happened to be some kind of topology issue preventing the media from flowing, you might want to verify that before proceeding with the call. > > - In a few places (including the abstract), it is claimed that ICE is less > brittle than STUN. This may be a little misleading since ICE itselfs > uses the STUN protocol. It should be clarified (as per my earlier point), > that what is meant by "STUN" in this context is that traditional STUN > only > is more brittle than ICE. > > > Typos: > - Section 2, third paragraph, first sentence. Replace "realsm" with > "realms". fixed. > > - In section 9.2, in the paragraph right before the description of the > UPDATE content, replace "has no offered" with "has not offered". That whole section is gone now. 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 Mon Jul 7 16:56: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 QAA14977 for ; Mon, 7 Jul 2003 16:56: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 19Zd28-00050J-EZ for sipping-archive@odin.ietf.org; Mon, 07 Jul 2003 16:56:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67KuOht019229 for sipping-archive@odin.ietf.org; Mon, 7 Jul 2003 16:56:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zd28-000504-A5 for sipping-web-archive@optimus.ietf.org; Mon, 07 Jul 2003 16:56: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 QAA14941 for ; Mon, 7 Jul 2003 16:56:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zd26-0002ek-00 for sipping-web-archive@ietf.org; Mon, 07 Jul 2003 16:56:22 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Zd25-0002eh-00 for sipping-web-archive@ietf.org; Mon, 07 Jul 2003 16:56:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zd1m-0004xz-0M; Mon, 07 Jul 2003 16:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zd1D-0004tU-OG for sipping@optimus.ietf.org; Mon, 07 Jul 2003 16:55: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 QAA14901 for ; Mon, 7 Jul 2003 16:55:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zd1B-0002dw-00 for sipping@ietf.org; Mon, 07 Jul 2003 16:55:25 -0400 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 19Zd19-0002dU-00 for sipping@ietf.org; Mon, 07 Jul 2003 16:55:25 -0400 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 22539; Mon, 07 Jul 2003 16:54:44 -0400 (EDT) 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 Date: Mon, 7 Jul 2003 16:54:51 -0400 Message-ID: <4A3384433CE2AB46A63468CB207E209D097CBF@zoe.office.snowshore.com> Thread-Topic: MSCML Draft Thread-Index: AcNEygLgjBPG400DQz68gvG3z+GOUw== From: "Eric Burger" To: "Sipping (E-mail)" Content-Transfer-Encoding: quoted-printable Subject: [Sipping] MSCML Draft Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable We have resubmitted the MSCML draft. There is no technical difference = between -02 and -03. However, some people were not aware of the royalty = free licensing terms that SnowShore submitted to the IETF in April. = Thus this draft explicitly calls out the royalty free license in the = text. We are in the moratorium period. However, as always, you can download = the draft from=20 http://flyingfox.snowshore.com/i-d/sip/ until the draft gets posted to the I-D archives. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 8 02:44: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 CAA11946 for ; Tue, 8 Jul 2003 02:44: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 19ZmCu-0007ie-EI for sipping-archive@odin.ietf.org; Tue, 08 Jul 2003 02:44:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h686i8TN029665 for sipping-archive@odin.ietf.org; Tue, 8 Jul 2003 02:44:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZmCu-0007iO-3A for sipping-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 02:44: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 CAA11915 for ; Tue, 8 Jul 2003 02:44:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZmCq-0006y3-00 for sipping-web-archive@ietf.org; Tue, 08 Jul 2003 02:44:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZmCp-0006y0-00 for sipping-web-archive@ietf.org; Tue, 08 Jul 2003 02:44:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZmCo-0007fn-LN; Tue, 08 Jul 2003 02: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 19ZmCC-0007dH-7m for sipping@optimus.ietf.org; Tue, 08 Jul 2003 02:43:24 -0400 Received: from us.svf.stuba.sk (us.svf.stuba.sk [147.175.16.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11816; Tue, 8 Jul 2003 02:43:19 -0400 (EDT) Received: from us.svf.stuba.sk (localhost [127.0.0.1]) by us.svf.stuba.sk (8.12.9/8.12.9) with ESMTP id h686fqb2093286; Tue, 8 Jul 2003 08:41:52 +0200 (CEST) (envelope-from md@us.svf.stuba.sk) Received: (from md@localhost) by us.svf.stuba.sk (8.12.9/8.12.9/Submit) id h686fgt7093272; Tue, 8 Jul 2003 08:41:42 +0200 (CEST) Date: Tue, 8 Jul 2003 08:41:42 +0200 From: Marian Durkovic To: Jim Reid Cc: enum@ietf.org, sipping@ietf.org Subject: Re: AW: AW: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Message-ID: <20030708084142.A91895@us.svf.stuba.sk> References: <3840.1057597536@shell.nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3840.1057597536@shell.nominum.com>; from Jim.Reid@nominum.com on Mon, Jul 07, 2003 at 10:05:36AM -0700 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , > Jim Reid wrote: > Indeed. But just because something is cheap doesn't necessarily mean > it's the Right Thing To Do. It could mean that the real issue -- which > seems to be provisioning in this case -- does not get addressed. Or > else a quick+dirty solution imposes undesirable constraints on > whatever is ultimately deployed. Use of wildcards in ENUM is not a provisioning issue. If it was, I'd spend a couple of minutes writing the script to generate the zone files instead of opening the topic here. The approach of having one record per every PBX extension is perhaps usable in trials, but it does not scale. Our institutions typically have 3-digit extensions, the larger ones 4-digit extensions. Having this in mind you can easily find yourself in the situation, where e.g. 300 customers generate as much as 1 million records. If there's 1 million records in top-level domain, you have 1 milion customers to cover the costs. But what will be the cost per customer, if the number of customers is 300 ? The approach with wildcards generates only 300 records per 300 customers. This is huge difference certainly worth inverstigating. > Patrik Faltstrom wrote: > The only place they are used is when the MX record refer to a gateway > (to X.400 or UUCP) where the other side of the gateway is managing a > number of (sub-) domains, and it is impossible to point all these > domains in DNS with individual MX records to the media gateway. You hit the nail. We need to do similar thing - redirect all voice traffic to a VoIP gateway connected to PBX with many many extensions. > Michael Haberler wrote: > Or do you propose to have a wildcard in the zone, and have the server > interpret it differently - i.e giving a matching non-wildcard response? This is how wildcards work _now_ with standard DNS - they are internal to the host running the DNS daemon. The end-user's resolver has no way to tell, if the response is based on wildcard or exact record, since the response is formulated as exact match in both cases. We can certaintly improve the default wildcard behaviour with more sophisticated record synthesizing, in order to get rid of common problems with classic wildcards, but I think we really need the capability for one-to-many conversion in ENUM DNS. I'd take BGP as an example. In early BGP3 stages, every C-class network has to be announced via BGP. Due to scaling issues, BGP4 has to be introduced, which enabled route aggregation. The ENUM problem is perhaps not that urgent, since ENUM zones are not dumped to every backbone router, but the basic principle is the same - the need for some form of aggregation is here now, and I think we can't close our eyes. With kind regards, -------------------------------------------------------------------------- ---- ---- ---- Marian Durkovic network manager ---- ---- ---- ---- Slovak Technical University Tel: +421 2 524 51 301 ---- ---- Computer Centre, Nam. Slobody 17 Fax: +421 2 524 94 351 ---- ---- 812 43 Bratislava, Slovak Republic E-mail: md@bts.sk ---- ---- ---- -------------------------------------------------------------------------- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 8 03:29: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 DAA12880 for ; Tue, 8 Jul 2003 03:29: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 19ZmuN-0001va-Vf for sipping-archive@odin.ietf.org; Tue, 08 Jul 2003 03:29:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h687T3GZ007408 for sipping-archive@odin.ietf.org; Tue, 8 Jul 2003 03:29:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZmuN-0001vP-OS for sipping-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 03:29: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 DAA12861 for ; Tue, 8 Jul 2003 03:29:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZmuL-0007Cv-00 for sipping-web-archive@ietf.org; Tue, 08 Jul 2003 03:29:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZmuK-0007Cs-00 for sipping-web-archive@ietf.org; Tue, 08 Jul 2003 03:29:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZmuM-0001uQ-3E; Tue, 08 Jul 2003 03:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZmtN-0001sC-OJ for sipping@optimus.ietf.org; Tue, 08 Jul 2003 03:28: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 DAA12816 for ; Tue, 8 Jul 2003 03:27:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZmtL-0007CI-00 for sipping@ietf.org; Tue, 08 Jul 2003 03:27:59 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ZmtG-0007CA-00 for sipping@ietf.org; Tue, 08 Jul 2003 03:27:54 -0400 Received: from dynamicsoft.com ([63.113.46.11]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h687RNiB005521 for ; Tue, 8 Jul 2003 03:27:24 -0400 (EDT) Message-ID: <3F0A7256.60900@dynamicsoft.com> Date: Tue, 08 Jul 2003 03:27: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: sipping Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Update to caller preferences use cases Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 Folks, You may have seen that I posted an update to the caller preferences use cases: http://www.jdrosen.net/papers/draft-ietf-sipping-callerprefs-usecases-00.txt http://www.jdrosen.net/papers/draft-ietf-sipping-callerprefs-usecases-00.html http://www.ietf.org/internet-drafts/draft-ietf-sipping-callerprefs-usecases-00.txt This is now a working item of SIPPING. There are a bunch of changes since the previous version. Firstly, the use cases are now aligned with the -09 version of caller preferences. As a result of the changes in the caller preferences algorithms, several use cases no longer work. I've already documented those in a note to sip. Some other changes: * added a hearing impaired use case * added a use case where the registered contact has an embedded Reject-Contact * added a bunch of example registrations from various common devices, to show how to use caller prefs * added a bunch of material up front to motivate caller prefs And some other open issues: * one of the use cases (section 3.14) is really better done with a CPL script than caller preferences. Should we eliminate this use case? I say yes. * do we advise devices to register what they can't do, along with what they can do? THis makes the registrations a lot more bloated, but caller preferences tends to work better. I say no. * do we want to include an example implementation of the matching procedure of rfc2533? The benefit is to help calrify the spec a lot. The drawback is - what happens if its not consistent with the normative algorithm in RFC2533? I say we should include it. Comments and 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 From exim@www1.ietf.org Tue Jul 8 09:04: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 JAA20348 for ; Tue, 8 Jul 2003 09:04: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 19Zs8f-0000X9-NW for sipping-archive@odin.ietf.org; Tue, 08 Jul 2003 09:04:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68D49Gc002047 for sipping-archive@odin.ietf.org; Tue, 8 Jul 2003 09:04:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zs8f-0000Ww-K6 for sipping-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 09:04: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 JAA20273 for ; Tue, 8 Jul 2003 09:04:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zs8d-0001Ol-00 for sipping-web-archive@ietf.org; Tue, 08 Jul 2003 09:04:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Zs8d-0001Of-00 for sipping-web-archive@ietf.org; Tue, 08 Jul 2003 09:04:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zs8X-0000UU-D5; Tue, 08 Jul 2003 09: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 19Zs8F-0000Su-CW for sipping@optimus.ietf.org; Tue, 08 Jul 2003 09:03: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 JAA20232 for ; Tue, 8 Jul 2003 09:03:40 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zs8D-0001No-00 for sipping@ietf.org; Tue, 08 Jul 2003 09:03:41 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19Zs8C-0001Ne-00 for sipping@ietf.org; Tue, 08 Jul 2003 09:03:40 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h68D3da09385 for ; Tue, 8 Jul 2003 16:03:39 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 8 Jul 2003 16:03:39 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 8 Jul 2003 16:03:38 +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] Comment on I-D ACTION:draft-niemi-sipping-event-throttle-reqs-02.tx Date: Tue, 8 Jul 2003 16:03:38 +0300 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945313@esebe013.ntc.nokia.com> Thread-Topic: Comment on I-D ACTION:draft-niemi-sipping-event-throttle-reqs-02.tx Thread-Index: AcNCHTqzu3u+Yqi4RtedKKgy11SOgQDEbtmg To: , X-OriginalArrivalTime: 08 Jul 2003 13:03:38.0928 (UTC) FILETIME=[594B4B00:01C34551] 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 Hisham, Inline. > -----Original Message----- > From: ext hisham.khartabil@nokia.com=20 > [mailto:hisham.khartabil@nokia.com] > Sent: 04 July, 2003 14:13 > To: sipping@ietf.org > Cc: Niemi Aki (NMP/Helsinki) > Subject: [Sipping] Comment on I-D > ACTION:draft-niemi-sipping-event-throttle-reqs-02.tx >=20 >=20 > Hi, >=20 > I have a comment on the model section rather than the requirements :) >=20 > I was ok with the model until I looked at the example. I=20 > don't like the idea of delayed notification, especially in=20 > the case of presence. I much prefer to receive up to date=20 > limited info (lossy model) rather than stale info. I.e.=20 > buffer size of 1. I agree both are equally good use cases, and I suspect there are several = more. I chose the other one because it seemed easier to construct in a = use-case format. Of course we could add a use case or two, but I doubt = that would shed any more light to the requirements we already have. Is this needed? If people feel strongly about including a stronger set = of use-cases, I certainly can add another one. =20 > Others might have a different preference depending on the=20 > type of event. Example is geoloc; I might want to see the=20 > towns/cities you are driving through while crossing Europe=20 > by car. Delayed notifications in this case are ok. Right. =20 > Example where the lossy model is favourable is message=20 > waiting indication where I don't want to receive=20 > notification every time I have a new message in my inbox,=20 > but I want to receive notifications on hourly basis telling=20 > me how many messaging I now have waiting.=20 This is also true. Although I would still call both models lossy, since = in the former one you lose accuracy in the form of delayed = notifications; in the latter there is actual loss of information. > Perhaps this is a subscriber option and a requirement is=20 > needed to address it: A subscribe SHOULD? be able to choose=20 > the model associated with the subscription. This is something that also came up in Dean's comments earlier. The = problem I have with this is the potential complexity involved in such a = requirement. There are at least the "delay" model and the "drop" model, = but also any combination of them, also depending on what the notifier = local policy dictates.=20 For example, in a scenario where the notifier buffer is large (but = finite), it can run the delay model only up until the buffer actually = runs out, at which point the policy would actually be forced from = delaying notifications to dropping them. So I would say no. The model by which the notifier treats notifications = in its buffer, and the properties of the buffer are implementation and = package specific. > Unrelated: >=20 > Have you considered a model where the trigger is just the=20 > timer and not timer + whatever is in the buffer. Continuing=20 > your trip through Europe: I want to receive notifications of=20 > your geoloc every hour regardless of your position (if it=20 > has changed or not). So I set the throttle to one hour and=20 > notifications are sent every hour, even if the buffer is empty. Yes, and I'm not sure it falls into throttling's territory. The = throttling policy sets a minimum time period between two notifications, = and this would be setting the *maximum time* between two notifications. Also, I think there are other, potentially simpler ways to accomplish = this - either by setting the subscription refresh rate at one hour, or = by polling once an hour.=20 Cheers, Aki >=20 > Regards, > Hisham >=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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 8 09:21: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 JAA20820 for ; Tue, 8 Jul 2003 09:21: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 19ZsP3-0001Ys-3P for sipping-archive@odin.ietf.org; Tue, 08 Jul 2003 09:21:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68DL52U006002 for sipping-archive@odin.ietf.org; Tue, 8 Jul 2003 09:21:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZsP3-0001Yj-0Z for sipping-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 09:21: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 JAA20768 for ; Tue, 8 Jul 2003 09:21:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZsP1-0001W9-00 for sipping-web-archive@ietf.org; Tue, 08 Jul 2003 09:21:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZsP0-0001W6-00 for sipping-web-archive@ietf.org; Tue, 08 Jul 2003 09:21:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZsOz-0001Xr-G4; Tue, 08 Jul 2003 09: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 19ZsOM-0001WY-WA for sipping@optimus.ietf.org; Tue, 08 Jul 2003 09:20: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 JAA20760; Tue, 8 Jul 2003 09:20:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZsOL-0001Vz-00; Tue, 08 Jul 2003 09:20:21 -0400 Received: from us.svf.stuba.sk ([147.175.16.9]) by ietf-mx with esmtp (Exim 4.12) id 19ZsOK-0001Vg-00; Tue, 08 Jul 2003 09:20:20 -0400 Received: from us.svf.stuba.sk (localhost [127.0.0.1]) by us.svf.stuba.sk (8.12.9/8.12.9) with ESMTP id h68DK5b2010694; Tue, 8 Jul 2003 15:20:05 +0200 (CEST) (envelope-from md@us.svf.stuba.sk) Received: (from md@localhost) by us.svf.stuba.sk (8.12.9/8.12.9/Submit) id h68DK0hY010693; Tue, 8 Jul 2003 15:20:00 +0200 (CEST) Date: Tue, 8 Jul 2003 15:20:00 +0200 From: Marian Durkovic To: Jim Reid Cc: enum@ietf.org, sipping@ietf.org Subject: Re: AW: AW: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Message-ID: <20030708152000.B5311@us.svf.stuba.sk> References: <20561.1057655282@shell.nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20561.1057655282@shell.nominum.com>; from Jim.Reid@nominum.com on Tue, Jul 08, 2003 at 02:08:02AM -0700 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , On Tue, Jul 08, 2003 at 10:58:46AM +0200, Jaap Akkerhuis wrote: > Most instances of this idea with customers with n-bit extensions > PBX I'm familar with, are actually maintaining such a PBX themselves. > If theu want top do ENUM, the obvious solution is to delegate to > that customer. [snip] You can delegate to a nameserver which > maintains that part of the name space for that particular PBX. > There is no need to populate the toplevel with all the nitty gritty > details of that PBX. Sure, those records would not appear in the toplevel, but at the ISP level, since the customers either outsource the DNS to them or at least request a backup DNS to be operated by the ISP. On Tue, Jul 08, 2003 at 02:08:02AM -0700, Jim Reid wrote: > I don't understand the point you're trying to make here. You seem to > be saying something "won't scale" for 300 names but somehow scales > just fine for 1 million names. I'm confused. And you've still to > explain why provisioning NAPTRs for each number -- something you said > was trivial -- couldn't be done and why a wildcard RR was the only > possible solution to the problem you're trying to solve. No, I'm saying that 300 PBX customers might create as much 1 million records. Operating DNS servers with millions of records is not a trivial task at least not for commonly available DNS software and just this is IMHO a good reason to look for alternatives which make more decent use of resources. > Well this is a perfect example of why DNS wildcards provide the wrong > answer to the wrong question. You're assuming that the only use of > ENUM for some range of numbers would be to contact a VoIP gateway. This > cannot be guaranteed. What happens when the owners of (some of) those > numbers want additional NAPTRs for other services? I'm not saying everyone _should_ use wildcards for every possible configuration. But plese don't do the opposite - i.e. don't tell me that we _must not_ use them. > What if they *don't* > want to use this default VoIP gateway? Or can't use it. You might still point the wildcard towards e.g. SIP proxy server, which can handle this more effectively (changes are visible immediately). > with numbers that are not in service? Should applications which look > these up be pointed at the VoIP gateway regardless? That's what you'd > get with a wildcard. Maybe it would be better to get an NXDOMAIN > response from the DNS. Which of course you can't get if there's a > wildcard RR. This can only introduce another point of failure. This would mean, that PBX configuration and DNS configuration must be always in sync which is hard to achieve. Better get the "No subscriber" from the PBX like with PSTN. > The same goes for numbers that are invalid because they > don't have the correct number of digits. What if some of the active > numbers must not be used for VoIP because they're bound to things like > a fax machine or a modem? What if you need to introduce additional > VoIP gateways for some or all of the numbers? Again, you can point the wildcard towards e.g. SIP proxy and introduce much more services. > Sorry, you can't change the semantics of DNS wildcarding without a > wholesale protocol rewrite. And somehow keeping backwards > compatibility with the installed base. Please show how you intend to > do this. I don't. I was mentioning record synthesizing indepened of classic wildcards and their problems. > Marian> but I think we really need the capability for one-to-many > Marian> conversion in ENUM DNS. > > I've not seen any justification for this so far though I accept it > might be useful. Perhaps you could provide some examples? DID (Direct Inward Dial) is a standard telco service that the customers are used to. Emulating it by enumerating all possible digit combinations could be only considered as a workaround and is in many cases pure waste of resources. If the wildcards are no good, other solution has to be found. M. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 8 09:55: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 JAA21674 for ; Tue, 8 Jul 2003 09:55: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 19Zsvy-0003UP-7T for sipping-archive@odin.ietf.org; Tue, 08 Jul 2003 09:55:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68Dt6U1013409 for sipping-archive@odin.ietf.org; Tue, 8 Jul 2003 09:55:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zsvy-0003UC-4U for sipping-web-archive@optimus.ietf.org; Tue, 08 Jul 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 JAA21644 for ; Tue, 8 Jul 2003 09:55:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zsvw-0001if-00 for sipping-web-archive@ietf.org; Tue, 08 Jul 2003 09:55:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Zsvv-0001ic-00 for sipping-web-archive@ietf.org; Tue, 08 Jul 2003 09:55:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zsvt-0003S0-59; Tue, 08 Jul 2003 09:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZsvZ-0003RV-UA for sipping@optimus.ietf.org; Tue, 08 Jul 2003 09:54: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 JAA21635; Tue, 8 Jul 2003 09:54:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZsvX-0001iU-00; Tue, 08 Jul 2003 09:54:40 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx with esmtp (Exim 4.12) id 19ZsvX-0001iQ-00; Tue, 08 Jul 2003 09:54:39 -0400 Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h68DriC18222; Tue, 8 Jul 2003 13:53:44 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jul 2003 09:54:48 -0400 Message-ID: <0449D80A0E9B614A83FA9031B07E8D3B257C80@stntexch2.va.neustar.com> From: "Peterson, Jon" To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= Cc: "'Stastny Richard'" , "Shockey, Richard" , enum@ietf.org, "'sipping@ietf.org'" Subject: RE: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Date: Tue, 8 Jul 2003 09:54:47 -0400 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: , Without speaking to the DNS wildcarding issue as a whole, I suppose that given the public outcry we should pass over this whole greedy regexp issue in silence in sipping-e164. Though ultimately I believe that the use of non-greedy regexps in ENUM encourages NAPTR records for partial numbers (which in turn encourage wildcarding, etc), I certainly don't feel strongly enough about this that I think we need to mandate against it, and I guess I could just drop the current RECOMMENDation. Some other notes below. Jon Peterson NeuStar, Inc. > > > > I'm not suggesting that clients refuse to process records with more complex > > regexp antecedents if they happen to receive them - this is in a section of > > advice for authors of NAPTR records, not a specification of resolver > > behavior. Nothing (I hope) in our document breaks DDDS or RFC2916bis > > compliance in any way. > > Why should they ignore it? They still have to _implement_ it. The people or systems that create the NAPTR records which are provisioned in the DNS do not have to 'implement' resolvers. [snip] > > > The restriction in the sipping-e164 document basically > > reinforces this (at a RECOMMENDED level, not as a mandatory statement), but > > given that this seems to be a controversial matter, perhaps it would be best > > if we passed over this in silence in the SIPPING document as well. > > [snip] > > This has _nothing_ to do with partial numbers. > > Let's then change the example to: > > 1.2.3.4.e164.arpa. IN CNAME foo.bar.example.com. > 2.2.3.4.e164.arpa. IN CNAME foo.bar.example.com. > 3.2.3.4.e164.arpa. IN CNAME foo.bar.example.com. > > foo.bar.example.com. IN NAPTR .... > "!^+4(.*)$!sip:9876\1@anotherexample.net!" > Well, all right, given this clever example, I agree that authors of records don't necessarily have to use partial E.164 numbers in order to use a non-greedy regexp antecedent in NAPTRs. But, authors of records don't really have any incentive to make records structured like this, in which you have to enumerate every number in the numbering plan in a CNAME record. Rather, they want to have a single NAPTR record for a partial number (as in the other examples aired on the list have suggested). > paf _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 8 11:36: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 LAA27209 for ; Tue, 8 Jul 2003 11:36: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 19ZuVh-0000c1-Me for sipping-archive@odin.ietf.org; Tue, 08 Jul 2003 11:36:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68Fa5FB002349 for sipping-archive@odin.ietf.org; Tue, 8 Jul 2003 11:36:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZuVh-0000bo-Je for sipping-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 11:36: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 LAA27179 for ; Tue, 8 Jul 2003 11:36:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZuVg-0002lX-00 for sipping-web-archive@ietf.org; Tue, 08 Jul 2003 11:36:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZuVg-0002lU-00 for sipping-web-archive@ietf.org; Tue, 08 Jul 2003 11:36:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZuVe-0000av-OW; Tue, 08 Jul 2003 11: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 19ZuV4-0000aB-8F for sipping@optimus.ietf.org; Tue, 08 Jul 2003 11:35: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 LAA27150 for ; Tue, 8 Jul 2003 11:35:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZuV3-0002kt-00 for sipping@ietf.org; Tue, 08 Jul 2003 11:35:25 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ZuV2-0002k3-00 for sipping@ietf.org; Tue, 08 Jul 2003 11:35:24 -0400 Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h68FYriB005683 for ; Tue, 8 Jul 2003 11:34:53 -0400 (EDT) Message-ID: <3F0AE499.2090602@dynamicsoft.com> Date: Tue, 08 Jul 2003 11:34: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: sipping Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Update to app-interaction framework Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 Folks, You may have noticed that I posted an update to the app-interaction framework. You can pick up the draft at: http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-app-interaction-framework-00.txt http://www.jdrosen.net/papers/draft-rosenberg-sipping-app-interaction-framework-01.txt http://www.jdrosen.net/papers/draft-rosenberg-sipping-app-interaction-framework-01.html The draft has been substantially slimmed down since the last rev. Thats because the team decided to descope the draft a little, and in particular, rule the stuff on client-remote feature interaction out of scope. While I think that the topic is an important one, it requires a LOT more work, much more than the rest of the framework. Since, for now, what people really need is a standard way to do basic single-application stimulus, and in particular, dtmf, we want to make progress on that bit. Other changes: * mention the use of SIP MESSAGE for conveying the DTMF for "one shot" markups, such as KPML (more on that in a separate note) * removed the bit about using a client-local KPML along with a client-remote VXML to achieve zero latency barge-in. This feature was cool, but required some ugly RTP hacks, and also went against the simplified model we went for with KPML - that its ideal for "one shot" reports of a single keypress, or for continous monitoring. Comments and 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 From exim@www1.ietf.org Tue Jul 8 12:00: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 MAA28574 for ; Tue, 8 Jul 2003 12:00: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 19Zusw-0002E6-GK for sipping-archive@odin.ietf.org; Tue, 08 Jul 2003 12:00:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68G06LK008558 for sipping-archive@odin.ietf.org; Tue, 8 Jul 2003 12: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 19Zusv-0002Dx-VV for sipping-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 12:00: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 MAA28535 for ; Tue, 8 Jul 2003 12:00:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zusu-00035u-00 for sipping-web-archive@ietf.org; Tue, 08 Jul 2003 12:00:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Zusu-00035r-00 for sipping-web-archive@ietf.org; Tue, 08 Jul 2003 12:00:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zusr-0002Cv-MW; Tue, 08 Jul 2003 12: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 19ZusP-0002C3-Ql for sipping@optimus.ietf.org; Tue, 08 Jul 2003 11:59: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 LAA28503 for ; Tue, 8 Jul 2003 11:59:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZusO-00035L-00 for sipping@ietf.org; Tue, 08 Jul 2003 11:59:32 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ZusN-00034y-00 for sipping@ietf.org; Tue, 08 Jul 2003 11:59:31 -0400 Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h68Fx0iB005698 for ; Tue, 8 Jul 2003 11:59:00 -0400 (EDT) Message-ID: <3F0AEA40.4020208@dynamicsoft.com> Date: Tue, 08 Jul 2003 11:58:56 -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: sipping Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] How to report DTMF - conclusion of the app interaction design team: SIP MESSAGE Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 Folks, The application interaction design team is near completion of our set of documents: http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-app-interaction-framework-01.txt http://www.ietf.org/internet-drafts/draft-jennings-sip-app-info-01.txt http://www.ietf.org/internet-drafts/draft-burger-sipping-kpml-02.txt http://www.ietf.org/internet-drafts/draft-culpepper-sipping-app-interact-reqs-03.txt There are really few open issues that we are aware of. The main point of contention, and I think the issue most folks want to see a decision on, is how to actually convey the DTMF to the application when KPML is used. Even within the design team we never really had strong consensus here. However, in the interests of progress, we chose the path we felt was the one of "least evil". That path was to use a SIP MESSAGE request from the client to the application, with content that contains the digits. Not ideal, no doubt. I suspect its also not clear from the documents that this was our decision. The KPML draft has some artifact text that mentions NOTIFY, and it also still talks about HTTP. The team did decide not to go with those. Here were the choices, and the reasoning we went through: 1. Use HTTP POST, as is done in VoiceXML, HTML, WML This approach works well when the post returns another script to execute, as is the case for the above markups. However, because KPML has no presentation, only input, there is really little value in doing that. KPML is useful for two things. The first are "one shots", where the KPML waits for a single sequence, and when it finds it, reports it to the application. From there, the application interacts with the user using media, and the KPML script is done. Common case: long pound in pre-paid. Another modality is what I call "monitor", where the KPML stays resident for the ENTIRE call, and simply reports sequences as it gets them. Once it reports one, it continues waiting for more. Neither of these modes quite fit the bill for HTTP. It could be done, by having the HTTP POST return the same script that is currently running. Not perfect, though. Furthermore, folks were concerned that HTTP was too much effort to put on a device just to report DTMF. 2. Use SIP INFO No doubt this represents the bulk of the implementations today, all non-interoperable unfortunately. The problem with INFO is that the message from the client to the application needs to be OUTSIDE the dialog. Otherwise, every proxy on the path sees it. There are lots of other problems with sending INFO within the dialog of the call setup. So, once you decide that the messaging from the client to the app is outside the dialog, you can't use INFO. INFO is constrained to be within the scope of a dialog. 3. Use NOTIFY, have App-Info create an implicit subscription The client would send a NOTIFY to the application when the digit sequence was matched. There would be no SUBSCRIBE. Rather, the App-Info header, which was used to pass the script to the client, would effectively create an implicit subscription. Implicit subscriptions have all kinds of troubles, which have been discussed on the list. We then need to manage a dialog between the client and application just for reporting DTMF. 4. Use an explicit SUBSCRIBE from the application to the client This has lots of problems. First, it needs to be done outside of the original call setup dialog. That means it needs GRUUs for the application to target the SUBSCRIBE to the specific UA instance that made the call. It also introduces a lot of extra overhead, and would repeat information in the App-Info header (i.e., an expression of interest) 5. New Method We could invent a new method, like REPORT-EVENT or something, sent from the client to the application. However, that seemed too specialized. Also not clear what is really gained from a new method above MESSAGE, see below. 6. Messaging Sessions Use an INVITE from the client to the application, for the purpose of setting up a messaging session, ala MSRP. Once the session is setup, convey the digits using content in MSRP messages. This seemed like a lot of overhead and work for what is probably going to be one or two messages. 7. SIP MESSAGE Send a SIP MESSAGE request from the client to the application, containing the digit sequence to report. This was a bit of a bending of the semantic of MESSAGE, which is really meant for conveying information for display to a user. However, the issue is mostly philosophical in nature. We didnt see any particular technical issue that would prevent this from working, unlike all of the above ones which had technical issues. So, as the path of least ugliness and minimal resistance, we went for MESSAGE. No doubt folks will have comments. The design team is at the point now where broader group input is needed to determine if there is consensus around this, or any other, direction. We felt it was important to capture our thinking on the options above, to give people a context for our decision and to serve as a grounding for further discussion. So, please fire away. 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 Tue Jul 8 13:53: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 NAA02025 for ; Tue, 8 Jul 2003 13:53: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 19ZweN-0000Xj-23 for sipping-archive@odin.ietf.org; Tue, 08 Jul 2003 13:53:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68HrAJ2002087 for sipping-archive@odin.ietf.org; Tue, 8 Jul 2003 13:53:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZweM-0000Xa-El for sipping-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 13:53: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 NAA01992 for ; Tue, 8 Jul 2003 13:53:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZweK-0003vv-00 for sipping-web-archive@ietf.org; Tue, 08 Jul 2003 13:53:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZweJ-0003vs-00 for sipping-web-archive@ietf.org; Tue, 08 Jul 2003 13:53:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZweE-0000Va-Cz; Tue, 08 Jul 2003 13:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zwdd-0000OQ-5c for sipping@optimus.ietf.org; Tue, 08 Jul 2003 13:52: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 NAA01949 for ; Tue, 8 Jul 2003 13:52:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zwdb-0003vU-00 for sipping@ietf.org; Tue, 08 Jul 2003 13:52:23 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ZwdZ-0003v0-00 for sipping@ietf.org; Tue, 08 Jul 2003 13:52:21 -0400 Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h68HpoiB005720 for ; Tue, 8 Jul 2003 13:51:51 -0400 (EDT) Message-ID: <3F0B04B2.3000901@dynamicsoft.com> Date: Tue, 08 Jul 2003 13:51: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: sipping Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Update to 3pcc Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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 From exim@www1.ietf.org Tue Jul 8 14:07: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 OAA02448 for ; Tue, 8 Jul 2003 14:07: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 19Zws0-0001PT-JW for sipping-archive@odin.ietf.org; Tue, 08 Jul 2003 14:07:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68I7G0x005420 for sipping-archive@odin.ietf.org; Tue, 8 Jul 2003 14:07:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zws0-0001PL-GT for sipping-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 14:07: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 OAA02442 for ; Tue, 8 Jul 2003 14:07:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zwry-00044B-00 for sipping-web-archive@ietf.org; Tue, 08 Jul 2003 14:07:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Zwrx-000448-00 for sipping-web-archive@ietf.org; Tue, 08 Jul 2003 14:07:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zwrl-0001MZ-M6; Tue, 08 Jul 2003 14: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 19Zwqy-0001M0-ON for sipping@optimus.ietf.org; Tue, 08 Jul 2003 14:06: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 OAA02433 for ; Tue, 8 Jul 2003 14:06:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zwqw-00043z-00 for sipping@ietf.org; Tue, 08 Jul 2003 14:06:10 -0400 Received: from web41504.mail.yahoo.com ([66.218.93.87]) by ietf-mx with smtp (Exim 4.12) id 19Zwqv-00043w-00 for sipping@ietf.org; Tue, 08 Jul 2003 14:06:09 -0400 Message-ID: <20030708180527.29780.qmail@web41504.mail.yahoo.com> Received: from [207.46.228.16] by web41504.mail.yahoo.com via HTTP; Tue, 08 Jul 2003 11:05:27 PDT Date: Tue, 8 Jul 2003 11:05:27 -0700 (PDT) From: Sean Olson Subject: Re: [Sipping] Update to 3pcc To: Jonathan Rosenberg , sipping In-Reply-To: <3F0B04B2.3000901@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: , This is a huge interop issue. Is .invalid to be the recommendation going forward or is this a stopgap measure? Hopefully SDPng addresses this more directly. --- 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. __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.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 Tue Jul 8 14:13: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 OAA02583 for ; Tue, 8 Jul 2003 14:13: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 19Zwxj-00025K-7e for sipping-archive@odin.ietf.org; Tue, 08 Jul 2003 14:13:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68IDBdJ008009 for sipping-archive@odin.ietf.org; Tue, 8 Jul 2003 14:13:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zwxj-000256-3d for sipping-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 14:13: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 OAA02567 for ; Tue, 8 Jul 2003 14:13:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zwxg-000470-00 for sipping-web-archive@ietf.org; Tue, 08 Jul 2003 14:13:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Zwxg-00046x-00 for sipping-web-archive@ietf.org; Tue, 08 Jul 2003 14:13:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZwxZ-00024E-A5; Tue, 08 Jul 2003 14: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 19Zwws-0001vY-L5 for sipping@optimus.ietf.org; Tue, 08 Jul 2003 14:12: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 OAA02542 for ; Tue, 8 Jul 2003 14:12:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zwwq-00046O-00 for sipping@ietf.org; Tue, 08 Jul 2003 14:12:16 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19Zwwo-00045e-00 for sipping@ietf.org; Tue, 08 Jul 2003 14:12:15 -0400 Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h68IBhiB005745 for ; Tue, 8 Jul 2003 14:11:44 -0400 (EDT) Message-ID: <3F0B095A.7050205@dynamicsoft.com> Date: Tue, 08 Jul 2003 14:11: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: sipping Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Update to conferencing package Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 Folks, You may have noticed that I submitted an update to the conferencing event package. This draft hasnt been touched for a while, since we were waiting for the conferencing design team to get farther along. We are at the point were it was appropriate to rev the document based on the current conferencing story. You can grab the draft at: http://www.ietf.org/internet-drafts/draft-ietf-sipping-conference-package-01.txt http://www.jdrosen.net/papers/draft-ietf-sipping-conference-package-01.txt http://www.jdrosen.net/papers/draft-ietf-sipping-conference-package-01.html Some of the changes in the spec are: * the XML format has information now that allows you to discover the conference policy and media policy protocols. It is done with a new element that contains a URI and a service type. * there are a bunch of new event header parameters that allow you to ask for specific subsets of the conference state, such as membership status, dialog information, conf-service information, etc. You'll only get notified when that subset changes. You can ask for more than one subset in a subscription by using a comma separated list of the parameters. * There used to be a bunch of information about who was receiving your media. That has all been removed, and will instead be handled by an extension to the package to cover the media policy states. * registered the schema The open issues are: * do we really want to learn the URIS for the other conference services (media and conference policy control) through a package? The information never changes, really. * the format for the conference service stuff really depends on the protocols we select. For example, if xcap is used, you need to include an AUID, whereas thats not used for other protocols. As such, its not clear we can include conference service information in the XML until that work is more solid. If the aim is to have the conferencing package proceed in sipping independent of xcon, this could be a problem. * The media streams information in the notifications indicates which media streams the user is connected to. This is also dependent on the media policy work in xcon. Its not clear that any media information can be present in this package without introducing a dependency on the xcon work. Comments or inputs on these issues are 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 From exim@www1.ietf.org Tue Jul 8 14:28: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 OAA03171 for ; Tue, 8 Jul 2003 14:28: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 19ZxCG-0002zF-O2 for sipping-archive@odin.ietf.org; Tue, 08 Jul 2003 14:28:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68ISCEP011476 for sipping-archive@odin.ietf.org; Tue, 8 Jul 2003 14:28:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZxCG-0002z1-LE for sipping-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 14: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 OAA03145 for ; Tue, 8 Jul 2003 14:28:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZxCE-0004MA-00 for sipping-web-archive@ietf.org; Tue, 08 Jul 2003 14:28:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZxCD-0004M7-00 for sipping-web-archive@ietf.org; Tue, 08 Jul 2003 14: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 19ZxC5-0002xy-HP; Tue, 08 Jul 2003 14: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 19ZxBb-0002xI-QP for sipping@optimus.ietf.org; Tue, 08 Jul 2003 14:27: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 OAA03120 for ; Tue, 8 Jul 2003 14:27:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZxBZ-0004LX-00 for sipping@ietf.org; Tue, 08 Jul 2003 14:27:29 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ZxBX-0004LB-00 for sipping@ietf.org; Tue, 08 Jul 2003 14:27:28 -0400 Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h68IQwiB005770 for ; Tue, 8 Jul 2003 14:26:58 -0400 (EDT) Message-ID: <3F0B0CED.7090603@dynamicsoft.com> Date: Tue, 08 Jul 2003 14:26:53 -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: sipping Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Update to dialog package Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 Folks, You may have noticed that I submitted an update to the dialog event package: http://www.jdrosen.net/papers/draft-ietf-sipping-dialog-package-02.txt http://www.jdrosen.net/papers/draft-ietf-sipping-dialog-package-02.html http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialog-package-02.txt The following changes were made between this and the previous version: * state agents are now allowed * checked the schema against the Schema Quality Checker (SQC) and fixed some problems. One of them is, AFAICT, there is no way to define a new type which is a restriction of string by enumeration, but which can also have attributes. As a result, the type definition for the state element does not enumerate the contents of the element. They are restricted by the spec, not by the schema. * Registered the schema with IANA * minor typos and clarifications suggested in comments during wglc Really, the only open issue is whether we want to include some additional information, like the stuff suggested in Sean's draft, into the main dialog package, or not. I don't really have a strong opinion on it. On the one hand, it would be nice to declare this finished and move on. On the other hand, why bother having two documents when we know we want both capabilities anyway? Comments and thoughts 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 From exim@www1.ietf.org Tue Jul 8 14:59: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 OAA04617 for ; Tue, 8 Jul 2003 14:59: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 19ZxgQ-0005XW-2a for sipping-archive@odin.ietf.org; Tue, 08 Jul 2003 14:59:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68IxM5C021292 for sipping-archive@odin.ietf.org; Tue, 8 Jul 2003 14:59:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZxgP-0005XL-Us for sipping-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 14:59: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 OAA04581 for ; Tue, 8 Jul 2003 14:59:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZxgN-0004p9-00 for sipping-web-archive@ietf.org; Tue, 08 Jul 2003 14:59:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZxgM-0004p6-00 for sipping-web-archive@ietf.org; Tue, 08 Jul 2003 14:59:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zxg5-0005UM-Kr; Tue, 08 Jul 2003 14:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZxfZ-0005Tm-EH for sipping@optimus.ietf.org; Tue, 08 Jul 2003 14:58: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 OAA04536 for ; Tue, 8 Jul 2003 14:58:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZxfW-0004o5-00 for sipping@ietf.org; Tue, 08 Jul 2003 14:58:26 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ZxfU-0004nT-00 for sipping@ietf.org; Tue, 08 Jul 2003 14:58:25 -0400 Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h68IvriB005787 for ; Tue, 8 Jul 2003 14:57:53 -0400 (EDT) Message-ID: <3F0B142C.5080700@dynamicsoft.com> Date: Tue, 08 Jul 2003 14:57:48 -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: sipping Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Update to ICE Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 Folks, You may have noticed that I submitted an update to the ICE spec: http://www.jdrosen.net/papers/draft-rosenberg-sipping-ice-01.txt http://www.jdrosen.net/papers/draft-rosenberg-sipping-ice-01.html http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-ice-01.txt A bunch of things changed in this revision: 1. Based on comments during the SF IETF, I worked on backwards compatibility. ICE is now backwards compatible with non-ICE clients. No Require or Proxy-Require is needed. No additional round trips of signaling are consumed. To do that, I am no longer using the ALT semantic for the SDP grouping framework. Instead, each media stream has one m line. There are any number of a=alt attributes within that stream, which provide alternate points of contact. So, if an ICE client calls a non-ICE client, they end up communicating using the address that the caller placed in the m and c lines. The spec now recommends that this be the address that is most likely to work, usually a TURN allocated address. 2. Construcing an answer is a lot simpler. It used to be that, because the number of m-lines in an offer and answer had to be the same, creating the answer was hard. You had to split it up over multiple cycles. Yuck. Now, the answer just contains as many "alt" attributes as is necessary. This avoids additional ICE cycles which used to be required. 3. an optimization has been added to avoid additional ice cycles. If a peer learns about new transport addresses, it only initiates a new offer if that address is higher priority than any other one that the peer has already connected to. 4. During the San Fran IETF, I proposed to deprecate the existing nat-scenarios document in favor of one which showed a single solution - ICE - in all configurations. The response was that I would need to show what that would look like before a decision could be made. Well, the -01 draft contains almost 50 pages of detailed call flows for each scenario. Residential, enterprise, and centrex configurations are shown. The flows in all cases are all the same basic ICE flows over and over, but with differing results based on the conditions. The good news is, as expected, ICE works well in each of those configurations and does the optimal thing in each, using the same single client algorithm described in the spec. 5. Removed the suggested q-values for the various addresses. Now, only the basic ordering is suggested. This is in line with the ordinal nature of q-values. 6. In a few places, a UA needs to know when its peer "connects" to a particular transport address. In -00, it was suggested that this is known when media arrives on that transport address. However, that doesnt work. A UA can't tell, when receiving media, whether it was sent TO the TURN derived or STUN derived address. As a result, this determination is now made based on the receipt of peer-to-peer STUN requests. The username and password within the STUN request can be used to disambiguate the transport address to which it was sent. 7. Partial alignment with a new revision of TURN. That new revision (which I'll comment on in a separate note), introduces a MORE-AVAILABLE feature, the aim of which is to allow a TURN server to allocate multiple bindings on a single request. The ICE draft assumes this works differently than the TURN spec does. There are a few open issues: 1. How exactly does a UA determine the "address that is most likely to work?" when populating the m and c lines in an offer? I found that, in the enterprise case, when the TURN server lives within the enterprise, there was no one single address. The enterprise case actually has two TURN addresses that get used. One is the private address, reachable from within the enterprise, and the other is the public address, reachable from outside. The right "default" depends on who you are calling. Of course, if the peer supports ICE, there is no need to choose a default, and the one which works best is discovered. 2. I suspect some enterprises may forbid outbound UDP traffic that doesnt come from some server in the DMZ. If that is the case, ICE will actually work well when you have a call between an enterprise with this restriction, and some other user without it (such as a residential user). You'll end up getting media sent in/out of the enterprise through its TURN server. But, in the case of an enterprise to enterprise call, both sides will block outbound UDP from end devices to each other's TURN servers, and so nothing works. What is the easiest way to fix this? I have some ideas on adding a feature to TURN to support this, similar to the way, in MSRP, you can use an outbound proxy to send messages. The other main issue is that status of this work. Is there interest in making this a working item of sipping? There was support for that at the last IETF (the minutes showed a hum of favor of adopting), but I think it was lukewarm. I am hoping that this rev addresses some of the concerns from last round. If there is support, I would propose that: 1. The behavioral parts of ice become a sipping BCP item, 2. The precondition stuff get pursued as a separate sip item, 3. The examples become an informational document, replacing draft-ietf-sipping-nat-scenarios, 4. the SDP extensions get worked in mmusic Comments and 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 From exim@www1.ietf.org Tue Jul 8 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 PAA05358 for ; Tue, 8 Jul 2003 15:07: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 19Zxnw-0006Ua-2B for sipping-archive@odin.ietf.org; Tue, 08 Jul 2003 15:07:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68J78mv024941 for sipping-archive@odin.ietf.org; Tue, 8 Jul 2003 15:07:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zxnv-0006U1-UD for sipping-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 15:07: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 PAA05275 for ; Tue, 8 Jul 2003 15:07:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zxnt-0004wW-00 for sipping-web-archive@ietf.org; Tue, 08 Jul 2003 15:07:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Zxns-0004wT-00 for sipping-web-archive@ietf.org; Tue, 08 Jul 2003 15:07:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zxnq-0006OM-3T; Tue, 08 Jul 2003 15:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZxnM-0006NI-DA for sipping@optimus.ietf.org; Tue, 08 Jul 2003 15:06: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 PAA05205; Tue, 8 Jul 2003 15:06:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZxnJ-0004vu-00; Tue, 08 Jul 2003 15:06:29 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ZxnH-0004vI-00; Tue, 08 Jul 2003 15:06:28 -0400 Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h68J60iB005794; Tue, 8 Jul 2003 15:06:00 -0400 (EDT) Message-ID: <3F0B1613.603@dynamicsoft.com> Date: Tue, 08 Jul 2003 15:05:55 -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: sipping CC: Midcom Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Update to TURN Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 Folks, I submitted an update to TURN. I havent seen it announced, but you can pick it up at: http://www.jdrosen.net/papers/draft-rosenberg-midcom-turn-02.txt http://www.jdrosen.net/papers/draft-rosenberg-midcom-turn-02.html There was only one change between this revision and the previous. The change is that I added a "MORE-AVAILABLE" attribute. The idea here is that in some cases, like enterprise, the TURN server is not on the public Internet. It may, in fact, have multiple addresses in different realms. In an enterprise, it would have a private address and also the public address on the public side of the enterprise NAT. So, when a client sends an allocate reuqest, the server really needs to provide it TWO bindings - one on its public address, and another on its private. In this rev, the server can do that. When an Allocate Request arrives from the client, it allocates one address, pre-allocates the others, and informs the client, using the MORE-AVAILABLE attribute, that others have been pre-allocated. The client then issues additional Allocate Requests, asking for the pre-allocated addresses in the TRANSPORT-PREFERENCES attribute. Comments and 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 From exim@www1.ietf.org Tue Jul 8 15:36: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 PAA07095 for ; Tue, 8 Jul 2003 15:36: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 19ZyG5-0008HR-3R for sipping-archive@odin.ietf.org; Tue, 08 Jul 2003 15:36:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68JaDsu031824 for sipping-archive@odin.ietf.org; Tue, 8 Jul 2003 15:36:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZyG5-0008HD-0A for sipping-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 15:36: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 PAA07045 for ; Tue, 8 Jul 2003 15:36:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZyG3-0005Gv-00 for sipping-web-archive@ietf.org; Tue, 08 Jul 2003 15:36:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZyG3-0005Gs-00 for sipping-web-archive@ietf.org; Tue, 08 Jul 2003 15:36:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZyFt-0008F8-RY; Tue, 08 Jul 2003 15: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 19ZyFq-0008El-T8 for sipping@optimus.ietf.org; Tue, 08 Jul 2003 15:35: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 PAA06985 for ; Tue, 8 Jul 2003 15:35:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZyFp-0005Ga-00 for sipping@ietf.org; Tue, 08 Jul 2003 15:35:57 -0400 Received: from radvmail.radvision.com ([12.44.63.10] helo=radvpost.radvision.com) by ietf-mx with esmtp (Exim 4.12) id 19ZyFo-0005GR-00 for sipping@ietf.org; Tue, 08 Jul 2003 15:35:56 -0400 Received: from radvpost.radvision.com [192.168.216.29] by radvpost.radvision.com with XWall v3.26 ; Tue, 8 Jul 2003 15:34:31 -0400 Received: by radvpost.RADVISION.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jul 2003 15:34:31 -0400 Message-ID: From: Orit Levin To: "'Jonathan Rosenberg'" , sipping Subject: RE: [Sipping] Update to conferencing package Date: Tue, 8 Jul 2003 15:34:30 -0400 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: , Hi Jonathan! Some comments: 1. The package doesn't contain information (or a placeholder for potential information) about conference's side-bars as agreed by the conferencing design team. 2. May be it is better to define the default subscription lifetime as the conference lifetime rather than a default of one hour. The rest of my comments are inline. Thanks, Orit. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, July 08, 2003 2:12 PM > To: sipping > Subject: [Sipping] Update to conferencing package > > Folks, > > You may have noticed that I submitted an update to the conferencing > event package. This draft hasnt been touched for a while, since we > were waiting for the conferencing design team to get farther along. We > are at the point were it was appropriate to rev the document based on > the current conferencing story. > > You can grab the draft at: > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-conference-package- > 01.txt > http://www.jdrosen.net/papers/draft-ietf-sipping-conference-package-01.txt > http://www.jdrosen.net/papers/draft-ietf-sipping-conference-package- > 01.html > > Some of the changes in the spec are: > > * the XML format has information now that allows you to discover the > conference policy and media policy protocols. It is done with a new > element that contains a URI and a service type. > > * there are a bunch of new event header parameters that allow you to > ask for specific subsets of the conference state, such as membership > status, dialog information, conf-service information, etc. You'll only > get notified when that subset changes. You can ask for more than one > subset in a subscription by using a comma separated list of the > parameters. I like the "User Element" concept because it conveys user's "conference status" vs. dialog status. It is also important to distinguish between a specific user that has "dialed in" the conference or has been "dialed out" by the focus. From the same "conceptual" (i.e. conference vs. dialog) reason as above, I suggest that the conferencing package will contain only a list of dialog identifiers allowed to be known/published instead of carrying the dialogs' information itself. Once a dialog identifier is known, an interested (and allowed) party can register and retrieve the dialog information using the dialog package(s) using the dialog package(s) parameters and policies. Otherwise (from pure technical reason) we will have the burden to define "what the change of the dialog state means to the change in a conference state", etc. > > * There used to be a bunch of information about who was receiving your > media. That has all been removed, and will instead be handled by an > extension to the package to cover the media policy states. > > * registered the schema > > The open issues are: > > * do we really want to learn the URIS for the other conference > services (media and conference policy control) through a package? The > information never changes, really. This information is compact - therefore, I don't think it is a big issue. Do we have additional or different means to retrieve this information (if different from default)? > > * the format for the conference service stuff really depends on the > protocols we select. For example, if xcap is used, you need to include > an AUID, whereas thats not used for other protocols. As such, its not > clear we can include conference service information in the XML until > that work is more solid. If the aim is to have the conferencing > package proceed in sipping independent of xcon, this could be a problem. I agree that we need to provide an array of general "service placeholders" (a REGISTERED service id and a single pointer or token). Each service can be defined later by out-of-SIPPING groups. > > * The media streams information in the notifications indicates which > media streams the user is connected to. This is also dependent on the > media policy work in xcon. Its not clear that any media information > can be present in this package without introducing a dependency on the > xcon work. > In my opinion, no media information should be defined in basic conferencing package: Any dialog media information should be retrieved using the dialog package(s). Any conferencing media information (i.e. mixing, switching, layouts ...) should be defined by MPCP/XCON and its services with their future corresponding packages. > > Comments or inputs on these issues are 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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 8 23:32: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 XAA20472 for ; Tue, 8 Jul 2003 23:32: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 19a5gh-0006Fw-Aq for sipping-archive@odin.ietf.org; Tue, 08 Jul 2003 23:32:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h693WB78024042 for sipping-archive@odin.ietf.org; Tue, 8 Jul 2003 23:32:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a5gh-0006Fe-7D for sipping-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 23:32: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 XAA20458 for ; Tue, 8 Jul 2003 23:32:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a5gf-0003AE-00 for sipping-web-archive@ietf.org; Tue, 08 Jul 2003 23:32:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19a5ge-0003AB-00 for sipping-web-archive@ietf.org; Tue, 08 Jul 2003 23: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 19a5gX-0006Ej-TM; Tue, 08 Jul 2003 23: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 19a5gK-0006EU-2w for sipping@optimus.ietf.org; Tue, 08 Jul 2003 23:31:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20454 for ; Tue, 8 Jul 2003 23:31:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a5gI-0003A3-00 for sipping@ietf.org; Tue, 08 Jul 2003 23:31:46 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx with esmtp (Exim 4.12) id 19a5gH-00039o-00 for sipping@ietf.org; Tue, 08 Jul 2003 23:31:45 -0400 Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h693V8C01559; Wed, 9 Jul 2003 03:31:08 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jul 2003 23:32:12 -0400 Message-ID: <0449D80A0E9B614A83FA9031B07E8D3B257C8A@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Sean Olson'" , Jonathan Rosenberg , sipping Subject: RE: [Sipping] Update to 3pcc Date: Tue, 8 Jul 2003 23:32:11 -0400 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 agree that this is something that should be fixed with explicit semantics in future versions of SDP. But I hope that the .invalid approach won't give rise to serious interoperability concerns. Can any implementers speak to what would happen if a domain name given in the c= line of SDP could not be resolved? I imagine that it's unlikely to lead to any media being sent, but is there a further concern that the SIP session would be terminated unceremoniously, or something like that? Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Sean Olson [mailto:seancolson@yahoo.com] > Sent: Tuesday, July 08, 2003 9:05 PM > To: Jonathan Rosenberg; sipping > Subject: Re: [Sipping] Update to 3pcc > > > This is a huge interop issue. Is .invalid to be the > recommendation going forward or is this a stopgap > measure? Hopefully SDPng addresses this more directly. > > --- 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. > > > __________________________________ > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! > http://sbc.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 Wed Jul 9 00:58: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 AAA22130 for ; Wed, 9 Jul 2003 00:58: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 19a71q-0004IM-IP for sipping-archive@odin.ietf.org; Wed, 09 Jul 2003 00:58:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h694w6ZI016504 for sipping-archive@odin.ietf.org; Wed, 9 Jul 2003 00:58:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a71q-0004I7-Et for sipping-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 00: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 AAA22122 for ; Wed, 9 Jul 2003 00:58:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a71n-0003WT-00 for sipping-web-archive@ietf.org; Wed, 09 Jul 2003 00:58:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19a71n-0003WQ-00 for sipping-web-archive@ietf.org; Wed, 09 Jul 2003 00:58:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a71l-0004HE-5q; Wed, 09 Jul 2003 00: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 19a71X-0004Ey-Io for sipping@optimus.ietf.org; Wed, 09 Jul 2003 00:57: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 AAA22107 for ; Wed, 9 Jul 2003 00:57:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a71U-0003W9-00 for sipping@ietf.org; Wed, 09 Jul 2003 00:57:44 -0400 Received: from smtp012.mail.yahoo.com ([216.136.173.32]) by ietf-mx with smtp (Exim 4.12) id 19a71U-0003W6-00 for sipping@ietf.org; Wed, 09 Jul 2003 00:57:44 -0400 Received: from 12-235-146-159.client.attbi.com (HELO cranberry) (seancolson@12.235.146.159 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 9 Jul 2003 04:57:44 -0000 Reply-To: From: "Sean Olson" To: "'Peterson, Jon'" , "'Jonathan Rosenberg'" , "'sipping'" Subject: RE: [Sipping] Update to 3pcc Date: Tue, 8 Jul 2003 21:57:54 -0700 Message-ID: <000801c345d6$a957fe60$6801a8c0@cranberry> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <0449D80A0E9B614A83FA9031B07E8D3B257C8A@stntexch2.va.neustar.com> Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It is likely that the session would be terminated. Badness. -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Tuesday, July 08, 2003 8:32 PM To: 'Sean Olson'; Jonathan Rosenberg; sipping Subject: RE: [Sipping] Update to 3pcc I agree that this is something that should be fixed with explicit semantics in future versions of SDP. But I hope that the .invalid approach won't give rise to serious interoperability concerns. Can any implementers speak to what would happen if a domain name given in the c= line of SDP could not be resolved? I imagine that it's unlikely to lead to any media being sent, but is there a further concern that the SIP session would be terminated unceremoniously, or something like that? Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Sean Olson [mailto:seancolson@yahoo.com] > Sent: Tuesday, July 08, 2003 9:05 PM > To: Jonathan Rosenberg; sipping > Subject: Re: [Sipping] Update to 3pcc > > > This is a huge interop issue. Is .invalid to be the recommendation > going forward or is this a stopgap measure? Hopefully SDPng addresses > this more directly. > > --- 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. > > > __________________________________ > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.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 Wed Jul 9 02:54: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 CAA20619 for ; Wed, 9 Jul 2003 02:54: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 19a8q7-0006qk-PP for sipping-archive@odin.ietf.org; Wed, 09 Jul 2003 02:54:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h696s7iP026326 for sipping-archive@odin.ietf.org; Wed, 9 Jul 2003 02:54:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a8q7-0006qX-Fa for sipping-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 02:54: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 CAA20554 for ; Wed, 9 Jul 2003 02:54:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a8q3-00049B-00 for sipping-web-archive@ietf.org; Wed, 09 Jul 2003 02:54:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19a8q3-000498-00 for sipping-web-archive@ietf.org; Wed, 09 Jul 2003 02:54:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a8q2-0006i9-BK; Wed, 09 Jul 2003 02:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a8pA-0006ag-Gj for sipping@optimus.ietf.org; Wed, 09 Jul 2003 02:53: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 CAA20508 for ; Wed, 9 Jul 2003 02:53:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a8p6-00048D-00 for sipping@ietf.org; Wed, 09 Jul 2003 02:53:04 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19a8p5-00048A-00 for sipping@ietf.org; Wed, 09 Jul 2003 02:53:04 -0400 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h696r3Ii023963; Wed, 9 Jul 2003 08:53:03 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id NW4VV2X5; Wed, 9 Jul 2003 08:53:02 +0200 Message-ID: <3F0BBBCA.7040803@ericsson.com> Date: Wed, 09 Jul 2003 08:52:58 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sean Olson CC: sipping Subject: Re: [Sipping] Update to 3pcc - SDPNG issue References: <20030708180527.29780.qmail@web41504.mail.yahoo.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 Hi, Sean Sean Olson wrote: > This is a huge interop issue. Is .invalid to be the > recommendation going forward or is this a stopgap > measure? Hopefully SDPng addresses this more directly. > Have you communicated this need to the SDPng authors? The main issue with SDPng is the lack of interest and review. I think they would appreciate the feedback. And the list to discuss SDPng is MMUSIC's. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.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 Jul 9 03: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 DAA21165 for ; Wed, 9 Jul 2003 03:12: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 19a97T-0000rn-3z for sipping-archive@odin.ietf.org; Wed, 09 Jul 2003 03:12:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h697C3xD003325 for sipping-archive@odin.ietf.org; Wed, 9 Jul 2003 03:12:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a97S-0000rX-WA for sipping-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 03:12: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 DAA21106 for ; Wed, 9 Jul 2003 03:12:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a97Q-0004HG-00 for sipping-web-archive@ietf.org; Wed, 09 Jul 2003 03:12:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19a97Q-0004HD-00 for sipping-web-archive@ietf.org; Wed, 09 Jul 2003 03:12:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a97R-0000q0-LL; Wed, 09 Jul 2003 03: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 19YdYe-0001g6-Tk for sipping@optimus.ietf.org; Fri, 04 Jul 2003 23:17: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 XAA16128; Fri, 4 Jul 2003 23:17:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YdYd-0005pf-00; Fri, 04 Jul 2003 23:17:51 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19YdYc-0005pQ-00; Fri, 04 Jul 2003 23:17:50 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 05 Jul 2003 05:17:35 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h653FFkF028009; Sat, 5 Jul 2003 05:15:15 +0200 (MET DST) Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 5 Jul 2003 05:17:19 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 5 Jul 2003 05:17:19 +0200 Date: Sat, 5 Jul 2003 05:17:13 +0200 Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'Stastny Richard'" , "Shockey, Richard" , enum@ietf.org, "'sipping@ietf.org'" To: "Peterson, Jon" From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <0449D80A0E9B614A83FA9031B07E8D3B257C68@stntexch2.va.neustar.com> Message-Id: <2C53CF10-AE97-11D7-BE0E-000A959CF516@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 05 Jul 2003 03:17:19.0487 (UTC) FILETIME=[F17958F0:01C342A3] 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 fredag, jul 4, 2003, at 20:05 Europe/Stockholm, Peterson, Jon wrote: > You'll note that the example from RFC2916 that showed a wildcard > has not been repeated in rfc2916bis. The old example showed a record > set for > 6.4.e164.arpa, and the antecedent of the regexp contained > "!^+46(.*)$!". You can have something like this (I think, straight from my head): 1.2.3.4.e164.arpa. IN CNAME 4.e164.arpa. 2.2.3.4.e164.arpa. IN CNAME 4.e164.arpa. 3.2.3.4.e164.arpa. IN CNAME 4.e164.arpa. 4.e164.arpa. IN NAPTR .... "!^+4(.*)$!sip:9876\1@example.com!" paf _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 9 03: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 DAA21166 for ; Wed, 9 Jul 2003 03:12: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 19a97S-0000r7-LT for sipping-archive@odin.ietf.org; Wed, 09 Jul 2003 03:12:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h697C2Lo003288 for sipping-archive@odin.ietf.org; Wed, 9 Jul 2003 03:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a97S-0000qv-C2 for sipping-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 03:12: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 DAA21103 for ; Wed, 9 Jul 2003 03:12:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a97Q-0004HC-00 for sipping-web-archive@ietf.org; Wed, 09 Jul 2003 03:12:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19a97P-0004H9-00 for sipping-web-archive@ietf.org; Wed, 09 Jul 2003 03:11:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a97Q-0000p2-Ix; Wed, 09 Jul 2003 03:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YdVz-0001J3-TK for sipping@optimus.ietf.org; Fri, 04 Jul 2003 23:15: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 XAA16012; Fri, 4 Jul 2003 23:15:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YdVy-0005nw-00; Fri, 04 Jul 2003 23:15:06 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19YdVx-0005ng-00; Fri, 04 Jul 2003 23:15:05 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 05 Jul 2003 05:14:50 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h653B9PQ027747; Sat, 5 Jul 2003 05:12:30 +0200 (MET DST) Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 5 Jul 2003 05:14:13 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 5 Jul 2003 05:14:12 +0200 Date: Sat, 5 Jul 2003 05:14:06 +0200 Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'Stastny Richard'" , "Shockey, Richard" , enum@ietf.org, "'sipping@ietf.org'" To: "Peterson, Jon" From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <0449D80A0E9B614A83FA9031B07E8D3B257C68@stntexch2.va.neustar.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 05 Jul 2003 03:14:12.0688 (UTC) FILETIME=[82221500:01C342A3] 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 fredag, jul 4, 2003, at 20:05 Europe/Stockholm, Peterson, Jon wrote: > I agree this is an important issue. While I acknowledge that > "wildcards" are > possible according to the syntax, what's the use-case that motivates > wildcards for ENUM? Because support for wildcards is a MUST when you implement the NAPTR record, which ENUM inherits from the DDDS application. If you don't implement it, you loose. You don't have a DDDS compliant implementation. So, I don't understand why you do this recommendation. What is it supposed to help wit, as implementations still have to implement the regexp according to the NAPTR specification. paf _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 9 03:12: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 DAA21195 for ; Wed, 9 Jul 2003 03:12: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 19a97V-0000u3-IK for sipping-archive@odin.ietf.org; Wed, 09 Jul 2003 03:12:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h697C5Q1003465 for sipping-archive@odin.ietf.org; Wed, 9 Jul 2003 03: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 19a97V-0000to-DN for sipping-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 03: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 DAA21115 for ; Wed, 9 Jul 2003 03:12:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a97T-0004HS-00 for sipping-web-archive@ietf.org; Wed, 09 Jul 2003 03:12:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19a97S-0004HL-00 for sipping-web-archive@ietf.org; Wed, 09 Jul 2003 03:12:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a97T-0000rt-Nc; Wed, 09 Jul 2003 03:12:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Z13b-0004cM-PB for sipping@optimus.ietf.org; Sun, 06 Jul 2003 00: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 AAA24191; Sun, 6 Jul 2003 00:23:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Z13Z-0007ce-00; Sun, 06 Jul 2003 00:23:21 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19Z13Y-0007cb-00; Sun, 06 Jul 2003 00:23:20 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 06 Jul 2003 06:23:03 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h664KjO6009990; Sun, 6 Jul 2003 06:20:45 +0200 (MET DST) Received: from xfe-ams-312.cisco.com ([144.254.228.205]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 6 Jul 2003 06:22:49 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 6 Jul 2003 06:22:49 +0200 Date: Sun, 6 Jul 2003 06:22:46 +0200 Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'Stastny Richard'" , "Shockey, Richard" , enum@ietf.org, "'sipping@ietf.org'" To: "Peterson, Jon" From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <0449D80A0E9B614A83FA9031B07E8D3B257C72@stntexch2.va.neustar.com> Message-Id: <7EDE6628-AF69-11D7-BE0E-000A959CF516@cisco.com> Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 06 Jul 2003 04:22:49.0496 (UTC) FILETIME=[425AE180:01C34376] 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 On s=F6ndag, jul 6, 2003, at 02:24 Europe/Stockholm, Peterson, Jon = wrote: >> Because support for wildcards is a MUST when you implement the NAPTR >> record, which ENUM inherits from the DDDS application. If you don't >> implement it, you loose. You don't have a DDDS compliant >> implementation. > > I'm not suggesting that clients refuse to process records with more=20 > complex > regexp antecedents if they happen to receive them - this is in a=20 > section of > advice for authors of NAPTR records, not a specification of resolver > behavior. Nothing (I hope) in our document breaks DDDS or RFC2916bis > compliance in any way. Why should they ignore it? They still have to _implement_ it. > [from another mail] >> You can have something like this (I think, straight from my head): >> >> 1.2.3.4.e164.arpa. IN CNAME 4.e164.arpa. >> 2.2.3.4.e164.arpa. IN CNAME 4.e164.arpa. >> 3.2.3.4.e164.arpa. IN CNAME 4.e164.arpa. >> >> 4.e164.arpa. IN NAPTR .... "!^+4(.*)$!sip:9876\1@example.com!" > > I had thought that the reason that the reason such examples were=20 > removed > from rfc2916bis is that we wanted to pass over this issue of partial=20= > E.164 > numbers in silence. No, the example was removed because it contained a wildcard in DNS. > The restriction in the sipping-e164 document basically > reinforces this (at a RECOMMENDED level, not as a mandatory=20 > statement), but > given that this seems to be a controversial matter, perhaps it would=20= > be best > if we passed over this in silence in the SIPPING document as well. > > Wildcarding is, I agree, a separable issue. But I guess I am also a=20 > little > unclear, given the example above, how delegation from 4.e164.arpa to=20= > the > subdomains works - would there be additional records under 4.e164.arpa > besides that NAPTR that indicate delegation? Many of the partial = number > cases (including the one Martin showed us) do entail some wildcarding, > anyway. This has _nothing_ to do with partial numbers. Let's then change the example to: 1.2.3.4.e164.arpa. IN CNAME foo.bar.example.com. 2.2.3.4.e164.arpa. IN CNAME foo.bar.example.com. 3.2.3.4.e164.arpa. IN CNAME foo.bar.example.com. foo.bar.example.com. IN NAPTR ....=20 "!^+4(.*)$!sip:9876\1@anotherexample.net!" paf _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 9 03:12: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 DAA21212 for ; Wed, 9 Jul 2003 03:12: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 19a97Y-000136-2Q for sipping-archive@odin.ietf.org; Wed, 09 Jul 2003 03:12:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h697C7oN004029 for sipping-archive@odin.ietf.org; Wed, 9 Jul 2003 03: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 19a97X-00010Y-Kx for sipping-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 03:12: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 DAA21122 for ; Wed, 9 Jul 2003 03:12:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a97U-0004Ha-00 for sipping-web-archive@ietf.org; Wed, 09 Jul 2003 03:12:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19a97U-0004HX-00 for sipping-web-archive@ietf.org; Wed, 09 Jul 2003 03: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 19a97U-0000tU-RO; Wed, 09 Jul 2003 03:12:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Z9Ah-0004w8-2X for sipping@optimus.ietf.org; Sun, 06 Jul 2003 09:03: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 JAA12429; Sun, 6 Jul 2003 09:03:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Z9Af-0001y2-00; Sun, 06 Jul 2003 09:03:13 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19Z9Ae-0001xT-00; Sun, 06 Jul 2003 09:03:12 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 06 Jul 2003 15:02:51 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h66D0VT4014216; Sun, 6 Jul 2003 15:00:33 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 6 Jul 2003 15:01:43 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 6 Jul 2003 15:01:43 +0200 Date: Sun, 6 Jul 2003 15:01:42 +0200 Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Content-Type: text/plain; delsp=yes; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: enum@ietf.org, sipping@ietf.org To: Marian Durkovic From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20030706104240.A47655@us.svf.stuba.sk> Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 06 Jul 2003 13:01:43.0475 (UTC) FILETIME=[BFA71030:01C343BE] 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 Can we please keep the discussions about the wildcard in DNS separate =20= from the regular expression in NAPTR as separate as possible? paf On s=F6ndag, jul 6, 2003, at 10:42 Europe/Stockholm, Marian Durkovic =20 wrote: >> Major problem: 5.3 >> "Authors of >> records intended to be used for SIP applications SHOULD always use = =20 >> a >> greedy regexp; no use-cases have been identified today in which a >> different antecedent is necessary." >> >> I strongly object this. >> First, the use of regular expessions is a feature in ENUM and DDDS, >> second, there are use cases (e.g. in wildcards) and >> third, if there is no-use cases, why is are regular >> expression there in >> the first place? > > Hi all, > > we're heavily using the wildcards in Slovak ENUM trial for pointing = =20 > all the > numbers behind a PBX to the VoIP gateway attached to this PBX. Here is = =20 > the > example: > > the PBX prefix +421-55555-xxx (number not real) > > The DNS: > > $ORIGIN 5.5.5.5.5.1.2.4.e164.arpa. > * IN NAPTR 100 10 "u" "E2U+sip" =20 > "!^\\+42155555(.*)$!sip:1\\1@foo.sk!" . > > Thus when one calls +421-55555-777 the above rule replaces it with > sip:1777@foo.sk > > I really refuse to put 1000 NAPTR records into DNS just to get the =20= > same > functionality. If someone wants to arrange things in a different way, > the exact NAPTR record can still be put into DNS and it overrides the > wildcard one. > > I've seen similar examples in Swedish ENUM trial, so I fully support = =20 > the > objection against the requirement for greedy regexpr. > > > With kind regards, > > M. > > = -----------------------------------------------------------------------=20= > --- > ---- =20= > ---- > ---- Marian Durkovic network manager =20= > ---- > ---- =20= > ---- > ---- Slovak Technical University Tel: +421 2 524 51 301 =20= > ---- > ---- Computer Centre, Nam. Slobody 17 Fax: +421 2 524 94 351 =20= > ---- > ---- 812 43 Bratislava, Slovak Republic E-mail: md@bts.sk =20= > ---- > ---- =20= > ---- > = -----------------------------------------------------------------------=20= > --- > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 9 03:12: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 DAA21230 for ; Wed, 9 Jul 2003 03:12: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 19a97c-00015L-MV for sipping-archive@odin.ietf.org; Wed, 09 Jul 2003 03:12:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h697CCLe004148 for sipping-archive@odin.ietf.org; Wed, 9 Jul 2003 03:12:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a97c-00014m-DW for sipping-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 03:12: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 DAA21118 for ; Wed, 9 Jul 2003 03:12:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a97T-0004HR-00 for sipping-web-archive@ietf.org; Wed, 09 Jul 2003 03:12:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19a97S-0004HM-00 for sipping-web-archive@ietf.org; Wed, 09 Jul 2003 03:12:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a97S-0000rD-Pb; Wed, 09 Jul 2003 03:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YlZV-0003y6-Lq for sipping@optimus.ietf.org; Sat, 05 Jul 2003 07: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 HAA05885; Sat, 5 Jul 2003 07:51:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YlZU-0000cl-00; Sat, 05 Jul 2003 07:51:16 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19YlZU-0000ch-00; Sat, 05 Jul 2003 07:51:16 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 05 Jul 2003 13:50:59 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h65BmdjZ000439; Sat, 5 Jul 2003 13:48:39 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 5 Jul 2003 13:50:43 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 5 Jul 2003 13:50:43 +0200 Date: Sat, 5 Jul 2003 13:50:37 +0200 Subject: Re: AW: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Peterson, Jon" , , "Shockey, Richard" , , To: "Stastny Richard" From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <06CF906FE3998C4E944213062009F162233712@oefeg-s02.oefeg.loc> Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 05 Jul 2003 11:50:43.0448 (UTC) FILETIME=[AA10C780:01C342EB] 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 On l=F6rdag, jul 5, 2003, at 12:08 Europe/Stockholm, Stastny Richard=20 wrote: > I have to admit that also within our trails there are two = schools of=20 > thought: One proposing the use of wildcards and regexp for this, the=20= > others (mostly DNS people having an horror of wildcards) are proposing=20= > just to generate zone entries for each full number. Don't mix up using wildcard in DNS with the regular expression issues.=20= They are two different issues, and should be kept separate. That's why=20= I gave an example without the wildcard in DNS. paf _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 9 03:39: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 DAA22397 for ; Wed, 9 Jul 2003 03: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 19a9Xe-0006AG-NK for sipping-archive@odin.ietf.org; Wed, 09 Jul 2003 03:39:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h697d6I4023689 for sipping-archive@odin.ietf.org; Wed, 9 Jul 2003 03:39:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a97w-0001Dz-Pw for sipping-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 03:12: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 DAA21144 for ; Wed, 9 Jul 2003 03:12:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a97k-0004IG-00 for sipping-web-archive@ietf.org; Wed, 09 Jul 2003 03:12:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19a97d-0004I0-00 for sipping-web-archive@ietf.org; Wed, 09 Jul 2003 03:12:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a97X-00012v-V1; Wed, 09 Jul 2003 03:12:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZCR5-0002OH-5W for sipping@optimus.ietf.org; Sun, 06 Jul 2003 12:32: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 MAA16732; Sun, 6 Jul 2003 12:32:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZCR3-0003RB-00; Sun, 06 Jul 2003 12:32:21 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19ZCR2-0003R0-00; Sun, 06 Jul 2003 12:32:21 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 06 Jul 2003 18:32:02 +0200 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h66GTivJ028000; Sun, 6 Jul 2003 18:29:45 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 6 Jul 2003 18:31:49 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 6 Jul 2003 18:31:49 +0200 Date: Sun, 6 Jul 2003 18:31:48 +0200 Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: enum@ietf.org, sipping@ietf.org To: Marian Durkovic From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20030706181004.A51884@us.svf.stuba.sk> Message-Id: <56D1CF00-AFCF-11D7-BE0E-000A959CF516@cisco.com> Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 06 Jul 2003 16:31:49.0201 (UTC) FILETIME=[19403410:01C343DC] 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 On s=F6ndag, jul 6, 2003, at 18:10 Europe/Stockholm, Marian Durkovic=20 wrote: > On Sun, Jul 06, 2003 at 03:01:42PM +0200, Patrik F=E4ltstr=F6m wrote: >> Can we please keep the discussions about the wildcard in DNS separate >> from the regular expression in NAPTR as separate as possible? > > I don't think this is fully possible. If you want to use wildcard in=20= > DNS, > you must use non-greedy regular expression with a subpattern ( ) to=20 > extract > and reuse the digits matched by the wildcard: > > $ORIGIN 5.5.5.5.5.1.2.4.e164.arpa. > * IN NAPTR 100 10 "u" "E2U+sip" =20 > "!^\\+42155555(.*)$!sip:1\\1@foo.sk!" . Yes, you are absolutely correct. And one can say dependencies exists in=20= the other direction as well. BUT, today I still see a large number of arguments (especially when=20 looking at DNSSEC) from a pure DNS perspective to _not_ use wildcards=20 in DNS. My point is that that is not enough as an argument for removing the=20 regular expression in the NAPTR for ENUM. It is needed anyway, and I=20 gave an example. You say you don't want a million NAPTR records in your DNS server, and=20= I can understand that given the most common provisioning mechanisms=20 which exists. The IETF do though concentrate on what goes on the wire between hosts,=20= and not so much of how things are inside the host itself. I.e. you might have some DNS software that you can configure given some=20= kind of wildcard, BUT, it will not be a wildcard from a DNS=20 perspective. That is a very very big difference. The wildcard in DNS=20 have many side effects -- most of them today felt being negative. paf _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 9 03:39: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 DAA22412 for ; Wed, 9 Jul 2003 03:39: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 19a9Xf-0006Aq-2q for sipping-archive@odin.ietf.org; Wed, 09 Jul 2003 03:39:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h697d7bs023725 for sipping-archive@odin.ietf.org; Wed, 9 Jul 2003 03:39:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a9Ej-0003Xh-Iw for sipping-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 03:19: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 DAA21556 for ; Wed, 9 Jul 2003 03:18:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a9E1-0004T5-00 for sipping-web-archive@ietf.org; Wed, 09 Jul 2003 03:18:49 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19a9E1-0004T2-00 for sipping-web-archive@ietf.org; Wed, 09 Jul 2003 03:18:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a9AF-0002IK-9j; Wed, 09 Jul 2003 03:14:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zwzy-0002Ik-J6 for sipping@optimus.ietf.org; Tue, 08 Jul 2003 14:15: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 OAA02632 for ; Tue, 8 Jul 2003 14:15:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zwzw-00049n-00 for sipping@ietf.org; Tue, 08 Jul 2003 14:15:28 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19Zwzu-00048k-00 for sipping@ietf.org; Tue, 08 Jul 2003 14:15:27 -0400 Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h68IENiB005748; Tue, 8 Jul 2003 14:14:24 -0400 (EDT) Message-ID: <3F0B09FB.40807@dynamicsoft.com> Date: Tue, 08 Jul 2003 14:14:19 -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: Paul Kyzivat , Michael Hammer , seancolson@yahoo.com, "'Rosen, Brian'" , hisham.khartabil@nokia.com, jason@azatel.com, drage@lucent.com, alan.johnston@wcom.com, sipping@ietf.org Subject: Re: [Sipping] proposed enhancement to dialog package 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: >> There are certainly other "states" of a telephony-like application >> residing on SIP. "Muted" has also been discussed in this thread. >> Generally, muted is a purely local operation, and doesnt manifest >> itself within SIP signaling in any way. >> >> As such, I dont think the dialog package is the right place for this >> information. Its much closer to presence, in fact. Indeed, Jon and I >> recently submitted an I-D that proposed a bunch of PIDF extensions to >> reflect status of phones, including application-level type of state: >> >> http://www.ietf.org/internet-drafts/draft-rosenberg-peterson-simple- >> pidf-phone-00.txt > > > i don't buy it. Its hard to respond to something like that without some kind of substantiation. Can you elaborate on why you don't buy 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 Jul 9 04:01:20 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 EAA23186 for ; Wed, 9 Jul 2003 04:01:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a9si-00078h-GW for sipping-archive@odin.ietf.org; Wed, 09 Jul 2003 04:00:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6980qpl027442 for sipping-archive@odin.ietf.org; Wed, 9 Jul 2003 04:00:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a9si-00078X-9M for sipping-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 04:00: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 DAA21424 for ; Wed, 9 Jul 2003 03:15:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a9Az-0004Nm-00 for sipping-web-archive@ietf.org; Wed, 09 Jul 2003 03:15:41 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19a9Aw-0004Ni-00 for sipping-web-archive@ietf.org; Wed, 09 Jul 2003 03:15:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a9A8-0002FP-Tm; Wed, 09 Jul 2003 03:14:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZoSh-0006n6-VG for sipping@optimus.ietf.org; Tue, 08 Jul 2003 05:08: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 FAA15233; Tue, 8 Jul 2003 05:08:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZoSe-00003k-00; Tue, 08 Jul 2003 05:08:32 -0400 Received: from shell.nominum.com ([128.177.192.160]) by ietf-mx with esmtp (Exim 4.12) id 19ZoSe-00002q-00; Tue, 08 Jul 2003 05:08:32 -0400 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 76130137F0D; Tue, 8 Jul 2003 02:08:02 -0700 (PDT) To: Marian Durkovic Cc: enum@ietf.org, sipping@ietf.org Subject: Re: AW: AW: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt In-Reply-To: Message from Marian Durkovic of "Tue, 08 Jul 2003 08:41:42 +0200." <20030708084142.A91895@us.svf.stuba.sk> Date: Tue, 08 Jul 2003 02:08:02 -0700 Message-ID: <20561.1057655282@shell.nominum.com> From: Jim Reid Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , >>>>> "Marian" == Marian Durkovic writes: Marian> The approach of having one record per every PBX extension Marian> is perhaps usable in trials, but it does not scale. Our Marian> institutions typically have 3-digit extensions, the larger Marian> ones 4-digit extensions. Having this in mind you can Marian> easily find yourself in the situation, where e.g. 300 Marian> customers generate as much as 1 million records. If Marian> there's 1 million records in top-level domain, you have 1 Marian> milion customers to cover the costs. But what will be the Marian> cost per customer, if the number of customers is 300 ? I don't understand the point you're trying to make here. You seem to be saying something "won't scale" for 300 names but somehow scales just fine for 1 million names. I'm confused. And you've still to explain why provisioning NAPTRs for each number -- something you said was trivial -- couldn't be done and why a wildcard RR was the only possible solution to the problem you're trying to solve. Despite what you said earlier, this still looks to me that the wildcard has been suggested as a kludge to work around a provisioning problem. And a straightforward one at that. Marian> The approach with wildcards generates only 300 records per Marian> 300 customers. This is huge difference certainly worth Marian> inverstigating. It has even bigger implications which you don't seem to appreciate. You've not given any convincing explanation why a wildcard RR is the only solution and why alternatives are not viable. Please provide that explanation. >> Patrik Faltstrom wrote: The only place they are used is when >> the MX record refer to a gateway (to X.400 or UUCP) where the >> other side of the gateway is managing a number of (sub-) >> domains, and it is impossible to point all these domains in DNS >> with individual MX records to the media gateway. Marian> You hit the nail. We need to do similar thing - redirect Marian> all voice traffic to a VoIP gateway connected to PBX with Marian> many many extensions. Well this is a perfect example of why DNS wildcards provide the wrong answer to the wrong question. You're assuming that the only use of ENUM for some range of numbers would be to contact a VoIP gateway. This cannot be guaranteed. What happens when the owners of (some of) those numbers want additional NAPTRs for other services? What if they *don't* want to use this default VoIP gateway? Or can't use it. What happens with numbers that are not in service? Should applications which look these up be pointed at the VoIP gateway regardless? That's what you'd get with a wildcard. Maybe it would be better to get an NXDOMAIN response from the DNS. Which of course you can't get if there's a wildcard RR. The same goes for numbers that are invalid because they don't have the correct number of digits. What if some of the active numbers must not be used for VoIP because they're bound to things like a fax machine or a modem? What if you need to introduce additional VoIP gateways for some or all of the numbers? BTW, what you're proposing is NOT similar to the scenario Patrik outlined at all. You're talking about a known, well-defined, if large, name space: a range of telephone numbers. It is possible to enumerate all the domain names that exist there. In fact, it's trivial. In the scenario Patrik explains the wildcard MX record covers a name space that is not known and cannot be enumerated because it is somewhat unstructured and dynamic. >> Michael Haberler wrote: Or do you propose to have a wildcard in >> the zone, and have the server interpret it differently - i.e >> giving a matching non-wildcard response? Marian> This is how wildcards work _now_ with standard DNS - they Marian> are internal to the host running the DNS daemon. The Marian> end-user's resolver has no way to tell, if the response is Marian> based on wildcard or exact record, since the response is Marian> formulated as exact match in both cases. We can certaintly Marian> improve the default wildcard behaviour with more Marian> sophisticated record synthesizing, in order to get rid of Marian> common problems with classic wildcards, Sorry, you can't change the semantics of DNS wildcarding without a wholesale protocol rewrite. And somehow keeping backwards compatibility with the installed base. Please show how you intend to do this. For bonus points, get the DNS WGs to adopt your proposal. :-) Marian> but I think we really need the capability for one-to-many Marian> conversion in ENUM DNS. I've not seen any justification for this so far though I accept it might be useful. Perhaps you could provide some examples? _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 9 05: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 FAA25395 for ; Wed, 9 Jul 2003 05: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 19aBIz-0003Df-2V for sipping-archive@odin.ietf.org; Wed, 09 Jul 2003 05:32:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h699W51Z012369 for sipping-archive@odin.ietf.org; Wed, 9 Jul 2003 05:32:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aBIy-0003DQ-Uw for sipping-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 05:32: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 FAA25374 for ; Wed, 9 Jul 2003 05:32:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aBIv-0005Rv-00 for sipping-web-archive@ietf.org; Wed, 09 Jul 2003 05:32:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aBIv-0005Rs-00 for sipping-web-archive@ietf.org; Wed, 09 Jul 2003 05: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 19aBIv-0003CR-2u; Wed, 09 Jul 2003 05: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 19aBI6-0003Bq-Mk for sipping@optimus.ietf.org; Wed, 09 Jul 2003 05:31: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 FAA25359 for ; Wed, 9 Jul 2003 05:31:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aBI3-0005Rf-00 for sipping@ietf.org; Wed, 09 Jul 2003 05:31:07 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19aBI2-0005RW-00 for sipping@ietf.org; Wed, 09 Jul 2003 05:31:06 -0400 Received: from dynamicsoft.com ([63.113.46.9]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h699UgiB006268; Wed, 9 Jul 2003 05:30:42 -0400 (EDT) Message-ID: <3F0BE0BC.8070403@dynamicsoft.com> Date: Wed, 09 Jul 2003 05:30:36 -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: seancolson@yahoo.com CC: "'Peterson, Jon'" , "'sipping'" Subject: Re: [Sipping] Update to 3pcc References: <000801c345d6$a957fe60$6801a8c0@cranberry> In-Reply-To: <000801c345d6$a957fe60$6801a8c0@cranberry> 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 Yes, definitely badness. We already have had a lot of interop issues with 3pcc, because lots of folks don't support things like INVITEs w/o SDP, even though its mandatory in 3261. This would add another problem to the mix. One could argue that, as a BCP, it is not the place of the specification to mandate UA behavior that differs from existing, standards track behavior (RFC 3264). The whole premise of 3pcc is that it should work with any rfc3261 compliant UA. Now, we are saying that a UA would need to explicitly support this new "3pcc feature" to work. How about this alternate approach: 1. 3pcc goes back to using 0.0.0.0 2. We write a separate I-D, which updates rfc3264, saying to use .invalid. We also add an option tag for it, so we can figure out if its understood. That would go through as a standards track document in sip, presumably. It would be short, just a few pages. With (2) in place, 3pcc could make use of .invalid, and couple it with Require as necessary to make sure backwards compatibility is addressed. I don't know whether this approach would be acceptable to IESG. Jon or Allison, comments? Thanks, Jonathan R. Sean Olson wrote: > It is likely that the session would be terminated. Badness. > > > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Tuesday, July 08, 2003 8:32 PM > To: 'Sean Olson'; Jonathan Rosenberg; sipping > Subject: RE: [Sipping] Update to 3pcc > > > > I agree that this is something that should be fixed with explicit semantics > in future versions of SDP. But I hope that the .invalid approach won't give > rise to serious interoperability concerns. Can any implementers speak to > what would happen if a domain name given in the c= line of SDP could not be > resolved? I imagine that it's unlikely to lead to any media being sent, but > is there a further concern that the SIP session would be terminated > unceremoniously, or something like that? > > Jon Peterson > NeuStar, Inc. > > >>-----Original Message----- >>From: Sean Olson [mailto:seancolson@yahoo.com] >>Sent: Tuesday, July 08, 2003 9:05 PM >>To: Jonathan Rosenberg; sipping >>Subject: Re: [Sipping] Update to 3pcc >> >> >>This is a huge interop issue. Is .invalid to be the recommendation >>going forward or is this a stopgap measure? Hopefully SDPng addresses >>this more directly. >> >>--- 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. >> >> >>__________________________________ >>Do you Yahoo!? >>SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.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 >> > > -- 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 Jul 9 06:58:49 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 GAA27258 for ; Wed, 9 Jul 2003 06:58: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 19aCeV-0002Mk-Jo for sipping-archive@odin.ietf.org; Wed, 09 Jul 2003 06:58:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69AwNoF009091 for sipping-archive@odin.ietf.org; Wed, 9 Jul 2003 06:58:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aCeV-0002MY-Gy for sipping-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 06: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 GAA27167 for ; Wed, 9 Jul 2003 06:58:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aCeQ-0005sO-00 for sipping-web-archive@ietf.org; Wed, 09 Jul 2003 06:58:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aCeQ-0005rg-00 for sipping-web-archive@ietf.org; Wed, 09 Jul 2003 06:58:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aCeF-0002Gc-5l; Wed, 09 Jul 2003 06: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 19aCNH-000124-Py for sipping@optimus.ietf.org; Wed, 09 Jul 2003 06:40: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 GAA26828 for ; Wed, 9 Jul 2003 06:40:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aCNB-0005l8-00 for sipping@ietf.org; Wed, 09 Jul 2003 06:40:29 -0400 Received: from beamer.mchh.siemens.de ([194.138.158.163]) by ietf-mx with esmtp (Exim 4.12) id 19aCNA-0005l3-00 for sipping@ietf.org; Wed, 09 Jul 2003 06:40:28 -0400 Received: from moody.mchh.siemens.de ([139.21.205.85]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id MAA04283 for ; Wed, 9 Jul 2003 12:40:24 +0200 (MET DST) Received: from mchh273e.demchh201e.icn.siemens.de (mchh273e.mchh.siemens.de [139.21.200.83]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id MAA14057 for ; Wed, 9 Jul 2003 12:40:23 +0200 (MET DST) Received: by mchh273e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Wed, 9 Jul 2003 12:39:51 +0200 Message-ID: <931A17FBB884D411B02B0008C70D9E2ABF1307@mchh243e.mchh.siemens.de> From: Stupka Jean-Marie To: "'sipping@ietf.org'" Date: Wed, 9 Jul 2003 12:39:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Sipping] Question on INVITE Initiated Dialog Event Package and Automatic C allback Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 All, As said in RFC 3265 it is possible to create an event subscription within a pre-existing dialog, e.g. a dialog created by an INVITE. In my understanding, this is the intention of draft-ietf-sipping-dialog-package-02.txt. According to the (PSTN) Automatic Callback given as example application in the introduction of this draft, user A can request a callback when user B hangs-up. User A off course needs to get the information that user B is busy before requesting the automatic callback, i.e. receive a "486 Busy Here" message. However, all early dialogs are considered terminated upon reception of a non-2xx final response (13.2.2.3 of RFC 3261). As consequence, the dialog and thus the data of the preceding call attempt are no more available and the callback cannot be requested. Can somebody provide clarification of the applicability of RFC 3265 and the draft-ietf-sipping-dialog-package-02.txt to Automatic Callback? Regards, Jean-Marie _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 9 07:45: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 GAA27259 for ; Wed, 9 Jul 2003 06:58: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 19aCeV-0002MV-DD for sipping-archive@odin.ietf.org; Wed, 09 Jul 2003 06:58:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69AwNOK009075 for sipping-archive@odin.ietf.org; Wed, 9 Jul 2003 06:58:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aCeV-0002MI-A7 for sipping-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 06: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 GAA27166 for ; Wed, 9 Jul 2003 06:58:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aCeQ-0005sR-00 for sipping-web-archive@ietf.org; Wed, 09 Jul 2003 06:58:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aCeQ-0005rh-00 for sipping-web-archive@ietf.org; Wed, 09 Jul 2003 06:58:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aCeB-0002DS-PY; Wed, 09 Jul 2003 06:58:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aC3J-0007AY-5a for sipping@optimus.ietf.org; Wed, 09 Jul 2003 06:19: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 GAA26352 for ; Wed, 9 Jul 2003 06:19:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aC3F-0005fP-00 for sipping@ietf.org; Wed, 09 Jul 2003 06:19:53 -0400 Received: from us.svf.stuba.sk ([147.175.16.9]) by ietf-mx with esmtp (Exim 4.12) id 19aC3E-0005fD-00 for sipping@ietf.org; Wed, 09 Jul 2003 06:19:52 -0400 Received: from us.svf.stuba.sk (localhost [127.0.0.1]) by us.svf.stuba.sk (8.12.9/8.12.9) with ESMTP id h69AJYb2037260; Wed, 9 Jul 2003 12:19:34 +0200 (CEST) (envelope-from md@us.svf.stuba.sk) Received: (from md@localhost) by us.svf.stuba.sk (8.12.9/8.12.9/Submit) id h69AJTm8037259; Wed, 9 Jul 2003 12:19:29 +0200 (CEST) Date: Wed, 9 Jul 2003 12:19:29 +0200 From: Marian Durkovic To: Jonathan Rosenberg Cc: "'sipping'" Subject: Re: [Sipping] Update to 3pcc Message-ID: <20030709121929.A36306@us.svf.stuba.sk> References: <000801c345d6$a957fe60$6801a8c0@cranberry> <3F0BE0BC.8070403@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F0BE0BC.8070403@dynamicsoft.com>; from jdrosen@dynamicsoft.com on Wed, Jul 09, 2003 at 05:30:36AM -0400 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , On Wed, Jul 09, 2003 at 05:30:36AM -0400, Jonathan Rosenberg wrote: > Yes, definitely badness. We already have had a lot of interop issues > with 3pcc, because lots of folks don't support things like INVITEs w/o > SDP, even though its mandatory in 3261. This would add another problem > to the mix. In my opinion, the definition for non-existing address should be available also for numeric representation, which is prefferably used in SDP. I don't see any problem with 0.0.0.0, since RFC1700 says this is only valid as _source_ address, while the c= line denotes where to send media - i.e. the _destination_ address. Thus seeing 0.0.0.0 as destination address can be safely considered invalid. With kind regards, M. > > One could argue that, as a BCP, it is not the place of the > specification to mandate UA behavior that differs from existing, > standards track behavior (RFC 3264). The whole premise of 3pcc is that > it should work with any rfc3261 compliant UA. Now, we are saying that > a UA would need to explicitly support this new "3pcc feature" to work. > > How about this alternate approach: > > 1. 3pcc goes back to using 0.0.0.0 > 2. We write a separate I-D, which updates rfc3264, saying to use > .invalid. We also add an option tag for it, so we can figure out if > its understood. That would go through as a standards track document in > sip, presumably. It would be short, just a few pages. > > With (2) in place, 3pcc could make use of .invalid, and couple it with > Require as necessary to make sure backwards compatibility is addressed. > > I don't know whether this approach would be acceptable to IESG. Jon or > Allison, comments? > > Thanks, > Jonathan R. > > > > > Sean Olson wrote: > > > It is likely that the session would be terminated. Badness. > > > > > > -----Original Message----- > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > > Sent: Tuesday, July 08, 2003 8:32 PM > > To: 'Sean Olson'; Jonathan Rosenberg; sipping > > Subject: RE: [Sipping] Update to 3pcc > > > > > > > > I agree that this is something that should be fixed with explicit semantics > > in future versions of SDP. But I hope that the .invalid approach won't give > > rise to serious interoperability concerns. Can any implementers speak to > > what would happen if a domain name given in the c= line of SDP could not be > > resolved? I imagine that it's unlikely to lead to any media being sent, but > > is there a further concern that the SIP session would be terminated > > unceremoniously, or something like that? > > > > Jon Peterson > > NeuStar, Inc. > > > > > >>-----Original Message----- > >>From: Sean Olson [mailto:seancolson@yahoo.com] > >>Sent: Tuesday, July 08, 2003 9:05 PM > >>To: Jonathan Rosenberg; sipping > >>Subject: Re: [Sipping] Update to 3pcc > >> > >> > >>This is a huge interop issue. Is .invalid to be the recommendation > >>going forward or is this a stopgap measure? Hopefully SDPng addresses > >>this more directly. > >> > >>--- 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. > >> > >> > >>__________________________________ > >>Do you Yahoo!? > >>SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.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 > >> > > > > > > -- > 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 -------------------------------------------------------------------------- ---- ---- ---- Marian Durkovic network manager ---- ---- ---- ---- Slovak Technical University Tel: +421 2 524 51 301 ---- ---- Computer Centre, Nam. Slobody 17 Fax: +421 2 524 94 351 ---- ---- 812 43 Bratislava, Slovak Republic E-mail: md@bts.sk ---- ---- ---- -------------------------------------------------------------------------- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 9 13:34:15 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 NAA11414 for ; Wed, 9 Jul 2003 13:34: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 19aIpA-0006Qg-RJ for sipping-archive@odin.ietf.org; Wed, 09 Jul 2003 13:33:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69HXmS1024712 for sipping-archive@odin.ietf.org; Wed, 9 Jul 2003 13:33:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aIpA-0006QV-Me for sipping-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 13:33:48 -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 NAA11369 for ; Wed, 9 Jul 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 19aIoP-0006PG-LV; Wed, 09 Jul 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 19aIoC-0006Ot-G0 for sipping@optimus.ietf.org; Wed, 09 Jul 2003 13:32:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11336 for ; Wed, 9 Jul 2003 13:32:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aIoA-00016n-00 for sipping@ietf.org; Wed, 09 Jul 2003 13:32:46 -0400 Received: from web41505.mail.yahoo.com ([66.218.93.88]) by ietf-mx with smtp (Exim 4.12) id 19aIo9-00016d-00 for sipping@ietf.org; Wed, 09 Jul 2003 13:32:45 -0400 Message-ID: <20030709173214.26964.qmail@web41505.mail.yahoo.com> Received: from [131.107.3.86] by web41505.mail.yahoo.com via HTTP; Wed, 09 Jul 2003 10:32:14 PDT Date: Wed, 9 Jul 2003 10:32:14 -0700 (PDT) From: Sean Olson Subject: Re: [Sipping] Update to 3pcc To: Jonathan Rosenberg Cc: "'Peterson, Jon'" , "'sipping'" In-Reply-To: <3F0BE0BC.8070403@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: , This sounds like a very sensible approach to me, but of course the decision lies with Jon/Allison. --- Jonathan Rosenberg wrote: > Yes, definitely badness. We already have had a lot > of interop issues > with 3pcc, because lots of folks don't support > things like INVITEs w/o > SDP, even though its mandatory in 3261. This would > add another problem > to the mix. > > One could argue that, as a BCP, it is not the place > of the > specification to mandate UA behavior that differs > from existing, > standards track behavior (RFC 3264). The whole > premise of 3pcc is that > it should work with any rfc3261 compliant UA. Now, > we are saying that > a UA would need to explicitly support this new > "3pcc feature" to work. > > How about this alternate approach: > > 1. 3pcc goes back to using 0.0.0.0 > 2. We write a separate I-D, which updates rfc3264, > saying to use > .invalid. We also add an option tag for it, so we > can figure out if > its understood. That would go through as a standards > track document in > sip, presumably. It would be short, just a few > pages. > > With (2) in place, 3pcc could make use of .invalid, > and couple it with > Require as necessary to make sure backwards > compatibility is addressed. > > I don't know whether this approach would be > acceptable to IESG. Jon or > Allison, comments? > > Thanks, > Jonathan R. > > > > > Sean Olson wrote: > > > It is likely that the session would be terminated. > Badness. > > > > > > -----Original Message----- > > From: Peterson, Jon > [mailto:jon.peterson@neustar.biz] > > Sent: Tuesday, July 08, 2003 8:32 PM > > To: 'Sean Olson'; Jonathan Rosenberg; sipping > > Subject: RE: [Sipping] Update to 3pcc > > > > > > > > I agree that this is something that should be > fixed with explicit semantics > > in future versions of SDP. But I hope that the > .invalid approach won't give > > rise to serious interoperability concerns. Can any > implementers speak to > > what would happen if a domain name given in the c= > line of SDP could not be > > resolved? I imagine that it's unlikely to lead to > any media being sent, but > > is there a further concern that the SIP session > would be terminated > > unceremoniously, or something like that? > > > > Jon Peterson > > NeuStar, Inc. > > > > > >>-----Original Message----- > >>From: Sean Olson [mailto:seancolson@yahoo.com] > >>Sent: Tuesday, July 08, 2003 9:05 PM > >>To: Jonathan Rosenberg; sipping > >>Subject: Re: [Sipping] Update to 3pcc > >> > >> > >>This is a huge interop issue. Is .invalid to be > the recommendation > >>going forward or is this a stopgap measure? > Hopefully SDPng addresses > >>this more directly. > >> > >>--- 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. > >> > >> > >>__________________________________ > >>Do you Yahoo!? > >>SBC Yahoo! DSL - Now only $29.95 per month! > http://sbc.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 > >> > > > > > > -- > 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 > __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.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 Wed Jul 9 14:48: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 OAA13963 for ; Wed, 9 Jul 2003 14:48: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 19aJz3-0002aG-To for sipping-archive@odin.ietf.org; Wed, 09 Jul 2003 14:48:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69Im5Sn009926 for sipping-archive@odin.ietf.org; Wed, 9 Jul 2003 14:48:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aJz3-0002a1-Qq for sipping-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 14:48: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 OAA13895 for ; Wed, 9 Jul 2003 14:48:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aJz1-0001mO-00 for sipping-web-archive@ietf.org; Wed, 09 Jul 2003 14:48:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aJz0-0001mK-00 for sipping-web-archive@ietf.org; Wed, 09 Jul 2003 14:48:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aJyz-0002YM-4C; Wed, 09 Jul 2003 14: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 19aJyu-0002Xr-FV for sipping@optimus.ietf.org; Wed, 09 Jul 2003 14:47: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 OAA13870 for ; Wed, 9 Jul 2003 14:47:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aJyr-0001lw-00 for sipping@ietf.org; Wed, 09 Jul 2003 14:47:53 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19aJyq-0001lt-00 for sipping@ietf.org; Wed, 09 Jul 2003 14:47:53 -0400 Received: from localhost ([127.0.0.1] helo=psg.com ident=mankin) by psg.com with esmtp (Exim 4.14) id 19aJyn-0006To-Nb; Wed, 09 Jul 2003 18:47:49 +0000 To: Sean Olson cc: Jonathan Rosenberg , "'Peterson, Jon'" , "'sipping'" Subject: Re: [Sipping] Update to 3pcc In-Reply-To: Message from Sean Olson of "Wed, 09 Jul 2003 10:32:14 PDT." <20030709173214.26964.qmail@web41505.mail.yahoo.com> Date: Wed, 09 Jul 2003 11:47:49 -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: , The mistake was in only recommending not to send 0.0.0.0 in RFC 3264, but not developing the .invalid tld alternative at the time. Ah, well. Crashing sessions is not an option. Jonathan's proposal sounds like the way to go, but it should caveat 0.0.0.0 with a brief description of drawbacks of it (such as RFC 3264 has), and the fact that future work will allow upgrade to an alternative. Allison > > This sounds like a very sensible approach to me, but > of course the decision lies with Jon/Allison. > > --- Jonathan Rosenberg > wrote: > > Yes, definitely badness. We already have had a lot > > of interop issues > > with 3pcc, because lots of folks don't support > > things like INVITEs w/o > > SDP, even though its mandatory in 3261. This would > > add another problem > > to the mix. > > > > One could argue that, as a BCP, it is not the place > > of the > > specification to mandate UA behavior that differs > > from existing, > > standards track behavior (RFC 3264). The whole > > premise of 3pcc is that > > it should work with any rfc3261 compliant UA. Now, > > we are saying that > > a UA would need to explicitly support this new > > "3pcc feature" to work. > > > > How about this alternate approach: > > > > 1. 3pcc goes back to using 0.0.0.0 > > 2. We write a separate I-D, which updates rfc3264, > > saying to use > > .invalid. We also add an option tag for it, so we > > can figure out if > > its understood. That would go through as a standards > > track document in > > sip, presumably. It would be short, just a few > > pages. > > > > With (2) in place, 3pcc could make use of .invalid, > > and couple it with > > Require as necessary to make sure backwards > > compatibility is addressed. > > > > I don't know whether this approach would be > > acceptable to IESG. Jon or > > Allison, comments? > > > > Thanks, > > Jonathan R. > > > > > > > > > > Sean Olson wrote: > > > > > It is likely that the session would be terminated. > > Badness. > > > > > > > > > -----Original Message----- > > > From: Peterson, Jon > > [mailto:jon.peterson@neustar.biz] > > > Sent: Tuesday, July 08, 2003 8:32 PM > > > To: 'Sean Olson'; Jonathan Rosenberg; sipping > > > Subject: RE: [Sipping] Update to 3pcc > > > > > > > > > > > > I agree that this is something that should be > > fixed with explicit semantics > > > in future versions of SDP. But I hope that the > > .invalid approach won't give > > > rise to serious interoperability concerns. Can any > > implementers speak to > > > what would happen if a domain name given in the c= > > line of SDP could not be > > > resolved? I imagine that it's unlikely to lead to > > any media being sent, but > > > is there a further concern that the SIP session > > would be terminated > > > unceremoniously, or something like that? > > > > > > Jon Peterson > > > NeuStar, 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 Wed Jul 9 16:44:11 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 QAA21081 for ; Wed, 9 Jul 2003 16:44:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aLmy-0002be-0t for sipping-archive@odin.ietf.org; Wed, 09 Jul 2003 16:43:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69KhiZu010014 for sipping-archive@odin.ietf.org; Wed, 9 Jul 2003 16:43:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aLmx-0002bR-SD for sipping-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 16:43: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 QAA21061 for ; Wed, 9 Jul 2003 16:43:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aLmv-0003CE-00 for sipping-web-archive@ietf.org; Wed, 09 Jul 2003 16:43:42 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aLmv-0003CA-00 for sipping-web-archive@ietf.org; Wed, 09 Jul 2003 16:43:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aLmI-0002MF-9M; Wed, 09 Jul 2003 16: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 19aLlY-0002J7-CI for sipping@optimus.ietf.org; Wed, 09 Jul 2003 16:42: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 QAA20971; Wed, 9 Jul 2003 16:42:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aLlW-0003An-00; Wed, 09 Jul 2003 16:42:14 -0400 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx with esmtp (Exim 4.12) id 19aLlU-0003AW-00; Wed, 09 Jul 2003 16:42:13 -0400 Received: by fox.iptel.org (Postfix, from userid 103) id 6C73C686; Wed, 9 Jul 2003 22:39:48 +0200 (CEST) Received: from jku07.iptel.org (port-212-202-40-87.reverse.qsc.de [212.202.40.87]) by fox.iptel.org (Postfix) with ESMTP id E211A683; Wed, 9 Jul 2003 22:39:47 +0200 (CEST) Message-Id: <5.2.0.9.0.20030709222843.0307c5f8@localhost> X-Sender: jiri@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 09 Jul 2003 22:38:11 +0200 To: sip@ietf.org, sipping@ietf.org From: Jiri Kuthan Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Subject: [Sipping] text conferencing at ietf57 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , FYI: there is a sip2jabber service that connects SIP users to jabber chat rooms in the upcoming IETF meeting. More information can be found at http://www.iptel.org/ietf54/ -jiri -- 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 Wed Jul 9 17:13:06 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 RAA22481 for ; Wed, 9 Jul 2003 17:13:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMEx-0005Xr-K1 for sipping-archive@odin.ietf.org; Wed, 09 Jul 2003 17:12:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69LCdUw021310 for sipping-archive@odin.ietf.org; Wed, 9 Jul 2003 17:12:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMEx-0005Xd-Dt for sipping-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 17: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 RAA22474 for ; Wed, 9 Jul 2003 17:12:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aMEv-0003Yn-00 for sipping-web-archive@ietf.org; Wed, 09 Jul 2003 17:12:37 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aMEu-0003Yk-00 for sipping-web-archive@ietf.org; Wed, 09 Jul 2003 17:12:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMEL-0005MF-59; Wed, 09 Jul 2003 17: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 19aMDh-0005Ld-Vv for sipping@optimus.ietf.org; Wed, 09 Jul 2003 17:11: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 RAA22444; Wed, 9 Jul 2003 17:11:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aMDf-0003Y4-00; Wed, 09 Jul 2003 17:11:19 -0400 Received: from mxsmta02.inithost.com ([209.235.30.104] helo=mxsmta02.dellhost.com) by ietf-mx with esmtp (Exim 4.12) id 19aMDe-0003Xv-00; Wed, 09 Jul 2003 17:11:18 -0400 Received: from garbagedump.com ([24.128.102.183]) by mxsmta02.dellhost.com (InterMail vM.5.01.03.06 201-253-122-118-106-20010523) with ESMTP id <20030709210916.MEGY7659.mxsmta02.dellhost.com@garbagedump.com>; Wed, 9 Jul 2003 17:09:16 -0400 Message-ID: <3F0C84FC.6070000@garbagedump.com> Date: Wed, 09 Jul 2003 17:11:24 -0400 From: "C. Wegrzyn" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a; MultiZilla v1.4.0.4A) Gecko/20030612 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jiri Kuthan CC: sip@ietf.org, sipping@ietf.org Subject: Re: [Sipping] text conferencing at ietf57 References: <5.2.0.9.0.20030709222843.0307c5f8@localhost> In-Reply-To: <5.2.0.9.0.20030709222843.0307c5f8@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I don't see anything at the provided URL. Chuck Wegrzyn Jiri Kuthan wrote: >FYI: there is a sip2jabber service that connects SIP users to jabber chat rooms >in the upcoming IETF meeting. More information can be found >at http://www.iptel.org/ietf54/ > >-jiri > >-- >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 > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 9 17:18: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 RAA22706 for ; Wed, 9 Jul 2003 17:18: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 19aMJm-0006Kp-Ji for sipping-archive@odin.ietf.org; Wed, 09 Jul 2003 17:17:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69LHcDa024345 for sipping-archive@odin.ietf.org; Wed, 9 Jul 2003 17:17:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMJm-0006Ka-Dw for sipping-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 17:17: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 RAA22672 for ; Wed, 9 Jul 2003 17:17:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aMJk-0003cf-00 for sipping-web-archive@ietf.org; Wed, 09 Jul 2003 17:17:36 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aMJj-0003cc-00 for sipping-web-archive@ietf.org; Wed, 09 Jul 2003 17:17:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMJB-0005zN-CC; Wed, 09 Jul 2003 17: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 19aMIG-0005ve-Mn for sipping@optimus.ietf.org; Wed, 09 Jul 2003 17:16: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 RAA22645; Wed, 9 Jul 2003 17:16:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aMIE-0003bb-00; Wed, 09 Jul 2003 17:16:02 -0400 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx with esmtp (Exim 4.12) id 19aMID-0003bY-00; Wed, 09 Jul 2003 17:16:01 -0400 Received: by fox.iptel.org (Postfix, from userid 103) id 3688C6B2; Wed, 9 Jul 2003 23:13:43 +0200 (CEST) Received: from jku07.iptel.org (port-212-202-40-87.reverse.qsc.de [212.202.40.87]) by fox.iptel.org (Postfix) with ESMTP id 9960A683; Wed, 9 Jul 2003 23:13:42 +0200 (CEST) Message-Id: <5.2.0.9.0.20030709231136.00b370d0@localhost> X-Sender: jiri@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 09 Jul 2003 23:12:05 +0200 To: sip@ietf.org, sipping@ietf.org From: Jiri Kuthan In-Reply-To: <5.2.0.9.0.20030709222843.0307c5f8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-1.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Subject: [Sipping] Re: text conferencing at ietf57 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 10:38 PM 7/9/2003, Jiri Kuthan wrote: >FYI: there is a sip2jabber service that connects SIP users to jabber chat rooms >in the upcoming IETF meeting. More information can be found >at http://www.iptel.org/ietf54/ typo: correct address is http://www.iptel.org/ietf57/ sorry, -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 Jul 10 04: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 EAA22777 for ; Thu, 10 Jul 2003 04:43: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 19aX1B-0003bj-TX for sipping-archive@odin.ietf.org; Thu, 10 Jul 2003 04:43:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6A8h9Xf013863 for sipping-archive@odin.ietf.org; Thu, 10 Jul 2003 04: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 19aX1A-0003bW-GE for sipping-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 04: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 EAA22770 for ; Thu, 10 Jul 2003 04:43:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aX17-0000du-00 for sipping-web-archive@ietf.org; Thu, 10 Jul 2003 04:43:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aX16-0000dr-00 for sipping-web-archive@ietf.org; Thu, 10 Jul 2003 04:43:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aX13-0003ad-8r; Thu, 10 Jul 2003 04: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 19aX0e-0003aA-Pk for sipping@optimus.ietf.org; Thu, 10 Jul 2003 04:42: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 EAA22759 for ; Thu, 10 Jul 2003 04:42:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aX0b-0000df-00 for sipping@ietf.org; Thu, 10 Jul 2003 04:42:33 -0400 Received: from mailgate.siemenscomms.co.uk ([194.129.217.115]) by ietf-mx with esmtp (Exim 4.12) id 19aX0a-0000dW-00 for sipping@ietf.org; Thu, 10 Jul 2003 04:42:32 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0HHS00D01W3B1Q@siemenscomms.co.uk> for sipping@ietf.org; Thu, 10 Jul 2003 09:40:39 +0100 (BST) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0HHS00CG4W2XXT@siemenscomms.co.uk> for sipping@ietf.org; Thu, 10 Jul 2003 09:40:09 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Jul 2003 09:40:52 +0100 Content-return: allowed Date: Thu, 10 Jul 2003 09:41:20 +0100 From: "Elwell, John" To: "'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_3LNmdtNRBxP/Z1kAH7DyPw)" Subject: [Sipping] Question on pick-up in service-examples-04 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_3LNmdtNRBxP/Z1kAH7DyPw) Content-type: text/plain Content-Transfer-Encoding: 7BIT 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) --Boundary_(ID_3LNmdtNRBxP/Z1kAH7DyPw) Content-type: text/html Content-Transfer-Encoding: 7BIT Question on pick-up in service-examples-04

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)

--Boundary_(ID_3LNmdtNRBxP/Z1kAH7DyPw)-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 10 08:48: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 IAA29566 for ; Thu, 10 Jul 2003 08:48: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 19aaqH-00049P-7m for sipping-archive@odin.ietf.org; Thu, 10 Jul 2003 08:48:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ACm9q6015948 for sipping-archive@odin.ietf.org; Thu, 10 Jul 2003 08:48:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aaqH-000498-3l for sipping-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 08:48: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 IAA29538 for ; Thu, 10 Jul 2003 08:48:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aaqF-0002SC-00 for sipping-web-archive@ietf.org; Thu, 10 Jul 2003 08:48:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aaqE-0002S8-00 for sipping-web-archive@ietf.org; Thu, 10 Jul 2003 08:48:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aaq9-000473-LT; Thu, 10 Jul 2003 08: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 19aapx-00046Y-UT for sipping@optimus.ietf.org; Thu, 10 Jul 2003 08:47: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 IAA29518 for ; Thu, 10 Jul 2003 08:47:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aapw-0002Ro-00 for sipping@ietf.org; Thu, 10 Jul 2003 08:47:48 -0400 Received: from mailgate.siemenscomms.co.uk ([194.129.217.115]) by ietf-mx with esmtp (Exim 4.12) id 19aapv-0002Rd-00 for sipping@ietf.org; Thu, 10 Jul 2003 08:47:47 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0HHT00J017HCQI@siemenscomms.co.uk> for sipping@ietf.org; Thu, 10 Jul 2003 13:46:24 +0100 (BST) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0HHT00J7N7GRNK@siemenscomms.co.uk> for sipping@ietf.org; Thu, 10 Jul 2003 13:46:03 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Jul 2003 13:46:46 +0100 Content-return: allowed Date: Thu, 10 Jul 2003 13:47:13 +0100 From: "Elwell, John" To: "'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_IjjfS6mdPASWKlBJSCIPqg)" Subject: [Sipping] draft-elwell-sipping-qsig-tunnel-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 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_IjjfS6mdPASWKlBJSCIPqg) Content-type: text/plain Content-Transfer-Encoding: 7BIT The following draft has been placed in the archives but I didn't see a notice on the list: http://www.ietf.org/internet-drafts/draft-elwell-sipping-qsig-tunnel-00.txt This documents procedures for tunnelling QSIG over SIP. There is already a MIME type defined for this in RFC3204, but procedures are not given. I would like to assess whether there is interest in adopting this as a SIPPING work item and producing an RFC. This may need to be standards track in view of the definition of a new option tag. John (john.elwell@siemens.com) --Boundary_(ID_IjjfS6mdPASWKlBJSCIPqg) Content-type: text/html Content-Transfer-Encoding: 7BIT draft-elwell-sipping-qsig-tunnel-00.txt

The following draft has been placed in the archives but I didn't see a notice on the list:

http://www.ietf.org/internet-drafts/draft-elwell-sipping-qsig-tunnel-00.txt

This documents procedures for tunnelling QSIG over SIP. There is already a MIME type defined for this in RFC3204, but procedures are not given. I would like to assess whether there is interest in adopting this as a SIPPING work item and producing an RFC. This may need to be standards track in view of the definition of a new option tag.

John (john.elwell@siemens.com)


--Boundary_(ID_IjjfS6mdPASWKlBJSCIPqg)-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 10 08:48: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 IAA29567 for ; Thu, 10 Jul 2003 08:48: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 19aaqH-00049d-9q for sipping-archive@odin.ietf.org; Thu, 10 Jul 2003 08:48:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ACm9O7015963 for sipping-archive@odin.ietf.org; Thu, 10 Jul 2003 08:48:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aaqH-000499-5W for sipping-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 08:48: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 IAA29540 for ; Thu, 10 Jul 2003 08:48:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aaqF-0002SF-00 for sipping-web-archive@ietf.org; Thu, 10 Jul 2003 08:48:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aaqE-0002S9-00 for sipping-web-archive@ietf.org; Thu, 10 Jul 2003 08:48:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aaqA-00047D-CY; Thu, 10 Jul 2003 08:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aaq2-00046e-Ng for sipping@optimus.ietf.org; Thu, 10 Jul 2003 08:47: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 IAA29522 for ; Thu, 10 Jul 2003 08:47:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aaq1-0002Ru-00 for sipping@ietf.org; Thu, 10 Jul 2003 08:47:53 -0400 Received: from mailgate.siemenscomms.co.uk ([194.129.217.115]) by ietf-mx with esmtp (Exim 4.12) id 19aaq0-0002Rj-00 for sipping@ietf.org; Thu, 10 Jul 2003 08:47:52 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0HHT00J017HPQR@siemenscomms.co.uk> for sipping@ietf.org; Thu, 10 Jul 2003 13:46:37 +0100 (BST) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0HHT00J8G7HNNK@siemenscomms.co.uk> for sipping@ietf.org; Thu, 10 Jul 2003 13:46:35 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Jul 2003 13:47:18 +0100 Content-return: allowed Date: Thu, 10 Jul 2003 13:47:45 +0100 From: "Elwell, John" To: "'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_WMeZ4jN4BJ4cJG752tPW5Q)" Subject: [Sipping] draft-elwell-sipping-qsig2sip-diversion-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 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_WMeZ4jN4BJ4cJG752tPW5Q) Content-type: text/plain Content-Transfer-Encoding: 7BIT The following draft has been placed in the archives but I didn't see a notice on the list: http://www.ietf.org/internet-drafts/draft-elwell-sipping-qsig2sip-diversion- 00.txt This expands on the topic of QSIG-SIP interworking by looking at interworking between call diversion in QSIG and the draft history information in SIP. I would like to assess whether there is interest in adopting this as a SIPPING work item and producing an informational RFC. John (john.elwell@siemens.com) --Boundary_(ID_WMeZ4jN4BJ4cJG752tPW5Q) Content-type: text/html Content-Transfer-Encoding: 7BIT draft-elwell-sipping-qsig2sip-diversion-00.txt

The following draft has been placed in the archives but I didn't see a notice on the list:

http://www.ietf.org/internet-drafts/draft-elwell-sipping-qsig2sip-diversion-00.txt

This expands on the topic of QSIG-SIP interworking by looking at interworking between call diversion in QSIG and the draft history information in SIP. I would like to assess whether there is interest in adopting this as a SIPPING work item and producing an informational RFC.

John (john.elwell@siemens.com)

--Boundary_(ID_WMeZ4jN4BJ4cJG752tPW5Q)-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 10 10:04:06 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 KAA02614 for ; Thu, 10 Jul 2003 10:04:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ac1M-000292-4u for sipping-archive@odin.ietf.org; Thu, 10 Jul 2003 10:03:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AE3eCw008238 for sipping-archive@odin.ietf.org; Thu, 10 Jul 2003 10:03:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ac1M-00028n-1q for sipping-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 10:03: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 KAA02539 for ; Thu, 10 Jul 2003 10:03:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ac1J-00037T-00 for sipping-web-archive@ietf.org; Thu, 10 Jul 2003 10:03:37 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ac1J-00037Q-00 for sipping-web-archive@ietf.org; Thu, 10 Jul 2003 10:03:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ac0j-0001yD-23; Thu, 10 Jul 2003 10: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 19ac0Y-0001xn-8O for sipping@optimus.ietf.org; Thu, 10 Jul 2003 10:02: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 KAA02460 for ; Thu, 10 Jul 2003 10:02:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ac0V-00036S-00 for sipping@ietf.org; Thu, 10 Jul 2003 10:02:47 -0400 Received: from pmesmtp02.wcom.com ([199.249.20.2]) by ietf-mx with esmtp (Exim 4.12) id 19ac0U-000369-00 for sipping@ietf.org; Thu, 10 Jul 2003 10:02:46 -0400 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HHT007G4AV3HC@firewall.wcom.com> for sipping@ietf.org; Thu, 10 Jul 2003 13:59:27 +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 <0HHT00D01AUSVM@pmismtp02.wcomnet.com>; Thu, 10 Jul 2003 13:59:27 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.104.1]) by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HHT00BHZAUY62@pmismtp02.wcomnet.com>; Thu, 10 Jul 2003 13:59:23 +0000 (GMT) Date: Thu, 10 Jul 2003 08:59:21 -0500 From: Alan Johnston Subject: Re: [Sipping] Question on pick-up in service-examples-04 In-reply-to: X-Sender: Alan.Johnston@pop.mcit.com To: "Elwell, John" , "'sipping@ietf.org'" Message-id: <5.2.1.1.0.20030710085538.01f1ced8@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 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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 From exim@www1.ietf.org Thu Jul 10 10:34: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 KAA04931 for ; Thu, 10 Jul 2003 10:34: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 19acUv-00055l-Hk for sipping-archive@odin.ietf.org; Thu, 10 Jul 2003 10:34:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AEYD9E019567 for sipping-archive@odin.ietf.org; Thu, 10 Jul 2003 10:34:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19acUv-00055V-DJ for sipping-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 10:34: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 KAA04881 for ; Thu, 10 Jul 2003 10:34:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19acUs-0003On-00 for sipping-web-archive@ietf.org; Thu, 10 Jul 2003 10:34:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19acUq-0003Ok-00 for sipping-web-archive@ietf.org; Thu, 10 Jul 2003 10:34:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19acUl-00053P-DK; Thu, 10 Jul 2003 10:34:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19acUg-00052X-NY for sipping@optimus.ietf.org; Thu, 10 Jul 2003 10:33: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 KAA04849 for ; Thu, 10 Jul 2003 10:33:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19acUe-0003O1-00 for sipping@ietf.org; Thu, 10 Jul 2003 10:33:56 -0400 Received: from cerbrus.convedia.com ([216.129.93.50]) by ietf-mx with esmtp (Exim 4.12) id 19acUd-0003Mg-00 for sipping@ietf.org; Thu, 10 Jul 2003 10:33:55 -0400 Received: from ladon.convedia.com (ladon [192.168.208.15]) by cerbrus.convedia.com (8.12.9/8.12.9) with ESMTP id h6AEUCCW011019 for ; Thu, 10 Jul 2003 07:30:13 -0700 (PDT) Received: from oemxif0gl8zo0j ([192.168.209.36]) by ladon.convedia.com (8.9.3+Sun/8.9.3) with SMTP id HAA05281; Thu, 10 Jul 2003 07:33:21 -0700 (PDT) From: "Garland Sharratt" To: "Sipping@Ietf. Org" Date: Thu, 10 Jul 2003 07:33:00 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-reply-to: Content-Transfer-Encoding: 7bit Subject: [Sipping] RE: Request for comments on new SIP media server interface drafts: MSML, MOML Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit A number of people have asked for further information on MSML/MOML and their background. To address this we have released a white paper document describing the rationale for the creation of MSML and MOML and giving a high-level description of the functionality they offer: http://www.convedia.com/PDFs/Whitepaper_MSML_MOML_v1.pdf Regards, Garland -----Original Message----- From: Garland Sharratt [mailto:gsharratt@convedia.com] Sent: Sunday, June 29, 2003 21:15 To: Sipping@Ietf. Org Subject: Request for comments on new SIP media server interface drafts: MSML, MOML Convedia has just released two Internet Drafts that together define a powerful, general purpose, and extensible SIP-based control interface for IP media servers. Convedia is releasing these drafts into the public domain with no intellectual property rights (IPR) claims. Media Sessions Markup Language (MSML): http://www.ietf.org/internet-drafts/draft-melanchuk-sipping-msml-00.txt Media Objects Markup Language (MOML): http://www.ietf.org/internet-drafts/draft-melanchuk-sipping-moml-00.txt MSML/MOML is the next step beyond the popular Netann draft, and allows media servers to support functionality on SIP that previously could only be accomplished with MGCP, including advanced (also known as business, moderated, or event) conferencing and unscripted (also known as tightly-coupled) IVR. MSML/MOML is a simple addition to SIP and makes use of XML content in the message bodies of SIP INVITE and INFO requests, without modifying the SIP protocol in any way. MSML/MOML is independent of the underlying transport mechanism so that it can easily be moved from SIP INFO to alternative mid-call mechanisms in the future. Convedia welcomes and seeks input and feedback from all interested parties, including service providers, vendors of softswitches and application servers that use media servers in their solutions, and other media server vendors. ______________________________________________________________________ Garland Sharratt Convedia VP, Bus. Dev. & Chief Architect 4190 Still Creek Dr., Suite 300 gsharratt@convedia.com Vancouver, BC, Canada V5C 6C6 Tel: +1.604.918.6393 Fax: +1.604.918.6400 Mob: +1.604.657.1880 Web: www.convedia.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 Jul 10 10:37: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 KAA05184 for ; Thu, 10 Jul 2003 10:37: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 19acXh-0005en-DJ for sipping-archive@odin.ietf.org; Thu, 10 Jul 2003 10:37:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AEb56e021739 for sipping-archive@odin.ietf.org; Thu, 10 Jul 2003 10:37:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19acXh-0005eY-94 for sipping-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 10:37: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 KAA05148 for ; Thu, 10 Jul 2003 10:36:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19acXe-0003Sw-00 for sipping-web-archive@ietf.org; Thu, 10 Jul 2003 10:37:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19acXe-0003St-00 for sipping-web-archive@ietf.org; Thu, 10 Jul 2003 10:37:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19acXe-0005ah-LR; Thu, 10 Jul 2003 10: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 19acXX-0005Yp-3i for sipping@optimus.ietf.org; Thu, 10 Jul 2003 10:36: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 KAA05136 for ; Thu, 10 Jul 2003 10:36:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19acXU-0003SZ-00 for sipping@ietf.org; Thu, 10 Jul 2003 10:36:52 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19acXU-0003RU-00 for sipping@ietf.org; Thu, 10 Jul 2003 10:36:52 -0400 Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.118.24]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6AEaJfq029244 for ; Thu, 10 Jul 2003 10:36:19 -0400 (EDT) Received: from cisco.com (dhcp-10-86-164-156.cisco.com [10.86.164.156]) by cannon.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAC27885; Thu, 10 Jul 2003 10:46:42 -0400 (EDT) Message-ID: <3F0D79E2.30005@cisco.com> Date: Thu, 10 Jul 2003 10:36:18 -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: sipping@ietf.org References: <200307031532.LAA16772@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Re::draft-ietf-sipping-3pcc-04.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Why is it that the latest rev of this draft has started using addresses from the .invalid TLD in a c-line to denote a black hole, instead of a zero address as in prior versions? The old way was backward compatible, since it was the traditional way of doing hold and so was implemented widely. It seems probable that the new way will fail for many UAs, especially since this behavior has never been in any normative document. 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 Thu Jul 10 11:36: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 LAA07769 for ; Thu, 10 Jul 2003 11: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 19adSu-0001wf-VU for sipping-archive@odin.ietf.org; Thu, 10 Jul 2003 11:36:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AFaCOg007470 for sipping-archive@odin.ietf.org; Thu, 10 Jul 2003 11:36:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19adSu-0001wP-RG for sipping-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 11:36: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 LAA07751 for ; Thu, 10 Jul 2003 11:36:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19adSt-00044b-00 for sipping-web-archive@ietf.org; Thu, 10 Jul 2003 11:36:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19adSt-00044Y-00 for sipping-web-archive@ietf.org; Thu, 10 Jul 2003 11:36:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19adSk-0001vL-7g; Thu, 10 Jul 2003 11: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 19adSJ-0001ur-Sg for sipping@optimus.ietf.org; Thu, 10 Jul 2003 11:35: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 LAA07733 for ; Thu, 10 Jul 2003 11:35:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19adSI-00044D-00 for sipping@ietf.org; Thu, 10 Jul 2003 11:35:34 -0400 Received: from machine77.level3.com ([209.244.4.106] helo=f1ee40-19.idc1.level3.com) by ietf-mx with esmtp (Exim 4.12) id 19adSI-00043z-00 for sipping@ietf.org; Thu, 10 Jul 2003 11:35:34 -0400 Received: from WDC1EXC0002.corp.global.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8p2+Sun/8.8.8) with SMTP id PAA01722 for ; Thu, 10 Jul 2003 15:34:57 GMT Received: from idc1exc0001.corp.global.level3.com ([10.1.7.194]) by WDC1EXC0002.corp.global.level3.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 10 Jul 2003 11:34:26 -0400 Received: from idc1exc0004.corp.global.level3.com ([10.1.8.20]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 10 Jul 2003 09:34:25 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Thu, 10 Jul 2003 09:34:25 -0600 Message-ID: <3DB099919328BA41905F651A6EF83976B4DDE0@idc1exc0004.corp.global.level3.com> Thread-Topic: Question on pstn-call-flows-02 draft Thread-Index: AcNG+L3m9TK0PkqrQHGnxnGxtFmGoQ== From: "Hearty, John" To: "Sipping@Ietf. Org" X-OriginalArrivalTime: 10 Jul 2003 15:34:25.0845 (UTC) FILETIME=[BE80C650:01C346F8] Content-Transfer-Encoding: quoted-printable Subject: [Sipping] Question on pstn-call-flows-02 draft Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable In section 2.2 message F7-F8, why is a 180 sent when the Progress indicator shows further call progress information may be available in-band? It would seem to me that for sure if it was 8 (In-band info or appropriate pattern now available), and probably 1, a 183 should be returned. Somewhat related to this I'd like some input on another flow not documented. For an IP to PSTN flow where the caller does not send SDP in Invite (offer in 200, answer in ACK), we have no way to forward in-band progress tones/announcements. What is the best SIP response to send in this case when a PSTN backwards message indicates progress tones/announcements may be available in-band? With a 180, the caller may falsely believe the call is ringing when it could be going to an announcement. 183 won't serve much purpose since the gateway doesn't yet know the caller's address to send RTP to, presumably the caller would get silence. Sending no provisional beyond 100 is another option, also resulting in silence. Any opinions what is best? John Hearty Level3 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 10 20:02: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 UAA27455 for ; Thu, 10 Jul 2003 20:02: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 19alMW-0005uk-VN for sipping-archive@odin.ietf.org; Thu, 10 Jul 2003 20:02:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6B028TB022733 for sipping-archive@odin.ietf.org; Thu, 10 Jul 2003 20:02:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19alMW-0005ua-SG for sipping-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 20:02: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 UAA27447 for ; Thu, 10 Jul 2003 20:02:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19alMU-0000aG-00 for sipping-web-archive@ietf.org; Thu, 10 Jul 2003 20:02:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19alMU-0000aC-00 for sipping-web-archive@ietf.org; Thu, 10 Jul 2003 20:02:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19alMQ-0005tf-7N; Thu, 10 Jul 2003 20:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19alLx-0005tH-I4 for sipping@optimus.ietf.org; Thu, 10 Jul 2003 20:01: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 UAA27440 for ; Thu, 10 Jul 2003 20:01:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19alLv-0000a8-00 for sipping@ietf.org; Thu, 10 Jul 2003 20:01:31 -0400 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 19alLu-0000a5-00 for sipping@ietf.org; Thu, 10 Jul 2003 20:01:30 -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 h6B01K1R012225; Fri, 11 Jul 2003 09:01:20 +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 h6B01J8E000480; Fri, 11 Jul 2003 09:01:19 +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 h6B01JeH001452; Fri, 11 Jul 2003 09:01:19 +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 JAA02070; Fri, 11 Jul 2003 09:01:18 +0900 (JST) Received: from Annika.lab.ntt.co.jp by img.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id JAA11289; Fri, 11 Jul 2003 09:01:17 +0900 (JST) Message-Id: <5.1.1.9.2.20030711083524.04951500@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: Fri, 11 Jul 2003 09:01:15 +0900 To: Jonathan Rosenberg , sipping@ietf.org From: Kumiko Ono Subject: [Sipping] Comments on draft-ietf-sipping-session-policy-req-00 In-Reply-To: <3F000692.9000109@ericsson.com> 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 Jonathan, First of all, the approach of the session-policy is a good idea. Proxies can express preferences for the use of codec during the codec negotiation between UAs. It seems that proxies join the offer-answer procedures. I have a comment on your session-policy-requirement I-D. REQ-CON-5,6 say the mechanism should allow the proxies to know whether or not the UAC/UAS has accepted its policy requests. I think this requirements imply another requirement that the mechanism should allow proxies to verify the integrity of the acceptance of its policy requests. I would suggest add this as a security requirement. Regards, Kumiko ----------------------------------- Kumiko Ono NTT Network Service Systems Labs. Tel +81 422 59 4508/Fax +81 422 60 4012 e-mail ono.kumiko@lab.ntt.co.jp ----------------------------------- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 11 10:52: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 KAA02269 for ; Fri, 11 Jul 2003 10:52:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19azGA-00006M-Bn for sipping-archive@odin.ietf.org; Fri, 11 Jul 2003 10:52:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BEqUpP000386 for sipping-archive@odin.ietf.org; Fri, 11 Jul 2003 10:52:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19azGA-000069-8d for sipping-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 10:52: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 KAA02250 for ; Fri, 11 Jul 2003 10:52:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19azG7-00069e-00 for sipping-web-archive@ietf.org; Fri, 11 Jul 2003 10:52:27 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19azG7-00069b-00 for sipping-web-archive@ietf.org; Fri, 11 Jul 2003 10:52:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19azFh-0008Vq-9o; Fri, 11 Jul 2003 10: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 19azEk-0008VD-V9 for sipping@optimus.ietf.org; Fri, 11 Jul 2003 10:51: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 KAA02214 for ; Fri, 11 Jul 2003 10:50:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19azEh-00069F-00 for sipping@ietf.org; Fri, 11 Jul 2003 10:50:59 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19azEd-00068y-00 for sipping@ietf.org; Fri, 11 Jul 2003 10:50:56 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23168; Fri, 11 Jul 2003 10:50:17 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA18906; Fri, 11 Jul 2003 10:50:18 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <3P1MRN27>; Fri, 11 Jul 2003 10:50:17 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5BD8@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Cullen Jennings'" , "'Yutaka Takeda'" , "'sipping@ietf.org'" Date: Fri, 11 Jul 2003 10:50:16 -0400 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 X-MIME-Autoconverted: from 8bit to quoted-printable by mailgate.pit.comms.marconi.com id KAA23168 Content-Transfer-Encoding: quoted-printable Subject: [Sipping] RE: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 Yeah, except there is no media. This does point out, however, the issue of whether KPML is the way to go for these kinds of problems. In both vmail and FECC, the abstraction is very clear, the UI less so. For the "server" to decide which buttons IMHO is not correct. You should describe the control abstraction, and let the end device UI designer decide how best to implement that abstraction, based on the capabilities and design guidelines of the device. Brian > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Friday, July 11, 2003 10:16 AM > To: Brian Rosen; 'Yutaka Takeda'; sip@ietf.org; mmusic@ietf.org > Subject: Re: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP >=20 >=20 >=20 > In many ways, this problem is similar to the far end camera=20 > control issues. > Real time responses is needed, It is a 1:1 relationship between the > controller and controlee, the control protocol needs to be extensible. >=20 > On 7/9/03 11:40, "Rosen, Brian" wrote: >=20 > > I've been thinking for a long time about what an appropriate > > mechanism to provide a voice/videomail client on a sipphone > > would be. It's really clear that you record and play messages > > with VCR like functionality. For that, you need start/stop/pause/ > > rewind/fast forward, and so I was thinking RTSP. On the other > > hand, you surely establish the session to the voicemail server > > with a sip call. > >=20 > > Thus, I like the way Jonathan is thinking, but you also need > > message selection/creation/deletion functions, and for those > > I was thinking KPML, and then you wonder if you just use that > > as the signalling mechanism for the record/play, and I get > > confused. > >=20 > > Brian > >=20 > >> -----Original Message----- > >> From: Yutaka Takeda [mailto:takeday@kmerl.com] > >> Sent: Wednesday, July 09, 2003 2:11 PM > >> To: sip@ietf.org; mmusic@ietf.org > >> Subject: RE: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP > >>=20 > >>=20 > >> The applications that have need for SIP and RTSP features I > >> can imagine are: > >>=20 > >> - Voice&video mail (similar to 'sipum' but VM server is in > >> the SIP phone) > >> - Personal broadcast station from my PC at home. > >> - Watching video recorded with VCR at home or office from remote... > >>=20 > >> What I am not sure is if RTSP has any solution or a framework for a > >> RTSP server behind a NAT. If not, the solution is likely to > >> be a repeat > >> of what SIP provides. I thought TURN could be used in order > >> for signaling > >> message to reach RTSP server behind a NAT, but I noticed that > >> it is not=20 > >> applicable (purposefully) for a server running behind a=20 > NAT because of > >> a security consideration. Lots of issues for RTSP in this=20 > area alone? > >>=20 > >> I believe a lot of people are interested in this discussion. > >>=20 > >> Best regards, > >> Yutaka > >>=20 > >>=20 > >>> -----Original Message----- > >>> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > >>> Sent: Wednesday, July 09, 2003 5:53 AM > >>> To: Pianigiani, Jacopo (Jacopo) > >>> Cc: sip@ietf.org; mmusic@ietf.org > >>> Subject: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP > >>>=20 > >>>=20 > >>> Hi, > >>>=20 > >>> When it comes to IMS and 3G terminals, most will already > >>> before having=20 > >>> an IMS functionality have support for PSS. PSS is > >>> Packet-based Streaming > >>> Service which is an umbrella kind of standard for=20 > streaming service > >>> defined in 3GPP targeted at low bit-rates and mobile networks. > >>> Specification available from Rel 4 in TS 26.233 and TS > >>> 26.234. Already > >>> today there exist GSM/GPRS phones that has a PSS client. > >>>=20 > >>> So I think that dual stack implementations will not be that > >>> impossible=20 > >>> to foresee. > >>>=20 > >>> However I think the main issue in this discussion is to > >> look at what=20 > >>> applications that has need for SIP-RTSP interactions. Based > >>> on this we=20 > >>> can see if there is solutions easily available or not. > >>>=20 > >>> I can agree with Rosenberg that if we where going to design a RTSP > >>> functionality protocol today, looking at SIP for session > >>> establishment=20 > >>> would be interesting. However that opportunity has passed > >> as RTSP has=20 > >>> started to be deployed in increasing numbers. I think even > >> the latest=20 > >>> Windows media player does support RTSP. > >>>=20 > >>>=20 > >>> Best Regards > >>>=20 > >>> Magnus Westerlund > >>>=20 > >>>=20 > >>> Pianigiani, Jacopo (Jacopo) wrote: > >>>> Hello all, > >>>> In my undertanding RTSP is suitable for broadcast, unicast > >>> or multicast streams distribution. The RTSP protocol was > >>> ideated for typical content delivery, and in effect for this > >>> application could be more than suitable. But referring to an > >>> IMS domain, in my point of view adopting RSTP as media > >>> streams control, would imply adopting at least a double > >>> protocol stack in the terminal equipment. The IMS concept was > >>> mainly driven by the concept - in my understanding - of > >>> simplifying the terminal (making it simpler from a protocol > >>> stack implementation means lowering costs and increasing > >>> penetration on the market) by adopting a single protocol > >>> stack in the terminal, and having the RAN and the core > >>> evolving toward a unified transport mechanism for which an > >>> almost unified level of control on the network resources > >>> allocated to a session (whatever session we refer to, voice , > >>> multimedia p-t-t call, web browsing, multimedia session with > >>> voice call and dynamic web pages). > >>>> So in this sense, my understanding is that the RTSP could > >>> be suitable for media content, but it would imply again new > >>> complexity on the IMS UMTS/CDMA terminal itself, which is > >>> against the idea of IMS of enhancing the services the user > >>> can access by having an homogeneous protocol stack on the > >>> terminal itself for all types of services. > >>>>=20 > >>>> After all, the RTSP , apart from content delivery (of > >>> streams), could not definitely handle appropriately sessions > >>> like Voice calls + Interactive Web Pages. > >>>> Regards > >>>>=20 > >>>> Jacopo Pianigiani > >>>> Lucent Technologies - Italy > >>>> =E839 335 7350536 > >>>>=20 > >>>> -----Original Message----- > >>>> From: Paolo Asprino [mailto:asprino@coritel.it] > >>>> Sent: Wednesday, July 09, 2003 9:40 AM > >>>> To: NAKAMURA, Hidefumi; sip@ietf.org; mmusic@ietf.org > >>>> Subject: Re: [Sip] Appropriate usage of SIP and RTSP > >>>>=20 > >>>>=20 > >>>> Hi all > >>>>=20 > >>>> I'm thinking a solution to join SIP and RTSP in the 3G=20 > IMS domain. > >>>> In particular in the IMS, I think that to provide multilmedia > >>>> service (i.e video on demand), one can estabilish a > >>> subscription to the service by SIP and then activate the > >>> service with RTSP by DIGEST autentication with the > >>>> parameters exchanged early during the subscription > >>> (username and password) > >>>>=20 > >>>> What do you think about that? > >>>>=20 > >>>> Best Regards=20 > >>>>=20 > >>>> ----- Original Message ----- > >>>> From: "NAKAMURA, Hidefumi" > >>>> To: ; > >>>> Cc: > >>>> Sent: Monday, July 07, 2003 9:49 AM > >>>> Subject: [Sip] Appropriate usage of SIP and RTSP > >>>>=20 > >>>>=20 > >>>>=20 > >>>>> Hi, all. > >>>>>=20 > >>>>> I have a question about the relationship between SIP and RTSP. > >>>>>=20 > >>>>> In RFC3261, there is a description that says > >>>>> "SIP is not a vertically integrated communications > >>> system. SIP is > >>>>> rather a component that can be used with other IETF > >> protocols to > >>>>> build a complete multimedia architecture. Typically, these > >>>>> architectures will include protocols such as the > >>> Real-time Transport > >>>>> Protocol (RTP) (RFC 1889 [28]) for transporting > >>> real-time data and > >>>>> providing QoS feedback, the Real-Time streaming protocol > >>> (RTSP) (RFC > >>>>> 2326 [29]) for controlling delivery of streaming media, ..." > >>>>> (RFC3261 Section 2) > >>>>>=20 > >>>>> However, my understanding is that both SIP and RTSP have > >>> the capability > >>>>> for "discovery of UAs or media streams." > >>>>> If I use SIP to establish a stream session and use RTSP=20 > to control > >>>>> the stream, there will be redundant sequences, i.e. > >>> INVITE-OK-ACK and > >>>>> SETUP-OK. > >>>>>=20 > >>>>> Was there any discussion on how to use these two protocols > >>> appropriately? > >>>>>=20 > >>>>> With SIP application server, network providers can=20 > provide various > >>>>> services on contents delivery while we will not be able to > >>> do so only > >>>>> with RTSP, I think. On the other hand, RTSP has enough > >>> capability for > >>>>> discovery of media streams and for negotiation of SDPs. > >>>>> So, I think, for the simple delivery of contents, RTSP is > >>> appropriate to > >>>>> use, and for various session control services regarding contents > >>>>> delivery, SIP with RTSP is appropriate to use. > >>>>>=20 > >>>>> Any opinions? > >>>>>=20 > >>>>> I wonder why no contents delivery server seems to prepare > >>> SIP stack now.=20 > >>>>> Is it because, up to now, there exists only a simple > >>> contents delivery > >>>>> service? > >>>>>=20 > >>>>> best regards, > >>>>>=20 > >>>>> --=20 > >>>>> NAKAMURA, Hidefumi > >>>>> NTT ServiceIntegration /NetworkServiceSystems Labs. > >>>>> tel: +81(422)59 3904; fax:+81(422)60 4012 > >>>>> --- > >>>>>=20 > >>>>>=20 > >>>>>=20 > >>>>> _______________________________________________ > >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>>> This list is for NEW development of the core SIP Protocol > >>>>> Use sip-implementors@cs.columbia.edu for questions on=20 > current sip > >>>>> Use sipping@ietf.org for new developments on the > >> application of sip > >>>>>=20 > >>>>=20 > >>>>=20 > >>>>=20 > >>>> --- > >>>> Outgoing mail is certified Virus Free. > >>>> Checked by AVG anti-virus system (http://www.grisoft.com). > >>>> Version: 6.0.495 / Virus Database: 294 - Release Date: > >>> 30/06/2003J*fj)bz b=B2=D8m=B6>?=FF=0C> > > 0=D6'=AD~S=E0=FEf=A2-f=A7=FEX=AC=B6)=DF=A3=FB"=A58b=B2X=AC=B6+=1F=A2=B3DY= =D7=AF > >>> zZ)(tm)=E9=ED=A1=FBay=CA+y"=0F>=BA-=A1=CA%R=C7=ACS~=A6=A6W=A6z{h=AE= =C7,r?n(tm)=B8sy=DBY=A2=BA=AEz=CBb=A2{(=9D=CB=AB > >>> =AD=E9=ED=B2*T=B1=EB"=A6~=A7''=AD~S=E0~S=E7{=07^=BD=E9h=A6g=A7=B6=CA= '=B6=17s=A6(tm)bq=ABb=A2z=1F > >>>>=20 > >>>> _______________________________________________ > >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>> This list is for NEW development of the core SIP Protocol > >>>> Use sip-implementors@cs.columbia.edu for questions on current sip > >>>> Use sipping@ietf.org for new developments on the > >> application of sip > >>>>=20 > >>>=20 > >>>=20 > >>> --=20 > >>>=20 > >>> Magnus Westerlund > >>>=20 > >>> Multimedia Technologies, Ericsson Research EAB/TVA/A > >>>=20 > >>=20 > ---------------------------------------------------------------------- > >>> Ericsson AB | Phone +46 8 4048287 > >>> Torshamsgatan 23 | Fax +46 8 7575550 > >>> S-164 80 Stockholm, Sweden | mailto:=20 > magnus.westerlund@ericsson.com > >>>=20 > >>>=20 > >>> _______________________________________________ > >>> mmusic mailing list > >>> mmusic@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/mmusic > >>>=20 > >>=20 > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mmusic > >>=20 > >=20 > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > >=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 From exim@www1.ietf.org Fri Jul 11 11:54: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 LAA04245 for ; Fri, 11 Jul 2003 11:54: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 19b0Du-0004XC-Tx for sipping-archive@odin.ietf.org; Fri, 11 Jul 2003 11:54:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BFsEoA017426 for sipping-archive@odin.ietf.org; Fri, 11 Jul 2003 11:54:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b0Du-0004Wz-R0 for sipping-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 11:54: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 LAA04237 for ; Fri, 11 Jul 2003 11:54:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b0Do-0006gV-00 for sipping-web-archive@ietf.org; Fri, 11 Jul 2003 11:54:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19b0Do-0006gS-00 for sipping-web-archive@ietf.org; Fri, 11 Jul 2003 11:54:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b0Dh-0004Vw-IN; Fri, 11 Jul 2003 11:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b0DD-0004VS-P6 for sipping@optimus.ietf.org; Fri, 11 Jul 2003 11:53: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 LAA04231 for ; Fri, 11 Jul 2003 11:53:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b0DC-0006gJ-00 for sipping@ietf.org; Fri, 11 Jul 2003 11:53:30 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19b0DB-0006g6-00 for sipping@ietf.org; Fri, 11 Jul 2003 11:53:29 -0400 Received: from cannon-old.cisco.com (IDENT:mirapoint@cannon-old.cisco.com [161.44.118.24]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6BFqefq008572; Fri, 11 Jul 2003 11:52:41 -0400 (EDT) Received: from cisco.com ([161.44.79.125]) by cannon-old.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAD00124; Fri, 11 Jul 2003 12:03:04 -0400 (EDT) Message-ID: <3F0EDD47.9050506@cisco.com> Date: Fri, 11 Jul 2003 11:52:39 -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: seancolson@yahoo.com, "'Peterson, Jon'" , "'sipping'" Subject: Re: [Sipping] Update to 3pcc References: <000801c345d6$a957fe60$6801a8c0@cranberry> <3F0BE0BC.8070403@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'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 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. Paul Jonathan Rosenberg wrote: > Yes, definitely badness. We already have had a lot of interop issues > with 3pcc, because lots of folks don't support things like INVITEs w/o > SDP, even though its mandatory in 3261. This would add another problem > to the mix. > > One could argue that, as a BCP, it is not the place of the specification > to mandate UA behavior that differs from existing, standards track > behavior (RFC 3264). The whole premise of 3pcc is that it should work > with any rfc3261 compliant UA. Now, we are saying that a UA would need > to explicitly support this new "3pcc feature" to work. > > How about this alternate approach: > > 1. 3pcc goes back to using 0.0.0.0 > 2. We write a separate I-D, which updates rfc3264, saying to use > .invalid. We also add an option tag for it, so we can figure out if its > understood. That would go through as a standards track document in sip, > presumably. It would be short, just a few pages. > > With (2) in place, 3pcc could make use of .invalid, and couple it with > Require as necessary to make sure backwards compatibility is addressed. > > I don't know whether this approach would be acceptable to IESG. Jon or > Allison, comments? > > Thanks, > Jonathan R. > > > > > Sean Olson wrote: > >> It is likely that the session would be terminated. Badness. >> >> >> -----Original Message----- >> From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Tuesday, >> July 08, 2003 8:32 PM >> To: 'Sean Olson'; Jonathan Rosenberg; sipping >> Subject: RE: [Sipping] Update to 3pcc >> >> >> >> I agree that this is something that should be fixed with explicit >> semantics >> in future versions of SDP. But I hope that the .invalid approach won't >> give >> rise to serious interoperability concerns. Can any implementers speak to >> what would happen if a domain name given in the c= line of SDP could >> not be >> resolved? I imagine that it's unlikely to lead to any media being >> sent, but >> is there a further concern that the SIP session would be terminated >> unceremoniously, or something like that? >> >> Jon Peterson >> NeuStar, Inc. >> >> >>> -----Original Message----- >>> From: Sean Olson [mailto:seancolson@yahoo.com] >>> Sent: Tuesday, July 08, 2003 9:05 PM >>> To: Jonathan Rosenberg; sipping >>> Subject: Re: [Sipping] Update to 3pcc >>> >>> >>> This is a huge interop issue. Is .invalid to be the recommendation >>> going forward or is this a stopgap measure? Hopefully SDPng addresses >>> this more directly. >>> >>> --- 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. >>> >>> >>> >>> __________________________________ >>> Do you Yahoo!? >>> SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.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 Fri Jul 11 13:47: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 NAA07882 for ; Fri, 11 Jul 2003 13:47: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 19b1zJ-0006L4-Mm for sipping-archive@odin.ietf.org; Fri, 11 Jul 2003 13:47:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BHlHYC024362 for sipping-archive@odin.ietf.org; Fri, 11 Jul 2003 13:47:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b1zJ-0006Kr-IK for sipping-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 13:47: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 NAA07865 for ; Fri, 11 Jul 2003 13:47:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b1zH-0007nP-00 for sipping-web-archive@ietf.org; Fri, 11 Jul 2003 13:47:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19b1zG-0007nM-00 for sipping-web-archive@ietf.org; Fri, 11 Jul 2003 13:47:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b1z3-0006Jl-Tp; Fri, 11 Jul 2003 13: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 19b1yH-000641-CG for sipping@optimus.ietf.org; Fri, 11 Jul 2003 13:46: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 NAA07832 for ; Fri, 11 Jul 2003 13:46:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b1yF-0007mq-00 for sipping@ietf.org; Fri, 11 Jul 2003 13:46:11 -0400 Received: from 67.105.118.114.ptr.us.xo.net ([67.105.118.114] helo=mail.kmerl.com) by ietf-mx with esmtp (Exim 4.12) id 19b1yE-0007mY-00 for sipping@ietf.org; Fri, 11 Jul 2003 13:46:10 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Jul 2003 10:45:38 -0700 Message-ID: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP Thread-Index: AcNHu9lWjViAOkzDT/mhBaMHQZ5E2QAEOcbA From: "Yutaka Takeda" To: "Rosen, Brian" , "Cullen Jennings" , Content-Transfer-Encoding: quoted-printable Subject: [Sipping] RE: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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, > > In many ways, this problem is similar to the far end camera=20 > > control issues. > > Real time responses is needed, It is a 1:1 relationship between the > > controller and controlee, the control protocol needs to be=20 > extensible. Thanks, Cullen. This is the issue that I am facing to... Generally, VCR like functionality can be solved with RTSP. So, I like=20 Jonathan's idea too, setting up a session for the control with SIP. My=20 idea is that maybe we can add such far-end device control methods=20 in the control session as well. Another issue is, as Brian mentioned, there need to be a way to=20 get a list of voice&video mail and delete operation for each item. This=20 is generally done by HTTP. As in the case of RTSP control session, it seems we need to add another session for this purpose... Am I on=20 the right track? In terms of the real-time far-end device control including VCR like operations, as a call session is already established at the point of doing it, we might be able to implement it with INFO method.=20 I would like to hear general comments or opinions here on the use=20 of INFO method for this purpose. Is this method considered as=20 'deprecated' generally? I have just noticed that MSML&MOML utilize INFO method, and=20 just started looking into them... > Agreed. Best regards, Yutaka > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Friday, July 11, 2003 7:50 AM > To: 'Cullen Jennings'; Yutaka Takeda; 'sipping@ietf.org' > Subject: RE: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP >=20 >=20 > > Yeah, except there is no media. >=20 > This does point out, however, the issue of whether KPML is the > way to go for these kinds of problems. In both vmail and > FECC, the abstraction is very clear, the UI less so. For the > "server" to decide which buttons IMHO is not correct. You > should describe the control abstraction, and let the end device > UI designer decide how best to implement that abstraction, based > on the capabilities and design guidelines of the device. >=20 > Brian >=20 > > -----Original Message----- > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > Sent: Friday, July 11, 2003 10:16 AM > > To: Brian Rosen; 'Yutaka Takeda'; sip@ietf.org; mmusic@ietf.org > > Subject: Re: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP > >=20 > >=20 > >=20 > > In many ways, this problem is similar to the far end camera=20 > > control issues. > > Real time responses is needed, It is a 1:1 relationship between the > > controller and controlee, the control protocol needs to be=20 > extensible. > >=20 > > On 7/9/03 11:40, "Rosen, Brian" wrote: > >=20 > > > I've been thinking for a long time about what an appropriate > > > mechanism to provide a voice/videomail client on a sipphone > > > would be. It's really clear that you record and play messages > > > with VCR like functionality. For that, you need start/stop/pause/ > > > rewind/fast forward, and so I was thinking RTSP. On the other > > > hand, you surely establish the session to the voicemail server > > > with a sip call. > > >=20 > > > Thus, I like the way Jonathan is thinking, but you also need > > > message selection/creation/deletion functions, and for those > > > I was thinking KPML, and then you wonder if you just use that > > > as the signalling mechanism for the record/play, and I get > > > confused. > > >=20 > > > Brian > > >=20 > > >> -----Original Message----- > > >> From: Yutaka Takeda [mailto:takeday@kmerl.com] > > >> Sent: Wednesday, July 09, 2003 2:11 PM > > >> To: sip@ietf.org; mmusic@ietf.org > > >> Subject: RE: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP > > >>=20 > > >>=20 > > >> The applications that have need for SIP and RTSP features I > > >> can imagine are: > > >>=20 > > >> - Voice&video mail (similar to 'sipum' but VM server is in > > >> the SIP phone) > > >> - Personal broadcast station from my PC at home. > > >> - Watching video recorded with VCR at home or office=20 > from remote... > > >>=20 > > >> What I am not sure is if RTSP has any solution or a=20 > framework for a > > >> RTSP server behind a NAT. If not, the solution is likely to > > >> be a repeat > > >> of what SIP provides. I thought TURN could be used in order > > >> for signaling > > >> message to reach RTSP server behind a NAT, but I noticed that > > >> it is not=20 > > >> applicable (purposefully) for a server running behind a=20 > > NAT because of > > >> a security consideration. Lots of issues for RTSP in this=20 > > area alone? > > >>=20 > > >> I believe a lot of people are interested in this discussion. > > >>=20 > > >> Best regards, > > >> Yutaka > > >>=20 > > >>=20 > > >>> -----Original Message----- > > >>> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > >>> Sent: Wednesday, July 09, 2003 5:53 AM > > >>> To: Pianigiani, Jacopo (Jacopo) > > >>> Cc: sip@ietf.org; mmusic@ietf.org > > >>> Subject: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP > > >>>=20 > > >>>=20 > > >>> Hi, > > >>>=20 > > >>> When it comes to IMS and 3G terminals, most will already > > >>> before having=20 > > >>> an IMS functionality have support for PSS. PSS is > > >>> Packet-based Streaming > > >>> Service which is an umbrella kind of standard for=20 > > streaming service > > >>> defined in 3GPP targeted at low bit-rates and mobile networks. > > >>> Specification available from Rel 4 in TS 26.233 and TS > > >>> 26.234. Already > > >>> today there exist GSM/GPRS phones that has a PSS client. > > >>>=20 > > >>> So I think that dual stack implementations will not be that > > >>> impossible=20 > > >>> to foresee. > > >>>=20 > > >>> However I think the main issue in this discussion is to > > >> look at what=20 > > >>> applications that has need for SIP-RTSP interactions. Based > > >>> on this we=20 > > >>> can see if there is solutions easily available or not. > > >>>=20 > > >>> I can agree with Rosenberg that if we where going to=20 > design a RTSP > > >>> functionality protocol today, looking at SIP for session > > >>> establishment=20 > > >>> would be interesting. However that opportunity has passed > > >> as RTSP has=20 > > >>> started to be deployed in increasing numbers. I think even > > >> the latest=20 > > >>> Windows media player does support RTSP. > > >>>=20 > > >>>=20 > > >>> Best Regards > > >>>=20 > > >>> Magnus Westerlund > > >>>=20 > > >>>=20 > > >>> Pianigiani, Jacopo (Jacopo) wrote: > > >>>> Hello all, > > >>>> In my undertanding RTSP is suitable for broadcast, unicast > > >>> or multicast streams distribution. The RTSP protocol was > > >>> ideated for typical content delivery, and in effect for this > > >>> application could be more than suitable. But referring to an > > >>> IMS domain, in my point of view adopting RSTP as media > > >>> streams control, would imply adopting at least a double > > >>> protocol stack in the terminal equipment. The IMS concept was > > >>> mainly driven by the concept - in my understanding - of > > >>> simplifying the terminal (making it simpler from a protocol > > >>> stack implementation means lowering costs and increasing > > >>> penetration on the market) by adopting a single protocol > > >>> stack in the terminal, and having the RAN and the core > > >>> evolving toward a unified transport mechanism for which an > > >>> almost unified level of control on the network resources > > >>> allocated to a session (whatever session we refer to, voice , > > >>> multimedia p-t-t call, web browsing, multimedia session with > > >>> voice call and dynamic web pages). > > >>>> So in this sense, my understanding is that the RTSP could > > >>> be suitable for media content, but it would imply again new > > >>> complexity on the IMS UMTS/CDMA terminal itself, which is > > >>> against the idea of IMS of enhancing the services the user > > >>> can access by having an homogeneous protocol stack on the > > >>> terminal itself for all types of services. > > >>>>=20 > > >>>> After all, the RTSP , apart from content delivery (of > > >>> streams), could not definitely handle appropriately sessions > > >>> like Voice calls + Interactive Web Pages. > > >>>> Regards > > >>>>=20 > > >>>> Jacopo Pianigiani > > >>>> Lucent Technologies - Italy > > >>>> =E839 335 7350536 > > >>>>=20 > > >>>> -----Original Message----- > > >>>> From: Paolo Asprino [mailto:asprino@coritel.it] > > >>>> Sent: Wednesday, July 09, 2003 9:40 AM > > >>>> To: NAKAMURA, Hidefumi; sip@ietf.org; mmusic@ietf.org > > >>>> Subject: Re: [Sip] Appropriate usage of SIP and RTSP > > >>>>=20 > > >>>>=20 > > >>>> Hi all > > >>>>=20 > > >>>> I'm thinking a solution to join SIP and RTSP in the 3G=20 > > IMS domain. > > >>>> In particular in the IMS, I think that to provide multilmedia > > >>>> service (i.e video on demand), one can estabilish a > > >>> subscription to the service by SIP and then activate the > > >>> service with RTSP by DIGEST autentication with the > > >>>> parameters exchanged early during the subscription > > >>> (username and password) > > >>>>=20 > > >>>> What do you think about that? > > >>>>=20 > > >>>> Best Regards=20 > > >>>>=20 > > >>>> ----- Original Message ----- > > >>>> From: "NAKAMURA, Hidefumi" > > >>>> To: ; > > >>>> Cc: > > >>>> Sent: Monday, July 07, 2003 9:49 AM > > >>>> Subject: [Sip] Appropriate usage of SIP and RTSP > > >>>>=20 > > >>>>=20 > > >>>>=20 > > >>>>> Hi, all. > > >>>>>=20 > > >>>>> I have a question about the relationship between SIP and RTSP. > > >>>>>=20 > > >>>>> In RFC3261, there is a description that says > > >>>>> "SIP is not a vertically integrated communications > > >>> system. SIP is > > >>>>> rather a component that can be used with other IETF > > >> protocols to > > >>>>> build a complete multimedia architecture. Typically, these > > >>>>> architectures will include protocols such as the > > >>> Real-time Transport > > >>>>> Protocol (RTP) (RFC 1889 [28]) for transporting > > >>> real-time data and > > >>>>> providing QoS feedback, the Real-Time streaming protocol > > >>> (RTSP) (RFC > > >>>>> 2326 [29]) for controlling delivery of streaming media, ..." > > >>>>> (RFC3261 Section 2) > > >>>>>=20 > > >>>>> However, my understanding is that both SIP and RTSP have > > >>> the capability > > >>>>> for "discovery of UAs or media streams." > > >>>>> If I use SIP to establish a stream session and use RTSP=20 > > to control > > >>>>> the stream, there will be redundant sequences, i.e. > > >>> INVITE-OK-ACK and > > >>>>> SETUP-OK. > > >>>>>=20 > > >>>>> Was there any discussion on how to use these two protocols > > >>> appropriately? > > >>>>>=20 > > >>>>> With SIP application server, network providers can=20 > > provide various > > >>>>> services on contents delivery while we will not be able to > > >>> do so only > > >>>>> with RTSP, I think. On the other hand, RTSP has enough > > >>> capability for > > >>>>> discovery of media streams and for negotiation of SDPs. > > >>>>> So, I think, for the simple delivery of contents, RTSP is > > >>> appropriate to > > >>>>> use, and for various session control services=20 > regarding contents > > >>>>> delivery, SIP with RTSP is appropriate to use. > > >>>>>=20 > > >>>>> Any opinions? > > >>>>>=20 > > >>>>> I wonder why no contents delivery server seems to prepare > > >>> SIP stack now.=20 > > >>>>> Is it because, up to now, there exists only a simple > > >>> contents delivery > > >>>>> service? > > >>>>>=20 > > >>>>> best regards, > > >>>>>=20 > > >>>>> --=20 > > >>>>> NAKAMURA, Hidefumi > > >>>>> NTT ServiceIntegration /NetworkServiceSystems Labs. > > >>>>> tel: +81(422)59 3904; fax:+81(422)60 4012 > > >>>>> --- > > >>>>>=20 > > >>>>>=20 > > >>>>>=20 > > >>>>> _______________________________________________ > > >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > >>>>> This list is for NEW development of the core SIP Protocol > > >>>>> Use sip-implementors@cs.columbia.edu for questions on=20 > > current sip > > >>>>> Use sipping@ietf.org for new developments on the > > >> application of sip > > >>>>>=20 > > >>>>=20 > > >>>>=20 > > >>>>=20 > > >>>> --- > > >>>> Outgoing mail is certified Virus Free. > > >>>> Checked by AVG anti-virus system (http://www.grisoft.com). > > >>>> Version: 6.0.495 / Virus Database: 294 - Release Date: > > >>> 30/06/2003J*fj)bz b=B2=D8m=B6>?=FF=0C> > > > > = 0=D6'=AD~S=E0=FEf=A2-f=A7=FEX=AC=B6)=DF=A3=FB"=A58b=B2X=AC=B6+=1F=A2=B3DY= =D7=AF > > >>> = zZ)(tm)=E9=ED=A1=FBay=CA+y"=0F>=BA-=A1=CA%R=C7=ACS~=A6=A6W=A6z{h=AE=C7,r?= n(tm)=B8sy=DBY=A2=BA=AEz=CBb=A2 > {(=9D=CB=AB > > >>> = =AD=E9=ED=B2*T=B1=EB"=A6~=A7''=AD~S=E0~S=E7{=07^=BD=E9h=A6g=A7=B6=CA'=B6=17= s=A6(tm)bq=ABb=A2z=1F > > >>>>=20 > > >>>> _______________________________________________ > > >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > >>>> This list is for NEW development of the core SIP Protocol > > >>>> Use sip-implementors@cs.columbia.edu for questions on=20 > current sip > > >>>> Use sipping@ietf.org for new developments on the > > >> application of sip > > >>>>=20 > > >>>=20 > > >>>=20 > > >>> --=20 > > >>>=20 > > >>> Magnus Westerlund > > >>>=20 > > >>> Multimedia Technologies, Ericsson Research EAB/TVA/A > > >>>=20 > > >>=20 > >=20 > ---------------------------------------------------------------------- > > >>> Ericsson AB | Phone +46 8 4048287 > > >>> Torshamsgatan 23 | Fax +46 8 7575550 > > >>> S-164 80 Stockholm, Sweden | mailto:=20 > > magnus.westerlund@ericsson.com > > >>>=20 > > >>>=20 > > >>> _______________________________________________ > > >>> mmusic mailing list > > >>> mmusic@ietf.org > > >>> https://www1.ietf.org/mailman/listinfo/mmusic > > >>>=20 > > >>=20 > > >> _______________________________________________ > > >> mmusic mailing list > > >> mmusic@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/mmusic > > >>=20 > > >=20 > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mmusic > > >=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 From exim@www1.ietf.org Mon Jul 14 04:20:26 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 EAA01277 for ; Mon, 14 Jul 2003 04:20: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 19byYv-0002VQ-OM for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 04:19:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6E8JvOV009629 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 04:19:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19byYv-0002VE-8o for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 04:19: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 EAA01259 for ; Mon, 14 Jul 2003 04:19:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19byYs-0002fx-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 04:19:54 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19byYr-0002ft-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 04:19:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19byY3-0002TG-UA; Mon, 14 Jul 2003 04:19:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19byXp-0002Sw-Uw for sipping@optimus.ietf.org; Mon, 14 Jul 2003 04:18: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 EAA01232 for ; Mon, 14 Jul 2003 04:18:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19byXn-0002fC-00 for sipping@ietf.org; Mon, 14 Jul 2003 04:18:47 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19byXm-0002ea-00 for sipping@ietf.org; Mon, 14 Jul 2003 04:18:46 -0400 Received: from dynamicsoft.com ([63.113.46.50]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6E8IEiB009411; Mon, 14 Jul 2003 04:18:15 -0400 (EDT) Message-ID: <3F12673F.90506@dynamicsoft.com> Date: Mon, 14 Jul 2003 04:18:07 -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: "'sipping@ietf.org'" Subject: Re: [Sipping] Question on INVITE Initiated Dialog Event Package and Automatic C allback References: <931A17FBB884D411B02B0008C70D9E2ABF1307@mchh243e.mchh.siemens.de> In-Reply-To: <931A17FBB884D411B02B0008C70D9E2ABF1307@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 The dialog package can be used by subscriptions made both within, and outside, of a dialog. So, in the case of automatic callback, the caller would, after receiving a 486, send a SUBSCRIBE request for the dialog package, and do so outside of any dialog. -Jonathan R. Stupka Jean-Marie wrote: > Hello All, > > As said in RFC 3265 it is possible to create an event subscription > within a pre-existing dialog, e.g. a dialog created by an INVITE. > In my understanding, this is the intention of > draft-ietf-sipping-dialog-package-02.txt. > > According to the (PSTN) Automatic Callback given as example > application in the introduction of this draft, user A can request a > callback when user B hangs-up. User A off course needs to get the > information that user B is busy before requesting the automatic > callback, i.e. receive a "486 Busy Here" message. However, all > early dialogs are considered terminated upon reception of a non-2xx > final response (13.2.2.3 of RFC 3261). As consequence, the dialog > and thus the data of the preceding call attempt are no more > available and the callback cannot be requested. > > Can somebody provide clarification of the applicability of RFC 3265 > and the draft-ietf-sipping-dialog-package-02.txt to Automatic > Callback? > > Regards, > > Jean-Marie > > > _______________________________________________ Sipping mailing > list https://www1.ietf.org/mailman/listinfo/sipping This list is > for NEW development of the 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 Mon Jul 14 05:15: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 FAA03215 for ; Mon, 14 Jul 2003 05:15: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 19bzQK-00058D-53 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 05:15:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6E9F8h6019726 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 05: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 19bzQJ-000585-T1 for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 05: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 FAA03208 for ; Mon, 14 Jul 2003 05:15:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bzQG-0003Bn-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 05:15:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bzQG-0003Bk-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 05:15:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bzQD-000577-N5; Mon, 14 Jul 2003 05:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bzPu-00056G-7j for sipping@optimus.ietf.org; Mon, 14 Jul 2003 05:14: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 FAA03194 for ; Mon, 14 Jul 2003 05:14:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bzPr-0003BR-00 for sipping@ietf.org; Mon, 14 Jul 2003 05:14:39 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19bzPq-0003BB-00 for sipping@ietf.org; Mon, 14 Jul 2003 05:14:38 -0400 Received: from dynamicsoft.com ([63.113.46.50]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6E9E1iB009445; Mon, 14 Jul 2003 05:14:02 -0400 (EDT) Message-ID: <3F127452.6010604@dynamicsoft.com> Date: Mon, 14 Jul 2003 05:13:54 -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: Volker Hilt CC: "Miguel A. Garcia" , sipping@ietf.org Subject: Re: [Sipping] Comments on draft-ietf-sipping-session-policy-req-00 References: <3F000692.9000109@ericsson.com> <3F05CB0B.7060008@bell-labs.com> In-Reply-To: <3F05CB0B.7060008@bell-labs.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. Volker Hilt wrote: > Jonathan, Miguel, > > Miguel A. Garcia wrote: > >> First, I am missing a general requirement that describes the general >> mechanism that we want. If you consider the General Requirements, >> there are many of them explaining different aspects of the solution, >> but none that describes generally what is needed. I would expect >> something on these lines: >> >> "A mechanism that provides SIP proxies with the ability to convey >> session related policies to SIP User Agents". > > > The goals of the policy draft have been motivated quite nicely with a > number of very convincing examples. The requirements for these examples > are reflected in some of the Policy Requirements (examples are > REQ-POL-4, REQ-POL-5 and REQ-POL-7 to REQ-POL-13). > > I was wondering if it is possible to separate the requirements specific > to these examples (e.g. requesting the use of a different codec, > different media addresses, firewalls, QoS) from requirements of the > general policy mechanism (the mechanism needed to exchange policy > information between UAC, proxies and UAS). This mechanism could be > defined independent of a certain use. It could enable a proxy to request > the modification of any aspect of a session description. > > The requirements for certain use cases of the session policy mechanism > could then be defined in a separate section/document. This separation > seems to be more extendible than combining the requirements of the > policy exchange mechanism and use cases. I think that makes sense. I'll restructure the document so that there are some general mechanism requirements, indpendent of the particular policy type, and then some requirements for specific policies (codec policy, intermediary policy, etc.). > >> The thing is that I don't foresee dynamic changes in policies, >> depending on the traffic in the network. One could do it, of course, >> but requires some extra administration or having some sort of monitor >> that acts upon thresholds. > > > How do you envision the proxy to change policies within an active call? > This sounds a little like re-INVITEs send out by the proxy (something a > proxy can't do!). I think what Miguel is saying is that they wouldnt need to change in the middle of a call. In fact, the policies would be fairly static and would change infrequently. When they do change, they don't need to do so synchronous with any particular call attempt. In that case, you can use mechanisms totally outside of a call. It becomes more of a provisioning problem, and things like xcap would be more applicable. > >> Instead I foresee another scenario where the administrator has >> certain fixed policies that do not change often. For instance, an >> administrator could permanently disallow the G.711 codec because of >> the high bandwidth. I think this is an important issue to discuss, >> because the solution may go in one or another direction depending on >> the rate of the changes in policy. I would suggest to add a >> requirement regarding the expected changes in the policies. > > > The session policies will probably not depend on highly dynamic factors > such a load (congestion control comes to mind here) but more on things > like network configuration and user preferences. These issues can easily > be considered by a proxy on a call to call basis. The point Miguel is making, and its important one, is it wouldn't even be on a call-by-call basis. This is really the first major issue we need to tackle (we'll discuss during the sipping meeting today). Do we think session policies need to be specified on a call-by-call basis? Certain policies tend to need to be call-by-call. For example, using an intermediary for relaying media. That needs to be call-by-call since the port to send to will be computed on a call-by-call basis. Other policies, such as codecs to use, arguably don't change much at all, and may not need to be computed on a call-by-call basis. So, the question is whether we think there are two mechanisms - one outside of a call, and one inside, or just one. One point to be made is that, if you have a single in-call mechanism, that could be used to cover both static and dynamic requirements. Thus, you would have just one mechanism (thats good). But, it might be inefficient for wireless, sending the same policeis to the UA over and over again (thats bad). Then again, sigcomp might fix it (thats good). So, its not obvious to me what the right direction is. Thoughts? -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 Mon Jul 14 05:19: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 FAA03390 for ; Mon, 14 Jul 2003 05:19: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 19bzUB-0005Ri-4c for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 05:19:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6E9J77L020928 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 05:19:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bzUB-0005RT-1C for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 05:19: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 FAA03356 for ; Mon, 14 Jul 2003 05:19:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bzU7-0003E6-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 05:19:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bzU7-0003E3-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 05:19:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bzU6-0005P9-NG; Mon, 14 Jul 2003 05:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bzU2-0005Nu-Om for sipping@optimus.ietf.org; Mon, 14 Jul 2003 05:18: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 FAA03353 for ; Mon, 14 Jul 2003 05:18:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bzTz-0003E0-00 for sipping@ietf.org; Mon, 14 Jul 2003 05:18:55 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19bzTy-0003Dn-00 for sipping@ietf.org; Mon, 14 Jul 2003 05:18:54 -0400 Received: from dynamicsoft.com ([63.113.46.50]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6E9IRiB009449; Mon, 14 Jul 2003 05:18:29 -0400 (EDT) Message-ID: <3F12755B.9040508@dynamicsoft.com> Date: Mon, 14 Jul 2003 05:18:19 -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: Kumiko Ono CC: sipping@ietf.org Subject: Re: [Sipping] Comments on draft-ietf-sipping-session-policy-req-00 References: <5.1.1.9.2.20030711083524.04951500@img.m.ecl.ntt.co.jp> In-Reply-To: <5.1.1.9.2.20030711083524.04951500@img.m.ecl.ntt.co.jp> 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 Kumiko Ono wrote: > Jonathan, > > First of all, the approach of the session-policy is a good idea. > Proxies can express preferences for the use of codec during the > codec negotiation between UAs. It seems that proxies join > the offer-answer procedures. > > I have a comment on your session-policy-requirement I-D. > > REQ-CON-5,6 say > the mechanism should allow the proxies to know whether or not > the UAC/UAS has accepted its policy requests. > > I think this requirements imply another requirement that > the mechanism should allow proxies to verify the integrity of the > acceptance of its policy requests. I would suggest add this > as a security requirement. I would reword that slightly to "the mechanism SHOULD allow the proxy to verify that the UAC/UAS has accepted its policy requests". Thats because your wording implies that there is some kind of policy object in the subsequent request which can have its integrity verified. Verification that a policy has been implemented may be done, for example, by using a firewall that blocks media from being sent anywhere except the port specified by the proxy. In that case, there isn't really a cryptographic integrity operation going on. 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 Mon Jul 14 06:28: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 GAA05622 for ; Mon, 14 Jul 2003 06:28: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 19c0YK-0000md-KN for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 06:27:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EARSVt002985 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 06:27:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0YJ-0000m0-Vt for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 06:27: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 GAA05525 for ; Mon, 14 Jul 2003 06:27:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c0YD-0003r1-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 06:27:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c0Y9-0003qX-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 06:27:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0Xy-0000Xf-FS; Mon, 14 Jul 2003 06:27:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ajcJ-0006K0-Eh for sipping@optimus.ietf.org; Thu, 10 Jul 2003 18:10: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 SAA24574 for ; Thu, 10 Jul 2003 18:10:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ajcG-00000D-00 for sipping@ietf.org; Thu, 10 Jul 2003 18:10:16 -0400 Received: from mail3.pi.se ([195.7.64.137]) by ietf-mx with esmtp (Exim 4.12) id 19ajcD-000005-00 for sipping@ietf.org; Thu, 10 Jul 2003 18:10:14 -0400 Received: from VAIOMHP (1Cust116.tnt2.stk3.swe.da.uu.net [213.116.227.116]) (authenticated) by mail3.pi.se (8.11.2/8.11.2) with ESMTP id h6AM9cR14543; Fri, 11 Jul 2003 00:09:39 +0200 (CEST) From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= To: "Arnoud van Wijk" , , , , , , , , "'James Hamlin'" , , , "'Rajesh Kumar'" , , , , , , "Henry Sinnreich" , "Paul E. Jones" Date: Fri, 11 Jul 2003 00:08:53 +0200 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.2910.0) Importance: Normal In-Reply-To: <00c001c3470e$b1bfd800$0401a8c0@packetizer.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.pi.se id h6AM9cR14543 Content-Transfer-Encoding: quoted-printable Subject: [Sipping] SV: items for vor voting in the BOF Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 Poul, No rush. I mean to begin the work to create a BCP or RFC with an I-D now,= or between now and next IETF meeting. BCP seems to be a less formal type of document than an RFC, so do not be scared by its name I agree that new gateway environments call for further standardisation, l= ike the one going on now in ITU. If something comes up in that work that should influence the SIP text telephony or SIP total conversation specs, it should be good timing to le= t these pieces of work influence each other. There could also be details coming from the camarillo I-D or RFC 3351 tha= t should be reflected in the intended spec. Descriptions about ways to invo= ke ither services, like transcoding service. I hope this will be covered in a BOF, with the explanation that Barry Din= gle wrote, and agreed to start a new work. I expect it to take 8 months to re= ach maturity. Gunnar ------------------------------------------- Gunnar Hellstr=F6m, Omnitor, Renathv=E4gen 2 SE 121 37 Johanneshov, SWEDEN Tel: +46 8 556 002 03 Mob: +46 708204288 e-mail: gunnar.hellstrom@omnitor.se web: www.omnitor.se > -----Ursprungligt meddelande----- > Fr=E5n: Paul E. Jones [mailto:paulej@packetizer.com] > Skickat: den 10 juli 2003 20:12 > Till: Gunnar Hellstr=F6m; Henry Sinnreich; Guido.Gybels@rnid.org.uk; > mike.spanner@rnid.org.uk; andreas.piirimets@omnitor.se; > gv@trace.wisc.edu; 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; > rohan@cisco.com; sipping@ietf.org > =C4mne: Re: items for vor voting in the BOF > > > Gunnar, > > So, I don't agree with getting this started and helping to steer > direction, > but I disagree that everything is standardized. As you know, we are st= ill > working on the standards for transport of TTY signals between > PSTN gateways > (ITU-T Q11/16). There are still open questions as to whether a large > trunking gateway should use one port for audio and one for text or > "multiplex" on the same port. (I put that in quotes, as it's not truly > multiplexing, but switching between one media type and another, but sti= ll > from the same source... the PSTN trunk.) > > We then have to consider how those GWs will then interface with the IP > phones. This is where I can see the BCP showing value to ensure that t= he > current practices are documented. However, the current practices may h= ave > to be amended, expanded, etc. In just the past few weeks, we've had > discussions on carrying text over audio, using RFC 2793 only, > inserting GWs > in the middle, etc. So, I think we have a few things to talk > about. Thus, > I would prefer that this be written and modified over the next > few meetings, > rather than rushed to RFC/BCP status. > > Paul > > ----- Original Message ----- > From: "Gunnar Hellstr=F6m" > To: "Paul E. Jones" ; "Henry Sinnreich" > ; ; > ; ; > ; ; "'Rajesh Kumar'" > ; ; = ; > "'James Hamlin'" ; > ; > ; ; ; > ; ; > Sent: Thursday, July 10, 2003 3:16 AM > Subject: SV: items for vor voting in the BOF > > > > Poul, > > We are seeking a form of document where we can collect the > pieces that are > > already well standardised for text in IP, but apparently a bit hard t= o > find, > > so we have an apparent risk that developers keep inventing new, > incompatible > > solutions for text while the IP voice telephony side converges. > > > > We cannot afford to let IP text conversation be as fragmented > as it was in > > PSTN. It must be a proper telecom feature on the same status level as > voice > > and video if we are ever to get any accessibility in this world. And = it > must > > be included in mainstream developments. > > > > The PSTN functions for text are good and important where they are ,bu= t > > nothing of the functionality level that we would drag into the future= as > any > > best common solution. That has been stated many times in the discussi= ons > > here. > > > > Gateways are defined and in operation. > > > > It is exactly the right moment now to create a document that > collects the > > views on IP text conversation. With that we can all contribute > to make it > > widespread. Without it, there is a risk of continued fragmentation. > > > > We proposed BCP (Best Common Practise) merely because everything is > already > > standardised and it is not good to have the same standard in two > documents. > > A BCP can pick up and clarify and put emphasis on standards created i= n > other > > documents. Of course it shall take the traditional route to be an I-D > first. > > I am flexible on this. If there is enough new material in it, it can = be > > proposed as an RFC. > > > > So, doing it now is the most important. > > > > Gunnar > > > > > > > > ------------------------------------------- > > Gunnar Hellstr=F6m, Omnitor, Renathv=E4gen 2 > > SE 121 37 Johanneshov, SWEDEN > > Tel: +46 8 556 002 03 Mob: +46 708204288 > > e-mail: gunnar.hellstrom@omnitor.se > > web: www.omnitor.se > > > > > > > -----Ursprungligt meddelande----- > > > Fr=E5n: Paul E. Jones [mailto:paulej@packetizer.com] > > > Skickat: den 9 juli 2003 19:30 > > > Till: Gunnar Hellstrom; Henry Sinnreich; Guido.Gybels@rnid.org.uk; > > > mike.spanner@rnid.org.uk; andreas.piirimets@omnitor.se; > > > gv@trace.wisc.edu; 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; > > > rohan@cisco.com; sipping@ietf.org > > > =C4mne: Re: items for vor voting in the BOF > > > > > > > > > Gunnar, > > > > > > Do you think it might be a bit premature to publish a BCP? After > > > all, it's > > > not widely used at this point, but it is expected to become much > > > more widely > > > used over the next few years. What is still not sorted out is > > > how this will > > > be married with the existing PSTN TTY equipment out there. There w= as > some > > > discussion of using specialized gateways for interworking, > > > putting RFC 2793 > > > on IP phones, doing pass-though on IP phones, etc. We still haven'= t > even > > > settled the issue of how text will even be entered into the average= IP > > > phone. I recognize that it's a best "current" practice, but given = the > > > amount of focus on this right now and the volatility, I think it mi= ght > be > > > better to just produce an I-D and re-publish that for a period of t= ime > and > > > not rush to produce a BCP. > > > > > > Paul > > > > > > ----- Original Message ----- > > > From: "Gunnar Hellstrom" > > > To: "Henry Sinnreich" ; > > > ; > > > ; ; > > > ; ; "'Rajesh Kumar'" > > > ; ; > ; > > > "'James Hamlin'" ; > > > ; > > > ; ; > > > ; ; ; > > > ; > > > Sent: Sunday, July 06, 2003 4:45 PM > > > Subject: SV: items for vor voting in the BOF > > > > > > > > > > OK, looks fine. > > > > > > > > What about the external alerting connections? There was some good > points > > > > that it can be arranged by logging in a SIP alerter with > the same user > > > name > > > > in the sip server. That is a good design, that one can do a lot o= f > smart > > > > things with. Evenso, the direct connection on the phone is > simple and > > > > needed. > > > > > > > > > > > > Whatever the outcome of the voting, we also agreed that it would = be > good > > > to > > > > have a BCP ( Best Current Practice ) on what SIP text > > > conversation is. The > > > > SDP for it, some good habits in design, what is need to support t= he > > > > transactions for invoking transcoding according to camarillo... > > > etc. Erik > > > > Zetterstrom and Andreas Piirimets made an initial draft. I > > > think they are > > > > prepared to issue a new, slightly improved. Barry Dingle had a go= od > > > > formulation promoting it. Has it progressed? I suggest that > > > these actions > > > > are handled jointly in the sipping meeting. > > > > > > > > Is anything like the sipdev activity going on for > multimedia devices? > I > > > > would like to participate there and get text included there as we= ll > > > together > > > > with video and voice. > > > > > > > > Regards > > > > > > > > Gunnar > > > > > > > > ------------------------------------------- > > > > Gunnar Hellstrom, Omnitor, Renathvagen 2 > > > > SE 121 37 Johanneshov, SWEDEN > > > > Tel: +46 8 556 002 03 Mob: +46 708204288 > > > > e-mail: gunnar.hellstrom@omnitor.se > > > > web: www.omnitor.se > > > > > > > > > > > > > -----Ursprungligt meddelande----- > > > > > Fran: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com] > > > > > Skickat: den 6 juli 2003 22:14 > > > > > Till: 'Gunnar Hellstrom'; Guido.Gybels@rnid.org.uk; > > > > > mike.spanner@rnid.org.uk; andreas.piirimets@omnitor.se; > > > > > gv@trace.wisc.edu; trefor@trefor.plus.com; 'Rajesh Kumar'; > > > > > marcelo@envilogg.se; jorgen.bjorkner@hotsip.com; 'James Hamlin'= ; > > > > > Erik.Zetterstrom@omnitor.se; hwildfeu@cisco.com; > > > paulej@packetizer.com; > > > > > barry.dingle@bigfoot.com.au; mgarakan@cisco.com; oran@cisco.com= ; > > > > > rohan@cisco.com; sipping@ietf.org > > > > > Amne: RE: items for vor voting in the BOF > > > > > > > > > > > > > > > Please see the attached slide for voting at the IETF BOF on > > > "Interactive > > > > > Text Support for SIP Telephony Devices". > > > > > > > > > > We have no day/time yet for the BOF, but expect to get it > > > scheduled, as > > > > > discussed with Rohan Mahy. > > > > > > > > > > Many thanks to Gunnar Hellstrom for the formulation of the text. > > > > > > > > > > Thanks, Henry > > > > > > > > > > > -----Original Message----- > > > > > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > > > > > > Sent: Wednesday, July 02, 2003 3:44 AM > > > > > > To: Henry Sinnreich > > > > > > Cc: trefor@trefor.plus.com; gv@trace.wisc.edu; > > > > > > mike.spanner@rnid.org.uk; Guido.Gybels@rnid.org.uk; > > > > > > Erik.Zetterstrom@omnitor.se; 'Rajesh Kumar'; 'James Hamlin'; > > > > > > andreas.piirimets@omnitor.se; jorgen.bjorkner@hotsip.com; > > > > > > marcelo@envilogg.se; rohan@cisco.com; oran@cisco.com; > > > > > > mgarakan@cisco.com; hwildfeu@cisco.com; > > > > > > barry.dingle@bigfoot.com.au; paulej@packetizer.com > > > > > > Subject: SV: items for vor voting in the BOF > > > > > > > > > > > > > > > > > > Henry, > > > > > > Yes please use the sentences in the IETF meeting, with no 3 > > > > > > amended as below. > > > > > > > > > > > > Some thoughts an explanations: > > > > > > > > > > > > Blind reference: > > > > > > ---------------- > > > > > > The reference about display interface for blind people refers > > > > > > to a need for blind people to follow hat is displayed on the > > > > > > phone through a device of their choice. It may be voice > > > > > > synthesis or electromechanical braille display or display > > > > > > with enlargement or extra strong light. We do not expect the > > > > > > phone to include these special devices, so a standardised > > > > > > interface to them must be provided. The SIP phone will have > > > > > > states so it will be impossible to expect that you shall be > > > > > > able to operate it without feedback from the phone. The > > > > > > mobile industry made the mistake to not initially provide a > > > > > > standardised interface to operate the mobile phone and that > > > > > > has caused enormous problems for blind people. The AT command > > > > > > interface available to 3GPP mobile phones seem to have > > > > > > overcome this mistake by including commands and responses for > > > > > > accessing most things required for operation through a serial > > > > > > command language that can be issued through Bluetooth or a > > > > > > USB or serial connector. Products are emerging. Something > > > > > > similar must be done on SIP phones. I concentrated on deaf > > > > > > issues, but I see that we have common interests here. > > > > > > > > > > > > The web interface: > > > > > > ------------------ > > > > > > I saw a comment that the web interface should not be > > > > > > mentioned as a solution. That may be true, it was with > > > > > > hesitation that I added it. But: I have seen SIP phones with > > > > > > the possibility to add the video component from a nearby > > > > > > computer. Similar things can be done for text. It is still > > > > > > valid to let the phone have all the other SIP phone > > > > > > functionality. I can imagine PDA access through Bluetooth > > > > > > executing a web browser to operate the phone. The text > > > > > > component could be accessible through that interface. > > > > > > Handling only the user interface aspect of the text part is > > > > > > an enormous difference from handling the complete SIP > > > > > > protocol and all audio coding. The sum is of course that when > > > > > > we open for many ways to add text and that the person > > > > > > carrying a text interface with him, will find that it can not > > > > > > be attached to any phone, and then accessibility is again > > > > > > limited. I am quite sure that phones will not come without > > > > > > display, and that they will follow the trend on PDAs and > > > > > > mobile phones, to include a full aphanumeric keyboard because > > > > > > it is needed for address and phonebook use, as well as to > > > > > > provide a good user interface to the very popular real time > > > > > > text conversation function ;-) . So, I am not too worried > > > > > > that we give many options. > > > > > > > > > > > > > > > > > > The analogue interface. > > > > > > ----------------------- > > > > > > The statement no 3 about the analogue adapter is not really > > > > > > formulated in a strict IETF style. A starting sentence > is needed: > > > > > > > > > > > > 3. A SIP device MAY provide analogue adapter functionality > > > > > > through an RJ11 port. IF an RJ11 port is provided for a PSTN > > > > > > device adapter interface, THEN it MUST/SHOULD provide T.38 > > > > > > support for fax AND V.18+RFC2793 support for text alternating > > > > > > with voice. If T.38 or RFC2793 negotiation fails then it MAY > > > > > > try to connect for G.711 and pass the audio through. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------- > > > > > > Gunnar Hellstrom, Omnitor, Renathvagen 2 > > > > > > SE 121 37 Johanneshov, SWEDEN > > > > > > Tel: +46 8 556 002 03 Mob: +46 708204288 > > > > > > e-mail: gunnar.hellstrom@omnitor.se > > > > > > web: www.omnitor.se > > > > > > > > > > > > > > > > > > > -----Ursprungligt meddelande----- > > > > > > > Fran: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com] > > > > > > > Skickat: den 2 juli 2003 02:27 > > > > > > > Till: 'Gunnar Hellstrom' > > > > > > > Kopia: paulej@packetizer.com; barry.dingle@bigfoot.com.au; > > > > > > > hwildfeu@cisco.com; mgarakan@cisco.com; oran@cisco.com; > > > > > > > rohan@cisco.com; marcelo@envilogg.se; > jorgen.bjorkner@hotsip.com; > > > > > > > Henry.Sinnreich@mci.com; andreas.piirimets@omnitor.se; > > > > > > 'James Hamlin'; > > > > > > > 'Rajesh Kumar'; Erik.Zetterstrom@omnitor.se; > > > > > > Guido.Gybels@rnid.org.uk; > > > > > > > mike.spanner@rnid.org.uk; gv@trace.wisc.edu; > > > trefor@trefor.plus.com > > > > > > > Amne: items for vor voting in the BOF > > > > > > > > > > > > > > > > > > > > > Gunnar, > > > > > > > > > > > > > > I will use with your permission your formulation to put > > > these three > > > > > > > items to vote in the BOF, for MUST or SHOULD: > > > > > > > > > > > > > > 1. MUST/SHOULD include protocol support for RFC2793 for tex= t. > > > > > > > > > > > > > > 2. MUST/SHOULD provide a way to input text and display > > > > > > text, through > > > > > > > any > > > > > > > method: Built in user interfaces, standard wired or > > > > > > wireless interfaces > > > > > > > for keyboard and display ( that is needed anyway for blind > > > > > > people), or > > > > > > > support for text through its already mandated web interface. > > > > > > > > > > > > > > ---- > > > > > > > And, with some doubt: > > > > > > > > > > > > > > 3. IF an RJ11 port is provided for a PSTN device adapter > > > interface, > > > > > > > THEN it MUST/SHOULD provide T.38 support for fax AND > V.18+RFC2793 > > > > > > > support for text alternating with voice. If T.38 or RFC2793 > > > > > > > negotiation fails then it MAY try to connect for G.711 > > > and pass the > > > > > > > audio through.( is there any need to mandate also modem > support? ) > > > > > > > > > > > > > > I believe these are very reasonable requirements. > > > > > > > > > > > > > > Thanks, Henry > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.s= e] > > > > > > > > Sent: Tuesday, July 01, 2003 4:08 PM > > > > > > > > To: Rajesh Kumar; James Hamlin > > > > > > > > Cc: paulej@packetizer.com; barry.dingle@bigfoot.com.au; > > > > > > > > hwildfeu@cisco.com; mgarakan@cisco.com; oran@cisco.com; > > > > > > > > rohan@cisco.com; marcelo@envilogg.se; > > > jorgen.bjorkner@hotsip.com; > > > > > > > > Henry.Sinnreich@mci.com; andreas.piirimets@omnitor.se; > > > > > > > > Erik.Zetterstrom@omnitor.se; Guido.Gybels@rnid.org.uk; > > > > > > > > mike.spanner@rnid.org.uk; gv@trace.wisc.edu; > > > > > > trefor@trefor.plus.com > > > > > > > > Subject: SV: SV: SV: Internet draft on real time text > > > conversation > > > > > > > > > > > > > > > > > > > > > > > > I see the discussion going in circles. > > > > > > > > > > > > > > > > Henry gave me the delicate task to sum up and get a > > > > > > proposed writing > > > > > > > > into the Sipdev specification. > > > > > > > > > > > > > > > > After looking back in the discussion, I come to the > > > > > > conclusion that, > > > > > > > > the only requirements that make real sense and takes deaf > > > > > > telecomms > > > > > > > > a bit towards equal opportunities is that SIP devices: > > > > > > > > > > > > > > > > 1. MUST include protocol support for RFC2793 for text. > > > > > > > > > > > > > > > > 2. MUST provide a way to input text and display text, > > > through any > > > > > > > > method: Built in user interfaces, standard wired or wirel= ess > > > > > > > > interfaces for keyboard and display ( that is needed anyw= ay > for > > > > > > > > blind people), or support for text through its already > > > > > > mandated web > > > > > > > > interface. > > > > > > > > > > > > > > > > ---- > > > > > > > > And, with some doubt: > > > > > > > > > > > > > > > > 3. IF an RJ11 port is provided for a PSTN device adapter > > > > > > interface, > > > > > > > > THEN it MUST provide T.38 support for fax AND > > > > > > V.18+RFC2793 support > > > > > > > > for text alternating with voice. If T.38 or RFC2793 > negotiation > > > > > > > > fails then it MAY try to connect for G.711 and pass > the audio > > > > > > > > through.( is there any need to mandate also modem support= ? ) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---- > > > > > > > > I am sure SIP signaling can take care of most tricky > > > > > > situations that > > > > > > > > have been up for discussion. > > > > > > > > > > > > > > > > E.g. > > > > > > > > A SIP phone without RJ11 port in contact with a PSTN > > > > > > device through > > > > > > > > a gateway, would signal RFC2793 capability. That will > > > > > > make a gateway > > > > > > > > involved in the call perceive any indication on use of > > > modem-like > > > > > > > > tones from PSTN as text if possible. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I intend to propose text with that content soon for the > > > > > > sipdev spec. > > > > > > > > > > > > > > > > With that, we could perhaps change topic to discuss > > > > > > contents of the > > > > > > > > text capable device I-D that Erik and Andreas made a > > > > > > first draft of. > > > > > > > > > > > > > > > > Has time been booked in the SIPPING meeting in Wienna to > discuss > > > > > > > > that? > > > > > > > > > > > > > > > > Can Erik and Andreas provide us with a second draft? > > > > > > > > > > > > > > > > Best regards > > > > > > > > > > > > > > > > Gunnar > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------- > > > > > > > > Gunnar Hellstrom, Omnitor, Renathvagen 2 > > > > > > > > SE 121 37 Johanneshov, SWEDEN > > > > > > > > Tel: +46 8 556 002 03 Mob: +46 708204288 > > > > > > > > e-mail: gunnar.hellstrom@omnitor.se > > > > > > > > web: www.omnitor.se > > > > > > > > > > > > > > > > > > > > > > > > > -----Ursprungligt meddelande----- > > > > > > > > > Fran: Rajesh Kumar [mailto:rkumar@cisco.com] > > > > > > > > > Skickat: den 1 juli 2003 19:15 > > > > > > > > > Till: James Hamlin > > > > > > > > > Kopia: paulej@packetizer.com; barry.dingle@bigfoot.com.= au; > > > > > > > > > hwildfeu@cisco.com; mgarakan@cisco.com; oran@cisco.com; > > > > > > > > > rohan@cisco.com; marcelo@envilogg.se; > > > > > > jorgen.bjorkner@hotsip.com; > > > > > > > > > Henry.Sinnreich@mci.com; andreas.piirimets@omnitor.se; > > > > > > > > > Erik.Zetterstrom@omnitor.se; gunnar.hellstrom@omnitor.s= e; > > > > > > > > > Guido.Gybels@rnid.org.uk; mike.spanner@rnid.org.uk; > > > > > > > > gv@trace.wisc.edu; > > > > > > > > > trefor@trefor.plus.com > > > > > > > > > Amne: RE: SV: SV: Internet draft on real time text > > > conversation > > > > > > > > > > > > > > > > > > > > > > > > > > > James, > > > > > > > > > > > > > > > > > > The intent here is that the called party could be any S= IP > > > > > > > > phone, not > > > > > > > > > just SIP phones specially designated for text-only > > > > > > > > operation. I think > > > > > > > > > the intent expressed by Guido and Gunnar et al is that = a > > > > > > > > PSTN TTY user > > > > > > > > > should be able > > > > > > > > > to open an RFC 2793 text channel with any SIP phone use= r, > > > > > > > > and that the > > > > > > > > > latter should either have an integral keyboard/display > > > > > > or a port > > > > > > > > > to such a display. So the problem of call > > > > > > discrimination when the > > > > > > > > > caller is a V.21 or > > > > > > > > > V.23 legacy textphone is not solved unless you allow > > > > > > > > passthrough fallback > > > > > > > > > when you cannot tell whether the V.21 signal is text or > not - > > > > > > > > > regardless of the existence of gateways/servers > that do PSTN > > > > > > > > > textphone to RFC 2793 conversion. > > > > > > > > > > > > > > > > > > In general, the solution of designating special phone > > > > > > numbers for > > > > > > > > > deaf-accessible operation militates against the > stipulation > > > > > > > > that the > > > > > > > > > deaf be able to create text channels from any PSTN or > > > SIP phone > > > > > > > > > number, and to any PSTN or SIP phone number. Here, > textphone > > > > > > > > > detection has to be on the basis of control signals > > > > > > > > exchanged in the > > > > > > > > > bearer stream or on the content of the bearer stream, > > > > > > and not on a > > > > > > > > > priori numbering plans that create a "deaf ghetto". > > > > > > > > > > > > > > > > > > For technical reasons, I still think you must mandate > > > > > > passthrough > > > > > > > > > operation to enable universal interoperability. > > > > > > > > > > > > > > > > > > Kind regards to all. > > > > > > > > > > > > > > > > > > Rajesh > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > At 04:33 PM 7/1/2003 +0100, James Hamlin wrote: > > > > > > > > > >Rajesh > > > > > > > > > > > > > > > > > > > >It would be possible for people on the IP network to > > > have PSTN > > > > > > > > > numbers that > > > > > > > > > >are taken from a block that is assigned only to text. > > > > > > Therefore > > > > > > > > > the gateway > > > > > > > > > >between PSTN and the IP network knows from the called > number > > > > > > > > > that the intent > > > > > > > > > >is to use text. > > > > > > > > > > > > > > > > > > > >Regards > > > > > > > > > > > > > > > > > > > >James > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > > > > > > > >From: Rajesh Kumar [mailto:rkumar@cisco.com] > > > > > > > > > >Sent: 01 July 2003 16:05 > > > > > > > > > >To: A vWijk > > > > > > > > > >Cc: paulej@packetizer.com; barry.dingle@bigfoot.com.au= ; > > > > > > > > > >hwildfeu@cisco.com; mgarakan@cisco.com; oran@cisco.com= ; > > > > > > > > > >rohan@cisco.com; marcelo@envilogg.se; > > > > > > jorgen.bjorkner@hotsip.com; > > > > > > > > > >Henry.Sinnreich@mci.com; andreas.piirimets@omnitor.se; > > > > > > > > > >Erik.Zetterstrom@omnitor.se; gunnar.hellstrom@omnitor.= se; > > > > > > > > > >Guido.Gybels@rnid.org.uk; james.hamlin@rnid.org.uk; > > > > > > > > > >mike.spanner@rnid.org.uk; gv@trace.wisc.edu; > > > > > > > > > >trefor@trefor.plus.com > > > > > > > > > >Subject: Re: SV: SV: Internet draft on real time text > > > > > > conversation > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> "rkumar@cisco.com" 07/01/03 16:04 >>> > > > > > > > > > > > > > > > > > > > >Arnoud, > > > > > > > > > > > > > > > > > > > >As I indicated in another email, interoperability with > legacy > > > > > > > > > V.21 and V.23T > > > > > > > > > > TY devices is not feasible unless you support a > passthrough > > > > > > > > > >fallback. I have no hidden agenda here, I am just > > > presenting a > > > > > > > > > >technical difficulty that SG16/Q11 and TIA TR.30.1 hav= e > been > > > > > > > > > >struggling with for the past 6 months. I do not know h= ow > > > > > > > > you can do > > > > > > > > > >without TTY passthrough if you want universal > > > > > > > > interoperability. Here > > > > > > > > > >was my mail, sent yesterday: > > > > > > > > > > > > > > > > > > > >There is a real technical difficulty which I would > > > want you all > > > > > > > > > to consider. > > > > > > > > > > > > > > > > > > > >Let us say that you mandate T.140/RFC 2793 for all SIP > > > > > > > > phones and do > > > > > > > > > >not mandate TTY passthrough. > > > > > > > > > > > > > > > > > > > >Let us say the call originates from a PSTN TTY and is > > > > > > routed via > > > > > > > > > a gatewayt > > > > > > > > > > o a SIP phone, which has native RFRC2793-based text > > > > > > > > > > capabilities. > > > > > > > > > > > > > > > > > > > >SG16/Q11 has struggled with the fact that you > cannot always > > > > > > > > > discriminate aT > > > > > > > > > > TY call from a non-TTY call when V.21 or V.23 > > > > > > > > modulations are used. > > > > > > > > > >In this case, there is no basis for the gateway to > > > convert the > > > > > > > > > >PSTN > > > > > > > > > TTY signali > > > > > > > > > > nto RFC 2793/T.140. However, the gateway can determi= ne > > > > > > > > that this is > > > > > > > > > >a modulated signal based on answer tone (if > present) or on > > > > > > > > specific > > > > > > > > > >FSK frequencies. It can use VBD passthrough (G.711) in > > > > > > > > this case but > > > > > > > > > >not RFC 2793 since it does not know if the V.21/V.23 > > > > > > > > signal is text > > > > > > > > > >or not. > > > > > > > > > > > > > > > > > > > >Ergo, we cannot preclude a requirement for G.711 VBD > > > > > > passthrough > > > > > > > > > support onS > > > > > > > > > > IP phones in favor of T.140. You can mandate both as > musts, > > > > > > > > > but you cannoth > > > > > > > > > > ave an interoperable solution if you do not have > > > passthrough. > > > > > > > > > > > > > > > > > > > >Rajesh > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >At 04:02 PM 7/1/2003 +0200, A vWijk wrote: > > > > > > > > > > >Paul, > > > > > > > > > > >How do you feel by mandating T.140/RTP along > with the TTY > > > > > > > > > passthrough on> > > > > > > > > > > IP telephones and such? > > > > > > > > > > >The technology is then ready for the T.140 usage. > > > > > > Which may be > > > > > > > > > very very> > > > > > > > > > > rapidly! > > > > > > > > > > >And remember..as I am stating over and over again. > > > RFC2793 is > > > > > > > > > NOT limited> > > > > > > > > > > for the hearing impaired users only! > > > > > > > > > > >Many other services will be possible with text > > > conversation. > > > > > > > > > > >And that will likely stimulate the acceptance of T.1= 40 > too. > > > > > > > > > > > > > > > > > > > > > >And if we explain the goal of T.140 and the > possibilities. > > > > > > > > > Then I do not> > > > > > > > > > > see any problems for the governments to subsidize th= is > > > > > > > > > development and buy> > > > > > > > > > > IP telephones for the hearing impaired. > > > > > > > > > > >Ofcourse, we have to guarantee the legacy TTY > > > > > > support. But also > > > > > > > > > > >that it has to be phased out. > > > > > > > > > > > > > > > > > > > > > >Please do not lock out T.140 by mandating TTY voice > > > > > > > > > fallback/passthrough> > > > > > > > > > > for IP telephones and clients/servers etc. > > > > > > > > > > > > > > > > > > > > > >greetz > > > > > > > > > > > > > > > > > > > > > >Arnoud van Wijk > > > > > > > > > > > > > > > > > > > > > ><<< "Paul E. Jones" 7/ 1 > > > 5:47a >>> > > > > > > > > > > >Rajesh, > > > > > > > > > > > > > > > > > > > > > >I agree with your concerns. Also, I think the case = is > even > > > > > > > > > stronger for > > > > > > > > > > >other countries where such issues are as thoughtfull= y > > > > > > > > > considered. I really > > > > > > > > > > >doubt that we'll see any requirements in many > countries. > > > > > > > > > > > > > > > > > > > > > >Another factor is cost. It might be a small > > > > > > per-unit cost to > > > > > > > > > > >include necessary support, but even if it is $10, > > > > > > $10 times the > > > > > > > > > > >number > > > > > > > > > of devices a > > > > > > > > > > >large, mass manufacturing company will produce in a > > > > > > > > > > >highly-competitive, low-margin environment becomes a > > > > > > > > major issue. > > > > > > > > > > >Thus, there will be a push-back from the extremely > > > > > > high-volume > > > > > > > > > > >manufacturers, I think. > > > > > > > > > > > > > > > > > > > > > >Considering all things, what I think the best > roadmap is: > > > > > > > > > > > 1) Create devices that are dual TTY/T.140 devices > > > > > > that work > > > > > > > > > on PSTN or > > > > > > > > > >IP > > > > > > > > > > > 2) Make sure every IP phone, residential > > > gateway / analog > > > > > > > > > > >terminal adapter, etc. > > > > > > > > > > > can properly carry TTY signals, modem signals, > > > > > > > > fax, etc. and that > > > > > > > > > > > a standard TTY device can interface with said > device > > > > > > > > > > > > > > > > > > > > > >Over time, we may see increased support for T.140 > > > > > > > > natively on every > > > > > > > > > > >IP phone. But, I really suspect that for a long > > > > > > time to come, > > > > > > > > > (2) is going to > > > > > > > > > > >be extremely important. Even so, with (1) in > existence, > > > > > > > > it means > > > > > > > > > > >that people can start to take advantage of T.140 as > > > > > > soon as the > > > > > > > > > devices are put > > > > > > > > > > >into their hands... and so the transition begins. > > > > > > > > > > > > > > > > > > > > > >Paul > > > > > > > > > > > > > > > > > > > > > >----- Original Message ----- > > > > > > > > > > >From: "Rajesh Kumar" > > > > > > > > > > >To: "A vWijk" > > > > > > > > > > >Cc: ; ; > > > > > > > > > > >; ; > > > > > > > > > ; > > > > > > > > > > >; ; > ; > > > > > > > > > > >; > > > > > > ; > > > > > > > > > > >; > > > > > > ; > > > > > > > > > > >; ; > > > > > > > > > > >; ; > > > > > > > > > > > > > > > > > > > >Sent: Monday, June 30, 2003 11:21 PM > > > > > > > > > > >Subject: Re: SV: SV: Internet draft on real time tex= t > > > > > > > > conversation > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Dr. van Wijk, > > > > > > > > > > > > > > > > > > > > > > > > While I support your sentiments, are you sure tha= t > > > > > > > > > governments all over > > > > > > > > > > >the > > > > > > > > > > > > world will provide these mobile text phones to th= e > > > > > > > > > hard-of-hearing on a > > > > > > > > > > > > subsidized basis? Also, the monthly plans that > > > go with it? > > > > > > > > > > > > > > > > > > > > > > > > While I do not know about other countries, > I seriously > > > > > > > > > doubt that the US > > > > > > > > > > > > will do such a thing in the near future. I think = the > US > > > > > > > > > deaf community > > > > > > > > > >is > > > > > > > > > > > > stuck with Baudot devices for a long time, > > > unless they can > > > > > > > > > afford PCs on > > > > > > > > > > > > their own budget.Probably a USB interface on > > > the SIP phone > > > > > > > > > to a cheap > > > > > > > > > > > > device is probably the best shot at universal > > > > > > > > > accessibility. Even so, I > > > > > > > > > > > > doubt if the US government will subsidize the SIP > > > > > > > > phone + keypad > > > > > > > > > > > > + > > > > > > > > > >screen > > > > > > > > > > > > combo, even it is cheaper that the Baudot TTY. T= his > > > > > > > > is because > > > > > > > > > > > > this > > > > > > > > > >would > > > > > > > > > > > > entail a mass replacement for thousands of > > > > > > existing Baudot > > > > > > > > > > > > devices. > > > > > > > > > > > > > > > > > > > > > > > > I might be wrong - I hope I am. > > > > > > > > > > > > > > > > > > > > > > > > Rajesh > > > > > > > > > > > > > > > > > > > > > > > > At 12:33 PM 6/26/2003 +0200, A vWijk wrote: > > > > > > > > > > > > >Paul, > > > > > > > > > > > > >I am also looking at a larger scale. > > > > > > > > > > > > >Imagine that 3 companies > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >******************************************************************* > > > > > > > > >** > > > > > > > > > >*** > > > > > > > > > >This email and any files transmitted with it are > > > > > > confidential and > > > > > > > > > >intended solely for the use of the individual or > > > > > > entity to whom > > > > > > > > > >they are addressed. Any views or opinions expressed > > > are solely > > > > > > > > > >those of the author and do not necessarily represent > > > > > > RNID policy. > > > > > > > > > > > > > > > > > > > >If you are not the intended recipient you are > advised that > > > > > > > > any use, > > > > > > > > > >dissemination, forwarding, printing or copying of this > > > > > > email is > > > > > > > > > >strictly prohibited. > > > > > > > > > > > > > > > > > > > >If you have received this email in error please notify > > > > > > the RNID > > > > > > > > > >Helpdesk by telephone on: +44 (0) 207 296 8282. > > > > > > > > > > > > > > > > > > > >The Royal National Institute for Deaf People > > > > > > > > > >Registered Office 19-23 Featherstone Street > > > > > > > > > >London EC1Y 8SL No. 454169 (England) > > > > > > > > > >Registered Charity No. 207720 > > > > > > > > > > > > > > > > > > > > > > > > >******************************************************************* > > > > > > > > >** > > > > > > > > > >*** > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 14 06:28: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 GAA05626 for ; Mon, 14 Jul 2003 06:28: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 19c0YK-0000ma-Ji for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 06:27:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EARSrW002980 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 06:27:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0YJ-0000ls-RH for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 06:27: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 GAA05519 for ; Mon, 14 Jul 2003 06:27:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c0YC-0003qi-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 06:27:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c0YA-0003qa-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 06:27:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0Y3-0000a5-7L; Mon, 14 Jul 2003 06:27:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bgyv-0007EC-VR for sipping@optimus.ietf.org; Sun, 13 Jul 2003 09:33: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 JAA20569 for ; Sun, 13 Jul 2003 09:33:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bgyu-0004KF-00 for sipping@ietf.org; Sun, 13 Jul 2003 09:33:36 -0400 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by ietf-mx with esmtp (Exim 4.12) id 19bgyt-0004Jp-00 for sipping@ietf.org; Sun, 13 Jul 2003 09:33:35 -0400 Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HHY00CAVTEEAY@firewall.wcom.com> for sipping@ietf.org; Sun, 13 Jul 2003 13:27:50 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HHY00A01TE96M@pmismtp04.wcomnet.com>; Sun, 13 Jul 2003 13:27:50 +0000 (GMT) Received: from hsinnreich2 ([166.50.104.120]) by pmismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HHY0090ST5Y2G@pmismtp04.wcomnet.com>; Sun, 13 Jul 2003 13:27:48 +0000 (GMT) Date: Sun, 13 Jul 2003 15:22:47 +0200 From: Henry Sinnreich In-reply-to: To: "'Gunnar Hellstrom'" , "'Henry Sinnreich'" , Guido.Gybels@rnid.org.uk, mike.spanner@rnid.org.uk, andreas.piirimets@omnitor.se, gv@trace.wisc.edu, trefor@trefor.plus.com, "'Rajesh Kumar'" , marcelo@envilogg.se, jorgen.bjorkner@hotsip.com, "'James Hamlin'" , Erik.Zetterstrom@omnitor.se, hwildfeu@cisco.com, paulej@packetizer.com, barry.dingle@bigfoot.com.au, mgarakan@cisco.com, oran@cisco.com, rohan@cisco.com, sipping@ietf.org Message-id: <00ae01c34942$8d6bd770$8ab8a051@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Subject: [Sipping] RE: items for vor voting in the BOF Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 From: Marcia Beaulieu [mbeaulie@foretec.com] Sent: Tuesday, July 08, 2003 5:04 PM To: Henry Sinnreich; 'Dean Willis'; 'Henry Sinnreich'; agenda@ietf.org Cc: rohan@cisco.com; gonzalo.camarillo@ericsson.com Subject: RE: Request for ad-hoc meeting on interactive text in SIP devices Meeting rooms at the Austria Center are not available after the regularly scheduled meetings. We are charged rent for the rooms and we do not rent them longer than what is needed. Marcia At 02:54 PM 7/2/03 -0500, Henry Sinnreich wrote: > > Would an evening "after hours" schedule work? > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Jul 14 06:28: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 GAA05652 for ; Mon, 14 Jul 2003 06:28: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 19c0YU-0000sY-5f for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 06:27:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EARcvX003367 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 06:27:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0YU-0000sA-1g for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 06:27: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 GAA05546 for ; Mon, 14 Jul 2003 06:27:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c0YP-0003rj-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 06:27:33 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c0YD-0003qn-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 06:27:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0Y1-0000ZH-Kk; Mon, 14 Jul 2003 06:27:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19beXX-0002gY-KK for sipping@optimus.ietf.org; Sun, 13 Jul 2003 06:57: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 GAA11348 for ; Sun, 13 Jul 2003 06:57:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19beXT-0001yn-00 for sipping@ietf.org; Sun, 13 Jul 2003 06:57:07 -0400 Received: from mail3.pi.se ([195.7.64.137]) by ietf-mx with esmtp (Exim 4.12) id 19beXS-0001yZ-00 for sipping@ietf.org; Sun, 13 Jul 2003 06:57:06 -0400 Received: from VAIOMHP (1Cust38.tnt2.stk3.swe.da.uu.net [213.116.227.38]) (authenticated) by mail3.pi.se (8.11.2/8.11.2) with ESMTP id h6DAu8700383; Sun, 13 Jul 2003 12:56:09 +0200 (CEST) From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= To: "Rohan Mahy" Cc: "A vWijk" , , , , , , , , , , , , , , , , , Date: Sun, 13 Jul 2003 12:55:52 +0200 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.2910.0) Importance: Normal In-Reply-To: <2A24E1C8-B4AD-11D7-9589-0003938AF740@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.pi.se id h6DAu8700383 Content-Transfer-Encoding: quoted-printable Subject: [Sipping] SV: SV: SV: items for vor voting in the BOF Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 Rohan, thanks. In my understanding of the BCP type of document, it could give the type of guidance that is intended by the SIPDEV spec as well as = the SIP based text conversation spec. Giving easyly found advice for something that is already standardised in many places, and thereby increase opportunity for interoperability and suitable functionality. Regards Gunnar ------------------------------------------- Gunnar Hellstr=F6m, Omnitor, Renathv=E4gen 2 SE 121 37 Johanneshov, SWEDEN Tel: +46 8 556 002 03 Mob: +46 708204288 e-mail: gunnar.hellstrom@omnitor.se web: www.omnitor.se > -----Ursprungligt meddelande----- > Fr=E5n: Rohan Mahy [mailto:rohan@cisco.com] > Skickat: den 12 juli 2003 23:10 > Till: Gunnar Hellstr=F6m > Kopia: A vWijk; barry.dingle@bigfoot.com.au; hwildfeu@cisco.com; > mgarakan@cisco.com; oran@cisco.com; rkumar@cisco.com; > marcelo@envilogg.se; jorgen.bjorkner@hotsip.com; sipping@ietf.org; > Henry.Sinnreich@mci.com; andreas.piirimets@omnitor.se; > Erik.Zetterstrom@omnitor.se; paulej@packetizer.com; > Guido.Gybels@rnid.org.uk; James.Hamlin@rnid.org.uk; > mike.spanner@rnid.org.uk; gv@trace.wisc.edu; trefor@trefor.plus.com > =C4mne: Re: SV: SV: items for vor voting in the BOF > > > Gunnar, > > Both these issues will be discussed in an adhoc meeting or "bar-bof" in > Vienna. No date or place is scheduled because the IETF secretariat has > to pay by the hour this time for the rooms in the congress center. > (Normally they pay a flat rate for the exclusive use of certain rooms > for the entire week.) This will probably occur offsite. I believe that > Henry is still looking for a location. Assuming he comes up with > something suitable, I will announce the adhoc at the start of the > SIPPING meeting and post a note to the mailing list. > > Also, as I stated before, sipdev is an individual informational > document meant to provide guidance to the industry, but is not > specifically endorsed by the IETF or any WG. (IETF WGs generally do > not endorse implementation recommendations). It is not a formal > specification in the IETF sense. Also, the term BOF is used formally by > the IETF in a very specific way, which does not apply to this meeting. > The official term is "adhoc". > > hope this helps. > thanks, > -rohan > > On Friday, July 11, 2003, at 08:31 AM, Gunnar Hellstr=F6m wrote: > > > Rohan or anyone who knows: > > > > Do we have a fixed day and time for the following items in the coming > > IETF > > meeting? > > > > 1. The discussion of the text and alerting additions in the SIPDEV > > specification. > > > > 2. A BOF session on SIP text conversation. > > > > I will not come, but there is a slight possibility that Erik > > Zetterstr=F6m can > > go there for these discussions. Erik has just done an RFC2793 > > implementation > > in JAVA, and is co-author of the draft BCP. > > > > Regards > > > > Gunnar > > ------------------------------------------- > > Gunnar Hellstr=F6m, Omnitor, Renathv=E4gen 2 > > SE 121 37 Johanneshov, SWEDEN > > Tel: +46 8 556 002 03 Mob: +46 708204288 > > e-mail: gunnar.hellstrom@omnitor.se > > web: www.omnitor.se > > > > > >> -----Ursprungligt meddelande----- > >> Fr=E5n: A vWijk [mailto:A.vWijk@viataal.nl] > >> Skickat: den 11 juli 2003 10:52 > >> Till: barry.dingle@bigfoot.com.au; hwildfeu@cisco.com; > >> mgarakan@cisco.com; oran@cisco.com; rkumar@cisco.com; rohan@cisco.co= m; > >> marcelo@envilogg.se; jorgen.bjorkner@hotsip.com; sipping@ietf.org; > >> Henry.Sinnreich@mci.com; andreas.piirimets@omnitor.se; > >> Erik.Zetterstrom@omnitor.se; gunnar.hellstrom@omnitor.se; > >> paulej@packetizer.com; Guido.Gybels@rnid.org.uk; > >> James.Hamlin@rnid.org.uk; mike.spanner@rnid.org.uk; gv@trace.wisc.ed= u; > >> trefor@trefor.plus.com > >> =C4mne: Re: SV: items for vor voting in the BOF > >> > >> > >> Yes, > >> we must take some time to see what exactly needs to be covered > >> and what kind of behaviour we need. > >> I wil make sure that the authors of the Invocation draft > >> camarillo-deaf-01 will understand that the role is getting bigger > >> here. > >> > >> The role of the PSTN will be important and also the role of the > >> gateways for backward compatibility to legacy TTY's. > >> > >> I will be at the IETF, so please feel free to grab me when you > >> see me. I am the only deaf guy around there. So it should be easy. := -) > >> > >> greetz > >> > >> Arnoud > >> > >> <<< Gunnar Hellstr=F6m 7/11 12:14a >>= > > >> > >> > >> > >> > > > > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 14 06:28: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 GAA05651 for ; Mon, 14 Jul 2003 06:28: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 19c0YT-0000q4-FQ for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 06:27:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EARbFA003207 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 06:27:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0YT-0000pb-8m for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 06: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 GAA05541 for ; Mon, 14 Jul 2003 06:27:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c0YO-0003rh-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 06:27:33 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c0YC-0003r5-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 06:27:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0Y5-0000bN-QJ; Mon, 14 Jul 2003 06:27:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bzfU-00062x-MM for sipping@optimus.ietf.org; Mon, 14 Jul 2003 05:30: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 FAA03681 for ; Mon, 14 Jul 2003 05:30:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bzfR-0003JK-00 for sipping@ietf.org; Mon, 14 Jul 2003 05:30:45 -0400 Received: from blitzen.doit.wisc.edu ([144.92.197.183] helo=smtp3.doit.wisc.edu) by ietf-mx with esmtp (Exim 4.12) id 19bzfQ-0003JH-00 for sipping@ietf.org; Mon, 14 Jul 2003 05:30:44 -0400 Received: from conversion-daemon.smtp3.doit.wisc.edu by smtp3.doit.wisc.edu (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) id <0HI000D01D1KQ8@smtp3.doit.wisc.edu> for sipping@ietf.org; Mon, 14 Jul 2003 04:30:44 -0500 (CDT) Received: from USD320002X (000-050-839.area3.spcsdns.net [68.24.200.40]) by smtp3.doit.wisc.edu (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPA id <0HI000LVND2SH2@smtp3.doit.wisc.edu>; Mon, 14 Jul 2003 04:30:44 -0500 (CDT) Date: Mon, 14 Jul 2003 04:30:24 -0500 From: Gregg Vanderheiden In-reply-to: <60ab7dbc.a335acbc.8165f00@imap01.eu.blackberry.net> To: guido.gybels@rnid.org.uk Cc: "'Henry Sinnreich'" , "'Gunnar Hellstrom'" , mike.spanner@rnid.org.uk, 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, paulej@packetizer.com, barry.dingle@bigfoot.com.au, mgarakan@cisco.com, oran@cisco.com, rohan@cisco.com, sipping@ietf.org Reply-to: gv@trace.wisc.edu Message-id: <000c01c349ea$98bc2d70$28c81844@USD320002X> Organization: Trace Center MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Sipping] RE: items for vor voting in the BOF Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 Is Gunnar's the version that will be used? Did you mean the BCP document? Or an earlier doc? (I looked and couldn't find one - that wasn't comments on comments. Gunnar won't be there -- so I was wondering (from the person that will be presenting this) what form would be presented. thx Gregg -- ------------------------------ Gregg C Vanderheiden Ph.D. Professor - Ind. Engr. & BioMed Engr. Director - Trace R & D Center University of Wisconsin-Madison -----Original Message----- From: Guido Gybels [mailto:ggybels@webclient.eu.blackberry.net] Sent: Monday, July 14, 2003 3:48 AM To: gv@trace.wisc.edu Cc: 'Henry Sinnreich'; 'Gunnar Hellstrom'; Guido.Gybels@rnid.org.uk; mike.spanner@rnid.org.uk; andreas.piirimets@omnitor.se; gv@trace.wisc.edu; trefor@trefor.plus.com; 'Rajesh Kumar'; marcelo@envilogg.se; jorgen.bjorkner@hotsip.com; 'James Hamlin'; Erik.Zetterstrom@omnitor.se; hwildfeu@cisco.com; paulej@packetizer.com; barry.dingle@bigfoot.com.au; mgarakan@cisco.com; oran@cisco.com; rohan@cisco.com; sipping@ietf.org Subject: RE: items for vor voting in the BOF Gregg, I think Gunnar's version was quite clear and straight forward, I don't think we should complicate things any further. So, I would suggest we use Gunnar's version. Guido _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 14 06:28: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 GAA05654 for ; Mon, 14 Jul 2003 06:28: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 19c0YU-0000t0-Cv for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 06:27:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EARcZ5003401 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 06:27:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0YU-0000si-8Q for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 06:27: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 GAA05553 for ; Mon, 14 Jul 2003 06:27:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c0YP-0003rp-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 06:27:33 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c0YK-0003qk-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 06:27:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0Xu-0000W2-Vk; Mon, 14 Jul 2003 06:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aVO7-0004Ve-6M for sipping@optimus.ietf.org; Thu, 10 Jul 2003 02:58: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 CAA20183 for ; Thu, 10 Jul 2003 02:58:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aVO3-0007kt-00 for sipping@ietf.org; Thu, 10 Jul 2003 02:58:39 -0400 Received: from mail3.pi.se ([195.7.64.137]) by ietf-mx with esmtp (Exim 4.12) id 19aVO1-0007ko-00 for sipping@ietf.org; Thu, 10 Jul 2003 02:58:37 -0400 Received: from VAIOMHP (1Cust23.tnt2.stk3.swe.da.uu.net [213.116.227.23]) (authenticated) by mail3.pi.se (8.11.2/8.11.2) with ESMTP id h6A6veR28092; Thu, 10 Jul 2003 08:57:41 +0200 (CEST) From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= To: "Paul E. Jones" , "Henry Sinnreich" , , , , , , "'Rajesh Kumar'" , , , "'James Hamlin'" , , , , , , , Date: Thu, 10 Jul 2003 08:57:20 +0200 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <023a01c3463c$896add50$0401a8c0@packetizer.org> Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.pi.se id h6A6veR28092 Content-Transfer-Encoding: quoted-printable Subject: [Sipping] SV: items for vor voting in the BOF Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 Please do not complicate this. I made a simple summary of the discussion that gave the meeting a simple set of choices. Now it is at risk to devia= te again. We have to keep this clear and simple, and not give the impression to the industry that this is a big complication so that the whole package of accessibility issues is thrown out. What I especially want to prevent is that #1 and #2 are lost because we h= ave so many other requirements in the list. Please stick to the origingal for the voting and proposals in the IETF meeting. I comment the proposals inline. Gunnar ------------------------------------------- Gunnar Hellstr=F6m, Omnitor, Renathv=E4gen 2 SE 121 37 Johanneshov, SWEDEN Tel: +46 8 556 002 03 Mob: +46 708204288 e-mail: gunnar.hellstrom@omnitor.se web: www.omnitor.se > -----Ursprungligt meddelande----- > Fr=E5n: Paul E. Jones [mailto:paulej@packetizer.com] > Skickat: den 9 juli 2003 19:07 > Till: Henry Sinnreich; 'Gunnar Hellstrom'; Guido.Gybels@rnid.org.uk; > mike.spanner@rnid.org.uk; andreas.piirimets@omnitor.se; > gv@trace.wisc.edu; 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; > rohan@cisco.com; sipping@ietf.org > =C4mne: Re: items for vor voting in the BOF > > > Henry, > > I made a number of comments on the previous proposal. Specifically, I = did > not want to see #3 as it was written. T.38 AND V.18 are entirely > separate. Gunnar> They both rely on the complication to include analogue phone connector and modem technology. They are both FSK modems in the base. I agree that the logic on top of that is different, but the complexity of T= .38 is at least 10 times more than V.18 plus T.140 and RFC2793. > Further, if we allow for VBD operation for TTY devices connected via RJ= 11, > then V.18 would not be something the phone needs to be complicated with. Gunnar> No, that is not right. VBD just takes the tones as they are and transport them to the other end. What shall we do with these tones if the= y are sent to a proper SIP textphone? You need to adapt to the habit in the network you are, and create compatibility, not offer fragmentation. > Realizing that this is a vote on a number of issues, I'd like to more > clearly separate the issues. I removed one sentence that caused > concern for > Gunnar related to V.21/V.23. Thus, please replace #3 with: > > 3. MUST/SHOULD provide an interface to legacy TTY devices and transport > those signals as RFC 2793 text Gunnar> We should not use the term TTY. That is a local American term, no= t understood elsewhere. Text telephone is the agreed term. > > 4. MUST/SHOULD provide an interface to legacy TTY devices and allow > transparent carriage of the TTY protocol through the audio path > ("pass-through" mode) Gunnar> Same comment about TTY > > 5. MUST/SHOULD provide an RJ11 port for interfacing with legacy > TTY devices, > fax devices, modems, and other legacy equipment for the purposes of > supporting the transfer of information from/to those legacy devices. > > 6. MUST/SHOULD provide a 2.5mm audio plug for interfacing with a > headset or > legacy TTY device > > Note that #5 gets into the area of V.150 modem relay and pass-through, = as > well as T.38 fax relay. That came from the original #3. > However, I do not > see the value in spelling out those protocols for the purposes of > this vote. > > Also, in #2, there is still a reference to a web interface. I > said I don't > think that's necessary, since if one can access the web interface, he/s= he > can probably just use a PC for communication. However, they may not be > true. In any case, I can see the web interface as "interesting", but > certainly could not see mandating it. Also, I don't agree with > the comment > about blind people needing a keyboard and screen. Gunnar> The comment was that blind people need a way to get an electronic interface to the input and output for operations of the phone. They probably need to get the user interface device themselves, but need = the standardised interface on the phone. The same interface should be possibl= e to use for text input and display. I agree that the comment does not need to be there in the text, it was me= ant to be for clarification in the discussion, but apparently was not clear enough. > I propose > rewording #2 as > follows: > > 2. MUST/SHOULD provide a way to input text and display text, through an= y > method: Built in user interfaces, standard wired or wireless interfa= ces > for > keyboard and display, or support for text through its web interface. > > OR, better: > > 2A. MUST/SHOULD provide a way to input text and display text > through either > a > built in user interfaces or standard wired or wireless interfaces > (including a screen and keyboard) > > 2B. MUST/SHOULD provide a way to input text and display text through it= s > web interface. > > Paul > > ----- Original Message ----- > From: "Henry Sinnreich" > To: "'Gunnar Hellstrom'" ; > ; ; > ; ; > ; "'Rajesh Kumar'" ; > ; ; "'James Hamlin'" > ; ; > ; ; > ; ; ; > ; > Sent: Sunday, July 06, 2003 4:14 PM > Subject: RE: items for vor voting in the BOF > > > > Please see the attached slide for voting at the IETF BOF on "Interact= ive > > Text Support for SIP Telephony Devices". > > > > We have no day/time yet for the BOF, but expect to get it scheduled, = as > > discussed with Rohan Mahy. > > > > Many thanks to Gunnar Hellstrom for the formulation of the text. > > > > Thanks, Henry > > > > > -----Original Message----- > > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > > > Sent: Wednesday, July 02, 2003 3:44 AM > > > To: Henry Sinnreich > > > Cc: trefor@trefor.plus.com; gv@trace.wisc.edu; > > > mike.spanner@rnid.org.uk; Guido.Gybels@rnid.org.uk; > > > Erik.Zetterstrom@omnitor.se; 'Rajesh Kumar'; 'James Hamlin'; > > > andreas.piirimets@omnitor.se; jorgen.bjorkner@hotsip.com; > > > marcelo@envilogg.se; rohan@cisco.com; oran@cisco.com; > > > mgarakan@cisco.com; hwildfeu@cisco.com; > > > barry.dingle@bigfoot.com.au; paulej@packetizer.com > > > Subject: SV: items for vor voting in the BOF > > > > > > > > > Henry, > > > Yes please use the sentences in the IETF meeting, with no 3 > > > amended as below. > > > > > > Some thoughts an explanations: > > > > > > Blind reference: > > > ---------------- > > > The reference about display interface for blind people refers > > > to a need for blind people to follow hat is displayed on the > > > phone through a device of their choice. It may be voice > > > synthesis or electromechanical braille display or display > > > with enlargement or extra strong light. We do not expect the > > > phone to include these special devices, so a standardised > > > interface to them must be provided. The SIP phone will have > > > states so it will be impossible to expect that you shall be > > > able to operate it without feedback from the phone. The > > > mobile industry made the mistake to not initially provide a > > > standardised interface to operate the mobile phone and that > > > has caused enormous problems for blind people. The AT command > > > interface available to 3GPP mobile phones seem to have > > > overcome this mistake by including commands and responses for > > > accessing most things required for operation through a serial > > > command language that can be issued through Bluetooth or a > > > USB or serial connector. Products are emerging. Something > > > similar must be done on SIP phones. I concentrated on deaf > > > issues, but I see that we have common interests here. > > > > > > The web interface: > > > ------------------ > > > I saw a comment that the web interface should not be > > > mentioned as a solution. That may be true, it was with > > > hesitation that I added it. But: I have seen SIP phones with > > > the possibility to add the video component from a nearby > > > computer. Similar things can be done for text. It is still > > > valid to let the phone have all the other SIP phone > > > functionality. I can imagine PDA access through Bluetooth > > > executing a web browser to operate the phone. The text > > > component could be accessible through that interface. > > > Handling only the user interface aspect of the text part is > > > an enormous difference from handling the complete SIP > > > protocol and all audio coding. The sum is of course that when > > > we open for many ways to add text and that the person > > > carrying a text interface with him, will find that it can not > > > be attached to any phone, and then accessibility is again > > > limited. I am quite sure that phones will not come without > > > display, and that they will follow the trend on PDAs and > > > mobile phones, to include a full aphanumeric keyboard because > > > it is needed for address and phonebook use, as well as to > > > provide a good user interface to the very popular real time > > > text conversation function ;-) . So, I am not too worried > > > that we give many options. > > > > > > > > > The analogue interface. > > > ----------------------- > > > The statement no 3 about the analogue adapter is not really > > > formulated in a strict IETF style. A starting sentence is needed: > > > > > > 3. A SIP device MAY provide analogue adapter functionality > > > through an RJ11 port. IF an RJ11 port is provided for a PSTN > > > device adapter interface, THEN it MUST/SHOULD provide T.38 > > > support for fax AND V.18+RFC2793 support for text alternating > > > with voice. If T.38 or RFC2793 negotiation fails then it MAY > > > try to connect for G.711 and pass the audio through. > > > > > > > > > > > > > > > ------------------------------------------- > > > Gunnar Hellstrom, Omnitor, Renathvagen 2 > > > SE 121 37 Johanneshov, SWEDEN > > > Tel: +46 8 556 002 03 Mob: +46 708204288 > > > e-mail: gunnar.hellstrom@omnitor.se > > > web: www.omnitor.se > > > > > > > > > > -----Ursprungligt meddelande----- > > > > Fran: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com] > > > > Skickat: den 2 juli 2003 02:27 > > > > Till: 'Gunnar Hellstrom' > > > > Kopia: paulej@packetizer.com; barry.dingle@bigfoot.com.au; > > > > hwildfeu@cisco.com; mgarakan@cisco.com; oran@cisco.com; > > > > rohan@cisco.com; marcelo@envilogg.se; jorgen.bjorkner@hotsip.com; > > > > Henry.Sinnreich@mci.com; andreas.piirimets@omnitor.se; > > > 'James Hamlin'; > > > > 'Rajesh Kumar'; Erik.Zetterstrom@omnitor.se; > > > Guido.Gybels@rnid.org.uk; > > > > mike.spanner@rnid.org.uk; gv@trace.wisc.edu; trefor@trefor.plus.c= om > > > > Amne: items for vor voting in the BOF > > > > > > > > > > > > Gunnar, > > > > > > > > I will use with your permission your formulation to put these thr= ee > > > > items to vote in the BOF, for MUST or SHOULD: > > > > > > > > 1. MUST/SHOULD include protocol support for RFC2793 for text. > > > > > > > > 2. MUST/SHOULD provide a way to input text and display > > > text, through > > > > any > > > > method: Built in user interfaces, standard wired or > > > wireless interfaces > > > > for keyboard and display ( that is needed anyway for blind > > > people), or > > > > support for text through its already mandated web interface. > > > > > > > > ---- > > > > And, with some doubt: > > > > > > > > 3. IF an RJ11 port is provided for a PSTN device adapter interfac= e, > > > > THEN it MUST/SHOULD provide T.38 support for fax AND V.18+RFC2793 > > > > support for text alternating with voice. If T.38 or RFC2793 > > > > negotiation fails then it MAY try to connect for G.711 and pass t= he > > > > audio through.( is there any need to mandate also modem support? = ) > > > > > > > > I believe these are very reasonable requirements. > > > > > > > > Thanks, Henry > > > > > > > > > -----Original Message----- > > > > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > > > > > Sent: Tuesday, July 01, 2003 4:08 PM > > > > > To: Rajesh Kumar; James Hamlin > > > > > Cc: paulej@packetizer.com; barry.dingle@bigfoot.com.au; > > > > > hwildfeu@cisco.com; mgarakan@cisco.com; oran@cisco.com; > > > > > rohan@cisco.com; marcelo@envilogg.se; jorgen.bjorkner@hotsip.co= m; > > > > > Henry.Sinnreich@mci.com; andreas.piirimets@omnitor.se; > > > > > Erik.Zetterstrom@omnitor.se; Guido.Gybels@rnid.org.uk; > > > > > mike.spanner@rnid.org.uk; gv@trace.wisc.edu; > > > trefor@trefor.plus.com > > > > > Subject: SV: SV: SV: Internet draft on real time text conversat= ion > > > > > > > > > > > > > > > I see the discussion going in circles. > > > > > > > > > > Henry gave me the delicate task to sum up and get a > > > proposed writing > > > > > into the Sipdev specification. > > > > > > > > > > After looking back in the discussion, I come to the > > > conclusion that, > > > > > the only requirements that make real sense and takes deaf > > > telecomms > > > > > a bit towards equal opportunities is that SIP devices: > > > > > > > > > > 1. MUST include protocol support for RFC2793 for text. > > > > > > > > > > 2. MUST provide a way to input text and display text, through a= ny > > > > > method: Built in user interfaces, standard wired or wireless > > > > > interfaces for keyboard and display ( that is needed anyway for > > > > > blind people), or support for text through its already > > > mandated web > > > > > interface. > > > > > > > > > > ---- > > > > > And, with some doubt: > > > > > > > > > > 3. IF an RJ11 port is provided for a PSTN device adapter > > > interface, > > > > > THEN it MUST provide T.38 support for fax AND > > > V.18+RFC2793 support > > > > > for text alternating with voice. If T.38 or RFC2793 negotiation > > > > > fails then it MAY try to connect for G.711 and pass the audio > > > > > through.( is there any need to mandate also modem support? ) > > > > > > > > > > > > > > > > > > > > ---- > > > > > I am sure SIP signaling can take care of most tricky > > > situations that > > > > > have been up for discussion. > > > > > > > > > > E.g. > > > > > A SIP phone without RJ11 port in contact with a PSTN > > > device through > > > > > a gateway, would signal RFC2793 capability. That will > > > make a gateway > > > > > involved in the call perceive any indication on use of modem-li= ke > > > > > tones from PSTN as text if possible. > > > > > > > > > > > > > > > > > > > > I intend to propose text with that content soon for the > > > sipdev spec. > > > > > > > > > > With that, we could perhaps change topic to discuss > > > contents of the > > > > > text capable device I-D that Erik and Andreas made a > > > first draft of. > > > > > > > > > > Has time been booked in the SIPPING meeting in Wienna to discus= s > > > > > that? > > > > > > > > > > Can Erik and Andreas provide us with a second draft? > > > > > > > > > > Best regards > > > > > > > > > > Gunnar > > > > > > > > > > > > > > > ------------------------------------------- > > > > > Gunnar Hellstrom, Omnitor, Renathvagen 2 > > > > > SE 121 37 Johanneshov, SWEDEN > > > > > Tel: +46 8 556 002 03 Mob: +46 708204288 > > > > > e-mail: gunnar.hellstrom@omnitor.se > > > > > web: www.omnitor.se > > > > > > > > > > > > > > > > -----Ursprungligt meddelande----- > > > > > > Fran: Rajesh Kumar [mailto:rkumar@cisco.com] > > > > > > Skickat: den 1 juli 2003 19:15 > > > > > > Till: James Hamlin > > > > > > Kopia: paulej@packetizer.com; barry.dingle@bigfoot.com.au; > > > > > > hwildfeu@cisco.com; mgarakan@cisco.com; oran@cisco.com; > > > > > > rohan@cisco.com; marcelo@envilogg.se; > > > jorgen.bjorkner@hotsip.com; > > > > > > Henry.Sinnreich@mci.com; andreas.piirimets@omnitor.se; > > > > > > Erik.Zetterstrom@omnitor.se; gunnar.hellstrom@omnitor.se; > > > > > > Guido.Gybels@rnid.org.uk; mike.spanner@rnid.org.uk; > > > > > gv@trace.wisc.edu; > > > > > > trefor@trefor.plus.com > > > > > > Amne: RE: SV: SV: Internet draft on real time text conversati= on > > > > > > > > > > > > > > > > > > James, > > > > > > > > > > > > The intent here is that the called party could be any SIP > > > > > phone, not > > > > > > just SIP phones specially designated for text-only > > > > > operation. I think > > > > > > the intent expressed by Guido and Gunnar et al is that a > > > > > PSTN TTY user > > > > > > should be able > > > > > > to open an RFC 2793 text channel with any SIP phone user, > > > > > and that the > > > > > > latter should either have an integral keyboard/display > > > or a port > > > > > > to such a display. So the problem of call > > > discrimination when the > > > > > > caller is a V.21 or > > > > > > V.23 legacy textphone is not solved unless you allow > > > > > passthrough fallback > > > > > > when you cannot tell whether the V.21 signal is text or not - > > > > > > regardless of the existence of gateways/servers that do PSTN > > > > > > textphone to RFC 2793 conversion. > > > > > > > > > > > > In general, the solution of designating special phone > > > numbers for > > > > > > deaf-accessible operation militates against the stipulation > > > > > that the > > > > > > deaf be able to create text channels from any PSTN or SIP pho= ne > > > > > > number, and to any PSTN or SIP phone number. Here, textphone > > > > > > detection has to be on the basis of control signals > > > > > exchanged in the > > > > > > bearer stream or on the content of the bearer stream, > > > and not on a > > > > > > priori numbering plans that create a "deaf ghetto". > > > > > > > > > > > > For technical reasons, I still think you must mandate > > > passthrough > > > > > > operation to enable universal interoperability. > > > > > > > > > > > > Kind regards to all. > > > > > > > > > > > > Rajesh > > > > > > > > > > > > > > > > > > > > > > > > At 04:33 PM 7/1/2003 +0100, James Hamlin wrote: > > > > > > >Rajesh > > > > > > > > > > > > > >It would be possible for people on the IP network to have PS= TN > > > > > > numbers that > > > > > > >are taken from a block that is assigned only to text. > > > Therefore > > > > > > the gateway > > > > > > >between PSTN and the IP network knows from the called number > > > > > > that the intent > > > > > > >is to use text. > > > > > > > > > > > > > >Regards > > > > > > > > > > > > > >James > > > > > > > > > > > > > >-----Original Message----- > > > > > > >From: Rajesh Kumar [mailto:rkumar@cisco.com] > > > > > > >Sent: 01 July 2003 16:05 > > > > > > >To: A vWijk > > > > > > >Cc: paulej@packetizer.com; barry.dingle@bigfoot.com.au; > > > > > > >hwildfeu@cisco.com; mgarakan@cisco.com; oran@cisco.com; > > > > > > >rohan@cisco.com; marcelo@envilogg.se; > > > jorgen.bjorkner@hotsip.com; > > > > > > >Henry.Sinnreich@mci.com; andreas.piirimets@omnitor.se; > > > > > > >Erik.Zetterstrom@omnitor.se; gunnar.hellstrom@omnitor.se; > > > > > > >Guido.Gybels@rnid.org.uk; james.hamlin@rnid.org.uk; > > > > > > >mike.spanner@rnid.org.uk; gv@trace.wisc.edu; > > > > > > >trefor@trefor.plus.com > > > > > > >Subject: Re: SV: SV: Internet draft on real time text > > > conversation > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> "rkumar@cisco.com" 07/01/03 16:04 >>> > > > > > > > > > > > > > >Arnoud, > > > > > > > > > > > > > >As I indicated in another email, interoperability with legac= y > > > > > > V.21 and V.23T > > > > > > > TY devices is not feasible unless you support a passthroug= h > > > > > > >fallback. I have no hidden agenda here, I am just presenting= a > > > > > > >technical difficulty that SG16/Q11 and TIA TR.30.1 have been > > > > > > >struggling with for the past 6 months. I do not know how > > > > > you can do > > > > > > >without TTY passthrough if you want universal > > > > > interoperability. Here > > > > > > >was my mail, sent yesterday: > > > > > > > > > > > > > >There is a real technical difficulty which I would want you = all > > > > > > to consider. > > > > > > > > > > > > > >Let us say that you mandate T.140/RFC 2793 for all SIP > > > > > phones and do > > > > > > >not mandate TTY passthrough. > > > > > > > > > > > > > >Let us say the call originates from a PSTN TTY and is > > > routed via > > > > > > a gatewayt > > > > > > > o a SIP phone, which has native RFRC2793-based text > > > > > > > capabilities. > > > > > > > > > > > > > >SG16/Q11 has struggled with the fact that you cannot always > > > > > > discriminate aT > > > > > > > TY call from a non-TTY call when V.21 or V.23 > > > > > modulations are used. > > > > > > >In this case, there is no basis for the gateway to convert t= he > > > > > > >PSTN > > > > > > TTY signali > > > > > > > nto RFC 2793/T.140. However, the gateway can determine > > > > > that this is > > > > > > >a modulated signal based on answer tone (if present) or on > > > > > specific > > > > > > >FSK frequencies. It can use VBD passthrough (G.711) in > > > > > this case but > > > > > > >not RFC 2793 since it does not know if the V.21/V.23 > > > > > signal is text > > > > > > >or not. > > > > > > > > > > > > > >Ergo, we cannot preclude a requirement for G.711 VBD > > > passthrough > > > > > > support onS > > > > > > > IP phones in favor of T.140. You can mandate both as musts= , > > > > > > but you cannoth > > > > > > > ave an interoperable solution if you do not have passthrou= gh. > > > > > > > > > > > > > >Rajesh > > > > > > > > > > > > > > > > > > > > > > > > > > > >At 04:02 PM 7/1/2003 +0200, A vWijk wrote: > > > > > > > >Paul, > > > > > > > >How do you feel by mandating T.140/RTP along with the TTY > > > > > > passthrough on> > > > > > > > IP telephones and such? > > > > > > > >The technology is then ready for the T.140 usage. > > > Which may be > > > > > > very very> > > > > > > > rapidly! > > > > > > > >And remember..as I am stating over and over again. RFC2793= is > > > > > > NOT limited> > > > > > > > for the hearing impaired users only! > > > > > > > >Many other services will be possible with text conversatio= n. > > > > > > > >And that will likely stimulate the acceptance of T.140 too. > > > > > > > > > > > > > > > >And if we explain the goal of T.140 and the possibilities. > > > > > > Then I do not> > > > > > > > see any problems for the governments to subsidize this > > > > > > development and buy> > > > > > > > IP telephones for the hearing impaired. > > > > > > > >Ofcourse, we have to guarantee the legacy TTY > > > support. But also > > > > > > > >that it has to be phased out. > > > > > > > > > > > > > > > >Please do not lock out T.140 by mandating TTY voice > > > > > > fallback/passthrough> > > > > > > > for IP telephones and clients/servers etc. > > > > > > > > > > > > > > > >greetz > > > > > > > > > > > > > > > >Arnoud van Wijk > > > > > > > > > > > > > > > ><<< "Paul E. Jones" 7/ 1 5:47a >= >> > > > > > > > >Rajesh, > > > > > > > > > > > > > > > >I agree with your concerns. Also, I think the case is eve= n > > > > > > stronger for > > > > > > > >other countries where such issues are as thoughtfully > > > > > > considered. I really > > > > > > > >doubt that we'll see any requirements in many countries. > > > > > > > > > > > > > > > >Another factor is cost. It might be a small > > > per-unit cost to > > > > > > > >include necessary support, but even if it is $10, > > > $10 times the > > > > > > > >number > > > > > > of devices a > > > > > > > >large, mass manufacturing company will produce in a > > > > > > > >highly-competitive, low-margin environment becomes a > > > > > major issue. > > > > > > > >Thus, there will be a push-back from the extremely > > > high-volume > > > > > > > >manufacturers, I think. > > > > > > > > > > > > > > > >Considering all things, what I think the best roadmap is: > > > > > > > > 1) Create devices that are dual TTY/T.140 devices > > > that work > > > > > > on PSTN or > > > > > > >IP > > > > > > > > 2) Make sure every IP phone, residential gateway / anal= og > > > > > > > >terminal adapter, etc. > > > > > > > > can properly carry TTY signals, modem signals, > > > > > fax, etc. and that > > > > > > > > a standard TTY device can interface with said device > > > > > > > > > > > > > > > >Over time, we may see increased support for T.140 > > > > > natively on every > > > > > > > >IP phone. But, I really suspect that for a long > > > time to come, > > > > > > (2) is going to > > > > > > > >be extremely important. Even so, with (1) in existence, > > > > > it means > > > > > > > >that people can start to take advantage of T.140 as > > > soon as the > > > > > > devices are put > > > > > > > >into their hands... and so the transition begins. > > > > > > > > > > > > > > > >Paul > > > > > > > > > > > > > > > >----- Original Message ----- > > > > > > > >From: "Rajesh Kumar" > > > > > > > >To: "A vWijk" > > > > > > > >Cc: ; ; > > > > > > > >; ; > > > > > > ; > > > > > > > >; ; = ; > > > > > > > >; > > > ; > > > > > > > >; > > > ; > > > > > > > >; ; > > > > > > > >; ; > > > > > > > > > > > > > >Sent: Monday, June 30, 2003 11:21 PM > > > > > > > >Subject: Re: SV: SV: Internet draft on real time text > > > > > conversation > > > > > > > > > > > > > > > > > > > > > > > > > Dr. van Wijk, > > > > > > > > > > > > > > > > > > While I support your sentiments, are you sure that > > > > > > governments all over > > > > > > > >the > > > > > > > > > world will provide these mobile text phones to the > > > > > > hard-of-hearing on a > > > > > > > > > subsidized basis? Also, the monthly plans that go with = it? > > > > > > > > > > > > > > > > > > While I do not know about other countries, I seriously > > > > > > doubt that the US > > > > > > > > > will do such a thing in the near future. I think the US > > > > > > deaf community > > > > > > >is > > > > > > > > > stuck with Baudot devices for a long time, unless they = can > > > > > > afford PCs on > > > > > > > > > their own budget.Probably a USB interface on the SIP ph= one > > > > > > to a cheap > > > > > > > > > device is probably the best shot at universal > > > > > > accessibility. Even so, I > > > > > > > > > doubt if the US government will subsidize the SIP > > > > > phone + keypad > > > > > > > > > + > > > > > > >screen > > > > > > > > > combo, even it is cheaper that the Baudot TTY. This > > > > > is because > > > > > > > > > this > > > > > > >would > > > > > > > > > entail a mass replacement for thousands of > > > existing Baudot > > > > > > > > > devices. > > > > > > > > > > > > > > > > > > I might be wrong - I hope I am. > > > > > > > > > > > > > > > > > > Rajesh > > > > > > > > > > > > > > > > > > At 12:33 PM 6/26/2003 +0200, A vWijk wrote: > > > > > > > > > >Paul, > > > > > > > > > >I am also looking at a larger scale. > > > > > > > > > >Imagine that 3 companies > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >******************************************************************= * > > > > > >** > > > > > > >*** > > > > > > >This email and any files transmitted with it are > > > confidential and > > > > > > >intended solely for the use of the individual or > > > entity to whom > > > > > > >they are addressed. Any views or opinions expressed are sole= ly > > > > > > >those of the author and do not necessarily represent > > > RNID policy. > > > > > > > > > > > > > >If you are not the intended recipient you are advised that > > > > > any use, > > > > > > >dissemination, forwarding, printing or copying of this > > > email is > > > > > > >strictly prohibited. > > > > > > > > > > > > > >If you have received this email in error please notify > > > the RNID > > > > > > >Helpdesk by telephone on: +44 (0) 207 296 8282. > > > > > > > > > > > > > >The Royal National Institute for Deaf People > > > > > > >Registered Office 19-23 Featherstone Street > > > > > > >London EC1Y 8SL No. 454169 (England) > > > > > > >Registered Charity No. 207720 > > > > > > > > > > > > > > >******************************************************************= * > > > > > >** > > > > > > >*** > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 14 06:28:06 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 GAA05678 for ; Mon, 14 Jul 2003 06:28:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0YS-0000pH-KN for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 06:27:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EARaO8003156 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 06:27:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0YS-0000od-Fg for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 06:27: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 GAA05534 for ; Mon, 14 Jul 2003 06:27:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c0YO-0003rg-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 06:27:32 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c0YA-0003qc-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 06:27:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0Xz-0000Y4-7p; Mon, 14 Jul 2003 06:27:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19atc6-0004zc-SM for sipping@optimus.ietf.org; Fri, 11 Jul 2003 04:50: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 EAA21492 for ; Fri, 11 Jul 2003 04:50:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19atc3-0003kK-00 for sipping@ietf.org; Fri, 11 Jul 2003 04:50:43 -0400 Received: from ns.ivd.nl ([193.67.37.226]) by ietf-mx with esmtp (Exim 4.12) id 19atc2-0003kG-00 for sipping@ietf.org; Fri, 11 Jul 2003 04:50:42 -0400 Received: (from root@localhost) by ns.ivd.nl (8.9.3c/8.6.12) id KAA34573 for ; Fri, 11 Jul 2003 10:51:42 +0200 (CEST) Received: by ns.ivd.nl (TUNIX txp2/smap) for id sma034349; Fri, 11 Jul 03 10:51:09 +0200 Received: from IVD-Message_Server by mailserver.viataal.nl with Novell_GroupWise; Fri, 11 Jul 2003 10:52:21 +0200 Message-Id: X-Mailer: Novell GroupWise 5.5.5 Date: Fri, 11 Jul 2003 10:51:54 +0200 From: "A vWijk" To: , , , , , , , , , , , , , , , , , , Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: [Sipping] Re: SV: items for vor voting in the BOF Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 Yes, we must take some time to see what exactly needs to be covered and what = kind of behaviour we need. I wil make sure that the authors of the Invocation draft camarillo-deaf-01 = will understand that the role is getting bigger here. The role of the PSTN will be important and also the role of the gateways = for backward compatibility to legacy TTY's. I will be at the IETF, so please feel free to grab me when you see me. I = am the only deaf guy around there. So it should be easy. :-) greetz Arnoud <<< Gunnar Hellstr=F6m 7/11 12:14a >>> =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 Mon Jul 14 06:28: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 GAA05776 for ; Mon, 14 Jul 2003 06:28:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0Yb-0001Qo-Og for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 06:27:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EARjmD005503 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 06:27:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0Ya-0001Qb-Sm for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 06:27: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 GAA05564 for ; Mon, 14 Jul 2003 06:27:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c0YQ-0003rn-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 06:27:34 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c0YB-0003qv-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 06:27:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0Xu-0000VO-3m; Mon, 14 Jul 2003 06:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aIl2-0006Hp-7n for sipping@optimus.ietf.org; Wed, 09 Jul 2003 13:29:32 -0400 Received: from paris.packetizer.org (system@rrcs-midsouth-24-199-221-51.biz.rr.com [24.199.221.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11225 for ; Wed, 9 Jul 2003 13:29:26 -0400 (EDT) Received: from berlin (berlin.packetizer.org [192.168.1.4]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id h69GT8tt023876; Wed, 9 Jul 2003 12:29:09 -0400 Message-ID: <027501c3463f$a7e71890$0401a8c0@packetizer.org> From: "Paul E. Jones" To: "Gunnar Hellstrom" , "Henry Sinnreich" , , , , , , "'Rajesh Kumar'" , , , "'James Hamlin'" , , , , , , , References: Date: Wed, 9 Jul 2003 13:29:30 -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: items for vor voting in the BOF Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 Gunnar, Do you think it might be a bit premature to publish a BCP? After all, it's not widely used at this point, but it is expected to become much more widely used over the next few years. What is still not sorted out is how this will be married with the existing PSTN TTY equipment out there. There was some discussion of using specialized gateways for interworking, putting RFC 2793 on IP phones, doing pass-though on IP phones, etc. We still haven't even settled the issue of how text will even be entered into the average IP phone. I recognize that it's a best "current" practice, but given the amount of focus on this right now and the volatility, I think it might be better to just produce an I-D and re-publish that for a period of time and not rush to produce a BCP. Paul ----- Original Message ----- From: "Gunnar Hellstrom" To: "Henry Sinnreich" ; ; ; ; ; ; "'Rajesh Kumar'" ; ; ; "'James Hamlin'" ; ; ; ; ; ; ; ; Sent: Sunday, July 06, 2003 4:45 PM Subject: SV: items for vor voting in the BOF > OK, looks fine. > > What about the external alerting connections? There was some good points > that it can be arranged by logging in a SIP alerter with the same user name > in the sip server. That is a good design, that one can do a lot of smart > things with. Evenso, the direct connection on the phone is simple and > needed. > > > Whatever the outcome of the voting, we also agreed that it would be good to > have a BCP ( Best Current Practice ) on what SIP text conversation is. The > SDP for it, some good habits in design, what is need to support the > transactions for invoking transcoding according to camarillo... etc. Erik > Zetterstrom and Andreas Piirimets made an initial draft. I think they are > prepared to issue a new, slightly improved. Barry Dingle had a good > formulation promoting it. Has it progressed? I suggest that these actions > are handled jointly in the sipping meeting. > > Is anything like the sipdev activity going on for multimedia devices? I > would like to participate there and get text included there as well together > with video and voice. > > Regards > > Gunnar > > ------------------------------------------- > Gunnar Hellstrom, Omnitor, Renathvagen 2 > SE 121 37 Johanneshov, SWEDEN > Tel: +46 8 556 002 03 Mob: +46 708204288 > e-mail: gunnar.hellstrom@omnitor.se > web: www.omnitor.se > > > > -----Ursprungligt meddelande----- > > Fran: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com] > > Skickat: den 6 juli 2003 22:14 > > Till: 'Gunnar Hellstrom'; Guido.Gybels@rnid.org.uk; > > mike.spanner@rnid.org.uk; andreas.piirimets@omnitor.se; > > gv@trace.wisc.edu; trefor@trefor.plus.com; 'Rajesh Kumar'; > > marcelo@envilogg.se; jorgen.bjorkner@hotsip.com; 'James Hamlin'; > > Erik.Zetterstrom@omnitor.se; hwildfeu@cisco.com; paulej@packetizer.com; > > barry.dingle@bigfoot.com.au; mgarakan@cisco.com; oran@cisco.com; > > rohan@cisco.com; sipping@ietf.org > > Amne: RE: items for vor voting in the BOF > > > > > > Please see the attached slide for voting at the IETF BOF on "Interactive > > Text Support for SIP Telephony Devices". > > > > We have no day/time yet for the BOF, but expect to get it scheduled, as > > discussed with Rohan Mahy. > > > > Many thanks to Gunnar Hellstrom for the formulation of the text. > > > > Thanks, Henry > > > > > -----Original Message----- > > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > > > Sent: Wednesday, July 02, 2003 3:44 AM > > > To: Henry Sinnreich > > > Cc: trefor@trefor.plus.com; gv@trace.wisc.edu; > > > mike.spanner@rnid.org.uk; Guido.Gybels@rnid.org.uk; > > > Erik.Zetterstrom@omnitor.se; 'Rajesh Kumar'; 'James Hamlin'; > > > andreas.piirimets@omnitor.se; jorgen.bjorkner@hotsip.com; > > > marcelo@envilogg.se; rohan@cisco.com; oran@cisco.com; > > > mgarakan@cisco.com; hwildfeu@cisco.com; > > > barry.dingle@bigfoot.com.au; paulej@packetizer.com > > > Subject: SV: items for vor voting in the BOF > > > > > > > > > Henry, > > > Yes please use the sentences in the IETF meeting, with no 3 > > > amended as below. > > > > > > Some thoughts an explanations: > > > > > > Blind reference: > > > ---------------- > > > The reference about display interface for blind people refers > > > to a need for blind people to follow hat is displayed on the > > > phone through a device of their choice. It may be voice > > > synthesis or electromechanical braille display or display > > > with enlargement or extra strong light. We do not expect the > > > phone to include these special devices, so a standardised > > > interface to them must be provided. The SIP phone will have > > > states so it will be impossible to expect that you shall be > > > able to operate it without feedback from the phone. The > > > mobile industry made the mistake to not initially provide a > > > standardised interface to operate the mobile phone and that > > > has caused enormous problems for blind people. The AT command > > > interface available to 3GPP mobile phones seem to have > > > overcome this mistake by including commands and responses for > > > accessing most things required for operation through a serial > > > command language that can be issued through Bluetooth or a > > > USB or serial connector. Products are emerging. Something > > > similar must be done on SIP phones. I concentrated on deaf > > > issues, but I see that we have common interests here. > > > > > > The web interface: > > > ------------------ > > > I saw a comment that the web interface should not be > > > mentioned as a solution. That may be true, it was with > > > hesitation that I added it. But: I have seen SIP phones with > > > the possibility to add the video component from a nearby > > > computer. Similar things can be done for text. It is still > > > valid to let the phone have all the other SIP phone > > > functionality. I can imagine PDA access through Bluetooth > > > executing a web browser to operate the phone. The text > > > component could be accessible through that interface. > > > Handling only the user interface aspect of the text part is > > > an enormous difference from handling the complete SIP > > > protocol and all audio coding. The sum is of course that when > > > we open for many ways to add text and that the person > > > carrying a text interface with him, will find that it can not > > > be attached to any phone, and then accessibility is again > > > limited. I am quite sure that phones will not come without > > > display, and that they will follow the trend on PDAs and > > > mobile phones, to include a full aphanumeric keyboard because > > > it is needed for address and phonebook use, as well as to > > > provide a good user interface to the very popular real time > > > text conversation function ;-) . So, I am not too worried > > > that we give many options. > > > > > > > > > The analogue interface. > > > ----------------------- > > > The statement no 3 about the analogue adapter is not really > > > formulated in a strict IETF style. A starting sentence is needed: > > > > > > 3. A SIP device MAY provide analogue adapter functionality > > > through an RJ11 port. IF an RJ11 port is provided for a PSTN > > > device adapter interface, THEN it MUST/SHOULD provide T.38 > > > support for fax AND V.18+RFC2793 support for text alternating > > > with voice. If T.38 or RFC2793 negotiation fails then it MAY > > > try to connect for G.711 and pass the audio through. > > > > > > > > > > > > > > > ------------------------------------------- > > > Gunnar Hellstrom, Omnitor, Renathvagen 2 > > > SE 121 37 Johanneshov, SWEDEN > > > Tel: +46 8 556 002 03 Mob: +46 708204288 > > > e-mail: gunnar.hellstrom@omnitor.se > > > web: www.omnitor.se > > > > > > > > > > -----Ursprungligt meddelande----- > > > > Fran: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com] > > > > Skickat: den 2 juli 2003 02:27 > > > > Till: 'Gunnar Hellstrom' > > > > Kopia: paulej@packetizer.com; barry.dingle@bigfoot.com.au; > > > > hwildfeu@cisco.com; mgarakan@cisco.com; oran@cisco.com; > > > > rohan@cisco.com; marcelo@envilogg.se; jorgen.bjorkner@hotsip.com; > > > > Henry.Sinnreich@mci.com; andreas.piirimets@omnitor.se; > > > 'James Hamlin'; > > > > 'Rajesh Kumar'; Erik.Zetterstrom@omnitor.se; > > > Guido.Gybels@rnid.org.uk; > > > > mike.spanner@rnid.org.uk; gv@trace.wisc.edu; trefor@trefor.plus.com > > > > Amne: items for vor voting in the BOF > > > > > > > > > > > > Gunnar, > > > > > > > > I will use with your permission your formulation to put these three > > > > items to vote in the BOF, for MUST or SHOULD: > > > > > > > > 1. MUST/SHOULD include protocol support for RFC2793 for text. > > > > > > > > 2. MUST/SHOULD provide a way to input text and display > > > text, through > > > > any > > > > method: Built in user interfaces, standard wired or > > > wireless interfaces > > > > for keyboard and display ( that is needed anyway for blind > > > people), or > > > > support for text through its already mandated web interface. > > > > > > > > ---- > > > > And, with some doubt: > > > > > > > > 3. IF an RJ11 port is provided for a PSTN device adapter interface, > > > > THEN it MUST/SHOULD provide T.38 support for fax AND V.18+RFC2793 > > > > support for text alternating with voice. If T.38 or RFC2793 > > > > negotiation fails then it MAY try to connect for G.711 and pass the > > > > audio through.( is there any need to mandate also modem support? ) > > > > > > > > I believe these are very reasonable requirements. > > > > > > > > Thanks, Henry > > > > > > > > > -----Original Message----- > > > > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > > > > > Sent: Tuesday, July 01, 2003 4:08 PM > > > > > To: Rajesh Kumar; James Hamlin > > > > > Cc: paulej@packetizer.com; barry.dingle@bigfoot.com.au; > > > > > hwildfeu@cisco.com; mgarakan@cisco.com; oran@cisco.com; > > > > > rohan@cisco.com; marcelo@envilogg.se; jorgen.bjorkner@hotsip.com; > > > > > Henry.Sinnreich@mci.com; andreas.piirimets@omnitor.se; > > > > > Erik.Zetterstrom@omnitor.se; Guido.Gybels@rnid.org.uk; > > > > > mike.spanner@rnid.org.uk; gv@trace.wisc.edu; > > > trefor@trefor.plus.com > > > > > Subject: SV: SV: SV: Internet draft on real time text conversation > > > > > > > > > > > > > > > I see the discussion going in circles. > > > > > > > > > > Henry gave me the delicate task to sum up and get a > > > proposed writing > > > > > into the Sipdev specification. > > > > > > > > > > After looking back in the discussion, I come to the > > > conclusion that, > > > > > the only requirements that make real sense and takes deaf > > > telecomms > > > > > a bit towards equal opportunities is that SIP devices: > > > > > > > > > > 1. MUST include protocol support for RFC2793 for text. > > > > > > > > > > 2. MUST provide a way to input text and display text, through any > > > > > method: Built in user interfaces, standard wired or wireless > > > > > interfaces for keyboard and display ( that is needed anyway for > > > > > blind people), or support for text through its already > > > mandated web > > > > > interface. > > > > > > > > > > ---- > > > > > And, with some doubt: > > > > > > > > > > 3. IF an RJ11 port is provided for a PSTN device adapter > > > interface, > > > > > THEN it MUST provide T.38 support for fax AND > > > V.18+RFC2793 support > > > > > for text alternating with voice. If T.38 or RFC2793 negotiation > > > > > fails then it MAY try to connect for G.711 and pass the audio > > > > > through.( is there any need to mandate also modem support? ) > > > > > > > > > > > > > > > > > > > > ---- > > > > > I am sure SIP signaling can take care of most tricky > > > situations that > > > > > have been up for discussion. > > > > > > > > > > E.g. > > > > > A SIP phone without RJ11 port in contact with a PSTN > > > device through > > > > > a gateway, would signal RFC2793 capability. That will > > > make a gateway > > > > > involved in the call perceive any indication on use of modem-like > > > > > tones from PSTN as text if possible. > > > > > > > > > > > > > > > > > > > > I intend to propose text with that content soon for the > > > sipdev spec. > > > > > > > > > > With that, we could perhaps change topic to discuss > > > contents of the > > > > > text capable device I-D that Erik and Andreas made a > > > first draft of. > > > > > > > > > > Has time been booked in the SIPPING meeting in Wienna to discuss > > > > > that? > > > > > > > > > > Can Erik and Andreas provide us with a second draft? > > > > > > > > > > Best regards > > > > > > > > > > Gunnar > > > > > > > > > > > > > > > ------------------------------------------- > > > > > Gunnar Hellstrom, Omnitor, Renathvagen 2 > > > > > SE 121 37 Johanneshov, SWEDEN > > > > > Tel: +46 8 556 002 03 Mob: +46 708204288 > > > > > e-mail: gunnar.hellstrom@omnitor.se > > > > > web: www.omnitor.se > > > > > > > > > > > > > > > > -----Ursprungligt meddelande----- > > > > > > Fran: Rajesh Kumar [mailto:rkumar@cisco.com] > > > > > > Skickat: den 1 juli 2003 19:15 > > > > > > Till: James Hamlin > > > > > > Kopia: paulej@packetizer.com; barry.dingle@bigfoot.com.au; > > > > > > hwildfeu@cisco.com; mgarakan@cisco.com; oran@cisco.com; > > > > > > rohan@cisco.com; marcelo@envilogg.se; > > > jorgen.bjorkner@hotsip.com; > > > > > > Henry.Sinnreich@mci.com; andreas.piirimets@omnitor.se; > > > > > > Erik.Zetterstrom@omnitor.se; gunnar.hellstrom@omnitor.se; > > > > > > Guido.Gybels@rnid.org.uk; mike.spanner@rnid.org.uk; > > > > > gv@trace.wisc.edu; > > > > > > trefor@trefor.plus.com > > > > > > Amne: RE: SV: SV: Internet draft on real time text conversation > > > > > > > > > > > > > > > > > > James, > > > > > > > > > > > > The intent here is that the called party could be any SIP > > > > > phone, not > > > > > > just SIP phones specially designated for text-only > > > > > operation. I think > > > > > > the intent expressed by Guido and Gunnar et al is that a > > > > > PSTN TTY user > > > > > > should be able > > > > > > to open an RFC 2793 text channel with any SIP phone user, > > > > > and that the > > > > > > latter should either have an integral keyboard/display > > > or a port > > > > > > to such a display. So the problem of call > > > discrimination when the > > > > > > caller is a V.21 or > > > > > > V.23 legacy textphone is not solved unless you allow > > > > > passthrough fallback > > > > > > when you cannot tell whether the V.21 signal is text or not - > > > > > > regardless of the existence of gateways/servers that do PSTN > > > > > > textphone to RFC 2793 conversion. > > > > > > > > > > > > In general, the solution of designating special phone > > > numbers for > > > > > > deaf-accessible operation militates against the stipulation > > > > > that the > > > > > > deaf be able to create text channels from any PSTN or SIP phone > > > > > > number, and to any PSTN or SIP phone number. Here, textphone > > > > > > detection has to be on the basis of control signals > > > > > exchanged in the > > > > > > bearer stream or on the content of the bearer stream, > > > and not on a > > > > > > priori numbering plans that create a "deaf ghetto". > > > > > > > > > > > > For technical reasons, I still think you must mandate > > > passthrough > > > > > > operation to enable universal interoperability. > > > > > > > > > > > > Kind regards to all. > > > > > > > > > > > > Rajesh > > > > > > > > > > > > > > > > > > > > > > > > At 04:33 PM 7/1/2003 +0100, James Hamlin wrote: > > > > > > >Rajesh > > > > > > > > > > > > > >It would be possible for people on the IP network to have PSTN > > > > > > numbers that > > > > > > >are taken from a block that is assigned only to text. > > > Therefore > > > > > > the gateway > > > > > > >between PSTN and the IP network knows from the called number > > > > > > that the intent > > > > > > >is to use text. > > > > > > > > > > > > > >Regards > > > > > > > > > > > > > >James > > > > > > > > > > > > > >-----Original Message----- > > > > > > >From: Rajesh Kumar [mailto:rkumar@cisco.com] > > > > > > >Sent: 01 July 2003 16:05 > > > > > > >To: A vWijk > > > > > > >Cc: paulej@packetizer.com; barry.dingle@bigfoot.com.au; > > > > > > >hwildfeu@cisco.com; mgarakan@cisco.com; oran@cisco.com; > > > > > > >rohan@cisco.com; marcelo@envilogg.se; > > > jorgen.bjorkner@hotsip.com; > > > > > > >Henry.Sinnreich@mci.com; andreas.piirimets@omnitor.se; > > > > > > >Erik.Zetterstrom@omnitor.se; gunnar.hellstrom@omnitor.se; > > > > > > >Guido.Gybels@rnid.org.uk; james.hamlin@rnid.org.uk; > > > > > > >mike.spanner@rnid.org.uk; gv@trace.wisc.edu; > > > > > > >trefor@trefor.plus.com > > > > > > >Subject: Re: SV: SV: Internet draft on real time text > > > conversation > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> "rkumar@cisco.com" 07/01/03 16:04 >>> > > > > > > > > > > > > > >Arnoud, > > > > > > > > > > > > > >As I indicated in another email, interoperability with legacy > > > > > > V.21 and V.23T > > > > > > > TY devices is not feasible unless you support a passthrough > > > > > > >fallback. I have no hidden agenda here, I am just presenting a > > > > > > >technical difficulty that SG16/Q11 and TIA TR.30.1 have been > > > > > > >struggling with for the past 6 months. I do not know how > > > > > you can do > > > > > > >without TTY passthrough if you want universal > > > > > interoperability. Here > > > > > > >was my mail, sent yesterday: > > > > > > > > > > > > > >There is a real technical difficulty which I would want you all > > > > > > to consider. > > > > > > > > > > > > > >Let us say that you mandate T.140/RFC 2793 for all SIP > > > > > phones and do > > > > > > >not mandate TTY passthrough. > > > > > > > > > > > > > >Let us say the call originates from a PSTN TTY and is > > > routed via > > > > > > a gatewayt > > > > > > > o a SIP phone, which has native RFRC2793-based text > > > > > > > capabilities. > > > > > > > > > > > > > >SG16/Q11 has struggled with the fact that you cannot always > > > > > > discriminate aT > > > > > > > TY call from a non-TTY call when V.21 or V.23 > > > > > modulations are used. > > > > > > >In this case, there is no basis for the gateway to convert the > > > > > > >PSTN > > > > > > TTY signali > > > > > > > nto RFC 2793/T.140. However, the gateway can determine > > > > > that this is > > > > > > >a modulated signal based on answer tone (if present) or on > > > > > specific > > > > > > >FSK frequencies. It can use VBD passthrough (G.711) in > > > > > this case but > > > > > > >not RFC 2793 since it does not know if the V.21/V.23 > > > > > signal is text > > > > > > >or not. > > > > > > > > > > > > > >Ergo, we cannot preclude a requirement for G.711 VBD > > > passthrough > > > > > > support onS > > > > > > > IP phones in favor of T.140. You can mandate both as musts, > > > > > > but you cannoth > > > > > > > ave an interoperable solution if you do not have passthrough. > > > > > > > > > > > > > >Rajesh > > > > > > > > > > > > > > > > > > > > > > > > > > > >At 04:02 PM 7/1/2003 +0200, A vWijk wrote: > > > > > > > >Paul, > > > > > > > >How do you feel by mandating T.140/RTP along with the TTY > > > > > > passthrough on> > > > > > > > IP telephones and such? > > > > > > > >The technology is then ready for the T.140 usage. > > > Which may be > > > > > > very very> > > > > > > > rapidly! > > > > > > > >And remember..as I am stating over and over again. RFC2793 is > > > > > > NOT limited> > > > > > > > for the hearing impaired users only! > > > > > > > >Many other services will be possible with text conversation. > > > > > > > >And that will likely stimulate the acceptance of T.140 too. > > > > > > > > > > > > > > > >And if we explain the goal of T.140 and the possibilities. > > > > > > Then I do not> > > > > > > > see any problems for the governments to subsidize this > > > > > > development and buy> > > > > > > > IP telephones for the hearing impaired. > > > > > > > >Ofcourse, we have to guarantee the legacy TTY > > > support. But also > > > > > > > >that it has to be phased out. > > > > > > > > > > > > > > > >Please do not lock out T.140 by mandating TTY voice > > > > > > fallback/passthrough> > > > > > > > for IP telephones and clients/servers etc. > > > > > > > > > > > > > > > >greetz > > > > > > > > > > > > > > > >Arnoud van Wijk > > > > > > > > > > > > > > > ><<< "Paul E. Jones" 7/ 1 5:47a >>> > > > > > > > >Rajesh, > > > > > > > > > > > > > > > >I agree with your concerns. Also, I think the case is even > > > > > > stronger for > > > > > > > >other countries where such issues are as thoughtfully > > > > > > considered. I really > > > > > > > >doubt that we'll see any requirements in many countries. > > > > > > > > > > > > > > > >Another factor is cost. It might be a small > > > per-unit cost to > > > > > > > >include necessary support, but even if it is $10, > > > $10 times the > > > > > > > >number > > > > > > of devices a > > > > > > > >large, mass manufacturing company will produce in a > > > > > > > >highly-competitive, low-margin environment becomes a > > > > > major issue. > > > > > > > >Thus, there will be a push-back from the extremely > > > high-volume > > > > > > > >manufacturers, I think. > > > > > > > > > > > > > > > >Considering all things, what I think the best roadmap is: > > > > > > > > 1) Create devices that are dual TTY/T.140 devices > > > that work > > > > > > on PSTN or > > > > > > >IP > > > > > > > > 2) Make sure every IP phone, residential gateway / analog > > > > > > > >terminal adapter, etc. > > > > > > > > can properly carry TTY signals, modem signals, > > > > > fax, etc. and that > > > > > > > > a standard TTY device can interface with said device > > > > > > > > > > > > > > > >Over time, we may see increased support for T.140 > > > > > natively on every > > > > > > > >IP phone. But, I really suspect that for a long > > > time to come, > > > > > > (2) is going to > > > > > > > >be extremely important. Even so, with (1) in existence, > > > > > it means > > > > > > > >that people can start to take advantage of T.140 as > > > soon as the > > > > > > devices are put > > > > > > > >into their hands... and so the transition begins. > > > > > > > > > > > > > > > >Paul > > > > > > > > > > > > > > > >----- Original Message ----- > > > > > > > >From: "Rajesh Kumar" > > > > > > > >To: "A vWijk" > > > > > > > >Cc: ; ; > > > > > > > >; ; > > > > > > ; > > > > > > > >; ; ; > > > > > > > >; > > > ; > > > > > > > >; > > > ; > > > > > > > >; ; > > > > > > > >; ; > > > > > > > > > > > > > >Sent: Monday, June 30, 2003 11:21 PM > > > > > > > >Subject: Re: SV: SV: Internet draft on real time text > > > > > conversation > > > > > > > > > > > > > > > > > > > > > > > > > Dr. van Wijk, > > > > > > > > > > > > > > > > > > While I support your sentiments, are you sure that > > > > > > governments all over > > > > > > > >the > > > > > > > > > world will provide these mobile text phones to the > > > > > > hard-of-hearing on a > > > > > > > > > subsidized basis? Also, the monthly plans that go with it? > > > > > > > > > > > > > > > > > > While I do not know about other countries, I seriously > > > > > > doubt that the US > > > > > > > > > will do such a thing in the near future. I think the US > > > > > > deaf community > > > > > > >is > > > > > > > > > stuck with Baudot devices for a long time, unless they can > > > > > > afford PCs on > > > > > > > > > their own budget.Probably a USB interface on the SIP phone > > > > > > to a cheap > > > > > > > > > device is probably the best shot at universal > > > > > > accessibility. Even so, I > > > > > > > > > doubt if the US government will subsidize the SIP > > > > > phone + keypad > > > > > > > > > + > > > > > > >screen > > > > > > > > > combo, even it is cheaper that the Baudot TTY. This > > > > > is because > > > > > > > > > this > > > > > > >would > > > > > > > > > entail a mass replacement for thousands of > > > existing Baudot > > > > > > > > > devices. > > > > > > > > > > > > > > > > > > I might be wrong - I hope I am. > > > > > > > > > > > > > > > > > > Rajesh > > > > > > > > > > > > > > > > > > At 12:33 PM 6/26/2003 +0200, A vWijk wrote: > > > > > > > > > >Paul, > > > > > > > > > >I am also looking at a larger scale. > > > > > > > > > >Imagine that 3 companies > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >******************************************************************* > > > > > >** > > > > > > >*** > > > > > > >This email and any files transmitted with it are > > > confidential and > > > > > > >intended solely for the use of the individual or > > > entity to whom > > > > > > >they are addressed. Any views or opinions expressed are solely > > > > > > >those of the author and do not necessarily represent > > > RNID policy. > > > > > > > > > > > > > >If you are not the intended recipient you are advised that > > > > > any use, > > > > > > >dissemination, forwarding, printing or copying of this > > > email is > > > > > > >strictly prohibited. > > > > > > > > > > > > > >If you have received this email in error please notify > > > the RNID > > > > > > >Helpdesk by telephone on: +44 (0) 207 296 8282. > > > > > > > > > > > > > >The Royal National Institute for Deaf People > > > > > > >Registered Office 19-23 Featherstone Street > > > > > > >London EC1Y 8SL No. 454169 (England) > > > > > > >Registered Charity No. 207720 > > > > > > > > > > > > > > >******************************************************************* > > > > > >** > > > > > > >*** > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 14 06:28:15 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 GAA05795 for ; Mon, 14 Jul 2003 06:28: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 19c0Yf-0001Rp-AV for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 06:27:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EARn8I005559 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 06:27:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0Yf-0001RZ-5D for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 06:27: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 GAA05589 for ; Mon, 14 Jul 2003 06:27:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c0Ya-0003sY-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 06:27:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c0YL-0003r2-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 06:27:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0Xx-0000XG-Jr; Mon, 14 Jul 2003 06:27:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aftj-0000h8-Ri for sipping@optimus.ietf.org; Thu, 10 Jul 2003 14:12: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 OAA14989 for ; Thu, 10 Jul 2003 14:11:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aftg-0005pz-00 for sipping@ietf.org; Thu, 10 Jul 2003 14:12:00 -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 19afte-0005pq-00 for sipping@ietf.org; Thu, 10 Jul 2003 14:11:58 -0400 Received: from berlin (berlin.packetizer.org [192.168.1.4]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id h6AIBXMd005184; Thu, 10 Jul 2003 14:11:33 -0400 Message-ID: <00c001c3470e$b1bfd800$0401a8c0@packetizer.org> From: "Paul E. Jones" To: "Gunnar Hellström" , "Henry Sinnreich" , , , , , , "'Rajesh Kumar'" , , , "'James Hamlin'" , , , , , , , References: Date: Thu, 10 Jul 2003 14:11:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 X-MIME-Autoconverted: from 8bit to quoted-printable by paris.packetizer.org id h6AIBXMd005184 Subject: [Sipping] Re: items for vor voting in the BOF Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 Gunnar, So, I don't agree with getting this started and helping to steer directio= n, but I disagree that everything is standardized. As you know, we are stil= l working on the standards for transport of TTY signals between PSTN gatewa= ys (ITU-T Q11/16). There are still open questions as to whether a large trunking gateway should use one port for audio and one for text or "multiplex" on the same port. (I put that in quotes, as it's not truly multiplexing, but switching between one media type and another, but still from the same source... the PSTN trunk.) We then have to consider how those GWs will then interface with the IP phones. This is where I can see the BCP showing value to ensure that the current practices are documented. However, the current practices may hav= e to be amended, expanded, etc. In just the past few weeks, we've had discussions on carrying text over audio, using RFC 2793 only, inserting G= Ws in the middle, etc. So, I think we have a few things to talk about. Thu= s, I would prefer that this be written and modified over the next few meetin= gs, rather than rushed to RFC/BCP status. Paul ----- Original Message -----=20 From: "Gunnar Hellstr=F6m" To: "Paul E. Jones" ; "Henry Sinnreich" ; ; ; ; ; ; "'Rajesh Kumar'" ; ; ; "'James Hamlin'" ; ; ; ; = ; ; ; Sent: Thursday, July 10, 2003 3:16 AM Subject: SV: items for vor voting in the BOF > Poul, > We are seeking a form of document where we can collect the pieces that = are > already well standardised for text in IP, but apparently a bit hard to find, > so we have an apparent risk that developers keep inventing new, incompatible > solutions for text while the IP voice telephony side converges. > > We cannot afford to let IP text conversation be as fragmented as it was= in > PSTN. It must be a proper telecom feature on the same status level as voice > and video if we are ever to get any accessibility in this world. And it must > be included in mainstream developments. > > The PSTN functions for text are good and important where they are ,but > nothing of the functionality level that we would drag into the future a= s any > best common solution. That has been stated many times in the discussion= s > here. > > Gateways are defined and in operation. > > It is exactly the right moment now to create a document that collects t= he > views on IP text conversation. With that we can all contribute to make = it > widespread. Without it, there is a risk of continued fragmentation. > > We proposed BCP (Best Common Practise) merely because everything is already > standardised and it is not good to have the same standard in two documents. > A BCP can pick up and clarify and put emphasis on standards created in other > documents. Of course it shall take the traditional route to be an I-D first. > I am flexible on this. If there is enough new material in it, it can be > proposed as an RFC. > > So, doing it now is the most important. > > Gunnar > > > > ------------------------------------------- > Gunnar Hellstr=F6m, Omnitor, Renathv=E4gen 2 > SE 121 37 Johanneshov, SWEDEN > Tel: +46 8 556 002 03 Mob: +46 708204288 > e-mail: gunnar.hellstrom@omnitor.se > web: www.omnitor.se > > > > -----Ursprungligt meddelande----- > > Fr=E5n: Paul E. Jones [mailto:paulej@packetizer.com] > > Skickat: den 9 juli 2003 19:30 > > Till: Gunnar Hellstrom; Henry Sinnreich; Guido.Gybels@rnid.org.uk; > > mike.spanner@rnid.org.uk; andreas.piirimets@omnitor.se; > > gv@trace.wisc.edu; 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; > > rohan@cisco.com; sipping@ietf.org > > =C4mne: Re: items for vor voting in the BOF > > > > > > Gunnar, > > > > Do you think it might be a bit premature to publish a BCP? After > > all, it's > > not widely used at this point, but it is expected to become much > > more widely > > used over the next few years. What is still not sorted out is > > how this will > > be married with the existing PSTN TTY equipment out there. There was some > > discussion of using specialized gateways for interworking, > > putting RFC 2793 > > on IP phones, doing pass-though on IP phones, etc. We still haven't even > > settled the issue of how text will even be entered into the average I= P > > phone. I recognize that it's a best "current" practice, but given th= e > > amount of focus on this right now and the volatility, I think it migh= t be > > better to just produce an I-D and re-publish that for a period of tim= e and > > not rush to produce a BCP. > > > > Paul > > > > ----- Original Message ----- > > From: "Gunnar Hellstrom" > > To: "Henry Sinnreich" ; > > ; > > ; ; > > ; ; "'Rajesh Kumar'" > > ; ; ; > > "'James Hamlin'" ; > > ; > > ; ; > > ; ; = ; > > ; > > Sent: Sunday, July 06, 2003 4:45 PM > > Subject: SV: items for vor voting in the BOF > > > > > > > OK, looks fine. > > > > > > What about the external alerting connections? There was some good points > > > that it can be arranged by logging in a SIP alerter with the same u= ser > > name > > > in the sip server. That is a good design, that one can do a lot of smart > > > things with. Evenso, the direct connection on the phone is simple a= nd > > > needed. > > > > > > > > > Whatever the outcome of the voting, we also agreed that it would be good > > to > > > have a BCP ( Best Current Practice ) on what SIP text > > conversation is. The > > > SDP for it, some good habits in design, what is need to support the > > > transactions for invoking transcoding according to camarillo... > > etc. Erik > > > Zetterstrom and Andreas Piirimets made an initial draft. I > > think they are > > > prepared to issue a new, slightly improved. Barry Dingle had a good > > > formulation promoting it. Has it progressed? I suggest that > > these actions > > > are handled jointly in the sipping meeting. > > > > > > Is anything like the sipdev activity going on for multimedia device= s? I > > > would like to participate there and get text included there as well > > together > > > with video and voice. > > > > > > Regards > > > > > > Gunnar > > > > > > ------------------------------------------- > > > Gunnar Hellstrom, Omnitor, Renathvagen 2 > > > SE 121 37 Johanneshov, SWEDEN > > > Tel: +46 8 556 002 03 Mob: +46 708204288 > > > e-mail: gunnar.hellstrom@omnitor.se > > > web: www.omnitor.se > > > > > > > > > > -----Ursprungligt meddelande----- > > > > Fran: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com] > > > > Skickat: den 6 juli 2003 22:14 > > > > Till: 'Gunnar Hellstrom'; Guido.Gybels@rnid.org.uk; > > > > mike.spanner@rnid.org.uk; andreas.piirimets@omnitor.se; > > > > gv@trace.wisc.edu; trefor@trefor.plus.com; 'Rajesh Kumar'; > > > > marcelo@envilogg.se; jorgen.bjorkner@hotsip.com; 'James Hamlin'; > > > > Erik.Zetterstrom@omnitor.se; hwildfeu@cisco.com; > > paulej@packetizer.com; > > > > barry.dingle@bigfoot.com.au; mgarakan@cisco.com; oran@cisco.com; > > > > rohan@cisco.com; sipping@ietf.org > > > > Amne: RE: items for vor voting in the BOF > > > > > > > > > > > > Please see the attached slide for voting at the IETF BOF on > > "Interactive > > > > Text Support for SIP Telephony Devices". > > > > > > > > We have no day/time yet for the BOF, but expect to get it > > scheduled, as > > > > discussed with Rohan Mahy. > > > > > > > > Many thanks to Gunnar Hellstrom for the formulation of the text. > > > > > > > > Thanks, Henry > > > > > > > > > -----Original Message----- > > > > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > > > > > Sent: Wednesday, July 02, 2003 3:44 AM > > > > > To: Henry Sinnreich > > > > > Cc: trefor@trefor.plus.com; gv@trace.wisc.edu; > > > > > mike.spanner@rnid.org.uk; Guido.Gybels@rnid.org.uk; > > > > > Erik.Zetterstrom@omnitor.se; 'Rajesh Kumar'; 'James Hamlin'; > > > > > andreas.piirimets@omnitor.se; jorgen.bjorkner@hotsip.com; > > > > > marcelo@envilogg.se; rohan@cisco.com; oran@cisco.com; > > > > > mgarakan@cisco.com; hwildfeu@cisco.com; > > > > > barry.dingle@bigfoot.com.au; paulej@packetizer.com > > > > > Subject: SV: items for vor voting in the BOF > > > > > > > > > > > > > > > Henry, > > > > > Yes please use the sentences in the IETF meeting, with no 3 > > > > > amended as below. > > > > > > > > > > Some thoughts an explanations: > > > > > > > > > > Blind reference: > > > > > ---------------- > > > > > The reference about display interface for blind people refers > > > > > to a need for blind people to follow hat is displayed on the > > > > > phone through a device of their choice. It may be voice > > > > > synthesis or electromechanical braille display or display > > > > > with enlargement or extra strong light. We do not expect the > > > > > phone to include these special devices, so a standardised > > > > > interface to them must be provided. The SIP phone will have > > > > > states so it will be impossible to expect that you shall be > > > > > able to operate it without feedback from the phone. The > > > > > mobile industry made the mistake to not initially provide a > > > > > standardised interface to operate the mobile phone and that > > > > > has caused enormous problems for blind people. The AT command > > > > > interface available to 3GPP mobile phones seem to have > > > > > overcome this mistake by including commands and responses for > > > > > accessing most things required for operation through a serial > > > > > command language that can be issued through Bluetooth or a > > > > > USB or serial connector. Products are emerging. Something > > > > > similar must be done on SIP phones. I concentrated on deaf > > > > > issues, but I see that we have common interests here. > > > > > > > > > > The web interface: > > > > > ------------------ > > > > > I saw a comment that the web interface should not be > > > > > mentioned as a solution. That may be true, it was with > > > > > hesitation that I added it. But: I have seen SIP phones with > > > > > the possibility to add the video component from a nearby > > > > > computer. Similar things can be done for text. It is still > > > > > valid to let the phone have all the other SIP phone > > > > > functionality. I can imagine PDA access through Bluetooth > > > > > executing a web browser to operate the phone. The text > > > > > component could be accessible through that interface. > > > > > Handling only the user interface aspect of the text part is > > > > > an enormous difference from handling the complete SIP > > > > > protocol and all audio coding. The sum is of course that when > > > > > we open for many ways to add text and that the person > > > > > carrying a text interface with him, will find that it can not > > > > > be attached to any phone, and then accessibility is again > > > > > limited. I am quite sure that phones will not come without > > > > > display, and that they will follow the trend on PDAs and > > > > > mobile phones, to include a full aphanumeric keyboard because > > > > > it is needed for address and phonebook use, as well as to > > > > > provide a good user interface to the very popular real time > > > > > text conversation function ;-) . So, I am not too worried > > > > > that we give many options. > > > > > > > > > > > > > > > The analogue interface. > > > > > ----------------------- > > > > > The statement no 3 about the analogue adapter is not really > > > > > formulated in a strict IETF style. A starting sentence is neede= d: > > > > > > > > > > 3. A SIP device MAY provide analogue adapter functionality > > > > > through an RJ11 port. IF an RJ11 port is provided for a PSTN > > > > > device adapter interface, THEN it MUST/SHOULD provide T.38 > > > > > support for fax AND V.18+RFC2793 support for text alternating > > > > > with voice. If T.38 or RFC2793 negotiation fails then it MAY > > > > > try to connect for G.711 and pass the audio through. > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------- > > > > > Gunnar Hellstrom, Omnitor, Renathvagen 2 > > > > > SE 121 37 Johanneshov, SWEDEN > > > > > Tel: +46 8 556 002 03 Mob: +46 708204288 > > > > > e-mail: gunnar.hellstrom@omnitor.se > > > > > web: www.omnitor.se > > > > > > > > > > > > > > > > -----Ursprungligt meddelande----- > > > > > > Fran: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com] > > > > > > Skickat: den 2 juli 2003 02:27 > > > > > > Till: 'Gunnar Hellstrom' > > > > > > Kopia: paulej@packetizer.com; barry.dingle@bigfoot.com.au; > > > > > > hwildfeu@cisco.com; mgarakan@cisco.com; oran@cisco.com; > > > > > > rohan@cisco.com; marcelo@envilogg.se; jorgen.bjorkner@hotsip.com; > > > > > > Henry.Sinnreich@mci.com; andreas.piirimets@omnitor.se; > > > > > 'James Hamlin'; > > > > > > 'Rajesh Kumar'; Erik.Zetterstrom@omnitor.se; > > > > > Guido.Gybels@rnid.org.uk; > > > > > > mike.spanner@rnid.org.uk; gv@trace.wisc.edu; > > trefor@trefor.plus.com > > > > > > Amne: items for vor voting in the BOF > > > > > > > > > > > > > > > > > > Gunnar, > > > > > > > > > > > > I will use with your permission your formulation to put > > these three > > > > > > items to vote in the BOF, for MUST or SHOULD: > > > > > > > > > > > > 1. MUST/SHOULD include protocol support for RFC2793 for text. > > > > > > > > > > > > 2. MUST/SHOULD provide a way to input text and display > > > > > text, through > > > > > > any > > > > > > method: Built in user interfaces, standard wired or > > > > > wireless interfaces > > > > > > for keyboard and display ( that is needed anyway for blind > > > > > people), or > > > > > > support for text through its already mandated web interface. > > > > > > > > > > > > ---- > > > > > > And, with some doubt: > > > > > > > > > > > > 3. IF an RJ11 port is provided for a PSTN device adapter > > interface, > > > > > > THEN it MUST/SHOULD provide T.38 support for fax AND V.18+RFC2793 > > > > > > support for text alternating with voice. If T.38 or RFC2793 > > > > > > negotiation fails then it MAY try to connect for G.711 > > and pass the > > > > > > audio through.( is there any need to mandate also modem support? ) > > > > > > > > > > > > I believe these are very reasonable requirements. > > > > > > > > > > > > Thanks, Henry > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > > > > > > > Sent: Tuesday, July 01, 2003 4:08 PM > > > > > > > To: Rajesh Kumar; James Hamlin > > > > > > > Cc: paulej@packetizer.com; barry.dingle@bigfoot.com.au; > > > > > > > hwildfeu@cisco.com; mgarakan@cisco.com; oran@cisco.com; > > > > > > > rohan@cisco.com; marcelo@envilogg.se; > > jorgen.bjorkner@hotsip.com; > > > > > > > Henry.Sinnreich@mci.com; andreas.piirimets@omnitor.se; > > > > > > > Erik.Zetterstrom@omnitor.se; Guido.Gybels@rnid.org.uk; > > > > > > > mike.spanner@rnid.org.uk; gv@trace.wisc.edu; > > > > > trefor@trefor.plus.com > > > > > > > Subject: SV: SV: SV: Internet draft on real time text > > conversation > > > > > > > > > > > > > > > > > > > > > I see the discussion going in circles. > > > > > > > > > > > > > > Henry gave me the delicate task to sum up and get a > > > > > proposed writing > > > > > > > into the Sipdev specification. > > > > > > > > > > > > > > After looking back in the discussion, I come to the > > > > > conclusion that, > > > > > > > the only requirements that make real sense and takes deaf > > > > > telecomms > > > > > > > a bit towards equal opportunities is that SIP devices: > > > > > > > > > > > > > > 1. MUST include protocol support for RFC2793 for text. > > > > > > > > > > > > > > 2. MUST provide a way to input text and display text, > > through any > > > > > > > method: Built in user interfaces, standard wired or wireles= s > > > > > > > interfaces for keyboard and display ( that is needed anyway for > > > > > > > blind people), or support for text through its already > > > > > mandated web > > > > > > > interface. > > > > > > > > > > > > > > ---- > > > > > > > And, with some doubt: > > > > > > > > > > > > > > 3. IF an RJ11 port is provided for a PSTN device adapter > > > > > interface, > > > > > > > THEN it MUST provide T.38 support for fax AND > > > > > V.18+RFC2793 support > > > > > > > for text alternating with voice. If T.38 or RFC2793 negotiation > > > > > > > fails then it MAY try to connect for G.711 and pass the aud= io > > > > > > > through.( is there any need to mandate also modem support? = ) > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---- > > > > > > > I am sure SIP signaling can take care of most tricky > > > > > situations that > > > > > > > have been up for discussion. > > > > > > > > > > > > > > E.g. > > > > > > > A SIP phone without RJ11 port in contact with a PSTN > > > > > device through > > > > > > > a gateway, would signal RFC2793 capability. That will > > > > > make a gateway > > > > > > > involved in the call perceive any indication on use of > > modem-like > > > > > > > tones from PSTN as text if possible. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I intend to propose text with that content soon for the > > > > > sipdev spec. > > > > > > > > > > > > > > With that, we could perhaps change topic to discuss > > > > > contents of the > > > > > > > text capable device I-D that Erik and Andreas made a > > > > > first draft of. > > > > > > > > > > > > > > Has time been booked in the SIPPING meeting in Wienna to discuss > > > > > > > that? > > > > > > > > > > > > > > Can Erik and Andreas provide us with a second draft? > > > > > > > > > > > > > > Best regards > > > > > > > > > > > > > > Gunnar > > > > > > > > > > > > > > > > > > > > > ------------------------------------------- > > > > > > > Gunnar Hellstrom, Omnitor, Renathvagen 2 > > > > > > > SE 121 37 Johanneshov, SWEDEN > > > > > > > Tel: +46 8 556 002 03 Mob: +46 708204288 > > > > > > > e-mail: gunnar.hellstrom@omnitor.se > > > > > > > web: www.omnitor.se > > > > > > > > > > > > > > > > > > > > > > -----Ursprungligt meddelande----- > > > > > > > > Fran: Rajesh Kumar [mailto:rkumar@cisco.com] > > > > > > > > Skickat: den 1 juli 2003 19:15 > > > > > > > > Till: James Hamlin > > > > > > > > Kopia: paulej@packetizer.com; barry.dingle@bigfoot.com.au= ; > > > > > > > > hwildfeu@cisco.com; mgarakan@cisco.com; oran@cisco.com; > > > > > > > > rohan@cisco.com; marcelo@envilogg.se; > > > > > jorgen.bjorkner@hotsip.com; > > > > > > > > Henry.Sinnreich@mci.com; andreas.piirimets@omnitor.se; > > > > > > > > Erik.Zetterstrom@omnitor.se; gunnar.hellstrom@omnitor.se; > > > > > > > > Guido.Gybels@rnid.org.uk; mike.spanner@rnid.org.uk; > > > > > > > gv@trace.wisc.edu; > > > > > > > > trefor@trefor.plus.com > > > > > > > > Amne: RE: SV: SV: Internet draft on real time text > > conversation > > > > > > > > > > > > > > > > > > > > > > > > James, > > > > > > > > > > > > > > > > The intent here is that the called party could be any SIP > > > > > > > phone, not > > > > > > > > just SIP phones specially designated for text-only > > > > > > > operation. I think > > > > > > > > the intent expressed by Guido and Gunnar et al is that a > > > > > > > PSTN TTY user > > > > > > > > should be able > > > > > > > > to open an RFC 2793 text channel with any SIP phone user, > > > > > > > and that the > > > > > > > > latter should either have an integral keyboard/display > > > > > or a port > > > > > > > > to such a display. So the problem of call > > > > > discrimination when the > > > > > > > > caller is a V.21 or > > > > > > > > V.23 legacy textphone is not solved unless you allow > > > > > > > passthrough fallback > > > > > > > > when you cannot tell whether the V.21 signal is text or not - > > > > > > > > regardless of the existence of gateways/servers that do P= STN > > > > > > > > textphone to RFC 2793 conversion. > > > > > > > > > > > > > > > > In general, the solution of designating special phone > > > > > numbers for > > > > > > > > deaf-accessible operation militates against the stipulati= on > > > > > > > that the > > > > > > > > deaf be able to create text channels from any PSTN or > > SIP phone > > > > > > > > number, and to any PSTN or SIP phone number. Here, textphone > > > > > > > > detection has to be on the basis of control signals > > > > > > > exchanged in the > > > > > > > > bearer stream or on the content of the bearer stream, > > > > > and not on a > > > > > > > > priori numbering plans that create a "deaf ghetto". > > > > > > > > > > > > > > > > For technical reasons, I still think you must mandate > > > > > passthrough > > > > > > > > operation to enable universal interoperability. > > > > > > > > > > > > > > > > Kind regards to all. > > > > > > > > > > > > > > > > Rajesh > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > At 04:33 PM 7/1/2003 +0100, James Hamlin wrote: > > > > > > > > >Rajesh > > > > > > > > > > > > > > > > > >It would be possible for people on the IP network to > > have PSTN > > > > > > > > numbers that > > > > > > > > >are taken from a block that is assigned only to text. > > > > > Therefore > > > > > > > > the gateway > > > > > > > > >between PSTN and the IP network knows from the called number > > > > > > > > that the intent > > > > > > > > >is to use text. > > > > > > > > > > > > > > > > > >Regards > > > > > > > > > > > > > > > > > >James > > > > > > > > > > > > > > > > > >-----Original Message----- > > > > > > > > >From: Rajesh Kumar [mailto:rkumar@cisco.com] > > > > > > > > >Sent: 01 July 2003 16:05 > > > > > > > > >To: A vWijk > > > > > > > > >Cc: paulej@packetizer.com; barry.dingle@bigfoot.com.au; > > > > > > > > >hwildfeu@cisco.com; mgarakan@cisco.com; oran@cisco.com; > > > > > > > > >rohan@cisco.com; marcelo@envilogg.se; > > > > > jorgen.bjorkner@hotsip.com; > > > > > > > > >Henry.Sinnreich@mci.com; andreas.piirimets@omnitor.se; > > > > > > > > >Erik.Zetterstrom@omnitor.se; gunnar.hellstrom@omnitor.se= ; > > > > > > > > >Guido.Gybels@rnid.org.uk; james.hamlin@rnid.org.uk; > > > > > > > > >mike.spanner@rnid.org.uk; gv@trace.wisc.edu; > > > > > > > > >trefor@trefor.plus.com > > > > > > > > >Subject: Re: SV: SV: Internet draft on real time text > > > > > conversation > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> "rkumar@cisco.com" 07/01/03 16:04 >>> > > > > > > > > > > > > > > > > > >Arnoud, > > > > > > > > > > > > > > > > > >As I indicated in another email, interoperability with legacy > > > > > > > > V.21 and V.23T > > > > > > > > > TY devices is not feasible unless you support a passthrough > > > > > > > > >fallback. I have no hidden agenda here, I am just > > presenting a > > > > > > > > >technical difficulty that SG16/Q11 and TIA TR.30.1 have been > > > > > > > > >struggling with for the past 6 months. I do not know how > > > > > > > you can do > > > > > > > > >without TTY passthrough if you want universal > > > > > > > interoperability. Here > > > > > > > > >was my mail, sent yesterday: > > > > > > > > > > > > > > > > > >There is a real technical difficulty which I would > > want you all > > > > > > > > to consider. > > > > > > > > > > > > > > > > > >Let us say that you mandate T.140/RFC 2793 for all SIP > > > > > > > phones and do > > > > > > > > >not mandate TTY passthrough. > > > > > > > > > > > > > > > > > >Let us say the call originates from a PSTN TTY and is > > > > > routed via > > > > > > > > a gatewayt > > > > > > > > > o a SIP phone, which has native RFRC2793-based text > > > > > > > > > capabilities. > > > > > > > > > > > > > > > > > >SG16/Q11 has struggled with the fact that you cannot alw= ays > > > > > > > > discriminate aT > > > > > > > > > TY call from a non-TTY call when V.21 or V.23 > > > > > > > modulations are used. > > > > > > > > >In this case, there is no basis for the gateway to > > convert the > > > > > > > > >PSTN > > > > > > > > TTY signali > > > > > > > > > nto RFC 2793/T.140. However, the gateway can determine > > > > > > > that this is > > > > > > > > >a modulated signal based on answer tone (if present) or = on > > > > > > > specific > > > > > > > > >FSK frequencies. It can use VBD passthrough (G.711) in > > > > > > > this case but > > > > > > > > >not RFC 2793 since it does not know if the V.21/V.23 > > > > > > > signal is text > > > > > > > > >or not. > > > > > > > > > > > > > > > > > >Ergo, we cannot preclude a requirement for G.711 VBD > > > > > passthrough > > > > > > > > support onS > > > > > > > > > IP phones in favor of T.140. You can mandate both as musts, > > > > > > > > but you cannoth > > > > > > > > > ave an interoperable solution if you do not have > > passthrough. > > > > > > > > > > > > > > > > > >Rajesh > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >At 04:02 PM 7/1/2003 +0200, A vWijk wrote: > > > > > > > > > >Paul, > > > > > > > > > >How do you feel by mandating T.140/RTP along with the = TTY > > > > > > > > passthrough on> > > > > > > > > > IP telephones and such? > > > > > > > > > >The technology is then ready for the T.140 usage. > > > > > Which may be > > > > > > > > very very> > > > > > > > > > rapidly! > > > > > > > > > >And remember..as I am stating over and over again. > > RFC2793 is > > > > > > > > NOT limited> > > > > > > > > > for the hearing impaired users only! > > > > > > > > > >Many other services will be possible with text > > conversation. > > > > > > > > > >And that will likely stimulate the acceptance of T.140 too. > > > > > > > > > > > > > > > > > > > >And if we explain the goal of T.140 and the possibilities. > > > > > > > > Then I do not> > > > > > > > > > see any problems for the governments to subsidize this > > > > > > > > development and buy> > > > > > > > > > IP telephones for the hearing impaired. > > > > > > > > > >Ofcourse, we have to guarantee the legacy TTY > > > > > support. But also > > > > > > > > > >that it has to be phased out. > > > > > > > > > > > > > > > > > > > >Please do not lock out T.140 by mandating TTY voice > > > > > > > > fallback/passthrough> > > > > > > > > > for IP telephones and clients/servers etc. > > > > > > > > > > > > > > > > > > > >greetz > > > > > > > > > > > > > > > > > > > >Arnoud van Wijk > > > > > > > > > > > > > > > > > > > ><<< "Paul E. Jones" 7/ 1 > > 5:47a >>> > > > > > > > > > >Rajesh, > > > > > > > > > > > > > > > > > > > >I agree with your concerns. Also, I think the case is even > > > > > > > > stronger for > > > > > > > > > >other countries where such issues are as thoughtfully > > > > > > > > considered. I really > > > > > > > > > >doubt that we'll see any requirements in many countrie= s. > > > > > > > > > > > > > > > > > > > >Another factor is cost. It might be a small > > > > > per-unit cost to > > > > > > > > > >include necessary support, but even if it is $10, > > > > > $10 times the > > > > > > > > > >number > > > > > > > > of devices a > > > > > > > > > >large, mass manufacturing company will produce in a > > > > > > > > > >highly-competitive, low-margin environment becomes a > > > > > > > major issue. > > > > > > > > > >Thus, there will be a push-back from the extremely > > > > > high-volume > > > > > > > > > >manufacturers, I think. > > > > > > > > > > > > > > > > > > > >Considering all things, what I think the best roadmap = is: > > > > > > > > > > 1) Create devices that are dual TTY/T.140 devices > > > > > that work > > > > > > > > on PSTN or > > > > > > > > >IP > > > > > > > > > > 2) Make sure every IP phone, residential > > gateway / analog > > > > > > > > > >terminal adapter, etc. > > > > > > > > > > can properly carry TTY signals, modem signals, > > > > > > > fax, etc. and that > > > > > > > > > > a standard TTY device can interface with said device > > > > > > > > > > > > > > > > > > > >Over time, we may see increased support for T.140 > > > > > > > natively on every > > > > > > > > > >IP phone. But, I really suspect that for a long > > > > > time to come, > > > > > > > > (2) is going to > > > > > > > > > >be extremely important. Even so, with (1) in existenc= e, > > > > > > > it means > > > > > > > > > >that people can start to take advantage of T.140 as > > > > > soon as the > > > > > > > > devices are put > > > > > > > > > >into their hands... and so the transition begins. > > > > > > > > > > > > > > > > > > > >Paul > > > > > > > > > > > > > > > > > > > >----- Original Message ----- > > > > > > > > > >From: "Rajesh Kumar" > > > > > > > > > >To: "A vWijk" > > > > > > > > > >Cc: ; = ; > > > > > > > > > >; ; > > > > > > > > ; > > > > > > > > > >; ; ; > > > > > > > > > >; > > > > > ; > > > > > > > > > >; > > > > > ; > > > > > > > > > >; = ; > > > > > > > > > >; ; > > > > > > > > > > > > > > > > > >Sent: Monday, June 30, 2003 11:21 PM > > > > > > > > > >Subject: Re: SV: SV: Internet draft on real time text > > > > > > > conversation > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Dr. van Wijk, > > > > > > > > > > > > > > > > > > > > > > While I support your sentiments, are you sure that > > > > > > > > governments all over > > > > > > > > > >the > > > > > > > > > > > world will provide these mobile text phones to the > > > > > > > > hard-of-hearing on a > > > > > > > > > > > subsidized basis? Also, the monthly plans that > > go with it? > > > > > > > > > > > > > > > > > > > > > > While I do not know about other countries, I seriou= sly > > > > > > > > doubt that the US > > > > > > > > > > > will do such a thing in the near future. I think th= e US > > > > > > > > deaf community > > > > > > > > >is > > > > > > > > > > > stuck with Baudot devices for a long time, > > unless they can > > > > > > > > afford PCs on > > > > > > > > > > > their own budget.Probably a USB interface on > > the SIP phone > > > > > > > > to a cheap > > > > > > > > > > > device is probably the best shot at universal > > > > > > > > accessibility. Even so, I > > > > > > > > > > > doubt if the US government will subsidize the SIP > > > > > > > phone + keypad > > > > > > > > > > > + > > > > > > > > >screen > > > > > > > > > > > combo, even it is cheaper that the Baudot TTY. Thi= s > > > > > > > is because > > > > > > > > > > > this > > > > > > > > >would > > > > > > > > > > > entail a mass replacement for thousands of > > > > > existing Baudot > > > > > > > > > > > devices. > > > > > > > > > > > > > > > > > > > > > > I might be wrong - I hope I am. > > > > > > > > > > > > > > > > > > > > > > Rajesh > > > > > > > > > > > > > > > > > > > > > > At 12:33 PM 6/26/2003 +0200, A vWijk wrote: > > > > > > > > > > > >Paul, > > > > > > > > > > > >I am also looking at a larger scale. > > > > > > > > > > > >Imagine that 3 companies > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >******************************************************************* > > > > > > > >** > > > > > > > > >*** > > > > > > > > >This email and any files transmitted with it are > > > > > confidential and > > > > > > > > >intended solely for the use of the individual or > > > > > entity to whom > > > > > > > > >they are addressed. Any views or opinions expressed > > are solely > > > > > > > > >those of the author and do not necessarily represent > > > > > RNID policy. > > > > > > > > > > > > > > > > > >If you are not the intended recipient you are advised th= at > > > > > > > any use, > > > > > > > > >dissemination, forwarding, printing or copying of this > > > > > email is > > > > > > > > >strictly prohibited. > > > > > > > > > > > > > > > > > >If you have received this email in error please notify > > > > > the RNID > > > > > > > > >Helpdesk by telephone on: +44 (0) 207 296 8282. > > > > > > > > > > > > > > > > > >The Royal National Institute for Deaf People > > > > > > > > >Registered Office 19-23 Featherstone Street > > > > > > > > >London EC1Y 8SL No. 454169 (England) > > > > > > > > >Registered Charity No. 207720 > > > > > > > > > > > > > > > > > > > > >******************************************************************* > > > > > > > >** > > > > > > > > >*** > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 14 06:28: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 GAA05822 for ; Mon, 14 Jul 2003 06:28: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 19c0Ye-0001RX-VI for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 06:27:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EARmLb005541 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 06:27:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0Ye-0001RI-Q9 for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 06:27:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05581 for ; Mon, 14 Jul 2003 06:27:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c0Ya-0003sa-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 06:27:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c0YM-0003rA-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 06:27:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0Y6-0000bm-P3; Mon, 14 Jul 2003 06: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 19bzoc-0006Vk-3t for sipping@optimus.ietf.org; Mon, 14 Jul 2003 05: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 FAA03943 for ; Mon, 14 Jul 2003 05:40:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bzoY-0003N0-00 for sipping@ietf.org; Mon, 14 Jul 2003 05:40:10 -0400 Received: from pxf01lhr.egham.rim.net ([193.109.81.7] helo=mrs02lhr.blackberry.net) by ietf-mx with esmtp (Exim 4.12) id 19bzoX-0003Ms-00 for sipping@ietf.org; Mon, 14 Jul 2003 05:40:09 -0400 Received: from mailrouter02.bwc.prod.uk.blackberry (mailrouter02.bwc.prod.uk.blackberry [172.16.80.218]) by mrs02lhr.blackberry.net (8.11.7+Sun/8.11.3) with ESMTP id h6E9c7O26216; Mon, 14 Jul 2003 10:38:07 +0100 (BST) Received: from imap01.eu.blackberry.net (imap01.eu.blackberry.net [172.16.80.224]) by mailrouter02.bwc.prod.uk.blackberry (8.12.8/8.12.8) with ESMTP id h6E9c5PI009521; Mon, 14 Jul 2003 09:38:05 GMT Received: from imap01.eu.blackberry.net (localhost.eu.blackberry.net [127.0.0.1]) by imap01.eu.blackberry.net (Mirapoint Messaging Server MOS 3.3.2-CR) with ESMTP id ABA01627; Mon, 14 Jul 2003 09:38:05 GMT Received: from 81.160.243.24 by imap01.eu.blackberry.net (Mirapoint Messaging Server MOS 3.3.2-CR) with HTTPS/1.1; Mon, 14 Jul 2003 10:38:05 +0100 Date: Mon, 14 Jul 2003 10:38:05 +0100 From: Guido Gybels To: gv@trace.wisc.edu Cc: guido.gybels@rnid.org.uk, "'Henry Sinnreich'", "'Gunnar Hellstrom'", mike.spanner@rnid.org.uk, 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, paulej@packetizer.com, barry.dingle@bigfoot.com.au, mgarakan@cisco.com, oran@cisco.com, rohan@cisco.com, sipping@ietf.org, A.vWijk@viataal.nl Reply-To: guido.gybels@rnid.org.uk X-Mailer: Webmail Mirapoint Direct 3.3.2-CR MIME-Version: 1.0 Message-Id: <14988b00.a33a47e6.8165f00@imap01.eu.blackberry.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] RE: items for vor voting in the BOF Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 Gregg, <> No I wasn't referring to the BCP document, which is a separate track, but to the slide for voting that Gunnar created and that Henry posted to the list (I think). I spoke again with Arnoud yesterday and we both feel there is a need to properly explain the scope and the user requirements. I'll do my best to send out some material before the ad hoc meeting, which I believe will take place on Thursday, but I'm sure Rohan will provide us with more info about place and time during the WG session this evening. Best regards, 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 From exim@www1.ietf.org Mon Jul 14 06:28:21 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 GAA05842 for ; Mon, 14 Jul 2003 06:28: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 19c0Yl-0001T6-GJ for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 06:27:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EARtYi005638 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 06: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 19c0Yl-0001Sr-Bw for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 06:27: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 GAA05603 for ; Mon, 14 Jul 2003 06:27:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c0Yc-0003sr-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 06:27:46 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c0YK-0003qj-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 06:27:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0Xt-0000VE-CV; Mon, 14 Jul 2003 06: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 19aIPx-0005XP-Kg for sipping@optimus.ietf.org; Wed, 09 Jul 2003 13:07: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 NAA10507 for ; Wed, 9 Jul 2003 13:07:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aIPu-0000sZ-00 for sipping@ietf.org; Wed, 09 Jul 2003 13:07:42 -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 19aIPs-0000sO-00 for sipping@ietf.org; Wed, 09 Jul 2003 13:07:41 -0400 Received: from berlin (berlin.packetizer.org [192.168.1.4]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id h69G6ktt023797; Wed, 9 Jul 2003 12:06:46 -0400 Message-ID: <023a01c3463c$896add50$0401a8c0@packetizer.org> From: "Paul E. Jones" To: "Henry Sinnreich" , "'Gunnar Hellstrom'" , , , , , , "'Rajesh Kumar'" , , , "'James Hamlin'" , , , , , , , References: <000001c343fb$274b6290$c17e32a6@hsinnreich2> Date: Wed, 9 Jul 2003 13:07:06 -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: items for vor voting in the BOF Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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, I made a number of comments on the previous proposal. Specifically, I did not want to see #3 as it was written. T.38 AND V.18 are entirely separate. Further, if we allow for VBD operation for TTY devices connected via RJ11, then V.18 would not be something the phone needs to be complicated with. Realizing that this is a vote on a number of issues, I'd like to more clearly separate the issues. I removed one sentence that caused concern for Gunnar related to V.21/V.23. Thus, please replace #3 with: 3. MUST/SHOULD provide an interface to legacy TTY devices and transport those signals as RFC 2793 text 4. MUST/SHOULD provide an interface to legacy TTY devices and allow transparent carriage of the TTY protocol through the audio path ("pass-through" mode) 5. MUST/SHOULD provide an RJ11 port for interfacing with legacy TTY devices, fax devices, modems, and other legacy equipment for the purposes of supporting the transfer of information from/to those legacy devices. 6. MUST/SHOULD provide a 2.5mm audio plug for interfacing with a headset or legacy TTY device Note that #5 gets into the area of V.150 modem relay and pass-through, as well as T.38 fax relay. That came from the original #3. However, I do not see the value in spelling out those protocols for the purposes of this vote. Also, in #2, there is still a reference to a web interface. I said I don't think that's necessary, since if one can access the web interface, he/she can probably just use a PC for communication. However, they may not be true. In any case, I can see the web interface as "interesting", but certainly could not see mandating it. Also, I don't agree with the comment about blind people needing a keyboard and screen. I propose rewording #2 as follows: 2. MUST/SHOULD provide a way to input text and display text, through any method: Built in user interfaces, standard wired or wireless interfaces for keyboard and display, or support for text through its web interface. OR, better: 2A. MUST/SHOULD provide a way to input text and display text through either a built in user interfaces or standard wired or wireless interfaces (including a screen and keyboard) 2B. MUST/SHOULD provide a way to input text and display text through its web interface. Paul ----- Original Message ----- From: "Henry Sinnreich" To: "'Gunnar Hellstrom'" ; ; ; ; ; ; "'Rajesh Kumar'" ; ; ; "'James Hamlin'" ; ; ; ; ; ; ; ; Sent: Sunday, July 06, 2003 4:14 PM Subject: RE: items for vor voting in the BOF > Please see the attached slide for voting at the IETF BOF on "Interactive > Text Support for SIP Telephony Devices". > > We have no day/time yet for the BOF, but expect to get it scheduled, as > discussed with Rohan Mahy. > > Many thanks to Gunnar Hellstrom for the formulation of the text. > > Thanks, Henry > > > -----Original Message----- > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > > Sent: Wednesday, July 02, 2003 3:44 AM > > To: Henry Sinnreich > > Cc: trefor@trefor.plus.com; gv@trace.wisc.edu; > > mike.spanner@rnid.org.uk; Guido.Gybels@rnid.org.uk; > > Erik.Zetterstrom@omnitor.se; 'Rajesh Kumar'; 'James Hamlin'; > > andreas.piirimets@omnitor.se; jorgen.bjorkner@hotsip.com; > > marcelo@envilogg.se; rohan@cisco.com; oran@cisco.com; > > mgarakan@cisco.com; hwildfeu@cisco.com; > > barry.dingle@bigfoot.com.au; paulej@packetizer.com > > Subject: SV: items for vor voting in the BOF > > > > > > Henry, > > Yes please use the sentences in the IETF meeting, with no 3 > > amended as below. > > > > Some thoughts an explanations: > > > > Blind reference: > > ---------------- > > The reference about display interface for blind people refers > > to a need for blind people to follow hat is displayed on the > > phone through a device of their choice. It may be voice > > synthesis or electromechanical braille display or display > > with enlargement or extra strong light. We do not expect the > > phone to include these special devices, so a standardised > > interface to them must be provided. The SIP phone will have > > states so it will be impossible to expect that you shall be > > able to operate it without feedback from the phone. The > > mobile industry made the mistake to not initially provide a > > standardised interface to operate the mobile phone and that > > has caused enormous problems for blind people. The AT command > > interface available to 3GPP mobile phones seem to have > > overcome this mistake by including commands and responses for > > accessing most things required for operation through a serial > > command language that can be issued through Bluetooth or a > > USB or serial connector. Products are emerging. Something > > similar must be done on SIP phones. I concentrated on deaf > > issues, but I see that we have common interests here. > > > > The web interface: > > ------------------ > > I saw a comment that the web interface should not be > > mentioned as a solution. That may be true, it was with > > hesitation that I added it. But: I have seen SIP phones with > > the possibility to add the video component from a nearby > > computer. Similar things can be done for text. It is still > > valid to let the phone have all the other SIP phone > > functionality. I can imagine PDA access through Bluetooth > > executing a web browser to operate the phone. The text > > component could be accessible through that interface. > > Handling only the user interface aspect of the text part is > > an enormous difference from handling the complete SIP > > protocol and all audio coding. The sum is of course that when > > we open for many ways to add text and that the person > > carrying a text interface with him, will find that it can not > > be attached to any phone, and then accessibility is again > > limited. I am quite sure that phones will not come without > > display, and that they will follow the trend on PDAs and > > mobile phones, to include a full aphanumeric keyboard because > > it is needed for address and phonebook use, as well as to > > provide a good user interface to the very popular real time > > text conversation function ;-) . So, I am not too worried > > that we give many options. > > > > > > The analogue interface. > > ----------------------- > > The statement no 3 about the analogue adapter is not really > > formulated in a strict IETF style. A starting sentence is needed: > > > > 3. A SIP device MAY provide analogue adapter functionality > > through an RJ11 port. IF an RJ11 port is provided for a PSTN > > device adapter interface, THEN it MUST/SHOULD provide T.38 > > support for fax AND V.18+RFC2793 support for text alternating > > with voice. If T.38 or RFC2793 negotiation fails then it MAY > > try to connect for G.711 and pass the audio through. > > > > > > > > > > ------------------------------------------- > > Gunnar Hellstrom, Omnitor, Renathvagen 2 > > SE 121 37 Johanneshov, SWEDEN > > Tel: +46 8 556 002 03 Mob: +46 708204288 > > e-mail: gunnar.hellstrom@omnitor.se > > web: www.omnitor.se > > > > > > > -----Ursprungligt meddelande----- > > > Fran: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com] > > > Skickat: den 2 juli 2003 02:27 > > > Till: 'Gunnar Hellstrom' > > > Kopia: paulej@packetizer.com; barry.dingle@bigfoot.com.au; > > > hwildfeu@cisco.com; mgarakan@cisco.com; oran@cisco.com; > > > rohan@cisco.com; marcelo@envilogg.se; jorgen.bjorkner@hotsip.com; > > > Henry.Sinnreich@mci.com; andreas.piirimets@omnitor.se; > > 'James Hamlin'; > > > 'Rajesh Kumar'; Erik.Zetterstrom@omnitor.se; > > Guido.Gybels@rnid.org.uk; > > > mike.spanner@rnid.org.uk; gv@trace.wisc.edu; trefor@trefor.plus.com > > > Amne: items for vor voting in the BOF > > > > > > > > > Gunnar, > > > > > > I will use with your permission your formulation to put these three > > > items to vote in the BOF, for MUST or SHOULD: > > > > > > 1. MUST/SHOULD include protocol support for RFC2793 for text. > > > > > > 2. MUST/SHOULD provide a way to input text and display > > text, through > > > any > > > method: Built in user interfaces, standard wired or > > wireless interfaces > > > for keyboard and display ( that is needed anyway for blind > > people), or > > > support for text through its already mandated web interface. > > > > > > ---- > > > And, with some doubt: > > > > > > 3. IF an RJ11 port is provided for a PSTN device adapter interface, > > > THEN it MUST/SHOULD provide T.38 support for fax AND V.18+RFC2793 > > > support for text alternating with voice. If T.38 or RFC2793 > > > negotiation fails then it MAY try to connect for G.711 and pass the > > > audio through.( is there any need to mandate also modem support? ) > > > > > > I believe these are very reasonable requirements. > > > > > > Thanks, Henry > > > > > > > -----Original Message----- > > > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > > > > Sent: Tuesday, July 01, 2003 4:08 PM > > > > To: Rajesh Kumar; James Hamlin > > > > Cc: paulej@packetizer.com; barry.dingle@bigfoot.com.au; > > > > hwildfeu@cisco.com; mgarakan@cisco.com; oran@cisco.com; > > > > rohan@cisco.com; marcelo@envilogg.se; jorgen.bjorkner@hotsip.com; > > > > Henry.Sinnreich@mci.com; andreas.piirimets@omnitor.se; > > > > Erik.Zetterstrom@omnitor.se; Guido.Gybels@rnid.org.uk; > > > > mike.spanner@rnid.org.uk; gv@trace.wisc.edu; > > trefor@trefor.plus.com > > > > Subject: SV: SV: SV: Internet draft on real time text conversation > > > > > > > > > > > > I see the discussion going in circles. > > > > > > > > Henry gave me the delicate task to sum up and get a > > proposed writing > > > > into the Sipdev specification. > > > > > > > > After looking back in the discussion, I come to the > > conclusion that, > > > > the only requirements that make real sense and takes deaf > > telecomms > > > > a bit towards equal opportunities is that SIP devices: > > > > > > > > 1. MUST include protocol support for RFC2793 for text. > > > > > > > > 2. MUST provide a way to input text and display text, through any > > > > method: Built in user interfaces, standard wired or wireless > > > > interfaces for keyboard and display ( that is needed anyway for > > > > blind people), or support for text through its already > > mandated web > > > > interface. > > > > > > > > ---- > > > > And, with some doubt: > > > > > > > > 3. IF an RJ11 port is provided for a PSTN device adapter > > interface, > > > > THEN it MUST provide T.38 support for fax AND > > V.18+RFC2793 support > > > > for text alternating with voice. If T.38 or RFC2793 negotiation > > > > fails then it MAY try to connect for G.711 and pass the audio > > > > through.( is there any need to mandate also modem support? ) > > > > > > > > > > > > > > > > ---- > > > > I am sure SIP signaling can take care of most tricky > > situations that > > > > have been up for discussion. > > > > > > > > E.g. > > > > A SIP phone without RJ11 port in contact with a PSTN > > device through > > > > a gateway, would signal RFC2793 capability. That will > > make a gateway > > > > involved in the call perceive any indication on use of modem-like > > > > tones from PSTN as text if possible. > > > > > > > > > > > > > > > > I intend to propose text with that content soon for the > > sipdev spec. > > > > > > > > With that, we could perhaps change topic to discuss > > contents of the > > > > text capable device I-D that Erik and Andreas made a > > first draft of. > > > > > > > > Has time been booked in the SIPPING meeting in Wienna to discuss > > > > that? > > > > > > > > Can Erik and Andreas provide us with a second draft? > > > > > > > > Best regards > > > > > > > > Gunnar > > > > > > > > > > > > ------------------------------------------- > > > > Gunnar Hellstrom, Omnitor, Renathvagen 2 > > > > SE 121 37 Johanneshov, SWEDEN > > > > Tel: +46 8 556 002 03 Mob: +46 708204288 > > > > e-mail: gunnar.hellstrom@omnitor.se > > > > web: www.omnitor.se > > > > > > > > > > > > > -----Ursprungligt meddelande----- > > > > > Fran: Rajesh Kumar [mailto:rkumar@cisco.com] > > > > > Skickat: den 1 juli 2003 19:15 > > > > > Till: James Hamlin > > > > > Kopia: paulej@packetizer.com; barry.dingle@bigfoot.com.au; > > > > > hwildfeu@cisco.com; mgarakan@cisco.com; oran@cisco.com; > > > > > rohan@cisco.com; marcelo@envilogg.se; > > jorgen.bjorkner@hotsip.com; > > > > > Henry.Sinnreich@mci.com; andreas.piirimets@omnitor.se; > > > > > Erik.Zetterstrom@omnitor.se; gunnar.hellstrom@omnitor.se; > > > > > Guido.Gybels@rnid.org.uk; mike.spanner@rnid.org.uk; > > > > gv@trace.wisc.edu; > > > > > trefor@trefor.plus.com > > > > > Amne: RE: SV: SV: Internet draft on real time text conversation > > > > > > > > > > > > > > > James, > > > > > > > > > > The intent here is that the called party could be any SIP > > > > phone, not > > > > > just SIP phones specially designated for text-only > > > > operation. I think > > > > > the intent expressed by Guido and Gunnar et al is that a > > > > PSTN TTY user > > > > > should be able > > > > > to open an RFC 2793 text channel with any SIP phone user, > > > > and that the > > > > > latter should either have an integral keyboard/display > > or a port > > > > > to such a display. So the problem of call > > discrimination when the > > > > > caller is a V.21 or > > > > > V.23 legacy textphone is not solved unless you allow > > > > passthrough fallback > > > > > when you cannot tell whether the V.21 signal is text or not - > > > > > regardless of the existence of gateways/servers that do PSTN > > > > > textphone to RFC 2793 conversion. > > > > > > > > > > In general, the solution of designating special phone > > numbers for > > > > > deaf-accessible operation militates against the stipulation > > > > that the > > > > > deaf be able to create text channels from any PSTN or SIP phone > > > > > number, and to any PSTN or SIP phone number. Here, textphone > > > > > detection has to be on the basis of control signals > > > > exchanged in the > > > > > bearer stream or on the content of the bearer stream, > > and not on a > > > > > priori numbering plans that create a "deaf ghetto". > > > > > > > > > > For technical reasons, I still think you must mandate > > passthrough > > > > > operation to enable universal interoperability. > > > > > > > > > > Kind regards to all. > > > > > > > > > > Rajesh > > > > > > > > > > > > > > > > > > > > At 04:33 PM 7/1/2003 +0100, James Hamlin wrote: > > > > > >Rajesh > > > > > > > > > > > >It would be possible for people on the IP network to have PSTN > > > > > numbers that > > > > > >are taken from a block that is assigned only to text. > > Therefore > > > > > the gateway > > > > > >between PSTN and the IP network knows from the called number > > > > > that the intent > > > > > >is to use text. > > > > > > > > > > > >Regards > > > > > > > > > > > >James > > > > > > > > > > > >-----Original Message----- > > > > > >From: Rajesh Kumar [mailto:rkumar@cisco.com] > > > > > >Sent: 01 July 2003 16:05 > > > > > >To: A vWijk > > > > > >Cc: paulej@packetizer.com; barry.dingle@bigfoot.com.au; > > > > > >hwildfeu@cisco.com; mgarakan@cisco.com; oran@cisco.com; > > > > > >rohan@cisco.com; marcelo@envilogg.se; > > jorgen.bjorkner@hotsip.com; > > > > > >Henry.Sinnreich@mci.com; andreas.piirimets@omnitor.se; > > > > > >Erik.Zetterstrom@omnitor.se; gunnar.hellstrom@omnitor.se; > > > > > >Guido.Gybels@rnid.org.uk; james.hamlin@rnid.org.uk; > > > > > >mike.spanner@rnid.org.uk; gv@trace.wisc.edu; > > > > > >trefor@trefor.plus.com > > > > > >Subject: Re: SV: SV: Internet draft on real time text > > conversation > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> "rkumar@cisco.com" 07/01/03 16:04 >>> > > > > > > > > > > > >Arnoud, > > > > > > > > > > > >As I indicated in another email, interoperability with legacy > > > > > V.21 and V.23T > > > > > > TY devices is not feasible unless you support a passthrough > > > > > >fallback. I have no hidden agenda here, I am just presenting a > > > > > >technical difficulty that SG16/Q11 and TIA TR.30.1 have been > > > > > >struggling with for the past 6 months. I do not know how > > > > you can do > > > > > >without TTY passthrough if you want universal > > > > interoperability. Here > > > > > >was my mail, sent yesterday: > > > > > > > > > > > >There is a real technical difficulty which I would want you all > > > > > to consider. > > > > > > > > > > > >Let us say that you mandate T.140/RFC 2793 for all SIP > > > > phones and do > > > > > >not mandate TTY passthrough. > > > > > > > > > > > >Let us say the call originates from a PSTN TTY and is > > routed via > > > > > a gatewayt > > > > > > o a SIP phone, which has native RFRC2793-based text > > > > > > capabilities. > > > > > > > > > > > >SG16/Q11 has struggled with the fact that you cannot always > > > > > discriminate aT > > > > > > TY call from a non-TTY call when V.21 or V.23 > > > > modulations are used. > > > > > >In this case, there is no basis for the gateway to convert the > > > > > >PSTN > > > > > TTY signali > > > > > > nto RFC 2793/T.140. However, the gateway can determine > > > > that this is > > > > > >a modulated signal based on answer tone (if present) or on > > > > specific > > > > > >FSK frequencies. It can use VBD passthrough (G.711) in > > > > this case but > > > > > >not RFC 2793 since it does not know if the V.21/V.23 > > > > signal is text > > > > > >or not. > > > > > > > > > > > >Ergo, we cannot preclude a requirement for G.711 VBD > > passthrough > > > > > support onS > > > > > > IP phones in favor of T.140. You can mandate both as musts, > > > > > but you cannoth > > > > > > ave an interoperable solution if you do not have passthrough. > > > > > > > > > > > >Rajesh > > > > > > > > > > > > > > > > > > > > > > > >At 04:02 PM 7/1/2003 +0200, A vWijk wrote: > > > > > > >Paul, > > > > > > >How do you feel by mandating T.140/RTP along with the TTY > > > > > passthrough on> > > > > > > IP telephones and such? > > > > > > >The technology is then ready for the T.140 usage. > > Which may be > > > > > very very> > > > > > > rapidly! > > > > > > >And remember..as I am stating over and over again. RFC2793 is > > > > > NOT limited> > > > > > > for the hearing impaired users only! > > > > > > >Many other services will be possible with text conversation. > > > > > > >And that will likely stimulate the acceptance of T.140 too. > > > > > > > > > > > > > >And if we explain the goal of T.140 and the possibilities. > > > > > Then I do not> > > > > > > see any problems for the governments to subsidize this > > > > > development and buy> > > > > > > IP telephones for the hearing impaired. > > > > > > >Ofcourse, we have to guarantee the legacy TTY > > support. But also > > > > > > >that it has to be phased out. > > > > > > > > > > > > > >Please do not lock out T.140 by mandating TTY voice > > > > > fallback/passthrough> > > > > > > for IP telephones and clients/servers etc. > > > > > > > > > > > > > >greetz > > > > > > > > > > > > > >Arnoud van Wijk > > > > > > > > > > > > > ><<< "Paul E. Jones" 7/ 1 5:47a >>> > > > > > > >Rajesh, > > > > > > > > > > > > > >I agree with your concerns. Also, I think the case is even > > > > > stronger for > > > > > > >other countries where such issues are as thoughtfully > > > > > considered. I really > > > > > > >doubt that we'll see any requirements in many countries. > > > > > > > > > > > > > >Another factor is cost. It might be a small > > per-unit cost to > > > > > > >include necessary support, but even if it is $10, > > $10 times the > > > > > > >number > > > > > of devices a > > > > > > >large, mass manufacturing company will produce in a > > > > > > >highly-competitive, low-margin environment becomes a > > > > major issue. > > > > > > >Thus, there will be a push-back from the extremely > > high-volume > > > > > > >manufacturers, I think. > > > > > > > > > > > > > >Considering all things, what I think the best roadmap is: > > > > > > > 1) Create devices that are dual TTY/T.140 devices > > that work > > > > > on PSTN or > > > > > >IP > > > > > > > 2) Make sure every IP phone, residential gateway / analog > > > > > > >terminal adapter, etc. > > > > > > > can properly carry TTY signals, modem signals, > > > > fax, etc. and that > > > > > > > a standard TTY device can interface with said device > > > > > > > > > > > > > >Over time, we may see increased support for T.140 > > > > natively on every > > > > > > >IP phone. But, I really suspect that for a long > > time to come, > > > > > (2) is going to > > > > > > >be extremely important. Even so, with (1) in existence, > > > > it means > > > > > > >that people can start to take advantage of T.140 as > > soon as the > > > > > devices are put > > > > > > >into their hands... and so the transition begins. > > > > > > > > > > > > > >Paul > > > > > > > > > > > > > >----- Original Message ----- > > > > > > >From: "Rajesh Kumar" > > > > > > >To: "A vWijk" > > > > > > >Cc: ; ; > > > > > > >; ; > > > > > ; > > > > > > >; ; ; > > > > > > >; > > ; > > > > > > >; > > ; > > > > > > >; ; > > > > > > >; ; > > > > > > > > > > > >Sent: Monday, June 30, 2003 11:21 PM > > > > > > >Subject: Re: SV: SV: Internet draft on real time text > > > > conversation > > > > > > > > > > > > > > > > > > > > > > Dr. van Wijk, > > > > > > > > > > > > > > > > While I support your sentiments, are you sure that > > > > > governments all over > > > > > > >the > > > > > > > > world will provide these mobile text phones to the > > > > > hard-of-hearing on a > > > > > > > > subsidized basis? Also, the monthly plans that go with it? > > > > > > > > > > > > > > > > While I do not know about other countries, I seriously > > > > > doubt that the US > > > > > > > > will do such a thing in the near future. I think the US > > > > > deaf community > > > > > >is > > > > > > > > stuck with Baudot devices for a long time, unless they can > > > > > afford PCs on > > > > > > > > their own budget.Probably a USB interface on the SIP phone > > > > > to a cheap > > > > > > > > device is probably the best shot at universal > > > > > accessibility. Even so, I > > > > > > > > doubt if the US government will subsidize the SIP > > > > phone + keypad > > > > > > > > + > > > > > >screen > > > > > > > > combo, even it is cheaper that the Baudot TTY. This > > > > is because > > > > > > > > this > > > > > >would > > > > > > > > entail a mass replacement for thousands of > > existing Baudot > > > > > > > > devices. > > > > > > > > > > > > > > > > I might be wrong - I hope I am. > > > > > > > > > > > > > > > > Rajesh > > > > > > > > > > > > > > > > At 12:33 PM 6/26/2003 +0200, A vWijk wrote: > > > > > > > > >Paul, > > > > > > > > >I am also looking at a larger scale. > > > > > > > > >Imagine that 3 companies > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >******************************************************************* > > > > >** > > > > > >*** > > > > > >This email and any files transmitted with it are > > confidential and > > > > > >intended solely for the use of the individual or > > entity to whom > > > > > >they are addressed. Any views or opinions expressed are solely > > > > > >those of the author and do not necessarily represent > > RNID policy. > > > > > > > > > > > >If you are not the intended recipient you are advised that > > > > any use, > > > > > >dissemination, forwarding, printing or copying of this > > email is > > > > > >strictly prohibited. > > > > > > > > > > > >If you have received this email in error please notify > > the RNID > > > > > >Helpdesk by telephone on: +44 (0) 207 296 8282. > > > > > > > > > > > >The Royal National Institute for Deaf People > > > > > >Registered Office 19-23 Featherstone Street > > > > > >London EC1Y 8SL No. 454169 (England) > > > > > >Registered Charity No. 207720 > > > > > > > > > > > >******************************************************************* > > > > >** > > > > > >*** > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 14 07:13: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 HAA08812 for ; Mon, 14 Jul 2003 07: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 19c1GS-0006o4-3E for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 07:13:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EBD4oP026158 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 07:13:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c1GR-0006na-L8 for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 07:13: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 GAA05537 for ; Mon, 14 Jul 2003 06:27:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c0YO-0003rl-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 06:27:32 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c0YK-0003ql-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 06:27:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0Y4-0000aU-3K; Mon, 14 Jul 2003 06:27:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19byEq-0001L1-HV for sipping@optimus.ietf.org; Mon, 14 Jul 2003 03:59: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 DAA00306 for ; Mon, 14 Jul 2003 03:59:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19byEn-0002Sc-00 for sipping@ietf.org; Mon, 14 Jul 2003 03:59:09 -0400 Received: from dasher.doit.wisc.edu ([144.92.197.145] helo=smtp1.doit.wisc.edu) by ietf-mx with esmtp (Exim 4.12) id 19byEm-0002SZ-00 for sipping@ietf.org; Mon, 14 Jul 2003 03:59:08 -0400 Received: from conversion-daemon.smtp1.doit.wisc.edu by smtp1.doit.wisc.edu (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) id <0HI0006018SD1L@smtp1.doit.wisc.edu> for sipping@ietf.org; Mon, 14 Jul 2003 02:57:57 -0500 (CDT) Received: from USD320002X (000-050-839.area3.spcsdns.net [68.24.200.40]) by smtp1.doit.wisc.edu (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPA id <0HI000HJD8QIU9@smtp1.doit.wisc.edu>; Mon, 14 Jul 2003 02:57:56 -0500 (CDT) Date: Mon, 14 Jul 2003 02:56:39 -0500 From: Gregg Vanderheiden In-reply-to: <00ae01c34942$8d6bd770$8ab8a051@hsinnreich2> To: "'Henry Sinnreich'" , "'Gunnar Hellstrom'" , Guido.Gybels@rnid.org.uk, mike.spanner@rnid.org.uk, andreas.piirimets@omnitor.se, gv@trace.wisc.edu, trefor@trefor.plus.com, "'Rajesh Kumar'" , marcelo@envilogg.se, jorgen.bjorkner@hotsip.com, "'James Hamlin'" , Erik.Zetterstrom@omnitor.se, hwildfeu@cisco.com, paulej@packetizer.com, barry.dingle@bigfoot.com.au, mgarakan@cisco.com, oran@cisco.com, rohan@cisco.com, sipping@ietf.org, "'Judy Harkins'" Reply-to: gv@trace.wisc.edu Message-id: <005301c349dd$9f2de110$28c81844@USD320002X> Organization: Trace Center MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Sipping] RE: items for vor voting in the BOF Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 All, Can someone post the current form of the items that are up for vote at the BOF? Is it still the original 3? Or has it been revised based on comments? Thanks Gregg -- ------------------------------ Gregg C Vanderheiden Ph.D. Professor - Ind. Engr. & BioMed Engr. Director - Trace R & D Center University of Wisconsin-Madison -----Original Message----- From: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com] Sent: Sunday, July 13, 2003 8:23 AM To: 'Gunnar Hellstrom'; 'Henry Sinnreich'; Guido.Gybels@rnid.org.uk; mike.spanner@rnid.org.uk; andreas.piirimets@omnitor.se; gv@trace.wisc.edu; trefor@trefor.plus.com; 'Rajesh Kumar'; marcelo@envilogg.se; jorgen.bjorkner@hotsip.com; 'James Hamlin'; Erik.Zetterstrom@omnitor.se; hwildfeu@cisco.com; paulej@packetizer.com; barry.dingle@bigfoot.com.au; mgarakan@cisco.com; oran@cisco.com; rohan@cisco.com; sipping@ietf.org Subject: RE: items for vor voting in the BOF From: Marcia Beaulieu [mbeaulie@foretec.com] Sent: Tuesday, July 08, 2003 5:04 PM To: Henry Sinnreich; 'Dean Willis'; 'Henry Sinnreich'; agenda@ietf.org Cc: rohan@cisco.com; gonzalo.camarillo@ericsson.com Subject: RE: Request for ad-hoc meeting on interactive text in SIP devices Meeting rooms at the Austria Center are not available after the regularly scheduled meetings. We are charged rent for the rooms and we do not rent them longer than what is needed. Marcia At 02:54 PM 7/2/03 -0500, Henry Sinnreich wrote: > > Would an evening "after hours" schedule work? > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Jul 14 07:16: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 GAA05653 for ; Mon, 14 Jul 2003 06:28: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 19c0YU-0000sk-8o for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 06:27:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EARcMw003381 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 06:27:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0YU-0000rV-1K for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 06:27: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 GAA05550 for ; Mon, 14 Jul 2003 06:27:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c0YP-0003ro-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 06:27:33 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c0YG-0003rB-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 06:27:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0Xz-0000YT-Vm; Mon, 14 Jul 2003 06:27:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19azsy-0002lS-Pl for sipping@optimus.ietf.org; Fri, 11 Jul 2003 11:32: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 LAA03788 for ; Fri, 11 Jul 2003 11:32:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19azsw-0006Z8-00 for sipping@ietf.org; Fri, 11 Jul 2003 11:32:34 -0400 Received: from mail3.pi.se ([195.7.64.137]) by ietf-mx with esmtp (Exim 4.12) id 19azsu-0006Z5-00 for sipping@ietf.org; Fri, 11 Jul 2003 11:32:33 -0400 Received: from VAIOMHP (1Cust201.tnt2.stk3.swe.da.uu.net [213.116.227.201]) (authenticated) by mail3.pi.se (8.11.2/8.11.2) with ESMTP id h6BFW6728782; Fri, 11 Jul 2003 17:32:06 +0200 (CEST) From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= To: "A vWijk" , , , , , , , , , , , , , , , , , , Date: Fri, 11 Jul 2003 17:31:50 +0200 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.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.pi.se id h6BFW6728782 Content-Transfer-Encoding: quoted-printable Subject: [Sipping] SV: SV: items for vor voting in the BOF Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 Rohan or anyone who knows: Do we have a fixed day and time for the following items in the coming IET= F meeting? 1. The discussion of the text and alerting additions in the SIPDEV specification. 2. A BOF session on SIP text conversation. I will not come, but there is a slight possibility that Erik Zetterstr=F6= m can go there for these discussions. Erik has just done an RFC2793 implementat= ion in JAVA, and is co-author of the draft BCP. Regards Gunnar ------------------------------------------- Gunnar Hellstr=F6m, Omnitor, Renathv=E4gen 2 SE 121 37 Johanneshov, SWEDEN Tel: +46 8 556 002 03 Mob: +46 708204288 e-mail: gunnar.hellstrom@omnitor.se web: www.omnitor.se > -----Ursprungligt meddelande----- > Fr=E5n: A vWijk [mailto:A.vWijk@viataal.nl] > Skickat: den 11 juli 2003 10:52 > Till: barry.dingle@bigfoot.com.au; hwildfeu@cisco.com; > mgarakan@cisco.com; oran@cisco.com; rkumar@cisco.com; rohan@cisco.com; > marcelo@envilogg.se; jorgen.bjorkner@hotsip.com; sipping@ietf.org; > Henry.Sinnreich@mci.com; andreas.piirimets@omnitor.se; > Erik.Zetterstrom@omnitor.se; gunnar.hellstrom@omnitor.se; > paulej@packetizer.com; Guido.Gybels@rnid.org.uk; > James.Hamlin@rnid.org.uk; mike.spanner@rnid.org.uk; gv@trace.wisc.edu; > trefor@trefor.plus.com > =C4mne: Re: SV: items for vor voting in the BOF > > > Yes, > we must take some time to see what exactly needs to be covered > and what kind of behaviour we need. > I wil make sure that the authors of the Invocation draft > camarillo-deaf-01 will understand that the role is getting bigger here. > > The role of the PSTN will be important and also the role of the > gateways for backward compatibility to legacy TTY's. > > I will be at the IETF, so please feel free to grab me when you > see me. I am the only deaf guy around there. So it should be easy. :-) > > greetz > > Arnoud > > <<< Gunnar Hellstr=F6m 7/11 12:14a >>> > > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 14 07:16: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 GAA05627 for ; Mon, 14 Jul 2003 06:28: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 19c0YK-0000mV-JP for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 06:27:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EARSuw002975 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 06:27:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0YJ-0000ln-PS for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 06:27: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 GAA05516 for ; Mon, 14 Jul 2003 06:27:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c0YC-0003qg-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 06:27:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c0YA-0003qY-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 06:27:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0Y0-0000Ys-Qm; Mon, 14 Jul 2003 06:27:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bRcg-0007Zf-Ja for sipping@optimus.ietf.org; Sat, 12 Jul 2003 17:09: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 RAA11333 for ; Sat, 12 Jul 2003 17:09:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bRce-0005VD-00 for sipping@ietf.org; Sat, 12 Jul 2003 17:09:36 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19bRcd-0005VA-00 for sipping@ietf.org; Sat, 12 Jul 2003 17:09:35 -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 h6CL83pp010935; Sat, 12 Jul 2003 14:08: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 AJB87874; Sat, 12 Jul 2003 14:05:28 -0700 (PDT) Date: Sat, 12 Jul 2003 14:09:46 -0700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "A vWijk" , , , , , , , , , , , , , , , , , To: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= From: Rohan Mahy In-Reply-To: Message-Id: <2A24E1C8-B4AD-11D7-9589-0003938AF740@cisco.com> Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: quoted-printable Subject: [Sipping] Re: SV: SV: items for vor voting in the BOF Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 Gunnar, Both these issues will be discussed in an adhoc meeting or "bar-bof" in=20= Vienna. No date or place is scheduled because the IETF secretariat has=20= to pay by the hour this time for the rooms in the congress center. =20 (Normally they pay a flat rate for the exclusive use of certain rooms=20 for the entire week.) This will probably occur offsite. I believe that=20= Henry is still looking for a location. Assuming he comes up with=20 something suitable, I will announce the adhoc at the start of the=20 SIPPING meeting and post a note to the mailing list. Also, as I stated before, sipdev is an individual informational=20 document meant to provide guidance to the industry, but is not=20 specifically endorsed by the IETF or any WG. (IETF WGs generally do=20 not endorse implementation recommendations). It is not a formal=20 specification in the IETF sense. Also, the term BOF is used formally by=20= the IETF in a very specific way, which does not apply to this meeting. =20= The official term is "adhoc". hope this helps. thanks, -rohan On Friday, July 11, 2003, at 08:31 AM, Gunnar Hellstr=F6m wrote: > Rohan or anyone who knows: > > Do we have a fixed day and time for the following items in the coming=20= > IETF > meeting? > > 1. The discussion of the text and alerting additions in the SIPDEV > specification. > > 2. A BOF session on SIP text conversation. > > I will not come, but there is a slight possibility that Erik=20 > Zetterstr=F6m can > go there for these discussions. Erik has just done an RFC2793=20 > implementation > in JAVA, and is co-author of the draft BCP. > > Regards > > Gunnar > ------------------------------------------- > Gunnar Hellstr=F6m, Omnitor, Renathv=E4gen 2 > SE 121 37 Johanneshov, SWEDEN > Tel: +46 8 556 002 03 Mob: +46 708204288 > e-mail: gunnar.hellstrom@omnitor.se > web: www.omnitor.se > > >> -----Ursprungligt meddelande----- >> Fr=E5n: A vWijk [mailto:A.vWijk@viataal.nl] >> Skickat: den 11 juli 2003 10:52 >> Till: barry.dingle@bigfoot.com.au; hwildfeu@cisco.com; >> mgarakan@cisco.com; oran@cisco.com; rkumar@cisco.com; = rohan@cisco.com; >> marcelo@envilogg.se; jorgen.bjorkner@hotsip.com; sipping@ietf.org; >> Henry.Sinnreich@mci.com; andreas.piirimets@omnitor.se; >> Erik.Zetterstrom@omnitor.se; gunnar.hellstrom@omnitor.se; >> paulej@packetizer.com; Guido.Gybels@rnid.org.uk; >> James.Hamlin@rnid.org.uk; mike.spanner@rnid.org.uk; = gv@trace.wisc.edu; >> trefor@trefor.plus.com >> =C4mne: Re: SV: items for vor voting in the BOF >> >> >> Yes, >> we must take some time to see what exactly needs to be covered >> and what kind of behaviour we need. >> I wil make sure that the authors of the Invocation draft >> camarillo-deaf-01 will understand that the role is getting bigger=20 >> here. >> >> The role of the PSTN will be important and also the role of the >> gateways for backward compatibility to legacy TTY's. >> >> I will be at the IETF, so please feel free to grab me when you >> see me. I am the only deaf guy around there. So it should be easy. = :-) >> >> greetz >> >> Arnoud >> >> <<< Gunnar Hellstr=F6m 7/11 12:14a >>> >> >> >> >> > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 14 07:16: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 GAA05623 for ; Mon, 14 Jul 2003 06:28: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 19c0YK-0000mb-K5 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 06:27:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EARSC0002974 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 06:27:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0YJ-0000ll-Nj for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 06:27: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 GAA05522 for ; Mon, 14 Jul 2003 06:27:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c0YD-0003r3-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 06:27:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c0YA-0003qb-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 06:27:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0Y2-0000Zg-DN; Mon, 14 Jul 2003 06:27:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bfeG-0004e9-55 for sipping@optimus.ietf.org; Sun, 13 Jul 2003 08:08: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 IAA15209 for ; Sun, 13 Jul 2003 08:08:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bfeF-0002x2-00 for sipping@ietf.org; Sun, 13 Jul 2003 08:08:11 -0400 Received: from ns.ivd.nl ([193.67.37.226]) by ietf-mx with esmtp (Exim 4.12) id 19bfeE-0002wz-00 for sipping@ietf.org; Sun, 13 Jul 2003 08:08:10 -0400 Received: (from root@localhost) by ns.ivd.nl (8.9.3c/8.6.12) id OAA05661 for ; Sun, 13 Jul 2003 14:09:07 +0200 (CEST) Received: by ns.ivd.nl (TUNIX txp2/smap) for id sma005456; Sun, 13 Jul 03 14:07:52 +0200 Received: from IVD-Message_Server by mailserver.viataal.nl with Novell_GroupWise; Sun, 13 Jul 2003 14:09:08 +0200 Message-Id: X-Mailer: Novell GroupWise 5.5.5 Date: Sun, 13 Jul 2003 14:08:54 +0200 From: "A vWijk" To: , Cc: , , , , , , , , , , , , , , , , Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: [Sipping] Betr.: Re: SV: SV: items for vor voting in the BOF Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 Rohan and others, We know that the IETF can only advise the industry here. 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 <<< Rohan Mahy 12-07 23:12 >>> Gunnar, Both these issues will be discussed in an adhoc meeting or "bar-bof" in=20 Vienna. No date or place is scheduled because the IETF secretariat has=20 to pay by the hour this time for the rooms in the congress center. =20 (Normally they pay a flat rate for the exclusive use of certain rooms=20 for the entire week.) This will probably occur offsite. I believe that=20 Henry is still looking for a location. Assuming he comes up with=20 something suitable, I will announce the adhoc at the start of the=20 SIPPING meeting and post a note to the mailing list. Also, as I stated before, sipdev is an individual informational=20 document meant to provide guidance to the industry, but is not=20 specifically endorsed by the IETF or any WG. (IETF WGs generally do=20 not endorse implementation recommendations). It is not a formal=20 specification in the IETF sense. Also, the term BOF is used formally by=20 the IETF in a very specific way, which does not apply to this meeting. =20 The official term is "adhoc". hope this helps. thanks, -rohan On Friday, July 11, 2003, at 08:31 AM, Gunnar Hellstr=F6m wrote: > Rohan or anyone who knows: > > Do we have a fixed day and time for the following items in the coming=20 > IETF > meeting? > > 1. The discussion of the text and alerting additions in the SIPDEV > specification. > > 2. A BOF session on SIP text conversation. > > I will not come, but there is a slight possibility that Erik=20 > Zetterstr=F6m can > go there for these discussions. Erik has just done an RFC2793=20 > implementation > in JAVA, and is co-author of the draft BCP. > > Regards > > Gunnar > ------------------------------------------- > Gunnar Hellstr=F6m, Omnitor, Renathv=E4gen 2 > SE 121 37 Johanneshov, SWEDEN > Tel: +46 8 556 002 03 Mob: +46 708204288 > e-mail: gunnar.hellstrom@omnitor.se > web: www.omnitor.se > > >> -----Ursprungligt meddelande----- >> Fr=E5n: A vWijk [mailto:A.vWijk@viataal.nl] >> Skickat: den 11 juli 2003 10:52 >> Till: barry.dingle@bigfoot.com.au; hwildfeu@cisco.com; >> mgarakan@cisco.com; oran@cisco.com; rkumar@cisco.com; rohan@cisco.com; >> marcelo@envilogg.se; jorgen.bjorkner@hotsip.com; sipping@ietf.org; >> Henry.Sinnreich@mci.com; andreas.piirimets@omnitor.se; >> Erik.Zetterstrom@omnitor.se; gunnar.hellstrom@omnitor.se; >> paulej@packetizer.com; Guido.Gybels@rnid.org.uk; >> James.Hamlin@rnid.org.uk; mike.spanner@rnid.org.uk; gv@trace.wisc.edu; >> trefor@trefor.plus.com >> =C4mne: Re: SV: items for vor voting in the BOF >> >> >> Yes, >> we must take some time to see what exactly needs to be covered >> and what kind of behaviour we need. >> I wil make sure that the authors of the Invocation draft >> camarillo-deaf-01 will understand that the role is getting bigger=20 >> here. >> >> The role of the PSTN will be important and also the role of the >> gateways for backward compatibility to legacy TTY's. >> >> I will be at the IETF, so please feel free to grab me when you >> see me. I am the only deaf guy around there. So it should be easy. :-) >> >> greetz >> >> Arnoud >> >> <<< Gunnar Hellstr=F6m 7/11 12:14a >>> >> >> >> >> > > =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 Mon Jul 14 07:16: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 GAA05650 for ; Mon, 14 Jul 2003 06:28: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 19c0YK-0000mc-KD for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 06:27:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EARSWO002990 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 06:27:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0YJ-0000lm-PP for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 06:27: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 GAA05528 for ; Mon, 14 Jul 2003 06:27:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c0YD-0003qu-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 06:27:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c0YA-0003qZ-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 06:27:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0Xv-0000WS-Rj; Mon, 14 Jul 2003 06: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 19aVhE-00064n-5p for sipping@optimus.ietf.org; Thu, 10 Jul 2003 03:18: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 DAA20763 for ; Thu, 10 Jul 2003 03:18:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aVhB-00006K-00 for sipping@ietf.org; Thu, 10 Jul 2003 03:18:25 -0400 Received: from mail3.pi.se ([195.7.64.137]) by ietf-mx with esmtp (Exim 4.12) id 19aVhA-00006G-00 for sipping@ietf.org; Thu, 10 Jul 2003 03:18:24 -0400 Received: from VAIOMHP (1Cust23.tnt2.stk3.swe.da.uu.net [213.116.227.23]) (authenticated) by mail3.pi.se (8.11.2/8.11.2) with ESMTP id h6A7HER22757; Thu, 10 Jul 2003 09:17:14 +0200 (CEST) From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= To: "Paul E. Jones" , "Henry Sinnreich" , , , , , , "'Rajesh Kumar'" , , , "'James Hamlin'" , , , , , , , Date: Thu, 10 Jul 2003 09:16:58 +0200 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <027501c3463f$a7e71890$0401a8c0@packetizer.org> Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.pi.se id h6A7HER22757 Content-Transfer-Encoding: quoted-printable Subject: [Sipping] SV: items for vor voting in the BOF Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 Poul, We are seeking a form of document where we can collect the pieces that ar= e already well standardised for text in IP, but apparently a bit hard to fi= nd, so we have an apparent risk that developers keep inventing new, incompati= ble solutions for text while the IP voice telephony side converges. We cannot afford to let IP text conversation be as fragmented as it was i= n PSTN. It must be a proper telecom feature on the same status level as voi= ce and video if we are ever to get any accessibility in this world. And it m= ust be included in mainstream developments. The PSTN functions for text are good and important where they are ,but nothing of the functionality level that we would drag into the future as = any best common solution. That has been stated many times in the discussions here. Gateways are defined and in operation. It is exactly the right moment now to create a document that collects the views on IP text conversation. With that we can all contribute to make it widespread. Without it, there is a risk of continued fragmentation. We proposed BCP (Best Common Practise) merely because everything is alrea= dy standardised and it is not good to have the same standard in two document= s. A BCP can pick up and clarify and put emphasis on standards created in ot= her documents. Of course it shall take the traditional route to be an I-D fir= st. I am flexible on this. If there is enough new material in it, it can be proposed as an RFC. So, doing it now is the most important. Gunnar ------------------------------------------- Gunnar Hellstr=F6m, Omnitor, Renathv=E4gen 2 SE 121 37 Johanneshov, SWEDEN Tel: +46 8 556 002 03 Mob: +46 708204288 e-mail: gunnar.hellstrom@omnitor.se web: www.omnitor.se > -----Ursprungligt meddelande----- > Fr=E5n: Paul E. Jones [mailto:paulej@packetizer.com] > Skickat: den 9 juli 2003 19:30 > Till: Gunnar Hellstrom; Henry Sinnreich; Guido.Gybels@rnid.org.uk; > mike.spanner@rnid.org.uk; andreas.piirimets@omnitor.se; > gv@trace.wisc.edu; 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; > rohan@cisco.com; sipping@ietf.org > =C4mne: Re: items for vor voting in the BOF > > > Gunnar, > > Do you think it might be a bit premature to publish a BCP? After > all, it's > not widely used at this point, but it is expected to become much > more widely > used over the next few years. What is still not sorted out is > how this will > be married with the existing PSTN TTY equipment out there. There was s= ome > discussion of using specialized gateways for interworking, > putting RFC 2793 > on IP phones, doing pass-though on IP phones, etc. We still haven't ev= en > settled the issue of how text will even be entered into the average IP > phone. I recognize that it's a best "current" practice, but given the > amount of focus on this right now and the volatility, I think it might = be > better to just produce an I-D and re-publish that for a period of time = and > not rush to produce a BCP. > > Paul > > ----- Original Message ----- > From: "Gunnar Hellstrom" > To: "Henry Sinnreich" ; > ; > ; ; > ; ; "'Rajesh Kumar'" > ; ; = ; > "'James Hamlin'" ; > ; > ; ; > ; ; ; > ; > Sent: Sunday, July 06, 2003 4:45 PM > Subject: SV: items for vor voting in the BOF > > > > OK, looks fine. > > > > What about the external alerting connections? There was some good poi= nts > > that it can be arranged by logging in a SIP alerter with the same use= r > name > > in the sip server. That is a good design, that one can do a lot of sm= art > > things with. Evenso, the direct connection on the phone is simple and > > needed. > > > > > > Whatever the outcome of the voting, we also agreed that it would be g= ood > to > > have a BCP ( Best Current Practice ) on what SIP text > conversation is. The > > SDP for it, some good habits in design, what is need to support the > > transactions for invoking transcoding according to camarillo... > etc. Erik > > Zetterstrom and Andreas Piirimets made an initial draft. I > think they are > > prepared to issue a new, slightly improved. Barry Dingle had a good > > formulation promoting it. Has it progressed? I suggest that > these actions > > are handled jointly in the sipping meeting. > > > > Is anything like the sipdev activity going on for multimedia devices?= I > > would like to participate there and get text included there as well > together > > with video and voice. > > > > Regards > > > > Gunnar > > > > ------------------------------------------- > > Gunnar Hellstrom, Omnitor, Renathvagen 2 > > SE 121 37 Johanneshov, SWEDEN > > Tel: +46 8 556 002 03 Mob: +46 708204288 > > e-mail: gunnar.hellstrom@omnitor.se > > web: www.omnitor.se > > > > > > > -----Ursprungligt meddelande----- > > > Fran: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com] > > > Skickat: den 6 juli 2003 22:14 > > > Till: 'Gunnar Hellstrom'; Guido.Gybels@rnid.org.uk; > > > mike.spanner@rnid.org.uk; andreas.piirimets@omnitor.se; > > > gv@trace.wisc.edu; trefor@trefor.plus.com; 'Rajesh Kumar'; > > > marcelo@envilogg.se; jorgen.bjorkner@hotsip.com; 'James Hamlin'; > > > Erik.Zetterstrom@omnitor.se; hwildfeu@cisco.com; > paulej@packetizer.com; > > > barry.dingle@bigfoot.com.au; mgarakan@cisco.com; oran@cisco.com; > > > rohan@cisco.com; sipping@ietf.org > > > Amne: RE: items for vor voting in the BOF > > > > > > > > > Please see the attached slide for voting at the IETF BOF on > "Interactive > > > Text Support for SIP Telephony Devices". > > > > > > We have no day/time yet for the BOF, but expect to get it > scheduled, as > > > discussed with Rohan Mahy. > > > > > > Many thanks to Gunnar Hellstrom for the formulation of the text. > > > > > > Thanks, Henry > > > > > > > -----Original Message----- > > > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > > > > Sent: Wednesday, July 02, 2003 3:44 AM > > > > To: Henry Sinnreich > > > > Cc: trefor@trefor.plus.com; gv@trace.wisc.edu; > > > > mike.spanner@rnid.org.uk; Guido.Gybels@rnid.org.uk; > > > > Erik.Zetterstrom@omnitor.se; 'Rajesh Kumar'; 'James Hamlin'; > > > > andreas.piirimets@omnitor.se; jorgen.bjorkner@hotsip.com; > > > > marcelo@envilogg.se; rohan@cisco.com; oran@cisco.com; > > > > mgarakan@cisco.com; hwildfeu@cisco.com; > > > > barry.dingle@bigfoot.com.au; paulej@packetizer.com > > > > Subject: SV: items for vor voting in the BOF > > > > > > > > > > > > Henry, > > > > Yes please use the sentences in the IETF meeting, with no 3 > > > > amended as below. > > > > > > > > Some thoughts an explanations: > > > > > > > > Blind reference: > > > > ---------------- > > > > The reference about display interface for blind people refers > > > > to a need for blind people to follow hat is displayed on the > > > > phone through a device of their choice. It may be voice > > > > synthesis or electromechanical braille display or display > > > > with enlargement or extra strong light. We do not expect the > > > > phone to include these special devices, so a standardised > > > > interface to them must be provided. The SIP phone will have > > > > states so it will be impossible to expect that you shall be > > > > able to operate it without feedback from the phone. The > > > > mobile industry made the mistake to not initially provide a > > > > standardised interface to operate the mobile phone and that > > > > has caused enormous problems for blind people. The AT command > > > > interface available to 3GPP mobile phones seem to have > > > > overcome this mistake by including commands and responses for > > > > accessing most things required for operation through a serial > > > > command language that can be issued through Bluetooth or a > > > > USB or serial connector. Products are emerging. Something > > > > similar must be done on SIP phones. I concentrated on deaf > > > > issues, but I see that we have common interests here. > > > > > > > > The web interface: > > > > ------------------ > > > > I saw a comment that the web interface should not be > > > > mentioned as a solution. That may be true, it was with > > > > hesitation that I added it. But: I have seen SIP phones with > > > > the possibility to add the video component from a nearby > > > > computer. Similar things can be done for text. It is still > > > > valid to let the phone have all the other SIP phone > > > > functionality. I can imagine PDA access through Bluetooth > > > > executing a web browser to operate the phone. The text > > > > component could be accessible through that interface. > > > > Handling only the user interface aspect of the text part is > > > > an enormous difference from handling the complete SIP > > > > protocol and all audio coding. The sum is of course that when > > > > we open for many ways to add text and that the person > > > > carrying a text interface with him, will find that it can not > > > > be attached to any phone, and then accessibility is again > > > > limited. I am quite sure that phones will not come without > > > > display, and that they will follow the trend on PDAs and > > > > mobile phones, to include a full aphanumeric keyboard because > > > > it is needed for address and phonebook use, as well as to > > > > provide a good user interface to the very popular real time > > > > text conversation function ;-) . So, I am not too worried > > > > that we give many options. > > > > > > > > > > > > The analogue interface. > > > > ----------------------- > > > > The statement no 3 about the analogue adapter is not really > > > > formulated in a strict IETF style. A starting sentence is needed: > > > > > > > > 3. A SIP device MAY provide analogue adapter functionality > > > > through an RJ11 port. IF an RJ11 port is provided for a PSTN > > > > device adapter interface, THEN it MUST/SHOULD provide T.38 > > > > support for fax AND V.18+RFC2793 support for text alternating > > > > with voice. If T.38 or RFC2793 negotiation fails then it MAY > > > > try to connect for G.711 and pass the audio through. > > > > > > > > > > > > > > > > > > > > ------------------------------------------- > > > > Gunnar Hellstrom, Omnitor, Renathvagen 2 > > > > SE 121 37 Johanneshov, SWEDEN > > > > Tel: +46 8 556 002 03 Mob: +46 708204288 > > > > e-mail: gunnar.hellstrom@omnitor.se > > > > web: www.omnitor.se > > > > > > > > > > > > > -----Ursprungligt meddelande----- > > > > > Fran: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com] > > > > > Skickat: den 2 juli 2003 02:27 > > > > > Till: 'Gunnar Hellstrom' > > > > > Kopia: paulej@packetizer.com; barry.dingle@bigfoot.com.au; > > > > > hwildfeu@cisco.com; mgarakan@cisco.com; oran@cisco.com; > > > > > rohan@cisco.com; marcelo@envilogg.se; jorgen.bjorkner@hotsip.co= m; > > > > > Henry.Sinnreich@mci.com; andreas.piirimets@omnitor.se; > > > > 'James Hamlin'; > > > > > 'Rajesh Kumar'; Erik.Zetterstrom@omnitor.se; > > > > Guido.Gybels@rnid.org.uk; > > > > > mike.spanner@rnid.org.uk; gv@trace.wisc.edu; > trefor@trefor.plus.com > > > > > Amne: items for vor voting in the BOF > > > > > > > > > > > > > > > Gunnar, > > > > > > > > > > I will use with your permission your formulation to put > these three > > > > > items to vote in the BOF, for MUST or SHOULD: > > > > > > > > > > 1. MUST/SHOULD include protocol support for RFC2793 for text. > > > > > > > > > > 2. MUST/SHOULD provide a way to input text and display > > > > text, through > > > > > any > > > > > method: Built in user interfaces, standard wired or > > > > wireless interfaces > > > > > for keyboard and display ( that is needed anyway for blind > > > > people), or > > > > > support for text through its already mandated web interface. > > > > > > > > > > ---- > > > > > And, with some doubt: > > > > > > > > > > 3. IF an RJ11 port is provided for a PSTN device adapter > interface, > > > > > THEN it MUST/SHOULD provide T.38 support for fax AND V.18+RFC27= 93 > > > > > support for text alternating with voice. If T.38 or RFC2793 > > > > > negotiation fails then it MAY try to connect for G.711 > and pass the > > > > > audio through.( is there any need to mandate also modem support= ? ) > > > > > > > > > > I believe these are very reasonable requirements. > > > > > > > > > > Thanks, Henry > > > > > > > > > > > -----Original Message----- > > > > > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > > > > > > Sent: Tuesday, July 01, 2003 4:08 PM > > > > > > To: Rajesh Kumar; James Hamlin > > > > > > Cc: paulej@packetizer.com; barry.dingle@bigfoot.com.au; > > > > > > hwildfeu@cisco.com; mgarakan@cisco.com; oran@cisco.com; > > > > > > rohan@cisco.com; marcelo@envilogg.se; > jorgen.bjorkner@hotsip.com; > > > > > > Henry.Sinnreich@mci.com; andreas.piirimets@omnitor.se; > > > > > > Erik.Zetterstrom@omnitor.se; Guido.Gybels@rnid.org.uk; > > > > > > mike.spanner@rnid.org.uk; gv@trace.wisc.edu; > > > > trefor@trefor.plus.com > > > > > > Subject: SV: SV: SV: Internet draft on real time text > conversation > > > > > > > > > > > > > > > > > > I see the discussion going in circles. > > > > > > > > > > > > Henry gave me the delicate task to sum up and get a > > > > proposed writing > > > > > > into the Sipdev specification. > > > > > > > > > > > > After looking back in the discussion, I come to the > > > > conclusion that, > > > > > > the only requirements that make real sense and takes deaf > > > > telecomms > > > > > > a bit towards equal opportunities is that SIP devices: > > > > > > > > > > > > 1. MUST include protocol support for RFC2793 for text. > > > > > > > > > > > > 2. MUST provide a way to input text and display text, > through any > > > > > > method: Built in user interfaces, standard wired or wireless > > > > > > interfaces for keyboard and display ( that is needed anyway f= or > > > > > > blind people), or support for text through its already > > > > mandated web > > > > > > interface. > > > > > > > > > > > > ---- > > > > > > And, with some doubt: > > > > > > > > > > > > 3. IF an RJ11 port is provided for a PSTN device adapter > > > > interface, > > > > > > THEN it MUST provide T.38 support for fax AND > > > > V.18+RFC2793 support > > > > > > for text alternating with voice. If T.38 or RFC2793 negotiati= on > > > > > > fails then it MAY try to connect for G.711 and pass the audio > > > > > > through.( is there any need to mandate also modem support? ) > > > > > > > > > > > > > > > > > > > > > > > > ---- > > > > > > I am sure SIP signaling can take care of most tricky > > > > situations that > > > > > > have been up for discussion. > > > > > > > > > > > > E.g. > > > > > > A SIP phone without RJ11 port in contact with a PSTN > > > > device through > > > > > > a gateway, would signal RFC2793 capability. That will > > > > make a gateway > > > > > > involved in the call perceive any indication on use of > modem-like > > > > > > tones from PSTN as text if possible. > > > > > > > > > > > > > > > > > > > > > > > > I intend to propose text with that content soon for the > > > > sipdev spec. > > > > > > > > > > > > With that, we could perhaps change topic to discuss > > > > contents of the > > > > > > text capable device I-D that Erik and Andreas made a > > > > first draft of. > > > > > > > > > > > > Has time been booked in the SIPPING meeting in Wienna to disc= uss > > > > > > that? > > > > > > > > > > > > Can Erik and Andreas provide us with a second draft? > > > > > > > > > > > > Best regards > > > > > > > > > > > > Gunnar > > > > > > > > > > > > > > > > > > ------------------------------------------- > > > > > > Gunnar Hellstrom, Omnitor, Renathvagen 2 > > > > > > SE 121 37 Johanneshov, SWEDEN > > > > > > Tel: +46 8 556 002 03 Mob: +46 708204288 > > > > > > e-mail: gunnar.hellstrom@omnitor.se > > > > > > web: www.omnitor.se > > > > > > > > > > > > > > > > > > > -----Ursprungligt meddelande----- > > > > > > > Fran: Rajesh Kumar [mailto:rkumar@cisco.com] > > > > > > > Skickat: den 1 juli 2003 19:15 > > > > > > > Till: James Hamlin > > > > > > > Kopia: paulej@packetizer.com; barry.dingle@bigfoot.com.au; > > > > > > > hwildfeu@cisco.com; mgarakan@cisco.com; oran@cisco.com; > > > > > > > rohan@cisco.com; marcelo@envilogg.se; > > > > jorgen.bjorkner@hotsip.com; > > > > > > > Henry.Sinnreich@mci.com; andreas.piirimets@omnitor.se; > > > > > > > Erik.Zetterstrom@omnitor.se; gunnar.hellstrom@omnitor.se; > > > > > > > Guido.Gybels@rnid.org.uk; mike.spanner@rnid.org.uk; > > > > > > gv@trace.wisc.edu; > > > > > > > trefor@trefor.plus.com > > > > > > > Amne: RE: SV: SV: Internet draft on real time text > conversation > > > > > > > > > > > > > > > > > > > > > James, > > > > > > > > > > > > > > The intent here is that the called party could be any SIP > > > > > > phone, not > > > > > > > just SIP phones specially designated for text-only > > > > > > operation. I think > > > > > > > the intent expressed by Guido and Gunnar et al is that a > > > > > > PSTN TTY user > > > > > > > should be able > > > > > > > to open an RFC 2793 text channel with any SIP phone user, > > > > > > and that the > > > > > > > latter should either have an integral keyboard/display > > > > or a port > > > > > > > to such a display. So the problem of call > > > > discrimination when the > > > > > > > caller is a V.21 or > > > > > > > V.23 legacy textphone is not solved unless you allow > > > > > > passthrough fallback > > > > > > > when you cannot tell whether the V.21 signal is text or not= - > > > > > > > regardless of the existence of gateways/servers that do PST= N > > > > > > > textphone to RFC 2793 conversion. > > > > > > > > > > > > > > In general, the solution of designating special phone > > > > numbers for > > > > > > > deaf-accessible operation militates against the stipulation > > > > > > that the > > > > > > > deaf be able to create text channels from any PSTN or > SIP phone > > > > > > > number, and to any PSTN or SIP phone number. Here, textpho= ne > > > > > > > detection has to be on the basis of control signals > > > > > > exchanged in the > > > > > > > bearer stream or on the content of the bearer stream, > > > > and not on a > > > > > > > priori numbering plans that create a "deaf ghetto". > > > > > > > > > > > > > > For technical reasons, I still think you must mandate > > > > passthrough > > > > > > > operation to enable universal interoperability. > > > > > > > > > > > > > > Kind regards to all. > > > > > > > > > > > > > > Rajesh > > > > > > > > > > > > > > > > > > > > > > > > > > > > At 04:33 PM 7/1/2003 +0100, James Hamlin wrote: > > > > > > > >Rajesh > > > > > > > > > > > > > > > >It would be possible for people on the IP network to > have PSTN > > > > > > > numbers that > > > > > > > >are taken from a block that is assigned only to text. > > > > Therefore > > > > > > > the gateway > > > > > > > >between PSTN and the IP network knows from the called numb= er > > > > > > > that the intent > > > > > > > >is to use text. > > > > > > > > > > > > > > > >Regards > > > > > > > > > > > > > > > >James > > > > > > > > > > > > > > > >-----Original Message----- > > > > > > > >From: Rajesh Kumar [mailto:rkumar@cisco.com] > > > > > > > >Sent: 01 July 2003 16:05 > > > > > > > >To: A vWijk > > > > > > > >Cc: paulej@packetizer.com; barry.dingle@bigfoot.com.au; > > > > > > > >hwildfeu@cisco.com; mgarakan@cisco.com; oran@cisco.com; > > > > > > > >rohan@cisco.com; marcelo@envilogg.se; > > > > jorgen.bjorkner@hotsip.com; > > > > > > > >Henry.Sinnreich@mci.com; andreas.piirimets@omnitor.se; > > > > > > > >Erik.Zetterstrom@omnitor.se; gunnar.hellstrom@omnitor.se; > > > > > > > >Guido.Gybels@rnid.org.uk; james.hamlin@rnid.org.uk; > > > > > > > >mike.spanner@rnid.org.uk; gv@trace.wisc.edu; > > > > > > > >trefor@trefor.plus.com > > > > > > > >Subject: Re: SV: SV: Internet draft on real time text > > > > conversation > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> "rkumar@cisco.com" 07/01/03 16:04 >>> > > > > > > > > > > > > > > > >Arnoud, > > > > > > > > > > > > > > > >As I indicated in another email, interoperability with leg= acy > > > > > > > V.21 and V.23T > > > > > > > > TY devices is not feasible unless you support a passthro= ugh > > > > > > > >fallback. I have no hidden agenda here, I am just > presenting a > > > > > > > >technical difficulty that SG16/Q11 and TIA TR.30.1 have be= en > > > > > > > >struggling with for the past 6 months. I do not know how > > > > > > you can do > > > > > > > >without TTY passthrough if you want universal > > > > > > interoperability. Here > > > > > > > >was my mail, sent yesterday: > > > > > > > > > > > > > > > >There is a real technical difficulty which I would > want you all > > > > > > > to consider. > > > > > > > > > > > > > > > >Let us say that you mandate T.140/RFC 2793 for all SIP > > > > > > phones and do > > > > > > > >not mandate TTY passthrough. > > > > > > > > > > > > > > > >Let us say the call originates from a PSTN TTY and is > > > > routed via > > > > > > > a gatewayt > > > > > > > > o a SIP phone, which has native RFRC2793-based text > > > > > > > > capabilities. > > > > > > > > > > > > > > > >SG16/Q11 has struggled with the fact that you cannot alway= s > > > > > > > discriminate aT > > > > > > > > TY call from a non-TTY call when V.21 or V.23 > > > > > > modulations are used. > > > > > > > >In this case, there is no basis for the gateway to > convert the > > > > > > > >PSTN > > > > > > > TTY signali > > > > > > > > nto RFC 2793/T.140. However, the gateway can determine > > > > > > that this is > > > > > > > >a modulated signal based on answer tone (if present) or on > > > > > > specific > > > > > > > >FSK frequencies. It can use VBD passthrough (G.711) in > > > > > > this case but > > > > > > > >not RFC 2793 since it does not know if the V.21/V.23 > > > > > > signal is text > > > > > > > >or not. > > > > > > > > > > > > > > > >Ergo, we cannot preclude a requirement for G.711 VBD > > > > passthrough > > > > > > > support onS > > > > > > > > IP phones in favor of T.140. You can mandate both as mus= ts, > > > > > > > but you cannoth > > > > > > > > ave an interoperable solution if you do not have > passthrough. > > > > > > > > > > > > > > > >Rajesh > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >At 04:02 PM 7/1/2003 +0200, A vWijk wrote: > > > > > > > > >Paul, > > > > > > > > >How do you feel by mandating T.140/RTP along with the TT= Y > > > > > > > passthrough on> > > > > > > > > IP telephones and such? > > > > > > > > >The technology is then ready for the T.140 usage. > > > > Which may be > > > > > > > very very> > > > > > > > > rapidly! > > > > > > > > >And remember..as I am stating over and over again. > RFC2793 is > > > > > > > NOT limited> > > > > > > > > for the hearing impaired users only! > > > > > > > > >Many other services will be possible with text > conversation. > > > > > > > > >And that will likely stimulate the acceptance of T.140 t= oo. > > > > > > > > > > > > > > > > > >And if we explain the goal of T.140 and the possibilitie= s. > > > > > > > Then I do not> > > > > > > > > see any problems for the governments to subsidize this > > > > > > > development and buy> > > > > > > > > IP telephones for the hearing impaired. > > > > > > > > >Ofcourse, we have to guarantee the legacy TTY > > > > support. But also > > > > > > > > >that it has to be phased out. > > > > > > > > > > > > > > > > > >Please do not lock out T.140 by mandating TTY voice > > > > > > > fallback/passthrough> > > > > > > > > for IP telephones and clients/servers etc. > > > > > > > > > > > > > > > > > >greetz > > > > > > > > > > > > > > > > > >Arnoud van Wijk > > > > > > > > > > > > > > > > > ><<< "Paul E. Jones" 7/ 1 > 5:47a >>> > > > > > > > > >Rajesh, > > > > > > > > > > > > > > > > > >I agree with your concerns. Also, I think the case is e= ven > > > > > > > stronger for > > > > > > > > >other countries where such issues are as thoughtfully > > > > > > > considered. I really > > > > > > > > >doubt that we'll see any requirements in many countries. > > > > > > > > > > > > > > > > > >Another factor is cost. It might be a small > > > > per-unit cost to > > > > > > > > >include necessary support, but even if it is $10, > > > > $10 times the > > > > > > > > >number > > > > > > > of devices a > > > > > > > > >large, mass manufacturing company will produce in a > > > > > > > > >highly-competitive, low-margin environment becomes a > > > > > > major issue. > > > > > > > > >Thus, there will be a push-back from the extremely > > > > high-volume > > > > > > > > >manufacturers, I think. > > > > > > > > > > > > > > > > > >Considering all things, what I think the best roadmap is= : > > > > > > > > > 1) Create devices that are dual TTY/T.140 devices > > > > that work > > > > > > > on PSTN or > > > > > > > >IP > > > > > > > > > 2) Make sure every IP phone, residential > gateway / analog > > > > > > > > >terminal adapter, etc. > > > > > > > > > can properly carry TTY signals, modem signals, > > > > > > fax, etc. and that > > > > > > > > > a standard TTY device can interface with said devi= ce > > > > > > > > > > > > > > > > > >Over time, we may see increased support for T.140 > > > > > > natively on every > > > > > > > > >IP phone. But, I really suspect that for a long > > > > time to come, > > > > > > > (2) is going to > > > > > > > > >be extremely important. Even so, with (1) in existence, > > > > > > it means > > > > > > > > >that people can start to take advantage of T.140 as > > > > soon as the > > > > > > > devices are put > > > > > > > > >into their hands... and so the transition begins. > > > > > > > > > > > > > > > > > >Paul > > > > > > > > > > > > > > > > > >----- Original Message ----- > > > > > > > > >From: "Rajesh Kumar" > > > > > > > > >To: "A vWijk" > > > > > > > > >Cc: ; ; > > > > > > > > >; ; > > > > > > > ; > > > > > > > > >; ; ; > > > > > > > > >; > > > > ; > > > > > > > > >; > > > > ; > > > > > > > > >; ; > > > > > > > > >; ; > > > > > > > > > > > > > > > >Sent: Monday, June 30, 2003 11:21 PM > > > > > > > > >Subject: Re: SV: SV: Internet draft on real time text > > > > > > conversation > > > > > > > > > > > > > > > > > > > > > > > > > > > > Dr. van Wijk, > > > > > > > > > > > > > > > > > > > > While I support your sentiments, are you sure that > > > > > > > governments all over > > > > > > > > >the > > > > > > > > > > world will provide these mobile text phones to the > > > > > > > hard-of-hearing on a > > > > > > > > > > subsidized basis? Also, the monthly plans that > go with it? > > > > > > > > > > > > > > > > > > > > While I do not know about other countries, I seriousl= y > > > > > > > doubt that the US > > > > > > > > > > will do such a thing in the near future. I think the = US > > > > > > > deaf community > > > > > > > >is > > > > > > > > > > stuck with Baudot devices for a long time, > unless they can > > > > > > > afford PCs on > > > > > > > > > > their own budget.Probably a USB interface on > the SIP phone > > > > > > > to a cheap > > > > > > > > > > device is probably the best shot at universal > > > > > > > accessibility. Even so, I > > > > > > > > > > doubt if the US government will subsidize the SIP > > > > > > phone + keypad > > > > > > > > > > + > > > > > > > >screen > > > > > > > > > > combo, even it is cheaper that the Baudot TTY. This > > > > > > is because > > > > > > > > > > this > > > > > > > >would > > > > > > > > > > entail a mass replacement for thousands of > > > > existing Baudot > > > > > > > > > > devices. > > > > > > > > > > > > > > > > > > > > I might be wrong - I hope I am. > > > > > > > > > > > > > > > > > > > > Rajesh > > > > > > > > > > > > > > > > > > > > At 12:33 PM 6/26/2003 +0200, A vWijk wrote: > > > > > > > > > > >Paul, > > > > > > > > > > >I am also looking at a larger scale. > > > > > > > > > > >Imagine that 3 companies > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >****************************************************************= *** > > > > > > >** > > > > > > > >*** > > > > > > > >This email and any files transmitted with it are > > > > confidential and > > > > > > > >intended solely for the use of the individual or > > > > entity to whom > > > > > > > >they are addressed. Any views or opinions expressed > are solely > > > > > > > >those of the author and do not necessarily represent > > > > RNID policy. > > > > > > > > > > > > > > > >If you are not the intended recipient you are advised that > > > > > > any use, > > > > > > > >dissemination, forwarding, printing or copying of this > > > > email is > > > > > > > >strictly prohibited. > > > > > > > > > > > > > > > >If you have received this email in error please notify > > > > the RNID > > > > > > > >Helpdesk by telephone on: +44 (0) 207 296 8282. > > > > > > > > > > > > > > > >The Royal National Institute for Deaf People > > > > > > > >Registered Office 19-23 Featherstone Street > > > > > > > >London EC1Y 8SL No. 454169 (England) > > > > > > > >Registered Charity No. 207720 > > > > > > > > > > > > > > > > > >****************************************************************= *** > > > > > > >** > > > > > > > >*** > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 14 07:16: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 GAA05796 for ; Mon, 14 Jul 2003 06:28: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 19c0Yf-0001S6-EP for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 06:27:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EARnur005574 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 06:27:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0Yf-0001Ra-6Y for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 06:27: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 GAA05587 for ; Mon, 14 Jul 2003 06:27:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c0Ya-0003sZ-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 06:27:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c0YK-0003qm-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 06:27:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0Xw-0000Wr-NF; Mon, 14 Jul 2003 06:27:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19afj6-00089i-H4 for sipping@optimus.ietf.org; Thu, 10 Jul 2003 14:01: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 OAA14620 for ; Thu, 10 Jul 2003 14:00:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19afj4-0005kG-00 for sipping@ietf.org; Thu, 10 Jul 2003 14:01:02 -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 19afj2-0005kC-00 for sipping@ietf.org; Thu, 10 Jul 2003 14:01:00 -0400 Received: from berlin (berlin.packetizer.org [192.168.1.4]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id h6AHxpMd005150; Thu, 10 Jul 2003 13:59:52 -0400 Message-ID: <00ba01c3470d$121d8fa0$0401a8c0@packetizer.org> From: "Paul E. Jones" To: "Gunnar Hellström" , "Henry Sinnreich" , , , , , , "'Rajesh Kumar'" , , , "'James Hamlin'" , , , , , , , References: Date: Thu, 10 Jul 2003 13:59:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 Subject: [Sipping] Re: items for vor voting in the BOF Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 Gunnar, > Please do not complicate this. I made a simple summary of the discussion > that gave the meeting a simple set of choices. Now it is at risk to deviate > again. I am certainly not trying to complicate matters. I really thought that point #3 was quite confusing as it was written and I merely tried to break it apart into a few choices. Each one may be independently accepted or rejected. > We have to keep this clear and simple, and not give the impression to the > industry that this is a big complication so that the whole package of > accessibility issues is thrown out. Agreed... but things are not necessarily always simple. > Please stick to the origingal for the voting and proposals in the IETF > meeting. > I comment the proposals inline. I don't like the original voting proposal... especially the comment about the blind, web interface, and #3 entirely. You want to reduce complexity, but I think 3 is complex as it is now. > > I made a number of comments on the previous proposal. Specifically, I did > > not want to see #3 as it was written. T.38 AND V.18 are entirely > > separate. > > Gunnar> They both rely on the complication to include analogue phone > connector and modem technology. They are both FSK modems in the base. I > agree that the logic on top of that is different, but the complexity of T.38 > is at least 10 times more than V.18 plus T.140 and RFC2793. Not necessarily. If we go with the 2.5mm jack, for example, that would suggest we support phones with input for TTY, so we'd consider V.18 in the senario, but not T.38. It just depends on what we want as baseline requirements. > > Further, if we allow for VBD operation for TTY devices connected via RJ11, > > then V.18 would not be something the phone needs to be complicated with. > > Gunnar> No, that is not right. VBD just takes the tones as they are and > transport them to the other end. What shall we do with these tones if they > are sent to a proper SIP textphone? You need to adapt to the habit in the > network you are, and create compatibility, not offer fragmentation. You continue to assume that every single IP phone will have text support. While I'm fully supportive of the goal, I just have doubts that it will be the reality. As I've argued before, there will be many low-margin IP phone manufacturers who would do no more than put an audio input on the phone (either 2.5mm or RJ-11) and interface with legacy TTY devices. The biggest hurdle with adding native text support is the user interface. This can become complicated by the fact that the UA may be some distance from the user. For example, an "IP phone" might include devices like "residential gateways" with one or two ports on them. They might normally be used to connect regular phones, not IP phones, and have no V.18 support in them. You might not call them IP phones, but we do have to worry with how they all interwork. Speaking strictly of IP phones, I just can't imagine that every manufacturer of every low-margin IP phone is going to properly support a text interface. This really concerns me, as *if* such a class of devices are produced, then we have a huge gap, with what you call "proper" SIP text phones on one side unable to work with a large class of "improper" SIP text phones. Thus, I contend that we need to take this in steps. We need to encourage the move to text, but not leave legacy TTY devices out in the cold entirely. > > 3. MUST/SHOULD provide an interface to legacy TTY devices and transport > > those signals as RFC 2793 text > > Gunnar> We should not use the term TTY. That is a local American term, not > understood elsewhere. Text telephone is the agreed term. The name makes no difference to me. > > 4. MUST/SHOULD provide an interface to legacy TTY devices and allow > > transparent carriage of the TTY protocol through the audio path > > ("pass-through" mode) > > Gunnar> Same comment about TTY Ditto. > > 5. MUST/SHOULD provide an RJ11 port for interfacing with legacy > > TTY devices, > > fax devices, modems, and other legacy equipment for the purposes of > > supporting the transfer of information from/to those legacy devices. > > > > 6. MUST/SHOULD provide a 2.5mm audio plug for interfacing with a > > headset or > > legacy TTY device > > > > Note that #5 gets into the area of V.150 modem relay and pass-through, as > > well as T.38 fax relay. That came from the original #3. > > However, I do not > > see the value in spelling out those protocols for the purposes of > > this vote. > > > > Also, in #2, there is still a reference to a web interface. I > > said I don't > > think that's necessary, since if one can access the web interface, he/she > > can probably just use a PC for communication. However, they may not be > > true. In any case, I can see the web interface as "interesting", but > > certainly could not see mandating it. Also, I don't agree with > > the comment > > about blind people needing a keyboard and screen. > > Gunnar> The comment was that blind people need a way to get an electronic > interface to the input and output for operations of the phone. > They probably need to get the user interface device themselves, but need the > standardised interface on the phone. The same interface should be possible > to use for text input and display. > I agree that the comment does not need to be there in the text, it was meant > to be for clarification in the discussion, but apparently was not clear > enough. So can we agree to remove it? There are a large number of issues we need to consider for the blind users and may result in subsequent revisions of this document going forward. Paul > > I propose > > rewording #2 as > > follows: > > > > 2. MUST/SHOULD provide a way to input text and display text, through any > > method: Built in user interfaces, standard wired or wireless interfaces > > for > > keyboard and display, or support for text through its web interface. > > > > OR, better: > > > > 2A. MUST/SHOULD provide a way to input text and display text > > through either > > a > > built in user interfaces or standard wired or wireless interfaces > > (including a screen and keyboard) > > > > 2B. MUST/SHOULD provide a way to input text and display text through its > > web interface. > > > > Paul > > > > ----- Original Message ----- > > From: "Henry Sinnreich" > > To: "'Gunnar Hellstrom'" ; > > ; ; > > ; ; > > ; "'Rajesh Kumar'" ; > > ; ; "'James Hamlin'" > > ; ; > > ; ; > > ; ; ; > > ; > > Sent: Sunday, July 06, 2003 4:14 PM > > Subject: RE: items for vor voting in the BOF > > > > > > > Please see the attached slide for voting at the IETF BOF on "Interactive > > > Text Support for SIP Telephony Devices". > > > > > > We have no day/time yet for the BOF, but expect to get it scheduled, as > > > discussed with Rohan Mahy. > > > > > > Many thanks to Gunnar Hellstrom for the formulation of the text. > > > > > > Thanks, Henry > > > > > > > -----Original Message----- > > > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > > > > Sent: Wednesday, July 02, 2003 3:44 AM > > > > To: Henry Sinnreich > > > > Cc: trefor@trefor.plus.com; gv@trace.wisc.edu; > > > > mike.spanner@rnid.org.uk; Guido.Gybels@rnid.org.uk; > > > > Erik.Zetterstrom@omnitor.se; 'Rajesh Kumar'; 'James Hamlin'; > > > > andreas.piirimets@omnitor.se; jorgen.bjorkner@hotsip.com; > > > > marcelo@envilogg.se; rohan@cisco.com; oran@cisco.com; > > > > mgarakan@cisco.com; hwildfeu@cisco.com; > > > > barry.dingle@bigfoot.com.au; paulej@packetizer.com > > > > Subject: SV: items for vor voting in the BOF > > > > > > > > > > > > Henry, > > > > Yes please use the sentences in the IETF meeting, with no 3 > > > > amended as below. > > > > > > > > Some thoughts an explanations: > > > > > > > > Blind reference: > > > > ---------------- > > > > The reference about display interface for blind people refers > > > > to a need for blind people to follow hat is displayed on the > > > > phone through a device of their choice. It may be voice > > > > synthesis or electromechanical braille display or display > > > > with enlargement or extra strong light. We do not expect the > > > > phone to include these special devices, so a standardised > > > > interface to them must be provided. The SIP phone will have > > > > states so it will be impossible to expect that you shall be > > > > able to operate it without feedback from the phone. The > > > > mobile industry made the mistake to not initially provide a > > > > standardised interface to operate the mobile phone and that > > > > has caused enormous problems for blind people. The AT command > > > > interface available to 3GPP mobile phones seem to have > > > > overcome this mistake by including commands and responses for > > > > accessing most things required for operation through a serial > > > > command language that can be issued through Bluetooth or a > > > > USB or serial connector. Products are emerging. Something > > > > similar must be done on SIP phones. I concentrated on deaf > > > > issues, but I see that we have common interests here. > > > > > > > > The web interface: > > > > ------------------ > > > > I saw a comment that the web interface should not be > > > > mentioned as a solution. That may be true, it was with > > > > hesitation that I added it. But: I have seen SIP phones with > > > > the possibility to add the video component from a nearby > > > > computer. Similar things can be done for text. It is still > > > > valid to let the phone have all the other SIP phone > > > > functionality. I can imagine PDA access through Bluetooth > > > > executing a web browser to operate the phone. The text > > > > component could be accessible through that interface. > > > > Handling only the user interface aspect of the text part is > > > > an enormous difference from handling the complete SIP > > > > protocol and all audio coding. The sum is of course that when > > > > we open for many ways to add text and that the person > > > > carrying a text interface with him, will find that it can not > > > > be attached to any phone, and then accessibility is again > > > > limited. I am quite sure that phones will not come without > > > > display, and that they will follow the trend on PDAs and > > > > mobile phones, to include a full aphanumeric keyboard because > > > > it is needed for address and phonebook use, as well as to > > > > provide a good user interface to the very popular real time > > > > text conversation function ;-) . So, I am not too worried > > > > that we give many options. > > > > > > > > > > > > The analogue interface. > > > > ----------------------- > > > > The statement no 3 about the analogue adapter is not really > > > > formulated in a strict IETF style. A starting sentence is needed: > > > > > > > > 3. A SIP device MAY provide analogue adapter functionality > > > > through an RJ11 port. IF an RJ11 port is provided for a PSTN > > > > device adapter interface, THEN it MUST/SHOULD provide T.38 > > > > support for fax AND V.18+RFC2793 support for text alternating > > > > with voice. If T.38 or RFC2793 negotiation fails then it MAY > > > > try to connect for G.711 and pass the audio through. > > > > > > > > > > > > > > > > > > > > ------------------------------------------- > > > > Gunnar Hellstrom, Omnitor, Renathvagen 2 > > > > SE 121 37 Johanneshov, SWEDEN > > > > Tel: +46 8 556 002 03 Mob: +46 708204288 > > > > e-mail: gunnar.hellstrom@omnitor.se > > > > web: www.omnitor.se > > > > > > > > > > > > > -----Ursprungligt meddelande----- > > > > > Fran: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com] > > > > > Skickat: den 2 juli 2003 02:27 > > > > > Till: 'Gunnar Hellstrom' > > > > > Kopia: paulej@packetizer.com; barry.dingle@bigfoot.com.au; > > > > > hwildfeu@cisco.com; mgarakan@cisco.com; oran@cisco.com; > > > > > rohan@cisco.com; marcelo@envilogg.se; jorgen.bjorkner@hotsip.com; > > > > > Henry.Sinnreich@mci.com; andreas.piirimets@omnitor.se; > > > > 'James Hamlin'; > > > > > 'Rajesh Kumar'; Erik.Zetterstrom@omnitor.se; > > > > Guido.Gybels@rnid.org.uk; > > > > > mike.spanner@rnid.org.uk; gv@trace.wisc.edu; trefor@trefor.plus.com > > > > > Amne: items for vor voting in the BOF > > > > > > > > > > > > > > > Gunnar, > > > > > > > > > > I will use with your permission your formulation to put these three > > > > > items to vote in the BOF, for MUST or SHOULD: > > > > > > > > > > 1. MUST/SHOULD include protocol support for RFC2793 for text. > > > > > > > > > > 2. MUST/SHOULD provide a way to input text and display > > > > text, through > > > > > any > > > > > method: Built in user interfaces, standard wired or > > > > wireless interfaces > > > > > for keyboard and display ( that is needed anyway for blind > > > > people), or > > > > > support for text through its already mandated web interface. > > > > > > > > > > ---- > > > > > And, with some doubt: > > > > > > > > > > 3. IF an RJ11 port is provided for a PSTN device adapter interface, > > > > > THEN it MUST/SHOULD provide T.38 support for fax AND V.18+RFC2793 > > > > > support for text alternating with voice. If T.38 or RFC2793 > > > > > negotiation fails then it MAY try to connect for G.711 and pass the > > > > > audio through.( is there any need to mandate also modem support? ) > > > > > > > > > > I believe these are very reasonable requirements. > > > > > > > > > > Thanks, Henry > > > > > > > > > > > -----Original Message----- > > > > > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > > > > > > Sent: Tuesday, July 01, 2003 4:08 PM > > > > > > To: Rajesh Kumar; James Hamlin > > > > > > Cc: paulej@packetizer.com; barry.dingle@bigfoot.com.au; > > > > > > hwildfeu@cisco.com; mgarakan@cisco.com; oran@cisco.com; > > > > > > rohan@cisco.com; marcelo@envilogg.se; jorgen.bjorkner@hotsip.com; > > > > > > Henry.Sinnreich@mci.com; andreas.piirimets@omnitor.se; > > > > > > Erik.Zetterstrom@omnitor.se; Guido.Gybels@rnid.org.uk; > > > > > > mike.spanner@rnid.org.uk; gv@trace.wisc.edu; > > > > trefor@trefor.plus.com > > > > > > Subject: SV: SV: SV: Internet draft on real time text conversation > > > > > > > > > > > > > > > > > > I see the discussion going in circles. > > > > > > > > > > > > Henry gave me the delicate task to sum up and get a > > > > proposed writing > > > > > > into the Sipdev specification. > > > > > > > > > > > > After looking back in the discussion, I come to the > > > > conclusion that, > > > > > > the only requirements that make real sense and takes deaf > > > > telecomms > > > > > > a bit towards equal opportunities is that SIP devices: > > > > > > > > > > > > 1. MUST include protocol support for RFC2793 for text. > > > > > > > > > > > > 2. MUST provide a way to input text and display text, through any > > > > > > method: Built in user interfaces, standard wired or wireless > > > > > > interfaces for keyboard and display ( that is needed anyway for > > > > > > blind people), or support for text through its already > > > > mandated web > > > > > > interface. > > > > > > > > > > > > ---- > > > > > > And, with some doubt: > > > > > > > > > > > > 3. IF an RJ11 port is provided for a PSTN device adapter > > > > interface, > > > > > > THEN it MUST provide T.38 support for fax AND > > > > V.18+RFC2793 support > > > > > > for text alternating with voice. If T.38 or RFC2793 negotiation > > > > > > fails then it MAY try to connect for G.711 and pass the audio > > > > > > through.( is there any need to mandate also modem support? ) > > > > > > > > > > > > > > > > > > > > > > > > ---- > > > > > > I am sure SIP signaling can take care of most tricky > > > > situations that > > > > > > have been up for discussion. > > > > > > > > > > > > E.g. > > > > > > A SIP phone without RJ11 port in contact with a PSTN > > > > device through > > > > > > a gateway, would signal RFC2793 capability. That will > > > > make a gateway > > > > > > involved in the call perceive any indication on use of modem-like > > > > > > tones from PSTN as text if possible. > > > > > > > > > > > > > > > > > > > > > > > > I intend to propose text with that content soon for the > > > > sipdev spec. > > > > > > > > > > > > With that, we could perhaps change topic to discuss > > > > contents of the > > > > > > text capable device I-D that Erik and Andreas made a > > > > first draft of. > > > > > > > > > > > > Has time been booked in the SIPPING meeting in Wienna to discuss > > > > > > that? > > > > > > > > > > > > Can Erik and Andreas provide us with a second draft? > > > > > > > > > > > > Best regards > > > > > > > > > > > > Gunnar > > > > > > > > > > > > > > > > > > ------------------------------------------- > > > > > > Gunnar Hellstrom, Omnitor, Renathvagen 2 > > > > > > SE 121 37 Johanneshov, SWEDEN > > > > > > Tel: +46 8 556 002 03 Mob: +46 708204288 > > > > > > e-mail: gunnar.hellstrom@omnitor.se > > > > > > web: www.omnitor.se > > > > > > > > > > > > > > > > > > > -----Ursprungligt meddelande----- > > > > > > > Fran: Rajesh Kumar [mailto:rkumar@cisco.com] > > > > > > > Skickat: den 1 juli 2003 19:15 > > > > > > > Till: James Hamlin > > > > > > > Kopia: paulej@packetizer.com; barry.dingle@bigfoot.com.au; > > > > > > > hwildfeu@cisco.com; mgarakan@cisco.com; oran@cisco.com; > > > > > > > rohan@cisco.com; marcelo@envilogg.se; > > > > jorgen.bjorkner@hotsip.com; > > > > > > > Henry.Sinnreich@mci.com; andreas.piirimets@omnitor.se; > > > > > > > Erik.Zetterstrom@omnitor.se; gunnar.hellstrom@omnitor.se; > > > > > > > Guido.Gybels@rnid.org.uk; mike.spanner@rnid.org.uk; > > > > > > gv@trace.wisc.edu; > > > > > > > trefor@trefor.plus.com > > > > > > > Amne: RE: SV: SV: Internet draft on real time text conversation > > > > > > > > > > > > > > > > > > > > > James, > > > > > > > > > > > > > > The intent here is that the called party could be any SIP > > > > > > phone, not > > > > > > > just SIP phones specially designated for text-only > > > > > > operation. I think > > > > > > > the intent expressed by Guido and Gunnar et al is that a > > > > > > PSTN TTY user > > > > > > > should be able > > > > > > > to open an RFC 2793 text channel with any SIP phone user, > > > > > > and that the > > > > > > > latter should either have an integral keyboard/display > > > > or a port > > > > > > > to such a display. So the problem of call > > > > discrimination when the > > > > > > > caller is a V.21 or > > > > > > > V.23 legacy textphone is not solved unless you allow > > > > > > passthrough fallback > > > > > > > when you cannot tell whether the V.21 signal is text or not - > > > > > > > regardless of the existence of gateways/servers that do PSTN > > > > > > > textphone to RFC 2793 conversion. > > > > > > > > > > > > > > In general, the solution of designating special phone > > > > numbers for > > > > > > > deaf-accessible operation militates against the stipulation > > > > > > that the > > > > > > > deaf be able to create text channels from any PSTN or SIP phone > > > > > > > number, and to any PSTN or SIP phone number. Here, textphone > > > > > > > detection has to be on the basis of control signals > > > > > > exchanged in the > > > > > > > bearer stream or on the content of the bearer stream, > > > > and not on a > > > > > > > priori numbering plans that create a "deaf ghetto". > > > > > > > > > > > > > > For technical reasons, I still think you must mandate > > > > passthrough > > > > > > > operation to enable universal interoperability. > > > > > > > > > > > > > > Kind regards to all. > > > > > > > > > > > > > > Rajesh > > > > > > > > > > > > > > > > > > > > > > > > > > > > At 04:33 PM 7/1/2003 +0100, James Hamlin wrote: > > > > > > > >Rajesh > > > > > > > > > > > > > > > >It would be possible for people on the IP network to have PSTN > > > > > > > numbers that > > > > > > > >are taken from a block that is assigned only to text. > > > > Therefore > > > > > > > the gateway > > > > > > > >between PSTN and the IP network knows from the called number > > > > > > > that the intent > > > > > > > >is to use text. > > > > > > > > > > > > > > > >Regards > > > > > > > > > > > > > > > >James > > > > > > > > > > > > > > > >-----Original Message----- > > > > > > > >From: Rajesh Kumar [mailto:rkumar@cisco.com] > > > > > > > >Sent: 01 July 2003 16:05 > > > > > > > >To: A vWijk > > > > > > > >Cc: paulej@packetizer.com; barry.dingle@bigfoot.com.au; > > > > > > > >hwildfeu@cisco.com; mgarakan@cisco.com; oran@cisco.com; > > > > > > > >rohan@cisco.com; marcelo@envilogg.se; > > > > jorgen.bjorkner@hotsip.com; > > > > > > > >Henry.Sinnreich@mci.com; andreas.piirimets@omnitor.se; > > > > > > > >Erik.Zetterstrom@omnitor.se; gunnar.hellstrom@omnitor.se; > > > > > > > >Guido.Gybels@rnid.org.uk; james.hamlin@rnid.org.uk; > > > > > > > >mike.spanner@rnid.org.uk; gv@trace.wisc.edu; > > > > > > > >trefor@trefor.plus.com > > > > > > > >Subject: Re: SV: SV: Internet draft on real time text > > > > conversation > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> "rkumar@cisco.com" 07/01/03 16:04 >>> > > > > > > > > > > > > > > > >Arnoud, > > > > > > > > > > > > > > > >As I indicated in another email, interoperability with legacy > > > > > > > V.21 and V.23T > > > > > > > > TY devices is not feasible unless you support a passthrough > > > > > > > >fallback. I have no hidden agenda here, I am just presenting a > > > > > > > >technical difficulty that SG16/Q11 and TIA TR.30.1 have been > > > > > > > >struggling with for the past 6 months. I do not know how > > > > > > you can do > > > > > > > >without TTY passthrough if you want universal > > > > > > interoperability. Here > > > > > > > >was my mail, sent yesterday: > > > > > > > > > > > > > > > >There is a real technical difficulty which I would want you all > > > > > > > to consider. > > > > > > > > > > > > > > > >Let us say that you mandate T.140/RFC 2793 for all SIP > > > > > > phones and do > > > > > > > >not mandate TTY passthrough. > > > > > > > > > > > > > > > >Let us say the call originates from a PSTN TTY and is > > > > routed via > > > > > > > a gatewayt > > > > > > > > o a SIP phone, which has native RFRC2793-based text > > > > > > > > capabilities. > > > > > > > > > > > > > > > >SG16/Q11 has struggled with the fact that you cannot always > > > > > > > discriminate aT > > > > > > > > TY call from a non-TTY call when V.21 or V.23 > > > > > > modulations are used. > > > > > > > >In this case, there is no basis for the gateway to convert the > > > > > > > >PSTN > > > > > > > TTY signali > > > > > > > > nto RFC 2793/T.140. However, the gateway can determine > > > > > > that this is > > > > > > > >a modulated signal based on answer tone (if present) or on > > > > > > specific > > > > > > > >FSK frequencies. It can use VBD passthrough (G.711) in > > > > > > this case but > > > > > > > >not RFC 2793 since it does not know if the V.21/V.23 > > > > > > signal is text > > > > > > > >or not. > > > > > > > > > > > > > > > >Ergo, we cannot preclude a requirement for G.711 VBD > > > > passthrough > > > > > > > support onS > > > > > > > > IP phones in favor of T.140. You can mandate both as musts, > > > > > > > but you cannoth > > > > > > > > ave an interoperable solution if you do not have passthrough. > > > > > > > > > > > > > > > >Rajesh > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >At 04:02 PM 7/1/2003 +0200, A vWijk wrote: > > > > > > > > >Paul, > > > > > > > > >How do you feel by mandating T.140/RTP along with the TTY > > > > > > > passthrough on> > > > > > > > > IP telephones and such? > > > > > > > > >The technology is then ready for the T.140 usage. > > > > Which may be > > > > > > > very very> > > > > > > > > rapidly! > > > > > > > > >And remember..as I am stating over and over again. RFC2793 is > > > > > > > NOT limited> > > > > > > > > for the hearing impaired users only! > > > > > > > > >Many other services will be possible with text conversation. > > > > > > > > >And that will likely stimulate the acceptance of T.140 too. > > > > > > > > > > > > > > > > > >And if we explain the goal of T.140 and the possibilities. > > > > > > > Then I do not> > > > > > > > > see any problems for the governments to subsidize this > > > > > > > development and buy> > > > > > > > > IP telephones for the hearing impaired. > > > > > > > > >Ofcourse, we have to guarantee the legacy TTY > > > > support. But also > > > > > > > > >that it has to be phased out. > > > > > > > > > > > > > > > > > >Please do not lock out T.140 by mandating TTY voice > > > > > > > fallback/passthrough> > > > > > > > > for IP telephones and clients/servers etc. > > > > > > > > > > > > > > > > > >greetz > > > > > > > > > > > > > > > > > >Arnoud van Wijk > > > > > > > > > > > > > > > > > ><<< "Paul E. Jones" 7/ 1 5:47a >>> > > > > > > > > >Rajesh, > > > > > > > > > > > > > > > > > >I agree with your concerns. Also, I think the case is even > > > > > > > stronger for > > > > > > > > >other countries where such issues are as thoughtfully > > > > > > > considered. I really > > > > > > > > >doubt that we'll see any requirements in many countries. > > > > > > > > > > > > > > > > > >Another factor is cost. It might be a small > > > > per-unit cost to > > > > > > > > >include necessary support, but even if it is $10, > > > > $10 times the > > > > > > > > >number > > > > > > > of devices a > > > > > > > > >large, mass manufacturing company will produce in a > > > > > > > > >highly-competitive, low-margin environment becomes a > > > > > > major issue. > > > > > > > > >Thus, there will be a push-back from the extremely > > > > high-volume > > > > > > > > >manufacturers, I think. > > > > > > > > > > > > > > > > > >Considering all things, what I think the best roadmap is: > > > > > > > > > 1) Create devices that are dual TTY/T.140 devices > > > > that work > > > > > > > on PSTN or > > > > > > > >IP > > > > > > > > > 2) Make sure every IP phone, residential gateway / analog > > > > > > > > >terminal adapter, etc. > > > > > > > > > can properly carry TTY signals, modem signals, > > > > > > fax, etc. and that > > > > > > > > > a standard TTY device can interface with said device > > > > > > > > > > > > > > > > > >Over time, we may see increased support for T.140 > > > > > > natively on every > > > > > > > > >IP phone. But, I really suspect that for a long > > > > time to come, > > > > > > > (2) is going to > > > > > > > > >be extremely important. Even so, with (1) in existence, > > > > > > it means > > > > > > > > >that people can start to take advantage of T.140 as > > > > soon as the > > > > > > > devices are put > > > > > > > > >into their hands... and so the transition begins. > > > > > > > > > > > > > > > > > >Paul > > > > > > > > > > > > > > > > > >----- Original Message ----- > > > > > > > > >From: "Rajesh Kumar" > > > > > > > > >To: "A vWijk" > > > > > > > > >Cc: ; ; > > > > > > > > >; ; > > > > > > > ; > > > > > > > > >; ; ; > > > > > > > > >; > > > > ; > > > > > > > > >; > > > > ; > > > > > > > > >; ; > > > > > > > > >; ; > > > > > > > > > > > > > > > >Sent: Monday, June 30, 2003 11:21 PM > > > > > > > > >Subject: Re: SV: SV: Internet draft on real time text > > > > > > conversation > > > > > > > > > > > > > > > > > > > > > > > > > > > > Dr. van Wijk, > > > > > > > > > > > > > > > > > > > > While I support your sentiments, are you sure that > > > > > > > governments all over > > > > > > > > >the > > > > > > > > > > world will provide these mobile text phones to the > > > > > > > hard-of-hearing on a > > > > > > > > > > subsidized basis? Also, the monthly plans that go with it? > > > > > > > > > > > > > > > > > > > > While I do not know about other countries, I seriously > > > > > > > doubt that the US > > > > > > > > > > will do such a thing in the near future. I think the US > > > > > > > deaf community > > > > > > > >is > > > > > > > > > > stuck with Baudot devices for a long time, unless they can > > > > > > > afford PCs on > > > > > > > > > > their own budget.Probably a USB interface on the SIP phone > > > > > > > to a cheap > > > > > > > > > > device is probably the best shot at universal > > > > > > > accessibility. Even so, I > > > > > > > > > > doubt if the US government will subsidize the SIP > > > > > > phone + keypad > > > > > > > > > > + > > > > > > > >screen > > > > > > > > > > combo, even it is cheaper that the Baudot TTY. This > > > > > > is because > > > > > > > > > > this > > > > > > > >would > > > > > > > > > > entail a mass replacement for thousands of > > > > existing Baudot > > > > > > > > > > devices. > > > > > > > > > > > > > > > > > > > > I might be wrong - I hope I am. > > > > > > > > > > > > > > > > > > > > Rajesh > > > > > > > > > > > > > > > > > > > > At 12:33 PM 6/26/2003 +0200, A vWijk wrote: > > > > > > > > > > >Paul, > > > > > > > > > > >I am also looking at a larger scale. > > > > > > > > > > >Imagine that 3 companies > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >******************************************************************* > > > > > > >** > > > > > > > >*** > > > > > > > >This email and any files transmitted with it are > > > > confidential and > > > > > > > >intended solely for the use of the individual or > > > > entity to whom > > > > > > > >they are addressed. Any views or opinions expressed are solely > > > > > > > >those of the author and do not necessarily represent > > > > RNID policy. > > > > > > > > > > > > > > > >If you are not the intended recipient you are advised that > > > > > > any use, > > > > > > > >dissemination, forwarding, printing or copying of this > > > > email is > > > > > > > >strictly prohibited. > > > > > > > > > > > > > > > >If you have received this email in error please notify > > > > the RNID > > > > > > > >Helpdesk by telephone on: +44 (0) 207 296 8282. > > > > > > > > > > > > > > > >The Royal National Institute for Deaf People > > > > > > > >Registered Office 19-23 Featherstone Street > > > > > > > >London EC1Y 8SL No. 454169 (England) > > > > > > > >Registered Charity No. 207720 > > > > > > > > > > > > > > > > > >******************************************************************* > > > > > > >** > > > > > > > >*** > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 14 08:01: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 HAA08811 for ; Mon, 14 Jul 2003 07: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 19c1GR-0006no-N9 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 07:13:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EBD39U026143 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 07:13:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c1GO-0006na-En for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 07:13: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 GAA05545 for ; Mon, 14 Jul 2003 06:27:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c0YP-0003rm-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 06:27:33 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c0YF-0003r4-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 06:27:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c0Y4-0000av-Ss; Mon, 14 Jul 2003 06:27:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bz2T-00043p-BU for sipping@optimus.ietf.org; Mon, 14 Jul 2003 04: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 EAA02445 for ; Mon, 14 Jul 2003 04:50:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bz2P-0002zl-00 for sipping@ietf.org; Mon, 14 Jul 2003 04:50:26 -0400 Received: from pxf01lhr.egham.rim.net ([193.109.81.7] helo=mhs02lhr.blackberry.net) by ietf-mx with esmtp (Exim 4.12) id 19bz2O-0002zX-00 for sipping@ietf.org; Mon, 14 Jul 2003 04:50:25 -0400 Received: from mailrouter02.bwc.prod.uk.blackberry (mailrouter02.bwc.prod.uk.blackberry [172.16.80.218]) by mhs02lhr.blackberry.net (8.11.7+Sun/8.11.3) with ESMTP id h6E8lnk04806; Mon, 14 Jul 2003 09:47:49 +0100 (BST) Received: from imap01.eu.blackberry.net (imap01.eu.blackberry.net [172.16.80.224]) by mailrouter02.bwc.prod.uk.blackberry (8.12.8/8.12.8) with ESMTP id h6E8lmPI008346; Mon, 14 Jul 2003 08:47:48 GMT Received: from imap01.eu.blackberry.net (localhost.eu.blackberry.net [127.0.0.1]) by imap01.eu.blackberry.net (Mirapoint Messaging Server MOS 3.3.2-CR) with ESMTP id ABA01580; Mon, 14 Jul 2003 08:47:46 GMT Received: from 81.160.243.24 by imap01.eu.blackberry.net (Mirapoint Messaging Server MOS 3.3.2-CR) with HTTPS/1.1; Mon, 14 Jul 2003 09:47:46 +0100 Date: Mon, 14 Jul 2003 09:47:46 +0100 From: Guido Gybels To: gv@trace.wisc.edu Cc: "'Henry Sinnreich'", "'Gunnar Hellstrom'", Guido.Gybels@rnid.org.uk, mike.spanner@rnid.org.uk, andreas.piirimets@omnitor.se, gv@trace.wisc.edu, trefor@trefor.plus.com, "'Rajesh Kumar'", marcelo@envilogg.se, jorgen.bjorkner@hotsip.com, "'James Hamlin'", Erik.Zetterstrom@omnitor.se, hwildfeu@cisco.com, paulej@packetizer.com, barry.dingle@bigfoot.com.au, mgarakan@cisco.com, oran@cisco.com, rohan@cisco.com, sipping@ietf.org Reply-To: guido.gybels@rnid.org.uk X-Mailer: Webmail Mirapoint Direct 3.3.2-CR MIME-Version: 1.0 Message-Id: <60ab7dbc.a335acbc.8165f00@imap01.eu.blackberry.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] RE: items for vor voting in the BOF Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 Gregg, I think Gunnar's version was quite clear and straight forward, I don't think we should complicate things any further. So, I would suggest we use Gunnar's version. Guido _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 14 09:33: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 JAA19482 for ; Mon, 14 Jul 2003 09:33: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 19c3Rb-0004nC-82 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 09:32:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EDWhRl018421 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 09:32:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3Rb-0004n2-4A for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 09:32:43 -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 JAA19396 for ; Mon, 14 Jul 2003 09:32: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 19c3Qv-0004hl-Rv; Mon, 14 Jul 2003 09: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 19c3Ql-0004hO-Kd for sipping@optimus.ietf.org; Mon, 14 Jul 2003 09:31:51 -0400 Received: from PLUTO.LEAPSTONE.COM ([207.164.160.106]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19236 for ; Mon, 14 Jul 2003 09:31:47 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: [Sipping] Comments on draft-ietf-sipping-session-policy-req-00 Date: Mon, 14 Jul 2003 09:21:01 -0400 Message-ID: <74C307FA4137884EA234B26DE84C0034013723@PLUTO.LEAPSTONE.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: [Sipping] Comments on draft-ietf-sipping-session-policy-req-00 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Index: AcNJ6Jz8yLKjwb2AQ9qUWyJG/baijwAIMclg From: "Dusan Mudric" To: "Jonathan Rosenberg" , "Volker Hilt" Cc: "Miguel A. Garcia" , 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 User preferences related to service negotiation between subscriber and = service/internet provider, like SLA, are good candidates for = out-of-a-call negotiation. These policies, like type of services, = quality of services, pricing for QoS and so on, would be negotiated very = infrequently and would be applied on every subsequent call. Regards, Dusan Mudric. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]=20 Sent: Monday, July 14, 2003 5:14 AM To: Volker Hilt Cc: Miguel A. Garcia; sipping@ietf.org Subject: Re: [Sipping] Comments on = draft-ietf-sipping-session-policy-req-00 inline. Volker Hilt wrote: > Jonathan, Miguel, >=20 > Miguel A. Garcia wrote: >=20 >> First, I am missing a general requirement that describes the general >> mechanism that we want. If you consider the General Requirements, >> there are many of them explaining different aspects of the solution, >> but none that describes generally what is needed. I would expect >> something on these lines: >> >> "A mechanism that provides SIP proxies with the ability to convey >> session related policies to SIP User Agents". >=20 >=20 > The goals of the policy draft have been motivated quite nicely with a > number of very convincing examples. The requirements for these = examples > are reflected in some of the Policy Requirements (examples are > REQ-POL-4, REQ-POL-5 and REQ-POL-7 to REQ-POL-13). >=20 > I was wondering if it is possible to separate the requirements = specific > to these examples (e.g. requesting the use of a different codec, > different media addresses, firewalls, QoS) from requirements of the > general policy mechanism (the mechanism needed to exchange policy > information between UAC, proxies and UAS). This mechanism could be > defined independent of a certain use. It could enable a proxy to = request > the modification of any aspect of a session description. >=20 > The requirements for certain use cases of the session policy mechanism > could then be defined in a separate section/document. This separation > seems to be more extendible than combining the requirements of the > policy exchange mechanism and use cases. I think that makes sense. I'll restructure the document so that there=20 are some general mechanism requirements, indpendent of the particular=20 policy type, and then some requirements for specific policies (codec=20 policy, intermediary policy, etc.). >=20 >> The thing is that I don't foresee dynamic changes in policies, >> depending on the traffic in the network. One could do it, of course, >> but requires some extra administration or having some sort of monitor >> that acts upon thresholds. >=20 >=20 > How do you envision the proxy to change policies within an active = call? > This sounds a little like re-INVITEs send out by the proxy (something = a > proxy can't do!). I think what Miguel is saying is that they wouldnt need to change in=20 the middle of a call. In fact, the policies would be fairly static and=20 would change infrequently. When they do change, they don't need to do=20 so synchronous with any particular call attempt. In that case, you can=20 use mechanisms totally outside of a call. It becomes more of a=20 provisioning problem, and things like xcap would be more applicable. >=20 >> Instead I foresee another scenario where the administrator has >> certain fixed policies that do not change often. For instance, an=20 >> administrator could permanently disallow the G.711 codec because of >> the high bandwidth. I think this is an important issue to discuss, >> because the solution may go in one or another direction depending on >> the rate of the changes in policy. I would suggest to add a >> requirement regarding the expected changes in the policies. >=20 >=20 > The session policies will probably not depend on highly dynamic = factors > such a load (congestion control comes to mind here) but more on things > like network configuration and user preferences. These issues can = easily > be considered by a proxy on a call to call basis. The point Miguel is making, and its important one, is it wouldn't even=20 be on a call-by-call basis. This is really the first major issue we need to tackle (we'll discuss=20 during the sipping meeting today). Do we think session policies need=20 to be specified on a call-by-call basis? Certain policies tend to need=20 to be call-by-call. For example, using an intermediary for relaying=20 media. That needs to be call-by-call since the port to send to will be=20 computed on a call-by-call basis. Other policies, such as codecs to=20 use, arguably don't change much at all, and may not need to be=20 computed on a call-by-call basis. So, the question is whether we think there are two mechanisms - one=20 outside of a call, and one inside, or just one. One point to be made=20 is that, if you have a single in-call mechanism, that could be used to=20 cover both static and dynamic requirements. Thus, you would have just=20 one mechanism (thats good). But, it might be inefficient for wireless,=20 sending the same policeis to the UA over and over again (thats bad).=20 Then again, sigcomp might fix it (thats good). So, its not obvious to me what the right direction is. Thoughts? -Jonathan R. --=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 Mon Jul 14 09:48: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 JAA20988 for ; Mon, 14 Jul 2003 09:48: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 19c3gX-0005l7-AO for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 09:48:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EDm9ft022130 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 09:48:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3gX-0005kr-3a for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 09:48: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 JAA20865 for ; Mon, 14 Jul 2003 09:48:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c3gV-0007mM-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 09:48:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c3gT-0007mI-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 09:48:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3gQ-0005fO-0N; Mon, 14 Jul 2003 09:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3gK-0005eE-Sw for sipping@optimus.ietf.org; Mon, 14 Jul 2003 09:47: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 JAA20841 for ; Mon, 14 Jul 2003 09:47:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c3gH-0007lk-00 for sipping@ietf.org; Mon, 14 Jul 2003 09:47:53 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19c3gF-0007ka-00 for sipping@ietf.org; Mon, 14 Jul 2003 09:47: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 h6EDlKE5006377 for ; Mon, 14 Jul 2003 09:47:20 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jul 2003 08:47:20 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FEE@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: sipping@ietf.org Date: Mon, 14 Jul 2003 08:47:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] GRUUs in REGISTER Contacts? Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Perhaps I just missed it, but I can't find or deduce any particular reason for using a GRUU in the Contact header field of a REGISTER request. The temporal binding properties of GRUU leasing are identical to those of registrations; what additional properties are afforded? /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 Jul 14 09:48: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 JAA21031 for ; Mon, 14 Jul 2003 09:48: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 19c3gY-0005lV-Oh for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 09:48:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EDmAA7022157 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 09:48:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3gY-0005lH-Lc for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 09:48: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 JAA20873 for ; Mon, 14 Jul 2003 09:48:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c3gW-0007mP-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 09:48:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c3gT-0007mJ-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 09:48:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3gR-0005fs-2L; Mon, 14 Jul 2003 09:48:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3gN-0005eP-Ag for sipping@optimus.ietf.org; Mon, 14 Jul 2003 09:47: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 JAA20851 for ; Mon, 14 Jul 2003 09:47:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c3gL-0007m5-00 for sipping@ietf.org; Mon, 14 Jul 2003 09:47:57 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19c3gF-0007kZ-00 for sipping@ietf.org; Mon, 14 Jul 2003 09:47:56 -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 h6EDlKE5006371 for ; Mon, 14 Jul 2003 09:47:20 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jul 2003 08:47:19 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FEC@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Jonathan Rosenberg , sipping Subject: RE: [Sipping] How to report DTMF - conclusion of the app interact ion design team: SIP MESSAGE Date: Mon, 14 Jul 2003 08:47: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: , > 7. SIP MESSAGE > > Send a SIP MESSAGE request from the client to the application, > containing the digit sequence to report. > > This was a bit of a bending of the semantic of MESSAGE, which is > really meant for conveying information for display to a user. > However, the issue is mostly philosophical in nature. We didn't > see any particular technical issue that would prevent this from > working, unlike all of the above ones which had technical issues. If we're throwing philosophical objections about the intended semantics of a method out the window, I'm left wondering why MESSAGE was selected over OPTIONS for this purpose. All other things being equal, receipt of a misdirected OPTIONS will never have harmful effects; meanwhile, receipt of a MESSAGE with an unrecognized content type has an extremely high probability of causing a nonzero number of implementations to pop up a window saying something like: +------------------------------------------------------------+ | 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] | +------------------------------------------------------------+ This is what I most emphatically do *not* want to happen. It is the key reason that I push back against use of MESSAGE for anything that is not to be rendered to a user, and it is a proof point that the objections to abusing MESSAGE for general purpose RPC go beyond philosophy into user experience. /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 Jul 14 10:35: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 KAA24693 for ; Mon, 14 Jul 2003 10:35: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 19c4Pb-0008SK-Lc for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 10:34:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EEYhe3032498 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 10:34:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4Pb-0008S5-IW for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 10:34: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 KAA24627 for ; Mon, 14 Jul 2003 10:34:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c4PX-0000bW-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 10:34:39 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c4PV-0000bP-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 10:34:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4Ow-0008Om-Oe; Mon, 14 Jul 2003 10:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4Oc-0008Nn-76 for sipping@optimus.ietf.org; Mon, 14 Jul 2003 10:33: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 KAA24512 for ; Mon, 14 Jul 2003 10:33:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c4OV-0000Zh-00 for sipping@ietf.org; Mon, 14 Jul 2003 10:33:35 -0400 Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx with esmtp (Exim 4.12) id 19c4OS-0000ZV-00 for sipping@ietf.org; Mon, 14 Jul 2003 10:33:32 -0400 Received: from pingtel.com (churchill.ietf57.telekom.at [81.160.177.148]) by mail.pingtel.com (8.11.6/8.11.6) with ESMTP id h6EEXKA15049; Mon, 14 Jul 2003 10:33:20 -0400 Message-ID: <3F12BF29.82377DEA@pingtel.com> Date: Mon, 14 Jul 2003 10:33:13 -0400 From: "Daniel G. Petrie" Organization: Pingtel Corp. http://www.pingtel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: georg.mayer@nokia.com CC: sipping@ietf.org Subject: Re: [Sipping] Comments on draft-ietf-sipping-config-framework-00.txt - 3: Fetching of Information References: <147748D63CC6B5449BC5E49FB5F8FF510149D379@esebe021.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think that in an enterpise or carrier scenario whith fixed phones, it is a desireable requirement that the UAs maintain a subscription so that the config server knows the device is still aournd and how it is configured and perhaps most importantly, be able to update the config when desired. I think that this is a SHOULD requirement. I have no issues with making this softer for wireless or suggesting that it be configurable. The config server MUST implement RFC 3265 which would allow SUBSCRIBE with Expires of zero. The draft should not be indicating otherwise. georg.mayer@nokia.com wrote: > Hi, > > another one on information fetching: > > The draft proposes that the subscription is kept alive. From point of view of a wireless terminal - with limited resources - it is not desirable to be mandated to keep a subscription for a service alive, although the service configuration data is not going to change very frequently. The user should therefore have the possiblity to fetch the information once (i.e. Expires=0 in SUBSCRIBE). If one of the services fails, the user can fetch again. This should be an option - other users may want to subscribe permanently to the event package. > > Cheers > Georg > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 Jul 14 10:35: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 KAA24695 for ; Mon, 14 Jul 2003 10:35: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 19c4Pc-0008Sd-Ps for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 10:34:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EEYikK032517 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 10:34:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4Pc-0008SO-Lp for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 10:34: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 KAA24637 for ; Mon, 14 Jul 2003 10:34:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c4PX-0000bT-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 10:34:39 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c4PV-0000bO-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 10:34:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4Ov-0008OR-Df; Mon, 14 Jul 2003 10: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 19c4Oc-0008No-0P for sipping@optimus.ietf.org; Mon, 14 Jul 2003 10:33: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 KAA24527 for ; Mon, 14 Jul 2003 10:33:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c4OZ-0000Zu-00 for sipping@ietf.org; Mon, 14 Jul 2003 10:33:39 -0400 Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx with esmtp (Exim 4.12) id 19c4OW-0000ZW-00 for sipping@ietf.org; Mon, 14 Jul 2003 10:33:37 -0400 Received: from pingtel.com (churchill.ietf57.telekom.at [81.160.177.148]) by mail.pingtel.com (8.11.6/8.11.6) with ESMTP id h6EEXNA15053; Mon, 14 Jul 2003 10:33:24 -0400 Message-ID: <3F12BF2D.662619E3@pingtel.com> Date: Mon, 14 Jul 2003 10:33:17 -0400 From: "Daniel G. Petrie" Organization: Pingtel Corp. http://www.pingtel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: georg.mayer@nokia.com CC: sipping@ietf.org Subject: Re: [Sipping] Comments on draft-ietf-sipping-config-framework-00.txt - 2: Content and format of configuration data References: <147748D63CC6B5449BC5E49FB5F8FF510149D37A@esebe021.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I have had a number of conversations with folks on the profile content. I think that I have distilled this to using name spaces to define small configuration sets that can be aggregated in a single xml document. The sets should be such that an implementor can decide based upon the funtionality they want to provide, which config sets they require. The UA should just ignore config sets that it does not need. There was an initial proposal defining a number of the config data parameters (http://www.pingtel.com/docs/draft-stredicke-sipping-ep-config-00.txt) However I think that we need to work out the generic format independent of any of the specific parameters. Then we can create drafts for each of the config sets. If you have time this week in Vienna, it would be great to get together and talk this through a little more and perhaps work out a plan for drafting it up. georg.mayer@nokia.com wrote: > Hello, > > next commten is on Content and format of configuration data: > > It's already said in the abstract, that content and format of configuration data are outside the scope of the draft. Currently only the possiblity for returning a link int he body of the subscribe is provided. It would be of general help if we could agree on generic service indicators / parameters, that could be downloaded to the UE directly from the configuration server in the NOTIFY. A XML based coding seems to be the best approach here. > > So a service parameter could look like e.g. sip:conf23@home1.net > > For this purpose it would be required to introduce a list of initial service parameters to the draft. > > As said above, the proposal here is to define mainly SIP service parameters. Of course this framework needs to be kept extensible also to other kinds of parameters. > > This would also not contradict to the initial idea of downloading a link, e.g. for a non-SIP related configuration of the UE, such a link could be one of the proposed parameters. > > If such an approach could be agreed, Hisham and I would start working on an I-D for that. > > Thanks > Georg > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 Jul 14 10:35: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 KAA24694 for ; Mon, 14 Jul 2003 10:35: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 19c4Pa-0008S2-8S for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 10:34:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EEYgYU032482 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 10:34:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4Pa-0008Rp-5H for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 10:34: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 KAA24626 for ; Mon, 14 Jul 2003 10:34:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c4PX-0000bZ-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 10:34:39 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c4PW-0000bQ-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 10:34:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4Ow-0008Oc-36; Mon, 14 Jul 2003 10:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4Oc-0008Nq-3E for sipping@optimus.ietf.org; Mon, 14 Jul 2003 10:33: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 KAA24526 for ; Mon, 14 Jul 2003 10:33:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c4OZ-0000Zx-00 for sipping@ietf.org; Mon, 14 Jul 2003 10:33:39 -0400 Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx with esmtp (Exim 4.12) id 19c4OX-0000Ze-00 for sipping@ietf.org; Mon, 14 Jul 2003 10:33:37 -0400 Received: from pingtel.com (churchill.ietf57.telekom.at [81.160.177.148]) by mail.pingtel.com (8.11.6/8.11.6) with ESMTP id h6EEXRA15058; Mon, 14 Jul 2003 10:33:27 -0400 Message-ID: <3F12BF30.ABD2C7F3@pingtel.com> Date: Mon, 14 Jul 2003 10:33:20 -0400 From: "Daniel G. Petrie" Organization: Pingtel Corp. http://www.pingtel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: georg.mayer@nokia.com CC: sipping@ietf.org Subject: Re: [Sipping] Comments on draft-ietf-sipping-config-framework-00.txt - 1: general scope of framework References: <147748D63CC6B5449BC5E49FB5F8FF510149D37B@esebe021.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The content and format are out of scope for draft-ietf-sipping-config-framework-00.txt. However the framework proposed is intended for service related parameters that the UA needs. So I think that this is not a scope change, it is within the existing scope unless I am missing something. georg.mayer@nokia.com wrote: > Hello Dan et al, > > after reviewing draft-ietf-sipping-config-framework-00.txt I have some comments which I send in this and the following messages. Most of them are written from point of view of wireless systems. > > 1. General Scope of the Framework > It looks that the draft is very useful in scenarios where a user needs to discover certain SIP service parameters. Therefore it would be good to widen the scope of the draft. From the abstract and overview sections, it reads as if this draft is mainly intended to bring vendor specific UE configuration data to the UE. I would propose to widen the scope in order to allow any type of configuration parameter to be sent to the UE, e.g. also SIP service parameters such as specific Application Servers, Conference (Factory) URIs etc. > > Best regards > Georg > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 Jul 14 11:11: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 LAA27559 for ; Mon, 14 Jul 2003 11: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 19c4yu-0002jK-4b for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 11:11:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EFBC3a010487 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 11: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 19c4yu-0002j4-0n for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 11:11: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 LAA27511 for ; Mon, 14 Jul 2003 11:11:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c4yr-0001Hp-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 11:11:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c4yq-0001Hl-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 11: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 19c4yj-0002f1-Vz; Mon, 14 Jul 2003 11:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4y3-0002dF-4N for sipping@optimus.ietf.org; Mon, 14 Jul 2003 11: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 LAA27454 for ; Mon, 14 Jul 2003 11:10:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c4y0-0001Gb-00 for sipping@ietf.org; Mon, 14 Jul 2003 11:10:16 -0400 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 19c4xz-0001GQ-00 for sipping@ietf.org; Mon, 14 Jul 2003 11:10:15 -0400 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 1858; Mon, 14 Jul 2003 11:09:11 -0400 (EDT) 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] New Tones draft (was: "who plays the tone" or something like th... Date: Mon, 14 Jul 2003 11:09:43 -0400 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F6548@zoe.office.snowshore.com> Thread-Topic: [Sipping] New Tones draft (was: "who plays the tone" or something like th... Thread-Index: AcM5rN6QZKB/ZcY4Soe+ixtx5CM5DgQUOQDw From: "Eric Burger" To: , 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 Decay: suppose it could be negative (gets louder) I think direction 1 (user agent to user) is the only sensible thing for = this draft. I guess that presupposes the whole idea is sensible in the = first place Z-) -----Original Message----- From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: Mon, June 23, 2003 1:25 PM To: rohan@cisco.com; sipping@ietf.org Subject: Re: [Sipping] New Tones draft (was: "who plays the tone" or = something like th... In a message dated 6/23/2003 2:02:12 AM Eastern Standard Time, = rohan@cisco.com writes:=20 wrote the following draft in order to provide some discussion on=20 alternatives to in-band early-media ringback, and to discuss the issue=20 of playing tones in general which I believe is inherently linked to=20 3pcc and application interaction.=20 Rohan,=20 This seems to handle the general case of instructing a UA to generate a = tone based on a specific set of characteristics (frequencies, levels, = duration, decay, modulation, etc.) One of the immediate questions is = what is the full set of possibilites required and what happens when = someone wants a tone that is outside of that defined set? For example, = you've shown examples of "decay", but what if the required tone starts = low and gets louder? Luckily, no one has used a tone that varies in = frequency over time.=20 I didn't see anything in your write-up or in RFC 2833 about specifying = which direction the UA should send the tone. There can be cases which = the UA needs to be told:=20 1. send the tone only to the user of that UA (e.g., Call Waiting)=20 2. send the tone only to the other end (e.g., Audible Ringing)=20 3. send the tone to both (e.g., Recorder Warning)=20 Volume is defined with a range of -3 to -63 decibels. However, I believe = that off-hook warning tone needs to be higher than -3 dB. Or maybe this = function should be done in a different way, since the UA is presumed to = have other alerting mechanisms (like ringing when already "off-hook").=20 This proposal would work, if every UA were required to support it.=20 Mike Pierce=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 Mon Jul 14 11: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 LAA27586 for ; Mon, 14 Jul 2003 11:11: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 19c4yv-0002jx-3t for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 11:11:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EFBDsE010527 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 11:11:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4yv-0002ji-0T for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 11:11: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 LAA27521 for ; Mon, 14 Jul 2003 11:11:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c4ys-0001Hw-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 11:11:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c4yq-0001Hm-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 11: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 19c4yl-0002fl-9x; Mon, 14 Jul 2003 11:11:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4y5-0002dV-Di for sipping@optimus.ietf.org; Mon, 14 Jul 2003 11:10: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 LAA27463 for ; Mon, 14 Jul 2003 11:10:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c4y2-0001Gs-00 for sipping@ietf.org; Mon, 14 Jul 2003 11:10:18 -0400 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 19c4y1-0001GQ-01 for sipping@ietf.org; Mon, 14 Jul 2003 11:10:18 -0400 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 1858; Mon, 14 Jul 2003 11:09:13 -0400 (EDT) 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] FWD:I-D ACTION:draft-johnston-sipping-rtcp-summary-00.txt Date: Mon, 14 Jul 2003 11:09:46 -0400 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F6551@zoe.office.snowshore.com> Thread-Topic: [Sipping] FWD:I-D ACTION:draft-johnston-sipping-rtcp-summary-00.txt Thread-Index: AcM83sPhMN2DZkCSRkOR05netSfPzANIyzpg From: "Eric Burger" To: "Alan Johnston" 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 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. =20 > -----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 >=20 >=20 > FYI - a new draft on the delivery of RTCP summary reports to=20 > third parties. >=20 > Comments most welcome. >=20 > Thanks, > Alan Johnston > MCI >=20 >=20 > ---------- > 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 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 >=20 > Title : RTCP Summary Report Delivery to=20 > 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 >=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 Mon Jul 14 11:29: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 LAA28488 for ; Mon, 14 Jul 2003 11:29: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 19c5GI-0003tJ-S5 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 11:29:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EFTAvT014953 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 11:29:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c5GI-0003t6-O0 for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 11:29: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 LAA28426 for ; Mon, 14 Jul 2003 11:29:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c5GF-0001Wa-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 11:29:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c5GD-0001WU-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 11:29:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c5G9-0003pK-TL; Mon, 14 Jul 2003 11: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 19c0ga-0003eQ-4d for sipping@optimus.ietf.org; Mon, 14 Jul 2003 06:36: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 GAA06261; Mon, 14 Jul 2003 06:35:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c0gU-00043F-00; Mon, 14 Jul 2003 06:35:54 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=arachne) by ietf-mx with esmtp (Exim 4.12) id 19c0gT-00042l-00; Mon, 14 Jul 2003 06:35:53 -0400 Received: by arachne (Postfix, from userid 1000) id 2BA991A368; Mon, 14 Jul 2003 13:36:03 +0200 (CEST) Date: Mon, 14 Jul 2003 13:36:03 +0200 From: Otmar Lendl To: Patrik =?iso-8859-15?B?RuRsdHN0cvZt?= Cc: "Peterson, Jon" , "'Stastny Richard'" , "Shockey, Richard" , enum@ietf.org, "'sipping@ietf.org'" Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt Message-ID: <20030714113603.GA10219@eunet-ag.at> References: <0449D80A0E9B614A83FA9031B07E8D3B257C80@stntexch2.va.neustar.com> <9EC5E078-B150-11D7-BE0E-000A959CF516@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <9EC5E078-B150-11D7-BE0E-000A959CF516@cisco.com> User-Agent: Mutt/1.3.28i Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id GAA06262 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 On 2003/07/08 16:07, Patrik F=E4ltstr=F6m wrote: >=20 > With experience from Cisco implementing the whole-nine-yards I can tell= =20 > you the problem is not the regexp engine.=20 FYI, I implemeted the full regex substitution algorithm for the=20 Asterisk PBX last week. Calls to Marian utilizing his wildcard NAPTRs worked fine. Based on the Posix regex functions included in the Linux libc, that took about 3 hours and 50 lines of C code. (and some glances at how ser is doing that stuff.) Bringing the code for full precedence/multiple NAPTRs/multiple servicespecs in one NAPTR/tel:-recursion (if needed) - handling up to RFC compliance gives me more headaches. From my point of view, there are the real pitfalls for ENUM resolver implementations. /ol _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 14 11:29: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 LAA28518 for ; Mon, 14 Jul 2003 11:29: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 19c5GN-0003uO-Nz for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 11:29:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EFTF83015018 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 11:29:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c5GN-0003te-HT for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 11:29: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 LAA28423 for ; Mon, 14 Jul 2003 11:29:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c5GF-0001WX-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 11:29:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c5GD-0001WQ-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 11:29:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c5GB-0003pe-G7; Mon, 14 Jul 2003 11:29:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4Hk-0007st-DB for sipping@optimus.ietf.org; Mon, 14 Jul 2003 10:26: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 KAA23728 for ; Mon, 14 Jul 2003 10:26:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c4Hh-0000Or-00 for sipping@ietf.org; Mon, 14 Jul 2003 10:26:33 -0400 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by ietf-mx with esmtp (Exim 4.12) id 19c4Hg-0000Ny-00 for sipping@ietf.org; Mon, 14 Jul 2003 10:26:32 -0400 Received: from dgismtp06.wcomnet.com ([166.38.58.89]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HI000HJQQIHB5@firewall.wcom.com> for sipping@ietf.org; Mon, 14 Jul 2003 14:20:42 +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 <0HI000101QHVJ1@dgismtp06.wcomnet.com>; Mon, 14 Jul 2003 14:20:41 +0000 (GMT) Received: from hsinnreich2 ([166.50.123.27]) by dgismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HI0000HTQI746@dgismtp06.wcomnet.com>; Mon, 14 Jul 2003 14:20:35 +0000 (GMT) Date: Mon, 14 Jul 2003 16:20:28 +0200 From: Henry Sinnreich In-reply-to: <000c01c349ea$98bc2d70$28c81844@USD320002X> To: sipping@ietf.org Cc: guido.gybels@rnid.org.uk, gv@trace.wisc.edu, "'Gunnar Hellstrom'" , mike.spanner@rnid.org.uk, 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, paulej@packetizer.com, barry.dingle@bigfoot.com.au, mgarakan@cisco.com, oran@cisco.com, rohan@cisco.com Message-id: <000301c34a13$17379ae0$8ab8a051@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: multipart/mixed; boundary="Boundary_(ID_XoB3eDt8vMlOq+DxG+8Gyw)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Subject: [Sipping] Time/place for BOF on Real-Time Text Conversation in SIP Telephony Devices Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_XoB3eDt8vMlOq+DxG+8Gyw) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The BOF on Real-Time Text Conversation in SIP Telephony Devices will take place Thursday July 17 in room J241/1 at 10:00-11:00 am CET. The main objective is to discuss and vote on the attached items. Thanks, Henry --Boundary_(ID_XoB3eDt8vMlOq+DxG+8Gyw) Content-type: application/pdf; name="Real-time Text Conversation in SIP Telephony Devices.pdf" Content-disposition: attachment; filename="Real-time Text Conversation in SIP Telephony Devices.pdf" Content-Transfer-Encoding: quoted-printable %PDF-1.3=0A= =0A= 1 0 obj=0A= <<=0A= /Producer (BCL's EasyPDF)=0A= >>=0A= endobj=0A= =0A= 3 0 obj=0A= <<=0A= /Count 0=0A= >>=0A= endobj=0A= =0A= 2 0 obj=0A= <<=0A= /Type /Catalog=0A= /Pages 4 0 R=0A= /Outlines 3 0 R=0A= >>=0A= endobj=0A= =0A= 7 0 obj=0A= [=0A= 806 806 806 806 806 806 806 806 806 806 806 806 806 806 = 806 806 =0A= 806 806 806 806 806 806 806 806 806 806 806 806 806 806 = 806 806 =0A= 298 298 381 597 597 955 716 205 358 358 418 627 298 358 = 298 298 =0A= 597 597 597 597 597 597 597 597 597 597 298 298 627 627 = 627 597 =0A= 1090 716 716 776 776 716 656 835 776 298 537 716 597 895 = 776 835 =0A= 716 835 776 716 656 776 716 1014 716 716 656 298 298 298 = 504 597 =0A= 358 597 597 537 597 597 298 597 597 239 239 537 239 895 = 597 597 =0A= 597 597 358 537 298 597 537 776 537 537 537 359 279 359 = 627 806 =0A= 597 806 239 597 358 1074 597 597 358 1074 716 358 1074 806 = 656 806 =0A= 806 239 239 358 358 376 597 1074 358 1074 537 358 1014 806 = 537 716 =0A= 298 358 597 597 597 597 279 597 358 791 398 597 627 358 = 791 593 =0A= 429 589 358 358 358 619 577 298 358 358 392 597 896 896 = 896 656 =0A= 716 716 716 716 716 716 1074 776 716 716 716 716 298 298 = 298 298 =0A= 776 776 835 835 835 835 835 627 835 776 776 776 776 716 = 716 656 =0A= 597 597 597 597 597 597 955 537 597 597 597 597 298 298 = 298 298 =0A= 597 597 597 597 597 597 597 589 656 597 597 597 597 537 = 597 537 =0A= ]=0A= endobj=0A= =0A= 9 0 obj=0A= <<=0A= /Length 10 0 R=0A= /Filter [/ASCII85Decode /FlateDecode]=0A= >>=0A= stream=0A= GhTQ,gMS6)&:O:So]*<7BBR^0)2&Q(Fp#?c!Gr5X@X2p%419+p0Qsbghc$GQVl/q#apLN\NI.= O@=0A= eYc05Wig4,S[.,6Pu583nM[g5s*"!2OghGC>,*,t\sq)V<%.ZCoAsNTihEf[XRikM)fO8;0rg= eh=0A= X/;OSja:qS[jJH/n!V_GAfd#HY,Z;pQ?ok=3DHBk0=3DO(KY>O?4j;S)Gkd=3DdX3A'A7fcYkOdMr>U;*mc]5X2C/B= >#RQW.m/T<=0A= C,Ih$[5Zd.TCJ_:)VLYt=3DjOAN*VN`IjfLFI-@J3R]ttaIklHjqFZdl#_1J165[7KV2Zgt.C= AK8E=0A= nWc",2UePG\uBjq[NMO'CqS6*bZ6uWK0Fa+Et$uff=3DESC?'UEqP7(N.Nn+;[2"%_"l(($;`= PW(b=0A= ;51&(:69UcO3=3DD6Z?P"[fe5>b,sG,OH?#pTcb;p@-gaOjrW1iYZ= kXYs=0A= !p;FEl[*JPZJ$(G^:M5W%WJ`6p06n"6hu/4E3():n*tj^R= c<=0A= [SO`=3D&rTL-l[c.^5%kAIAWq,>$O*.uK!5$S*k[CHD+"(1.q\kflCS-%ohdYSOSa\3"B6Cn2= PC+t=0A= O8UJh%A4,klp"0R`6P*@\4)@c63E7t2-pf;$fNXS3=3DF-,k;)U]Xgs2n2mJ":-U]jp;c\521= eWro=0A= ^j-Kg*)3*5sEF8H$C.#:N7Xr#'un":G!(:1LOCVMM"-)HLK(Y0\c=3D,U"6;XR= MCJm=0A= E&GPqWuV8.RC/X'B(7+b,Xd]-\;[?lb6B^V$Ccjq4CXZXeMAJn22b,M+HQ2e"= g"=0A= -UGZ^n]=3DnLR)H'P'$FqQ(cO5<=3Dm;^D,5BTY_Y]G31$X-.Lm9tg$``ur= *Y!RY'=0A= 7?,C4lUZ,BL&)=3DFOplf;gD7B\+A6lS6??$2>u[cK=3D2I!u_K/OB(8eCQ0q3KS(Ps(D^"@N= =3DdsaZ/=0A= Itf4(AR[:FU?a.`?SZ:1X-^Gna&(o`dC\p\TK[f1-duW(7[@[$$+JrT4EV>tEHXT>puR\174:,p6_VrQ(sS(<*= n0=0A= YuFLJ*](X?O0sYg&dJE+0fp\62!KrL&dbUaE)rS:pWpt?s,j'(.#@F4a)BsW;ebJ&GUP.%8rJ= V'=0A= m'AP7LH:2r%'CHE0\fEbFQ>%JZ@2rrQS:mWM1*>XQI-p-]@#= k_!o=0A= 4^oQRh!:C:]!dZuUrC\pJGE%,)L%W9P;[EqlbN7J7t$9k:AZrm4jMAO:`cIe=3Dh#Hu4.du:,= -eFY=0A= *pMm:SA_#Pp@Y'FlbEFN&TXB.>q1!6UY=0A= endstream=0A= endobj=0A= =0A= 10 0 obj=0A= 1897=0A= endobj=0A= =0A= 6 0 obj=0A= <<=0A= /Type /Page=0A= /Parent 4 0 R=0A= /MediaBox [ 0 0 792 612 ]=0A= /Resources <<=0A= /Font 5 0 R=0A= /ProcSet [/PDF /Text /ImageB /ImageC] >>=0A= /Contents 9 0 R=0A= >>=0A= endobj=0A= =0A= 4 0 obj=0A= <<=0A= /Type /Pages=0A= /Kids [=0A= 6 0 R=0A= ]=0A= /Count 1=0A= >>=0A= endobj=0A= =0A= 8 0 obj=0A= <<=0A= /Type /FontDescriptor=0A= /Ascent 972=0A= /CapHeight 1200=0A= /Descent 228=0A= /Flags 32=0A= /FontBBox [0 -228 2892 972]=0A= /FontName /ArialMT=0A= /ItalicAngle 0=0A= /StemV 0=0A= >>=0A= endobj=0A= =0A= 5 0 obj=0A= <<=0A= /F1 << /Type /Font /Subtype /Type1 /BaseFont /Courier >>=0A= /F2 << /Type /Font /Subtype /Type1 /BaseFont /Courier-Bold >>=0A= /F3 << /Type /Font /Subtype /Type1 /BaseFont /Courier-BoldOblique >>=0A= /F4 << /Type /Font /Subtype /Type1 /BaseFont /Courier-Oblique >>=0A= /F5 << /Type /Font /Subtype /Type1 /BaseFont /Helvetica >>=0A= /F6 << /Type /Font /Subtype /Type1 /BaseFont /Helvetica-Bold >>=0A= /F7 << /Type /Font /Subtype /Type1 /BaseFont /Helvetica-BoldOblique >>=0A= /F8 << /Type /Font /Subtype /Type1 /BaseFont /Helvetica-Oblique >>=0A= /F9 << /Type /Font /Subtype /Type1 /BaseFont /Times-Roman >>=0A= /F10 << /Type /Font /Subtype /Type1 /BaseFont /Times-Bold >>=0A= /F11 << /Type /Font /Subtype /Type1 /BaseFont /Times-Italic >>=0A= /F12 << /Type /Font /Subtype /Type1 /BaseFont /Times-BoldItalic >>=0A= /F13 << /Type /Font /Subtype /Type1 /BaseFont /Symbol >>=0A= /F14 << /Type /Font /Subtype /Type1 /BaseFont /ZapfDingbats >>=0A= /F15=0A= <<=0A= /Type /Font=0A= /Subtype /TrueType=0A= /BaseFont /ArialMT=0A= /Encoding /WinAnsiEncoding=0A= /FirstChar 0=0A= /LastChar 255=0A= /FontDescriptor 8 0 R=0A= /Widths 7 0 R=0A= >>=0A= >>=0A= endobj=0A= =0A= xref=0A= 0 11=0A= 0000000000 65535 f =0A= 0000000010 00000 n =0A= 0000000089 00000 n =0A= 0000000058 00000 n =0A= 0000003631 00000 n =0A= 0000003857 00000 n =0A= 0000003474 00000 n =0A= 0000000155 00000 n =0A= 0000003691 00000 n =0A= 0000001464 00000 n =0A= 0000003452 00000 n =0A= trailer=0A= <<=0A= /Size 11=0A= /Root 2 0 R=0A= /Info 1 0 R=0A= >>=0A= startxref=0A= 4916=0A= %%EOF=0A= --Boundary_(ID_XoB3eDt8vMlOq+DxG+8Gyw)-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 14 11:29: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 LAA28519 for ; Mon, 14 Jul 2003 11:29: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 19c5GN-0003u4-LC for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 11:29:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EFTFqA014988 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 11:29:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c5GN-0003tf-Gk for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 11:29: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 LAA28420 for ; Mon, 14 Jul 2003 11:29:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c5GE-0001WT-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 11:29:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c5GD-0001WM-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 11:29:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c5GC-0003po-7A; Mon, 14 Jul 2003 11:29:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4hP-0001g8-F5 for sipping@optimus.ietf.org; Mon, 14 Jul 2003 10:53: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 KAA26658 for ; Mon, 14 Jul 2003 10:53:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c4hM-000142-00 for sipping@ietf.org; Mon, 14 Jul 2003 10:53:05 -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 19c4hM-00013x-00 for sipping@ietf.org; Mon, 14 Jul 2003 10:53:04 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 14 Jul 2003 07:51:36 -0700 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 h6EEqRuG026404; Mon, 14 Jul 2003 07:52: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 AJC76693; Mon, 14 Jul 2003 07:49:35 -0700 (PDT) Date: Mon, 14 Jul 2003 07:54:06 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: sipping@ietf.org, guido.gybels@rnid.org.uk, gv@trace.wisc.edu, "'Gunnar Hellstrom'" , mike.spanner@rnid.org.uk, 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, paulej@packetizer.com, barry.dingle@bigfoot.com.au, mgarakan@cisco.com, oran@cisco.com To: Henry Sinnreich From: Rohan Mahy In-Reply-To: <000301c34a13$17379ae0$8ab8a051@hsinnreich2> Message-Id: <048847A9-B60B-11D7-9589-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: Time/place for BOF on Real-Time Text Conversation in SIP Telephony Devices Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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, July 14, 2003, at 07:20 AM, Henry Sinnreich wrote: > The BOF .... the *Adhoc* will take place at the place/time below. This is NOT an IETF BOF. See you then. thanks, -rohan > on Real-Time Text Conversation in SIP Telephony Devices will > take place Thursday July 17 in room J241/1 at 10:00-11:00 am CET. The > main objective is to discuss and vote on the attached items. > > Thanks, Henry > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 14 11: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 LAA28793 for ; Mon, 14 Jul 2003 11: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 19c5I9-0004Yh-IN for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 11:31:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EFV5xO017522 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 11:31:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c5I9-0004YX-DK for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 11:31: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 LAA28727 for ; Mon, 14 Jul 2003 11:31:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c5I8-0001bV-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 11:31:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c5I7-0001bS-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 11:31:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c5I7-0004XX-8Z; Mon, 14 Jul 2003 11:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c5Hs-0004WX-8D for sipping@optimus.ietf.org; Mon, 14 Jul 2003 11:30:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28688 for ; Mon, 14 Jul 2003 11:30:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c5Hr-0001ax-00 for sipping@ietf.org; Mon, 14 Jul 2003 11:30:47 -0400 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 19c5Hq-0001ZT-00 for sipping@ietf.org; Mon, 14 Jul 2003 11:30:46 -0400 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 1845; Mon, 14 Jul 2003 11:29:41 -0400 (EDT) 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] How to report DTMF - conclusion of the app interaction design team: SIP MESSAGE Date: Mon, 14 Jul 2003 11:30:13 -0400 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F6562@zoe.office.snowshore.com> Thread-Topic: [Sipping] How to report DTMF - conclusion of the app interaction design team: SIP MESSAGE Thread-Index: AcNKDrLyKGtBRSA9Ro6Rinzym+Ww4QADdgeA From: "Eric Burger" To: "Adam Roach" , "Jonathan Rosenberg" , "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 That is incredibly sensible. Sounds like time for a dip into the well of method space for a new = method name. Can we get away with, "just like MESSAGE, but without the = user interaction expectations"? That is what it is, after all. > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Mon, July 14, 2003 9:47 AM > To: Jonathan Rosenberg; sipping > Subject: RE: [Sipping] How to report DTMF - conclusion of the app > interaction design team: SIP MESSAGE >=20 >=20 > > 7. SIP MESSAGE > >=20 > > Send a SIP MESSAGE request from the client to the application,=20 > > containing the digit sequence to report. > >=20 > > This was a bit of a bending of the semantic of MESSAGE, which is=20 > > really meant for conveying information for display to a user.=20 > > However, the issue is mostly philosophical in nature. We didn't > > see any particular technical issue that would prevent this from > > working, unlike all of the above ones which had technical issues. >=20 > If we're throwing philosophical objections about the intended > semantics of a method out the window, I'm left wondering why > MESSAGE was selected over OPTIONS for this purpose. >=20 > All other things being equal, receipt of a misdirected OPTIONS > will never have harmful effects; meanwhile, receipt of a > MESSAGE with an unrecognized content type has an extremely > high probability of causing a nonzero number of implementations > to pop up a window saying something like: >=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 > This is what I most emphatically do *not* want to happen. It is > the key reason that I push back against use of MESSAGE for > anything that is not to be rendered to a user, and it is a > proof point that the objections to abusing MESSAGE for general > purpose RPC go beyond philosophy into user experience. >=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 >=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 From exim@www1.ietf.org Mon Jul 14 12:16: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 LAA28517 for ; Mon, 14 Jul 2003 11:29: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 19c5GN-0003uD-Lm for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 11:29:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EFTF9o014994 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 11:29:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c5GN-0003td-Fz for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 11:29: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 LAA28417 for ; Mon, 14 Jul 2003 11:29:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c5GE-0001WP-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 11:29:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c5GD-0001WL-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 11:29:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c5GA-0003pU-Mk; Mon, 14 Jul 2003 11:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c21n-0000hR-7P for sipping@optimus.ietf.org; Mon, 14 Jul 2003 08:01: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 IAA13721 for ; Mon, 14 Jul 2003 08:01:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c21m-00064z-00 for sipping@ietf.org; Mon, 14 Jul 2003 08:01:58 -0400 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by ietf-mx with esmtp (Exim 4.12) id 19c21l-00063o-00 for sipping@ietf.org; Mon, 14 Jul 2003 08:01:57 -0400 Received: from dgismtp06.wcomnet.com ([166.38.58.89]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HI00025HJVHGU@firewall.wcom.com> for sipping@ietf.org; Mon, 14 Jul 2003 11:57:17 +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 <0HI000G01JVGSN@dgismtp06.wcomnet.com>; Mon, 14 Jul 2003 11:57:17 +0000 (GMT) Received: from hsinnreich2 ([166.50.112.151]) by dgismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HI000DFSJV6BP@dgismtp06.wcomnet.com>; Mon, 14 Jul 2003 11:57:16 +0000 (GMT) Date: Mon, 14 Jul 2003 13:57:00 +0200 From: Henry Sinnreich Subject: RE: [Sipping] RE: items for vor voting in the BOF In-reply-to: <000c01c349ea$98bc2d70$28c81844@USD320002X> To: gv@trace.wisc.edu, guido.gybels@rnid.org.uk Cc: "'Henry Sinnreich'" , "'Gunnar Hellstrom'" , mike.spanner@rnid.org.uk, 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, paulej@packetizer.com, barry.dingle@bigfoot.com.au, mgarakan@cisco.com, oran@cisco.com, rohan@cisco.com, sipping@ietf.org Message-id: <000401c349ff$10f8ba10$8ab8a051@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: multipart/mixed; boundary="Boundary_(ID_yxnS3Ee9EU7VF5zI0urf5w)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_yxnS3Ee9EU7VF5zI0urf5w) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Gunnar won't be there -- so I was wondering (from the person > that will be presenting this) what form would be presented. I plan to present the .pdf file that was mailed out and hope to do the best we can. As mentioned, we still have no room for the BOF, as yet. The main issue it seems, is we have stumbled upon a vry complex topic, as this mail trail shows and much more work needs to be done for the interactive text service. I don't expect this to be solved in the BOF, but just get some hooks for it into SIP phones, in a reasonable manner. As you know, reasonable people can differ on what reasonable means... Having to pay attention to the IETF meetings in progress, I excuse myself from this mail trail for now and may not be able to follow and respond. Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of Gregg Vanderheiden > Sent: Monday, July 14, 2003 11:30 AM > To: guido.gybels@rnid.org.uk > Cc: 'Henry Sinnreich'; 'Gunnar Hellstrom'; > mike.spanner@rnid.org.uk; 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; > paulej@packetizer.com; barry.dingle@bigfoot.com.au; > mgarakan@cisco.com; oran@cisco.com; rohan@cisco.com; sipping@ietf.org > Subject: [Sipping] RE: items for vor voting in the BOF > > > Is Gunnar's the version that will be used? > > Did you mean the BCP document? > Or an earlier doc? (I looked and couldn't find one - that > wasn't comments > on comments. > > Gunnar won't be there -- so I was wondering (from the person > that will be presenting this) what form would be presented. > > thx > > Gregg > > -- ------------------------------ > Gregg C Vanderheiden Ph.D. > Professor - Ind. Engr. & BioMed Engr. > Director - Trace R & D Center > University of Wisconsin-Madison > > -----Original Message----- > From: Guido Gybels [mailto:ggybels@webclient.eu.blackberry.net] > Sent: Monday, July 14, 2003 3:48 AM > To: gv@trace.wisc.edu > Cc: 'Henry Sinnreich'; 'Gunnar Hellstrom'; > Guido.Gybels@rnid.org.uk; mike.spanner@rnid.org.uk; > andreas.piirimets@omnitor.se; gv@trace.wisc.edu; > trefor@trefor.plus.com; 'Rajesh Kumar'; marcelo@envilogg.se; > jorgen.bjorkner@hotsip.com; 'James Hamlin'; > Erik.Zetterstrom@omnitor.se; hwildfeu@cisco.com; > paulej@packetizer.com; barry.dingle@bigfoot.com.au; > mgarakan@cisco.com; oran@cisco.com; rohan@cisco.com; sipping@ietf.org > Subject: RE: items for vor voting in the BOF > > Gregg, > > I think Gunnar's version was quite clear and straight > forward, I don't think we should complicate things any > further. So, I would suggest we use Gunnar's version. > > Guido > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sip@ietf.org for new developments of core SIP > --Boundary_(ID_yxnS3Ee9EU7VF5zI0urf5w) Content-type: application/pdf; name="Real-time Text Conversation in SIP Telephony Devices.pdf" Content-disposition: attachment; filename="Real-time Text Conversation in SIP Telephony Devices.pdf" Content-Transfer-Encoding: quoted-printable %PDF-1.3=0A= =0A= 1 0 obj=0A= <<=0A= /Producer (BCL's EasyPDF)=0A= >>=0A= endobj=0A= =0A= 3 0 obj=0A= <<=0A= /Count 0=0A= >>=0A= endobj=0A= =0A= 2 0 obj=0A= <<=0A= /Type /Catalog=0A= /Pages 4 0 R=0A= /Outlines 3 0 R=0A= >>=0A= endobj=0A= =0A= 7 0 obj=0A= [=0A= 806 806 806 806 806 806 806 806 806 806 806 806 806 806 = 806 806 =0A= 806 806 806 806 806 806 806 806 806 806 806 806 806 806 = 806 806 =0A= 298 298 381 597 597 955 716 205 358 358 418 627 298 358 = 298 298 =0A= 597 597 597 597 597 597 597 597 597 597 298 298 627 627 = 627 597 =0A= 1090 716 716 776 776 716 656 835 776 298 537 716 597 895 = 776 835 =0A= 716 835 776 716 656 776 716 1014 716 716 656 298 298 298 = 504 597 =0A= 358 597 597 537 597 597 298 597 597 239 239 537 239 895 = 597 597 =0A= 597 597 358 537 298 597 537 776 537 537 537 359 279 359 = 627 806 =0A= 597 806 239 597 358 1074 597 597 358 1074 716 358 1074 806 = 656 806 =0A= 806 239 239 358 358 376 597 1074 358 1074 537 358 1014 806 = 537 716 =0A= 298 358 597 597 597 597 279 597 358 791 398 597 627 358 = 791 593 =0A= 429 589 358 358 358 619 577 298 358 358 392 597 896 896 = 896 656 =0A= 716 716 716 716 716 716 1074 776 716 716 716 716 298 298 = 298 298 =0A= 776 776 835 835 835 835 835 627 835 776 776 776 776 716 = 716 656 =0A= 597 597 597 597 597 597 955 537 597 597 597 597 298 298 = 298 298 =0A= 597 597 597 597 597 597 597 589 656 597 597 597 597 537 = 597 537 =0A= ]=0A= endobj=0A= =0A= 9 0 obj=0A= <<=0A= /Length 10 0 R=0A= /Filter [/ASCII85Decode /FlateDecode]=0A= >>=0A= stream=0A= GhTQ,gMS6)&:O:So]*<7BBR^0)2&Q(Fp#?c!Gr5X@X2p%419+p0Qsbghc$GQVl/q#apLN\NI.= O@=0A= eYc05Wig4,S[.,6Pu583nM[g5s*"!2OghGC>,*,t\sq)V<%.ZCoAsNTihEf[XRikM)fO8;0rg= eh=0A= X/;OSja:qS[jJH/n!V_GAfd#HY,Z;pQ?ok=3DHBk0=3DO(KY>O?4j;S)Gkd=3DdX3A'A7fcYkOdMr>U;*mc]5X2C/B= >#RQW.m/T<=0A= C,Ih$[5Zd.TCJ_:)VLYt=3DjOAN*VN`IjfLFI-@J3R]ttaIklHjqFZdl#_1J165[7KV2Zgt.C= AK8E=0A= nWc",2UePG\uBjq[NMO'CqS6*bZ6uWK0Fa+Et$uff=3DESC?'UEqP7(N.Nn+;[2"%_"l(($;`= PW(b=0A= ;51&(:69UcO3=3DD6Z?P"[fe5>b,sG,OH?#pTcb;p@-gaOjrW1iYZ= kXYs=0A= !p;FEl[*JPZJ$(G^:M5W%WJ`6p06n"6hu/4E3():n*tj^R= c<=0A= [SO`=3D&rTL-l[c.^5%kAIAWq,>$O*.uK!5$S*k[CHD+"(1.q\kflCS-%ohdYSOSa\3"B6Cn2= PC+t=0A= O8UJh%A4,klp"0R`6P*@\4)@c63E7t2-pf;$fNXS3=3DF-,k;)U]Xgs2n2mJ":-U]jp;c\521= eWro=0A= ^j-Kg*)3*5sEF8H$C.#:N7Xr#'un":G!(:1LOCVMM"-)HLK(Y0\c=3D,U"6;XR= MCJm=0A= E&GPqWuV8.RC/X'B(7+b,Xd]-\;[?lb6B^V$Ccjq4CXZXeMAJn22b,M+HQ2e"= g"=0A= -UGZ^n]=3DnLR)H'P'$FqQ(cO5<=3Dm;^D,5BTY_Y]G31$X-.Lm9tg$``ur= *Y!RY'=0A= 7?,C4lUZ,BL&)=3DFOplf;gD7B\+A6lS6??$2>u[cK=3D2I!u_K/OB(8eCQ0q3KS(Ps(D^"@N= =3DdsaZ/=0A= Itf4(AR[:FU?a.`?SZ:1X-^Gna&(o`dC\p\TK[f1-duW(7[@[$$+JrT4EV>tEHXT>puR\174:,p6_VrQ(sS(<*= n0=0A= YuFLJ*](X?O0sYg&dJE+0fp\62!KrL&dbUaE)rS:pWpt?s,j'(.#@F4a)BsW;ebJ&GUP.%8rJ= V'=0A= m'AP7LH:2r%'CHE0\fEbFQ>%JZ@2rrQS:mWM1*>XQI-p-]@#= k_!o=0A= 4^oQRh!:C:]!dZuUrC\pJGE%,)L%W9P;[EqlbN7J7t$9k:AZrm4jMAO:`cIe=3Dh#Hu4.du:,= -eFY=0A= *pMm:SA_#Pp@Y'FlbEFN&TXB.>q1!6UY=0A= endstream=0A= endobj=0A= =0A= 10 0 obj=0A= 1897=0A= endobj=0A= =0A= 6 0 obj=0A= <<=0A= /Type /Page=0A= /Parent 4 0 R=0A= /MediaBox [ 0 0 792 612 ]=0A= /Resources <<=0A= /Font 5 0 R=0A= /ProcSet [/PDF /Text /ImageB /ImageC] >>=0A= /Contents 9 0 R=0A= >>=0A= endobj=0A= =0A= 4 0 obj=0A= <<=0A= /Type /Pages=0A= /Kids [=0A= 6 0 R=0A= ]=0A= /Count 1=0A= >>=0A= endobj=0A= =0A= 8 0 obj=0A= <<=0A= /Type /FontDescriptor=0A= /Ascent 972=0A= /CapHeight 1200=0A= /Descent 228=0A= /Flags 32=0A= /FontBBox [0 -228 2892 972]=0A= /FontName /ArialMT=0A= /ItalicAngle 0=0A= /StemV 0=0A= >>=0A= endobj=0A= =0A= 5 0 obj=0A= <<=0A= /F1 << /Type /Font /Subtype /Type1 /BaseFont /Courier >>=0A= /F2 << /Type /Font /Subtype /Type1 /BaseFont /Courier-Bold >>=0A= /F3 << /Type /Font /Subtype /Type1 /BaseFont /Courier-BoldOblique >>=0A= /F4 << /Type /Font /Subtype /Type1 /BaseFont /Courier-Oblique >>=0A= /F5 << /Type /Font /Subtype /Type1 /BaseFont /Helvetica >>=0A= /F6 << /Type /Font /Subtype /Type1 /BaseFont /Helvetica-Bold >>=0A= /F7 << /Type /Font /Subtype /Type1 /BaseFont /Helvetica-BoldOblique >>=0A= /F8 << /Type /Font /Subtype /Type1 /BaseFont /Helvetica-Oblique >>=0A= /F9 << /Type /Font /Subtype /Type1 /BaseFont /Times-Roman >>=0A= /F10 << /Type /Font /Subtype /Type1 /BaseFont /Times-Bold >>=0A= /F11 << /Type /Font /Subtype /Type1 /BaseFont /Times-Italic >>=0A= /F12 << /Type /Font /Subtype /Type1 /BaseFont /Times-BoldItalic >>=0A= /F13 << /Type /Font /Subtype /Type1 /BaseFont /Symbol >>=0A= /F14 << /Type /Font /Subtype /Type1 /BaseFont /ZapfDingbats >>=0A= /F15=0A= <<=0A= /Type /Font=0A= /Subtype /TrueType=0A= /BaseFont /ArialMT=0A= /Encoding /WinAnsiEncoding=0A= /FirstChar 0=0A= /LastChar 255=0A= /FontDescriptor 8 0 R=0A= /Widths 7 0 R=0A= >>=0A= >>=0A= endobj=0A= =0A= xref=0A= 0 11=0A= 0000000000 65535 f =0A= 0000000010 00000 n =0A= 0000000089 00000 n =0A= 0000000058 00000 n =0A= 0000003631 00000 n =0A= 0000003857 00000 n =0A= 0000003474 00000 n =0A= 0000000155 00000 n =0A= 0000003691 00000 n =0A= 0000001464 00000 n =0A= 0000003452 00000 n =0A= trailer=0A= <<=0A= /Size 11=0A= /Root 2 0 R=0A= /Info 1 0 R=0A= >>=0A= startxref=0A= 4916=0A= %%EOF=0A= --Boundary_(ID_yxnS3Ee9EU7VF5zI0urf5w)-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 14 14:06: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 OAA09503 for ; Mon, 14 Jul 2003 14:06: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 19c7iB-00064Q-AU for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 14:06:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EI67cq023330 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 14: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 19c7iB-00064D-7W for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 14:06: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 OAA09489 for ; Mon, 14 Jul 2003 14:06:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7i8-0004Fc-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 14:06:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c7i8-0004FZ-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 14:06:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7i6-00063L-30; Mon, 14 Jul 2003 14: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 19c7hX-000632-6y for sipping@optimus.ietf.org; Mon, 14 Jul 2003 14:05: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 OAA09470 for ; Mon, 14 Jul 2003 14:05:24 -0400 (EDT) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7hU-0004FV-00 for sipping@ietf.org; Mon, 14 Jul 2003 14:05:24 -0400 Received: from imo-m02.mx.aol.com ([64.12.136.5]) by ietf-mx with esmtp (Exim 4.12) id 19c7hU-0004FM-00 for sipping@ietf.org; Mon, 14 Jul 2003 14:05:24 -0400 Received: from Mpierce1@aol.com by imo-m02.mx.aol.com (mail_out_v36_r1.1.) id 7.5a.1f5113cc (3964); Mon, 14 Jul 2003 14:04:44 -0400 (EDT) Message-ID: <5a.1f5113cc.2c444abc@aol.com> Date: Mon, 14 Jul 2003 14:04:44 EDT Subject: Re: [Sipping] New Tones draft (was: "who plays the tone" or something like th... To: eburger@snowshore.com, sipping@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_5a.1f5113cc.2c444abc_boundary" X-Mailer: 6.0 for Windows XP sub 10500 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --part1_5a.1f5113cc.2c444abc_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 7/14/2003 11:11:46 AM Eastern Daylight Time, eburger@snowshore.com writes: > think direction 1 (user agent to user) is the only sensible thing for this > draft. I guess that presupposes the whole idea is sensible in the first > place Z-) > I believe that being able to tell the UA to send the tone in either direction or both is a basic requirement. If not included now, we'll be sorry later. I believe it is easy to find cases for the use of each. Mike Pierce --part1_5a.1f5113cc.2c444abc_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 7/14/2= 003 11:11:46 AM Eastern Daylight Time, eburger@snowshore.com writes:


think direction 1 (user ag= ent to user) is the only sensible thing for this draft.  I guess that p= resupposes the whole idea is sensible in the first place Z-)



I believe that being able to tell the UA to send the tone in either dire= ction or both is a basic requirement. If not included now, we'll be sorry la= ter. I believe it is easy to find cases for the use of each.

Mike Pierce
--part1_5a.1f5113cc.2c444abc_boundary-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Jul 14 14:47: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 OAA13563 for ; Mon, 14 Jul 2003 14:47: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 19c8Ls-0001Yu-PA for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 14:47:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EIl8q7005998 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 14:47:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c8Ls-0001Yf-M3 for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 14:47: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 OAA13514 for ; Mon, 14 Jul 2003 14:47:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c8Lp-0005GQ-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 14:47:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c8Lo-0005GK-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 14: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 19c8Ln-0001Wi-EI; Mon, 14 Jul 2003 14:47:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c8Lh-0001W6-4t for sipping@optimus.ietf.org; Mon, 14 Jul 2003 14:46: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 OAA13490 for ; Mon, 14 Jul 2003 14:46:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c8Le-0005G3-00 for sipping@ietf.org; Mon, 14 Jul 2003 14:46:54 -0400 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 19c8Ld-0005FJ-00 for sipping@ietf.org; Mon, 14 Jul 2003 14:46:53 -0400 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 1861; Mon, 14 Jul 2003 14:45:48 -0400 (EDT) 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] How to report DTMF - conclusion of the app interaction design team: SIP MESSAGE Date: Mon, 14 Jul 2003 14:46:22 -0400 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F656D@zoe.office.snowshore.com> Thread-Topic: [Sipping] How to report DTMF - conclusion of the app interaction design team: SIP MESSAGE Thread-Index: AcNKDrLyKGtBRSA9Ro6Rinzym+Ww4QADdgeAAAa5J0A= From: "Eric Burger" To: "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 Hmmm. Alan pointed out that would be equivalent to INFO. You know, the = application-to-application signaling message. > -----Original Message----- > From: Eric Burger=20 > Sent: Mon, July 14, 2003 11:30 AM > To: Adam Roach; Jonathan Rosenberg; sipping > Subject: RE: [Sipping] How to report DTMF - conclusion of the app > interaction design team: SIP MESSAGE >=20 >=20 > That is incredibly sensible. >=20 > Sounds like time for a dip into the well of method space for=20 > a new method name. Can we get away with, "just like MESSAGE,=20 > but without the user interaction expectations"? That is what=20 > it is, after all. >=20 > > -----Original Message----- > > From: Adam Roach [mailto:adam@dynamicsoft.com] > > Sent: Mon, July 14, 2003 9:47 AM > > To: Jonathan Rosenberg; sipping > > Subject: RE: [Sipping] How to report DTMF - conclusion of the app > > interaction design team: SIP MESSAGE > >=20 > >=20 > > > 7. SIP MESSAGE > > >=20 > > > Send a SIP MESSAGE request from the client to the application,=20 > > > containing the digit sequence to report. > > >=20 > > > This was a bit of a bending of the semantic of MESSAGE, which is=20 > > > really meant for conveying information for display to a user.=20 > > > However, the issue is mostly philosophical in nature. We didn't > > > see any particular technical issue that would prevent this from > > > working, unlike all of the above ones which had technical issues. > >=20 > > If we're throwing philosophical objections about the intended > > semantics of a method out the window, I'm left wondering why > > MESSAGE was selected over OPTIONS for this purpose. > >=20 > > All other things being equal, receipt of a misdirected OPTIONS > > will never have harmful effects; meanwhile, receipt of a > > MESSAGE with an unrecognized content type has an extremely > > high probability of causing a nonzero number of implementations > > to pop up a window saying something like: > >=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 > > This is what I most emphatically do *not* want to happen. It is > > the key reason that I push back against use of MESSAGE for > > anything that is not to be rendered to a user, and it is a > > proof point that the objections to abusing MESSAGE for general > > purpose RPC go beyond philosophy into user experience. > >=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 > >=20 > >=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 >=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 From exim@www1.ietf.org Mon Jul 14 14: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 OAA13582 for ; Mon, 14 Jul 2003 14:47: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 19c8Ls-0001Ye-LO for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 14:47:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EIl8Mn005982 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 14:47:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c8Ls-0001YP-Fk for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 14:47: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 OAA13511 for ; Mon, 14 Jul 2003 14:47:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c8Lp-0005GN-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 14:47:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c8Lo-0005GJ-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 14: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 19c8Lm-0001WY-NN; Mon, 14 Jul 2003 14: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 19c8Lg-0001W1-7Q for sipping@optimus.ietf.org; Mon, 14 Jul 2003 14:46: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 OAA13487 for ; Mon, 14 Jul 2003 14:46:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c8Ld-0005Fu-00 for sipping@ietf.org; Mon, 14 Jul 2003 14:46:53 -0400 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 19c8Lc-0005FJ-00 for sipping@ietf.org; Mon, 14 Jul 2003 14:46:52 -0400 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 1861; Mon, 14 Jul 2003 14:45:47 -0400 (EDT) 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] New Tones draft (was: "who plays the tone" or something like th... Date: Mon, 14 Jul 2003 14:46:21 -0400 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F656C@zoe.office.snowshore.com> Thread-Topic: [Sipping] New Tones draft (was: "who plays the tone" or something like th... Thread-Index: AcNKMm1DJJkOnlC8RVq/tKV4eKaLUwAAzLNg From: "Eric Burger" To: , 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 Wouldn't the reverse direction just be another target for another tone? = For example, what if the indicator tone was different in different = countries, per Q.35? -----Original Message----- From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: Mon, July 14, 2003 2:05 PM To: Eric Burger; sipping@ietf.org Subject: Re: [Sipping] New Tones draft (was: "who plays the tone" or = something like th... In a message dated 7/14/2003 11:11:46 AM Eastern Daylight Time, = eburger@snowshore.com writes:=20 think direction 1 (user agent to user) is the only sensible thing for = this draft. I guess that presupposes the whole idea is sensible in the = first place Z-)=20 I believe that being able to tell the UA to send the tone in either = direction or both is a basic requirement. If not included now, we'll be = sorry later. I believe it is easy to find cases for the use of each.=20 Mike Pierce=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 Mon Jul 14 15:11: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 PAA16403 for ; Mon, 14 Jul 2003 15:11: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 19c8j4-0003ND-36 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 15:11:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EJB65h012961 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 15:11:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c8j2-0003My-I6 for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 15:11: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 PAA16302 for ; Mon, 14 Jul 2003 15:11:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c8iz-0005ol-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 15:11:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c8iy-0005oi-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 15:11:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c8iz-0003Ll-EJ; Mon, 14 Jul 2003 15:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c8iL-0003C5-Sz for sipping@optimus.ietf.org; Mon, 14 Jul 2003 15:10: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 PAA16179 for ; Mon, 14 Jul 2003 15:10:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c8iI-0005nT-00 for sipping@ietf.org; Mon, 14 Jul 2003 15:10:18 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19c8iH-0005n3-00 for sipping@ietf.org; Mon, 14 Jul 2003 15:10:17 -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 h6EJ9lE5007255; Mon, 14 Jul 2003 15:09:47 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jul 2003 14:09:46 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E861FD@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Eric Burger'" , sipping Subject: RE: [Sipping] How to report DTMF - conclusion of the app interact ion design team: SIP MESSAGE Date: Mon, 14 Jul 2003 14:09: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: , Yes, except without the "in a dialog" requirement. You could call it "CALL" (borrowing the term from RFC 1057). More realistically, a specific new method (say, FEEDBACK) that has semantics of collecting input from a user would seem to be a well-scoped and reasonable way to go about sending this information. /a > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: Monday, July 14, 2003 13:46 > To: sipping > Subject: RE: [Sipping] How to report DTMF - conclusion of the app > interaction design team: SIP MESSAGE > > > Hmmm. Alan pointed out that would be equivalent to INFO. > You know, the application-to-application signaling message. > > > -----Original Message----- > > From: Eric Burger > > Sent: Mon, July 14, 2003 11:30 AM > > To: Adam Roach; Jonathan Rosenberg; sipping > > Subject: RE: [Sipping] How to report DTMF - conclusion of the app > > interaction design team: SIP MESSAGE > > > > > > That is incredibly sensible. > > > > Sounds like time for a dip into the well of method space for > > a new method name. Can we get away with, "just like MESSAGE, > > but without the user interaction expectations"? That is what > > it is, after all. > > > > > -----Original Message----- > > > From: Adam Roach [mailto:adam@dynamicsoft.com] > > > Sent: Mon, July 14, 2003 9:47 AM > > > To: Jonathan Rosenberg; sipping > > > Subject: RE: [Sipping] How to report DTMF - conclusion of the app > > > interaction design team: SIP MESSAGE > > > > > > > > > > 7. SIP MESSAGE > > > > > > > > Send a SIP MESSAGE request from the client to the application, > > > > containing the digit sequence to report. > > > > > > > > This was a bit of a bending of the semantic of MESSAGE, > which is > > > > really meant for conveying information for display to a user. > > > > However, the issue is mostly philosophical in nature. We didn't > > > > see any particular technical issue that would prevent this from > > > > working, unlike all of the above ones which had > technical issues. > > > > > > If we're throwing philosophical objections about the intended > > > semantics of a method out the window, I'm left wondering why > > > MESSAGE was selected over OPTIONS for this purpose. > > > > > > All other things being equal, receipt of a misdirected OPTIONS > > > will never have harmful effects; meanwhile, receipt of a > > > MESSAGE with an unrecognized content type has an extremely > > > high probability of causing a nonzero number of implementations > > > to pop up a window saying something like: > > > > > > +------------------------------------------------------------+ > > > | 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] | > > > +------------------------------------------------------------+ > > > > > > This is what I most emphatically do *not* want to happen. It is > > > the key reason that I push back against use of MESSAGE for > > > anything that is not to be rendered to a user, and it is a > > > proof point that the objections to abusing MESSAGE for general > > > purpose RPC go beyond philosophy into user experience. > > > > > > /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 > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 Jul 14 15:27: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 PAA18386 for ; Mon, 14 Jul 2003 15:27: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 19c8yZ-0004Q0-PF for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 15:27:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EJR7GS016985 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 15:27:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c8yZ-0004Ps-ES for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 15:27: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 PAA18354 for ; Mon, 14 Jul 2003 15:27:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c8yY-0006Bv-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 15:27:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c8yX-0006Bs-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 15:27:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c8yT-0004Ol-Lo; Mon, 14 Jul 2003 15: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 19c8y0-0004La-G9 for sipping@optimus.ietf.org; Mon, 14 Jul 2003 15:26: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 PAA18247 for ; Mon, 14 Jul 2003 15:26:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c8xz-0006AH-00 for sipping@ietf.org; Mon, 14 Jul 2003 15:26:31 -0400 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 19c8xy-00069O-00 for sipping@ietf.org; Mon, 14 Jul 2003 15:26:30 -0400 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 1873; Mon, 14 Jul 2003 15:25:24 -0400 (EDT) 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] How to report DTMF - conclusion of the app interaction design team: SIP MESSAGE Date: Mon, 14 Jul 2003 15:25:59 -0400 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F656F@zoe.office.snowshore.com> Thread-Topic: [Sipping] How to report DTMF - conclusion of the app interaction design team: SIP MESSAGE Thread-Index: AcNKO5gGpDDcpydNTlGtfhDLHjYdxgAAZBUw From: "Eric Burger" To: "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 I like it -- say what we mean. > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Mon, July 14, 2003 3:10 PM > To: Eric Burger; sipping > Subject: RE: [Sipping] How to report DTMF - conclusion of the app > interaction design team: SIP MESSAGE >=20 >=20 > Yes, except without the "in a dialog" requirement. You could > call it "CALL" (borrowing the term from RFC 1057). >=20 > More realistically, a specific new method (say, FEEDBACK) that > has semantics of collecting input from a user would seem to be > a well-scoped and reasonable way to go about sending this > information. >=20 > /a >=20 >=20 > > -----Original Message----- > > From: Eric Burger [mailto:eburger@snowshore.com] > > Sent: Monday, July 14, 2003 13:46 > > To: sipping > > Subject: RE: [Sipping] How to report DTMF - conclusion of the app > > interaction design team: SIP MESSAGE > >=20 > >=20 > > Hmmm. Alan pointed out that would be equivalent to INFO. =20 > > You know, the application-to-application signaling message. > >=20 > > > -----Original Message----- > > > From: Eric Burger=20 > > > Sent: Mon, July 14, 2003 11:30 AM > > > To: Adam Roach; Jonathan Rosenberg; sipping > > > Subject: RE: [Sipping] How to report DTMF - conclusion of the app > > > interaction design team: SIP MESSAGE > > >=20 > > >=20 > > > That is incredibly sensible. > > >=20 > > > Sounds like time for a dip into the well of method space for=20 > > > a new method name. Can we get away with, "just like MESSAGE,=20 > > > but without the user interaction expectations"? That is what=20 > > > it is, after all. > > >=20 > > > > -----Original Message----- > > > > From: Adam Roach [mailto:adam@dynamicsoft.com] > > > > Sent: Mon, July 14, 2003 9:47 AM > > > > To: Jonathan Rosenberg; sipping > > > > Subject: RE: [Sipping] How to report DTMF - conclusion=20 > of the app > > > > interaction design team: SIP MESSAGE > > > >=20 > > > >=20 > > > > > 7. SIP MESSAGE > > > > >=20 > > > > > Send a SIP MESSAGE request from the client to the=20 > application,=20 > > > > > containing the digit sequence to report. > > > > >=20 > > > > > This was a bit of a bending of the semantic of MESSAGE,=20 > > which is=20 > > > > > really meant for conveying information for display to a user.=20 > > > > > However, the issue is mostly philosophical in nature.=20 > We didn't > > > > > see any particular technical issue that would prevent=20 > this from > > > > > working, unlike all of the above ones which had=20 > > technical issues. > > > >=20 > > > > If we're throwing philosophical objections about the intended > > > > semantics of a method out the window, I'm left wondering why > > > > MESSAGE was selected over OPTIONS for this purpose. > > > >=20 > > > > All other things being equal, receipt of a misdirected OPTIONS > > > > will never have harmful effects; meanwhile, receipt of a > > > > MESSAGE with an unrecognized content type has an extremely > > > > high probability of causing a nonzero number of implementations > > > > to pop up a window saying something like: > > > >=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 > > > > This is what I most emphatically do *not* want to happen. It is > > > > the key reason that I push back against use of MESSAGE for > > > > anything that is not to be rendered to a user, and it is a > > > > proof point that the objections to abusing MESSAGE for general > > > > purpose RPC go beyond philosophy into user experience. > > > >=20 > > > > /a > > > >=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 > >=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 >=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 From exim@www1.ietf.org Mon Jul 14 15:47: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 PAA20237 for ; Mon, 14 Jul 2003 15:47: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 19c9Ht-0005ks-Oa for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 15:47:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EJl59t022116 for sipping-archive@odin.ietf.org; Mon, 14 Jul 2003 15:47:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c9Ht-0005kd-8x for sipping-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 15:47: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 PAA20198 for ; Mon, 14 Jul 2003 15:47:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c9Hr-0006cX-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 15:47:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c9Hr-0006cU-00 for sipping-web-archive@ietf.org; Mon, 14 Jul 2003 15:47:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c9Hp-0005jg-Ei; Mon, 14 Jul 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 19c9Hi-0005jN-U6 for sipping@optimus.ietf.org; Mon, 14 Jul 2003 15:46: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 PAA20184 for ; Mon, 14 Jul 2003 15:46:52 -0400 (EDT) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c9Hh-0006cE-00 for sipping@ietf.org; Mon, 14 Jul 2003 15:46:53 -0400 Received: from imo-m05.mx.aol.com ([64.12.136.8]) by ietf-mx with esmtp (Exim 4.12) id 19c9Hg-0006bS-00 for sipping@ietf.org; Mon, 14 Jul 2003 15:46:52 -0400 Received: from Mpierce1@aol.com by imo-m05.mx.aol.com (mail_out_v36_r1.1.) id 7.1a4.17579820 (30960); Mon, 14 Jul 2003 15:46:05 -0400 (EDT) Message-ID: <1a4.17579820.2c44627c@aol.com> Date: Mon, 14 Jul 2003 15:46:04 EDT Subject: Re: [Sipping] New Tones draft (was: "who plays the tone" or something like th... To: eburger@snowshore.com, sipping@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_1a4.17579820.2c44627c_boundary" X-Mailer: 6.0 for Windows XP sub 10500 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --part1_1a4.17579820.2c44627c_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 7/14/2003 2:48:07 PM Eastern Daylight Time, eburger@snowshore.com writes: > Wouldn't the reverse direction just be another target for another tone? > For example, what if the indicator tone was different in different countries, > per Q.35? > Not sure what your comment is. The thing being discussed is the contents of the data (XML) being sent to a specific end device ("terminal" or "UA") to tell it to inject a tone to someone. It needs to include something like: (I'm not an XML expert.) Mike Pierce --part1_1a4.17579820.2c44627c_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 7/14/2= 003 2:48:07 PM Eastern Daylight Time, eburger@snowshore.com writes:


Wouldn't the reverse direct= ion just be another target for another tone?  For example, what if the=20= indicator tone was different in different countries, per Q.35?


Not sure what your comment is. The thing being discussed is the contents= of the data (XML) being sent to a specific end device ("terminal" or "UA")=20= to tell it to inject a tone to someone. It needs to include something like:

           <x= s:element maxOccurs=3D"1" minOccurs=3D"1"
            = ;    name=3D"direction" type=3D"directionType"/>

     <xs:complexType name=3D"directionType"= >
        <xs:attribute name= =3D"type" use=3D"required">
           <x= s:simpleType>
            = ;  <xs:restriction base=3D"xs:string">
            = ;     <xs:enumeration value=3D"toLocal"/>
            = ;     <xs:enumeration value=3D"toFar"/>
            = ;     <xs:enumeration value=3D"toBoth"/>
            = ;  </xs:restriction>
           </= xs:simpleType>
        </xs:attribute>

(I'm not an XML expert.)

Mike Pierce
--part1_1a4.17579820.2c44627c_boundary-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Jul 15 00:23: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 AAA29825 for ; Tue, 15 Jul 2003 00:23: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 19cHLO-0005EE-Hc for sipping-archive@odin.ietf.org; Tue, 15 Jul 2003 00:23:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F4NEvD020098 for sipping-archive@odin.ietf.org; Tue, 15 Jul 2003 00:23:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cHLN-0005E5-U2 for sipping-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 00: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 AAA29770 for ; Tue, 15 Jul 2003 00:23:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cHLL-0000kj-00 for sipping-web-archive@ietf.org; Tue, 15 Jul 2003 00:23:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cHLK-0000kg-00 for sipping-web-archive@ietf.org; Tue, 15 Jul 2003 00:23:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cHLB-0005D2-9i; Tue, 15 Jul 2003 00: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 19cHKZ-0005Co-VW for sipping@optimus.ietf.org; Tue, 15 Jul 2003 00:22: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 AAA29708 for ; Tue, 15 Jul 2003 00:22:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cHKX-0000jJ-00 for sipping@ietf.org; Tue, 15 Jul 2003 00:22:21 -0400 Received: from dirty.research.bell-labs.com ([204.178.16.6]) by ietf-mx with esmtp (Exim 4.12) id 19cHKV-0000jE-00 for sipping@ietf.org; Tue, 15 Jul 2003 00:22:19 -0400 Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h6F4KsHa059844; Tue, 15 Jul 2003 00:20:54 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h6F4Kh1u014239; Tue, 15 Jul 2003 00:20:43 -0400 (EDT) Received: from bell-labs.com ([135.104.20.65]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h6F4KaQ4015925; Tue, 15 Jul 2003 00:20:37 -0400 (EDT) Message-ID: <3F13810F.4090100@bell-labs.com> Date: Tue, 15 Jul 2003 00:20:31 -0400 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg , sipping@ietf.org CC: "Miguel A. Garcia" Subject: Re: [Sipping] Comments on draft-ietf-sipping-session-policy-req-00 References: <3F000692.9000109@ericsson.com> <3F05CB0B.7060008@bell-labs.com> <3F127452.6010604@dynamicsoft.com> In-Reply-To: <3F127452.6010604@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: > I think what Miguel is saying is that they wouldnt need to change in the > middle of a call. In fact, the policies would be fairly static and would > change infrequently. When they do change, they don't need to do so > synchronous with any particular call attempt. In that case, you can use > mechanisms totally outside of a call. It becomes more of a provisioning > problem, and things like xcap would be more applicable. Yes, I totally agree. > The point Miguel is making, and its important one, is it wouldn't even > be on a call-by-call basis. > > This is really the first major issue we need to tackle (we'll discuss > during the sipping meeting today). Do we think session policies need to > be specified on a call-by-call basis? Certain policies tend to need to > be call-by-call. For example, using an intermediary for relaying media. > That needs to be call-by-call since the port to send to will be computed > on a call-by-call basis. Other policies, such as codecs to use, arguably > don't change much at all, and may not need to be computed on a > call-by-call basis. > > So, the question is whether we think there are two mechanisms - one > outside of a call, and one inside, or just one. One point to be made is > that, if you have a single in-call mechanism, that could be used to > cover both static and dynamic requirements. Thus, you would have just > one mechanism (thats good). But, it might be inefficient for wireless, > sending the same policeis to the UA over and over again (thats bad). > Then again, sigcomp might fix it (thats good). I haven't attended the SIPPING WG meeting so I apologize for raising something might have already been discussed. The call-by-call mechanism seems to be crucial for the use of policies since it is the only mechanism that can operate end-to-end, considering the policies of transit and destination networks. Besides this, I agree that there might be call-by-call policies (for example, include my networked recording server in all calls to my favorite used car dealer). A register-by-register mechanism seems to streamline the process in certain scenarios by supplying static policies. Since the destination of a call is unknown when the policy is set, the policies of transit or destination networks can't be taken into account and the call-by-call mechanism still needs to be invoked for all calls. However, the benefits of having this mechanism would be to avoid the repeated transmission of the same policy (although I agree that the gain can be rather small) and (maybe more important) to prevent the UAC from trying something that would be rejected anyway. This might save the client and the proxy an unsuccessful call attempt before the UAC considers the requested policy and call goes through. -- Volker -- Volker Hilt Bell Labs / Lucent Technologies phone: +1 732 332 6432 101 Crawfords Corner Rd email: volkerh@bell-labs.com Holmdel, NJ 07733 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 15 03:54: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 DAA01056 for ; Tue, 15 Jul 2003 03:54: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 19cKdU-000465-DC for sipping-archive@odin.ietf.org; Tue, 15 Jul 2003 03:54:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F7s85L015631 for sipping-archive@odin.ietf.org; Tue, 15 Jul 2003 03:54:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cKdU-00043t-0E for sipping-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 03:54: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 DAA00975 for ; Tue, 15 Jul 2003 03:54:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cKdR-0005YF-00 for sipping-web-archive@ietf.org; Tue, 15 Jul 2003 03:54:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cKdQ-0005YC-00 for sipping-web-archive@ietf.org; Tue, 15 Jul 2003 03:54:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cKdN-00042u-IO; Tue, 15 Jul 2003 03:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c8Fx-0000sa-Bt for sipping@optimus.ietf.org; Mon, 14 Jul 2003 14:41: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 OAA12958 for ; Mon, 14 Jul 2003 14:40:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c8Fu-00057F-00 for sipping@ietf.org; Mon, 14 Jul 2003 14:40:58 -0400 Received: from pxf01lhr.egham.rim.net ([193.109.81.7] helo=mhs01lhr.blackberry.net) by ietf-mx with esmtp (Exim 4.12) id 19c8Ft-00056Q-00 for sipping@ietf.org; Mon, 14 Jul 2003 14:40:57 -0400 Received: from mailrouter01.bwc.prod.uk.blackberry (mailrouter01.bwc.prod.uk.blackberry [172.16.80.216]) by mhs01lhr.blackberry.net (8.11.7+Sun/8.11.3) with ESMTP id h6EIeMe28088; Mon, 14 Jul 2003 19:40:22 +0100 (BST) Received: from imap01.eu.blackberry.net (imap01.eu.blackberry.net [172.16.80.224]) by mailrouter01.bwc.prod.uk.blackberry (8.12.8/8.12.8) with ESMTP id h6EIeKSt028718; Mon, 14 Jul 2003 18:40:21 GMT Received: from imap01.eu.blackberry.net (localhost.eu.blackberry.net [127.0.0.1]) by imap01.eu.blackberry.net (Mirapoint Messaging Server MOS 3.3.2-CR) with ESMTP id ABA02243; Mon, 14 Jul 2003 18:40:20 GMT Received: from 81.160.243.24 by imap01.eu.blackberry.net (Mirapoint Messaging Server MOS 3.3.2-CR) with HTTPS/1.1; Mon, 14 Jul 2003 19:40:20 +0100 Date: Mon, 14 Jul 2003 19:40:20 +0100 From: Guido Gybels Subject: Re: [Sipping] Update to caller preferences use cases To: sipping@ietf.org Cc: A.vWijk@viataal.nl, james.hamlin@rnid.org.uk, mike.spanner@rnid.org.uk, frank.shearar@rnid.org.uk, jdrosen@dynamicsoft.com Reply-To: guido.gybels@rnid.org.uk X-Mailer: Webmail Mirapoint Direct 3.3.2-CR MIME-Version: 1.0 Message-Id: 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 Jonathan: <<* added a hearing impaired use case>> First of all, I think it is extremely useful to have some use cases for deaf and hard of hearing people in the draft. Some comments/questions: 1) If I understand the case correctly, the relay service needs to issue a registration on behalf of the user, indicating that this registration accepts audio. One of the problems with that scenario is that this seems to suggest that the user must register through the relay in order to be able to receive incoming calls. I'm not so sure how practical that is, especially with regard to roaming users (how would they discover the relay in the network?). Some thoughts on this would be welcome. 2) The current version is slightly vague with regard to the type of text coming out of the relay. Using traditional messaging (IM) is not really an option for relay calls. I'd like to see a more explicit example of using RFC2793 character-by-character text coming from the relay, as that is likely to be what will be used in a real- world scenario. We have experimented at Typetalk with using IM for the interaction with the relay, but that has proven to be quite useless, as the conversation breaks down and the long pauzes and silences that result out of the message based interaction (as opposed to a continuous stream of text going back and forward) become extremely akward for both parties. Can I therefore suggest that this use case specifically mentions RTP T.140 text streams, rather just messaging. In fact, the deaf or hard of hearing user could register for both T.140 and IM, so that he/she can accept both those. If the hearing user want to set up an IM session, that will just succeed. If the call is rerouted through the relay, than it will connect a T.140 stream. 3) The current scenario is based on an incoming audio conversation, which certainly is a valid case. However, there is also the opposite possibility of making an outgoing call using T.140 but with a voice destination. In that case, again, the call needs to be routed through the relay. However, it seems unlikely that every hearing user will be registered with a relay service, so there is no registration for those hearing users, as hearing people cannot necessarily know in advance that they will be called by a deaf or hard of hearing person. So, can caller preferences deal with such a scenario? If yes, I would be grateful for a use case demonstrating this, otherwise we need suggestions on how to deal with such situations. As ever, 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 From exim@www1.ietf.org Tue Jul 15 05:56: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 FAA11745 for ; Tue, 15 Jul 2003 05:56: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 19cMX5-0003zt-Gp for sipping-archive@odin.ietf.org; Tue, 15 Jul 2003 05:55:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F9tdkt015359 for sipping-archive@odin.ietf.org; Tue, 15 Jul 2003 05:55:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cMX3-0003ze-VD for sipping-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 05:55: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 FAA11699 for ; Tue, 15 Jul 2003 05:55: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 19cMWU-0003mK-Bg; Tue, 15 Jul 2003 05:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cMW1-0003kd-5R for sipping@optimus.ietf.org; Tue, 15 Jul 2003 05:54:33 -0400 Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11538 for ; Tue, 15 Jul 2003 05:54:26 -0400 (EDT) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id h6F9sQA10749; Tue, 15 Jul 2003 11:54:26 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id h6F9sPE16434; Tue, 15 Jul 2003 11:54:26 +0200 (MEST) Received: from mchh273e.demchh201e.icn.siemens.de (mchh273e.mchh.siemens.de [139.21.200.83]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id LAA23353; Tue, 15 Jul 2003 11:54:25 +0200 (MET DST) Received: by mchh273e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Tue, 15 Jul 2003 11:53:51 +0200 Message-ID: <931A17FBB884D411B02B0008C70D9E2ABF1314@mchh243e.mchh.siemens.de> From: Stupka Jean-Marie To: "'Jonathan Rosenberg'" Cc: "'sipping@ietf.org'" Subject: AW: [Sipping] Question on INVITE Initiated Dialog Event Package a nd Automatic C allback Date: Tue, 15 Jul 2003 11:53:48 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) 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: , Jonathan, I doubt that sending the SUBSCRIBE request for the dialog package outside of any dialog is possible in case of automatic callback, since the required data are no more available. The problem is that when a 486 is received, the dialog initiated by the INVITE terminates and, the data related to that dialog (including the called user number) disappear. Therefore it is no more possible to send the SUBSCRIBE to request automatic callback for this destination. A possible solution would be to keep for a short period of time the data of the previous call attempt (i.e. the called user number, the bearer description, ...) at the user agent after a 486 is received. This would allow the user agent to re-use the called user number and other data from the preceding call attempt for the SUBSCRIBE request and for the subsequent call after the remote user is free. However, the procedure of retaining data is not foreseen in RFC 3261. A better (more economical and user friendly) solution would be to keep at the user agent only when an automatic callback is possible (e.g. not precluded by other services at the remote user side, lacking network resources, etc.). This would require to extend the 486 with a "Automatic Callback Possible" indication, or to introduce a new message with this meaning. Jean-Marie -----Ursprungliche Nachricht----- Von: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Gesendet: Montag, 14. Juli 2003 10:18 An: Stupka Jean-Marie Cc: 'sipping@ietf.org' Betreff: Re: [Sipping] Question on INVITE Initiated Dialog Event Package and Automatic C allback The dialog package can be used by subscriptions made both within, and outside, of a dialog. So, in the case of automatic callback, the caller would, after receiving a 486, send a SUBSCRIBE request for the dialog package, and do so outside of any dialog. -Jonathan R. Stupka Jean-Marie wrote: > Hello All, > > As said in RFC 3265 it is possible to create an event subscription > within a pre-existing dialog, e.g. a dialog created by an INVITE. > In my understanding, this is the intention of > draft-ietf-sipping-dialog-package-02.txt. > > According to the (PSTN) Automatic Callback given as example > application in the introduction of this draft, user A can request a > callback when user B hangs-up. User A off course needs to get the > information that user B is busy before requesting the automatic > callback, i.e. receive a "486 Busy Here" message. However, all > early dialogs are considered terminated upon reception of a non-2xx > final response (13.2.2.3 of RFC 3261). As consequence, the dialog > and thus the data of the preceding call attempt are no more > available and the callback cannot be requested. > > Can somebody provide clarification of the applicability of RFC 3265 > and the draft-ietf-sipping-dialog-package-02.txt to Automatic > Callback? > > Regards, > > Jean-Marie > > > _______________________________________________ Sipping mailing > list https://www1.ietf.org/mailman/listinfo/sipping This list is > for NEW development of the 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 Tue Jul 15 08:15:23 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 IAA15879 for ; Tue, 15 Jul 2003 08:15:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cOhs-0002GO-MA for sipping-archive@odin.ietf.org; Tue, 15 Jul 2003 08:14:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FCEug1008696 for sipping-archive@odin.ietf.org; Tue, 15 Jul 2003 08:14:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cOhs-0002GB-IX for sipping-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 08:14: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 IAA15868 for ; Tue, 15 Jul 2003 08:14:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cOhm-0001KM-00 for sipping-web-archive@ietf.org; Tue, 15 Jul 2003 08:14:50 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cOhM-0001I8-00 for sipping-web-archive@ietf.org; Tue, 15 Jul 2003 08:14:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cOgz-00027P-7W; Tue, 15 Jul 2003 08: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 19cOgP-000262-ND for sipping@optimus.ietf.org; Tue, 15 Jul 2003 08:13: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 IAA15844 for ; Tue, 15 Jul 2003 08:13:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cOgJ-0001Hq-00 for sipping@ietf.org; Tue, 15 Jul 2003 08:13: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 19cOft-0001HT-00 for sipping@ietf.org; Tue, 15 Jul 2003 08:12:54 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 15 Jul 2003 05:15:56 -0700 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 h6FCBguG024596; Tue, 15 Jul 2003 05:11:48 -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 AJD98566; Tue, 15 Jul 2003 05:08:50 -0700 (PDT) Date: Tue, 15 Jul 2003 05:13:36 -0700 Subject: Re: [Sipping] GRUUs in REGISTER Contacts? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: sipping@ietf.org To: Adam Roach From: Rohan Mahy In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3EE5FEE@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 when "roaming" in the Cisco network, I might fetch a GRUU from a Cisco proxy which I use as a Contact when I register an AOR with iptel.org For example.... REGISTER sip:iptel.org SIP/2.0 From: To: Contact: On Monday, July 14, 2003, at 06:47 AM, Adam Roach wrote: > Perhaps I just missed it, but I can't find or deduce any > particular reason for using a GRUU in the Contact header > field of a REGISTER request. The temporal binding properties > of GRUU leasing are identical to those of registrations; what > additional properties are afforded? > > /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 Jul 15 08:22:23 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 IAA16126 for ; Tue, 15 Jul 2003 08:22:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cOoe-0002aP-E8 for sipping-archive@odin.ietf.org; Tue, 15 Jul 2003 08:21:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FCLuY3009935 for sipping-archive@odin.ietf.org; Tue, 15 Jul 2003 08:21:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cOoe-0002aA-B7 for sipping-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 08:21: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 IAA16116 for ; Tue, 15 Jul 2003 08:21:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cOoY-0001Nz-00 for sipping-web-archive@ietf.org; Tue, 15 Jul 2003 08:21:50 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cOo7-0001Nb-00 for sipping-web-archive@ietf.org; Tue, 15 Jul 2003 08: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 19cOnl-0002Rd-V0; Tue, 15 Jul 2003 08: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 19cOnf-0002RB-Lz for sipping@optimus.ietf.org; Tue, 15 Jul 2003 08:21: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 IAA16066 for ; Tue, 15 Jul 2003 08:20:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cOnZ-0001NR-00 for sipping@ietf.org; Tue, 15 Jul 2003 08:20: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 19cOn9-0001Mz-00 for sipping@ietf.org; Tue, 15 Jul 2003 08:20:23 -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 h6FCJP89019055; Tue, 15 Jul 2003 05:19:26 -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 AJD99045; Tue, 15 Jul 2003 05:16:32 -0700 (PDT) Date: Tue, 15 Jul 2003 05:21:17 -0700 Subject: Re: AW: [Sipping] Question on INVITE Initiated Dialog Event Package a nd Automatic C allback Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'Jonathan Rosenberg'" , "'sipping@ietf.org'" To: Stupka Jean-Marie From: Rohan Mahy In-Reply-To: <931A17FBB884D411B02B0008C70D9E2ABF1314@mchh243e.mchh.siemens.de> 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 Jean-Marie, It seems perfectly reasonable to send a SUBSCRIBE to the dialog package outside of a dialog. The default behavior would be to send a list of dialogs but with no dialog information or peer information. I believe this is sufficient to build a callback service. thanks, -rohan On Tuesday, July 15, 2003, at 02:53 AM, Stupka Jean-Marie wrote: > Jonathan, > > I doubt that sending the SUBSCRIBE request for the dialog package > outside of any dialog is possible in case of automatic callback, since > the required data are no more available. > > The problem is that when a 486 is received, the dialog initiated by > the INVITE terminates and, the data related to that dialog (including > the called user number) disappear. Therefore it is no more possible to > send the SUBSCRIBE to request automatic callback for this destination. > > A possible solution would be to keep for a short period of time the > data of the previous call attempt (i.e. the called user number, the > bearer description, ...) at the user agent after a 486 is received. > This would allow the user agent to re-use the called user number and > other data from the preceding call attempt for the SUBSCRIBE request > and for the subsequent call after the remote user is free. However, > the procedure of retaining data is not foreseen in RFC 3261. > > A better (more economical and user friendly) solution would be to keep > at the user agent only when an automatic callback is possible (e.g. > not precluded by other services at the remote user side, lacking > network resources, etc.). This would require to extend the 486 with a > "Automatic Callback Possible" indication, or to introduce a new > message with this meaning. > > Jean-Marie > > -----Ursprungliche Nachricht----- > Von: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Gesendet: Montag, 14. Juli 2003 10:18 > An: Stupka Jean-Marie > Cc: 'sipping@ietf.org' > Betreff: Re: [Sipping] Question on INVITE Initiated Dialog Event > Package > and Automatic C allback > > > The dialog package can be used by subscriptions made both within, and > outside, of a dialog. So, in the case of automatic callback, the > caller would, after receiving a 486, send a SUBSCRIBE request for the > dialog package, and do so outside of any dialog. > > -Jonathan R. > > Stupka Jean-Marie wrote: > >> Hello All, >> >> As said in RFC 3265 it is possible to create an event subscription >> within a pre-existing dialog, e.g. a dialog created by an INVITE. >> In my understanding, this is the intention of >> draft-ietf-sipping-dialog-package-02.txt. >> >> According to the (PSTN) Automatic Callback given as example >> application in the introduction of this draft, user A can request a >> callback when user B hangs-up. User A off course needs to get the >> information that user B is busy before requesting the automatic >> callback, i.e. receive a "486 Busy Here" message. However, all >> early dialogs are considered terminated upon reception of a non-2xx >> final response (13.2.2.3 of RFC 3261). As consequence, the dialog >> and thus the data of the preceding call attempt are no more >> available and the callback cannot be requested. >> >> Can somebody provide clarification of the applicability of RFC 3265 >> and the draft-ietf-sipping-dialog-package-02.txt to Automatic >> Callback? >> >> Regards, >> >> Jean-Marie >> >> >> _______________________________________________ Sipping mailing >> list https://www1.ietf.org/mailman/listinfo/sipping This list is >> for NEW development of the 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 Jul 15 13:51: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 NAA27925 for ; Tue, 15 Jul 2003 13:51: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 19cTxO-0001uG-Ex for sipping-archive@odin.ietf.org; Tue, 15 Jul 2003 13:51:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FHpI0D007324 for sipping-archive@odin.ietf.org; Tue, 15 Jul 2003 13:51:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cTxO-0001u3-Aw for sipping-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 13: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 NAA27919 for ; Tue, 15 Jul 2003 13:51:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cTxM-00048l-00 for sipping-web-archive@ietf.org; Tue, 15 Jul 2003 13:51:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cTxG-00048h-00 for sipping-web-archive@ietf.org; Tue, 15 Jul 2003 13:51:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cTx7-0001tA-K7; Tue, 15 Jul 2003 13:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cTwM-0001sg-92 for sipping@optimus.ietf.org; Tue, 15 Jul 2003 13:50: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 NAA27905 for ; Tue, 15 Jul 2003 13:50:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cTwK-00048M-00 for sipping@ietf.org; Tue, 15 Jul 2003 13:50:12 -0400 Received: from ns.ivd.nl ([193.67.37.226]) by ietf-mx with esmtp (Exim 4.12) id 19cTw9-00048H-00 for sipping@ietf.org; Tue, 15 Jul 2003 13:50:01 -0400 Received: (from root@localhost) by ns.ivd.nl (8.9.3c/8.6.12) id TAA68559 for ; Tue, 15 Jul 2003 19:50:52 +0200 (CEST) Received: by ns.ivd.nl (TUNIX txp2/smap) for id sma068231; Tue, 15 Jul 03 19:50:08 +0200 Received: from IVD-Message_Server by mailserver.viataal.nl with Novell_GroupWise; Tue, 15 Jul 2003 19:51:08 +0200 Message-Id: X-Mailer: Novell GroupWise 5.5.5 Date: Tue, 15 Jul 2003 19:50:41 +0200 From: "A vWijk" To: , , Cc: , , , Subject: Re: [Sipping] Update to caller preferences use cases Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 This is indeed one of "the still unclear how we solve it part". And = perhaps for many people unclear why this is needed. When I started with this hearing impairment work, I found the best = solution in the caller preferences (that was around august 2000!). Where a = user could indicate that he or she needs a speech to text or speech to = sign or english or spanish or Dutch language. That a relay service can = immediately see what kind of relay service it can offer to the user. It is = all listed in the preferences. Those preferences would be independent to whatever location the user is = calling or getting called. The latter is especially the problem now. If a = caller uses a relay to call me (the deaf user), how can the relay know = that it has to send audio, and to offer a text containing the speech of = the said audio and to let me reply in audio to the caller (voice carry = over, I am deaf, but I talk w/o any problem). And perhaps in an other = case, a different deaf user prefers a signlanguage interpreting service = for incoming voice and outgoing (user signs the answer back and the relay = translates it into voice). What we need here is a way of registering the different preferences of the = services like described above. Make this registration independent of = location (thus not bound to a specific relay operator and country). Else = we get roaming problems and that not all users have a selected relay = operator (most have none, e.g most hearing users). Ofcourse, it would be easy just to have the deaf user initiate the relay = service. But that means that the deaf user has to pay for such service = while it could be an phone advertisement or an unimportant call. I as a = deaf user expect people who call me, to pay the charges of the relay if = they need to get ahold of me. And if I want to keep my deafness a secret, I am then willing to initiate = the relay service anytime, even if it means I pay for an advertisement/mark= eting call. But most deaf users want every incoming a call a call that he = or she understands. Thus as text,via IM or via T.140/RTP or as signlanguage= etc. Regardless of the terminal used and the location. I am open to good suggestions. For hearing people I want to add that this = is not only benefitting the hearing/speech impaired. Imagine that you can = get a (streaming) text translation in English when a Spanish speaking = person calls you (translation can also be offered in voice ofcourse). It = is the same principle. And with IP telephony, international calls will = increase, since the distinction between local, interlocal and international= will disappear. greetz Arnoud <<< ggybels@webclient.eu.blackberry.net 7/15 9:57a >>> Jonathan: <<* added a hearing impaired use case>> First of all, I think it is extremely useful to have some=20 use cases for deaf and hard of hearing people in the=20 draft. Some comments/questions: 1) If I understand the case correctly, the relay service=20 needs to issue a registration on behalf of the user,=20 indicating that this registration accepts audio. One of=20 the problems with that scenario is that this seems to=20 suggest that the user must register through the relay in=20 order to be able to receive incoming calls. I'm not so=20 sure how practical that is, especially with regard to=20 roaming users (how would they discover the relay in the=20 network?). Some thoughts on this would be welcome. 2) The current version is slightly vague with regard to=20 the type of text coming out of the relay. Using=20 traditional messaging (IM) is not really an option for=20 relay calls. I'd like to see a more explicit example of=20 using RFC2793 character-by-character text coming from the=20 relay, as that is likely to be what will be used in a real- world scenario. We have experimented at Typetalk with=20 using IM for the interaction with the relay, but that has=20 proven to be quite useless, as the conversation breaks=20 down and the long pauzes=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 Wed Jul 16 02:28:49 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 CAA14009 for ; Wed, 16 Jul 2003 02:28: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 19cfm3-0002LY-Iy for sipping-archive@odin.ietf.org; Wed, 16 Jul 2003 02:28:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G6SNss009017 for sipping-archive@odin.ietf.org; Wed, 16 Jul 2003 02:28:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cfm1-0002LH-3Z for sipping-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 02:28: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 CAA13476 for ; Wed, 16 Jul 2003 02:28:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cflx-0003M7-00 for sipping-web-archive@ietf.org; Wed, 16 Jul 2003 02:28:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cflr-0003M4-00 for sipping-web-archive@ietf.org; Wed, 16 Jul 2003 02:28:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cflj-0002J9-Cl; Wed, 16 Jul 2003 02: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 19cflN-0002I0-ED for sipping@optimus.ietf.org; Wed, 16 Jul 2003 02:27: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 CAA13152 for ; Wed, 16 Jul 2003 02:27:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cflJ-0003Ln-00 for sipping@ietf.org; Wed, 16 Jul 2003 02:27:37 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19cfl8-0003LU-00 for sipping@ietf.org; Wed, 16 Jul 2003 02:27:26 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6G6QSY14857 for ; Wed, 16 Jul 2003 01:26:28 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <301TXBZJ>; Wed, 16 Jul 2003 01:26:29 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF578A8D@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'sipping@ietf.org'" Date: Wed, 16 Jul 2003 01:26:28 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [Sipping] Security drafts being discussed in SIP & SIPPING (Wed./Thursday) Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 all, As Rohan mentioned in the SIPPING session on Monday nite, there will be some discussion of middle-to-end and end-to-middle security during the remaining SIP and SIPPING sessions this week. On Wednesday morning in the SIP WG session, along with the History Info solution draft, I'll be discussing the related security solution draft put forth to provide a general mechanism for securing the headers inserted by intermediaries, draft-barnes-sipping-sec-inserted-info-00.txt. On Thursday, there will be a discussion of the draft-ono-sipping-end2middle-security-00 which describes a method of achieving end-to-middle security, allowing a SIP UA to disclose message data to selected intermediaries and protect the data from being seen by other intermediaries. There's not been any discussion of these drafts on the mailing list, so this is just a reminder to facilitate the discussions this morning and Thursday and hopefully solicit some feedback on these proposals. Here's the links: http://www.ietf.org/internet-drafts/draft-barnes-sipping-sec-inserted-info-0 0.txt http://www.ietf.org/internet-drafts/draft-ono-sipping-end2middle-security-00 .txt Regards, Mary H. Barnes mbarnes@nortelnetworks.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 Jul 16 02:52: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 CAA17245 for ; Wed, 16 Jul 2003 02:52: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 19cg9E-00041W-Pv for sipping-archive@odin.ietf.org; Wed, 16 Jul 2003 02:52:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G6qKFE015467 for sipping-archive@odin.ietf.org; Wed, 16 Jul 2003 02:52:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cg9A-0003zS-Bk for sipping-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 02:52: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 CAA17186 for ; Wed, 16 Jul 2003 02:52:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cg96-0003fa-00 for sipping-web-archive@ietf.org; Wed, 16 Jul 2003 02:52:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cg90-0003fU-00 for sipping-web-archive@ietf.org; Wed, 16 Jul 2003 02:52:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cg8x-0003uZ-Bx; Wed, 16 Jul 2003 02: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 19cg8L-0003ra-JP for sipping@optimus.ietf.org; Wed, 16 Jul 2003 02:51: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 CAA17143 for ; Wed, 16 Jul 2003 02:51:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cg8H-0003ew-00 for sipping@ietf.org; Wed, 16 Jul 2003 02:51:21 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cg86-0003eh-00 for sipping@ietf.org; Wed, 16 Jul 2003 02:51:10 -0400 Received: from dynamicsoft.com ([63.113.46.64]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6G6ociB010709; Wed, 16 Jul 2003 02:50:38 -0400 (EDT) Message-ID: <3F148374.1020204@dynamicsoft.com> Date: Tue, 15 Jul 2003 18:43:00 -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: A vWijk CC: sipping@ietf.org, guido.gybels@rnid.org.uk, ggybels@webclient.eu.blackberry.net, frank.shearar@rnid.org.uk, james.hamlin@rnid.org.uk, mike.spanner@rnid.org.uk Subject: Re: [Sipping] Update to caller preferences use cases 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 A vWijk wrote: > This is indeed one of "the still unclear how we solve it part". And > perhaps for many people unclear why this is needed. When I > started with this hearing impairment work, I found the best > solution in the caller preferences (that was around august 2000!). > Where a user could indicate that he or she needs a speech to text > or speech to sign or english or spanish or Dutch language. That a > relay service can immediately see what kind of relay service it can > offer to the user. It is all listed in the preferences. Lets be careful here, I think you mean its listed in the capabilities, not the preferences. What I *think* you mean is that a hearing impaired user would register to a relay service. That registration would have callee capabilities that indicates that it needs incoming audio translated to text, for example. I'm really not sure that this is a CAPABILITIES issue. Its a service invocation issue. The question is how one asks a service to return an IP address and port on which a certain type of media will be received, and then forwarded somewhere else in a specified translated format. To be honest, this feels much closer to TURN (http://www.jdrosen.net/papers/draft-rosenberg-midcom-turn-02.txt). TURN allows a client to ask for a relay service to forward packets to it. However, right now, the relay doesnt perform any transformations. One can imagine, however, extending TURN to provide transformation services as well - converting g711 to g729, or converting from audio to streaming text. To do this, the turn allocation request would contain a new attribute that specifies the desired transformation. As such, its really a service invocation. The same thing would apply to MSRP, btw, one could add an attribute to a bind operation that asks for desired transformations. This may not be the right approach either (need to think about it some more), but I think its a lot closer than callee capabilities. Those > preferences would be independent to whatever location the user is > calling or getting called. The latter is especially the problem > now. If a caller uses a relay to call me (the deaf user), how can > the relay know that it has to send audio, and to offer a text > containing the speech of the said audio and to let me reply in > audio to the caller (voice carry over, I am deaf, but I talk w/o > any problem). And perhaps in an other case, a different deaf user > prefers a signlanguage interpreting service for incoming voice and > outgoing (user signs the answer back and the relay translates it > into voice). I think the above proposal would solve that. > > What we need here is a way of registering the different preferences > of the services like described above. Make this registration > independent of location (thus not bound to a specific relay > operator and country). Else we get roaming problems and that not > all users have a selected relay operator (most have none, e.g most > hearing users). In the above idea, the relay is purely the problem for the user that is hearing impaired. If they roam, they would presumably still contact their home relay service. If not, there needs to be some kind of visited service discovery done. Thats a general problem, not specific to transformation services. > > Ofcourse, it would be easy just to have the deaf user initiate the > relay service. But that means that the deaf user has to pay for > such service while it could be an phone advertisement or an > unimportant call. Well, thats the nice bit about TURN. It wouldnt work that way. A called party thats hearing impaired wouldnt contact the TURN server until after it receives the incoming call. This way, if the call is from a telemarketer the relay doesnt get contacted. You would just reject the call. I as a deaf user expect people who call me, to > pay the charges of the relay if they need to get ahold of me. Well, thats probably not going to work in my proposed approach. I dont see how it works that way in any approach, without some serious settlement capabilities put into place. > I am open to good suggestions. For hearing people I want to add > that this is not only benefitting the hearing/speech impaired. > Imagine that you can get a (streaming) text translation in English > when a Spanish speaking person calls you (translation can also be > offered in voice ofcourse). It is the same principle. And with IP > telephony, international calls will increase, since the distinction > between local, interlocal and international will disappear. I agree to some extent. I think my proposed idea would be reasonable for automated translation services, and certainly language translation is NOT in that category. Codec translation is though. -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 Jul 16 02:52: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 CAA17261 for ; Wed, 16 Jul 2003 02:52: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 19cg9N-0004Cx-Ck for sipping-archive@odin.ietf.org; Wed, 16 Jul 2003 02:52:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G6qTJ4016168 for sipping-archive@odin.ietf.org; Wed, 16 Jul 2003 02:52:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cg9M-0004AJ-IE for sipping-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 02:52: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 CAA17195 for ; Wed, 16 Jul 2003 02:52:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cg96-0003fX-00 for sipping-web-archive@ietf.org; Wed, 16 Jul 2003 02:52:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cg90-0003fT-00 for sipping-web-archive@ietf.org; Wed, 16 Jul 2003 02:52:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cg8w-0003uP-G8; Wed, 16 Jul 2003 02: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 19cg8L-0003rZ-JM for sipping@optimus.ietf.org; Wed, 16 Jul 2003 02:51: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 CAA17144 for ; Wed, 16 Jul 2003 02:51:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cg8H-0003ex-00 for sipping@ietf.org; Wed, 16 Jul 2003 02:51:21 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cg86-0003eb-00 for sipping@ietf.org; Wed, 16 Jul 2003 02:51:10 -0400 Received: from dynamicsoft.com ([63.113.46.64]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6G6oViB010706; Wed, 16 Jul 2003 02:50:32 -0400 (EDT) Message-ID: <3F1480A4.4020603@dynamicsoft.com> Date: Tue, 15 Jul 2003 18:31:00 -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: guido.gybels@rnid.org.uk CC: sipping@ietf.org, A.vWijk@viataal.nl, james.hamlin@rnid.org.uk, mike.spanner@rnid.org.uk, frank.shearar@rnid.org.uk Subject: Re: [Sipping] Update to caller preferences use cases 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. Guido Gybels wrote: > Jonathan: > > <<* added a hearing impaired use case>> > > First of all, I think it is extremely useful to have some > use cases for deaf and hard of hearing people in the > draft. Some comments/questions: > > 1) If I understand the case correctly, the relay service > needs to issue a registration on behalf of the user, > indicating that this registration accepts audio. One of > the problems with that scenario is that this seems to > suggest that the user must register through the relay in > order to be able to receive incoming calls. I'm not so > sure how practical that is, especially with regard to > roaming users (how would they discover the relay in the > network?). Some thoughts on this would be welcome. I thought about this use case some more, and I actually concluded that this service is really not a CALLER PREFERENCE service. Its not about the caller preference at all. Its about a routing application on the callee side which sends incoming audio calls to a relay, and incoming messaging calls to a user. Something like that is best implemented through servlets on the callee side, or something. Its not a caller preference at all. So, I would like to remove this case altogether, and find something which is really an example of a caller preference. > > 2) The current version is slightly vague with regard to > the type of text coming out of the relay. Using > traditional messaging (IM) is not really an option for > relay calls. I'd like to see a more explicit example of > using RFC2793 character-by-character text coming from the > relay, as that is likely to be what will be used in a real- > world scenario. Yeah, the example didnt say - I had meant something like RFC2793. > 3) The current scenario is based on an incoming audio > conversation, which certainly is a valid case. However, > there is also the opposite possibility of making an > outgoing call using T.140 but with a voice destination. In > that case, again, the call needs to be routed through the > relay. However, it seems unlikely that every hearing user > will be registered with a relay service, so there is no > registration for those hearing users, as hearing people > cannot necessarily know in advance that they will be > called by a deaf or hard of hearing person. So, can caller > preferences deal with such a scenario? If yes, I would be > grateful for a use case demonstrating this, otherwise we > need suggestions on how to deal with such situations. I dont see how. Clearly all called parties can't register against your relay. I have a much simpler use case for hearing impaired services. I'm not sure its practical or useful, though, so please comment on that. Consider a caller that is hearing impaired. Before making a call, they contact a relay service. This relay service will receive audio and transform it to streaming text. Of course the caller can also receive streaming text directly from the called party. So, in their invite, they have an m-line for audio, and an m-line for streaming text. They add a caller preference to have their call routed to a device that supports streaming text. In this way, if a called party happens to be able to do both audio on one device, or streaming text on another, the call is routed to the device that can do streaming text. It feels farfetched to me, so please comment. 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 Wed Jul 16 07:08: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 HAA25422 for ; Wed, 16 Jul 2003 07:08: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 19ck8o-0002Po-TX for sipping-archive@odin.ietf.org; Wed, 16 Jul 2003 07:08:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GB8AEp009280 for sipping-archive@odin.ietf.org; Wed, 16 Jul 2003 07:08:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ck8o-0002Pb-QI for sipping-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 07:08: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 HAA25392 for ; Wed, 16 Jul 2003 07:08:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ck8k-0005ul-00 for sipping-web-archive@ietf.org; Wed, 16 Jul 2003 07:08:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ck8f-0005ui-00 for sipping-web-archive@ietf.org; Wed, 16 Jul 2003 07:08:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ck8g-0002Od-JF; Wed, 16 Jul 2003 07:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ck8B-0002Il-PE for sipping@optimus.ietf.org; Wed, 16 Jul 2003 07:07: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 HAA25373 for ; Wed, 16 Jul 2003 07:07:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ck87-0005uO-00 for sipping@ietf.org; Wed, 16 Jul 2003 07:07:27 -0400 Received: from ns.ivd.nl ([193.67.37.226]) by ietf-mx with esmtp (Exim 4.12) id 19ck7w-0005tz-00 for sipping@ietf.org; Wed, 16 Jul 2003 07:07:16 -0400 Received: (from root@localhost) by ns.ivd.nl (8.9.3c/8.6.12) id NAA29857 for ; Wed, 16 Jul 2003 13:07:55 +0200 (CEST) Received: by ns.ivd.nl (TUNIX txp2/smap) for id sma029612; Wed, 16 Jul 03 13:06:53 +0200 Received: from IVD-Message_Server by mailserver.viataal.nl with Novell_GroupWise; Wed, 16 Jul 2003 13:07:54 +0200 Message-Id: X-Mailer: Novell GroupWise 5.5.5 Date: Wed, 16 Jul 2003 13:07:29 +0200 From: "A vWijk" To: , Cc: , , , Subject: Re: [Sipping] Update to caller preferences use cases Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 Jonathan, In this case you are only looking at the relay invocation at the callee's = side. Thus the deaf user must always register him or herself at a selected relay = service. This solution will surely work, but I am not happy with this registering = with the relay itself. It still does not solve incoming relay calls to the = exact requirements of the receiving user. About your other suggestion: If I understand this correctly, you state here that receiving streamed = text (RFC 2793) can be a caller preference to ensure when a text call is = initiated, that the correct terminal is selected. That is a good idea. It = gives the users more flexibility. And this allows the user who owns 3 phones, 2 cheap wallmart phones = without any screen and keyboard and one normal IP telephone with a screen = and keyboard to receive text calls on the right phone. And perhaps also in this way that the user is only logged in a non text = terminal, that the relay service or the caller can see that setting up a = text call won't work? And that the relay then kicks in and converts audio to text and vice = versa. I think that this is indeed useful. This will allow a relay service at = least know which kind of media can be sent. E.g a terminal has no video = ability but it has text. The relay can fallback to text in that case. Even = if the caller uses a video connection and communicates via signlanguage. (or the video caller can also switch to text and skip the relay). This is useful at this level. So, this can be added as an example. It does = not offer flexibility of voice carry over or hearing carry over and such. = But for the basics it is useful. Greetz Arnoud <<< Jonathan Rosenberg 7/16 8:54a >>> inline. Guido Gybels wrote: > Jonathan: >=20 > <<* added a hearing impaired use case>> >=20 > First of all, I think it is extremely useful to have some=20 > use cases for deaf and hard of hearing people in the=20 > draft. Some comments/questions: >=20 > 1) If I understand the case correctly, the relay service=20 > needs to issue a registration on behalf of the user,=20 > indicating that this registration accepts audio. One of=20 > the problems with that scenario is that this seems to=20 > suggest that the user must register through the relay in=20 > order to be able to receive incoming calls. I'm not so=20 > sure how practical that is, especially with regard to=20 > roaming users (how would they discover the relay in the=20 > network?). Some thoughts on this would be welcome. I thought about this use case some more, and I actually concluded that=20 this service is really not a CALLER PREFERENCE service. Its not about=20 the caller preference at all. Its about a routing application on the=20 callee side which sends incoming audio calls to a relay, and incoming=20 messaging calls to a user. Something like that is best implemented=20 through servlets on the callee side, or something. Its not a caller=20 preference at all. So, I would like to remove this case altogether,=20 and find something which is really an example of a caller preference. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 16 07:49: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 HAA26578 for ; Wed, 16 Jul 2003 07:49: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 19ckmW-0005S5-AC for sipping-archive@odin.ietf.org; Wed, 16 Jul 2003 07:49:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GBnCBf020951 for sipping-archive@odin.ietf.org; Wed, 16 Jul 2003 07:49:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ckmW-0005RG-6D for sipping-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 07:49: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 HAA26571 for ; Wed, 16 Jul 2003 07:49:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ckmV-0006JM-00 for sipping-web-archive@ietf.org; Wed, 16 Jul 2003 07:49:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ckmP-0006JJ-00 for sipping-web-archive@ietf.org; Wed, 16 Jul 2003 07: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 19ckmL-0005Of-5F; Wed, 16 Jul 2003 07: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 19cklZ-0005Nw-BI for sipping@optimus.ietf.org; Wed, 16 Jul 2003 07:48: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 HAA26552 for ; Wed, 16 Jul 2003 07:48:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cklY-0006Im-00 for sipping@ietf.org; Wed, 16 Jul 2003 07:48:12 -0400 Received: from ns.ivd.nl ([193.67.37.226]) by ietf-mx with esmtp (Exim 4.12) id 19cklN-0006Ij-00 for sipping@ietf.org; Wed, 16 Jul 2003 07:48:01 -0400 Received: (from root@localhost) by ns.ivd.nl (8.9.3c/8.6.12) id NAA34412 for ; Wed, 16 Jul 2003 13:49:13 +0200 (CEST) Received: by ns.ivd.nl (TUNIX txp2/smap) for id sma034209; Wed, 16 Jul 03 13:48:12 +0200 Received: from IVD-Message_Server by mailserver.viataal.nl with Novell_GroupWise; Wed, 16 Jul 2003 13:49:13 +0200 Message-Id: X-Mailer: Novell GroupWise 5.5.5 Date: Wed, 16 Jul 2003 13:49:12 +0200 From: "A vWijk" To: Cc: , , , , , Subject: Re: [Sipping] Update to caller preferences use cases Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 Jonathan, <<> This is indeed one of "the still unclear how we solve it part". And > perhaps for many people unclear why this is needed. When I > started with this hearing impairment work, I found the best > solution in the caller preferences (that was around august 2000!). > Where a user could indicate that he or she needs a speech to text > or speech to sign or english or spanish or Dutch language. That a > relay service can immediately see what kind of relay service it can > offer to the user. It is all listed in the preferences.>> I mean preferences based on the capabilities. :-) If a terminal can receive text, great that is a capability. But my = preference is that I want only incoming audio to be changed into text. = Outggoing audio remains unchanged. And we still have no way to indicate that independent of any relay = operator. The callee is in this case the hearing impaired user who registered = him/herself..right? If so, yes.. this relay operator has then all my preferences listed. That = will indeed work. But the problem remains that the hearing impaired user = MUST register him/herself with a certain relay operator. And I am thus looking for a way to have those preferences listed independen= t of the registrar used. May it be from a local network operator or a = relay operator or even from the university. Yes, correct it is a service option and not capability. Umm I will check out the TURN method. It sounds good. Perhaps this can = bring the solution closer. I will also think more about this. And try to come with use cases to = identify the missing links. << Those > preferences would be independent to whatever location the user is > calling or getting called. The latter is especially the problem > now. If a caller uses a relay to call me (the deaf user), how can > the relay know that it has to send audio, and to offer a text > containing the speech of the said audio and to let me reply in > audio to the caller (voice carry over, I am deaf, but I talk w/o > any problem). And perhaps in an other case, a different deaf user > prefers a signlanguage interpreting service for incoming voice and > outgoing (user signs the answer back and the relay translates it > into voice).>> Maybe. I will comment more as soon I have taken a good look at TURN. As I = said before. I do not care how it is solved, as long the preferences of = the invocation happens at a standardized and reliable way. And that it = does not require the hearing impaired user to be registered with a relay = opera _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 16 08:07: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 IAA27050 for ; Wed, 16 Jul 2003 08:07: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 19cl3w-0006PS-2k for sipping-archive@odin.ietf.org; Wed, 16 Jul 2003 08:07:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GC7C38024632 for sipping-archive@odin.ietf.org; Wed, 16 Jul 2003 08: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 19cl3v-0006P2-Ur for sipping-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 08:07: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 IAA27011 for ; Wed, 16 Jul 2003 08:07:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cl3u-0006Rt-00 for sipping-web-archive@ietf.org; Wed, 16 Jul 2003 08:07:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cl3p-0006Rq-00 for sipping-web-archive@ietf.org; Wed, 16 Jul 2003 08: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 19cl3n-0006JL-5o; Wed, 16 Jul 2003 08:07:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cl3R-0006I2-9o for sipping@optimus.ietf.org; Wed, 16 Jul 2003 08:06: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 IAA26977 for ; Wed, 16 Jul 2003 08:06:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cl3Q-0006Ra-00 for sipping@ietf.org; Wed, 16 Jul 2003 08:06:40 -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 19cl3F-0006RJ-00 for sipping@ietf.org; Wed, 16 Jul 2003 08:06:29 -0400 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 h6GC5ouJ016568; Wed, 16 Jul 2003 05:05:51 -0700 (PDT) Received: from cisco.com (ams-clip-vpn-dhcp4171.cisco.com [10.61.80.74]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAR98320; Wed, 16 Jul 2003 08:05:48 -0400 (EDT) Message-ID: <3F153F9B.2080107@cisco.com> Date: Wed, 16 Jul 2003 08:05: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: A vWijk CC: jdrosen@dynamicsoft.com, guido.gybels@rnid.org.uk, sipping@ietf.org, frank.shearar@rnid.org.uk, james.hamlin@rnid.org.uk, mike.spanner@rnid.org.uk Subject: Re: [Sipping] Update to caller preferences use cases 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 think this scenario may be better solved with preconditions - a new kind of precondition for an acceptable mix of media being available. This avoids even alerted called parties if a satisfactory arrangement can't be made. This doesn't exclude using callerprefs to help, such as in picking the order in which to try devices, but does make it secondary. Today we get away without preconditions on media because generally there is only one important medium. Many UAs will fail a call if no media are negotiated, effectively implementing a rudimentary form of precondition. But that is going to work going forward - there are beginning to be interesting call flows that have no media. So in this case the hearing impared user's UA can first initiate a call with precondition for streaming text media. If that succeeds, fine. If not, it can try again - setting up a relay and sending a voice invite that splices in the relay. Paul A vWijk wrote: > Jonathan, > In this case you are only looking at the relay invocation at the callee's side. > Thus the deaf user must always register him or herself at a selected relay service. > > This solution will surely work, but I am not happy with this registering with the relay itself. It still does not solve incoming relay calls to the exact requirements of the receiving user. > > About your other suggestion: > sure its practical or useful, though, so please comment on that. > Consider a caller that is hearing impaired. Before making a call, they > contact a relay service. This relay service will receive audio and > transform it to streaming text. Of course the caller can also receive > streaming text directly from the called party. So, in their invite, > they have an m-line for audio, and an m-line for streaming text. They > add a caller preference to have their call routed to a device that > supports streaming text. In this way, if a called party happens to be > able to do both audio on one device, or streaming text on another, the > call is routed to the device that can do streaming text. > > It feels farfetched to me, so please comment. > > Thanks, > Jonathan R.> > > If I understand this correctly, you state here that receiving streamed text (RFC 2793) can be a caller preference to ensure when a text call is initiated, that the correct terminal is selected. That is a good idea. It gives the users more flexibility. > And this allows the user who owns 3 phones, 2 cheap wallmart phones without any screen and keyboard and one normal IP telephone with a screen and keyboard to receive text calls on the right phone. > > And perhaps also in this way that the user is only logged in a non text terminal, that the relay service or the caller can see that setting up a text call won't work? > And that the relay then kicks in and converts audio to text and vice versa. > > I think that this is indeed useful. This will allow a relay service at least know which kind of media can be sent. E.g a terminal has no video ability but it has text. The relay can fallback to text in that case. Even if the caller uses a video connection and communicates via signlanguage. > (or the video caller can also switch to text and skip the relay). > > This is useful at this level. So, this can be added as an example. It does not offer flexibility of voice carry over or hearing carry over and such. But for the basics it is useful. > > Greetz > > Arnoud > > <<< Jonathan Rosenberg 7/16 8:54a >>> > inline. > > Guido Gybels wrote: > > >>Jonathan: >> >><<* added a hearing impaired use case>> >> >>First of all, I think it is extremely useful to have some >>use cases for deaf and hard of hearing people in the >>draft. Some comments/questions: >> >>1) If I understand the case correctly, the relay service >>needs to issue a registration on behalf of the user, >>indicating that this registration accepts audio. One of >>the problems with that scenario is that this seems to >>suggest that the user must register through the relay in >>order to be able to receive incoming calls. I'm not so >>sure how practical that is, especially with regard to >>roaming users (how would they discover the relay in the >>network?). Some thoughts on this would be welcome. > > > I thought about this use case some more, and I actually concluded that > this service is really not a CALLER PREFERENCE service. Its not about > the caller preference at all. Its about a routing application on the > callee side which sends incoming audio calls to a relay, and incoming > messaging calls to a user. Something like that is best implemented > through servlets on the callee side, or something. Its not a caller > preference at all. So, I would like to remove this case altogether, > and find something which is really an example of a caller preference. > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 Jul 16 14:42:02 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 OAA12015 for ; Wed, 16 Jul 2003 14:42:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crDc-0005HA-HJ for sipping-archive@odin.ietf.org; Wed, 16 Jul 2003 14:41:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GIfa7C020279 for sipping-archive@odin.ietf.org; Wed, 16 Jul 2003 14:41:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crDb-0005H0-V5 for sipping-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 14:41:35 -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 OAA11999 for ; Wed, 16 Jul 2003 14:41: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 19crD4-00058J-1G; Wed, 16 Jul 2003 14:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crCB-00057g-Tm for sipping@optimus.ietf.org; Wed, 16 Jul 2003 14:40: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 OAA11978 for ; Wed, 16 Jul 2003 14:40:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19crC9-00023E-00 for sipping@ietf.org; Wed, 16 Jul 2003 14:40:05 -0400 Received: from pmesmtp02.wcom.com ([199.249.20.2]) by ietf-mx with esmtp (Exim 4.12) id 19crBy-00022q-00 for sipping@ietf.org; Wed, 16 Jul 2003 14:39:54 -0400 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HI400DDYRRTMD@firewall.wcom.com> for sipping@ietf.org; Wed, 16 Jul 2003 18:38:17 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HI400801RPOP9@pmismtp01.wcomnet.com>; Wed, 16 Jul 2003 18:38:17 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.113.41]) by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HI4008NARQXA0@pmismtp01.wcomnet.com>; Wed, 16 Jul 2003 18:37:49 +0000 (GMT) Date: Wed, 16 Jul 2003 13:37:42 -0500 From: Alan Johnston Subject: RE: [Sipping] FWD:I-D ACTION:draft-johnston-sipping-rtcp-summary-00.txt In-reply-to: <4A3384433CE2AB46A63468CB207E209D4F6551@zoe.office.snowshor e.com> X-Sender: Alan.Johnston@pop.mcit.com To: Eric Burger Cc: sipping@ietf.org Message-id: <5.2.1.1.0.20030716133610.02209e00@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 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Eric, The stated intent is delivery of RTCP XR (extended report) summary reports, not individual RTCP SR or RR reports which would generate much traffic of little interest. Thanks, Alan. At 11:09 AM 7/14/2003 -0400, 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 From exim@www1.ietf.org Wed Jul 16 14:46:47 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 OAA12233 for ; Wed, 16 Jul 2003 14:46: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 19crIC-0005kH-1J for sipping-archive@odin.ietf.org; Wed, 16 Jul 2003 14:46:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GIkKxw022079 for sipping-archive@odin.ietf.org; Wed, 16 Jul 2003 14:46:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crIA-0005k2-HH for sipping-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 14: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 OAA12190 for ; Wed, 16 Jul 2003 14:46:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19crI7-00028Y-00 for sipping-web-archive@ietf.org; Wed, 16 Jul 2003 14:46:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19crI2-00028O-00 for sipping-web-archive@ietf.org; Wed, 16 Jul 2003 14: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 19crHv-0005dm-Cg; Wed, 16 Jul 2003 14: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 19crHl-0005bM-AI for sipping@optimus.ietf.org; Wed, 16 Jul 2003 14:45: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 OAA12175 for ; Wed, 16 Jul 2003 14:45:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19crHi-000281-00 for sipping@ietf.org; Wed, 16 Jul 2003 14:45:50 -0400 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by ietf-mx with esmtp (Exim 4.12) id 19crHX-00027C-00 for sipping@ietf.org; Wed, 16 Jul 2003 14:45:39 -0400 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HI4006MVRU14G@firewall.wcom.com> for sipping@ietf.org; Wed, 16 Jul 2003 18:39:38 +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 <0HI400801RTZT8@pmismtp02.wcomnet.com>; Wed, 16 Jul 2003 18:39:38 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.113.41]) by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HI400879RTWDY@pmismtp02.wcomnet.com>; Wed, 16 Jul 2003 18:39:35 +0000 (GMT) Date: Wed, 16 Jul 2003 13:39:29 -0500 From: Alan Johnston Subject: Re: AW: [Sipping] Question on INVITE Initiated Dialog Event Package a nd Automatic C allback In-reply-to: X-Sender: Alan.Johnston@pop.mcit.com To: Rohan Mahy , Stupka Jean-Marie Cc: "'Jonathan Rosenberg'" , "'sipping@ietf.org'" Message-id: <5.2.1.1.0.20030716133411.021f06a8@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: <931A17FBB884D411B02B0008C70D9E2ABF1314@mchh243e.mchh.siemens.de> Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 Jean-Marie, The SIP Service Examples section 2.17 shows exactly this flow with a SUBSCRIBE outside of the dialog (which ended with the 486). Thanks, Alan Johnston MCI At 05:21 AM 7/15/2003 -0700, Rohan Mahy wrote: >Jean-Marie, > >It seems perfectly reasonable to send a SUBSCRIBE to the dialog package >outside of a dialog. The default behavior would be to send a list of >dialogs but with no dialog information or peer information. I believe >this is sufficient to build a callback service. > >thanks, >-rohan > > > >On Tuesday, July 15, 2003, at 02:53 AM, Stupka Jean-Marie wrote: > >>Jonathan, >> >>I doubt that sending the SUBSCRIBE request for the dialog package outside >>of any dialog is possible in case of automatic callback, since the >>required data are no more available. >> >>The problem is that when a 486 is received, the dialog initiated by the >>INVITE terminates and, the data related to that dialog (including the >>called user number) disappear. Therefore it is no more possible to send >>the SUBSCRIBE to request automatic callback for this destination. >> >>A possible solution would be to keep for a short period of time the data >>of the previous call attempt (i.e. the called user number, the bearer >>description, ...) at the user agent after a 486 is received. This would >>allow the user agent to re-use the called user number and other data from >>the preceding call attempt for the SUBSCRIBE request and for the >>subsequent call after the remote user is free. However, the procedure of >>retaining data is not foreseen in RFC 3261. >> >>A better (more economical and user friendly) solution would be to keep at >>the user agent only when an automatic callback is possible (e.g. not >>precluded by other services at the remote user side, lacking network >>resources, etc.). This would require to extend the 486 with a "Automatic >>Callback Possible" indication, or to introduce a new message with this meaning. >> >>Jean-Marie >> >>-----Ursprungliche Nachricht----- >>Von: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>Gesendet: Montag, 14. Juli 2003 10:18 >>An: Stupka Jean-Marie >>Cc: 'sipping@ietf.org' >>Betreff: Re: [Sipping] Question on INVITE Initiated Dialog Event Package >>and Automatic C allback >> >> >>The dialog package can be used by subscriptions made both within, and >>outside, of a dialog. So, in the case of automatic callback, the >>caller would, after receiving a 486, send a SUBSCRIBE request for the >>dialog package, and do so outside of any dialog. >> >>-Jonathan R. >> >>Stupka Jean-Marie wrote: >> >>>Hello All, >>> >>>As said in RFC 3265 it is possible to create an event subscription >>>within a pre-existing dialog, e.g. a dialog created by an INVITE. >>>In my understanding, this is the intention of >>>draft-ietf-sipping-dialog-package-02.txt. >>> >>>According to the (PSTN) Automatic Callback given as example >>>application in the introduction of this draft, user A can request a >>>callback when user B hangs-up. User A off course needs to get the >>>information that user B is busy before requesting the automatic >>>callback, i.e. receive a "486 Busy Here" message. However, all >>>early dialogs are considered terminated upon reception of a non-2xx >>>final response (13.2.2.3 of RFC 3261). As consequence, the dialog >>>and thus the data of the preceding call attempt are no more >>>available and the callback cannot be requested. >>> >>>Can somebody provide clarification of the applicability of RFC 3265 >>>and the draft-ietf-sipping-dialog-package-02.txt to Automatic >>>Callback? >>> >>>Regards, >>> >>>Jean-Marie >>> >>> >>>_______________________________________________ Sipping mailing >>>list https://www1.ietf.org/mailman/listinfo/sipping This list is >>>for NEW development of the 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 Wed Jul 16 14:54: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 OAA12541 for ; Wed, 16 Jul 2003 14:54: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 19crPn-0006FH-9z for sipping-archive@odin.ietf.org; Wed, 16 Jul 2003 14:54:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GIsBMS024001 for sipping-archive@odin.ietf.org; Wed, 16 Jul 2003 14:54:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crPn-0006F2-6b for sipping-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 14:54: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 OAA12500 for ; Wed, 16 Jul 2003 14:54:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19crPk-0002CG-00 for sipping-web-archive@ietf.org; Wed, 16 Jul 2003 14:54:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19crPe-0002CD-00 for sipping-web-archive@ietf.org; Wed, 16 Jul 2003 14:54:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crPd-0006Be-UU; Wed, 16 Jul 2003 14:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crP7-0006A3-Ou for sipping@optimus.ietf.org; Wed, 16 Jul 2003 14:53: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 OAA12479 for ; Wed, 16 Jul 2003 14:53:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19crP4-0002C6-00 for sipping@ietf.org; Wed, 16 Jul 2003 14:53:27 -0400 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by ietf-mx with esmtp (Exim 4.12) id 19crOu-0002Br-00 for sipping@ietf.org; Wed, 16 Jul 2003 14:53:16 -0400 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HI400A2OSFAKO@firewall.wcom.com> for sipping@ietf.org; Wed, 16 Jul 2003 18:52:22 +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 <0HI400901S7OFK@pmismtp02.wcomnet.com>; Wed, 16 Jul 2003 18:52:21 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.113.41]) by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HI4008LMSDLVV@pmismtp02.wcomnet.com>; Wed, 16 Jul 2003 18:51:23 +0000 (GMT) Date: Wed, 16 Jul 2003 13:51:22 -0500 From: Alan Johnston In-reply-to: <4A3384433CE2AB46A63468CB207E209D4F6555@zoe.office.snowshor e.com> X-Sender: Alan.Johnston@pop.mcit.com To: Eric Burger Cc: sipping Message-id: <5.2.1.1.0.20030716134212.021f7388@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 Subject: [Sipping] Re: Comments on draft-ietf-sipping-cc-conferencing-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: , Eric, Thanks for your comments. See mine below. Thanks, Alan Johnston MCI At 11:09 AM 7/14/2003 -0400, Eric Burger wrote: >[on XCON list, even though a SIPPING draft] [Moved to SIPPING where the discussion belongs] >Section 3.4: >I'm hesitant to say a conference aware UA SHOULD subscribe to conference >state. That's really an application decision. One might suggest it, >e.g., "the UA can subscribe to the conference state." A similar sentiment >goes for the following paragraph. Why would or why would not a UA want to >display information gleaned from SIP? In any event, it is not a protocol >issue, so it doesn't really merit a MAY (or SHOULD). The choice of strength of the statement stems from the fact that subscription to the conference package is a necessary first step if any conference policy, media policy, or floor control is to take place. (The NOTIFY contains the conference policy, media policy, and floor control URIs) Perhaps dropping the normative but explaining the importance of this step unless no further conferencing interaction/services are going to be used by the participant. >Section 4.2: >How else, in the SIP world, would a focus bring a user agent into the >conference other than by INVITE? Maybe the SHOULD here is the inclusion >of the ;isfocus parameter. That said, why is it not MUST? Yes, the SHOULD relates to the isfocus parameter. It is not a MUST because a focus may wish to conceal the fact that it is a focus. >Section 4.3: >Having the scars of Early Media from netann, I would suggest not going >down the path of IVR interactions before session establishment >completes. There are a lot of ugly corner cases to think of and work >around. I would drop the paragraph. OK. I'm not a huge fan either. >Section 4.6: >Same as 4.2, but with REFER. Is the SHOULD that REFER is preferred to a >new INVITE or that ;isfocus SHOULD be in the contact. If the former, this >is the SIPPING work group, the only thing we can spec is SIP stuff, and >thus this is redundant. If it is the latter, then is there a reason >including ;isfocus is not mandatory? Again, it does relate to the isfocus tag and the same argument as above applies. We'll work on rewording some of these requirements to make them more clear. >_______________________________________________ >XCON mailing list >XCON@softarmor.com >http://www.softarmor.com/mailman/listinfo/xcon _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 16 14: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 OAA12700 for ; Wed, 16 Jul 2003 14:57: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 19crSf-0006jx-O1 for sipping-archive@odin.ietf.org; Wed, 16 Jul 2003 14:57:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GIv9sa025904 for sipping-archive@odin.ietf.org; Wed, 16 Jul 2003 14:57:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crSf-0006jj-L7 for sipping-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 14:57: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 OAA12656 for ; Wed, 16 Jul 2003 14:57:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19crSc-0002EJ-00 for sipping-web-archive@ietf.org; Wed, 16 Jul 2003 14:57:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19crSX-0002EG-00 for sipping-web-archive@ietf.org; Wed, 16 Jul 2003 14:57:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crSX-0006gW-QS; Wed, 16 Jul 2003 14:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crSP-0006gJ-Mn for sipping@optimus.ietf.org; Wed, 16 Jul 2003 14:56: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 OAA12645 for ; Wed, 16 Jul 2003 14:56:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19crSM-0002Dy-00 for sipping@ietf.org; Wed, 16 Jul 2003 14:56:50 -0400 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 19crSC-0002D8-00 for sipping@ietf.org; Wed, 16 Jul 2003 14:56:40 -0400 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 17080; Wed, 16 Jul 2003 14:55:27 -0400 (EDT) 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] FWD:I-D ACTION:draft-johnston-sipping-rtcp-summary-00.txt Date: Wed, 16 Jul 2003 14:55:13 -0400 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F6598@zoe.office.snowshore.com> Thread-Topic: [Sipping] FWD:I-D ACTION:draft-johnston-sipping-rtcp-summary-00.txt Thread-Index: AcNLyZW6UJd7rMLSTb6nYKt1aCL7XQAAavaA From: "Eric Burger" To: "Alan Johnston" 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 To be clear, I was endorsing the conclusion of your paper. You examined diverting copies of RTCP summary reports to a third-party = vs. having the third-party subscribe to a 'call statistics' package. = The conclusion was that a subscription was the most sensible. I was = just piling on reasons why your choice was the best, and why third-party = reporting of RTCP is not the best solution. > -----Original Message----- > From: Alan Johnston [mailto:alan.johnston@mci.com] > Sent: Wed, July 16, 2003 2:38 PM > To: Eric Burger > Cc: sipping@ietf.org > Subject: RE: [Sipping] FWD:I-D > ACTION:draft-johnston-sipping-rtcp-summary-00.txt >=20 >=20 > Eric, >=20 > The stated intent is delivery of RTCP XR (extended report)=20 > summary reports,=20 > not individual RTCP SR or RR reports which would generate=20 > much traffic of=20 > little interest. >=20 > Thanks, > Alan. >=20 >=20 > At 11:09 AM 7/14/2003 -0400, Eric Burger wrote: > >Would any reporting system ever be interested in RTCP=20 > messages? I would=20 > >expect network operators (who I presume would be the interested=20 > >third-parties) to be interested in end-of-call summaries=20 > only. Otherwise,=20 > >a service provider of any significant size is signing up for=20 > a significant=20 > >amount of RTCP reporting (flooding?). > > > >Being NOTIFIED of end-of-call statistics is a sensible=20 > option. That way=20 > >you can use the existing SIP security, subscription, and=20 > message routing=20 > >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 :=20 > draft-johnston-sipping-rtcp-summary-00.txt > > > Pages : 9 > > > Date : 2003-6-23 > > > >=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 From exim@www1.ietf.org Wed Jul 16 15:04: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 PAA13080 for ; Wed, 16 Jul 2003 15:04: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 19crZQ-0007ND-TE for sipping-archive@odin.ietf.org; Wed, 16 Jul 2003 15:04:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GJ48th028337 for sipping-archive@odin.ietf.org; Wed, 16 Jul 2003 15:04:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crZQ-0007My-QA for sipping-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 15:04: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 PAA13029 for ; Wed, 16 Jul 2003 15:04:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19crZN-0002Ky-00 for sipping-web-archive@ietf.org; Wed, 16 Jul 2003 15:04:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19crZI-0002Kv-00 for sipping-web-archive@ietf.org; Wed, 16 Jul 2003 15:04:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crZJ-0007Jt-Cs; Wed, 16 Jul 2003 15: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 19crZA-0007JW-PA for sipping@optimus.ietf.org; Wed, 16 Jul 2003 15:03: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 PAA12988 for ; Wed, 16 Jul 2003 15:03:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19crZ7-0002Kp-00 for sipping@ietf.org; Wed, 16 Jul 2003 15:03:49 -0400 Received: from pmesmtp01.wcom.com ([199.249.20.1]) by ietf-mx with esmtp (Exim 4.12) id 19crYx-0002Jv-00 for sipping@ietf.org; Wed, 16 Jul 2003 15:03:39 -0400 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HI400D21STX9D@firewall.wcom.com> for sipping@ietf.org; Wed, 16 Jul 2003 19:01:09 +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 <0HI400A01STUOV@pmismtp02.wcomnet.com>; Wed, 16 Jul 2003 19:01:09 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.113.41]) by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HI400A0MSTTOB@pmismtp02.wcomnet.com>; Wed, 16 Jul 2003 19:01:07 +0000 (GMT) Date: Wed, 16 Jul 2003 14:01:06 -0500 From: Alan Johnston In-reply-to: <4A3384433CE2AB46A63468CB207E209D4F6553@zoe.office.snowshor e.com> X-Sender: Alan.Johnston@pop.mcit.com To: Eric Burger Cc: sipping Message-id: <5.2.1.1.0.20030716135148.021fbdc0@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 Subject: [Sipping] Re: Sidebars Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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:09 AM 7/14/2003 -0400, Eric Burger wrote: >[on XCON list, even though a SIPPING draft] [Moved to SIPPING where discussion belongs] >I still don't get the motivation, use case, or reasoning for REQ-7,8,9 >(sidebars) in draft-ietf-sipping-conferencing-requirements-00. > >Why aren't sidebars different dialogs? Eric, When talking about sidebars, we usually have audio and video sidebars in mind as IM sidebars are somewhat trivial (and common). The motivation is that many user agents only support a single dialog and ones that do support 2 or more dialogs treat the two dialogs as independent sessions (i.e. the media is never mixed and you can only work on one dialog at a time - the other is usually put on hold). If the mixing is being done centrally, entering a sidebar just changes the mix sent to you. In distributed mixing, a sidebar will likely result in an additional media stream being sent to the participant in addition to the other streams. In both these cases, there is no reason (or advantage) to having a separate dialog. There are some corner cases where a non-participant is invited to a sidebar but is not a participant in a conference - look for a discussion of these cases in an upcoming I-D on sidebars which is intended to help clarify some of these sorts of questions. Thanks, Alan Johnston MCI >_______________________________________________ >XCON mailing list >XCON@softarmor.com >http://www.softarmor.com/mailman/listinfo/xcon _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 16 19:31: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 TAA22603 for ; Wed, 16 Jul 2003 19:31: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 19cvju-0005Sz-Sn for sipping-archive@odin.ietf.org; Wed, 16 Jul 2003 19:31:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GNVETk021007 for sipping-archive@odin.ietf.org; Wed, 16 Jul 2003 19:31:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cvju-0005Sk-PV for sipping-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 19:31: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 TAA22587 for ; Wed, 16 Jul 2003 19:31:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cvjt-0004eD-00 for sipping-web-archive@ietf.org; Wed, 16 Jul 2003 19:31:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cvjn-0004eA-00 for sipping-web-archive@ietf.org; Wed, 16 Jul 2003 19: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 19cvji-0005Rj-W9; Wed, 16 Jul 2003 19: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 19cvjE-0005R6-MQ for sipping@optimus.ietf.org; Wed, 16 Jul 2003 19:30: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 TAA22572 for ; Wed, 16 Jul 2003 19:30:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cvjD-0004dx-00 for sipping@ietf.org; Wed, 16 Jul 2003 19:30:31 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cvj2-0004dY-00 for sipping@ietf.org; Wed, 16 Jul 2003 19:30:20 -0400 Received: from dynamicsoft.com ([63.113.46.115]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6GNTZiB011404; Wed, 16 Jul 2003 19:29:36 -0400 (EDT) Message-ID: <3F15DFD9.1010806@dynamicsoft.com> Date: Wed, 16 Jul 2003 19:29: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: "Rosen, Brian" CC: "'Cullen Jennings'" , "'Yutaka Takeda'" , "'sipping@ietf.org'" Subject: Re: [Sipping] RE: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP References: <313680C9A886D511A06000204840E1CF070B5BD8@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF070B5BD8@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rosen, Brian wrote: > > Yeah, except there is no media. > > This does point out, however, the issue of whether KPML is the > way to go for these kinds of problems. In both vmail and > FECC, the abstraction is very clear, the UI less so. For the > "server" to decide which buttons IMHO is not correct. You > should describe the control abstraction, and let the end device > UI designer decide how best to implement that abstraction, based > on the capabilities and design guidelines of the device. That would argue against a stimulus approach (i.e., KPML or HTML). I'm inclined to agree, and the fact that folks created a protocol to control streaming, and that these clients are not web clients, means others agree too. Mike asked: > Hmm. I'd always thought of SIP as a rendezvous > protocol so this seems perfectly natural to me. > Is the general problem here that the SDP > announcement for an RTSP controlled session isn't > defined? Thats part of it. The other part is that RTSP wasn't meant to be used as a control protocol in a session setup by someone else. So, its not entirely clear to me how to use RTSP in this way. Much of my confusion stems around naming and session identification issues, which are done differently in SIP and RTSP. -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 Jul 16 19: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 TAA22744 for ; Wed, 16 Jul 2003 19: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 19cvvS-0006Ps-3g for sipping-archive@odin.ietf.org; Wed, 16 Jul 2003 19:43:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GNhApC024646 for sipping-archive@odin.ietf.org; Wed, 16 Jul 2003 19: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 19cvvR-0006PH-VT for sipping-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 19:43: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 TAA22732 for ; Wed, 16 Jul 2003 19:43:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cvvQ-0004gi-00 for sipping-web-archive@ietf.org; Wed, 16 Jul 2003 19:43:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cvvK-0004gf-00 for sipping-web-archive@ietf.org; Wed, 16 Jul 2003 19:43:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cvvJ-0006JD-8R; Wed, 16 Jul 2003 19: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 19cvud-0006Iq-CF for sipping@optimus.ietf.org; Wed, 16 Jul 2003 19:42: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 TAA22729 for ; Wed, 16 Jul 2003 19:42:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cvub-0004gT-00 for sipping@ietf.org; Wed, 16 Jul 2003 19:42:17 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cvuQ-0004gJ-00 for sipping@ietf.org; Wed, 16 Jul 2003 19:42:06 -0400 Received: from dynamicsoft.com ([63.113.46.115]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6GNfUiB011408; Wed, 16 Jul 2003 19:41:30 -0400 (EDT) Message-ID: <3F15E2A4.6070800@dynamicsoft.com> Date: Wed, 16 Jul 2003 19:41:24 -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: "'Eric Burger'" , sipping Subject: Re: [Sipping] How to report DTMF - conclusion of the app interact ion design team: SIP MESSAGE References: <9BF66EBF6BEFD942915B4D4D45C051F3E861FD@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E861FD@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 To be honest, I am starting to warm on an implicit subscription (though HTTP remains my preference), since NOTIFY is really the method we already have for FEEDBACK. I must say for the life of me, at this moment I cannot enumerate what kind of issues we have had with implicit subscriptions. Adam - can you enumerate them and we can see which ones might or might not apply here? Thanks, Jonathan R. Adam Roach wrote: > Yes, except without the "in a dialog" requirement. You could > call it "CALL" (borrowing the term from RFC 1057). > > More realistically, a specific new method (say, FEEDBACK) that > has semantics of collecting input from a user would seem to be > a well-scoped and reasonable way to go about sending this > information. > > /a > > > >>-----Original Message----- >>From: Eric Burger [mailto:eburger@snowshore.com] >>Sent: Monday, July 14, 2003 13:46 >>To: sipping >>Subject: RE: [Sipping] How to report DTMF - conclusion of the app >>interaction design team: SIP MESSAGE >> >> >>Hmmm. Alan pointed out that would be equivalent to INFO. >>You know, the application-to-application signaling message. >> >> >>>-----Original Message----- >>>From: Eric Burger >>>Sent: Mon, July 14, 2003 11:30 AM >>>To: Adam Roach; Jonathan Rosenberg; sipping >>>Subject: RE: [Sipping] How to report DTMF - conclusion of the app >>>interaction design team: SIP MESSAGE >>> >>> >>>That is incredibly sensible. >>> >>>Sounds like time for a dip into the well of method space for >>>a new method name. Can we get away with, "just like MESSAGE, >>>but without the user interaction expectations"? That is what >>>it is, after all. >>> >>> >>>>-----Original Message----- >>>>From: Adam Roach [mailto:adam@dynamicsoft.com] >>>>Sent: Mon, July 14, 2003 9:47 AM >>>>To: Jonathan Rosenberg; sipping >>>>Subject: RE: [Sipping] How to report DTMF - conclusion of the app >>>>interaction design team: SIP MESSAGE >>>> >>>> >>>> >>>>>7. SIP MESSAGE >>>>> >>>>>Send a SIP MESSAGE request from the client to the application, >>>>>containing the digit sequence to report. >>>>> >>>>>This was a bit of a bending of the semantic of MESSAGE, >> >>which is >> >>>>>really meant for conveying information for display to a user. >>>>>However, the issue is mostly philosophical in nature. We didn't >>>>>see any particular technical issue that would prevent this from >>>>>working, unlike all of the above ones which had >> >>technical issues. >> >>>>If we're throwing philosophical objections about the intended >>>>semantics of a method out the window, I'm left wondering why >>>>MESSAGE was selected over OPTIONS for this purpose. >>>> >>>>All other things being equal, receipt of a misdirected OPTIONS >>>>will never have harmful effects; meanwhile, receipt of a >>>>MESSAGE with an unrecognized content type has an extremely >>>>high probability of causing a nonzero number of implementations >>>>to pop up a window saying something like: >>>> >>>> +------------------------------------------------------------+ >>>> | 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] | >>>> +------------------------------------------------------------+ >>>> >>>>This is what I most emphatically do *not* want to happen. It is >>>>the key reason that I push back against use of MESSAGE for >>>>anything that is not to be rendered to a user, and it is a >>>>proof point that the objections to abusing MESSAGE for general >>>>purpose RPC go beyond philosophy into user experience. >>>> >>>>/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 >> >> > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 Jul 16 20:09: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 UAA23239 for ; Wed, 16 Jul 2003 20:09: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 19cwKc-0007jG-Ej for sipping-archive@odin.ietf.org; Wed, 16 Jul 2003 20:09:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H09ABY029704 for sipping-archive@odin.ietf.org; Wed, 16 Jul 2003 20:09:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cwKc-0007j1-Bb for sipping-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 20:09: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 UAA23225 for ; Wed, 16 Jul 2003 20:09:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cwKa-0004uM-00 for sipping-web-archive@ietf.org; Wed, 16 Jul 2003 20:09:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cwKU-0004uJ-00 for sipping-web-archive@ietf.org; Wed, 16 Jul 2003 20:09:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cwKT-0007ht-T8; Wed, 16 Jul 2003 20: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 19cwKQ-0007hS-Iw for sipping@optimus.ietf.org; Wed, 16 Jul 2003 20:08: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 UAA23211 for ; Wed, 16 Jul 2003 20:08:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cwKO-0004u2-00 for sipping@ietf.org; Wed, 16 Jul 2003 20:08:56 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cwKD-0004tr-00 for sipping@ietf.org; Wed, 16 Jul 2003 20:08:45 -0400 Received: from dynamicsoft.com ([63.113.46.115]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6H080iB011422; Wed, 16 Jul 2003 20:08:01 -0400 (EDT) Message-ID: <3F15E8DA.5050804@dynamicsoft.com> Date: Wed, 16 Jul 2003 20:07:54 -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: "'sipping@ietf.org'" Subject: Re: [Sipping] New Tones draft (was: "who plays the tone" or something like that) References: <7F9D6ACC-A53E-11D7-8E0D-0003938AF740@cisco.com> In-Reply-To: <7F9D6ACC-A53E-11D7-8E0D-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 Rohan, I just got around to reading this draft. I think its neat. You say in your note below that its linked to app-interaction, but you don't use the app-interaction framework. I believe this is precisely the kind of thing we want to do with app-interaction - its a stimulus interface to the user. That means that you should be using app-info headers to convey the information, for example. Indeed, there are probably existing xml formats which may even do this. -Jonathan R. Rohan Mahy wrote: > Hi, > > I wrote the following draft in order to provide some discussion on > alternatives to in-band early-media ringback, and to discuss the issue > of playing tones in general which I believe is inherently linked to 3pcc > and application interaction. > > http://www.softarmor.com/sipping/drafts/draft-mahy-sipping-tones-00.html > http://www.softarmor.com/sipping/drafts/draft-mahy-sipping-tones-00.txt > > comments welcome. > thx, > -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 > -- 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 Jul 16 20:14: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 UAA23377 for ; Wed, 16 Jul 2003 20:14: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 19cwPQ-00082l-08 for sipping-archive@odin.ietf.org; Wed, 16 Jul 2003 20:14:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H0E7Ur030915 for sipping-archive@odin.ietf.org; Wed, 16 Jul 2003 20:14:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cwPP-00082Y-T6 for sipping-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 20:14: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 UAA23352 for ; Wed, 16 Jul 2003 20:14:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cwPN-0004wd-00 for sipping-web-archive@ietf.org; Wed, 16 Jul 2003 20:14:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cwPI-0004wa-00 for sipping-web-archive@ietf.org; Wed, 16 Jul 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 19cwPJ-0007xT-Cb; Wed, 16 Jul 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 19cwOK-0007x6-Sz for sipping@optimus.ietf.org; Wed, 16 Jul 2003 20:13: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 UAA23338 for ; Wed, 16 Jul 2003 20:12:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cwOI-0004wI-00 for sipping@ietf.org; Wed, 16 Jul 2003 20:12:58 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cwO8-0004w4-00 for sipping@ietf.org; Wed, 16 Jul 2003 20:12:48 -0400 Received: from dynamicsoft.com ([63.113.46.115]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6H0BZiB011425; Wed, 16 Jul 2003 20:11:36 -0400 (EDT) Message-ID: <3F15E9B2.8020503@dynamicsoft.com> Date: Wed, 16 Jul 2003 20:11:30 -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: Mpierce1@aol.com CC: eburger@snowshore.com, sipping@ietf.org Subject: Re: [Sipping] New Tones draft (was: "who plays the tone" or something like th... References: <5a.1f5113cc.2c444abc@aol.com> In-Reply-To: <5a.1f5113cc.2c444abc@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I find the notion that an application can instruct a user to send media to its peer in a call - frightening. It can be the source of some potentially bad attacks where a not-so-nice application has you sending media to your friends that you otherwise would not want to send. Its particularly worrisome if you go beyond just a "tones" markup and consider something much richer like VoiceXML. -Jonathan R. Mpierce1@aol.com wrote: > In a message dated 7/14/2003 11:11:46 AM Eastern Daylight Time, > eburger@snowshore.com writes: > > >> think direction 1 (user agent to user) is the only sensible thing for >> this draft. I guess that presupposes the whole idea is sensible in >> the first place Z-) > > > > > I believe that being able to tell the UA to send the tone in either > direction or both is a basic requirement. If not included now, we'll be > sorry later. I believe it is easy to find cases for the use of each. > > Mike Pierce -- 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 Jul 16 20:33: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 UAA23777 for ; Wed, 16 Jul 2003 20:33: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 19cwhr-0000a5-KF for sipping-archive@odin.ietf.org; Wed, 16 Jul 2003 20:33:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H0XBb3002230 for sipping-archive@odin.ietf.org; Wed, 16 Jul 2003 20: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 19cwhr-0000Zt-Fi for sipping-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 20: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 UAA23769 for ; Wed, 16 Jul 2003 20:33:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cwhp-00057a-00 for sipping-web-archive@ietf.org; Wed, 16 Jul 2003 20:33:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cwhj-00057X-00 for sipping-web-archive@ietf.org; Wed, 16 Jul 2003 20: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 19cwhh-0000Yz-KB; Wed, 16 Jul 2003 20: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 19cwgr-0000Yb-Jk for sipping@optimus.ietf.org; Wed, 16 Jul 2003 20:32: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 UAA23765 for ; Wed, 16 Jul 2003 20:32:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cwgp-00057D-00 for sipping@ietf.org; Wed, 16 Jul 2003 20:32:07 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cwge-000576-00 for sipping@ietf.org; Wed, 16 Jul 2003 20:31:56 -0400 Received: from dynamicsoft.com ([63.113.46.115]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6H0VJiB011429; Wed, 16 Jul 2003 20:31:20 -0400 (EDT) Message-ID: <3F15EE52.7030308@dynamicsoft.com> Date: Wed, 16 Jul 2003 20:31:14 -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: Eric Burger CC: Alan Johnston , sipping@ietf.org Subject: Re: [Sipping] FWD:I-D ACTION:draft-johnston-sipping-rtcp-summary-00.txt References: <4A3384433CE2AB46A63468CB207E209D4F6598@zoe.office.snowshore.com> In-Reply-To: <4A3384433CE2AB46A63468CB207E209D4F6598@zoe.office.snowshore.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It seems to me that this is all about network management. The question is how a provider monitors and manages the quality of calls in a VoIP network with lots of endpoints. In that case, I think there are some important higher level questions that need to be asked: 1. Is the aim of collection to monitor overall network quality (i.e., performance management)? 2. Is the aim of the collection to look for faults (fault management)? If the problem is (1), real time reporting is not needed. It seems to me that to have each phone send a summary report to the provider at the end of each call might be burdensome. Why not just sweep these statistics up periodically using SNMP, with the SNMP MIB? Once a day or something would work, if not less frequently even. This is a standard technique for collecting statistics. Indeed, one probably could sample subsets of the phones to obtain information - not all of the data is needed. If the problem is (2), it seems that you don't want notifications for all calls - only ones where there is a problem. Thus, if one had a managed object representing a loss threshold, you might set a trap to get fired when the threshold is crossed. All of the standard problems of alarm correlation and root cause analysis would then apply, and standard network management tools exist for that. Either way, its not clear to me that SIP is the right tool for network management. Thanks, Jonathan R. Eric Burger wrote: > To be clear, I was endorsing the conclusion of your paper. > > You examined diverting copies of RTCP summary reports to a > third-party vs. having the third-party subscribe to a 'call > statistics' package. The conclusion was that a subscription was > the most sensible. I was just piling on reasons why your choice > was the best, and why third-party reporting of RTCP is not the best > solution. > > >> -----Original Message----- From: Alan Johnston >> [mailto:alan.johnston@mci.com] Sent: Wed, July 16, 2003 2:38 PM >> To: Eric Burger Cc: sipping@ietf.org Subject: RE: [Sipping] >> FWD:I-D ACTION:draft-johnston-sipping-rtcp-summary-00.txt >> >> >> Eric, >> >> The stated intent is delivery of RTCP XR (extended report) >> summary reports, not individual RTCP SR or RR reports which would >> generate much traffic of little interest. >> >> Thanks, Alan. >> >> >> At 11:09 AM 7/14/2003 -0400, 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 > -- 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 Jul 17 02:17: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 CAA16519 for ; Thu, 17 Jul 2003 02:17: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 19d24M-0002Up-EI for sipping-archive@odin.ietf.org; Thu, 17 Jul 2003 02:16:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H6Gk6F009589 for sipping-archive@odin.ietf.org; Thu, 17 Jul 2003 02:16:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d24K-0002Ua-RY for sipping-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 02:16:44 -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 CAA16440 for ; Thu, 17 Jul 2003 02:16: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 19d23g-0002Qr-En; Thu, 17 Jul 2003 02:16:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d22l-0002GS-7b for sipping@optimus.ietf.org; Thu, 17 Jul 2003 02: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 CAA16259 for ; Thu, 17 Jul 2003 02:15:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d22h-0001M5-00 for sipping@ietf.org; Thu, 17 Jul 2003 02:15:03 -0400 Received: from pxf01lhr.egham.rim.net ([193.109.81.7] helo=mhs02lhr.blackberry.net) by ietf-mx with esmtp (Exim 4.12) id 19d22W-0001Lb-00 for sipping@ietf.org; Thu, 17 Jul 2003 02:14:52 -0400 Received: from mailrouter01.bwc.prod.uk.blackberry (mailrouter01.bwc.prod.uk.blackberry [172.16.80.216]) by mhs02lhr.blackberry.net (8.11.7+Sun/8.11.3) with ESMTP id h6H6EIG11588 for ; Thu, 17 Jul 2003 06:14:18 GMT Received: from engine02.bwc.prod.uk.blackberry (load-bal-out.bwc.prod.uk.blackberry [172.16.94.133]) by mailrouter01.bwc.prod.uk.blackberry (8.12.8/8.12.8) with SMTP id h6H6EHSt029289 for sipping@ietf.org; Thu, 17 Jul 2003 06:14:17 GMT Message-ID: <2028902718-1058422456-cardhu_blackberry.rim.net-24036-@engine02.bwc.prod.uk.blackberry> REPLY-TO: guido.gybels@rnid.org.uk FROM: "Guido Gybels" Importance: Normal To: sipping@ietf.org Date: Thu, 17 Jul 2003 06:12:24 +0000 GMT Content-type: text/plain MIME-Version: 1.0 Subject: [Sipping] Sipdev adhoc meeting: the req. for character-by-character interactive text Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , All, I posted this link yesterday morning, but it didn't make it to the list. So, once again, in preparation for the ad-hoc meeting this morning, here is a link to a short clarification on what the requirements are for interactive texting and what is proposed as the solution: http://www.ictrnid.org.uk/sipping/sipdev.html 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 From exim@www1.ietf.org Thu Jul 17 03:01: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 DAA19109 for ; Thu, 17 Jul 2003 03:01: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 19d2lP-00064F-5R for sipping-archive@odin.ietf.org; Thu, 17 Jul 2003 03:01:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H71FF0023322 for sipping-archive@odin.ietf.org; Thu, 17 Jul 2003 03:01:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d2lO-000645-T0 for sipping-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 03:01: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 DAA19088 for ; Thu, 17 Jul 2003 03:01:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d2lL-0001xS-00 for sipping-web-archive@ietf.org; Thu, 17 Jul 2003 03:01:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d2lF-0001xP-00 for sipping-web-archive@ietf.org; Thu, 17 Jul 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 19d2lB-000632-Rb; Thu, 17 Jul 2003 03: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 19d2kc-00062F-IQ for sipping@optimus.ietf.org; Thu, 17 Jul 2003 03:00: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 DAA19072 for ; Thu, 17 Jul 2003 03:00:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d2kY-0001x2-00 for sipping@ietf.org; Thu, 17 Jul 2003 03:00:22 -0400 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 19d2kN-0001wT-00 for sipping@ietf.org; Thu, 17 Jul 2003 03:00:11 -0400 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 1847; Thu, 17 Jul 2003 02:58:58 -0400 (EDT) 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] FWD:I-D ACTION:draft-johnston-sipping-rtcp-summary-00.txt Date: Thu, 17 Jul 2003 02:59:17 -0400 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F65B2@zoe.office.snowshore.com> Thread-Topic: [Sipping] FWD:I-D ACTION:draft-johnston-sipping-rtcp-summary-00.txt Thread-Index: AcNL+tjEYPR0znEpRRKgtjKKSz2Z1gANdwxQ From: "Eric Burger" To: "Jonathan Rosenberg" Cc: "Alan Johnston" , 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 Agreed. This does look much more like an SNMP problem than a SIP or = RTCP problem. > -----Original Message----- From: Jonathan Rosenberg = [mailto:jdrosen@dynamicsoft.com] [snip] > It seems to me that this is all about network management. The question > is how a provider monitors and manages the quality of calls in a VoIP > network with lots of endpoints. [snip] > Why not just sweep these statistics up periodically using SNMP, with > the SNMP MIB?=20 [snip] > Either way, its not clear to me that SIP is the right tool for network > management. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 17 03:49: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 DAA21129 for ; Thu, 17 Jul 2003 03:49: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 19d3Vr-0001OP-Fp for sipping-archive@odin.ietf.org; Thu, 17 Jul 2003 03:49:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H7nF4F005347 for sipping-archive@odin.ietf.org; Thu, 17 Jul 2003 03:49:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3Vr-0001OA-9w for sipping-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 03:49: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 DAA21084 for ; Thu, 17 Jul 2003 03:49:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d3Vo-0002Wp-00 for sipping-web-archive@ietf.org; Thu, 17 Jul 2003 03:49:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d3Vi-0002Wj-00 for sipping-web-archive@ietf.org; Thu, 17 Jul 2003 03:49:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3Ve-0001LV-OO; Thu, 17 Jul 2003 03:49:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cwfq-0000RF-EH for sipping@optimus.ietf.org; Wed, 16 Jul 2003 20:31: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 UAA23752 for ; Wed, 16 Jul 2003 20:31:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cwfo-00056w-00 for sipping@ietf.org; Wed, 16 Jul 2003 20:31:04 -0400 Received: from ckmso1.att.com ([12.20.58.69] helo=ckmso1.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 19cwfd-00056T-00 for sipping@ietf.org; Wed, 16 Jul 2003 20:30:53 -0400 Received: from maillennium.att.com ([135.25.114.99]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h6H0U38Z009103 for ; Wed, 16 Jul 2003 20:30:03 -0400 Received: from fisherlatitude (unknown[135.210.82.64](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20030717002812gw100r9hi1e>; Thu, 17 Jul 2003 00:28:13 +0000 From: "Steve Fisher" To: "'sipping'" Subject: RE: [Sipping] How to report DTMF - conclusion of the app interaction design team: SIP MESSAGE Date: Wed, 16 Jul 2003 20:29:22 -0400 Message-ID: <001401c34bfa$78c41750$4052d287@fisherlatitude> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-reply-to: <3F0AEA40.4020208@dynamicsoft.com> Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Great work on the app interaction drafts! I have a few comments/questions: 1) The framework document refers to both "one shot" and "monitor" models, and while KPML supports both, support for the "monitor" model is somewhat awkward (requires having the device quarantine digits and then issue a new KPML document via a re-INVITE). Is there a reason the initial KPML document couldn't just specify which model was desired for that particular interaction, and, if "monitor" was desired, simply keep monitoring for the specified digits? If we've adandoned HTTP reporting, I don't see what the downside to this would be. 2) I think that some example message flows would be helpful to tie all these pieces together, and I would be happy to help draft some if you'd like. 3) An Jonathan said in the note below, the KPML draft still describes HTTP reporting, and also mentions NOTIFY. Just to clarify -- are these mistakes, and the team is now only proposing to use MESSAGE? 4) I also would prefer a new SIP method, instead of overloading MESSAGE. 5) I'm confused how the device determines the Request-URI for the MESSAGE. The KPML document says: When the user enters keypress(es) that match a tag, the user device will issue a SIP MESSAGE to the Request-URI specified by the href attribute. and The specification of any scheme-specific part, that is, anything following the colon in "sip:", is an error. The interpreter MUST reject the request. If the href attribute can't specify any scheme-specific part, how does the device determine the Request-URI from the href attribute? Thanks, and great work! Steve -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Tuesday, July 08, 2003 11:59 AM To: sipping Subject: [Sipping] How to report DTMF - conclusion of the app interaction design team: SIP MESSAGE Folks, The application interaction design team is near completion of our set of documents: http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-app-interact ion-framework-01.txt http://www.ietf.org/internet-drafts/draft-jennings-sip-app-info-01.txt http://www.ietf.org/internet-drafts/draft-burger-sipping-kpml-02.txt http://www.ietf.org/internet-drafts/draft-culpepper-sipping-app-interact -reqs-03.txt There are really few open issues that we are aware of. The main point of contention, and I think the issue most folks want to see a decision on, is how to actually convey the DTMF to the application when KPML is used. Even within the design team we never really had strong consensus here. However, in the interests of progress, we chose the path we felt was the one of "least evil". That path was to use a SIP MESSAGE request from the client to the application, with content that contains the digits. Not ideal, no doubt. I suspect its also not clear from the documents that this was our decision. The KPML draft has some artifact text that mentions NOTIFY, and it also still talks about HTTP. The team did decide not to go with those. Here were the choices, and the reasoning we went through: 1. Use HTTP POST, as is done in VoiceXML, HTML, WML This approach works well when the post returns another script to execute, as is the case for the above markups. However, because KPML has no presentation, only input, there is really little value in doing that. KPML is useful for two things. The first are "one shots", where the KPML waits for a single sequence, and when it finds it, reports it to the application. From there, the application interacts with the user using media, and the KPML script is done. Common case: long pound in pre-paid. Another modality is what I call "monitor", where the KPML stays resident for the ENTIRE call, and simply reports sequences as it gets them. Once it reports one, it continues waiting for more. Neither of these modes quite fit the bill for HTTP. It could be done, by having the HTTP POST return the same script that is currently running. Not perfect, though. Furthermore, folks were concerned that HTTP was too much effort to put on a device just to report DTMF. 2. Use SIP INFO No doubt this represents the bulk of the implementations today, all non-interoperable unfortunately. The problem with INFO is that the message from the client to the application needs to be OUTSIDE the dialog. Otherwise, every proxy on the path sees it. There are lots of other problems with sending INFO within the dialog of the call setup. So, once you decide that the messaging from the client to the app is outside the dialog, you can't use INFO. INFO is constrained to be within the scope of a dialog. 3. Use NOTIFY, have App-Info create an implicit subscription The client would send a NOTIFY to the application when the digit sequence was matched. There would be no SUBSCRIBE. Rather, the App-Info header, which was used to pass the script to the client, would effectively create an implicit subscription. Implicit subscriptions have all kinds of troubles, which have been discussed on the list. We then need to manage a dialog between the client and application just for reporting DTMF. 4. Use an explicit SUBSCRIBE from the application to the client This has lots of problems. First, it needs to be done outside of the original call setup dialog. That means it needs GRUUs for the application to target the SUBSCRIBE to the specific UA instance that made the call. It also introduces a lot of extra overhead, and would repeat information in the App-Info header (i.e., an expression of interest) 5. New Method We could invent a new method, like REPORT-EVENT or something, sent from the client to the application. However, that seemed too specialized. Also not clear what is really gained from a new method above MESSAGE, see below. 6. Messaging Sessions Use an INVITE from the client to the application, for the purpose of setting up a messaging session, ala MSRP. Once the session is setup, convey the digits using content in MSRP messages. This seemed like a lot of overhead and work for what is probably going to be one or two messages. 7. SIP MESSAGE Send a SIP MESSAGE request from the client to the application, containing the digit sequence to report. This was a bit of a bending of the semantic of MESSAGE, which is really meant for conveying information for display to a user. However, the issue is mostly philosophical in nature. We didnt see any particular technical issue that would prevent this from working, unlike all of the above ones which had technical issues. So, as the path of least ugliness and minimal resistance, we went for MESSAGE. No doubt folks will have comments. The design team is at the point now where broader group input is needed to determine if there is consensus around this, or any other, direction. We felt it was important to capture our thinking on the options above, to give people a context for our decision and to serve as a grounding for further discussion. So, please fire away. 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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 17 03:49: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 DAA21145 for ; Thu, 17 Jul 2003 03:49: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 19d3Vt-0001Oh-Ee for sipping-archive@odin.ietf.org; Thu, 17 Jul 2003 03:49:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H7nHQL005365 for sipping-archive@odin.ietf.org; Thu, 17 Jul 2003 03:49:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3Vr-0001OS-T6 for sipping-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 03:49: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 DAA21088 for ; Thu, 17 Jul 2003 03:49:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d3Vo-0002Wm-00 for sipping-web-archive@ietf.org; Thu, 17 Jul 2003 03:49:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d3Vi-0002Wf-00 for sipping-web-archive@ietf.org; Thu, 17 Jul 2003 03:49:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3Vf-0001Lu-R5; Thu, 17 Jul 2003 03:49:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cytj-0007Yd-Q6 for sipping@optimus.ietf.org; Wed, 16 Jul 2003 22:53: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 WAA28042 for ; Wed, 16 Jul 2003 22:53:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cytg-0006XD-00 for sipping@ietf.org; Wed, 16 Jul 2003 22:53:32 -0400 Received: from bbs.izone.net.au ([202.160.128.31]) by ietf-mx with esmtp (Exim 4.12) id 19cytU-0006XA-00 for sipping@ietf.org; Wed, 16 Jul 2003 22:53:21 -0400 Received: from bazza (dialup-67.34.221.203.acc14-dryb-mel.comindico.com.au [203.221.34.67]) by bbs.izone.net.au (8.11.2/8.11.2) with SMTP id h6H2P8f11585; Thu, 17 Jul 2003 12:25:24 +1000 Message-ID: <003901c34c0e$bb293940$4322ddcb@bazza> From: "Barry Dingle" To: , Cc: , , , , , , , , , , , , "Barry Dingle" References: <30d9fb02.a43a9837.8189000@imap01.eu.blackberry.net> Date: Thu, 17 Jul 2003 12:53:04 +1000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01C34C62.5D094360" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Subject: [Sipping] Re: Sipdev: an attempt to clarify the requirements for interactive texting as a basic service Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_001A_01C34C62.5D094360 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Guido, All I can say is BRILLIANT !!! =20 Your paper informs people not so familiar with the issues in a clear and = concise way of the issues.=20 I will be using your paper in our work to develop an Any-to-Any Text = plan for Australia. /Barry DINGLE Project Manager - ACIF Any-to-Any Text Connectivity Options WG=20 Telecommunications Consultant Fellow of the University of Melbourne barry.dingle@bigfoot.com.au Mob: +61 (0)41 911 7578 Fixed: +61 (0)3 9725 3937 ----- Original Message -----=20 From: Guido Gybels=20 To: sipping@ietf.org=20 Cc: barry.dingle@bigfoot.com.au ; oran@cisco.com ; rohan@cisco.com ; = james.hamlin@rnid.org.uk ; mike.spanner@rnid.org.uk ; A.vWijk@viataal.nl = ; frank.shearar@rnid.org.uk ; jamie.buchanan@rnid.org.uk ; = jdrosen@dynamicsoft.com ; eburger@snowshore.com ; hgs@cs.columbia.edu ; = dean.willis@softarmor.com ; mhammer@cisco.com=20 Sent: Wednesday, July 16, 2003 6:17 PM Subject: Sipdev: an attempt to clarify the requirements for = interactive texting as a basic service All, After the sometimes heated debate of the last couple of months and in = preparation for the ad-hoc meeting on Henry's draft tomorrow, I have now = written a short=20 clarification on what the requirements are for interactive texting and = what is proposed as the solution. You can read this short document here: http://www.ictrnid.org.uk/sipping/sipdev.html Please do read it, otherwise we'll keep going round in circles. If you = have any questions or comments, feel free to grab me during coffee = breaks etc. For the ad-hoc meeting tomorrow, I'm preparing some = additional slides that show how traffic slows and how we interwork with = other networks and legacy technology. 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 ------=_NextPart_000_001A_01C34C62.5D094360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Guido,
 
All I can say is BRILLIANT !!! 
 
Your paper informs people not so familiar with = the issues=20 in a clear and concise way of the issues.
 
I will be using your paper in our work to develop an = Any-to-Any Text plan for Australia.
 
/Barry DINGLE
Project Manager - ACIF Any-to-Any Text = Connectivity=20 Options WG
Telecommunications Consultant
Fellow of the University = of=20 Melbourne
 
barry.dingle@bigfoot.com.au
 
Mob: +61 (0)41 911 7578
Fixed: +61 (0)3 9725 3937
----- Original Message -----
From:=20 Guido Gybels =
Cc: barry.dingle@bigfoot.com.au ; oran@cisco.com ; rohan@cisco.com ; james.hamlin@rnid.org.uk = ; mike.spanner@rnid.org.uk = ; A.vWijk@viataal.nl ; frank.shearar@rnid.org.uk = ; jamie.buchanan@rnid.org.uk= ; jdrosen@dynamicsoft.com ; = eburger@snowshore.com ; hgs@cs.columbia.edu ; dean.willis@softarmor.com = ; mhammer@cisco.com=20
Sent: Wednesday, July 16, 2003 = 6:17=20 PM
Subject: Sipdev: an attempt to = clarify=20 the requirements for interactive texting as a basic service

All,

After the sometimes heated debate of the = last=20 couple of months and in preparation for the ad-hoc meeting on Henry's = draft=20 tomorrow, I have now written a short
clarification on what the=20 requirements are for interactive texting and what is proposed as the = solution.=20 You can read this short document here:

http://www.ictrnid= .org.uk/sipping/sipdev.html

Please=20 do read it, otherwise we'll keep going round in circles. If you have = any=20 questions or comments, feel free to grab me during coffee breaks etc. = For the=20 ad-hoc meeting tomorrow, I'm preparing some additional slides that = show how=20 traffic slows and how we interwork with other networks and legacy=20 technology.

Guido

Guido Gybels
Director of New=20 Technologies

RNID, 19-23 Featherstone Street
London EC1Y = 8SL,=20 UK
Tel +44(0)20-7294 3713
Fax +44(0)20-7296=20 8069
------=_NextPart_000_001A_01C34C62.5D094360-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 17 03:49:49 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 DAA21173 for ; Thu, 17 Jul 2003 03:49: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 19d3Vx-0001V3-B1 for sipping-archive@odin.ietf.org; Thu, 17 Jul 2003 03:49:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H7nKJi005586 for sipping-archive@odin.ietf.org; Thu, 17 Jul 2003 03:49:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3Vw-0001RS-Ec for sipping-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 03:49: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 DAA21089 for ; Thu, 17 Jul 2003 03:49:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d3Vo-0002Wi-00 for sipping-web-archive@ietf.org; Thu, 17 Jul 2003 03:49:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d3Vi-0002We-00 for sipping-web-archive@ietf.org; Thu, 17 Jul 2003 03:49:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3Vd-0001L6-Mn; Thu, 17 Jul 2003 03: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 19chUq-0001Te-Ar for sipping@optimus.ietf.org; Wed, 16 Jul 2003 04:18: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 EAA20483 for ; Wed, 16 Jul 2003 04:18:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19chUn-0004VR-00 for sipping@ietf.org; Wed, 16 Jul 2003 04:18:41 -0400 Received: from pxf01lhr.egham.rim.net ([193.109.81.7] helo=mrs01lhr.blackberry.net) by ietf-mx with esmtp (Exim 4.12) id 19chUX-0004VF-00 for sipping@ietf.org; Wed, 16 Jul 2003 04:18:25 -0400 Received: from mailrouter01.bwc.prod.uk.blackberry (mailrouter01.bwc.prod.uk.blackberry [172.16.80.216]) by mrs01lhr.blackberry.net (8.11.7+Sun/8.11.3) with ESMTP id h6G8HSu02285; Wed, 16 Jul 2003 09:17:28 +0100 (BST) Received: from imap01.eu.blackberry.net (imap01.eu.blackberry.net [172.16.80.224]) by mailrouter01.bwc.prod.uk.blackberry (8.12.8/8.12.8) with ESMTP id h6G8HQSt028683; Wed, 16 Jul 2003 08:17:26 GMT Received: from imap01.eu.blackberry.net (localhost.eu.blackberry.net [127.0.0.1]) by imap01.eu.blackberry.net (Mirapoint Messaging Server MOS 3.3.2-CR) with ESMTP id ABA09205; Wed, 16 Jul 2003 08:17:18 GMT Received: from 81.160.243.24 by imap01.eu.blackberry.net (Mirapoint Messaging Server MOS 3.3.2-CR) with HTTPS/1.1; Wed, 16 Jul 2003 09:17:18 +0100 Date: Wed, 16 Jul 2003 09:17:18 +0100 From: Guido Gybels To: sipping@ietf.org Cc: barry.dingle@bigfoot.com.au, oran@cisco.com, rohan@cisco.com, james.hamlin@rnid.org.uk, mike.spanner@rnid.org.uk, A.vWijk@viataal.nl, frank.shearar@rnid.org.uk, jamie.buchanan@rnid.org.uk, jdrosen@dynamicsoft.com, eburger@snowshore.com, hgs@cs.columbia.edu, dean.willis@softarmor.com, mhammer@cisco.com Reply-To: guido.gybels@rnid.org.uk X-Mailer: Webmail Mirapoint Direct 3.3.2-CR MIME-Version: 1.0 Message-Id: <30d9fb02.a43a9837.8189000@imap01.eu.blackberry.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Sipdev: an attempt to clarify the requirements for interactive texting as a basic service Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 All, After the sometimes heated debate of the last couple of months and in preparation for the ad-hoc meeting on Henry's draft tomorrow, I have now written a short clarification on what the requirements are for interactive texting and what is proposed as the solution. You can read this short document here: http://www.ictrnid.org.uk/sipping/sipdev.html Please do read it, otherwise we'll keep going round in circles. If you have any questions or comments, feel free to grab me during coffee breaks etc. For the ad-hoc meeting tomorrow, I'm preparing some additional slides that show how traffic slows and how we interwork with other networks and legacy technology. 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 From exim@www1.ietf.org Thu Jul 17 04:23: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 EAA22693 for ; Thu, 17 Jul 2003 04: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 19d42l-0004Zr-Iy for sipping-archive@odin.ietf.org; Thu, 17 Jul 2003 04:23:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H8NFNk017591 for sipping-archive@odin.ietf.org; Thu, 17 Jul 2003 04:23:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d42j-0004Ze-8F for sipping-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 04: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 EAA22685 for ; Thu, 17 Jul 2003 04:23:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d42g-00031W-00 for sipping-web-archive@ietf.org; Thu, 17 Jul 2003 04:23:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d42a-00031T-00 for sipping-web-archive@ietf.org; Thu, 17 Jul 2003 04:23:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d42X-0004Lv-95; Thu, 17 Jul 2003 04: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 19d41n-0004F1-R8 for sipping@optimus.ietf.org; Thu, 17 Jul 2003 04:22: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 EAA22628 for ; Thu, 17 Jul 2003 04:22:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d41k-00030V-00 for sipping@ietf.org; Thu, 17 Jul 2003 04:22:12 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 19d41Z-00030K-00 for sipping@ietf.org; Thu, 17 Jul 2003 04:22:01 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id h6H8Lmt04778; Thu, 17 Jul 2003 10:21:48 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id h6H8LlK15950; Thu, 17 Jul 2003 10:21:47 +0200 (MEST) Received: from mchh253e.mchh.siemens.de (mchh253e.mchh.siemens.de [139.21.200.63]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id KAA18920; Thu, 17 Jul 2003 10:21:47 +0200 (MET DST) Received: by mchh253e.mchh.siemens.de with Internet Mail Service (5.5.2653.19) id <3945KA6C>; Thu, 17 Jul 2003 10:21:12 +0200 Message-ID: <931A17FBB884D411B02B0008C70D9E2ABF1320@mchh243e.mchh.siemens.de> From: Stupka Jean-Marie To: "'Alan Johnston'" , Rohan Mahy Cc: "'Jonathan Rosenberg'" , "'sipping@ietf.org'" Subject: AW: AW: [Sipping] Question on INVITE Initiated Dialog Event Packa ge a nd Automatic C allback Date: Thu, 17 Jul 2003 10:21:02 +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: , Hi Alan, The flow 2.17 of draft-ietf-sipping-service-examples-04.txt is a good example to show what is wrong. After the 486 message and the ACK the transaction is terminated: 13.2.2.3 of RFC3261 says "All early dialogs are considered terminated upon reception of the non-2xx final response". As a consequence, all data related to the previous call attempt are lost (why and how long should a SIP client keep this data?). This is at least conforming RFC3261. Therefore, the SUBSCRIBE message shown in the flow is just not possible, as the destination address (Bob's address or user number) is no more existing at the SIP user side. Keeping the data for a short period of time after a 486 would help, but I wouldn't say that this is an implementation matter, the behavior of a SIP client needs to be predictable, i.e. standardized. Coming back to my initial concern, the PSTN call completion application given as an example in draft-ietf-sipping-dialog-package-02.txt. Sending a SUBSCRIBE to the Dialog Package within the dialog initiated by the INVITE of the preceding call attempt would ease the implementation because the call data are available within this dialog at the SIP user side and at its peer (e.g. the gateway in the PSTN). This is in my understanding the benefit of draft-ietf-sipping-dialog-package-02.txt. A possible solution would be to keep for a short period of time the dialog with the data of the previous call attempt (i.e. the called user number, the bearer description, ...) at the user agent after a 486 is received if an automatic callback is possible (e.g. not precluded by other services at the remote user side, lacking network resources, etc.). Then the called user number and other data from the preceding call attempt could be re-used for the SUBSCRIBE request and for the subsequent call when the remote user gets free. This would require to extend the 486 with a "Automatic Callback Possible" indication, or to introduce a new message with this meaning and the procedure of retaining data - a change to RFC3261. Any view on that? Thanks, Jean-Marie -----Ursprungliche Nachricht----- Von: Alan Johnston [mailto:alan.johnston@mci.com] Gesendet: Mittwoch, 16. Juli 2003 20:39 An: Rohan Mahy; Stupka Jean-Marie Cc: 'Jonathan Rosenberg'; 'sipping@ietf.org' Betreff: Re: AW: [Sipping] Question on INVITE Initiated Dialog Event Package a nd Automatic C allback Hi Jean-Marie, The SIP Service Examples section 2.17 shows exactly this flow with a SUBSCRIBE outside of the dialog (which ended with the 486). Thanks, Alan Johnston MCI At 05:21 AM 7/15/2003 -0700, Rohan Mahy wrote: >Jean-Marie, > >It seems perfectly reasonable to send a SUBSCRIBE to the dialog package >outside of a dialog. The default behavior would be to send a list of >dialogs but with no dialog information or peer information. I believe >this is sufficient to build a callback service. > >thanks, >-rohan > > > >On Tuesday, July 15, 2003, at 02:53 AM, Stupka Jean-Marie wrote: > >>Jonathan, >> >>I doubt that sending the SUBSCRIBE request for the dialog package outside >>of any dialog is possible in case of automatic callback, since the >>required data are no more available. >> >>The problem is that when a 486 is received, the dialog initiated by the >>INVITE terminates and, the data related to that dialog (including the >>called user number) disappear. Therefore it is no more possible to send >>the SUBSCRIBE to request automatic callback for this destination. >> >>A possible solution would be to keep for a short period of time the data >>of the previous call attempt (i.e. the called user number, the bearer >>description, ...) at the user agent after a 486 is received. This would >>allow the user agent to re-use the called user number and other data from >>the preceding call attempt for the SUBSCRIBE request and for the >>subsequent call after the remote user is free. However, the procedure of >>retaining data is not foreseen in RFC 3261. >> >>A better (more economical and user friendly) solution would be to keep at >>the user agent only when an automatic callback is possible (e.g. not >>precluded by other services at the remote user side, lacking network >>resources, etc.). This would require to extend the 486 with a "Automatic >>Callback Possible" indication, or to introduce a new message with this meaning. >> >>Jean-Marie >> >>-----Ursprungliche Nachricht----- >>Von: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>Gesendet: Montag, 14. Juli 2003 10:18 >>An: Stupka Jean-Marie >>Cc: 'sipping@ietf.org' >>Betreff: Re: [Sipping] Question on INVITE Initiated Dialog Event Package >>and Automatic C allback >> >> >>The dialog package can be used by subscriptions made both within, and >>outside, of a dialog. So, in the case of automatic callback, the >>caller would, after receiving a 486, send a SUBSCRIBE request for the >>dialog package, and do so outside of any dialog. >> >>-Jonathan R. >> >>Stupka Jean-Marie wrote: >> >>>Hello All, >>> >>>As said in RFC 3265 it is possible to create an event subscription >>>within a pre-existing dialog, e.g. a dialog created by an INVITE. >>>In my understanding, this is the intention of >>>draft-ietf-sipping-dialog-package-02.txt. >>> >>>According to the (PSTN) Automatic Callback given as example >>>application in the introduction of this draft, user A can request a >>>callback when user B hangs-up. User A off course needs to get the >>>information that user B is busy before requesting the automatic >>>callback, i.e. receive a "486 Busy Here" message. However, all >>>early dialogs are considered terminated upon reception of a non-2xx >>>final response (13.2.2.3 of RFC 3261). As consequence, the dialog >>>and thus the data of the preceding call attempt are no more >>>available and the callback cannot be requested. >>> >>>Can somebody provide clarification of the applicability of RFC 3265 >>>and the draft-ietf-sipping-dialog-package-02.txt to Automatic >>>Callback? >>> >>>Regards, >>> >>>Jean-Marie >>> >>> >>>_______________________________________________ Sipping mailing >>>list https://www1.ietf.org/mailman/listinfo/sipping This list is >>>for NEW development of the 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 Jul 17 04:52: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 EAA23895 for ; Thu, 17 Jul 2003 04:52: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 19d4Ua-0006vr-Ug for sipping-archive@odin.ietf.org; Thu, 17 Jul 2003 04:52:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H8q00F026614 for sipping-archive@odin.ietf.org; Thu, 17 Jul 2003 04: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 19d4Ua-0006v9-7z for sipping-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 04:52:00 -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 EAA23852 for ; Thu, 17 Jul 2003 04:51:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4Td-0006XG-7O; Thu, 17 Jul 2003 04:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4So-0006Qn-Ho for sipping@optimus.ietf.org; Thu, 17 Jul 2003 04:50:10 -0400 Received: from imo-d05.mx.aol.com (imo-d05.mx.aol.com [205.188.157.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23750 for ; Thu, 17 Jul 2003 04:50:06 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-d05.mx.aol.com (mail_out_v36_r1.1.) id r.113.26605778 (16781); Thu, 17 Jul 2003 04:49:25 -0400 (EDT) Message-ID: <113.26605778.2c47bd15@aol.com> Date: Thu, 17 Jul 2003 04:49:25 EDT Subject: Re: [Sipping] New Tones draft (was: "who plays the tone" or something like th... To: jdrosen@dynamicsoft.com CC: eburger@snowshore.com, sipping@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_113.26605778.2c47bd15_boundary" X-Mailer: 6.0 for Windows XP sub 10500 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --part1_113.26605778.2c47bd15_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 7/16/2003 8:14:30 PM Eastern Daylight Time, jdrosen@dynamicsoft.com writes: > find the notion that an application can instruct a user to send > media to its peer in a call - frightening. It can be the source of > some potentially bad attacks where a not-so-nice application has you > sending media to your friends that you otherwise would not want to > send. Its particularly worrisome if you go beyond just a "tones" > markup and consider something much richer like VoiceXML. > I share completely the concern with any ability to send someone not-so-nice media, which is why I oppose any notion of some general purpose, infinitely flexible method (via url or similar) to instruct a device to send an unknown media stream (tone or announcement) to anyone, whether to the user of the same device or the person at the other end of the call. Your concern with an application being able to tell your UA to send something to "your friends" should also apply to the possibility of that same application telling your UA to send the same thing to yourself or for the same application to tell your friend's UA to send something to them. The actual directionality in either UA is not the issue. But, in the existing network, the local exchange switch that one party is connected to often has to send tones or announcements to the user at the other end. When SIP assumes that there is no equivalent to the "local exchange", it must depend on the UA to do some of those functions. This includes sending tones in either direction. To address the concern with "not-so-nice" media being sent, the instructions to the UA (for tone insertion) can be in either form: 1. Send tone of such-and-such freq, level, duration, direction, etc. (with the UA being unaware of what the tone is intended to mean). The limits on the parameter values effectively prevents misuse (e.g., level no greater than -3dB). 2. Send ringing tone, busy tone, preempt tone, etc. (with the UA being expected to know the proper charactersitics for the desired tone, including which way to send it.) I believe that similar possibilities should apply for announcements (or any more complicated media streams). It must provide procedures so that only the desired message (e.g., "The party you are calling is not available.") is sent to either user without being replaced by advertising or an obscene message. Mike Pierce --part1_113.26605778.2c47bd15_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 7/16/2= 003 8:14:30 PM Eastern Daylight Time, jdrosen@dynamicsoft.com writes:


find the notion that an ap= plication can instruct a user to send=20
media to its peer in a call - frightening. It can be the source of=20
some potentially bad attacks where a not-so-nice application has you=20
sending media to your friends that you otherwise would not want to=20
send. Its particularly worrisome if you go beyond just a "tones"=20
markup and consider something much richer like VoiceXML.



I share completely the concern with any ability to send someone not-so-n= ice media, which is why I oppose any notion of some general purpose, infinit= ely flexible method (via url or similar) to instruct a device to send an unk= nown media stream (tone or announcement) to anyone, whether to the user of t= he same device or the person at the other end of the call. Your concern with= an application being able to tell your UA to send something to "your friend= s" should also apply to the possibility of that same application telling you= r UA to send the same thing to yourself or for the same application to tell=20= your friend's UA to send something to them. The actual directionality in eit= her UA is not the issue.

But, in the existing network, the local exchange switch that one party i= s connected to often has to send tones or announcements to the user at the o= ther end. When SIP assumes that there is no equivalent to the "local exchang= e", it must depend on the UA to do some of those functions. This includes se= nding tones in either direction.

To address the concern with "not-so-nice" media being sent, the instruct= ions to the UA (for tone insertion) can be in either form:

1. Send tone of such-and-such freq, level, duration, direction, etc. (wi= th the UA being unaware of what the tone is intended to mean). The limits on= the parameter values effectively prevents misuse (e.g., level no greater th= an -3dB).

2. Send ringing tone, busy tone, preempt tone, etc. (with the UA being e= xpected to know the proper charactersitics for the desired tone, including w= hich way to send it.)

I believe that similar possibilities should apply for announcements (or=20= any more complicated media streams). It must provide procedures so that only= the desired message (e.g., "The party you are calling is not available.") i= s sent to either user without being replaced by advertising or an obscene me= ssage.

Mike Pierce
--part1_113.26605778.2c47bd15_boundary-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Jul 17 05:09: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 FAA24527 for ; Thu, 17 Jul 2003 05:09: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 19d4lA-0008Px-LQ for sipping-archive@odin.ietf.org; Thu, 17 Jul 2003 05:09:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H998Zv032351 for sipping-archive@odin.ietf.org; Thu, 17 Jul 2003 05:09:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4lA-0008Pi-Hq for sipping-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 05: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 FAA24518 for ; Thu, 17 Jul 2003 05:09:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d4l7-0003Yy-00 for sipping-web-archive@ietf.org; Thu, 17 Jul 2003 05:09:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d4l1-0003Yv-00 for sipping-web-archive@ietf.org; Thu, 17 Jul 2003 05:08:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4l2-0008Md-Vy; Thu, 17 Jul 2003 05:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4kv-0008MO-QI for sipping@optimus.ietf.org; Thu, 17 Jul 2003 05:08: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 FAA24515 for ; Thu, 17 Jul 2003 05:08:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d4ks-0003Ys-00 for sipping@ietf.org; Thu, 17 Jul 2003 05:08:50 -0400 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by ietf-mx with esmtp (Exim 4.12) id 19d4kh-0003Wi-00 for sipping@ietf.org; Thu, 17 Jul 2003 05:08:39 -0400 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HI5008C9VVKLU@firewall.wcom.com> for sipping@ietf.org; Thu, 17 Jul 2003 09:04:32 +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 <0HI500D01VVKDB@pmismtp02.wcomnet.com>; Thu, 17 Jul 2003 09:04:32 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.104.6]) by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HI500C4HVVHTY@pmismtp02.wcomnet.com>; Thu, 17 Jul 2003 09:04:32 +0000 (GMT) Date: Thu, 17 Jul 2003 04:04:28 -0500 From: Alan Johnston Subject: Re: AW: AW: [Sipping] Question on INVITE Initiated Dialog Event Package and Automatic Callback In-reply-to: <931A17FBB884D411B02B0008C70D9E2ABF1320@mchh243e.mchh.sieme ns.de> X-Sender: Alan.Johnston@pop.mcit.com To: Stupka Jean-Marie , Rohan Mahy Cc: "'Jonathan Rosenberg'" , "'sipping@ietf.org'" Message-id: <5.2.1.1.0.20030717034639.01fb7430@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 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 Jean-Marie, Comments below. Thanks, Alan Johnston MCI At 10:21 AM 7/17/2003 +0200, Stupka Jean-Marie wrote: >Hi Alan, > >The flow 2.17 of draft-ietf-sipping-service-examples-04.txt is a good >example to show what is wrong. After the 486 message and the ACK the >transaction is terminated: 13.2.2.3 of RFC3261 says "All early dialogs are >considered terminated upon reception of the non-2xx final response". In this flow, the dialog between Alice and Bob does terminate with the INVITE/486/ACK exchange. However, Bob has a dialog with another user, say Carol (perhaps the flow should show this for clarity?). If Bob was not currently involved in a dialog, the 486 would not have been sent, right? > As a consequence, all data related to the previous call attempt are lost > (why and how long should a SIP client keep this data?). This is at least > conforming RFC3261. Bob is in a dialog with Carol and keeps this dialog state for as long as the session exists (as long as Bob is busy). >Therefore, the SUBSCRIBE message shown in the flow is just not possible, >as the destination address (Bob's address or user number) is no more >existing at the SIP user side. I don't know what you mean here. Bob still exists - he is still sip:bob@biloxi.example.com, right? As a result, Bob can receive a SUBSCRIBE request from Alice. Alice does not specify any call-id, to-tag, or from-tag Event parameters, so that means that Alice is requesting information about ANY dialogs that Bob is currently active in. (Alice is not requesting information about only dialogs with Alice - this information would be redundant since if Alice is in the dialog, Alice would already know the state and dialog identifiers.) All the NOTIFYs that Alice receives provides information about the dialog between Bob and Carol. >Keeping the data for a short period of time after a 486 would help, but I >wouldn't say that this is an implementation matter, the behavior of a SIP >client needs to be predictable, i.e. standardized. Dialog state does need to be kept for 32 seconds after sending a non-success final response in case of the loss of the 486 which would be detected by the failure to receive an ACK. However, this has no bearing on this scenario. >Coming back to my initial concern, the PSTN call completion application >given as an example in draft-ietf-sipping-dialog-package-02.txt. Sending a >SUBSCRIBE to the Dialog Package within the dialog initiated by the INVITE >of the preceding call attempt would ease the implementation because the >call data are available within this dialog at the SIP user side and at its >peer (e.g. the gateway in the PSTN). This is in my understanding the >benefit of draft-ietf-sipping-dialog-package-02.txt. Are you saying that you would like Alice to be able to send a SUBSCRIBE to Bob within the dialog between Bob and Carol? This is not possible - a dialog is between two peers - a third party can not inject messages. >A possible solution would be to keep for a short period of time the dialog >with the data of the previous call attempt (i.e. the called user number, >the bearer description, ...) at the user agent after a 486 is received if >an automatic callback is possible (e.g. not precluded by other services at >the remote user side, lacking network resources, etc.). Are you perhaps concerned about authorizing the subscription? That is, Bob only accepts a SUBSCRIBE from Alice if Alice has previously just made a call attempt (sent an INVITE and received a 486 busy)? If this is what you want, I'm not sure the exact benefit of this. >Then the called user number and other data from the preceding call attempt >could be re-used for the SUBSCRIBE request and for the subsequent call >when the remote user gets free. This would require to extend the 486 with >a "Automatic Callback Possible" indication, or to introduce a new message >with this meaning and the procedure of retaining data - a change to RFC3261. > >Any view on that? > >Thanks, >Jean-Marie > > >-----Ursprungliche Nachricht----- >Von: Alan Johnston [mailto:alan.johnston@mci.com] >Gesendet: Mittwoch, 16. Juli 2003 20:39 >An: Rohan Mahy; Stupka Jean-Marie >Cc: 'Jonathan Rosenberg'; 'sipping@ietf.org' >Betreff: Re: AW: [Sipping] Question on INVITE Initiated Dialog Event >Package a nd Automatic C allback > > >Hi Jean-Marie, > >The SIP Service Examples section 2.17 shows exactly this flow with a >SUBSCRIBE outside of the dialog (which ended with the 486). > >Thanks, >Alan Johnston >MCI > >At 05:21 AM 7/15/2003 -0700, Rohan Mahy wrote: > >Jean-Marie, > > > >It seems perfectly reasonable to send a SUBSCRIBE to the dialog package > >outside of a dialog. The default behavior would be to send a list of > >dialogs but with no dialog information or peer information. I believe > >this is sufficient to build a callback service. > > > >thanks, > >-rohan > > > > > > > >On Tuesday, July 15, 2003, at 02:53 AM, Stupka Jean-Marie wrote: > > > >>Jonathan, > >> > >>I doubt that sending the SUBSCRIBE request for the dialog package outside > >>of any dialog is possible in case of automatic callback, since the > >>required data are no more available. > >> > >>The problem is that when a 486 is received, the dialog initiated by the > >>INVITE terminates and, the data related to that dialog (including the > >>called user number) disappear. Therefore it is no more possible to send > >>the SUBSCRIBE to request automatic callback for this destination. > >> > >>A possible solution would be to keep for a short period of time the data > >>of the previous call attempt (i.e. the called user number, the bearer > >>description, ...) at the user agent after a 486 is received. This would > >>allow the user agent to re-use the called user number and other data from > >>the preceding call attempt for the SUBSCRIBE request and for the > >>subsequent call after the remote user is free. However, the procedure of > >>retaining data is not foreseen in RFC 3261. > >> > >>A better (more economical and user friendly) solution would be to keep at > >>the user agent only when an automatic callback is possible (e.g. not > >>precluded by other services at the remote user side, lacking network > >>resources, etc.). This would require to extend the 486 with a "Automatic > >>Callback Possible" indication, or to introduce a new message with this > meaning. > >> > >>Jean-Marie > >> > >>-----Ursprungliche Nachricht----- > >>Von: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > >>Gesendet: Montag, 14. Juli 2003 10:18 > >>An: Stupka Jean-Marie > >>Cc: 'sipping@ietf.org' > >>Betreff: Re: [Sipping] Question on INVITE Initiated Dialog Event Package > >>and Automatic C allback > >> > >> > >>The dialog package can be used by subscriptions made both within, and > >>outside, of a dialog. So, in the case of automatic callback, the > >>caller would, after receiving a 486, send a SUBSCRIBE request for the > >>dialog package, and do so outside of any dialog. > >> > >>-Jonathan R. > >> > >>Stupka Jean-Marie wrote: > >> > >>>Hello All, > >>> > >>>As said in RFC 3265 it is possible to create an event subscription > >>>within a pre-existing dialog, e.g. a dialog created by an INVITE. > >>>In my understanding, this is the intention of > >>>draft-ietf-sipping-dialog-package-02.txt. > >>> > >>>According to the (PSTN) Automatic Callback given as example > >>>application in the introduction of this draft, user A can request a > >>>callback when user B hangs-up. User A off course needs to get the > >>>information that user B is busy before requesting the automatic > >>>callback, i.e. receive a "486 Busy Here" message. However, all > >>>early dialogs are considered terminated upon reception of a non-2xx > >>>final response (13.2.2.3 of RFC 3261). As consequence, the dialog > >>>and thus the data of the preceding call attempt are no more > >>>available and the callback cannot be requested. > >>> > >>>Can somebody provide clarification of the applicability of RFC 3265 > >>>and the draft-ietf-sipping-dialog-package-02.txt to Automatic > >>>Callback? > >>> > >>>Regards, > >>> > >>>Jean-Marie > >>> > >>> > >>>_______________________________________________ Sipping mailing > >>>list https://www1.ietf.org/mailman/listinfo/sipping This list is > >>>for NEW development of the 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 Jul 17 05:32: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 FAA26426 for ; Thu, 17 Jul 2003 05:32: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 19d56s-0002JR-Uv for sipping-archive@odin.ietf.org; Thu, 17 Jul 2003 05:31:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H9VYPZ008888 for sipping-archive@odin.ietf.org; Thu, 17 Jul 2003 05:31:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d56s-0002JH-Ri for sipping-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 05:31: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 FAA26350 for ; Thu, 17 Jul 2003 05:31: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 19d56M-00020K-2L; Thu, 17 Jul 2003 05: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 19d565-0001wr-DP for sipping@optimus.ietf.org; Thu, 17 Jul 2003 05:30:45 -0400 Received: from webshield.office.snowshore.com (goalie.snowshore.com [216.57.133.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA26284 for ; Thu, 17 Jul 2003 05:30:40 -0400 (EDT) Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 12257; Thu, 17 Jul 2003 05:29:28 -0400 (EDT) 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] How to report DTMF - conclusion of the app interaction design team: SIP MESSAGE Date: Thu, 17 Jul 2003 05:30:13 -0400 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F65C0@zoe.office.snowshore.com> Thread-Topic: [Sipping] How to report DTMF - conclusion of the app interaction design team: SIP MESSAGE Thread-Index: AcNMOBVd38gr/CrmSRSbgYMmYCxrDgADMOpQ From: "Eric Burger" To: "Steve Fisher" Cc: "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 Mostly goofs on my part. Thoughts in-line. > -----Original Message----- From: Steve Fisher = [mailto:sfisher1@att.com] [snip] > 1) The framework document refers to both "one shot" and "monitor" > models, and while KPML supports both, support for the=20 > "monitor" model is > somewhat awkward (requires having the device quarantine=20 > digits and then > issue a new KPML document via a re-INVITE). Is there a reason the > initial KPML document couldn't just specify which model was=20 > desired for > that particular interaction, and, if "monitor" was desired,=20 > simply keep > monitoring for the specified digits? If we've adandoned HTTP=20 > reporting, > I don't see what the downside to this would be. I realized that I didn't have that described. It will be an attribute = to the kpml tag. > 2) I think that some example message flows would be helpful to tie all > these pieces together, and I would be happy to help draft=20 > some if you'd like. I like :-) > 3) An Jonathan said in the note below, the KPML draft still describes > HTTP reporting, and also mentions NOTIFY. Just to clarify -- are these > mistakes, and the team is now only proposing to use MESSAGE? That is still up for discussion. I'm leaning toward NOTIFY/FEEDBACK/FOO = rather than HTTP. However, there is a contingent that feels HTTP is a = reasonable mechanism. The nice thing is KPML exists outside either. It = is up to the interpreter to "do the right thing" if it encounters a sip: = or a http: or a bar: scheme. > 4) I also would prefer a new SIP method, instead of=20 > overloading MESSAGE. Yes. > 5) I'm confused how the device determines the Request-URI for the > MESSAGE. The KPML document says: >=20 > When the > user enters keypress(es) that match a tag, the user device > will issue a SIP MESSAGE to the Request-URI specified by the href > attribute.=20 > =20 > and >=20 > The specification of any scheme-specific part, that is, anything > following the colon in "sip:", is an error. The interpreter MUST > reject the request. >=20 > If the href attribute can't specify any scheme-specific part, how does > the device determine the Request-URI from the href attribute? Definite cut & paste error where I forgot to cut :-) Thanks for the close reading! -- - Eric _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 17 06:34: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 GAA28857 for ; Thu, 17 Jul 2003 06:34: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 19d65W-0006Bi-0r for sipping-archive@odin.ietf.org; Thu, 17 Jul 2003 06:34:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HAYDkT023780 for sipping-archive@odin.ietf.org; Thu, 17 Jul 2003 06:34:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d65V-0006BT-U7 for sipping-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 06:34: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 GAA28837 for ; Thu, 17 Jul 2003 06:34:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d65R-0004W6-00 for sipping-web-archive@ietf.org; Thu, 17 Jul 2003 06:34:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d65M-0004W3-00 for sipping-web-archive@ietf.org; Thu, 17 Jul 2003 06:34:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d65J-00069S-Lg; Thu, 17 Jul 2003 06: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 19d64v-000678-I1 for sipping@optimus.ietf.org; Thu, 17 Jul 2003 06: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 GAA28809 for ; Thu, 17 Jul 2003 06:33:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d64r-0004Vl-00 for sipping@ietf.org; Thu, 17 Jul 2003 06:33:33 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19d64g-0004V6-00 for sipping@ietf.org; Thu, 17 Jul 2003 06:33:22 -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; Thu, 17 Jul 2003 11:36:02 +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="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 17 Jul 2003 11:31:53 +0100 Message-ID: <45730E094814E44488F789C1CDED27AE0219B03F@gbnewp0758m.eu.ubiquity.net> Thread-Topic: draft-rosenberg-peterson-simple-pidf-phone-00.txt Thread-Index: AcNMTqPjTgvIM4RCSlWand3ZRTP91Q== From: "Chris Boulton" To: , Cc: Content-Transfer-Encoding: base64 Subject: [Sipping] draft-rosenberg-peterson-simple-pidf-phone-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: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGFkIGEgcmVhZCBvZiB0aGlzIGRyYWZ0IGFuZCBub3RlZCBhIGNvdXBsZSBvZiBtaW5vciBuaXRz Lg0KDQogDQoNCkNocmlzLg0KDQogDQoNCiANCg0KU2VjdGlvbiAzIHJlYWRzIDotDQoNCiANCg0K RHVlIHRvIHRoZSBuYXR1cmUgb2YgUE9UUyBsaW5lcywgdGhlIHN3aXRjaGluZyBpbmZyYXN0cnVj dHVyZSBoYXMgbm8NCg0KICAgcmVsaWFibGUgd2F5IHRvIGRldGVybWluZSB3aGV0aGVyIHplcm8s IG9uZSBvciBtb3JlIHRlcm1pbmFscyBoYXZlDQoNCiAgIGJlZW4gY29ubmVjdGVkIHRvIGEgc2lu Z2xlIHRlbGVwaG9uZSBsaW5lIC0gdGh1cyBhIHByZXNlbmNlIGRvY3VtZW50DQoNCiAgIGdlbmVy YXRlZCBieSB0aGUgc3dpdGNoaW5nIGluZnJhc3RydWN0dXJlIGNhbm5vdCBiZSBrbm93IHdpdGgg YW55DQoNCiAgIGNlcnRhaW50eSB0byBjb3JyZXNwb25kIHRvIGEgcGFydGljdWxhciB0ZWxlcGhv bmUuDQoNCiANCg0KQW5kIHNob3VsZCByZWFkOi0NCg0KIA0KDQpEdWUgdG8gdGhlIG5hdHVyZSBv ZiBQT1RTIGxpbmVzLCB0aGUgc3dpdGNoaW5nIGluZnJhc3RydWN0dXJlIGhhcyBubw0KDQogICBy ZWxpYWJsZSB3YXkgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgemVybywgb25lIG9yIG1vcmUgdGVybWlu YWxzIGhhdmUNCg0KICAgYmVlbiBjb25uZWN0ZWQgdG8gYSBzaW5nbGUgdGVsZXBob25lIGxpbmUg LSB0aHVzIGEgcHJlc2VuY2UgZG9jdW1lbnQNCg0KICAgZ2VuZXJhdGVkIGJ5IHRoZSBzd2l0Y2hp bmcgaW5mcmFzdHJ1Y3R1cmUgY2Fubm90IGJlIGtub3duIHdpdGggYW55DQoNCiAgIGNlcnRhaW50 eSB0byBjb3JyZXNwb25kIHRvIGEgcGFydGljdWxhciB0ZWxlcGhvbmUuIA0KDQogDQoNCkFsc28g aW4gU2VjdGlvbiAzIHJlYWRzOi0NCg0KIA0KDQpjYWxsLXdhaXRpbmc6IFRoaXMgZWxlbWVudCBp cyB1c2VkIHdoZW4gdGhlIGNhbGwgc3RhdGUgaXMgJ2luLWNhbGwnDQoNCiAgICAgIG9ubHkuIEl0 IHNpZ25pZmllcyB3aGV0aGVyIG9yIG5vdCB0aGUgY2FsbCBpcyBwcm9ncmVzcyBpcw0KDQogICAg ICBpbnRlcnJ1cHRhYmxlIGJ5IGNhbGwgd2FpdGluZy4NCg0KIA0KDQpBbmQgc2hvdWxkIHJlYWQg Oi0NCg0KIA0KDQpjYWxsLXdhaXRpbmc6IFRoaXMgZWxlbWVudCBpcyB1c2VkIHdoZW4gdGhlIGNh bGwgc3RhdGUgaXMgJ2luLWNhbGwnDQoNCiAgICAgIG9ubHkuIEl0IHNpZ25pZmllcyB3aGV0aGVy IG9yIG5vdCB0aGUgY2FsbCBpbiBwcm9ncmVzcyBpcw0KDQogICAgICBpbnRlcnJ1cHRhYmxlIGJ5 IGNhbGwgd2FpdGluZy4NCg0K _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 17 09:00: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 JAA04794 for ; Thu, 17 Jul 2003 09:00: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 19d8Mk-0007sf-9K for sipping-archive@odin.ietf.org; Thu, 17 Jul 2003 09:00:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HD0Ano030289 for sipping-archive@odin.ietf.org; Thu, 17 Jul 2003 09:00:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d8Mk-0007sS-6P for sipping-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 09:00: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 JAA04752 for ; Thu, 17 Jul 2003 09:00:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d8Mi-0006BQ-00 for sipping-web-archive@ietf.org; Thu, 17 Jul 2003 09:00:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d8Md-0006BN-00 for sipping-web-archive@ietf.org; Thu, 17 Jul 2003 09: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 19d8Mc-0007rL-2d; Thu, 17 Jul 2003 09: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 19d8Ma-0007ql-CU for sipping@optimus.ietf.org; Thu, 17 Jul 2003 09:00: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 IAA04735 for ; Thu, 17 Jul 2003 08:59:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d8MY-0006B7-00 for sipping@ietf.org; Thu, 17 Jul 2003 08:59:59 -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 19d8MO-0006AR-00 for sipping@ietf.org; Thu, 17 Jul 2003 08:59:48 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 17 Jul 2003 06:03:38 -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 h6HCwquD017759; Thu, 17 Jul 2003 05:58:52 -0700 (PDT) Received: from cisco.com (ams-clip-vpn-dhcp4133.cisco.com [10.61.80.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAS95413; Thu, 17 Jul 2003 08:58:49 -0400 (EDT) Message-ID: <3F169D88.20003@cisco.com> Date: Thu, 17 Jul 2003 08:58:48 -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: sipping Subject: Re: [Sipping] How to report DTMF - conclusion of the app interaction design team: SIP MESSAGE References: <3F0AEA40.4020208@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: > > 7. SIP MESSAGE > > Send a SIP MESSAGE request from the client to the application, > containing the digit sequence to report. > > This was a bit of a bending of the semantic of MESSAGE, which is really > meant for conveying information for display to a user. However, the > issue is mostly philosophical in nature. We didnt see any particular > technical issue that would prevent this from working, unlike all of the > above ones which had technical issues. Adam gave some good examples of bad things that might happen if the UAS was confused and attempted to render this to a user. But there are mechanisms already in place to deal with this. For one thing, the application already has an opportunity to pick the address to which the MESSAGEs are sent. So it should be able to ensure that the recipient knows these messages shouldn't be displayed directly to an end-user. Beyond that, there is the Content-Disposition header, which seems intended for purposes like this. In the normal use of MESSAGE for IM, the obvious content type is "render". Here we don't want that, so we should pick some other content type. Sip takes Content-Disposition from RFC 2183, and extends the valid set of values. Sip specific values are: session, alert, icon, render, while 2183 values are inline and attachment. It isn't entirely clear how any of these apply to MESSAGE. The following is a shot at defining them: - session: as defined in 3261, this is N/A for MESSAGE. But by extension it might actually be appropriate here. - alert: N/A? - icon: N/A? - render: clearly appropriate - display content to recipient user - inline: In the case of email, this means the body should be displayed with the containing document. When this is used with MESSAGE it *could* be viewed as being processed internally by the application. So this is a possibility. - attachment: In case of email this means to not display with the enclosing message, and often is used for transferring files. This probably has good meaning for file transfer in IM. The prudent course might be to define a new disposition specifically for this purpose - perhaps "application", aligning it well with the use of App-Info to initiate the process. Bottom line - I think MESSAGE is quite suitable for the DTMF reports. 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 Thu Jul 17 09: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 JAA05268 for ; Thu, 17 Jul 2003 09: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 19d8UY-0000OF-9V for sipping-archive@odin.ietf.org; Thu, 17 Jul 2003 09:08:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HD8EpW001494 for sipping-archive@odin.ietf.org; Thu, 17 Jul 2003 09:08:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d8UY-0000O1-4F for sipping-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 09:08: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 JAA05252 for ; Thu, 17 Jul 2003 09:08:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d8UU-0006HL-00 for sipping-web-archive@ietf.org; Thu, 17 Jul 2003 09:08:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d8UP-0006HI-00 for sipping-web-archive@ietf.org; Thu, 17 Jul 2003 09:08:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d8UM-0000Jn-7h; Thu, 17 Jul 2003 09:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d8Td-0000CO-NL for sipping@optimus.ietf.org; Thu, 17 Jul 2003 09:07: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 JAA05239 for ; Thu, 17 Jul 2003 09:07:13 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d8Tc-0006Gt-00 for sipping@ietf.org; Thu, 17 Jul 2003 09:07:16 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19d8TQ-0006GQ-00 for sipping@ietf.org; Thu, 17 Jul 2003 09:07:04 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6HD6RB21102 for ; Thu, 17 Jul 2003 16:06:27 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Jul 2003 16:06:26 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 17 Jul 2003 16:06:25 +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 Date: Thu, 17 Jul 2003 16:06:25 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796F20@esebe019.ntc.nokia.com> Thread-Topic: Draft SIPPING minutes, 2nd Session Thread-Index: AcNMZDmZbLyT3CzNRFunyZ/YFM72Vg== To: Cc: X-OriginalArrivalTime: 17 Jul 2003 13:06:25.0473 (UTC) FILETIME=[3A47CB10:01C34C64] Content-Transfer-Encoding: quoted-printable Subject: [Sipping] Draft SIPPING minutes, 2nd Session Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 SIPPING WG Meeting Thursday, July 17, 2003, 1300-1500 AKA v2 was pointed out and drawn attention to. WG does not need to = review document. 1300 Open Issues from Application Interaction Design Team =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Jonathan Rosenberg Status: - submitted new documents below. - Design teams considered itself done. Only 1 issue remaining - Question remaining is if WG is interesting in adopting this work - Changes from previous revision presented (see slides) No comments on the mike for adopting this work Voting: - rough consensus to adopt the work as WG items. draft-rosenberg-sipping-app-interaction-framework-00 draft-jennings-sip-app-info-01 ---------------------------------------------------- Jonathan Rosenberg Open issue: KPML DTMF reporting - INFO: INFO is only for within dialogs - NOTIFY: implicit subscriptions has issues - Explicit subscription: GRUU and authorisation problem - HTTP: not returning a script in proposed issues - New method: what does this buy us? - MESSAGE: least harmful solution. It is the proposed solution for now. Discussion: - Most mike speakers were advocating a new method. Jonathan has = reservation (semantics) - Another proposal was presented suggesting content-disposition with = MESSAGE. - Implicit subscription is really bad, from REFER experience. Jonathan = asks to explicitly list the problems with implicit subscriptions and we = can figure out which ones apply/don't apply to this problem. - implicit subscription might may cause flood of proposals to use other = methods with it. We don't want to have to go through the exercise of = going through the pros and cons every time someone wants to use = implicit subscriptions. - no consensus, take it to the list. draft-burger-sipping-kpml-02=20 ---------------------------------------------------- Eric Burger - Issues and resolutions presented (see slides) - No comments, questions or suggestions - Will be sent to AD for consideration 1320 Discussion of Media-related Issues=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D draft-camarillo-sipping-early-media-02.txt ---------------------------------------------------- - Presented by Gonzalo - Missed the dead line, so it wasn't submitted - no issues discussed draft-mahy-sipping-tones-00.txt ---------------------------------------------------- Rohan Mahy - Presented background and proposal (put it in the body) - trying to reduce early media occurrence - using explicit tones can convey country specific tones - Rohan asks if this is interesting to the working group. Discussion: - no concrete support from comments on the mike - speaker asks for comments on the mailing list regarding support of = this work. draft-burger-sipping-netann-06=20 1350 Discussion of Event Filtering and Throttling=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Aki Niemi draft-niemi-sipping-event-throttle-reqs-02.txt=20 ---------------------------------------------------- - presenter clarified how is this different than filtering and partial = notification. - presented the model behind the requirements Open issues/ discussion: - need to elaborate on use cases. Proposal is not to do so - might be worth mentioning the buffer behaviour - move to WG item - Rough consensus to take this as a WG item 1400 Discussion of DPNSS to SIP interworking=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Ranjith Mukundan draft-mukundan-sipping-dpnss-02.txt=20 ---------------------------------------------------- - presented what is dpnss, why dpnss is needed and how its complementary = to QSIG/SIP. - MIME type as a proposal Issues/Discussion: - Some scepticism on the usefulness of this work. - Do we have the expertise to review it. Is this the right place to take = on this work - A show of hands was asked showing interest in this topic: One hand = went up in the room - About 4 people raised their hand claiming expertise in dpnss - DPNSS to sip translation: no interest in the group - WG item? Conclusion was a no. Authors can proceed with it as = individual work 1410 Discussion of End-to-middle Security=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Kumiko Ono draft-ono-sipping-end2middle-security-00.txt ---------------------------------------------------- - presented why this type of security is needed, using use cases.=20 Issues/Discussion: - Any interest from WG? - middle to end and end to middle: just the inverse of each other. = Others suggest that they are complementary. - too early as a wg item. - A hum was taken on interest in this topic. The hum showed interest. - A hum was taken on interest of having the requirements taken as WG = item. The hum showed interest. 1435 Discussion on Phone-related Status and Presence=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Jonathan Rosenberg draft-rosenberg-peterson-simple-pidf-phone ---------------------------------------------------- - Presented what is it. Asked people to take a look at it. Discussion: - maybe presence is not the right thing to do for this - this is tide to dialog state. Answer is that you don't want both, but = you definitely need presence. the worry is that you have to subscribe = to both event packages. Answer is that different things need different = packages - A hum was taken on interest in this topic. The hum showed interest. - Propose to produce use cases to motivate this work. Agreed. - Might be an issue if this is a sipping or simple work. We can decide = later 1450 Discussion of Diagnostics in SIP=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Alan Johnston draft-johnston-sipping-rtcp-summary-00.txt ---------------------------------------------------- - Delivery of RTCP summery reports to 3rd parties - 3 possibilities: 1 RTCP to multiple locations, 2 SIP header in BYE, 3 = Event package Discussion: - this is interesting and needed, although the proposed mechanisms were = not well received. - why not use some snmp mechanisms? - RMON WG is working on such things already. Advice to take a look at = the work being done there. - Need evaluate RMON work. Alan will do that.=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 Jul 17 11:37: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 LAA11800 for ; Thu, 17 Jul 2003 11:37: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 19dAop-0000cg-Fi for sipping-archive@odin.ietf.org; Thu, 17 Jul 2003 11:37:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HFbJ11002388 for sipping-archive@odin.ietf.org; Thu, 17 Jul 2003 11:37:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dAol-0000aD-47 for sipping-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 11:37: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 LAA11728 for ; Thu, 17 Jul 2003 11:37:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dAok-0007GZ-00 for sipping-web-archive@ietf.org; Thu, 17 Jul 2003 11:37:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dAoe-0007GW-00 for sipping-web-archive@ietf.org; Thu, 17 Jul 2003 11:37:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dAoY-0000Sp-Fd; Thu, 17 Jul 2003 11: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 19dAoW-0000Rj-Cb for sipping@optimus.ietf.org; Thu, 17 Jul 2003 11:37: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 LAA11713 for ; Thu, 17 Jul 2003 11:36:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dAoV-0007GE-00 for sipping@ietf.org; Thu, 17 Jul 2003 11:36:59 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19dAoK-0007Fr-00 for sipping@ietf.org; Thu, 17 Jul 2003 11:36:48 -0400 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6HFaApp001632; Thu, 17 Jul 2003 08:36:11 -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 AHJ77529; Thu, 17 Jul 2003 08:36:09 -0700 (PDT) Message-Id: <4.3.2.7.2.20030717113237.00b1fee0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Jul 2003 11:36:09 -0400 To: Alan Johnston From: Michael Hammer Subject: Re: [Sipping] Re: Comments on draft-ietf-sipping-cc-conferencing-01 Cc: Eric Burger , sipping In-Reply-To: <5.2.1.1.0.20030716134212.021f7388@pop.mcit.com> References: <4A3384433CE2AB46A63468CB207E209D4F6555@zoe.office.snowshor e.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_8074500==_.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: , --=====================_8074500==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 01:51 PM 7/16/2003 -0500, Alan Johnston wrote: >>Section 4.2: >>How else, in the SIP world, would a focus bring a user agent into the >>conference other than by INVITE? Maybe the SHOULD here is the inclusion >>of the ;isfocus parameter. That said, why is it not MUST? > >Yes, the SHOULD relates to the isfocus parameter. It is not a MUST >because a focus may wish to conceal the fact that it is a focus. Some places have requirements that a participant in a call be notified if there are others eavesdropping on the call. This strikes me as a form of wire-tapping. Could you elaborate on why a focus would want to conceal that fact? Mike --=====================_8074500==_.ALT Content-Type: text/html; charset="us-ascii" At 01:51 PM 7/16/2003 -0500, Alan Johnston wrote:
Section 4.2:
How else, in the SIP world, would a focus bring a user agent into the conference other than by INVITE?  Maybe the SHOULD here is the inclusion of the ;isfocus parameter.  That said, why is it not MUST?

Yes, the SHOULD relates to the isfocus parameter.  It is not a MUST because a focus may wish to conceal the fact that it is a focus.

Some places have requirements that a participant in a call be notified if there are others eavesdropping on the call.  This strikes me as a form of wire-tapping.  Could you elaborate on why a focus would want to conceal that fact?

Mike
 --=====================_8074500==_.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 Thu Jul 17 13:25: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 NAA14487 for ; Thu, 17 Jul 2003 13:25: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 19dCVD-00065T-R2 for sipping-archive@odin.ietf.org; Thu, 17 Jul 2003 13:25:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HHPBBL023398 for sipping-archive@odin.ietf.org; Thu, 17 Jul 2003 13:25:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dCVD-00065J-ML for sipping-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 13:25: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 NAA14481 for ; Thu, 17 Jul 2003 13:25:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dCVB-00005G-00 for sipping-web-archive@ietf.org; Thu, 17 Jul 2003 13:25:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dCV6-00005D-00 for sipping-web-archive@ietf.org; Thu, 17 Jul 2003 13:25:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dCV3-00064N-FX; Thu, 17 Jul 2003 13:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dCUh-00063y-OG for sipping@optimus.ietf.org; Thu, 17 Jul 2003 13:24: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 NAA14477 for ; Thu, 17 Jul 2003 13:24:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dCUf-000055-00 for sipping@ietf.org; Thu, 17 Jul 2003 13:24:37 -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 19dCUV-00002u-00 for sipping@ietf.org; Thu, 17 Jul 2003 13:24:27 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 17 Jul 2003 10:26:29 -0700 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 h6HHLc89021483; Thu, 17 Jul 2003 10:21:38 -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 AHK05186; Thu, 17 Jul 2003 10:21:37 -0700 (PDT) Message-Id: <4.3.2.7.2.20030717130947.00b1ada0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Jul 2003 13:21:36 -0400 To: "A vWijk" From: Michael Hammer Subject: Re: [Sipping] Update to caller preferences use cases Cc: , , , , , , In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_14401968==_.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: , --=====================_14401968==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 01:49 PM 7/16/2003 +0200, A vWijk wrote: >And that it does not require the hearing impaired user to be registered >with a relay operator At the risk of assuming too much, does this mean that the hearing-impaired user does not have a "home" relay operator, but will need to be able to send an INVITE, much like an "sos" service code (perhaps "tdd" or "relay"), along with caller preferences or pre-conditions indicating the need for a particular type of relay service (e.g. "voice-to-2973" with directionality), and get forwarded to an appropriate server? Furthermore, would that user be able to send a REFER to that server indicating the need to INVITE the called party? This feels like a 2-way conference of sorts, with the focus not only mixing media, but also translating media. Or perhaps there is another way to invoke this ad-hoc. Mike --=====================_14401968==_.ALT Content-Type: text/html; charset="us-ascii" At 01:49 PM 7/16/2003 +0200, A vWijk wrote:
And that it does not require the hearing impaired user to be registered with a relay operator

At the risk of assuming too much, does this mean that the hearing-impaired user does not have a "home" relay operator, but will need to be able to send an INVITE, much like an "sos" service code (perhaps "tdd" or "relay"), along with caller preferences or pre-conditions indicating the need for a particular type of relay service (e.g. "voice-to-2973" with directionality), and get forwarded to an appropriate server?  Furthermore, would that user be able to send a REFER to that server indicating the need to INVITE the called party?  This feels like a 2-way conference of sorts, with the focus not only mixing media, but also translating media.

Or perhaps there is another way to invoke this ad-hoc.

Mike
 --=====================_14401968==_.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 Thu Jul 17 14:21:55 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 OAA16539 for ; Thu, 17 Jul 2003 14:21:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dDNh-0000qc-5j for sipping-archive@odin.ietf.org; Thu, 17 Jul 2003 14:21:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HILTfx003252 for sipping-archive@odin.ietf.org; Thu, 17 Jul 2003 14:21:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dDNg-0000qN-W0 for sipping-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 14:21: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 OAA16511 for ; Thu, 17 Jul 2003 14:21:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dDNe-0000SL-00 for sipping-web-archive@ietf.org; Thu, 17 Jul 2003 14:21:26 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dDNY-0000Rs-00 for sipping-web-archive@ietf.org; Thu, 17 Jul 2003 14:21:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dDMI-0000dD-8L; Thu, 17 Jul 2003 14: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 19dDLQ-0000bO-Jr for sipping@optimus.ietf.org; Thu, 17 Jul 2003 14:19:08 -0400 Received: from mhs02lhr.blackberry.net (pxf01lhr.egham.rim.net [193.109.81.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16450 for ; Thu, 17 Jul 2003 14:19:03 -0400 (EDT) Received: from mailrouter01.bwc.prod.uk.blackberry (mailrouter01.bwc.prod.uk.blackberry [172.16.80.216]) by mhs02lhr.blackberry.net (8.11.7+Sun/8.11.3) with ESMTP id h6HIH9G20623; Thu, 17 Jul 2003 18:17:09 GMT Received: from engine01.bwc.prod.uk.blackberry (load-bal-out.bwc.prod.uk.blackberry [172.16.94.130]) by mailrouter01.bwc.prod.uk.blackberry (8.12.8/8.12.8) with SMTP id h6HIH9St016384; Thu, 17 Jul 2003 18:17:09 GMT Message-ID: <1977232048-1058465828-cardhu_blackberry.rim.net-1875-@engine01.bwc.prod.uk.blackberry> REPLY-TO: guido.gybels@rnid.org.uk FROM: "Guido Gybels" Importance: Normal To: "Michael Hammer" To: "Arnoud van Wijk" Cc: jdrosen@dynamicsoft.com Cc: sipping@ietf.org Cc: "Frank Shearar" Cc: "Guido Gybels" Cc: "James Hamlin" Cc: "Mike Spanner" Subject: Re: [Sipping] Update to caller preferences use cases Date: Thu, 17 Jul 2003 18:15:14 +0000 GMT Content-type: text/plain MIME-Version: 1.0 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Mike and others, You raise a number of interesting issues, and so have other people over the last couple of days. I'm happy to comment on a case by case basis, but it seems to me that there is a more fundamental issue here: the fact that we are missing a clear set of use cases describing the various scenarios for relay service usage as well as a proper set of requirements in terms of functional behaviour. Maybe Arnoud and myself, together with those that want to participate should first carry out a proper analysis of this whole problem. We could then prepare a draft that presents the relay cases so that the most appropriate solutions can then be created. Otherwise, I think that we will keep bouncing the issue around: we will raise a particular case, work out a solution for it, only to see that it doesn't fit very well with other cases. Maybe we first need to establish the bigger picture, try to get the overview first, before we can start detailing? What do you all think? Based on a conversation I had with Arnoud today I think he would agree with this and I think we are willing to do this analysis and write it down. Does this sound like a good way forward? Guido >>> "mhammer@cisco.com" 07/17/03 18:21 >>> At 01:49 PM 7/16/2003 +0200, A vWijk wrote: >And that it does not require the hearing impaired user to be registered >with a relay operator At the risk of assuming too much, does this mean that the hearing-impairedu ser does not have a "home" relay operator, but will need to be able to send an INVITE, much like an "sos" service code (perhaps "tdd" or "relay"),a long with caller preferences or pre-conditions indicating the need for ap articular type of relay service (e.g. "voice-to-2973" with directionality), and get forwarded to an appropriate server? Furthermore,w ould that user be able to send a REFER to that server indicating the needt o INVITE the called party? This feels like a 2-way conference of sorts,w ith the focus not only mixing media, but also translating media. Or perhaps there is another way to invoke this ad-hoc. Mike _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 18 02:35: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 CAA18956 for ; Fri, 18 Jul 2003 02:35: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 19dOpt-00046r-Et for sipping-archive@odin.ietf.org; Fri, 18 Jul 2003 02:35:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6I6ZL9a015796 for sipping-archive@odin.ietf.org; Fri, 18 Jul 2003 02:35:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dOpt-00046h-2D for sipping-web-archive@optimus.ietf.org; Fri, 18 Jul 2003 02:35: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 CAA18953 for ; Fri, 18 Jul 2003 02:35:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dOpp-0005RH-00 for sipping-web-archive@ietf.org; Fri, 18 Jul 2003 02:35:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dOpj-0005RB-00 for sipping-web-archive@ietf.org; Fri, 18 Jul 2003 02:35:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dOpa-00045S-Q0; Fri, 18 Jul 2003 02:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dOpR-00042T-Ha for sipping@optimus.ietf.org; Fri, 18 Jul 2003 02:34:54 -0400 Received: from mrs02lhr.blackberry.net (pxf01lhr.egham.rim.net [193.109.81.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18913 for ; Fri, 18 Jul 2003 02:34:49 -0400 (EDT) Received: from mailrouter02.bwc.prod.uk.blackberry (mailrouter02.bwc.prod.uk.blackberry [172.16.80.218]) by mrs02lhr.blackberry.net (8.11.7+Sun/8.11.3) with ESMTP id h6I6XAO07329; Fri, 18 Jul 2003 07:33:10 +0100 (BST) Received: from engine02.bwc.prod.uk.blackberry (load-bal-out.bwc.prod.uk.blackberry [172.16.94.133]) by mailrouter02.bwc.prod.uk.blackberry (8.12.8/8.12.8) with SMTP id h6I6WuPI026467; Fri, 18 Jul 2003 06:32:57 GMT Message-ID: <1204311701-1058509975-cardhu_blackberry.rim.net-20506-@engine02.bwc.prod.uk.blackberry> REPLY-TO: guido.gybels@rnid.org.uk FROM: "Guido Gybels" Importance: Normal To: "Paul E. Jones" To: gv@trace.wisc.edu Cc: "Henry Sinnreich" Cc: "Gunnar Hellstrom" Cc: "Guido Gybels" Cc: "Mike Spanner" Cc: andreas.piirimets@omnitor.se Cc: gv@trace.wisc.edu Cc: trefor@trefor.plus.com Cc: "'Rajesh Kumar'" Cc: marcelo@envilogg.se Cc: jorgen.bjorkner@hotsip.com Cc: "James Hamlin" Cc: Erik.Zetterstrom@omnitor.se Cc: hwildfeu@cisco.com Cc: barry.dingle@bigfoot.com.au Cc: mgarakan@cisco.com Cc: oran@cisco.com Cc: rohan@cisco.com Cc: sipping@ietf.org Date: Fri, 18 Jul 2003 06:31:03 +0000 GMT Content-type: text/plain MIME-Version: 1.0 Subject: [Sipping] Re: items for vor voting in the BOF Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Paul, <> 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. <> 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 From exim@www1.ietf.org Fri Jul 18 03:03: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 DAA19957 for ; Fri, 18 Jul 2003 03:03: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 19dPGq-0005SC-F1 for sipping-archive@odin.ietf.org; Fri, 18 Jul 2003 03:03:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6I73CKL020964 for sipping-archive@odin.ietf.org; Fri, 18 Jul 2003 03:03:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dPGq-0005S3-8X for sipping-web-archive@optimus.ietf.org; Fri, 18 Jul 2003 03:03: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 DAA19944 for ; Fri, 18 Jul 2003 03:03:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dPGm-0005gz-00 for sipping-web-archive@ietf.org; Fri, 18 Jul 2003 03:03:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dPGg-0005gw-00 for sipping-web-archive@ietf.org; Fri, 18 Jul 2003 03:03:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dPGf-0005Ow-CZ; Fri, 18 Jul 2003 03: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 19dPG2-0005JT-Np for sipping@optimus.ietf.org; Fri, 18 Jul 2003 03:02: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 DAA19899 for ; Fri, 18 Jul 2003 03:02:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dPFy-0005g0-00 for sipping@ietf.org; Fri, 18 Jul 2003 03:02:18 -0400 Received: from natsmtp00.webmailer.de ([192.67.198.74] helo=post.webmailer.de) by ietf-mx with esmtp (Exim 4.12) id 19dPFi-0005ff-00 for sipping@ietf.org; Fri, 18 Jul 2003 03:02:02 -0400 Received: from discofox (pD95879B2.dip.t-dialin.net [217.88.121.178]) by post.webmailer.de (8.12.8/8.8.7) with ESMTP id h6I71Qru018246 for ; Fri, 18 Jul 2003 09:01:27 +0200 (MEST) From: "Christian Stredicke" To: Date: Fri, 18 Jul 2003 09:01:27 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0037_01C34D0B.2EC446E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-MS-TNEF-Correlator: 00000000079B3E933667D34D964E175E0119A6EDA4AC4500 Subject: [Sipping] SNMP on draft-johnston-sipping-rtcp-summary-00 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0037_01C34D0B.2EC446E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! Thinking about NAT and the way we want to solve it it's probably a good = idea using SIP messages instead of SNMP. Otherwise I don't see how operators = want to collect the data. Using the result of the RTCP/SNMP discussion of WHAT to send is probably = a good idea. I don't think we have to repeat this discussion. Christian -- Christian Stredicke sip:christian@stredicke.de ------=_NextPart_000_0037_01C34D0B.2EC446E0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IiAHAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGAAcAAQAAAAAAAAEGgAMADgAAANMHBwAS AAkAAQAAAAUAAgEBA5AGAFgGAAAqAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAAC ATEAAQAAABgAAAAAAAAAB5s+kzZn002WThdeARmm7QSsRQADADYAAAAAAB4AcAABAAAALwAAAFNO TVAgb24gZHJhZnQtam9obnN0b24tc2lwcGluZy1ydGNwLXN1bW1hcnktMDAAAAIBcQABAAAAFgAA AAHDTPlFoESVc+iuMEaJrvCiQmxK2zMAAAIBHQwBAAAAEAAAAFNNVFA6Q1NAU05PTS5ERQALAAEO AAAAAEAABg4A3hdY+kzDAQIBCg4BAAAAGAAAAAAAAAAHmz6TNmfTTZZOF14BGabtwoAAAAMAFA4A AAAACwAfDgEAAAACAQkQAQAAAMYBAADCAQAAvwIAAExaRnWIUznjAwAKAHJjcGcxMjXiMgNDdGV4 BUEBAwH3TwqAAqQD4wIAY2gKwHPwZXQwIAcTAoAP8wBQfwRWCFUHshHFDlEDARDHMvcGAAbDEcUz BEYQyRLbEdPbCO8J9zsYvw4wNRHCDGDOYwBQCwkBZDM2EVALpnAgSGkhCqIKhAqAVMpoC4BrC4Bn IAGgCGARBUBOQVQfAG5kIIB0aGUgd2F5ICBHIBICMB/gbyBzBvB2DSAQaQVAIYBcJzkyVQQgcANg YgGgbCBQYXggZ28EcCFwAQAiwHVDAJAe4VNJUCAHgXOsYWcHkQuAcw6wYR/QBG9mBgBOTVAuIBpP H/FyA/EgEEkgZJ8CICHSBUARICAQaG8H4PRvcASQYSDwERAglxgxLmwFkCDRIAFkJ9BhLh0dylUj kx/yGMBzdWwHBUAlMR/yUlRDUC/3JWImcAQAYyOAAJACICUi/FdIH4Eg8gnwIxEiHyMj/yWgJmkf 8B6hIGIQ8CFRIPF/GMAnoCfQMIIEICyoKbtDPmgFECTQBzALkB3TLS2bM30GAHQYwQ3ga2UdxNkA kHA6EOAz9UAk0DYFFi4BAB3EfTjgAAADAJIQAAAAAAIBFDoBAAAAEAAAAKDJ03l7H6xGi/m9ofB9 sGgDAN4/n04AAAMACVkBAAAAAwBAZQAAAAALAAGACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAA AAMAA4AIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAHgAggBgAAAAAAwAAAAAAAAEYAAAAA UoUAABuXAQAeAAmACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAUAAAAxMC4wAAAAAAsADYAI IAYAAAAAAMAAAAAAAABGAAAAAIKFAAABAAAACwA6gAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAA AAADAD2ACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAAsAVYAIIAYAAAAAAMAAAAAAAABGAAAA AAaFAAAAAAAAAwBWgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAABAAFiACCAGAAAAAADAAAAA AAAARgAAAABghQAAAKRqnff//x8CAfgPAQAAABAAAAAHmz6TNmfTTZZOF14BGabtAgH6DwEAAAAQ AAAAB5s+kzZn002WThdeARmm7QIB+w8BAAAAoAAAAAAAAAA4obsQBeUQGqG7CAArKlbCAABtc3Bz dC5kbGwAAAAAAE5JVEH5v7gBAKoAN9luAAAAQzpcRG9rdW1lbnRlIHVuZCBFaW5zdGVsbHVuZ2Vu XHN0cmVkaWNoXExva2FsZSBFaW5zdGVsbHVuZ2VuXEFud2VuZHVuZ3NkYXRlblxNaWNyb3NvZnRc T3V0bG9va1xPdXRsb29rLnBzdAADAP4PBQAAAAMADTT9NwIAAgEUNAEAAAAQAAAATklUQfm/uAEA qgA32W4AAAIBfwABAAAAMQAAADAwMDAwMDAwMDc5QjNFOTMzNjY3RDM0RDk2NEUxNzVFMDExOUE2 RURBNEFDNDUwMAAAAAADAAYQkx11lQMABxAtAQAAAwAQEAAAAAADABEQAAAAAB4ACBABAAAAZQAA AEhJVEhJTktJTkdBQk9VVE5BVEFORFRIRVdBWVdFV0FOVFRPU09MVkVJVElUU1BST0JBQkxZQUdP T0RJREVBVVNJTkdTSVBNRVNTQUdFU0lOU1RFQURPRlNOTVBPVEhFUldJU0UAAAAAy3A= ------=_NextPart_000_0037_01C34D0B.2EC446E0-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 18 03:14: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 DAA20463 for ; Fri, 18 Jul 2003 03:14: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 19dPRT-0006KR-CD for sipping-archive@odin.ietf.org; Fri, 18 Jul 2003 03:14:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6I7EBUB024326 for sipping-archive@odin.ietf.org; Fri, 18 Jul 2003 03:14:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dPRS-0006KH-GV for sipping-web-archive@optimus.ietf.org; Fri, 18 Jul 2003 03:14: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 DAA20456 for ; Fri, 18 Jul 2003 03:14:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dPRQ-0005rG-00 for sipping-web-archive@ietf.org; Fri, 18 Jul 2003 03:14:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dPRK-0005rD-00 for sipping-web-archive@ietf.org; Fri, 18 Jul 2003 03: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 19dPRJ-0006Dv-Cp; Fri, 18 Jul 2003 03: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 19dPQs-0006DO-7u for sipping@optimus.ietf.org; Fri, 18 Jul 2003 03:13: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 DAA20445 for ; Fri, 18 Jul 2003 03:13:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dPQq-0005qq-00 for sipping@ietf.org; Fri, 18 Jul 2003 03:13:32 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19dPQf-0005qR-00 for sipping@ietf.org; Fri, 18 Jul 2003 03:13:21 -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 h6I7CCE5017834; Fri, 18 Jul 2003 03:12:12 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Jul 2003 02:12:12 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3EE601D@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Paul Kyzivat , Jonathan Rosenberg Cc: sipping Subject: RE: [Sipping] How to report DTMF - conclusion of the app interact ion design team: SIP MESSAGE Date: Fri, 18 Jul 2003 02:12: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: , Paul Kyzivat [mailto:pkyzivat@cisco.com] writes: > For one thing, the application already has an opportunity to pick the > address to which the MESSAGEs are sent. So it should be able > to ensure > that the recipient knows these messages shouldn't be > displayed directly > to an end-user. The problem really is one of a slippery slope. You already heard a participant get up in the meeting and suggest that MESSAGE should be the mechanism by which a server pushes a KPML script to a UA. This is just one use case away from sending a MESSAGE to a UA from which no message has yet been received, which will undoubtedly cause the relic I described earlier. > Beyond that, there is the Content-Disposition header, which seems > intended for purposes like this. In the normal use of MESSAGE for IM, > the obvious content type is "render". Here we don't want that, so we > should pick some other content type. Without well-defined semantics in the MESSAGE RFC, I can confidently assert that many, if not most, UAs will not bother with checking the Content-Disposition when they receive a MESSAGE. MESSAGE has an explicit render semantic built in. /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 Jul 18 03:51:06 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 DAA21319 for ; Fri, 18 Jul 2003 03:51:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dQ0k-0007t2-2Z for sipping-archive@odin.ietf.org; Fri, 18 Jul 2003 03:50:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6I7obFk030310 for sipping-archive@odin.ietf.org; Fri, 18 Jul 2003 03:50:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dQ0j-0007sn-8v for sipping-web-archive@optimus.ietf.org; Fri, 18 Jul 2003 03:50: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 DAA21306 for ; Fri, 18 Jul 2003 03:50: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 19dQ0A-0007nd-6V; Fri, 18 Jul 2003 03:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dQ03-0007mZ-Q5 for sipping@optimus.ietf.org; Fri, 18 Jul 2003 03:49: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 DAA21282 for ; Fri, 18 Jul 2003 03:49:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dQ01-000681-00 for sipping@ietf.org; Fri, 18 Jul 2003 03:49:53 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19dPzl-00067p-00 for sipping@ietf.org; Fri, 18 Jul 2003 03:49:37 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6I7mxkM025408 for ; Fri, 18 Jul 2003 03:48:59 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6I7mwg00691 for ; Fri, 18 Jul 2003 03:48:58 -0400 Message-ID: <3F17A571.70101@cs.columbia.edu> Date: Fri, 18 Jul 2003 03:44:49 -0400 From: Henning Schulzrinne Organization: Columbia University 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: sipping@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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 From exim@www1.ietf.org Fri Jul 18 03:55:02 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 DAA21424 for ; Fri, 18 Jul 2003 03:55:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dQ4X-0008HD-Lh for sipping-archive@odin.ietf.org; Fri, 18 Jul 2003 03:54:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6I7sXF1031809 for sipping-archive@odin.ietf.org; Fri, 18 Jul 2003 03:54:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dQ4X-0008Gy-Fs for sipping-web-archive@optimus.ietf.org; Fri, 18 Jul 2003 03:54:33 -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 DAA21397 for ; Fri, 18 Jul 2003 03:54: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 19dQ42-00087c-Kn; Fri, 18 Jul 2003 03:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dQ3H-00086d-TR for sipping@optimus.ietf.org; Fri, 18 Jul 2003 03:53: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 DAA21378 for ; Fri, 18 Jul 2003 03:53:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dQ3F-00069R-00 for sipping@ietf.org; Fri, 18 Jul 2003 03:53:13 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19dQ34-000694-00 for sipping@ietf.org; Fri, 18 Jul 2003 03:53:02 -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 h6I7qKE5017881; Fri, 18 Jul 2003 03:52:25 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Jul 2003 02:52:19 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86218@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Jonathan Rosenberg , Adam Roach Cc: "'Eric Burger'" , sipping Subject: RE: [Sipping] How to report DTMF - conclusion of the app interact ion design team: SIP MESSAGE Date: Fri, 18 Jul 2003 02:52:14 -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: > I must say for the life of me, at this moment I cannot enumerate what > kind of issues we have had with implicit subscriptions. Adam > - can you > enumerate them and we can see which ones might or might not > apply here? I can't create an exhaustive list at the moment, but I can offer a few problems (many from the SIPPING meeting). Hopefully Robert can offer additional areas of difficulty, since he's the one who most deeply regretted choosing implicit subscriptions for REFER. - 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: - 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. - 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. - 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. - 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. - 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. I'm certain there were other problems, just based on the frequency with which the issue arose in REFER; I can't remember what they were, though. /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 Jul 18 05:27:49 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 FAA24447 for ; Fri, 18 Jul 2003 05:27: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 19dRWL-0004sN-O5 for sipping-archive@odin.ietf.org; Fri, 18 Jul 2003 05:27:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6I9RLRZ018739 for sipping-archive@odin.ietf.org; Fri, 18 Jul 2003 05:27:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dRWK-0004s8-7e for sipping-web-archive@optimus.ietf.org; Fri, 18 Jul 2003 05:27: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 FAA24395 for ; Fri, 18 Jul 2003 05:27:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dRWG-0006zV-00 for sipping-web-archive@ietf.org; Fri, 18 Jul 2003 05:27:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dRWB-0006zS-00 for sipping-web-archive@ietf.org; Fri, 18 Jul 2003 05:27:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dRW2-0004k4-RG; Fri, 18 Jul 2003 05:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dRVZ-0004h1-CH for sipping@optimus.ietf.org; Fri, 18 Jul 2003 05:26: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 FAA24377 for ; Fri, 18 Jul 2003 05:26:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dRVV-0006ym-00 for sipping@ietf.org; Fri, 18 Jul 2003 05:26:29 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 19dRVK-0006yg-00 for sipping@ietf.org; Fri, 18 Jul 2003 05:26:18 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id h6I9Q5Y29988; Fri, 18 Jul 2003 11:26:06 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id h6I9Q4q00449; Fri, 18 Jul 2003 11:26:04 +0200 (MEST) Received: from mchh273e.demchh201e.icn.siemens.de (mchh273e.mchh.siemens.de [139.21.200.83]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id LAA06688; Fri, 18 Jul 2003 11:26:03 +0200 (MET DST) Received: by mchh273e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Fri, 18 Jul 2003 11:25:29 +0200 Message-ID: <931A17FBB884D411B02B0008C70D9E2ABF1324@mchh243e.mchh.siemens.de> From: Stupka Jean-Marie To: "'Alan Johnston'" Cc: "'Jonathan Rosenberg'" , Rohan Mahy , "'sipping@ietf.org'" Subject: AW: AW: AW: [Sipping] Question on INVITE Initiated Dialog Event P ackage and Automatic Callback Date: Fri, 18 Jul 2003 11:25:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) 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: , Hi Alan, all, Thanks for your answer. Having seen your comments, I think that my previous mail was somewhat unclear. Let me clarify my concerns with the flows below. A GW / B | | | INVITE F1 | |--------------->| |486 Busy Here F2| |<---------------| User B is busy | ACK F3 | |--------------->| | | | | User A calls user B which is either a SIP client (B) or a PSTN subscriber behind a Gateway (GW). User B is initially busy when User A calls. The dialog initiated by the INVITE terminates upon reception of the 486. After having received the 486, a standard SIP client -- i.e. a client compliant to RFC3261 -- considers the INVITE transaction completed and generates the ACK for the response (this behavior is described in 13.2.2.3 of RFC3261). 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. For the reason above, a procedure is needed to keep the dialog/transaction open after a 486. Of course it would only make sense to keep the dialog if an automatic callback is possible, e.g. not precluded by other services at the remote user side, lacking network resources, etc. This should be indicated to the A's SIP UA. If automatic callback is possible, then the dialog (the transaction having the call data) shall not be terminated upon reception of a 486, leaving user A the possibility to request automatic callback. If user A does not request automatic callback within a reasonable time interval (about 10-15s) the dialog terminates. If user A does request automatic callback then a SUBSCRIBE (F4) is sent on the already existing dialog that was initiated by the preceding INVITE (F1). Sending the SUBSCRIBE within the dialog initiated by the INVITE of the preceding call attempt would ease the implementation because the call data are available within this dialog at the SIP user side and at its peer (e.g. the gateway in the PSTN). The call data can then be re-used for the SUBSCRIBE request and for the subsequent call when user B gets free. The flow then looks like this: A GW / B | | | INVITE F1 | |--------------->| |486 Busy Here F2| |<---------------| User B is busy T |(Autom.Callback | T Timer for automatic callback | | possible) | | | | ACK F3 | | | |--------------->| | | | | | ==> | | | | User A requests automatic callback | | | | | | SUBSCRIBE F4 | | v |--------------->| v | 200 OK F5 | |<---------------| | NOTIFY F6 | |<---------------| | 200 OK F7 | |--------------->| | | | NOTIFY F8 | <== User B is now available |<---------------| | 200 OK F9 | |--------------->| | | | INVITE F10 | |--------------->| Session setup successfully | 180 Ringing F11| |<---------------| | 200 OK F12 | |<---------------| | ACK F13 | |--------------->| | Media Session | |<==============>| | | User A calls user B which is either a SIP client (B) or a PSTN subscriber behind a Gateway (GW). User B is initially busy when user A calls. - F1 INVITE creates a new dialog between A and GW/B (let's say D1) - F2 486 Busy Here: automatic callback is possible. GW/B indicates to A that automatic callback is possible and starts a timer in order to retain the dialog and call data for a possible request for automatic callback. When receiving a 486 with the indication automatic callback possible, A starts a timer in order to retain the dialog and call data giving user A the possibility to request automatic callback. If the timer expires (no callback request has arrived) then the dialog/transaction is terminated at A and GW/B. - User A requests automatic callback: A stops the timer and sends a SUBSCRIBE request to GW/B (F4) within the dialog (D1) initiated by the preceding INVITE. There is one hand no necessity to open a new dialog, and one the other hand, sending the SUBSCRIBE within the dialog initiated by the INVITE of the preceding call attempt would ease the implementation because the call data are available within this dialog at the SIP user side and at its peer (e.g. the gateway in the PSTN) - F4 SUBSCRIBE: GW/B stops the timer and starts monitoring B states. F5, F6, F7, F8, F9 as in 2.17 of draft-ietf-sipping-service-examples-04.txt - F10 INVITE: A sends the INVITE within the still open dialog (D1) initiated by F1 (reason given above) - F11, etc. as in 2.17 Summary: - There is a need to retain dialogs initiated by an INVITE after a 486 message when automatic callback is possible - It is desirable that the SUBSCRIBE request and a subsequent call set-up triggered by the NOTIFY uses the pre-existing dialog initiated by the preceding INVITE. I hope I have clarified my concerns. Regards, Jean-Marie > -----Ursprungliche Nachricht----- > Von: Alan Johnston [mailto:alan.johnston@mci.com] > Gesendet: Donnerstag, 17. Juli 2003 11:04 > An: Stupka Jean-Marie; Rohan Mahy > Cc: 'Jonathan Rosenberg'; 'sipping@ietf.org' > Betreff: Re: AW: AW: [Sipping] Question on INVITE Initiated > Dialog Event > Package and Automatic Callback > > > Hi Jean-Marie, > > Comments below. > > Thanks, > Alan Johnston > MCI > > At 10:21 AM 7/17/2003 +0200, Stupka Jean-Marie wrote: > >Hi Alan, > > > >The flow 2.17 of draft-ietf-sipping-service-examples-04.txt > is a good > >example to show what is wrong. After the 486 message and the ACK the > >transaction is terminated: 13.2.2.3 of RFC3261 says "All > early dialogs are > >considered terminated upon reception of the non-2xx final response". > > In this flow, the dialog between Alice and Bob does terminate > with the > INVITE/486/ACK exchange. However, Bob has a dialog with > another user, say > Carol (perhaps the flow should show this for clarity?). If > Bob was not > currently involved in a dialog, the 486 would not have been > sent, right? Right. > > > As a consequence, all data related to the previous call > attempt are lost > > (why and how long should a SIP client keep this data?). > This is at least > > conforming RFC3261. > > Bob is in a dialog with Carol and keeps this dialog state for > as long as > the session exists (as long as Bob is busy). Right. > > >Therefore, the SUBSCRIBE message shown in the flow is just > not possible, > >as the destination address (Bob's address or user number) is no more > >existing at the SIP user side. > > I don't know what you mean here. Bob still exists - he is still > sip:bob@biloxi.example.com, right? As a result, Bob can receive a > SUBSCRIBE request from Alice. Alice does not specify any > call-id, to-tag, > or from-tag Event parameters, so that means that Alice is requesting > information about ANY dialogs that Bob is currently active > in. (Alice is > not requesting information about only dialogs with Alice - > this information > would be redundant since if Alice is in the dialog, Alice > would already > know the state and dialog identifiers.) All the NOTIFYs that Alice > receives provides information about the dialog between Bob and Carol. > See explanation and flows above. > >Keeping the data for a short period of time after a 486 > would help, but I > >wouldn't say that this is an implementation matter, the > behavior of a SIP > >client needs to be predictable, i.e. standardized. > > Dialog state does need to be kept for 32 seconds after sending a > non-success final response in case of the loss of the 486 > which would be > detected by the failure to receive an ACK. However, this has > no bearing on > this scenario. See explanation and flows above. > > >Coming back to my initial concern, the PSTN call completion > application > >given as an example in > draft-ietf-sipping-dialog-package-02.txt. Sending a > >SUBSCRIBE to the Dialog Package within the dialog initiated > by the INVITE > >of the preceding call attempt would ease the implementation > because the > >call data are available within this dialog at the SIP user > side and at its > >peer (e.g. the gateway in the PSTN). This is in my understanding the > >benefit of draft-ietf-sipping-dialog-package-02.txt. > > Are you saying that you would like Alice to be able to send a > SUBSCRIBE to > Bob within the dialog between Bob and Carol? This is not > possible - a > dialog is between two peers - a third party can not inject messages. > Of course not, see explanation and flows above. > > >A possible solution would be to keep for a short period of > time the dialog > >with the data of the previous call attempt (i.e. the called > user number, > >the bearer description, ...) at the user agent after a 486 > is received if > >an automatic callback is possible (e.g. not precluded by > other services at > >the remote user side, lacking network resources, etc.). > > Are you perhaps concerned about authorizing the subscription? > That is, Bob > only accepts a SUBSCRIBE from Alice if Alice has previously > just made a > call attempt (sent an INVITE and received a 486 busy)? If > this is what you > want, I'm not sure the exact benefit of this. Not at all my concern. > > >Then the called user number and other data from the > preceding call attempt > >could be re-used for the SUBSCRIBE request and for the > subsequent call > >when the remote user gets free. This would require to extend > the 486 with > >a "Automatic Callback Possible" indication, or to introduce > a new message > >with this meaning and the procedure of retaining data - a > change to RFC3261. > > > >Any view on that? > > > >Thanks, > >Jean-Marie > > > > > >-----Ursprungliche Nachricht----- > >Von: Alan Johnston [mailto:alan.johnston@mci.com] > >Gesendet: Mittwoch, 16. Juli 2003 20:39 > >An: Rohan Mahy; Stupka Jean-Marie > >Cc: 'Jonathan Rosenberg'; 'sipping@ietf.org' > >Betreff: Re: AW: [Sipping] Question on INVITE Initiated Dialog Event > >Package a nd Automatic C allback > > > > > >Hi Jean-Marie, > > > >The SIP Service Examples section 2.17 shows exactly this flow with a > >SUBSCRIBE outside of the dialog (which ended with the 486). > > > >Thanks, > >Alan Johnston > >MCI > > > >At 05:21 AM 7/15/2003 -0700, Rohan Mahy wrote: > > >Jean-Marie, > > > > > >It seems perfectly reasonable to send a SUBSCRIBE to the > dialog package > > >outside of a dialog. The default behavior would be to > send a list of > > >dialogs but with no dialog information or peer > information. I believe > > >this is sufficient to build a callback service. > > > > > >thanks, > > >-rohan > > > > > > > > > > > >On Tuesday, July 15, 2003, at 02:53 AM, Stupka Jean-Marie wrote: > > > > > >>Jonathan, > > >> > > >>I doubt that sending the SUBSCRIBE request for the dialog > package outside > > >>of any dialog is possible in case of automatic callback, since the > > >>required data are no more available. > > >> > > >>The problem is that when a 486 is received, the dialog > initiated by the > > >>INVITE terminates and, the data related to that dialog > (including the > > >>called user number) disappear. Therefore it is no more > possible to send > > >>the SUBSCRIBE to request automatic callback for this destination. > > >> > > >>A possible solution would be to keep for a short period > of time the data > > >>of the previous call attempt (i.e. the called user > number, the bearer > > >>description, ...) at the user agent after a 486 is > received. This would > > >>allow the user agent to re-use the called user number and > other data from > > >>the preceding call attempt for the SUBSCRIBE request and for the > > >>subsequent call after the remote user is free. However, > the procedure of > > >>retaining data is not foreseen in RFC 3261. > > >> > > >>A better (more economical and user friendly) solution > would be to keep at > > >>the user agent only when an automatic callback is > possible (e.g. not > > >>precluded by other services at the remote user side, > lacking network > > >>resources, etc.). This would require to extend the 486 > with a "Automatic > > >>Callback Possible" indication, or to introduce a new > message with this > > meaning. > > >> > > >>Jean-Marie > > >> > > >>-----Ursprungliche Nachricht----- > > >>Von: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > >>Gesendet: Montag, 14. Juli 2003 10:18 > > >>An: Stupka Jean-Marie > > >>Cc: 'sipping@ietf.org' > > >>Betreff: Re: [Sipping] Question on INVITE Initiated > Dialog Event Package > > >>and Automatic C allback > > >> > > >> > > >>The dialog package can be used by subscriptions made both > within, and > > >>outside, of a dialog. So, in the case of automatic callback, the > > >>caller would, after receiving a 486, send a SUBSCRIBE > request for the > > >>dialog package, and do so outside of any dialog. > > >> > > >>-Jonathan R. > > >> > > >>Stupka Jean-Marie wrote: > > >> > > >>>Hello All, > > >>> > > >>>As said in RFC 3265 it is possible to create an event > subscription > > >>>within a pre-existing dialog, e.g. a dialog created by an INVITE. > > >>>In my understanding, this is the intention of > > >>>draft-ietf-sipping-dialog-package-02.txt. > > >>> > > >>>According to the (PSTN) Automatic Callback given as example > > >>>application in the introduction of this draft, user A > can request a > > >>>callback when user B hangs-up. User A off course needs to get the > > >>>information that user B is busy before requesting the automatic > > >>>callback, i.e. receive a "486 Busy Here" message. However, all > > >>>early dialogs are considered terminated upon reception > of a non-2xx > > >>>final response (13.2.2.3 of RFC 3261). As consequence, the dialog > > >>>and thus the data of the preceding call attempt are no more > > >>>available and the callback cannot be requested. > > >>> > > >>>Can somebody provide clarification of the applicability > of RFC 3265 > > >>>and the draft-ietf-sipping-dialog-package-02.txt to Automatic > > >>>Callback? > > >>> > > >>>Regards, > > >>> > > >>>Jean-Marie > > >>> > > >>> > > >>>_______________________________________________ Sipping mailing > > >>>list https://www1.ietf.org/mailman/listinfo/sipping This list is > > >>>for NEW development of the 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 Fri Jul 18 05:28: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 FAA24510 for ; Fri, 18 Jul 2003 05:28: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 19dRX7-0005D9-SC for sipping-archive@odin.ietf.org; Fri, 18 Jul 2003 05:28:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6I9S9sO020032 for sipping-archive@odin.ietf.org; Fri, 18 Jul 2003 05:28:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dRX7-0005D1-KF for sipping-web-archive@optimus.ietf.org; Fri, 18 Jul 2003 05:28: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 FAA24470 for ; Fri, 18 Jul 2003 05:28:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dRX4-00070R-00 for sipping-web-archive@ietf.org; Fri, 18 Jul 2003 05:28:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dRWy-00070O-00 for sipping-web-archive@ietf.org; Fri, 18 Jul 2003 05:28:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dRX0-00053V-OP; Fri, 18 Jul 2003 05:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dRWm-0004wx-WE for sipping@optimus.ietf.org; Fri, 18 Jul 2003 05:27: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 FAA24443 for ; Fri, 18 Jul 2003 05:27:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dRWj-0006zu-00 for sipping@ietf.org; Fri, 18 Jul 2003 05:27:45 -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 19dRWY-0006zD-00 for sipping@ietf.org; Fri, 18 Jul 2003 05:27:35 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 18 Jul 2003 02:31:57 -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 h6I9QuuD001512; Fri, 18 Jul 2003 02:26:56 -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 AJH96253; Fri, 18 Jul 2003 02:23:39 -0700 (PDT) Date: Fri, 18 Jul 2003 02:28:54 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Henry Sinnreich To: "'sipping@ietf.org'" From: Rohan Mahy Content-Transfer-Encoding: 7bit Message-Id: <3FCEAC5E-B902-11D7-9589-0003938AF740@cisco.com> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Sipping] results from the sipdev Adhoc thursday morning Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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, Henry Sinnreich organized an adhoc meeting Thursday morning to discuss an open issue in an individual draft related to SIPPING which was consuming a lot of list traffic. His document is an informational individual draft (not the product of the SIP or SIPPING WGs) designed to capture guidance from a group of implementors on what is useful to implement in a SIP telephony device (draft-sinnreich-sipping-sipdev-01.txt). This following folks attended the adhoc: Henry Sinnreich - henry.sinnreichATmci.com Christian Stredicke - csATsnom.de John Elwell - john.elwellATsiemens.com JF Rey - jean-francois.reyATbst.bsf.alcatel.fr Peter Darling - p.darlingATacif.org.au Steven Lass - steven.lassATmci.com Makoto Saito - ma.saitoATntt.com Scott Huddle - scott.huddleATmci.com Atte Monrad - atte.monradATericsson.com Georg Mayer - georg.mayerATnokia.com Peter Kozdon - pkozdonATieee.org Wilhelm Wimmreuter - wilhelmATwimmreuter.de Lawrence Conroy - lwcATroke.co.uk Arnoud van Wijk - a.vwijkATviataal.nl Rohan Mahy - rohanATcisco.com Eric Burger - e_burgerATieee.org Cullen Jennings - fluffyATcisco.com David Oran - oranATcisco.com Wolfgang Beck - beckwATt-systems.com Dan Petrie - dpetrieATpingtel.com Bob Hughes - rchughesATus.ibm.com Guido Gybels - guido.gybelsATrnid.org.uk Richard Stastny - richard.stastnyAToc.tcg.at The group proposed the following text be incorporated in to the sipdev draft for accessibility purposes: 1. SIP telephony devices which include a display, or have a facility for connecting an external display, MUST include protocol support for RFC2793 for real-time interactive text. (strong consensus, with a few objectors requesting SHOULD strength instead) 2. SIP telephony devices SHOULD provide a way to input text and display text through any reasonable method. Built-in user interfaces, standard wired or wireless interfaces, and/or support for text through a web interface are all considered reasonable mechanisms. In addition, SIP telephony devices SHOULD provide an external standard wired or wireless interface or interfaces to connect external input and display devices. (unanimous consent) 3. A SIP telephony device MAY provide analog adaptor functionality through an RJ-11 (FXS) port. If an RJ-11 (FXS) port is provided, then it MAY support a gateway function from text telephone protocols to RFC-2793 text messaging (in fact this is encouraged in the near term). If this gateway function is not included or fails, the device MUST pass-through all text-telephone protocols in a transparent fashion according to [insert ref here]. (strong consensus with a few objections) 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 Fri Jul 18 05:48: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 FAA25190 for ; Fri, 18 Jul 2003 05:48: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 19dRqX-0006Lj-Nq for sipping-archive@odin.ietf.org; Fri, 18 Jul 2003 05:48:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6I9mDah024407 for sipping-archive@odin.ietf.org; Fri, 18 Jul 2003 05:48:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dRqW-0006La-9H for sipping-web-archive@optimus.ietf.org; Fri, 18 Jul 2003 05:48: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 FAA25180 for ; Fri, 18 Jul 2003 05:48:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dRqS-0007Ba-00 for sipping-web-archive@ietf.org; Fri, 18 Jul 2003 05:48:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dRqM-0007BX-00 for sipping-web-archive@ietf.org; Fri, 18 Jul 2003 05:48:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dRqL-0006IL-HO; Fri, 18 Jul 2003 05: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 19dRq6-0006Hv-BP for sipping@optimus.ietf.org; Fri, 18 Jul 2003 05:47: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 FAA25170 for ; Fri, 18 Jul 2003 05:47:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dRq2-0007B9-00 for sipping@ietf.org; Fri, 18 Jul 2003 05:47:42 -0400 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 19dRpr-00079g-00 for sipping@ietf.org; Fri, 18 Jul 2003 05:47:31 -0400 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 13544; Fri, 18 Jul 2003 05:46:14 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: AW: AW: AW: [Sipping] Question on INVITE Initiated Dialog Event Package and Automatic Callback Date: Fri, 18 Jul 2003 05:43:51 -0400 Message-ID: <4A3384433CE2AB46A63468CB207E209D097CC8@zoe.office.snowshore.com> Thread-Topic: AW: AW: [Sipping] Question on INVITE Initiated Dialog Event Package and Automatic Callback Thread-Index: AcNNDvw3W8TCasTgQeG3DInTzngkswAASWMJ From: "Eric Burger" To: "Stupka Jean-Marie" , "Alan Johnston" Cc: "Jonathan Rosenberg" , "Rohan Mahy" , Content-Transfer-Encoding: base64 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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: base64 Content-Transfer-Encoding: base64 W3NvcnJ5IGZvciB0aGUgZm9ybWF0dGluZyAtLSBXZWIgT3V0bG9vayBhdCBWSUVdDQogDQpJIGRv bid0IHVuZGVyc3RhbmQgd2h5IHRoZXJlIGlzIGEgbmVlZCB0byBoYXZlIHRoZSBjYWxsYmFjayBp biB0aGUgc2FtZSBkaWFsb2cuIEl0IGlzIGEgZGlmZmVyZW50IGNhbGwuIEl0IGlzIHVwIHRvIHRo ZSBVQUMgdG8ga25vdyBpdCB0cmllZCBhIGxvY2F0aW9uLCBnb3QgYSA0ODYsIGFuZCBzaG91bGQg dHJ5IGFnYWluIGxhdGVyLiAgQXMgQWxhbiB3cm90ZSwgeW91IGRvbid0IG5lZWQgdG8gYmUgaW4g YSBkaWFsb2cgdG8gc3Vic2NyaWJlIHRvIHRoZSBkaWFsb2cgc3RhdGUuDQogDQpJIGFtIHRyeWlu ZyB0byB1bmRlcnN0YW5kIHRoZSByZXF1ZXN0LiAgSWYgaXQgaXMgdG8gc2ltcGx5IHNhdmUgb24g dGhlIEFDSywgaXQgaXMgbm90IHdvcnRoIGl0LiAgSXMgaXQgdG8gaGF2ZSBzb21ldGhpbmcgc3Bl Y2lhbCBnb2luZyBvbiBhdCB0aGUgVUFTPyBGb3IgZXhhbXBsZSwgb25seSBhY2NlcHQgYW4gSU5W SVRFIGZyb20gYSBjYW1wZWQtb24gY2FsbGVyPyAgVGhlcmUgYXJlIGJldHRlciB3YXlzIG9mIGRv aW5nIHRoYXQsIGRyaXZlbiBieSB0aGUgVUEncywgYXMgd2VsbC4NCiANCiANCi0tLS0tVXJzcHLD vG5nbGljaGUgTmFjaHJpY2h0LS0tLS0gDQpWb246IFN0dXBrYSBKZWFuLU1hcmllIFttYWlsdG86 amVhbi1tYXJpZS5zdHVwa2FAc2llbWVucy5jb21dIA0KR2VzZW5kZXQ6IEZyIDE4LjA3LjIwMDMg MDU6MjUgDQpBbjogJ0FsYW4gSm9obnN0b24nIA0KQ2M6ICdKb25hdGhhbiBSb3NlbmJlcmcnOyBS b2hhbiBNYWh5OyAnc2lwcGluZ0BpZXRmLm9yZycgDQpCZXRyZWZmOiBBVzogQVc6IEFXOiBbU2lw cGluZ10gUXVlc3Rpb24gb24gSU5WSVRFIEluaXRpYXRlZCBEaWFsb2cgRXZlbnQgUGFja2FnZSBh bmQgQXV0b21hdGljIENhbGxiYWNrDQoNCg0KDQoJSGkgQWxhbiwgYWxsLA0KCQ0KCVRoYW5rcyBm b3IgeW91ciBhbnN3ZXIuIEhhdmluZyBzZWVuIHlvdXIgY29tbWVudHMsIEkgdGhpbmsgdGhhdCBt eSBwcmV2aW91cyBtYWlsIHdhcyBzb21ld2hhdCB1bmNsZWFyLiBMZXQgbWUgY2xhcmlmeSBteSBj b25jZXJucyB3aXRoIHRoZSBmbG93cyBiZWxvdy4NCgkNCgkNCgkgICAgICAgICAgQSAgICAgICAg ICAgICBHVyAvIEINCgkgICAgICAgICAgfCAgICAgICAgICAgICAgICB8DQoJICAgICAgICAgIHwg ICAgSU5WSVRFIEYxICAgfA0KCSAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0tPnwNCgkgICAgICAg ICAgfDQ4NiBCdXN5IEhlcmUgRjJ8DQoJICAgICAgICAgIHw8LS0tLS0tLS0tLS0tLS0tfCAgICBV c2VyIEIgaXMgYnVzeQ0KCSAgICAgICAgICB8ICAgICBBQ0sgRjMgICAgIHwNCgkgICAgICAgICAg fC0tLS0tLS0tLS0tLS0tLT58DQoJICAgICAgICAgIHwgICAgICAgICAgICAgICAgfA0KCSAgICAg ICAgICB8ICAgICAgICAgICAgICAgIHwNCgkNCglVc2VyIEEgY2FsbHMgdXNlciBCIHdoaWNoIGlz IGVpdGhlciBhIFNJUCBjbGllbnQgKEIpIG9yIGEgUFNUTiBzdWJzY3JpYmVyIGJlaGluZCBhIEdh dGV3YXkgKEdXKS4gVXNlciBCIGlzIGluaXRpYWxseSBidXN5IHdoZW4gVXNlciBBIGNhbGxzLg0K CQ0KCVRoZSBkaWFsb2cgaW5pdGlhdGVkIGJ5IHRoZSBJTlZJVEUgdGVybWluYXRlcyB1cG9uIHJl Y2VwdGlvbiBvZiB0aGUgNDg2LiBBZnRlciBoYXZpbmcgcmVjZWl2ZWQgdGhlIDQ4NiwgYSBzdGFu ZGFyZCBTSVAgY2xpZW50IC0tIGkuZS4gYSBjbGllbnQgY29tcGxpYW50IHRvIFJGQzMyNjEgLS0g Y29uc2lkZXJzIHRoZSBJTlZJVEUgdHJhbnNhY3Rpb24gY29tcGxldGVkIGFuZCBnZW5lcmF0ZXMg dGhlIEFDSyBmb3IgdGhlIHJlc3BvbnNlICh0aGlzIGJlaGF2aW9yIGlzIGRlc2NyaWJlZCBpbiAx My4yLjIuMyBvZiBSRkMzMjYxKS4NCgkNCglUaGUgdHJhbnNhY3Rpb24gYmVpbmcgdGVybWluYXRl ZCwgdGhlIGRhdGEgb2YgdGhlIGNhbGwgYXR0ZW1wdCBhcmUgZGVsZXRlZCBhbmQgdGh1cyB0aGUg ZGF0YSAoaW5jbHVkaW5nIHVzZXIgQidzIG51bWJlcikgYXJlIG5vIG1vcmUgYXZhaWxhYmxlIGZv ciBhIHN1YnNlcXVlbnQgYXV0b21hdGljIGNhbGxiYWNrIHJlcXVlc3QsIHJpZ2h0Pw0KCUlmIEkg YW0gd3JvbmcsIGNvdWxkIHlvdSBwbGVhc2Ugc2hvdyBtZSB3aGVyZSBpdCBpcyBzYWlkIGluIFJG QzMyNjEgdGhhdCBhIFNJUCB1c2VyIGFnZW50IGhhcyB0byBrZWVwIGRhdGEgb2YgYSB0cmFuc2Fj dGlvbiB0aGF0IGlzIHRlcm1pbmF0ZWQuDQoJDQoJRm9yIHRoZSByZWFzb24gYWJvdmUsIGEgcHJv Y2VkdXJlIGlzIG5lZWRlZCB0byBrZWVwIHRoZSBkaWFsb2cvdHJhbnNhY3Rpb24gb3BlbiBhZnRl ciBhIDQ4Ni4gT2YgY291cnNlIGl0IHdvdWxkIG9ubHkgbWFrZSBzZW5zZSB0byBrZWVwIHRoZSBk aWFsb2cgaWYgYW4gYXV0b21hdGljIGNhbGxiYWNrIGlzIHBvc3NpYmxlLCBlLmcuIG5vdCBwcmVj bHVkZWQgYnkgb3RoZXIgc2VydmljZXMgYXQgdGhlIHJlbW90ZSB1c2VyIHNpZGUsIGxhY2tpbmcg bmV0d29yayByZXNvdXJjZXMsIGV0Yy4gVGhpcyBzaG91bGQgYmUgaW5kaWNhdGVkIHRvIHRoZSBB J3MgU0lQIFVBLiBJZiBhdXRvbWF0aWMgY2FsbGJhY2sgaXMgcG9zc2libGUsIHRoZW4gdGhlIGRp YWxvZyAodGhlIHRyYW5zYWN0aW9uIGhhdmluZyB0aGUgY2FsbCBkYXRhKSBzaGFsbCBub3QgYmUg dGVybWluYXRlZCB1cG9uIHJlY2VwdGlvbiBvZiBhIDQ4NiwgbGVhdmluZyB1c2VyIEEgdGhlIHBv c3NpYmlsaXR5IHRvIHJlcXVlc3QgYXV0b21hdGljIGNhbGxiYWNrLg0KCUlmIHVzZXIgQSBkb2Vz IG5vdCByZXF1ZXN0IGF1dG9tYXRpYyBjYWxsYmFjayB3aXRoaW4gYSByZWFzb25hYmxlIHRpbWUg aW50ZXJ2YWwgKGFib3V0IDEwLTE1cykgdGhlIGRpYWxvZyB0ZXJtaW5hdGVzLg0KCUlmIHVzZXIg QSBkb2VzIHJlcXVlc3QgYXV0b21hdGljIGNhbGxiYWNrIHRoZW4gYSBTVUJTQ1JJQkUgKEY0KSBp cyBzZW50IG9uIHRoZSBhbHJlYWR5IGV4aXN0aW5nIGRpYWxvZyB0aGF0IHdhcyBpbml0aWF0ZWQg YnkgdGhlIHByZWNlZGluZyBJTlZJVEUgKEYxKS4gU2VuZGluZyB0aGUgU1VCU0NSSUJFIHdpdGhp biB0aGUgZGlhbG9nIGluaXRpYXRlZCBieSB0aGUgSU5WSVRFIG9mIHRoZSBwcmVjZWRpbmcgY2Fs bCBhdHRlbXB0IHdvdWxkIGVhc2UgdGhlIGltcGxlbWVudGF0aW9uIGJlY2F1c2UgdGhlIGNhbGwg ZGF0YSBhcmUgYXZhaWxhYmxlIHdpdGhpbiB0aGlzIGRpYWxvZyBhdCB0aGUgU0lQIHVzZXIgc2lk ZSBhbmQgYXQgaXRzIHBlZXIgKGUuZy4gdGhlIGdhdGV3YXkgaW4gdGhlIFBTVE4pLiBUaGUgY2Fs bCBkYXRhIGNhbiB0aGVuIGJlIHJlLXVzZWQgZm9yIHRoZSBTVUJTQ1JJQkUgcmVxdWVzdCBhbmQg Zm9yIHRoZSBzdWJzZXF1ZW50IGNhbGwgd2hlbiB1c2VyIEIgZ2V0cyBmcmVlLg0KCQ0KCVRoZSBm bG93IHRoZW4gbG9va3MgbGlrZSB0aGlzOg0KCQ0KCQ0KCSAgICAgICAgICBBICAgICAgICAgICAg IEdXIC8gQg0KCSAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwNCgkgICAgICAgICAgfCAgICBJ TlZJVEUgRjEgICB8DQoJICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0+fA0KCSAgICAgICAgICB8 NDg2IEJ1c3kgSGVyZSBGMnwNCgkgICAgICAgICAgfDwtLS0tLS0tLS0tLS0tLS18ICAgICAgVXNl ciBCIGlzIGJ1c3kNCgkgICAgIFQgICAgfChBdXRvbS5DYWxsYmFjayB8ICAgVCAgVGltZXIgZm9y IGF1dG9tYXRpYyBjYWxsYmFjaw0KCSAgICAgfCAgICB8ICAgcG9zc2libGUpICAgIHwgICB8DQoJ ICAgICB8ICAgIHwgICAgIEFDSyBGMyAgICAgfCAgIHwNCgkgICAgIHwgICAgfC0tLS0tLS0tLS0t LS0tLT58ICAgfA0KCSAgICAgfCAgICB8ICAgICAgICAgICAgICAgIHwgICB8DQoJPT0+ICB8ICAg IHwgICAgICAgICAgICAgICAgfCAgIHwgIFVzZXIgQSByZXF1ZXN0cyBhdXRvbWF0aWMgY2FsbGJh Y2sNCgkgICAgIHwgICAgfCAgICAgICAgICAgICAgICB8ICAgfA0KCSAgICAgfCAgICB8ICBTVUJT Q1JJQkUgRjQgIHwgICB8DQoJICAgICB2ICAgIHwtLS0tLS0tLS0tLS0tLS0+fCAgIHYNCgkgICAg ICAgICAgfCAgIDIwMCBPSyBGNSAgICB8DQoJICAgICAgICAgIHw8LS0tLS0tLS0tLS0tLS0tfA0K CSAgICAgICAgICB8ICAgIE5PVElGWSBGNiAgIHwNCgkgICAgICAgICAgfDwtLS0tLS0tLS0tLS0t LS18DQoJICAgICAgICAgIHwgICAyMDAgT0sgRjcgICAgfA0KCSAgICAgICAgICB8LS0tLS0tLS0t LS0tLS0tPnwNCgkgICAgICAgICAgfCAgICAgICAgICAgICAgICB8DQoJICAgICAgICAgIHwgICAg Tk9USUZZIEY4ICAgfCAgPD09IFVzZXIgQiBpcyBub3cgYXZhaWxhYmxlDQoJICAgICAgICAgIHw8 LS0tLS0tLS0tLS0tLS0tfA0KCSAgICAgICAgICB8ICAgMjAwIE9LIEY5ICAgIHwNCgkgICAgICAg ICAgfC0tLS0tLS0tLS0tLS0tLT58DQoJICAgICAgICAgIHwgICAgICAgICAgICAgICAgfA0KCSAg ICAgICAgICB8ICAgSU5WSVRFIEYxMCAgIHwNCgkgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLT58 ICAgICAgU2Vzc2lvbiBzZXR1cCBzdWNjZXNzZnVsbHkNCgkgICAgICAgICAgfCAxODAgUmluZ2lu ZyBGMTF8DQoJICAgICAgICAgIHw8LS0tLS0tLS0tLS0tLS0tfA0KCSAgICAgICAgICB8ICAgMjAw IE9LIEYxMiAgIHwNCgkgICAgICAgICAgfDwtLS0tLS0tLS0tLS0tLS18DQoJICAgICAgICAgIHwg ICAgIEFDSyBGMTMgICAgfA0KCSAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0tPnwNCgkgICAgICAg ICAgfCAgTWVkaWEgU2Vzc2lvbiB8DQoJICAgICAgICAgIHw8PT09PT09PT09PT09PT0+fA0KCSAg ICAgICAgICB8ICAgICAgICAgICAgICAgIHwNCgkNCglVc2VyIEEgY2FsbHMgdXNlciBCIHdoaWNo IGlzIGVpdGhlciBhIFNJUCBjbGllbnQgKEIpIG9yIGEgUFNUTiBzdWJzY3JpYmVyIGJlaGluZCBh IEdhdGV3YXkgKEdXKS4gVXNlciBCIGlzIGluaXRpYWxseSBidXN5IHdoZW4gdXNlciBBIGNhbGxz Lg0KCQ0KCS0gRjEgSU5WSVRFIGNyZWF0ZXMgYSBuZXcgZGlhbG9nIGJldHdlZW4gQSBhbmQgR1cv QiAobGV0J3Mgc2F5IEQxKQ0KCQ0KCS0gRjIgNDg2IEJ1c3kgSGVyZTogYXV0b21hdGljIGNhbGxi YWNrIGlzIHBvc3NpYmxlLg0KCUdXL0IgaW5kaWNhdGVzIHRvIEEgdGhhdCBhdXRvbWF0aWMgY2Fs bGJhY2sgaXMgcG9zc2libGUgYW5kIHN0YXJ0cyBhIHRpbWVyIGluIG9yZGVyIHRvIHJldGFpbiB0 aGUgZGlhbG9nIGFuZCBjYWxsIGRhdGEgZm9yIGEgcG9zc2libGUgcmVxdWVzdCBmb3IgYXV0b21h dGljIGNhbGxiYWNrLg0KCVdoZW4gcmVjZWl2aW5nIGEgNDg2IHdpdGggdGhlIGluZGljYXRpb24g YXV0b21hdGljIGNhbGxiYWNrIHBvc3NpYmxlLCBBIHN0YXJ0cyBhIHRpbWVyIGluIG9yZGVyIHRv IHJldGFpbiB0aGUgZGlhbG9nIGFuZCBjYWxsIGRhdGEgZ2l2aW5nIHVzZXIgQSB0aGUgcG9zc2li aWxpdHkgdG8gcmVxdWVzdCBhdXRvbWF0aWMgY2FsbGJhY2suDQoJSWYgdGhlIHRpbWVyIGV4cGly ZXMgKG5vIGNhbGxiYWNrIHJlcXVlc3QgaGFzIGFycml2ZWQpIHRoZW4gdGhlIGRpYWxvZy90cmFu c2FjdGlvbiBpcyB0ZXJtaW5hdGVkIGF0IEEgYW5kIEdXL0IuDQoJDQoJLSBVc2VyIEEgcmVxdWVz dHMgYXV0b21hdGljIGNhbGxiYWNrOiBBIHN0b3BzIHRoZSB0aW1lciBhbmQgc2VuZHMgYSBTVUJT Q1JJQkUgcmVxdWVzdCB0byBHVy9CIChGNCkgd2l0aGluIHRoZSBkaWFsb2cgKEQxKSBpbml0aWF0 ZWQgYnkgdGhlIHByZWNlZGluZyBJTlZJVEUuIFRoZXJlIGlzIG9uZSBoYW5kIG5vIG5lY2Vzc2l0 eSB0byBvcGVuIGEgbmV3IGRpYWxvZywgYW5kIG9uZSB0aGUgb3RoZXIgaGFuZCwgc2VuZGluZyB0 aGUgU1VCU0NSSUJFIHdpdGhpbiB0aGUgZGlhbG9nIGluaXRpYXRlZCBieSB0aGUgSU5WSVRFIG9m IHRoZSBwcmVjZWRpbmcgY2FsbCBhdHRlbXB0IHdvdWxkIGVhc2UgdGhlIGltcGxlbWVudGF0aW9u IGJlY2F1c2UgdGhlIGNhbGwgZGF0YSBhcmUgYXZhaWxhYmxlIHdpdGhpbiB0aGlzIGRpYWxvZyBh dCB0aGUgU0lQIHVzZXIgc2lkZSBhbmQgYXQgaXRzIHBlZXIgKGUuZy4gdGhlIGdhdGV3YXkgaW4g dGhlIFBTVE4pDQoJDQoJLSBGNCBTVUJTQ1JJQkU6IEdXL0Igc3RvcHMgdGhlIHRpbWVyIGFuZCBz dGFydHMgbW9uaXRvcmluZyBCIHN0YXRlcy4NCglGNSwgRjYsIEY3LCBGOCwgRjkgYXMgaW4gMi4x NyBvZiBkcmFmdC1pZXRmLXNpcHBpbmctc2VydmljZS1leGFtcGxlcy0wNC50eHQNCgkNCgktIEYx MCBJTlZJVEU6IEEgc2VuZHMgdGhlIElOVklURSB3aXRoaW4gdGhlIHN0aWxsIG9wZW4gZGlhbG9n IChEMSkgaW5pdGlhdGVkIGJ5IEYxIChyZWFzb24gZ2l2ZW4gYWJvdmUpDQoJDQoJLSBGMTEsIGV0 Yy4gYXMgaW4gMi4xNw0KCQ0KCVN1bW1hcnk6DQoJLSBUaGVyZSBpcyBhIG5lZWQgdG8gcmV0YWlu IGRpYWxvZ3MgaW5pdGlhdGVkIGJ5IGFuIElOVklURSBhZnRlciBhIDQ4NiBtZXNzYWdlIHdoZW4g YXV0b21hdGljIGNhbGxiYWNrIGlzIHBvc3NpYmxlDQoJLSBJdCBpcyBkZXNpcmFibGUgdGhhdCB0 aGUgU1VCU0NSSUJFIHJlcXVlc3QgYW5kIGEgc3Vic2VxdWVudCBjYWxsIHNldC11cCB0cmlnZ2Vy ZWQgYnkgdGhlIE5PVElGWSB1c2VzIHRoZSBwcmUtZXhpc3RpbmcgZGlhbG9nIGluaXRpYXRlZCBi eSB0aGUgcHJlY2VkaW5nIElOVklURS4NCgkNCglJIGhvcGUgSSBoYXZlIGNsYXJpZmllZCBteSBj b25jZXJucy4NCgkNCglSZWdhcmRzLA0KCUplYW4tTWFyaWUNCgkNCgkNCgkNCgk+IC0tLS0tVXJz cHJ1bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KCT4gVm9uOiBBbGFuIEpvaG5zdG9uIFttYWlsdG86 YWxhbi5qb2huc3RvbkBtY2kuY29tXQ0KCT4gR2VzZW5kZXQ6IERvbm5lcnN0YWcsIDE3LiBKdWxp IDIwMDMgMTE6MDQNCgk+IEFuOiBTdHVwa2EgSmVhbi1NYXJpZTsgUm9oYW4gTWFoeQ0KCT4gQ2M6 ICdKb25hdGhhbiBSb3NlbmJlcmcnOyAnc2lwcGluZ0BpZXRmLm9yZycNCgk+IEJldHJlZmY6IFJl OiBBVzogQVc6IFtTaXBwaW5nXSBRdWVzdGlvbiBvbiBJTlZJVEUgSW5pdGlhdGVkDQoJPiBEaWFs b2cgRXZlbnQNCgk+IFBhY2thZ2UgYW5kIEF1dG9tYXRpYyBDYWxsYmFjaw0KCT4NCgk+DQoJPiBI aSBKZWFuLU1hcmllLA0KCT4NCgk+IENvbW1lbnRzIGJlbG93Lg0KCT4NCgk+IFRoYW5rcywNCgk+ IEFsYW4gSm9obnN0b24NCgk+IE1DSQ0KCT4NCgk+IEF0IDEwOjIxIEFNIDcvMTcvMjAwMyArMDIw MCwgU3R1cGthIEplYW4tTWFyaWUgd3JvdGU6DQoJPiA+SGkgQWxhbiwNCgk+ID4NCgk+ID5UaGUg ZmxvdyAyLjE3IG9mIGRyYWZ0LWlldGYtc2lwcGluZy1zZXJ2aWNlLWV4YW1wbGVzLTA0LnR4dA0K CT4gaXMgYSBnb29kDQoJPiA+ZXhhbXBsZSB0byBzaG93IHdoYXQgaXMgd3JvbmcuIEFmdGVyIHRo ZSA0ODYgbWVzc2FnZSBhbmQgdGhlIEFDSyB0aGUNCgk+ID50cmFuc2FjdGlvbiBpcyB0ZXJtaW5h dGVkOiAxMy4yLjIuMyBvZiBSRkMzMjYxIHNheXMgIkFsbA0KCT4gZWFybHkgZGlhbG9ncyBhcmUN Cgk+ID5jb25zaWRlcmVkIHRlcm1pbmF0ZWQgdXBvbiByZWNlcHRpb24gb2YgdGhlIG5vbi0yeHgg ZmluYWwgcmVzcG9uc2UiLg0KCT4NCgk+IEluIHRoaXMgZmxvdywgdGhlIGRpYWxvZyBiZXR3ZWVu IEFsaWNlIGFuZCBCb2IgZG9lcyB0ZXJtaW5hdGUNCgk+IHdpdGggdGhlDQoJPiBJTlZJVEUvNDg2 L0FDSyBleGNoYW5nZS4gIEhvd2V2ZXIsIEJvYiBoYXMgYSBkaWFsb2cgd2l0aA0KCT4gYW5vdGhl ciB1c2VyLCBzYXkNCgk+IENhcm9sIChwZXJoYXBzIHRoZSBmbG93IHNob3VsZCBzaG93IHRoaXMg Zm9yIGNsYXJpdHk/KS4gIElmDQoJPiBCb2Igd2FzIG5vdA0KCT4gY3VycmVudGx5IGludm9sdmVk IGluIGEgZGlhbG9nLCB0aGUgNDg2IHdvdWxkIG5vdCBoYXZlIGJlZW4NCgk+IHNlbnQsIHJpZ2h0 Pw0KCQ0KCVJpZ2h0Lg0KCQ0KCT4NCgk+ID4gIEFzIGEgY29uc2VxdWVuY2UsIGFsbCBkYXRhIHJl bGF0ZWQgdG8gdGhlIHByZXZpb3VzIGNhbGwNCgk+IGF0dGVtcHQgYXJlIGxvc3QNCgk+ID4gKHdo eSBhbmQgaG93IGxvbmcgc2hvdWxkIGEgU0lQIGNsaWVudCBrZWVwIHRoaXMgZGF0YT8pLg0KCT4g VGhpcyBpcyBhdCBsZWFzdA0KCT4gPiBjb25mb3JtaW5nIFJGQzMyNjEuDQoJPg0KCT4gQm9iIGlz IGluIGEgZGlhbG9nIHdpdGggQ2Fyb2wgYW5kIGtlZXBzIHRoaXMgZGlhbG9nIHN0YXRlIGZvcg0K CT4gYXMgbG9uZyBhcw0KCT4gdGhlIHNlc3Npb24gZXhpc3RzIChhcyBsb25nIGFzIEJvYiBpcyBi dXN5KS4NCgkNCglSaWdodC4NCgkNCgk+DQoJPiA+VGhlcmVmb3JlLCB0aGUgU1VCU0NSSUJFIG1l c3NhZ2Ugc2hvd24gaW4gdGhlIGZsb3cgaXMganVzdA0KCT4gbm90IHBvc3NpYmxlLA0KCT4gPmFz IHRoZSBkZXN0aW5hdGlvbiBhZGRyZXNzIChCb2IncyBhZGRyZXNzIG9yIHVzZXIgbnVtYmVyKSBp cyBubyBtb3JlDQoJPiA+ZXhpc3RpbmcgYXQgdGhlIFNJUCB1c2VyIHNpZGUuDQoJPg0KCT4gSSBk b24ndCBrbm93IHdoYXQgeW91IG1lYW4gaGVyZS4gIEJvYiBzdGlsbCBleGlzdHMgLSBoZSBpcyBz dGlsbA0KCT4gc2lwOmJvYkBiaWxveGkuZXhhbXBsZS5jb20sIHJpZ2h0PyAgQXMgYSByZXN1bHQs IEJvYiBjYW4gcmVjZWl2ZSBhDQoJPiBTVUJTQ1JJQkUgcmVxdWVzdCBmcm9tIEFsaWNlLiAgQWxp Y2UgZG9lcyBub3Qgc3BlY2lmeSBhbnkNCgk+IGNhbGwtaWQsIHRvLXRhZywNCgk+IG9yIGZyb20t dGFnIEV2ZW50IHBhcmFtZXRlcnMsIHNvIHRoYXQgbWVhbnMgdGhhdCBBbGljZSBpcyByZXF1ZXN0 aW5nDQoJPiBpbmZvcm1hdGlvbiBhYm91dCBBTlkgZGlhbG9ncyB0aGF0IEJvYiBpcyBjdXJyZW50 bHkgYWN0aXZlDQoJPiBpbi4gIChBbGljZSBpcw0KCT4gbm90IHJlcXVlc3RpbmcgaW5mb3JtYXRp b24gYWJvdXQgb25seSBkaWFsb2dzIHdpdGggQWxpY2UgLQ0KCT4gdGhpcyBpbmZvcm1hdGlvbg0K CT4gd291bGQgYmUgcmVkdW5kYW50IHNpbmNlIGlmIEFsaWNlIGlzIGluIHRoZSBkaWFsb2csIEFs aWNlDQoJPiB3b3VsZCBhbHJlYWR5DQoJPiBrbm93IHRoZSBzdGF0ZSBhbmQgZGlhbG9nIGlkZW50 aWZpZXJzLikgIEFsbCB0aGUgTk9USUZZcyB0aGF0IEFsaWNlDQoJPiByZWNlaXZlcyBwcm92aWRl cyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgZGlhbG9nIGJldHdlZW4gQm9iIGFuZCBDYXJvbC4NCgk+ DQoJDQoJU2VlIGV4cGxhbmF0aW9uIGFuZCBmbG93cyBhYm92ZS4NCgkNCgk+ID5LZWVwaW5nIHRo ZSBkYXRhIGZvciBhIHNob3J0IHBlcmlvZCBvZiB0aW1lIGFmdGVyIGEgNDg2DQoJPiB3b3VsZCBo ZWxwLCBidXQgSQ0KCT4gPndvdWxkbid0IHNheSB0aGF0IHRoaXMgaXMgYW4gaW1wbGVtZW50YXRp b24gbWF0dGVyLCB0aGUNCgk+IGJlaGF2aW9yIG9mIGEgU0lQDQoJPiA+Y2xpZW50IG5lZWRzIHRv IGJlIHByZWRpY3RhYmxlLCBpLmUuIHN0YW5kYXJkaXplZC4NCgk+DQoJPiBEaWFsb2cgc3RhdGUg ZG9lcyBuZWVkIHRvIGJlIGtlcHQgZm9yIDMyIHNlY29uZHMgYWZ0ZXIgc2VuZGluZyBhDQoJPiBu b24tc3VjY2VzcyBmaW5hbCByZXNwb25zZSBpbiBjYXNlIG9mIHRoZSBsb3NzIG9mIHRoZSA0ODYN Cgk+IHdoaWNoIHdvdWxkIGJlDQoJPiBkZXRlY3RlZCBieSB0aGUgZmFpbHVyZSB0byByZWNlaXZl IGFuIEFDSy4gIEhvd2V2ZXIsIHRoaXMgaGFzDQoJPiBubyBiZWFyaW5nIG9uDQoJPiB0aGlzIHNj ZW5hcmlvLg0KCQ0KCVNlZSBleHBsYW5hdGlvbiBhbmQgZmxvd3MgYWJvdmUuDQoJDQoJPg0KCT4g PkNvbWluZyBiYWNrIHRvIG15IGluaXRpYWwgY29uY2VybiwgdGhlIFBTVE4gY2FsbCBjb21wbGV0 aW9uDQoJPiBhcHBsaWNhdGlvbg0KCT4gPmdpdmVuIGFzIGFuIGV4YW1wbGUgaW4NCgk+IGRyYWZ0 LWlldGYtc2lwcGluZy1kaWFsb2ctcGFja2FnZS0wMi50eHQuIFNlbmRpbmcgYQ0KCT4gPlNVQlND UklCRSB0byB0aGUgRGlhbG9nIFBhY2thZ2Ugd2l0aGluIHRoZSBkaWFsb2cgaW5pdGlhdGVkDQoJ PiBieSB0aGUgSU5WSVRFDQoJPiA+b2YgdGhlIHByZWNlZGluZyBjYWxsIGF0dGVtcHQgd291bGQg ZWFzZSB0aGUgaW1wbGVtZW50YXRpb24NCgk+IGJlY2F1c2UgdGhlDQoJPiA+Y2FsbCBkYXRhIGFy ZSBhdmFpbGFibGUgd2l0aGluIHRoaXMgZGlhbG9nIGF0IHRoZSBTSVAgdXNlcg0KCT4gc2lkZSBh bmQgYXQgaXRzDQoJPiA+cGVlciAoZS5nLiB0aGUgZ2F0ZXdheSBpbiB0aGUgUFNUTikuIFRoaXMg aXMgaW4gbXkgdW5kZXJzdGFuZGluZyB0aGUNCgk+ID5iZW5lZml0IG9mIGRyYWZ0LWlldGYtc2lw cGluZy1kaWFsb2ctcGFja2FnZS0wMi50eHQuDQoJPg0KCT4gQXJlIHlvdSBzYXlpbmcgdGhhdCB5 b3Ugd291bGQgbGlrZSBBbGljZSB0byBiZSBhYmxlIHRvIHNlbmQgYQ0KCT4gU1VCU0NSSUJFIHRv DQoJPiBCb2Igd2l0aGluIHRoZSBkaWFsb2cgYmV0d2VlbiBCb2IgYW5kIENhcm9sPyAgVGhpcyBp cyBub3QNCgk+IHBvc3NpYmxlIC0gYQ0KCT4gZGlhbG9nIGlzIGJldHdlZW4gdHdvIHBlZXJzIC0g YSB0aGlyZCBwYXJ0eSBjYW4gbm90IGluamVjdCBtZXNzYWdlcy4NCgk+DQoJDQoJT2YgY291cnNl IG5vdCwgc2VlIGV4cGxhbmF0aW9uIGFuZCBmbG93cyBhYm92ZS4NCgkNCgk+DQoJPiA+QSBwb3Nz aWJsZSBzb2x1dGlvbiB3b3VsZCBiZSB0byBrZWVwIGZvciBhIHNob3J0IHBlcmlvZCBvZg0KCT4g dGltZSB0aGUgZGlhbG9nDQoJPiA+d2l0aCB0aGUgZGF0YSBvZiB0aGUgcHJldmlvdXMgY2FsbCBh dHRlbXB0IChpLmUuIHRoZSBjYWxsZWQNCgk+IHVzZXIgbnVtYmVyLA0KCT4gPnRoZSBiZWFyZXIg ZGVzY3JpcHRpb24sIC4uLikgYXQgdGhlIHVzZXIgYWdlbnQgYWZ0ZXIgYSA0ODYNCgk+IGlzIHJl Y2VpdmVkIGlmDQoJPiA+YW4gYXV0b21hdGljIGNhbGxiYWNrIGlzIHBvc3NpYmxlIChlLmcuIG5v dCBwcmVjbHVkZWQgYnkNCgk+IG90aGVyIHNlcnZpY2VzIGF0DQoJPiA+dGhlIHJlbW90ZSB1c2Vy IHNpZGUsIGxhY2tpbmcgbmV0d29yayByZXNvdXJjZXMsIGV0Yy4pLg0KCT4NCgk+IEFyZSB5b3Ug cGVyaGFwcyBjb25jZXJuZWQgYWJvdXQgYXV0aG9yaXppbmcgdGhlIHN1YnNjcmlwdGlvbj8NCgk+ ICBUaGF0IGlzLCBCb2INCgk+IG9ubHkgYWNjZXB0cyBhIFNVQlNDUklCRSBmcm9tIEFsaWNlIGlm IEFsaWNlIGhhcyBwcmV2aW91c2x5DQoJPiBqdXN0IG1hZGUgYQ0KCT4gY2FsbCBhdHRlbXB0IChz ZW50IGFuIElOVklURSBhbmQgcmVjZWl2ZWQgYSA0ODYgYnVzeSk/ICBJZg0KCT4gdGhpcyBpcyB3 aGF0IHlvdQ0KCT4gd2FudCwgSSdtIG5vdCBzdXJlIHRoZSBleGFjdCBiZW5lZml0IG9mIHRoaXMu DQoJDQoJTm90IGF0IGFsbCBteSBjb25jZXJuLg0KCQ0KCT4NCgk+ID5UaGVuIHRoZSBjYWxsZWQg dXNlciBudW1iZXIgYW5kIG90aGVyIGRhdGEgZnJvbSB0aGUNCgk+IHByZWNlZGluZyBjYWxsIGF0 dGVtcHQNCgk+ID5jb3VsZCBiZSByZS11c2VkIGZvciB0aGUgU1VCU0NSSUJFIHJlcXVlc3QgYW5k IGZvciB0aGUNCgk+IHN1YnNlcXVlbnQgY2FsbA0KCT4gPndoZW4gdGhlIHJlbW90ZSB1c2VyIGdl dHMgZnJlZS4gVGhpcyB3b3VsZCByZXF1aXJlIHRvIGV4dGVuZA0KCT4gdGhlIDQ4NiB3aXRoDQoJ PiA+YSAiQXV0b21hdGljIENhbGxiYWNrIFBvc3NpYmxlIiBpbmRpY2F0aW9uLCBvciB0byBpbnRy b2R1Y2UNCgk+IGEgbmV3IG1lc3NhZ2UNCgk+ID53aXRoIHRoaXMgbWVhbmluZyBhbmQgdGhlIHBy b2NlZHVyZSBvZiByZXRhaW5pbmcgZGF0YSAtIGENCgk+IGNoYW5nZSB0byBSRkMzMjYxLg0KCT4g Pg0KCT4gPkFueSB2aWV3IG9uIHRoYXQ/DQoJPiA+DQoJPiA+VGhhbmtzLA0KCT4gPkplYW4tTWFy aWUNCgk+ID4NCgk+ID4NCgk+ID4tLS0tLVVyc3BydW5nbGljaGUgTmFjaHJpY2h0LS0tLS0NCgk+ ID5Wb246IEFsYW4gSm9obnN0b24gW21haWx0bzphbGFuLmpvaG5zdG9uQG1jaS5jb21dDQoJPiA+ R2VzZW5kZXQ6IE1pdHR3b2NoLCAxNi4gSnVsaSAyMDAzIDIwOjM5DQoJPiA+QW46IFJvaGFuIE1h aHk7IFN0dXBrYSBKZWFuLU1hcmllDQoJPiA+Q2M6ICdKb25hdGhhbiBSb3NlbmJlcmcnOyAnc2lw cGluZ0BpZXRmLm9yZycNCgk+ID5CZXRyZWZmOiBSZTogQVc6IFtTaXBwaW5nXSBRdWVzdGlvbiBv biBJTlZJVEUgSW5pdGlhdGVkIERpYWxvZyBFdmVudA0KCT4gPlBhY2thZ2UgYSBuZCBBdXRvbWF0 aWMgQyBhbGxiYWNrDQoJPiA+DQoJPiA+DQoJPiA+SGkgSmVhbi1NYXJpZSwNCgk+ID4NCgk+ID5U aGUgU0lQIFNlcnZpY2UgRXhhbXBsZXMgc2VjdGlvbiAyLjE3IHNob3dzIGV4YWN0bHkgdGhpcyBm bG93IHdpdGggYQ0KCT4gPlNVQlNDUklCRSBvdXRzaWRlIG9mIHRoZSBkaWFsb2cgKHdoaWNoIGVu ZGVkIHdpdGggdGhlIDQ4NikuDQoJPiA+DQoJPiA+VGhhbmtzLA0KCT4gPkFsYW4gSm9obnN0b24N Cgk+ID5NQ0kNCgk+ID4NCgk+ID5BdCAwNToyMSBBTSA3LzE1LzIwMDMgLTA3MDAsIFJvaGFuIE1h aHkgd3JvdGU6DQoJPiA+ID5KZWFuLU1hcmllLA0KCT4gPiA+DQoJPiA+ID5JdCBzZWVtcyBwZXJm ZWN0bHkgcmVhc29uYWJsZSB0byBzZW5kIGEgU1VCU0NSSUJFIHRvIHRoZQ0KCT4gZGlhbG9nIHBh Y2thZ2UNCgk+ID4gPm91dHNpZGUgb2YgYSBkaWFsb2cuICBUaGUgZGVmYXVsdCBiZWhhdmlvciB3 b3VsZCBiZSB0bw0KCT4gc2VuZCBhIGxpc3Qgb2YNCgk+ID4gPmRpYWxvZ3MgYnV0IHdpdGggbm8g ZGlhbG9nIGluZm9ybWF0aW9uIG9yIHBlZXINCgk+IGluZm9ybWF0aW9uLiAgSSBiZWxpZXZlDQoJ PiA+ID50aGlzIGlzIHN1ZmZpY2llbnQgdG8gYnVpbGQgYSBjYWxsYmFjayBzZXJ2aWNlLg0KCT4g PiA+DQoJPiA+ID50aGFua3MsDQoJPiA+ID4tcm9oYW4NCgk+ID4gPg0KCT4gPiA+DQoJPiA+ID4N Cgk+ID4gPk9uIFR1ZXNkYXksIEp1bHkgMTUsIDIwMDMsIGF0IDAyOjUzIEFNLCBTdHVwa2EgSmVh bi1NYXJpZSB3cm90ZToNCgk+ID4gPg0KCT4gPiA+PkpvbmF0aGFuLA0KCT4gPiA+Pg0KCT4gPiA+ PkkgZG91YnQgdGhhdCBzZW5kaW5nIHRoZSBTVUJTQ1JJQkUgcmVxdWVzdCBmb3IgdGhlIGRpYWxv Zw0KCT4gcGFja2FnZSBvdXRzaWRlDQoJPiA+ID4+b2YgYW55IGRpYWxvZyBpcyBwb3NzaWJsZSBp biBjYXNlIG9mIGF1dG9tYXRpYyBjYWxsYmFjaywgc2luY2UgdGhlDQoJPiA+ID4+cmVxdWlyZWQg ZGF0YSBhcmUgbm8gbW9yZSBhdmFpbGFibGUuDQoJPiA+ID4+DQoJPiA+ID4+VGhlIHByb2JsZW0g aXMgdGhhdCB3aGVuIGEgNDg2IGlzIHJlY2VpdmVkLCB0aGUgZGlhbG9nDQoJPiBpbml0aWF0ZWQg YnkgdGhlDQoJPiA+ID4+SU5WSVRFIHRlcm1pbmF0ZXMgYW5kLCB0aGUgZGF0YSByZWxhdGVkIHRv IHRoYXQgZGlhbG9nDQoJPiAoaW5jbHVkaW5nIHRoZQ0KCT4gPiA+PmNhbGxlZCB1c2VyIG51bWJl cikgZGlzYXBwZWFyLiBUaGVyZWZvcmUgaXQgaXMgbm8gbW9yZQ0KCT4gcG9zc2libGUgdG8gc2Vu ZA0KCT4gPiA+PnRoZSBTVUJTQ1JJQkUgdG8gcmVxdWVzdCBhdXRvbWF0aWMgY2FsbGJhY2sgZm9y IHRoaXMgZGVzdGluYXRpb24uDQoJPiA+ID4+DQoJPiA+ID4+QSBwb3NzaWJsZSBzb2x1dGlvbiB3 b3VsZCBiZSB0byBrZWVwIGZvciBhIHNob3J0IHBlcmlvZA0KCT4gb2YgdGltZSB0aGUgZGF0YQ0K CT4gPiA+Pm9mIHRoZSBwcmV2aW91cyBjYWxsIGF0dGVtcHQgKGkuZS4gdGhlIGNhbGxlZCB1c2Vy DQoJPiBudW1iZXIsIHRoZSBiZWFyZXINCgk+ID4gPj5kZXNjcmlwdGlvbiwgLi4uKSBhdCB0aGUg dXNlciBhZ2VudCBhZnRlciBhIDQ4NiBpcw0KCT4gcmVjZWl2ZWQuIFRoaXMgd291bGQNCgk+ID4g Pj5hbGxvdyB0aGUgdXNlciBhZ2VudCB0byByZS11c2UgdGhlIGNhbGxlZCB1c2VyIG51bWJlciBh bmQNCgk+IG90aGVyIGRhdGEgZnJvbQ0KCT4gPiA+PnRoZSBwcmVjZWRpbmcgY2FsbCBhdHRlbXB0 IGZvciB0aGUgU1VCU0NSSUJFIHJlcXVlc3QgYW5kIGZvciB0aGUNCgk+ID4gPj5zdWJzZXF1ZW50 IGNhbGwgYWZ0ZXIgdGhlIHJlbW90ZSB1c2VyIGlzIGZyZWUuIEhvd2V2ZXIsDQoJPiB0aGUgcHJv Y2VkdXJlIG9mDQoJPiA+ID4+cmV0YWluaW5nIGRhdGEgaXMgbm90IGZvcmVzZWVuIGluIFJGQyAz MjYxLg0KCT4gPiA+Pg0KCT4gPiA+PkEgYmV0dGVyIChtb3JlIGVjb25vbWljYWwgYW5kIHVzZXIg ZnJpZW5kbHkpIHNvbHV0aW9uDQoJPiB3b3VsZCBiZSB0byBrZWVwIGF0DQoJPiA+ID4+dGhlIHVz ZXIgYWdlbnQgb25seSB3aGVuIGFuIGF1dG9tYXRpYyBjYWxsYmFjayBpcw0KCT4gcG9zc2libGUg KGUuZy4gbm90DQoJPiA+ID4+cHJlY2x1ZGVkIGJ5IG90aGVyIHNlcnZpY2VzIGF0IHRoZSByZW1v dGUgdXNlciBzaWRlLA0KCT4gbGFja2luZyBuZXR3b3JrDQoJPiA+ID4+cmVzb3VyY2VzLCBldGMu KS4gVGhpcyB3b3VsZCByZXF1aXJlIHRvIGV4dGVuZCB0aGUgNDg2DQoJPiB3aXRoIGEgIkF1dG9t YXRpYw0KCT4gPiA+PkNhbGxiYWNrIFBvc3NpYmxlIiBpbmRpY2F0aW9uLCBvciB0byBpbnRyb2R1 Y2UgYSBuZXcNCgk+IG1lc3NhZ2Ugd2l0aCB0aGlzDQoJPiA+IG1lYW5pbmcuDQoJPiA+ID4+DQoJ PiA+ID4+SmVhbi1NYXJpZQ0KCT4gPiA+Pg0KCT4gPiA+Pi0tLS0tVXJzcHJ1bmdsaWNoZSBOYWNo cmljaHQtLS0tLQ0KCT4gPiA+PlZvbjogSm9uYXRoYW4gUm9zZW5iZXJnIFttYWlsdG86amRyb3Nl bkBkeW5hbWljc29mdC5jb21dDQoJPiA+ID4+R2VzZW5kZXQ6IE1vbnRhZywgMTQuIEp1bGkgMjAw MyAxMDoxOA0KCT4gPiA+PkFuOiBTdHVwa2EgSmVhbi1NYXJpZQ0KCT4gPiA+PkNjOiAnc2lwcGlu Z0BpZXRmLm9yZycNCgk+ID4gPj5CZXRyZWZmOiBSZTogW1NpcHBpbmddIFF1ZXN0aW9uIG9uIElO VklURSBJbml0aWF0ZWQNCgk+IERpYWxvZyBFdmVudCBQYWNrYWdlDQoJPiA+ID4+YW5kIEF1dG9t YXRpYyBDIGFsbGJhY2sNCgk+ID4gPj4NCgk+ID4gPj4NCgk+ID4gPj5UaGUgZGlhbG9nIHBhY2th Z2UgY2FuIGJlIHVzZWQgYnkgc3Vic2NyaXB0aW9ucyBtYWRlIGJvdGgNCgk+IHdpdGhpbiwgYW5k DQoJPiA+ID4+b3V0c2lkZSwgb2YgYSBkaWFsb2cuIFNvLCBpbiB0aGUgY2FzZSBvZiBhdXRvbWF0 aWMgY2FsbGJhY2ssIHRoZQ0KCT4gPiA+PmNhbGxlciB3b3VsZCwgYWZ0ZXIgcmVjZWl2aW5nIGEg NDg2LCBzZW5kIGEgU1VCU0NSSUJFDQoJPiByZXF1ZXN0IGZvciB0aGUNCgk+ID4gPj5kaWFsb2cg cGFja2FnZSwgYW5kIGRvIHNvIG91dHNpZGUgb2YgYW55IGRpYWxvZy4NCgk+ID4gPj4NCgk+ID4g Pj4tSm9uYXRoYW4gUi4NCgk+ID4gPj4NCgk+ID4gPj5TdHVwa2EgSmVhbi1NYXJpZSB3cm90ZToN Cgk+ID4gPj4NCgk+ID4gPj4+SGVsbG8gQWxsLA0KCT4gPiA+Pj4NCgk+ID4gPj4+QXMgc2FpZCBp biBSRkMgMzI2NSBpdCBpcyBwb3NzaWJsZSB0byBjcmVhdGUgYW4gZXZlbnQNCgk+IHN1YnNjcmlw dGlvbg0KCT4gPiA+Pj53aXRoaW4gYSBwcmUtZXhpc3RpbmcgZGlhbG9nLCBlLmcuIGEgZGlhbG9n IGNyZWF0ZWQgYnkgYW4gSU5WSVRFLg0KCT4gPiA+Pj5JbiBteSB1bmRlcnN0YW5kaW5nLCB0aGlz IGlzIHRoZSBpbnRlbnRpb24gb2YNCgk+ID4gPj4+ZHJhZnQtaWV0Zi1zaXBwaW5nLWRpYWxvZy1w YWNrYWdlLTAyLnR4dC4NCgk+ID4gPj4+DQoJPiA+ID4+PkFjY29yZGluZyB0byB0aGUgKFBTVE4p IEF1dG9tYXRpYyBDYWxsYmFjayBnaXZlbiBhcyBleGFtcGxlDQoJPiA+ID4+PmFwcGxpY2F0aW9u IGluIHRoZSBpbnRyb2R1Y3Rpb24gb2YgdGhpcyBkcmFmdCwgdXNlciBBDQoJPiBjYW4gcmVxdWVz dCBhDQoJPiA+ID4+PmNhbGxiYWNrIHdoZW4gdXNlciBCIGhhbmdzLXVwLiBVc2VyIEEgb2ZmIGNv dXJzZSBuZWVkcyB0byBnZXQgdGhlDQoJPiA+ID4+PmluZm9ybWF0aW9uIHRoYXQgdXNlciBCIGlz IGJ1c3kgYmVmb3JlIHJlcXVlc3RpbmcgdGhlIGF1dG9tYXRpYw0KCT4gPiA+Pj5jYWxsYmFjaywg aS5lLiByZWNlaXZlIGEgIjQ4NiBCdXN5IEhlcmUiIG1lc3NhZ2UuIEhvd2V2ZXIsIGFsbA0KCT4g PiA+Pj5lYXJseSBkaWFsb2dzIGFyZSBjb25zaWRlcmVkIHRlcm1pbmF0ZWQgdXBvbiByZWNlcHRp b24NCgk+IG9mIGEgbm9uLTJ4eA0KCT4gPiA+Pj5maW5hbCByZXNwb25zZSAoMTMuMi4yLjMgb2Yg UkZDIDMyNjEpLiBBcyBjb25zZXF1ZW5jZSwgdGhlIGRpYWxvZw0KCT4gPiA+Pj5hbmQgdGh1cyB0 aGUgZGF0YSBvZiB0aGUgcHJlY2VkaW5nIGNhbGwgYXR0ZW1wdCBhcmUgbm8gbW9yZQ0KCT4gPiA+ Pj5hdmFpbGFibGUgYW5kIHRoZSBjYWxsYmFjayBjYW5ub3QgYmUgcmVxdWVzdGVkLg0KCT4gPiA+ Pj4NCgk+ID4gPj4+Q2FuIHNvbWVib2R5IHByb3ZpZGUgY2xhcmlmaWNhdGlvbiBvZiB0aGUgYXBw bGljYWJpbGl0eQ0KCT4gb2YgUkZDIDMyNjUNCgk+ID4gPj4+YW5kIHRoZSBkcmFmdC1pZXRmLXNp cHBpbmctZGlhbG9nLXBhY2thZ2UtMDIudHh0IHRvIEF1dG9tYXRpYw0KCT4gPiA+Pj5DYWxsYmFj az8NCgk+ID4gPj4+DQoJPiA+ID4+PlJlZ2FyZHMsDQoJPiA+ID4+Pg0KCT4gPiA+Pj5KZWFuLU1h cmllDQoJPiA+ID4+Pg0KCT4gPiA+Pj4NCgk+ID4gPj4+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18gU2lwcGluZyBtYWlsaW5nDQoJPiA+ID4+Pmxpc3QgIGh0 dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcHBpbmcgVGhpcyBsaXN0IGlz DQoJPiA+ID4+PmZvciBORVcgZGV2ZWxvcG1lbnQgb2YgdGhlIGFwcGxpY2F0aW9uIG9mIFNJUCBV c2UNCgk+ID4gPj4+c2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUgZm9yIHF1ZXN0aW9u cyBvbiBjdXJyZW50IHNpcCBVc2UNCgk+ID4gPj4+c2lwQGlldGYub3JnIGZvciBuZXcgZGV2ZWxv cG1lbnRzIG9mIGNvcmUgU0lQDQoJPiA+ID4+DQoJPiA+ID4+LS0NCgk+ID4gPj5Kb25hdGhhbiBE LiBSb3NlbmJlcmcsIFBoLkQuICAgICAgICAgICAgICAgIDYwMCBMYW5pZGV4IFBsYXphDQoJPiA+ ID4+Q2hpZWYgVGVjaG5vbG9neSBPZmZpY2VyICAgICAgICAgICAgICAgICAgICBQYXJzaXBwYW55 LA0KCT4gTkogMDcwNTQtMjcxMQ0KCT4gPiA+PmR5bmFtaWNzb2Z0DQoJPiA+ID4+amRyb3NlbkBk eW5hbWljc29mdC5jb20gICAgICAgICAgICAgICAgICAgICBGQVg6ICAgKDk3MykgOTUyLTUwNTAN Cgk+ID4gPj5odHRwOi8vd3d3Lmpkcm9zZW4ubmV0ICAgICAgICAgICAgICAgICAgICAgIFBIT05F OiAoOTczKSA5NTItNTAwMA0KCT4gPiA+Pmh0dHA6Ly93d3cuZHluYW1pY3NvZnQuY29tDQoJPiA+ ID4+DQoJPiA+ID4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCgk+ID4gPj5TaXBwaW5nIG1haWxpbmcgbGlzdCANCgk+IGh0dHBzOi8vd3d3MS5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NpcHBpbmcNCgk+ID4gPj5UaGlzIGxpc3QgaXMgZm9yIE5FVyBk ZXZlbG9wbWVudCBvZiB0aGUgYXBwbGljYXRpb24gb2YgU0lQDQoJPiA+ID4+VXNlIHNpcC1pbXBs ZW1lbnRvcnNAY3MuY29sdW1iaWEuZWR1IGZvciBxdWVzdGlvbnMgb24gY3VycmVudCBzaXANCgk+ ID4gPj5Vc2Ugc2lwQGlldGYub3JnIGZvciBuZXcgZGV2ZWxvcG1lbnRzIG9mIGNvcmUgU0lQDQoJ PiA+ID4NCgk+ID4gPg0KCT4gPiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCgk+ID4gPlNpcHBpbmcgbWFpbGluZyBsaXN0IA0KCT4gaHR0cHM6Ly93d3cx LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwcGluZw0KCT4gPiA+VGhpcyBsaXN0IGlzIGZv ciBORVcgZGV2ZWxvcG1lbnQgb2YgdGhlIGFwcGxpY2F0aW9uIG9mIFNJUA0KCT4gPiA+VXNlIHNp cC1pbXBsZW1lbnRvcnNAY3MuY29sdW1iaWEuZWR1IGZvciBxdWVzdGlvbnMgb24gY3VycmVudCBz aXANCgk+ID4gPlVzZSBzaXBAaWV0Zi5vcmcgZm9yIG5ldyBkZXZlbG9wbWVudHMgb2YgY29yZSBT SVANCgk+DQoJDQoJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCglTaXBwaW5nIG1haWxpbmcgbGlzdCAgaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2lwcGluZw0KCVRoaXMgbGlzdCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRo ZSBhcHBsaWNhdGlvbiBvZiBTSVANCglVc2Ugc2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5l ZHUgZm9yIHF1ZXN0aW9ucyBvbiBjdXJyZW50IHNpcA0KCVVzZSBzaXBAaWV0Zi5vcmcgZm9yIG5l dyBkZXZlbG9wbWVudHMgb2YgY29yZSBTSVANCgkNCgkNCg0K _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 20 10:52: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 KAA20795 for ; Sun, 20 Jul 2003 10:52: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 19eFY3-0001Tt-GD for sipping-archive@odin.ietf.org; Sun, 20 Jul 2003 10:52:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6KEqRHt005694 for sipping-archive@odin.ietf.org; Sun, 20 Jul 2003 10:52:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eFY3-0001Tl-As for sipping-web-archive@optimus.ietf.org; Sun, 20 Jul 2003 10:52: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 KAA20785 for ; Sun, 20 Jul 2003 10:52:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eFY0-0002l1-00 for sipping-web-archive@ietf.org; Sun, 20 Jul 2003 10:52:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19eFXu-0002kt-00 for sipping-web-archive@ietf.org; Sun, 20 Jul 2003 10:52:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eFXe-0001RZ-4L; Sun, 20 Jul 2003 10: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 19eFXL-0001RB-I4 for sipping@optimus.ietf.org; Sun, 20 Jul 2003 10:51: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 KAA20763 for ; Sun, 20 Jul 2003 10:51:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eFXJ-0002kL-00 for sipping@ietf.org; Sun, 20 Jul 2003 10:51:41 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19eFX8-0002ju-00 for sipping@ietf.org; Sun, 20 Jul 2003 10:51:30 -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 h6KEoVpp005559; Sun, 20 Jul 2003 07:50:31 -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 AJJ67739; Sun, 20 Jul 2003 07:46:55 -0700 (PDT) Date: Sat, 19 Jul 2003 19:57:55 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Mary Barnes , rohan@cisco.com To: sipping@ietf.org ('sipping@ietf.org') From: Rohan Mahy Content-Transfer-Encoding: 7bit Message-Id: <867877E9-BA12-11D7-B1E0-0003938AF740@cisco.com> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Sipping] sec-inserted Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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, Regarding the sec-inserted draft, I'm not especially fond of the token name "aiihb". I like the idea of creating a new Content-Disposition type for protecting intermediary SIP content, but I would like to use a different name and make the mechanism a bit more generic. Specifically, I don't see any reason to restrict the intermediary content to identities. Maybe this is just a "proxy asserted sipfrag" or "pas". A proxy could then assert that it was responsible for a particular sipfrag, or that it can authenticate parts of the sipfrag? the real question is what are the semantics on the body. Does a proxy put in only stuff it added? obviously not, because it needs to include headers that tie the body to the message for replay prevention. What existing stuff does it include? For headers with multiple header field values can it just include one? (probably a good idea if we ever do this for Via.) these are the questions I want to explore. 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 Sun Jul 20 10:52: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 KAA20798 for ; Sun, 20 Jul 2003 10:52: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 19eFY3-0001UG-KG for sipping-archive@odin.ietf.org; Sun, 20 Jul 2003 10:52:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6KEqRYM005710 for sipping-archive@odin.ietf.org; Sun, 20 Jul 2003 10:52:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eFY3-0001Tw-Gb for sipping-web-archive@optimus.ietf.org; Sun, 20 Jul 2003 10:52: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 KAA20788 for ; Sun, 20 Jul 2003 10:52:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eFY0-0002ky-00 for sipping-web-archive@ietf.org; Sun, 20 Jul 2003 10:52:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19eFXu-0002ks-00 for sipping-web-archive@ietf.org; Sun, 20 Jul 2003 10:52:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eFXe-0001Rj-Su; Sun, 20 Jul 2003 10: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 19eFXV-0001RL-Ri for sipping@optimus.ietf.org; Sun, 20 Jul 2003 10:51: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 KAA20767 for ; Sun, 20 Jul 2003 10:51:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eFXT-0002kQ-00 for sipping@ietf.org; Sun, 20 Jul 2003 10:51:51 -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 19eFXI-0002jx-00 for sipping@ietf.org; Sun, 20 Jul 2003 10:51:40 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 20 Jul 2003 07:51:05 -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 h6KEoguJ021871; Sun, 20 Jul 2003 07:50:42 -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 AJJ67763; Sun, 20 Jul 2003 07:47:07 -0700 (PDT) Date: Sun, 20 Jul 2003 04:53:19 +0200 Subject: Re: AW: AW: [Sipping] Question on INVITE Initiated Dialog Event Packa ge a nd Automatic C allback Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'Alan Johnston'" , "'Jonathan Rosenberg'" , "'sipping@ietf.org'" To: Stupka Jean-Marie From: Rohan Mahy In-Reply-To: <931A17FBB884D411B02B0008C70D9E2ABF1320@mchh243e.mchh.siemens.de> Message-Id: <51C56008-BA5D-11D7-B1E0-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 Thursday, July 17, 2003, at 10:21 AM, Stupka Jean-Marie wrote: > Hi Alan, > > The flow 2.17 of draft-ietf-sipping-service-examples-04.txt is a good > example to show what is wrong. After the 486 message and the ACK the > transaction is terminated: 13.2.2.3 of RFC3261 says "All early dialogs > are considered terminated upon reception of the non-2xx final > response". As a consequence, all data related to the previous call > attempt are lost (why and how long should a SIP client keep this > data?). This is at least conforming RFC3261. > Therefore, the SUBSCRIBE message shown in the flow is just not > possible, as the destination address (Bob's address or user number) is > no more existing at the SIP user side. There is something incredibly basic and fundamental here which you are not grasping. If you want to implement a service on your User Agent (whether it is a PSTN gateway, a media server, a phone, or an instant messaging client), you are responsible for storing the information you need in order to accomplish that service. There is no expectation that all the state you need in order to accomplish some arbitrary service is encapsulated in some data structure that is defined in the SIP specification. The flow shown is not only possible, it has been implemented and it works. > Keeping the data for a short period of time after a 486 would help, > but I wouldn't say that this is an implementation matter, the behavior > of a SIP client needs to be predictable, i.e. standardized. The behavior of SIP User Agents is predictable insofar as what is exchanged on the wire. The IETF does not mandate services or implementations operate in a particular way. > Coming back to my initial concern, the PSTN call completion > application given as an example in > draft-ietf-sipping-dialog-package-02.txt. Sending a SUBSCRIBE to the > Dialog Package within the dialog initiated by the INVITE of the > preceding call attempt would ease the implementation because the call > data are available within this dialog at the SIP user side and at its > peer (e.g. the gateway in the PSTN). This is in my understanding the > benefit of draft-ietf-sipping-dialog-package-02.txt. the problem is that a full dialog does not even exist. > A possible solution would be to keep for a short period of time the > dialog with the data of the previous call attempt (i.e. the called > user number, the bearer description, ...) at the user agent after a > 486 is received if an automatic callback is possible (e.g. not > precluded by other services at the remote user side, lacking network > resources, etc.). > Then the called user number and other data from the preceding call > attempt could be re-used for the SUBSCRIBE request and for the > subsequent call when the remote user gets free. This would require to > extend the 486 with a "Automatic Callback Possible" indication, or to > introduce a new message with this meaning and the procedure of > retaining data - a change to RFC3261. Just keep the data yourself in your User Agent. There is no need to modify any specifications, in fact doing so would be harmful. I'll also point out that "486 Automatic Callback Possible" is a bit silly. You can already tell if automatic callback is possible if the 486 contains an Allow-Events header with the dialog package token. thanks, -rohan > Any view on that? > > Thanks, > Jean-Marie > > > -----Ursprungliche Nachricht----- > Von: Alan Johnston [mailto:alan.johnston@mci.com] > Gesendet: Mittwoch, 16. Juli 2003 20:39 > An: Rohan Mahy; Stupka Jean-Marie > Cc: 'Jonathan Rosenberg'; 'sipping@ietf.org' > Betreff: Re: AW: [Sipping] Question on INVITE Initiated Dialog Event > Package a nd Automatic C allback > > > Hi Jean-Marie, > > The SIP Service Examples section 2.17 shows exactly this flow with a > SUBSCRIBE outside of the dialog (which ended with the 486). > > Thanks, > Alan Johnston > MCI > > At 05:21 AM 7/15/2003 -0700, Rohan Mahy wrote: >> Jean-Marie, >> >> It seems perfectly reasonable to send a SUBSCRIBE to the dialog >> package >> outside of a dialog. The default behavior would be to send a list of >> dialogs but with no dialog information or peer information. I believe >> this is sufficient to build a callback service. >> >> thanks, >> -rohan >> >> >> >> On Tuesday, July 15, 2003, at 02:53 AM, Stupka Jean-Marie wrote: >> >>> Jonathan, >>> >>> I doubt that sending the SUBSCRIBE request for the dialog package >>> outside >>> of any dialog is possible in case of automatic callback, since the >>> required data are no more available. >>> >>> The problem is that when a 486 is received, the dialog initiated by >>> the >>> INVITE terminates and, the data related to that dialog (including the >>> called user number) disappear. Therefore it is no more possible to >>> send >>> the SUBSCRIBE to request automatic callback for this destination. >>> >>> A possible solution would be to keep for a short period of time the >>> data >>> of the previous call attempt (i.e. the called user number, the bearer >>> description, ...) at the user agent after a 486 is received. This >>> would >>> allow the user agent to re-use the called user number and other data >>> from >>> the preceding call attempt for the SUBSCRIBE request and for the >>> subsequent call after the remote user is free. However, the >>> procedure of >>> retaining data is not foreseen in RFC 3261. >>> >>> A better (more economical and user friendly) solution would be to >>> keep at >>> the user agent only when an automatic callback is possible (e.g. not >>> precluded by other services at the remote user side, lacking network >>> resources, etc.). This would require to extend the 486 with a >>> "Automatic >>> Callback Possible" indication, or to introduce a new message with >>> this meaning. >>> >>> Jean-Marie >>> >>> -----Ursprungliche Nachricht----- >>> Von: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>> Gesendet: Montag, 14. Juli 2003 10:18 >>> An: Stupka Jean-Marie >>> Cc: 'sipping@ietf.org' >>> Betreff: Re: [Sipping] Question on INVITE Initiated Dialog Event >>> Package >>> and Automatic C allback >>> >>> >>> The dialog package can be used by subscriptions made both within, and >>> outside, of a dialog. So, in the case of automatic callback, the >>> caller would, after receiving a 486, send a SUBSCRIBE request for the >>> dialog package, and do so outside of any dialog. >>> >>> -Jonathan R. >>> >>> Stupka Jean-Marie wrote: >>> >>>> Hello All, >>>> >>>> As said in RFC 3265 it is possible to create an event subscription >>>> within a pre-existing dialog, e.g. a dialog created by an INVITE. >>>> In my understanding, this is the intention of >>>> draft-ietf-sipping-dialog-package-02.txt. >>>> >>>> According to the (PSTN) Automatic Callback given as example >>>> application in the introduction of this draft, user A can request a >>>> callback when user B hangs-up. User A off course needs to get the >>>> information that user B is busy before requesting the automatic >>>> callback, i.e. receive a "486 Busy Here" message. However, all >>>> early dialogs are considered terminated upon reception of a non-2xx >>>> final response (13.2.2.3 of RFC 3261). As consequence, the dialog >>>> and thus the data of the preceding call attempt are no more >>>> available and the callback cannot be requested. >>>> >>>> Can somebody provide clarification of the applicability of RFC 3265 >>>> and the draft-ietf-sipping-dialog-package-02.txt to Automatic >>>> Callback? >>>> >>>> Regards, >>>> >>>> Jean-Marie >>>> >>>> >>>> _______________________________________________ Sipping mailing >>>> list https://www1.ietf.org/mailman/listinfo/sipping This list is >>>> for NEW development of the 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 Sun Jul 20 10:53: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 KAA20843 for ; Sun, 20 Jul 2003 10:53: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 19eFYh-0001c1-U0 for sipping-archive@odin.ietf.org; Sun, 20 Jul 2003 10:53:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6KEr7C9006191 for sipping-archive@odin.ietf.org; Sun, 20 Jul 2003 10:53:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eFYh-0001bm-QR for sipping-web-archive@optimus.ietf.org; Sun, 20 Jul 2003 10:53: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 KAA20834 for ; Sun, 20 Jul 2003 10:53:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eFYf-0002lO-00 for sipping-web-archive@ietf.org; Sun, 20 Jul 2003 10:53:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19eFYZ-0002lL-00 for sipping-web-archive@ietf.org; Sun, 20 Jul 2003 10:52:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eFYa-0001Yb-Uc; Sun, 20 Jul 2003 10:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eFXl-0001SJ-26 for sipping@optimus.ietf.org; Sun, 20 Jul 2003 10:52: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 KAA20771 for ; Sun, 20 Jul 2003 10:52:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eFXi-0002kZ-00 for sipping@ietf.org; Sun, 20 Jul 2003 10:52:06 -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 19eFXX-0002k5-00 for sipping@ietf.org; Sun, 20 Jul 2003 10:51:55 -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 h6KEoquJ021957; Sun, 20 Jul 2003 07:50:53 -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 AJJ67772; Sun, 20 Jul 2003 07:47:15 -0700 (PDT) Date: Sun, 20 Jul 2003 05:17:58 +0200 Subject: Re: AW: AW: AW: [Sipping] Question on INVITE Initiated Dialog Event P ackage and Automatic Callback Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'Alan Johnston'" , "'Jonathan Rosenberg'" , "'sipping@ietf.org'" To: Stupka Jean-Marie From: Rohan Mahy In-Reply-To: <931A17FBB884D411B02B0008C70D9E2ABF1324@mchh243e.mchh.siemens.de> 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, July 18, 2003, at 11:25 AM, Stupka Jean-Marie wrote: > Hi Alan, all, > > Thanks for your answer. Having seen your comments, I think that my > previous mail was somewhat unclear. Let me clarify my concerns with > the flows below. > > > A GW / B > | | > | INVITE F1 | > |--------------->| > |486 Busy Here F2| > |<---------------| User B is busy > | ACK F3 | > |--------------->| > | | > | | > > User A calls user B which is either a SIP client (B) or a PSTN > subscriber behind a Gateway (GW). User B is initially busy when User A > calls. > > The dialog initiated by the INVITE terminates upon reception of the > 486. After having received the 486, a standard SIP client -- i.e. a > client compliant to RFC3261 -- considers the INVITE transaction > completed and generates the ACK for the response (this behavior is > described in 13.2.2.3 of RFC3261). > > 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? no. the data about the *dialog* is deleted. You are free to keep whatever data around you would like. > 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. it doesn't *have* to keep any data. it *wants* to keep the data, because it wants to invoke another SIP primitive. thanks, -rohan > For the reason above, a procedure is needed to keep the > dialog/transaction open after a 486. Of course it would only make > sense to keep the dialog if an automatic callback is possible, e.g. > not precluded by other services at the remote user side, lacking > network resources, etc. This should be indicated to the A's SIP UA. If > automatic callback is possible, then the dialog (the transaction > having the call data) shall not be terminated upon reception of a 486, > leaving user A the possibility to request automatic callback. > If user A does not request automatic callback within a reasonable time > interval (about 10-15s) the dialog terminates. > If user A does request automatic callback then a SUBSCRIBE (F4) is > sent on the already existing dialog that was initiated by the > preceding INVITE (F1). Sending the SUBSCRIBE within the dialog > initiated by the INVITE of the preceding call attempt would ease the > implementation because the call data are available within this dialog > at the SIP user side and at its peer (e.g. the gateway in the PSTN). > The call data can then be re-used for the SUBSCRIBE request and for > the subsequent call when user B gets free. > > The flow then looks like this: > > > A GW / B > | | > | INVITE F1 | > |--------------->| > |486 Busy Here F2| > |<---------------| User B is busy > T |(Autom.Callback | T Timer for automatic callback > | | possible) | | > | | ACK F3 | | > | |--------------->| | > | | | | > ==> | | | | User A requests automatic callback > | | | | > | | SUBSCRIBE F4 | | > v |--------------->| v > | 200 OK F5 | > |<---------------| > | NOTIFY F6 | > |<---------------| > | 200 OK F7 | > |--------------->| > | | > | NOTIFY F8 | <== User B is now available > |<---------------| > | 200 OK F9 | > |--------------->| > | | > | INVITE F10 | > |--------------->| Session setup successfully > | 180 Ringing F11| > |<---------------| > | 200 OK F12 | > |<---------------| > | ACK F13 | > |--------------->| > | Media Session | > |<==============>| > | | > > User A calls user B which is either a SIP client (B) or a PSTN > subscriber behind a Gateway (GW). User B is initially busy when user A > calls. > > - F1 INVITE creates a new dialog between A and GW/B (let's say D1) > > - F2 486 Busy Here: automatic callback is possible. > GW/B indicates to A that automatic callback is possible and starts a > timer in order to retain the dialog and call data for a possible > request for automatic callback. > When receiving a 486 with the indication automatic callback possible, > A starts a timer in order to retain the dialog and call data giving > user A the possibility to request automatic callback. > If the timer expires (no callback request has arrived) then the > dialog/transaction is terminated at A and GW/B. > > - User A requests automatic callback: A stops the timer and sends a > SUBSCRIBE request to GW/B (F4) within the dialog (D1) initiated by the > preceding INVITE. There is one hand no necessity to open a new dialog, > and one the other hand, sending the SUBSCRIBE within the dialog > initiated by the INVITE of the preceding call attempt would ease the > implementation because the call data are available within this dialog > at the SIP user side and at its peer (e.g. the gateway in the PSTN) > > - F4 SUBSCRIBE: GW/B stops the timer and starts monitoring B states. > F5, F6, F7, F8, F9 as in 2.17 of > draft-ietf-sipping-service-examples-04.txt > > - F10 INVITE: A sends the INVITE within the still open dialog (D1) > initiated by F1 (reason given above) > > - F11, etc. as in 2.17 > > Summary: > - There is a need to retain dialogs initiated by an INVITE after a 486 > message when automatic callback is possible > - It is desirable that the SUBSCRIBE request and a subsequent call > set-up triggered by the NOTIFY uses the pre-existing dialog initiated > by the preceding INVITE. > > I hope I have clarified my concerns. > > Regards, > Jean-Marie > > > >> -----Ursprungliche Nachricht----- >> Von: Alan Johnston [mailto:alan.johnston@mci.com] >> Gesendet: Donnerstag, 17. Juli 2003 11:04 >> An: Stupka Jean-Marie; Rohan Mahy >> Cc: 'Jonathan Rosenberg'; 'sipping@ietf.org' >> Betreff: Re: AW: AW: [Sipping] Question on INVITE Initiated >> Dialog Event >> Package and Automatic Callback >> >> >> Hi Jean-Marie, >> >> Comments below. >> >> Thanks, >> Alan Johnston >> MCI >> >> At 10:21 AM 7/17/2003 +0200, Stupka Jean-Marie wrote: >>> Hi Alan, >>> >>> The flow 2.17 of draft-ietf-sipping-service-examples-04.txt >> is a good >>> example to show what is wrong. After the 486 message and the ACK the >>> transaction is terminated: 13.2.2.3 of RFC3261 says "All >> early dialogs are >>> considered terminated upon reception of the non-2xx final response". >> >> In this flow, the dialog between Alice and Bob does terminate >> with the >> INVITE/486/ACK exchange. However, Bob has a dialog with >> another user, say >> Carol (perhaps the flow should show this for clarity?). If >> Bob was not >> currently involved in a dialog, the 486 would not have been >> sent, right? > > Right. > >> >>> As a consequence, all data related to the previous call >> attempt are lost >>> (why and how long should a SIP client keep this data?). >> This is at least >>> conforming RFC3261. >> >> Bob is in a dialog with Carol and keeps this dialog state for >> as long as >> the session exists (as long as Bob is busy). > > Right. > >> >>> Therefore, the SUBSCRIBE message shown in the flow is just >> not possible, >>> as the destination address (Bob's address or user number) is no more >>> existing at the SIP user side. >> >> I don't know what you mean here. Bob still exists - he is still >> sip:bob@biloxi.example.com, right? As a result, Bob can receive a >> SUBSCRIBE request from Alice. Alice does not specify any >> call-id, to-tag, >> or from-tag Event parameters, so that means that Alice is requesting >> information about ANY dialogs that Bob is currently active >> in. (Alice is >> not requesting information about only dialogs with Alice - >> this information >> would be redundant since if Alice is in the dialog, Alice >> would already >> know the state and dialog identifiers.) All the NOTIFYs that Alice >> receives provides information about the dialog between Bob and Carol. >> > > See explanation and flows above. > >>> Keeping the data for a short period of time after a 486 >> would help, but I >>> wouldn't say that this is an implementation matter, the >> behavior of a SIP >>> client needs to be predictable, i.e. standardized. >> >> Dialog state does need to be kept for 32 seconds after sending a >> non-success final response in case of the loss of the 486 >> which would be >> detected by the failure to receive an ACK. However, this has >> no bearing on >> this scenario. > > See explanation and flows above. > >> >>> Coming back to my initial concern, the PSTN call completion >> application >>> given as an example in >> draft-ietf-sipping-dialog-package-02.txt. Sending a >>> SUBSCRIBE to the Dialog Package within the dialog initiated >> by the INVITE >>> of the preceding call attempt would ease the implementation >> because the >>> call data are available within this dialog at the SIP user >> side and at its >>> peer (e.g. the gateway in the PSTN). This is in my understanding the >>> benefit of draft-ietf-sipping-dialog-package-02.txt. >> >> Are you saying that you would like Alice to be able to send a >> SUBSCRIBE to >> Bob within the dialog between Bob and Carol? This is not >> possible - a >> dialog is between two peers - a third party can not inject messages. >> > > Of course not, see explanation and flows above. > >> >>> A possible solution would be to keep for a short period of >> time the dialog >>> with the data of the previous call attempt (i.e. the called >> user number, >>> the bearer description, ...) at the user agent after a 486 >> is received if >>> an automatic callback is possible (e.g. not precluded by >> other services at >>> the remote user side, lacking network resources, etc.). >> >> Are you perhaps concerned about authorizing the subscription? >> That is, Bob >> only accepts a SUBSCRIBE from Alice if Alice has previously >> just made a >> call attempt (sent an INVITE and received a 486 busy)? If >> this is what you >> want, I'm not sure the exact benefit of this. > > Not at all my concern. > >> >>> Then the called user number and other data from the >> preceding call attempt >>> could be re-used for the SUBSCRIBE request and for the >> subsequent call >>> when the remote user gets free. This would require to extend >> the 486 with >>> a "Automatic Callback Possible" indication, or to introduce >> a new message >>> with this meaning and the procedure of retaining data - a >> change to RFC3261. >>> >>> Any view on that? >>> >>> Thanks, >>> Jean-Marie >>> >>> >>> -----Ursprungliche Nachricht----- >>> Von: Alan Johnston [mailto:alan.johnston@mci.com] >>> Gesendet: Mittwoch, 16. Juli 2003 20:39 >>> An: Rohan Mahy; Stupka Jean-Marie >>> Cc: 'Jonathan Rosenberg'; 'sipping@ietf.org' >>> Betreff: Re: AW: [Sipping] Question on INVITE Initiated Dialog Event >>> Package a nd Automatic C allback >>> >>> >>> Hi Jean-Marie, >>> >>> The SIP Service Examples section 2.17 shows exactly this flow with a >>> SUBSCRIBE outside of the dialog (which ended with the 486). >>> >>> Thanks, >>> Alan Johnston >>> MCI >>> >>> At 05:21 AM 7/15/2003 -0700, Rohan Mahy wrote: >>>> Jean-Marie, >>>> >>>> It seems perfectly reasonable to send a SUBSCRIBE to the >> dialog package >>>> outside of a dialog. The default behavior would be to >> send a list of >>>> dialogs but with no dialog information or peer >> information. I believe >>>> this is sufficient to build a callback service. >>>> >>>> thanks, >>>> -rohan >>>> >>>> >>>> >>>> On Tuesday, July 15, 2003, at 02:53 AM, Stupka Jean-Marie wrote: >>>> >>>>> Jonathan, >>>>> >>>>> I doubt that sending the SUBSCRIBE request for the dialog >> package outside >>>>> of any dialog is possible in case of automatic callback, since the >>>>> required data are no more available. >>>>> >>>>> The problem is that when a 486 is received, the dialog >> initiated by the >>>>> INVITE terminates and, the data related to that dialog >> (including the >>>>> called user number) disappear. Therefore it is no more >> possible to send >>>>> the SUBSCRIBE to request automatic callback for this destination. >>>>> >>>>> A possible solution would be to keep for a short period >> of time the data >>>>> of the previous call attempt (i.e. the called user >> number, the bearer >>>>> description, ...) at the user agent after a 486 is >> received. This would >>>>> allow the user agent to re-use the called user number and >> other data from >>>>> the preceding call attempt for the SUBSCRIBE request and for the >>>>> subsequent call after the remote user is free. However, >> the procedure of >>>>> retaining data is not foreseen in RFC 3261. >>>>> >>>>> A better (more economical and user friendly) solution >> would be to keep at >>>>> the user agent only when an automatic callback is >> possible (e.g. not >>>>> precluded by other services at the remote user side, >> lacking network >>>>> resources, etc.). This would require to extend the 486 >> with a "Automatic >>>>> Callback Possible" indication, or to introduce a new >> message with this >>> meaning. >>>>> >>>>> Jean-Marie >>>>> >>>>> -----Ursprungliche Nachricht----- >>>>> Von: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>>>> Gesendet: Montag, 14. Juli 2003 10:18 >>>>> An: Stupka Jean-Marie >>>>> Cc: 'sipping@ietf.org' >>>>> Betreff: Re: [Sipping] Question on INVITE Initiated >> Dialog Event Package >>>>> and Automatic C allback >>>>> >>>>> >>>>> The dialog package can be used by subscriptions made both >> within, and >>>>> outside, of a dialog. So, in the case of automatic callback, the >>>>> caller would, after receiving a 486, send a SUBSCRIBE >> request for the >>>>> dialog package, and do so outside of any dialog. >>>>> >>>>> -Jonathan R. >>>>> >>>>> Stupka Jean-Marie wrote: >>>>> >>>>>> Hello All, >>>>>> >>>>>> As said in RFC 3265 it is possible to create an event >> subscription >>>>>> within a pre-existing dialog, e.g. a dialog created by an INVITE. >>>>>> In my understanding, this is the intention of >>>>>> draft-ietf-sipping-dialog-package-02.txt. >>>>>> >>>>>> According to the (PSTN) Automatic Callback given as example >>>>>> application in the introduction of this draft, user A >> can request a >>>>>> callback when user B hangs-up. User A off course needs to get the >>>>>> information that user B is busy before requesting the automatic >>>>>> callback, i.e. receive a "486 Busy Here" message. However, all >>>>>> early dialogs are considered terminated upon reception >> of a non-2xx >>>>>> final response (13.2.2.3 of RFC 3261). As consequence, the dialog >>>>>> and thus the data of the preceding call attempt are no more >>>>>> available and the callback cannot be requested. >>>>>> >>>>>> Can somebody provide clarification of the applicability >> of RFC 3265 >>>>>> and the draft-ietf-sipping-dialog-package-02.txt to Automatic >>>>>> Callback? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Jean-Marie >>>>>> >>>>>> >>>>>> _______________________________________________ Sipping mailing >>>>>> list https://www1.ietf.org/mailman/listinfo/sipping This list is >>>>>> for NEW development of the 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 Sun Jul 20 15:41: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 PAA26506 for ; Sun, 20 Jul 2003 15:41: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 19eK3W-0000Fr-5O for sipping-archive@odin.ietf.org; Sun, 20 Jul 2003 15:41:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6KJfEiJ000966 for sipping-archive@odin.ietf.org; Sun, 20 Jul 2003 15:41:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eK3W-0000FT-05 for sipping-web-archive@optimus.ietf.org; Sun, 20 Jul 2003 15:41: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 PAA26501 for ; Sun, 20 Jul 2003 15:41:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eK3U-0004hj-00 for sipping-web-archive@ietf.org; Sun, 20 Jul 2003 15:41:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19eK3O-0004hg-00 for sipping-web-archive@ietf.org; Sun, 20 Jul 2003 15:41:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eK3J-0000EC-FD; Sun, 20 Jul 2003 15: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 19eK3I-0000Dq-Bd for sipping@optimus.ietf.org; Sun, 20 Jul 2003 15:41: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 PAA26487 for ; Sun, 20 Jul 2003 15:40:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eK3G-0004hQ-00 for sipping@ietf.org; Sun, 20 Jul 2003 15:40:59 -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 19eK36-0004h8-00 for sipping@ietf.org; Sun, 20 Jul 2003 15:40:48 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 20 Jul 2003 12:40:35 -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 h6KJeCuD008231 for ; Sun, 20 Jul 2003 12:40: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 AJJ76265; Sun, 20 Jul 2003 12:36:35 -0700 (PDT) Date: Sun, 20 Jul 2003 21:42:15 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Rohan Mahy To: "'sipping@ietf.org'" Content-Transfer-Encoding: 7bit Message-Id: <43F14AB8-BAEA-11D7-B1E0-0003938AF740@cisco.com> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Sipping] new lis for sipdev issues Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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, Various discussions regarding the sipdev document are consuming a huge chunk of the current sipping list traffic. For this reason, I have created a mailing list to discuss sipdev issues. Please do not post any more questions or comments about this individual document to the sipping list. Please use the new list instead. To subscribe, send email to mailer@cisco.com with no subject. the body of your email should be: subscribe sipdev To unsubscribe send to the same address: unsubscribe sipdev To send mail to the list send to sipdevATexternal.cisco.com (replace AT with an at-sign) 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 Mon Jul 21 04:51: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 EAA21168 for ; Mon, 21 Jul 2003 04: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 19eWO2-0004T6-LM for sipping-archive@odin.ietf.org; Mon, 21 Jul 2003 04:51:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6L8pEwX017172 for sipping-archive@odin.ietf.org; Mon, 21 Jul 2003 04:51:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eWO2-0004St-HQ for sipping-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 04:51: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 EAA21156 for ; Mon, 21 Jul 2003 04:51:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eWNz-000116-00 for sipping-web-archive@ietf.org; Mon, 21 Jul 2003 04:51:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19eWNt-000113-00 for sipping-web-archive@ietf.org; Mon, 21 Jul 2003 04:51:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eWNp-0004Rx-O9; Mon, 21 Jul 2003 04:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eWNI-0004Rc-7n for sipping@optimus.ietf.org; Mon, 21 Jul 2003 04:50: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 EAA21153 for ; Mon, 21 Jul 2003 04:50:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eWNF-00010n-00 for sipping@ietf.org; Mon, 21 Jul 2003 04:50:25 -0400 Received: from ns.ivd.nl ([193.67.37.226]) by ietf-mx with esmtp (Exim 4.12) id 19eWN4-00010b-00 for sipping@ietf.org; Mon, 21 Jul 2003 04:50:14 -0400 Received: (from root@localhost) by ns.ivd.nl (8.9.3c/8.6.12) id KAA87494 for ; Mon, 21 Jul 2003 10:51:11 +0200 (CEST) Received: by ns.ivd.nl (TUNIX txp2/smap) for id sma087189; Mon, 21 Jul 03 10:50:16 +0200 Received: from IVD-Message_Server by mailserver.viataal.nl with Novell_GroupWise; Mon, 21 Jul 2003 10:51:18 +0200 Message-Id: X-Mailer: Novell GroupWise 5.5.5 Date: Mon, 21 Jul 2003 10:50:55 +0200 From: "A vWijk" To: Cc: , , , , , , Subject: Re: [Sipping] Update to caller preferences use cases Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 Mike, yes the REFER idea is also what I talked about with the other authors of = the invocation draft. In this way, the simple SIP telephone only needs to REFER the call and the = much and much more advanced Relay SIP UA /conference bridge can set up the = relay service. A REFER to a URI: speech2text@localrelay.com would indicate that all voice = has to be changed into text. It is a good thing to see that other people are thinking about this kind = of problem. greetz Arnoud <<< Michael Hammer 7/17 7:25p >>> At 01:49 PM 7/16/2003 +0200, A vWijk wrote: >And that it does not require the hearing impaired user to be registered=20= >with a relay operator At the risk of assuming too much, does this mean that the hearing-impaired= =20 user does not have a "home" relay operator, but will need to be able to=20 send an INVITE, much like an "sos" service code (perhaps "tdd" or = "relay"),=20 along with caller preferences or pre-conditions indicating the need for = a=20 particular type of relay service (e.g. "voice-to-2973" with=20 directionality), and get forwarded to an appropriate server? Furthermore,= =20 would that user be able to send a REFER to that server indicating the = need=20 to INVITE the called party? This feels like a 2-way conference of = sorts,=20 with the focus not only mixing media, but also translating media. Or perhaps there is another way to invoke this ad-hoc. Mike =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 Mon Jul 21 04:54: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 EAA21223 for ; Mon, 21 Jul 2003 04:54: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 19eWQt-0004gP-GK for sipping-archive@odin.ietf.org; Mon, 21 Jul 2003 04:54:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6L8sBcX017999 for sipping-archive@odin.ietf.org; Mon, 21 Jul 2003 04:54:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eWQr-0004gD-TM for sipping-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 04:54: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 EAA21215 for ; Mon, 21 Jul 2003 04:54:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eWQo-000121-00 for sipping-web-archive@ietf.org; Mon, 21 Jul 2003 04:54:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19eWQj-00011x-00 for sipping-web-archive@ietf.org; Mon, 21 Jul 2003 04:54:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eWQj-0004cW-8f; Mon, 21 Jul 2003 04:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eWPx-0004bj-6D for sipping@optimus.ietf.org; Mon, 21 Jul 2003 04:53: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 EAA21195 for ; Mon, 21 Jul 2003 04:53:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eWPu-00011V-00 for sipping@ietf.org; Mon, 21 Jul 2003 04:53:10 -0400 Received: from ns.ivd.nl ([193.67.37.226]) by ietf-mx with esmtp (Exim 4.12) id 19eWPj-00011S-00 for sipping@ietf.org; Mon, 21 Jul 2003 04:52:59 -0400 Received: (from root@localhost) by ns.ivd.nl (8.9.3c/8.6.12) id KAA87724 for ; Mon, 21 Jul 2003 10:54:16 +0200 (CEST) Received: by ns.ivd.nl (TUNIX txp2/smap) for id sma087578; Mon, 21 Jul 03 10:52:49 +0200 Received: from IVD-Message_Server by mailserver.viataal.nl with Novell_GroupWise; Mon, 21 Jul 2003 10:53:50 +0200 Message-Id: X-Mailer: Novell GroupWise 5.5.5 Date: Mon, 21 Jul 2003 10:53:44 +0200 From: "A vWijk" To: Cc: , , , , , Subject: Re: [Sipping] Update to caller preferences use cases Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 fully agree here Guido. So, lets start on this. :-) greetz Arnoud PS A big problem is still how a relay service can know what kind of = service you need. Especially for incoming relay calls.=20 <<< ggybels@webclient.eu.blackberry.net 7/17 8:23p >>> Mike and others, You raise a number of interesting issues, and so have other people over = the last couple of days. I'm happy to comment on a case by case basis, but it seems to me that = there is a more fundamental issue here: the fact that we are missing a = clear set of use cases describing the various scenarios for relay service = usage as well as a proper set of requirements in terms of functional = behaviour. Maybe Arnoud and myself, together with those that want to participate = should first carry out a proper analysis of this whole problem. We could = then prepare a draft that presents the relay cases so that the most = appropriate solutions can then be created. Otherwise, I think that we will keep bouncing the issue around: we will = raise a particular case, work out a solution for it, only to see that it = doesn't fit very well with other cases. Maybe we first need to establish = the bigger picture, try to get the overview first, before we can start = detailing? What do you all think? Based on a conversation I had with Arnoud today I = think he would agree with this and I think we are willing to do this = analysis and write it down. Does this sound like a good way forward? Guido >>> "mhammer@cisco.com" 07/17/03 18:21 >>> At 01:49 PM 7/16/2003 +0200, A vWijk wrote: >And that it does not require the hearing impaired user to be registered=20= >with a relay operator At the risk of assuming too much, does this mean that the hearing-impairedu= ser does not have a "home" relay operator, but will need to be able to=20 send an INVITE, much like an "sos" service code (perhaps "tdd" or = "relay"),a long with caller preferences or pre-conditions indicating the need for ap articular type of relay service (e.g. "voice-to-2973" with=20 directionality), and get forwarded to an appropriate server? Furthermore,w= ould that user be able to send a REFER to that server indicating the = needt o INVITE the called party? This feels like a 2-way conference of sorts,w ith the focus not only mixing media, but also translating media. Or perhaps there is another way to invoke this ad-hoc. Mike =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 Mon Jul 21 08:03: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 IAA25061 for ; Mon, 21 Jul 2003 08:03: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 19eZNu-00020W-IV for sipping-archive@odin.ietf.org; Mon, 21 Jul 2003 08:03:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LC3IF8007716 for sipping-archive@odin.ietf.org; Mon, 21 Jul 2003 08:03:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eZNu-00020N-DQ for sipping-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 08:03: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 IAA25058 for ; Mon, 21 Jul 2003 08:03:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eZNt-0002FJ-00 for sipping-web-archive@ietf.org; Mon, 21 Jul 2003 08:03:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19eZNn-0002FG-00 for sipping-web-archive@ietf.org; Mon, 21 Jul 2003 08:03:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eZNd-0001zM-TF; Mon, 21 Jul 2003 08: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 19eZNW-0001z6-P5 for sipping@optimus.ietf.org; Mon, 21 Jul 2003 08:02: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 IAA25044 for ; Mon, 21 Jul 2003 08:02:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eZNV-0002F4-00 for sipping@ietf.org; Mon, 21 Jul 2003 08:02:53 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19eZNL-0002Eq-00 for sipping@ietf.org; Mon, 21 Jul 2003 08:02:43 -0400 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6LC2IIi018812; Mon, 21 Jul 2003 14:02:18 +0200 (MEST) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id NW4X5T1H; Mon, 21 Jul 2003 14:02:18 +0200 Received: from ericsson.com by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id OAA04323; Mon, 21 Jul 2003 14:02:17 +0200 Message-ID: <3F1BD649.5050707@ericsson.com> Date: Mon, 21 Jul 2003 15:02:17 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" Organization: Ericsson 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, es MIME-Version: 1.0 To: Henning Schulzrinne CC: sipping@ietf.org, aboba@internaut.com Subject: Re: [Sipping] FYI: RADIUS & SIP References: <3F17A571.70101@cs.columbia.edu> In-Reply-To: <3F17A571.70101@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I guess Bernard is asking in relation with the Diameter Multimedia Application that I was presenting at IETF 57. Slides: http://www.drizzle.com/~aboba/IETF57/AAA/IETF-57-Diameter-Multimedia-Application.ppt And the draft, http://www.ietf.org/internet-drafts/draft-belinchon-aaa-diameter-mm-app-01.txt Regards, Miguel Henning Schulzrinne wrote: > 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 -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 21 10: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 KAA28056 for ; Mon, 21 Jul 2003 10: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 19ebKo-0006Ks-MU for sipping-archive@odin.ietf.org; Mon, 21 Jul 2003 10:08:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LE8Eq1024348 for sipping-archive@odin.ietf.org; Mon, 21 Jul 2003 10:08:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ebKo-0006Kd-Hu for sipping-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 10:08: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 KAA28008 for ; Mon, 21 Jul 2003 10:08:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ebKm-00039S-00 for sipping-web-archive@ietf.org; Mon, 21 Jul 2003 10:08:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ebKg-00039M-00 for sipping-web-archive@ietf.org; Mon, 21 Jul 2003 10:08:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ebKb-0006Ha-VM; Mon, 21 Jul 2003 10: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 19ebJp-00064E-Sp for sipping@optimus.ietf.org; Mon, 21 Jul 2003 10: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 KAA27925 for ; Mon, 21 Jul 2003 10:07:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ebJn-00038t-00 for sipping@ietf.org; Mon, 21 Jul 2003 10:07:11 -0400 Received: from brazilnut.cc.columbia.edu ([128.59.59.203] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19ebJY-00038c-00 for sipping@ietf.org; Mon, 21 Jul 2003 10:06:56 -0400 Received: from cs.columbia.edu (dhcp22.cs.columbia.edu [128.59.19.222]) (user=hgs10 mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h6LE6Hk5027398 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 21 Jul 2003 10:06:17 -0400 (EDT) Message-ID: <3F1BF33C.6000709@cs.columbia.edu> Date: Mon, 21 Jul 2003 10:05:48 -0400 From: Henning Schulzrinne 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: "Miguel A. Garcia" CC: sipping@ietf.org, aboba@internaut.com Subject: Re: [Sipping] FYI: RADIUS & SIP References: <3F17A571.70101@cs.columbia.edu> <3F1BD649.5050707@ericsson.com> In-Reply-To: <3F1BD649.5050707@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit No, the discussion is about RADIUS, not DIAMETER. The goal is to identify issues that affect deployment of services in existing RADIUS installations, not whether DIAMETER will replace RADIUS or how to use DIAMETER. Miguel A. Garcia wrote: > I guess Bernard is asking in relation with the Diameter Multimedia > Application that I was presenting at IETF 57. > > Slides: > http://www.drizzle.com/~aboba/IETF57/AAA/IETF-57-Diameter-Multimedia-Application.ppt > > > And the draft, > http://www.ietf.org/internet-drafts/draft-belinchon-aaa-diameter-mm-app-01.txt _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 21 11:19: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 LAA00590 for ; Mon, 21 Jul 2003 11:19: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 19ecRk-0000dS-T4 for sipping-archive@odin.ietf.org; Mon, 21 Jul 2003 11:19:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LFJSIA002438 for sipping-archive@odin.ietf.org; Mon, 21 Jul 2003 11:19:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ecRk-0000bF-9Y for sipping-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 11:19: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 LAA00583 for ; Mon, 21 Jul 2003 11:19:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ecRg-0003jG-00 for sipping-web-archive@ietf.org; Mon, 21 Jul 2003 11:19:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ecRa-0003jB-00 for sipping-web-archive@ietf.org; Mon, 21 Jul 2003 11:19:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ecRJ-0000aL-Iv; Mon, 21 Jul 2003 11: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 19ecR0-0000a8-Gy for sipping@optimus.ietf.org; Mon, 21 Jul 2003 11:18: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 LAA00572 for ; Mon, 21 Jul 2003 11:18:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ecQz-0003ir-00 for sipping@ietf.org; Mon, 21 Jul 2003 11:18:41 -0400 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx with esmtp (Exim 4.12) id 19ecQn-0003ie-00 for sipping@ietf.org; Mon, 21 Jul 2003 11:18:29 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 21 Jul 2003 17:17:48 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Jul 2003 17:17:47 +0200 Message-Id: <53CD1252F68ED61183F5000347AE5F55030AA385@G8PPZ.blf01.telekom.de> From: "Poetzl, Joachim" To: rohan@cisco.com Cc: alan.johnston@mci.com, jdrosen@dynamicsoft.com, sipping@ietf.org, jean-marie.stupka@siemens.com Subject: AW: AW: AW: AW: [Sipping] Question on INVITE Initiated Dialog Eve nt P ackage and Automatic Callback Date: Mon, 21 Jul 2003 17:17:47 +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: , Hi Rohan Mahy, all, response to your answer (see below): What is the use of standards, RFCs and all the discussions on the list, if an implementation and any implementer can choose what ever data it/he want?s to store or not? The behaviour of an implementation should somehow be predictable and fixed in a document which should state a clear particular behaviour. It is clearly said in 13.2.2.3 of RFC3261, that after having received the 486 a standard SIP client considers the INVITE transaction completed and all early dialogs are considered terminated upon reception of the non-2xx final response. So there is no freedom to store anything arbitrarily. Some views on that? Thanks in advance --snip no. the data about the *dialog* is deleted. You are free to keep whatever data around you would like. > 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. it doesn't *have* to keep any data. it *wants* to keep the data, because it wants to invoke another SIP primitive. --snap Best Regards Joachim Potzl Deutsche Telekom AG T-Com Zentrale T38-13; Signalling, Gateways and Switching Systems 64307 DARMSTADT, GERMANY Phone: +49 6151 83-2134 Fax: +49 6151 83-4577 PCFax: +49 521 52244 983 mailto:joachim.poetzl@telekom.de -----Ursprungliche Nachricht----- Von: Rohan Mahy [mailto:rohan@cisco.com] Gesendet: Sonntag, 20. Juli 2003 05:18 An: Stupka Jean-Marie Cc: 'Alan Johnston'; 'Jonathan Rosenberg'; 'sipping@ietf.org' Betreff: Re: AW: AW: AW: [Sipping] Question on INVITE Initiated Dialog Event P ackage and Automatic Callback On Friday, July 18, 2003, at 11:25 AM, Stupka Jean-Marie wrote: > Hi Alan, all, > > Thanks for your answer. Having seen your comments, I think that my > previous mail was somewhat unclear. Let me clarify my concerns with > the flows below. > > > A GW / B > | | > | INVITE F1 | > |--------------->| > |486 Busy Here F2| > |<---------------| User B is busy > | ACK F3 | > |--------------->| > | | > | | > > User A calls user B which is either a SIP client (B) or a PSTN > subscriber behind a Gateway (GW). User B is initially busy when User A > calls. > > The dialog initiated by the INVITE terminates upon reception of the > 486. After having received the 486, a standard SIP client -- i.e. a > client compliant to RFC3261 -- considers the INVITE transaction > completed and generates the ACK for the response (this behavior is > described in 13.2.2.3 of RFC3261). > > 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? no. the data about the *dialog* is deleted. You are free to keep whatever data around you would like. > 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. it doesn't *have* to keep any data. it *wants* to keep the data, because it wants to invoke another SIP primitive. thanks, -rohan > For the reason above, a procedure is needed to keep the > dialog/transaction open after a 486. Of course it would only make > sense to keep the dialog if an automatic callback is possible, e.g. > not precluded by other services at the remote user side, lacking > network resources, etc. This should be indicated to the A's SIP UA. If > automatic callback is possible, then the dialog (the transaction > having the call data) shall not be terminated upon reception of a 486, > leaving user A the possibility to request automatic callback. > If user A does not request automatic callback within a reasonable time > interval (about 10-15s) the dialog terminates. > If user A does request automatic callback then a SUBSCRIBE (F4) is > sent on the already existing dialog that was initiated by the > preceding INVITE (F1). Sending the SUBSCRIBE within the dialog > initiated by the INVITE of the preceding call attempt would ease the > implementation because the call data are available within this dialog > at the SIP user side and at its peer (e.g. the gateway in the PSTN). > The call data can then be re-used for the SUBSCRIBE request and for > the subsequent call when user B gets free. > > The flow then looks like this: > > > A GW / B > | | > | INVITE F1 | > |--------------->| > |486 Busy Here F2| > |<---------------| User B is busy > T |(Autom.Callback | T Timer for automatic callback > | | possible) | | > | | ACK F3 | | > | |--------------->| | > | | | | > ==> | | | | User A requests automatic callback > | | | | > | | SUBSCRIBE F4 | | > v |--------------->| v > | 200 OK F5 | > |<---------------| > | NOTIFY F6 | > |<---------------| > | 200 OK F7 | > |--------------->| > | | > | NOTIFY F8 | <== User B is now available > |<---------------| > | 200 OK F9 | > |--------------->| > | | > | INVITE F10 | > |--------------->| Session setup successfully > | 180 Ringing F11| > |<---------------| > | 200 OK F12 | > |<---------------| > | ACK F13 | > |--------------->| > | Media Session | > |<==============>| > | | > > User A calls user B which is either a SIP client (B) or a PSTN > subscriber behind a Gateway (GW). User B is initially busy when user A > calls. > > - F1 INVITE creates a new dialog between A and GW/B (let's say D1) > > - F2 486 Busy Here: automatic callback is possible. > GW/B indicates to A that automatic callback is possible and starts a > timer in order to retain the dialog and call data for a possible > request for automatic callback. > When receiving a 486 with the indication automatic callback possible, > A starts a timer in order to retain the dialog and call data giving > user A the possibility to request automatic callback. > If the timer expires (no callback request has arrived) then the > dialog/transaction is terminated at A and GW/B. > > - User A requests automatic callback: A stops the timer and sends a > SUBSCRIBE request to GW/B (F4) within the dialog (D1) initiated by the > preceding INVITE. There is one hand no necessity to open a new dialog, > and one the other hand, sending the SUBSCRIBE within the dialog > initiated by the INVITE of the preceding call attempt would ease the > implementation because the call data are available within this dialog > at the SIP user side and at its peer (e.g. the gateway in the PSTN) > > - F4 SUBSCRIBE: GW/B stops the timer and starts monitoring B states. > F5, F6, F7, F8, F9 as in 2.17 of > draft-ietf-sipping-service-examples-04.txt > > - F10 INVITE: A sends the INVITE within the still open dialog (D1) > initiated by F1 (reason given above) > > - F11, etc. as in 2.17 > > Summary: > - There is a need to retain dialogs initiated by an INVITE after a 486 > message when automatic callback is possible > - It is desirable that the SUBSCRIBE request and a subsequent call > set-up triggered by the NOTIFY uses the pre-existing dialog initiated > by the preceding INVITE. > > I hope I have clarified my concerns. > > Regards, > Jean-Marie > > > >> -----Ursprungliche Nachricht----- >> Von: Alan Johnston [mailto:alan.johnston@mci.com] >> Gesendet: Donnerstag, 17. Juli 2003 11:04 >> An: Stupka Jean-Marie; Rohan Mahy >> Cc: 'Jonathan Rosenberg'; 'sipping@ietf.org' >> Betreff: Re: AW: AW: [Sipping] Question on INVITE Initiated >> Dialog Event >> Package and Automatic Callback >> >> >> Hi Jean-Marie, >> >> Comments below. >> >> Thanks, >> Alan Johnston >> MCI >> >> At 10:21 AM 7/17/2003 +0200, Stupka Jean-Marie wrote: >>> Hi Alan, >>> >>> The flow 2.17 of draft-ietf-sipping-service-examples-04.txt >> is a good >>> example to show what is wrong. After the 486 message and the ACK the >>> transaction is terminated: 13.2.2.3 of RFC3261 says "All >> early dialogs are >>> considered terminated upon reception of the non-2xx final response". >> >> In this flow, the dialog between Alice and Bob does terminate >> with the >> INVITE/486/ACK exchange. However, Bob has a dialog with >> another user, say >> Carol (perhaps the flow should show this for clarity?). If >> Bob was not >> currently involved in a dialog, the 486 would not have been >> sent, right? > > Right. > >> >>> As a consequence, all data related to the previous call >> attempt are lost >>> (why and how long should a SIP client keep this data?). >> This is at least >>> conforming RFC3261. >> >> Bob is in a dialog with Carol and keeps this dialog state for >> as long as >> the session exists (as long as Bob is busy). > > Right. > >> >>> Therefore, the SUBSCRIBE message shown in the flow is just >> not possible, >>> as the destination address (Bob's address or user number) is no more >>> existing at the SIP user side. >> >> I don't know what you mean here. Bob still exists - he is still >> sip:bob@biloxi.example.com, right? As a result, Bob can receive a >> SUBSCRIBE request from Alice. Alice does not specify any >> call-id, to-tag, >> or from-tag Event parameters, so that means that Alice is requesting >> information about ANY dialogs that Bob is currently active >> in. (Alice is >> not requesting information about only dialogs with Alice - >> this information >> would be redundant since if Alice is in the dialog, Alice >> would already >> know the state and dialog identifiers.) All the NOTIFYs that Alice >> receives provides information about the dialog between Bob and Carol. >> > > See explanation and flows above. > >>> Keeping the data for a short period of time after a 486 >> would help, but I >>> wouldn't say that this is an implementation matter, the >> behavior of a SIP >>> client needs to be predictable, i.e. standardized. >> >> Dialog state does need to be kept for 32 seconds after sending a >> non-success final response in case of the loss of the 486 >> which would be >> detected by the failure to receive an ACK. However, this has >> no bearing on >> this scenario. > > See explanation and flows above. > >> >>> Coming back to my initial concern, the PSTN call completion >> application >>> given as an example in >> draft-ietf-sipping-dialog-package-02.txt. Sending a >>> SUBSCRIBE to the Dialog Package within the dialog initiated >> by the INVITE >>> of the preceding call attempt would ease the implementation >> because the >>> call data are available within this dialog at the SIP user >> side and at its >>> peer (e.g. the gateway in the PSTN). This is in my understanding the >>> benefit of draft-ietf-sipping-dialog-package-02.txt. >> >> Are you saying that you would like Alice to be able to send a >> SUBSCRIBE to >> Bob within the dialog between Bob and Carol? This is not >> possible - a >> dialog is between two peers - a third party can not inject messages. >> > > Of course not, see explanation and flows above. > >> >>> A possible solution would be to keep for a short period of >> time the dialog >>> with the data of the previous call attempt (i.e. the called >> user number, >>> the bearer description, ...) at the user agent after a 486 >> is received if >>> an automatic callback is possible (e.g. not precluded by >> other services at >>> the remote user side, lacking network resources, etc.). >> >> Are you perhaps concerned about authorizing the subscription? >> That is, Bob >> only accepts a SUBSCRIBE from Alice if Alice has previously >> just made a >> call attempt (sent an INVITE and received a 486 busy)? If >> this is what you >> want, I'm not sure the exact benefit of this. > > Not at all my concern. > >> >>> Then the called user number and other data from the >> preceding call attempt >>> could be re-used for the SUBSCRIBE request and for the >> subsequent call >>> when the remote user gets free. This would require to extend >> the 486 with >>> a "Automatic Callback Possible" indication, or to introduce >> a new message >>> with this meaning and the procedure of retaining data - a >> change to RFC3261. >>> >>> Any view on that? >>> >>> Thanks, >>> Jean-Marie >>> >>> >>> -----Ursprungliche Nachricht----- >>> Von: Alan Johnston [mailto:alan.johnston@mci.com] >>> Gesendet: Mittwoch, 16. Juli 2003 20:39 >>> An: Rohan Mahy; Stupka Jean-Marie >>> Cc: 'Jonathan Rosenberg'; 'sipping@ietf.org' >>> Betreff: Re: AW: [Sipping] Question on INVITE Initiated Dialog Event >>> Package a nd Automatic C allback >>> >>> >>> Hi Jean-Marie, >>> >>> The SIP Service Examples section 2.17 shows exactly this flow with a >>> SUBSCRIBE outside of the dialog (which ended with the 486). >>> >>> Thanks, >>> Alan Johnston >>> MCI >>> >>> At 05:21 AM 7/15/2003 -0700, Rohan Mahy wrote: >>>> Jean-Marie, >>>> >>>> It seems perfectly reasonable to send a SUBSCRIBE to the >> dialog package >>>> outside of a dialog. The default behavior would be to >> send a list of >>>> dialogs but with no dialog information or peer >> information. I believe >>>> this is sufficient to build a callback service. >>>> >>>> thanks, >>>> -rohan >>>> >>>> >>>> >>>> On Tuesday, July 15, 2003, at 02:53 AM, Stupka Jean-Marie wrote: >>>> >>>>> Jonathan, >>>>> >>>>> I doubt that sending the SUBSCRIBE request for the dialog >> package outside >>>>> of any dialog is possible in case of automatic callback, since the >>>>> required data are no more available. >>>>> >>>>> The problem is that when a 486 is received, the dialog >> initiated by the >>>>> INVITE terminates and, the data related to that dialog >> (including the >>>>> called user number) disappear. Therefore it is no more >> possible to send >>>>> the SUBSCRIBE to request automatic callback for this destination. >>>>> >>>>> A possible solution would be to keep for a short period >> of time the data >>>>> of the previous call attempt (i.e. the called user >> number, the bearer >>>>> description, ...) at the user agent after a 486 is >> received. This would >>>>> allow the user agent to re-use the called user number and >> other data from >>>>> the preceding call attempt for the SUBSCRIBE request and for the >>>>> subsequent call after the remote user is free. However, >> the procedure of >>>>> retaining data is not foreseen in RFC 3261. >>>>> >>>>> A better (more economical and user friendly) solution >> would be to keep at >>>>> the user agent only when an automatic callback is >> possible (e.g. not >>>>> precluded by other services at the remote user side, >> lacking network >>>>> resources, etc.). This would require to extend the 486 >> with a "Automatic >>>>> Callback Possible" indication, or to introduce a new >> message with this >>> meaning. >>>>> >>>>> Jean-Marie >>>>> >>>>> -----Ursprungliche Nachricht----- >>>>> Von: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>>>> Gesendet: Montag, 14. Juli 2003 10:18 >>>>> An: Stupka Jean-Marie >>>>> Cc: 'sipping@ietf.org' >>>>> Betreff: Re: [Sipping] Question on INVITE Initiated >> Dialog Event Package >>>>> and Automatic C allback >>>>> >>>>> >>>>> The dialog package can be used by subscriptions made both >> within, and >>>>> outside, of a dialog. So, in the case of automatic callback, the >>>>> caller would, after receiving a 486, send a SUBSCRIBE >> request for the >>>>> dialog package, and do so outside of any dialog. >>>>> >>>>> -Jonathan R. >>>>> >>>>> Stupka Jean-Marie wrote: >>>>> >>>>>> Hello All, >>>>>> >>>>>> As said in RFC 3265 it is possible to create an event >> subscription >>>>>> within a pre-existing dialog, e.g. a dialog created by an INVITE. >>>>>> In my understanding, this is the intention of >>>>>> draft-ietf-sipping-dialog-package-02.txt. >>>>>> >>>>>> According to the (PSTN) Automatic Callback given as example >>>>>> application in the introduction of this draft, user A >> can request a >>>>>> callback when user B hangs-up. User A off course needs to get the >>>>>> information that user B is busy before requesting the automatic >>>>>> callback, i.e. receive a "486 Busy Here" message. However, all >>>>>> early dialogs are considered terminated upon reception >> of a non-2xx >>>>>> final response (13.2.2.3 of RFC 3261). As consequence, the dialog >>>>>> and thus the data of the preceding call attempt are no more >>>>>> available and the callback cannot be requested. >>>>>> >>>>>> Can somebody provide clarification of the applicability >> of RFC 3265 >>>>>> and the draft-ietf-sipping-dialog-package-02.txt to Automatic >>>>>> Callback? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Jean-Marie >>>>>> >>>>>> >>>>>> _______________________________________________ Sipping mailing >>>>>> list https://www1.ietf.org/mailman/listinfo/sipping This list is >>>>>> for NEW development of the 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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 21 11: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 LAA01684 for ; Mon, 21 Jul 2003 11: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 19ed2D-0002Ba-LQ for sipping-archive@odin.ietf.org; Mon, 21 Jul 2003 11:57:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LFv9Pd008396 for sipping-archive@odin.ietf.org; Mon, 21 Jul 2003 11:57:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ed2D-0002BL-Hd for sipping-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 11:57: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 LAA01664 for ; Mon, 21 Jul 2003 11:57:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ed2C-00042k-00 for sipping-web-archive@ietf.org; Mon, 21 Jul 2003 11:57:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ed26-00042h-00 for sipping-web-archive@ietf.org; Mon, 21 Jul 2003 11: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 19ed25-0002AJ-Jg; Mon, 21 Jul 2003 11:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ed1A-00029f-6C for sipping@optimus.ietf.org; Mon, 21 Jul 2003 11: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 LAA01616 for ; Mon, 21 Jul 2003 11:55:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ed19-00042F-00 for sipping@ietf.org; Mon, 21 Jul 2003 11:56:03 -0400 Received: from [216.53.120.69] (helo=mail03.ewr2.n2pcorp.com) by ietf-mx with esmtp (Exim 4.12) id 19ed0y-000423-00 for sipping@ietf.org; Mon, 21 Jul 2003 11:55: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Jul 2003 11:55:12 -0400 Message-ID: Thread-Topic: [Sipping] FYI: RADIUS & SIP Thread-Index: AcNPkZL3MwsPxSRZQBipvXItyq+qFAADbyoQ From: "Romel Khan" To: Content-Transfer-Encoding: quoted-printable Subject: [Sipping] Diversion 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: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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?=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 Mon Jul 21 14:27: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 OAA05866 for ; Mon, 21 Jul 2003 14:27: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 19efNY-0007pX-7g for sipping-archive@odin.ietf.org; Mon, 21 Jul 2003 14:27:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LIRKmO030094 for sipping-archive@odin.ietf.org; Mon, 21 Jul 2003 14:27:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efNX-0007pH-DJ for sipping-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 14:27: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 OAA05846 for ; Mon, 21 Jul 2003 14:27:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19efNU-0005EM-00 for sipping-web-archive@ietf.org; Mon, 21 Jul 2003 14:27:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19efNP-0005EJ-00 for sipping-web-archive@ietf.org; Mon, 21 Jul 2003 14:27:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efNF-0007oB-HJ; Mon, 21 Jul 2003 14: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 19efMc-0007nd-St for sipping@optimus.ietf.org; Mon, 21 Jul 2003 14:26: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 OAA05821 for ; Mon, 21 Jul 2003 14:26:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19efMa-0005Dm-00 for sipping@ietf.org; Mon, 21 Jul 2003 14:26:20 -0400 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 19efMP-0005DR-00 for sipping@ietf.org; Mon, 21 Jul 2003 14:26:09 -0400 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 7164; Mon, 21 Jul 2003 14:24:38 -0400 (EDT) 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: AW: AW: AW: [Sipping] Question on INVITE Initiated Dialog Event P ackage and Automatic Callback Date: Mon, 21 Jul 2003 14:25:29 -0400 Message-ID: <4A3384433CE2AB46A63468CB207E209D59E471@zoe.office.snowshore.com> Thread-Topic: AW: AW: AW: [Sipping] Question on INVITE Initiated Dialog Event P ackage and Automatic Callback Thread-Index: AcNPm7NA6Hs2ulDjTmyNLD6Fkos4zwAGSuvw From: "Eric Burger" To: "Poetzl, Joachim" 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 The standard is VERY well defined. Behaviors are VERY well defined. BY DESIGN, application behaviors are... up to the application. Note that the service you describe can be done 100% at the calling user = agent. However you want to define it, you can. It does not rely on = ANYTHING being implemented at the called user agent. As a service provider, you can implement the service at an outbound = proxy for your subscribers. What this means is that you can give a better (or worse) offering than = your competitors. Contrast this to developing a small set of services = (small, because it takes a long time to standardize something, so = nothing much will get done). This means that everyone offers identical = services. That means that service providers compete predominantly on = price. That is not a good situation, either technically or = commercially. > -----Original Message----- > From: Poetzl, Joachim [mailto:Joachim.Poetzl@telekom.de] > Sent: Mon, July 21, 2003 11:18 AM > To: rohan@cisco.com > Cc: alan.johnston@mci.com; jdrosen@dynamicsoft.com; sipping@ietf.org; > jean-marie.stupka@siemens.com > Subject: AW: AW: AW: AW: [Sipping] Question on INVITE Initiated Dialog > Event P ackage and Automatic Callback >=20 >=20 > Hi Rohan Mahy, all, >=20 > response to your answer (see below): >=20 > What is the use of standards, RFCs and all the discussions on=20 > the list, if an implementation and any implementer can choose=20 > what ever data it/he want?s to store or not? The behaviour of=20 > an implementation should somehow be predictable and fixed in=20 > a document which should state a clear particular behaviour. >=20 > It is clearly said in 13.2.2.3 of RFC3261, that after having=20 > received the 486 a standard SIP client considers the INVITE=20 > transaction completed and all early dialogs are considered=20 > terminated upon reception of the non-2xx final response. >=20 > So there is no freedom to store anything arbitrarily. >=20 > Some views on that? >=20 > Thanks in advance >=20 > --snip >=20 > no. the data about the *dialog* is deleted. You are free to keep=20 > whatever data around you would like. >=20 > > If I am wrong, could you please show me where it is said in RFC3261=20 > > that a SIP user agent has to keep data of a transaction that is=20 > > terminated. >=20 > it doesn't *have* to keep any data. it *wants* to keep the data,=20 > because it wants to invoke another SIP primitive. >=20 > --snap >=20 >=20 >=20 >=20 > Best Regards > =20 > Joachim Potzl > Deutsche Telekom AG > T-Com Zentrale > T38-13; Signalling, Gateways and Switching Systems > 64307 DARMSTADT, GERMANY=20 > Phone: +49 6151 83-2134 > Fax: +49 6151 83-4577 > PCFax: +49 521 52244 983 > mailto:joachim.poetzl@telekom.de >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----Ursprungliche Nachricht----- > Von: Rohan Mahy [mailto:rohan@cisco.com] > Gesendet: Sonntag, 20. Juli 2003 05:18 > An: Stupka Jean-Marie > Cc: 'Alan Johnston'; 'Jonathan Rosenberg'; 'sipping@ietf.org' > Betreff: Re: AW: AW: AW: [Sipping] Question on INVITE Initiated Dialog > Event P ackage and Automatic Callback >=20 >=20 >=20 > On Friday, July 18, 2003, at 11:25 AM, Stupka Jean-Marie wrote: >=20 > > Hi Alan, all, > > > > Thanks for your answer. Having seen your comments, I think that my=20 > > previous mail was somewhat unclear. Let me clarify my concerns with=20 > > the flows below. > > > > > > A GW / B > > | | > > | INVITE F1 | > > |--------------->| > > |486 Busy Here F2| > > |<---------------| User B is busy > > | ACK F3 | > > |--------------->| > > | | > > | | > > > > User A calls user B which is either a SIP client (B) or a PSTN=20 > > subscriber behind a Gateway (GW). User B is initially busy=20 > when User A=20 > > calls. > > > > The dialog initiated by the INVITE terminates upon reception of the=20 > > 486. After having received the 486, a standard SIP client -- i.e. a=20 > > client compliant to RFC3261 -- considers the INVITE transaction=20 > > completed and generates the ACK for the response (this behavior is=20 > > described in 13.2.2.3 of RFC3261). > > > > The transaction being terminated, the data of the call attempt are=20 > > deleted and thus the data (including user B's number) are no more=20 > > available for a subsequent automatic callback request, right? >=20 > no. the data about the *dialog* is deleted. You are free to keep=20 > whatever data around you would like. >=20 > > If I am wrong, could you please show me where it is said in RFC3261=20 > > that a SIP user agent has to keep data of a transaction that is=20 > > terminated. >=20 > it doesn't *have* to keep any data. it *wants* to keep the data,=20 > because it wants to invoke another SIP primitive. >=20 > thanks, > -rohan >=20 > > For the reason above, a procedure is needed to keep the=20 > > dialog/transaction open after a 486. Of course it would only make=20 > > sense to keep the dialog if an automatic callback is possible, e.g.=20 > > not precluded by other services at the remote user side, lacking=20 > > network resources, etc. This should be indicated to the A's=20 > SIP UA. If=20 > > automatic callback is possible, then the dialog (the transaction=20 > > having the call data) shall not be terminated upon=20 > reception of a 486,=20 > > leaving user A the possibility to request automatic callback. > > If user A does not request automatic callback within a=20 > reasonable time=20 > > interval (about 10-15s) the dialog terminates. > > If user A does request automatic callback then a SUBSCRIBE (F4) is=20 > > sent on the already existing dialog that was initiated by the=20 > > preceding INVITE (F1). Sending the SUBSCRIBE within the dialog=20 > > initiated by the INVITE of the preceding call attempt would=20 > ease the=20 > > implementation because the call data are available within=20 > this dialog=20 > > at the SIP user side and at its peer (e.g. the gateway in=20 > the PSTN).=20 > > The call data can then be re-used for the SUBSCRIBE request and for=20 > > the subsequent call when user B gets free. > > > > The flow then looks like this: > > > > > > A GW / B > > | | > > | INVITE F1 | > > |--------------->| > > |486 Busy Here F2| > > |<---------------| User B is busy > > T |(Autom.Callback | T Timer for automatic callback > > | | possible) | | > > | | ACK F3 | | > > | |--------------->| | > > | | | | > > =3D=3D> | | | | User A requests automatic = callback > > | | | | > > | | SUBSCRIBE F4 | | > > v |--------------->| v > > | 200 OK F5 | > > |<---------------| > > | NOTIFY F6 | > > |<---------------| > > | 200 OK F7 | > > |--------------->| > > | | > > | NOTIFY F8 | <=3D=3D User B is now available > > |<---------------| > > | 200 OK F9 | > > |--------------->| > > | | > > | INVITE F10 | > > |--------------->| Session setup successfully > > | 180 Ringing F11| > > |<---------------| > > | 200 OK F12 | > > |<---------------| > > | ACK F13 | > > |--------------->| > > | Media Session | > > |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > > | | > > > > User A calls user B which is either a SIP client (B) or a PSTN=20 > > subscriber behind a Gateway (GW). User B is initially busy=20 > when user A=20 > > calls. > > > > - F1 INVITE creates a new dialog between A and GW/B (let's say D1) > > > > - F2 486 Busy Here: automatic callback is possible. > > GW/B indicates to A that automatic callback is possible and=20 > starts a=20 > > timer in order to retain the dialog and call data for a possible=20 > > request for automatic callback. > > When receiving a 486 with the indication automatic callback=20 > possible,=20 > > A starts a timer in order to retain the dialog and call data giving=20 > > user A the possibility to request automatic callback. > > If the timer expires (no callback request has arrived) then the=20 > > dialog/transaction is terminated at A and GW/B. > > > > - User A requests automatic callback: A stops the timer and sends a=20 > > SUBSCRIBE request to GW/B (F4) within the dialog (D1)=20 > initiated by the=20 > > preceding INVITE. There is one hand no necessity to open a=20 > new dialog,=20 > > and one the other hand, sending the SUBSCRIBE within the dialog=20 > > initiated by the INVITE of the preceding call attempt would=20 > ease the=20 > > implementation because the call data are available within=20 > this dialog=20 > > at the SIP user side and at its peer (e.g. the gateway in the PSTN) > > > > - F4 SUBSCRIBE: GW/B stops the timer and starts monitoring B states. > > F5, F6, F7, F8, F9 as in 2.17 of=20 > > draft-ietf-sipping-service-examples-04.txt > > > > - F10 INVITE: A sends the INVITE within the still open dialog (D1)=20 > > initiated by F1 (reason given above) > > > > - F11, etc. as in 2.17 > > > > Summary: > > - There is a need to retain dialogs initiated by an INVITE=20 > after a 486=20 > > message when automatic callback is possible > > - It is desirable that the SUBSCRIBE request and a subsequent call=20 > > set-up triggered by the NOTIFY uses the pre-existing dialog=20 > initiated=20 > > by the preceding INVITE. > > > > I hope I have clarified my concerns. > > > > Regards, > > Jean-Marie > > > > > > > >> -----Ursprungliche Nachricht----- > >> Von: Alan Johnston [mailto:alan.johnston@mci.com] > >> Gesendet: Donnerstag, 17. Juli 2003 11:04 > >> An: Stupka Jean-Marie; Rohan Mahy > >> Cc: 'Jonathan Rosenberg'; 'sipping@ietf.org' > >> Betreff: Re: AW: AW: [Sipping] Question on INVITE Initiated > >> Dialog Event > >> Package and Automatic Callback > >> > >> > >> Hi Jean-Marie, > >> > >> Comments below. > >> > >> Thanks, > >> Alan Johnston > >> MCI > >> > >> At 10:21 AM 7/17/2003 +0200, Stupka Jean-Marie wrote: > >>> Hi Alan, > >>> > >>> The flow 2.17 of draft-ietf-sipping-service-examples-04.txt > >> is a good > >>> example to show what is wrong. After the 486 message and=20 > the ACK the > >>> transaction is terminated: 13.2.2.3 of RFC3261 says "All > >> early dialogs are > >>> considered terminated upon reception of the non-2xx final=20 > response". > >> > >> In this flow, the dialog between Alice and Bob does terminate > >> with the > >> INVITE/486/ACK exchange. However, Bob has a dialog with > >> another user, say > >> Carol (perhaps the flow should show this for clarity?). If > >> Bob was not > >> currently involved in a dialog, the 486 would not have been > >> sent, right? > > > > Right. > > > >> > >>> As a consequence, all data related to the previous call > >> attempt are lost > >>> (why and how long should a SIP client keep this data?). > >> This is at least > >>> conforming RFC3261. > >> > >> Bob is in a dialog with Carol and keeps this dialog state for > >> as long as > >> the session exists (as long as Bob is busy). > > > > Right. > > > >> > >>> Therefore, the SUBSCRIBE message shown in the flow is just > >> not possible, > >>> as the destination address (Bob's address or user number)=20 > is no more > >>> existing at the SIP user side. > >> > >> I don't know what you mean here. Bob still exists - he is still > >> sip:bob@biloxi.example.com, right? As a result, Bob can receive a > >> SUBSCRIBE request from Alice. Alice does not specify any > >> call-id, to-tag, > >> or from-tag Event parameters, so that means that Alice is=20 > requesting > >> information about ANY dialogs that Bob is currently active > >> in. (Alice is > >> not requesting information about only dialogs with Alice - > >> this information > >> would be redundant since if Alice is in the dialog, Alice > >> would already > >> know the state and dialog identifiers.) All the NOTIFYs that Alice > >> receives provides information about the dialog between Bob=20 > and Carol. > >> > > > > See explanation and flows above. > > > >>> Keeping the data for a short period of time after a 486 > >> would help, but I > >>> wouldn't say that this is an implementation matter, the > >> behavior of a SIP > >>> client needs to be predictable, i.e. standardized. > >> > >> Dialog state does need to be kept for 32 seconds after sending a > >> non-success final response in case of the loss of the 486 > >> which would be > >> detected by the failure to receive an ACK. However, this has > >> no bearing on > >> this scenario. > > > > See explanation and flows above. > > > >> > >>> Coming back to my initial concern, the PSTN call completion > >> application > >>> given as an example in > >> draft-ietf-sipping-dialog-package-02.txt. Sending a > >>> SUBSCRIBE to the Dialog Package within the dialog initiated > >> by the INVITE > >>> of the preceding call attempt would ease the implementation > >> because the > >>> call data are available within this dialog at the SIP user > >> side and at its > >>> peer (e.g. the gateway in the PSTN). This is in my=20 > understanding the > >>> benefit of draft-ietf-sipping-dialog-package-02.txt. > >> > >> Are you saying that you would like Alice to be able to send a > >> SUBSCRIBE to > >> Bob within the dialog between Bob and Carol? This is not > >> possible - a > >> dialog is between two peers - a third party can not inject=20 > messages. > >> > > > > Of course not, see explanation and flows above. > > > >> > >>> A possible solution would be to keep for a short period of > >> time the dialog > >>> with the data of the previous call attempt (i.e. the called > >> user number, > >>> the bearer description, ...) at the user agent after a 486 > >> is received if > >>> an automatic callback is possible (e.g. not precluded by > >> other services at > >>> the remote user side, lacking network resources, etc.). > >> > >> Are you perhaps concerned about authorizing the subscription? > >> That is, Bob > >> only accepts a SUBSCRIBE from Alice if Alice has previously > >> just made a > >> call attempt (sent an INVITE and received a 486 busy)? If > >> this is what you > >> want, I'm not sure the exact benefit of this. > > > > Not at all my concern. > > > >> > >>> Then the called user number and other data from the > >> preceding call attempt > >>> could be re-used for the SUBSCRIBE request and for the > >> subsequent call > >>> when the remote user gets free. This would require to extend > >> the 486 with > >>> a "Automatic Callback Possible" indication, or to introduce > >> a new message > >>> with this meaning and the procedure of retaining data - a > >> change to RFC3261. > >>> > >>> Any view on that? > >>> > >>> Thanks, > >>> Jean-Marie > >>> > >>> > >>> -----Ursprungliche Nachricht----- > >>> Von: Alan Johnston [mailto:alan.johnston@mci.com] > >>> Gesendet: Mittwoch, 16. Juli 2003 20:39 > >>> An: Rohan Mahy; Stupka Jean-Marie > >>> Cc: 'Jonathan Rosenberg'; 'sipping@ietf.org' > >>> Betreff: Re: AW: [Sipping] Question on INVITE Initiated=20 > Dialog Event > >>> Package a nd Automatic C allback > >>> > >>> > >>> Hi Jean-Marie, > >>> > >>> The SIP Service Examples section 2.17 shows exactly this=20 > flow with a > >>> SUBSCRIBE outside of the dialog (which ended with the 486). > >>> > >>> Thanks, > >>> Alan Johnston > >>> MCI > >>> > >>> At 05:21 AM 7/15/2003 -0700, Rohan Mahy wrote: > >>>> Jean-Marie, > >>>> > >>>> It seems perfectly reasonable to send a SUBSCRIBE to the > >> dialog package > >>>> outside of a dialog. The default behavior would be to > >> send a list of > >>>> dialogs but with no dialog information or peer > >> information. I believe > >>>> this is sufficient to build a callback service. > >>>> > >>>> thanks, > >>>> -rohan > >>>> > >>>> > >>>> > >>>> On Tuesday, July 15, 2003, at 02:53 AM, Stupka Jean-Marie wrote: > >>>> > >>>>> Jonathan, > >>>>> > >>>>> I doubt that sending the SUBSCRIBE request for the dialog > >> package outside > >>>>> of any dialog is possible in case of automatic=20 > callback, since the > >>>>> required data are no more available. > >>>>> > >>>>> The problem is that when a 486 is received, the dialog > >> initiated by the > >>>>> INVITE terminates and, the data related to that dialog > >> (including the > >>>>> called user number) disappear. Therefore it is no more > >> possible to send > >>>>> the SUBSCRIBE to request automatic callback for this=20 > destination. > >>>>> > >>>>> A possible solution would be to keep for a short period > >> of time the data > >>>>> of the previous call attempt (i.e. the called user > >> number, the bearer > >>>>> description, ...) at the user agent after a 486 is > >> received. This would > >>>>> allow the user agent to re-use the called user number and > >> other data from > >>>>> the preceding call attempt for the SUBSCRIBE request and for the > >>>>> subsequent call after the remote user is free. However, > >> the procedure of > >>>>> retaining data is not foreseen in RFC 3261. > >>>>> > >>>>> A better (more economical and user friendly) solution > >> would be to keep at > >>>>> the user agent only when an automatic callback is > >> possible (e.g. not > >>>>> precluded by other services at the remote user side, > >> lacking network > >>>>> resources, etc.). This would require to extend the 486 > >> with a "Automatic > >>>>> Callback Possible" indication, or to introduce a new > >> message with this > >>> meaning. > >>>>> > >>>>> Jean-Marie > >>>>> > >>>>> -----Ursprungliche Nachricht----- > >>>>> Von: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > >>>>> Gesendet: Montag, 14. Juli 2003 10:18 > >>>>> An: Stupka Jean-Marie > >>>>> Cc: 'sipping@ietf.org' > >>>>> Betreff: Re: [Sipping] Question on INVITE Initiated > >> Dialog Event Package > >>>>> and Automatic C allback > >>>>> > >>>>> > >>>>> The dialog package can be used by subscriptions made both > >> within, and > >>>>> outside, of a dialog. So, in the case of automatic callback, the > >>>>> caller would, after receiving a 486, send a SUBSCRIBE > >> request for the > >>>>> dialog package, and do so outside of any dialog. > >>>>> > >>>>> -Jonathan R. > >>>>> > >>>>> Stupka Jean-Marie wrote: > >>>>> > >>>>>> Hello All, > >>>>>> > >>>>>> As said in RFC 3265 it is possible to create an event > >> subscription > >>>>>> within a pre-existing dialog, e.g. a dialog created by=20 > an INVITE. > >>>>>> In my understanding, this is the intention of > >>>>>> draft-ietf-sipping-dialog-package-02.txt. > >>>>>> > >>>>>> According to the (PSTN) Automatic Callback given as example > >>>>>> application in the introduction of this draft, user A > >> can request a > >>>>>> callback when user B hangs-up. User A off course needs=20 > to get the > >>>>>> information that user B is busy before requesting the automatic > >>>>>> callback, i.e. receive a "486 Busy Here" message. However, all > >>>>>> early dialogs are considered terminated upon reception > >> of a non-2xx > >>>>>> final response (13.2.2.3 of RFC 3261). As consequence,=20 > the dialog > >>>>>> and thus the data of the preceding call attempt are no more > >>>>>> available and the callback cannot be requested. > >>>>>> > >>>>>> Can somebody provide clarification of the applicability > >> of RFC 3265 > >>>>>> and the draft-ietf-sipping-dialog-package-02.txt to Automatic > >>>>>> Callback? > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>>> Jean-Marie > >>>>>> > >>>>>> > >>>>>> _______________________________________________ Sipping mailing > >>>>>> list https://www1.ietf.org/mailman/listinfo/sipping=20 > This list is > >>>>>> for NEW development of the application of SIP Use > >>>>>> sip-implementors@cs.columbia.edu for questions on=20 > 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: =20 > (973) 952-5050 > >>>>> http://www.jdrosen.net PHONE:=20 > (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=20 > 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 > >> >=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 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 From exim@www1.ietf.org Mon Jul 21 14:35:02 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 OAA06294 for ; Mon, 21 Jul 2003 14:35:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efUa-000050-JY for sipping-archive@odin.ietf.org; Mon, 21 Jul 2003 14:34:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LIYae1000300 for sipping-archive@odin.ietf.org; Mon, 21 Jul 2003 14:34:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efUa-0008WR-Ew for sipping-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 14:34:36 -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 OAA06212 for ; Mon, 21 Jul 2003 14: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 19efU2-0008IF-Ni; Mon, 21 Jul 2003 14:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efTE-0008Bz-Ih for sipping@optimus.ietf.org; Mon, 21 Jul 2003 14:33: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 OAA06062 for ; Mon, 21 Jul 2003 14:33:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19efTB-0005IR-00 for sipping@ietf.org; Mon, 21 Jul 2003 14:33:10 -0400 Received: from tomts10.bellnexxia.net ([209.226.175.54] helo=tomts10-srv.bellnexxia.net) by ietf-mx with esmtp (Exim 4.12) id 19efT1-0005Hf-00 for sipping@ietf.org; Mon, 21 Jul 2003 14:32:59 -0400 Received: from Shulin ([199.243.90.234]) by tomts10-srv.bellnexxia.net (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20030721183228.UJNZ17844.tomts10-srv.bellnexxia.net@Shulin> for ; Mon, 21 Jul 2003 14:32:28 -0400 From: "Shu-Lin CHen" To: Date: Mon, 21 Jul 2003 14:32:24 -0400 Message-ID: <000001c34fb6$70239c50$390aa8c0@blueslicemtl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <4A3384433CE2AB46A63468CB207E209D59E471@zoe.office.snowshore.com> Content-Transfer-Encoding: 7bit Subject: [Sipping] Stateless Proxy Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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: It is mentioned in RFC3261 that a Stateful Proxy cannot switch to Stateless mode if 100 Trying was sent initially. Why should 100 Trying prevent the proxy from switching mode? Thanks. shu-lin chen _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 21 15:53:11 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 PAA09069 for ; Mon, 21 Jul 2003 15:53:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19egi9-0003Hl-9n for sipping-archive@odin.ietf.org; Mon, 21 Jul 2003 15:52:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LJqf59012626 for sipping-archive@odin.ietf.org; Mon, 21 Jul 2003 15:52:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19egi9-0003HZ-4h for sipping-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 15:52:41 -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 PAA09018 for ; Mon, 21 Jul 2003 15:52: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 19eghV-00038j-TU; Mon, 21 Jul 2003 15: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 19eggs-00038R-2Q for sipping@optimus.ietf.org; Mon, 21 Jul 2003 15:51: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 PAA08988 for ; Mon, 21 Jul 2003 15:51:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eggq-0005vY-00 for sipping@ietf.org; Mon, 21 Jul 2003 15:51:20 -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 19eggf-0005tK-00 for sipping@ietf.org; Mon, 21 Jul 2003 15:51:09 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 21 Jul 2003 12:54:37 -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 h6LJmXQk027826; Mon, 21 Jul 2003 12:48:33 -0700 (PDT) Received: from cisco.com ([161.44.79.176]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAV76110; Mon, 21 Jul 2003 15:48:31 -0400 (EDT) Message-ID: <3F1C438F.8020105@cisco.com> Date: Mon, 21 Jul 2003 15:48:31 -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: Adam Roach CC: Jonathan Rosenberg , sipping Subject: Re: [Sipping] How to report DTMF - conclusion of the app interact ion design team: SIP MESSAGE References: <9BF66EBF6BEFD942915B4D4D45C051F3EE601D@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: > Paul Kyzivat [mailto:pkyzivat@cisco.com] writes: > > >>For one thing, the application already has an opportunity to pick the >>address to which the MESSAGEs are sent. So it should be able >>to ensure >>that the recipient knows these messages shouldn't be >>displayed directly >>to an end-user. > > > The problem really is one of a slippery slope. You already > heard a participant get up in the meeting and suggest that > MESSAGE should be the mechanism by which a server pushes a > KPML script to a UA. This is just one use case away from > sending a MESSAGE to a UA from which no message has yet been > received, which will undoubtedly cause the relic I described > earlier. While there may be better ways, I will walk out on a limb as say that this proposal doesn't strike me as too outlandish. But were we to go that way I think there is more specification work to do. >>Beyond that, there is the Content-Disposition header, which seems >>intended for purposes like this. In the normal use of MESSAGE for IM, >>the obvious content type is "render". Here we don't want that, so we >>should pick some other content type. > > Without well-defined semantics in the MESSAGE RFC, I can > confidently assert that many, if not most, UAs will not bother > with checking the Content-Disposition when they receive a MESSAGE. > MESSAGE has an explicit render semantic built in. I agree that this needs some additions to the MESSAGE RFC before it can fly. Or maybe someplace else that better defines content disposition in general, for all messages. That shouldn't be any harder than inventing a new message. And at the same time, it will be nailing down an ambiguity in the existing specs. (What should a UAS do if it receives a MESSAGE whose content disposition isn't "render"?) 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 Tue Jul 22 01:28: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 BAA20097 for ; Tue, 22 Jul 2003 01:28: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 19eph9-00047V-3a for sipping-archive@odin.ietf.org; Tue, 22 Jul 2003 01:28:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6M5SFn1015831 for sipping-archive@odin.ietf.org; Tue, 22 Jul 2003 01:28:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eph8-00047G-6I for sipping-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 01: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 BAA20088 for ; Tue, 22 Jul 2003 01:28:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eph5-0001Y9-00 for sipping-web-archive@ietf.org; Tue, 22 Jul 2003 01:28:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19epgz-0001Y6-00 for sipping-web-archive@ietf.org; Tue, 22 Jul 2003 01:28:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19epgv-00046M-BR; Tue, 22 Jul 2003 01: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 19epgr-000469-4O for sipping@optimus.ietf.org; Tue, 22 Jul 2003 01:27: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 BAA20084 for ; Tue, 22 Jul 2003 01:27:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19epgn-0001Y2-00 for sipping@ietf.org; Tue, 22 Jul 2003 01:27:53 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19epgc-0001Xq-00 for sipping@ietf.org; Tue, 22 Jul 2003 01:27:43 -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 h6M5QXpp005574; Mon, 21 Jul 2003 22:26:33 -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 AJL17237; Mon, 21 Jul 2003 22:22:43 -0700 (PDT) Date: Tue, 22 Jul 2003 07:28:37 +0200 Subject: Re: AW: AW: AW: AW: [Sipping] Question on INVITE Initiated Dialog Eve nt P ackage and Automatic Callback Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: alan.johnston@mci.com, jdrosen@dynamicsoft.com, sipping@ietf.org, jean-marie.stupka@siemens.com To: "Poetzl, Joachim" From: Rohan Mahy In-Reply-To: <53CD1252F68ED61183F5000347AE5F55030AA385@G8PPZ.blf01.telekom.de> Message-Id: <58381C84-BC05-11D7-B1E0-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, July 21, 2003, at 05:17 PM, Poetzl, Joachim wrote: > Hi Rohan Mahy, all, > > response to your answer (see below): > > What is the use of standards, RFCs and all the discussions on the > list, if an implementation and any implementer can choose what ever > data it/he want?s to store or not? The behaviour of an implementation > should somehow be predictable and fixed in a document which should > state a clear particular behaviour. The IETF does not standardize services or implementations, it standardizes protocols. Protocol specifications tell you how to react to messages you receive from the network, and what you are legally permitted to send. Sometimes they also make additional recommendations, but they do not try to limit what services you can build. We've been doing this very successfully for a very long time in computer time scales. > It is clearly said in 13.2.2.3 of RFC3261, that after having received > the 486 a standard SIP client considers the INVITE transaction > completed and all early dialogs are considered terminated upon > reception of the non-2xx final response. yes. the SIP transaction is terminated and the dialogs are terminated. However if an application wants to store a copy of the last contacts tried, or store my grandmother's shoe size, it is free to do that, and in no way restricted by the SIP specification. To take your argument to the absurd extreme no SIP proxy or user agent is allowed to perform logging or accounting, because the SIP specification doesn't say you can make a copy of data from data structures which are mentioned in the spec. thx, -r > So there is no freedom to store anything arbitrarily. > Some views on that? > > Thanks in advance > > --snip > > no. the data about the *dialog* is deleted. You are free to keep > whatever data around you would like. > >> 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. > > it doesn't *have* to keep any data. it *wants* to keep the data, > because it wants to invoke another SIP primitive. > > --snap > > > > > Best Regards > > Joachim Potzl > Deutsche Telekom AG > T-Com Zentrale > T38-13; Signalling, Gateways and Switching Systems > 64307 DARMSTADT, GERMANY > Phone: +49 6151 83-2134 > Fax: +49 6151 83-4577 > PCFax: +49 521 52244 983 > mailto:joachim.poetzl@telekom.de > > > > > > > > > > > > -----Ursprungliche Nachricht----- > Von: Rohan Mahy [mailto:rohan@cisco.com] > Gesendet: Sonntag, 20. Juli 2003 05:18 > An: Stupka Jean-Marie > Cc: 'Alan Johnston'; 'Jonathan Rosenberg'; 'sipping@ietf.org' > Betreff: Re: AW: AW: AW: [Sipping] Question on INVITE Initiated Dialog > Event P ackage and Automatic Callback > > > > On Friday, July 18, 2003, at 11:25 AM, Stupka Jean-Marie wrote: > >> Hi Alan, all, >> >> Thanks for your answer. Having seen your comments, I think that my >> previous mail was somewhat unclear. Let me clarify my concerns with >> the flows below. >> >> >> A GW / B >> | | >> | INVITE F1 | >> |--------------->| >> |486 Busy Here F2| >> |<---------------| User B is busy >> | ACK F3 | >> |--------------->| >> | | >> | | >> >> User A calls user B which is either a SIP client (B) or a PSTN >> subscriber behind a Gateway (GW). User B is initially busy when User A >> calls. >> >> The dialog initiated by the INVITE terminates upon reception of the >> 486. After having received the 486, a standard SIP client -- i.e. a >> client compliant to RFC3261 -- considers the INVITE transaction >> completed and generates the ACK for the response (this behavior is >> described in 13.2.2.3 of RFC3261). >> >> 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? > > no. the data about the *dialog* is deleted. You are free to keep > whatever data around you would like. > >> 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. > > it doesn't *have* to keep any data. it *wants* to keep the data, > because it wants to invoke another SIP primitive. > > thanks, > -rohan > >> For the reason above, a procedure is needed to keep the >> dialog/transaction open after a 486. Of course it would only make >> sense to keep the dialog if an automatic callback is possible, e.g. >> not precluded by other services at the remote user side, lacking >> network resources, etc. This should be indicated to the A's SIP UA. If >> automatic callback is possible, then the dialog (the transaction >> having the call data) shall not be terminated upon reception of a 486, >> leaving user A the possibility to request automatic callback. >> If user A does not request automatic callback within a reasonable time >> interval (about 10-15s) the dialog terminates. >> If user A does request automatic callback then a SUBSCRIBE (F4) is >> sent on the already existing dialog that was initiated by the >> preceding INVITE (F1). Sending the SUBSCRIBE within the dialog >> initiated by the INVITE of the preceding call attempt would ease the >> implementation because the call data are available within this dialog >> at the SIP user side and at its peer (e.g. the gateway in the PSTN). >> The call data can then be re-used for the SUBSCRIBE request and for >> the subsequent call when user B gets free. >> >> The flow then looks like this: >> >> >> A GW / B >> | | >> | INVITE F1 | >> |--------------->| >> |486 Busy Here F2| >> |<---------------| User B is busy >> T |(Autom.Callback | T Timer for automatic callback >> | | possible) | | >> | | ACK F3 | | >> | |--------------->| | >> | | | | >> ==> | | | | User A requests automatic callback >> | | | | >> | | SUBSCRIBE F4 | | >> v |--------------->| v >> | 200 OK F5 | >> |<---------------| >> | NOTIFY F6 | >> |<---------------| >> | 200 OK F7 | >> |--------------->| >> | | >> | NOTIFY F8 | <== User B is now available >> |<---------------| >> | 200 OK F9 | >> |--------------->| >> | | >> | INVITE F10 | >> |--------------->| Session setup successfully >> | 180 Ringing F11| >> |<---------------| >> | 200 OK F12 | >> |<---------------| >> | ACK F13 | >> |--------------->| >> | Media Session | >> |<==============>| >> | | >> >> User A calls user B which is either a SIP client (B) or a PSTN >> subscriber behind a Gateway (GW). User B is initially busy when user A >> calls. >> >> - F1 INVITE creates a new dialog between A and GW/B (let's say D1) >> >> - F2 486 Busy Here: automatic callback is possible. >> GW/B indicates to A that automatic callback is possible and starts a >> timer in order to retain the dialog and call data for a possible >> request for automatic callback. >> When receiving a 486 with the indication automatic callback possible, >> A starts a timer in order to retain the dialog and call data giving >> user A the possibility to request automatic callback. >> If the timer expires (no callback request has arrived) then the >> dialog/transaction is terminated at A and GW/B. >> >> - User A requests automatic callback: A stops the timer and sends a >> SUBSCRIBE request to GW/B (F4) within the dialog (D1) initiated by the >> preceding INVITE. There is one hand no necessity to open a new dialog, >> and one the other hand, sending the SUBSCRIBE within the dialog >> initiated by the INVITE of the preceding call attempt would ease the >> implementation because the call data are available within this dialog >> at the SIP user side and at its peer (e.g. the gateway in the PSTN) >> >> - F4 SUBSCRIBE: GW/B stops the timer and starts monitoring B states. >> F5, F6, F7, F8, F9 as in 2.17 of >> draft-ietf-sipping-service-examples-04.txt >> >> - F10 INVITE: A sends the INVITE within the still open dialog (D1) >> initiated by F1 (reason given above) >> >> - F11, etc. as in 2.17 >> >> Summary: >> - There is a need to retain dialogs initiated by an INVITE after a 486 >> message when automatic callback is possible >> - It is desirable that the SUBSCRIBE request and a subsequent call >> set-up triggered by the NOTIFY uses the pre-existing dialog initiated >> by the preceding INVITE. >> >> I hope I have clarified my concerns. >> >> Regards, >> Jean-Marie >> >> >> >>> -----Ursprungliche Nachricht----- >>> Von: Alan Johnston [mailto:alan.johnston@mci.com] >>> Gesendet: Donnerstag, 17. Juli 2003 11:04 >>> An: Stupka Jean-Marie; Rohan Mahy >>> Cc: 'Jonathan Rosenberg'; 'sipping@ietf.org' >>> Betreff: Re: AW: AW: [Sipping] Question on INVITE Initiated >>> Dialog Event >>> Package and Automatic Callback >>> >>> >>> Hi Jean-Marie, >>> >>> Comments below. >>> >>> Thanks, >>> Alan Johnston >>> MCI >>> >>> At 10:21 AM 7/17/2003 +0200, Stupka Jean-Marie wrote: >>>> Hi Alan, >>>> >>>> The flow 2.17 of draft-ietf-sipping-service-examples-04.txt >>> is a good >>>> example to show what is wrong. After the 486 message and the ACK the >>>> transaction is terminated: 13.2.2.3 of RFC3261 says "All >>> early dialogs are >>>> considered terminated upon reception of the non-2xx final response". >>> >>> In this flow, the dialog between Alice and Bob does terminate >>> with the >>> INVITE/486/ACK exchange. However, Bob has a dialog with >>> another user, say >>> Carol (perhaps the flow should show this for clarity?). If >>> Bob was not >>> currently involved in a dialog, the 486 would not have been >>> sent, right? >> >> Right. >> >>> >>>> As a consequence, all data related to the previous call >>> attempt are lost >>>> (why and how long should a SIP client keep this data?). >>> This is at least >>>> conforming RFC3261. >>> >>> Bob is in a dialog with Carol and keeps this dialog state for >>> as long as >>> the session exists (as long as Bob is busy). >> >> Right. >> >>> >>>> Therefore, the SUBSCRIBE message shown in the flow is just >>> not possible, >>>> as the destination address (Bob's address or user number) is no more >>>> existing at the SIP user side. >>> >>> I don't know what you mean here. Bob still exists - he is still >>> sip:bob@biloxi.example.com, right? As a result, Bob can receive a >>> SUBSCRIBE request from Alice. Alice does not specify any >>> call-id, to-tag, >>> or from-tag Event parameters, so that means that Alice is requesting >>> information about ANY dialogs that Bob is currently active >>> in. (Alice is >>> not requesting information about only dialogs with Alice - >>> this information >>> would be redundant since if Alice is in the dialog, Alice >>> would already >>> know the state and dialog identifiers.) All the NOTIFYs that Alice >>> receives provides information about the dialog between Bob and Carol. >>> >> >> See explanation and flows above. >> >>>> Keeping the data for a short period of time after a 486 >>> would help, but I >>>> wouldn't say that this is an implementation matter, the >>> behavior of a SIP >>>> client needs to be predictable, i.e. standardized. >>> >>> Dialog state does need to be kept for 32 seconds after sending a >>> non-success final response in case of the loss of the 486 >>> which would be >>> detected by the failure to receive an ACK. However, this has >>> no bearing on >>> this scenario. >> >> See explanation and flows above. >> >>> >>>> Coming back to my initial concern, the PSTN call completion >>> application >>>> given as an example in >>> draft-ietf-sipping-dialog-package-02.txt. Sending a >>>> SUBSCRIBE to the Dialog Package within the dialog initiated >>> by the INVITE >>>> of the preceding call attempt would ease the implementation >>> because the >>>> call data are available within this dialog at the SIP user >>> side and at its >>>> peer (e.g. the gateway in the PSTN). This is in my understanding the >>>> benefit of draft-ietf-sipping-dialog-package-02.txt. >>> >>> Are you saying that you would like Alice to be able to send a >>> SUBSCRIBE to >>> Bob within the dialog between Bob and Carol? This is not >>> possible - a >>> dialog is between two peers - a third party can not inject messages. >>> >> >> Of course not, see explanation and flows above. >> >>> >>>> A possible solution would be to keep for a short period of >>> time the dialog >>>> with the data of the previous call attempt (i.e. the called >>> user number, >>>> the bearer description, ...) at the user agent after a 486 >>> is received if >>>> an automatic callback is possible (e.g. not precluded by >>> other services at >>>> the remote user side, lacking network resources, etc.). >>> >>> Are you perhaps concerned about authorizing the subscription? >>> That is, Bob >>> only accepts a SUBSCRIBE from Alice if Alice has previously >>> just made a >>> call attempt (sent an INVITE and received a 486 busy)? If >>> this is what you >>> want, I'm not sure the exact benefit of this. >> >> Not at all my concern. >> >>> >>>> Then the called user number and other data from the >>> preceding call attempt >>>> could be re-used for the SUBSCRIBE request and for the >>> subsequent call >>>> when the remote user gets free. This would require to extend >>> the 486 with >>>> a "Automatic Callback Possible" indication, or to introduce >>> a new message >>>> with this meaning and the procedure of retaining data - a >>> change to RFC3261. >>>> >>>> Any view on that? >>>> >>>> Thanks, >>>> Jean-Marie >>>> >>>> >>>> -----Ursprungliche Nachricht----- >>>> Von: Alan Johnston [mailto:alan.johnston@mci.com] >>>> Gesendet: Mittwoch, 16. Juli 2003 20:39 >>>> An: Rohan Mahy; Stupka Jean-Marie >>>> Cc: 'Jonathan Rosenberg'; 'sipping@ietf.org' >>>> Betreff: Re: AW: [Sipping] Question on INVITE Initiated Dialog Event >>>> Package a nd Automatic C allback >>>> >>>> >>>> Hi Jean-Marie, >>>> >>>> The SIP Service Examples section 2.17 shows exactly this flow with a >>>> SUBSCRIBE outside of the dialog (which ended with the 486). >>>> >>>> Thanks, >>>> Alan Johnston >>>> MCI >>>> >>>> At 05:21 AM 7/15/2003 -0700, Rohan Mahy wrote: >>>>> Jean-Marie, >>>>> >>>>> It seems perfectly reasonable to send a SUBSCRIBE to the >>> dialog package >>>>> outside of a dialog. The default behavior would be to >>> send a list of >>>>> dialogs but with no dialog information or peer >>> information. I believe >>>>> this is sufficient to build a callback service. >>>>> >>>>> thanks, >>>>> -rohan >>>>> >>>>> >>>>> >>>>> On Tuesday, July 15, 2003, at 02:53 AM, Stupka Jean-Marie wrote: >>>>> >>>>>> Jonathan, >>>>>> >>>>>> I doubt that sending the SUBSCRIBE request for the dialog >>> package outside >>>>>> of any dialog is possible in case of automatic callback, since the >>>>>> required data are no more available. >>>>>> >>>>>> The problem is that when a 486 is received, the dialog >>> initiated by the >>>>>> INVITE terminates and, the data related to that dialog >>> (including the >>>>>> called user number) disappear. Therefore it is no more >>> possible to send >>>>>> the SUBSCRIBE to request automatic callback for this destination. >>>>>> >>>>>> A possible solution would be to keep for a short period >>> of time the data >>>>>> of the previous call attempt (i.e. the called user >>> number, the bearer >>>>>> description, ...) at the user agent after a 486 is >>> received. This would >>>>>> allow the user agent to re-use the called user number and >>> other data from >>>>>> the preceding call attempt for the SUBSCRIBE request and for the >>>>>> subsequent call after the remote user is free. However, >>> the procedure of >>>>>> retaining data is not foreseen in RFC 3261. >>>>>> >>>>>> A better (more economical and user friendly) solution >>> would be to keep at >>>>>> the user agent only when an automatic callback is >>> possible (e.g. not >>>>>> precluded by other services at the remote user side, >>> lacking network >>>>>> resources, etc.). This would require to extend the 486 >>> with a "Automatic >>>>>> Callback Possible" indication, or to introduce a new >>> message with this >>>> meaning. >>>>>> >>>>>> Jean-Marie >>>>>> >>>>>> -----Ursprungliche Nachricht----- >>>>>> Von: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>>>>> Gesendet: Montag, 14. Juli 2003 10:18 >>>>>> An: Stupka Jean-Marie >>>>>> Cc: 'sipping@ietf.org' >>>>>> Betreff: Re: [Sipping] Question on INVITE Initiated >>> Dialog Event Package >>>>>> and Automatic C allback >>>>>> >>>>>> >>>>>> The dialog package can be used by subscriptions made both >>> within, and >>>>>> outside, of a dialog. So, in the case of automatic callback, the >>>>>> caller would, after receiving a 486, send a SUBSCRIBE >>> request for the >>>>>> dialog package, and do so outside of any dialog. >>>>>> >>>>>> -Jonathan R. >>>>>> >>>>>> Stupka Jean-Marie wrote: >>>>>> >>>>>>> Hello All, >>>>>>> >>>>>>> As said in RFC 3265 it is possible to create an event >>> subscription >>>>>>> within a pre-existing dialog, e.g. a dialog created by an INVITE. >>>>>>> In my understanding, this is the intention of >>>>>>> draft-ietf-sipping-dialog-package-02.txt. >>>>>>> >>>>>>> According to the (PSTN) Automatic Callback given as example >>>>>>> application in the introduction of this draft, user A >>> can request a >>>>>>> callback when user B hangs-up. User A off course needs to get the >>>>>>> information that user B is busy before requesting the automatic >>>>>>> callback, i.e. receive a "486 Busy Here" message. However, all >>>>>>> early dialogs are considered terminated upon reception >>> of a non-2xx >>>>>>> final response (13.2.2.3 of RFC 3261). As consequence, the dialog >>>>>>> and thus the data of the preceding call attempt are no more >>>>>>> available and the callback cannot be requested. >>>>>>> >>>>>>> Can somebody provide clarification of the applicability >>> of RFC 3265 >>>>>>> and the draft-ietf-sipping-dialog-package-02.txt to Automatic >>>>>>> Callback? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Jean-Marie >>>>>>> >>>>>>> >>>>>>> _______________________________________________ Sipping mailing >>>>>>> list https://www1.ietf.org/mailman/listinfo/sipping This list is >>>>>>> for NEW development of the 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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 22 05:52: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 FAA07498 for ; Tue, 22 Jul 2003 05:52: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 19etod-0007EH-Rv for sipping-archive@odin.ietf.org; Tue, 22 Jul 2003 05:52:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6M9qFNx027786 for sipping-archive@odin.ietf.org; Tue, 22 Jul 2003 05:52:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19etoc-0007E1-ID for sipping-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 05: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 FAA07486 for ; Tue, 22 Jul 2003 05:52:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19etoY-00035E-00 for sipping-web-archive@ietf.org; Tue, 22 Jul 2003 05:52:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19etoS-00035B-00 for sipping-web-archive@ietf.org; Tue, 22 Jul 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 19etoP-0007D2-GM; Tue, 22 Jul 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 19eto5-0007CV-LI for sipping@optimus.ietf.org; Tue, 22 Jul 2003 05: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 FAA07477 for ; Tue, 22 Jul 2003 05:51:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eto1-000355-00 for sipping@ietf.org; Tue, 22 Jul 2003 05:51:37 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 19etnq-000350-00 for sipping@ietf.org; Tue, 22 Jul 2003 05:51:26 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id h6M9pD612974; Tue, 22 Jul 2003 11:51:13 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id h6M9pCA29801; Tue, 22 Jul 2003 11:51:12 +0200 (MEST) Received: from mchh246e.demchh201e.icn.siemens.de (mchh246e.mchh.siemens.de [139.21.200.56]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id LAA29512; Tue, 22 Jul 2003 11:51:11 +0200 (MET DST) Received: by mchh246e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Tue, 22 Jul 2003 11:50:36 +0200 Message-ID: <931A17FBB884D411B02B0008C70D9E2ABF132E@mchh243e.mchh.siemens.de> From: Stupka Jean-Marie To: "'Rohan Mahy'" , "Poetzl, Joachim" Cc: alan.johnston@mci.com, jdrosen@dynamicsoft.com, sipping@ietf.org, Stupka Jean-Marie Subject: AW: AW: AW: AW: AW: [Sipping] Question on INVITE Initiated Dialog Eve nt P ackage and Automatic Callback Date: Tue, 22 Jul 2003 11:50:34 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) 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 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 > -----Ursprungliche Nachricht----- > Von: Rohan Mahy [mailto:rohan@cisco.com] > Gesendet: Dienstag, 22. Juli 2003 07:29 > An: Poetzl, Joachim > Cc: alan.johnston@mci.com; jdrosen@dynamicsoft.com; sipping@ietf.org; > jean-marie.stupka@siemens.com > Betreff: Re: AW: AW: AW: AW: [Sipping] Question on INVITE Initiated > Dialog Eve nt P ackage and Automatic Callback > > > > On Monday, July 21, 2003, at 05:17 PM, Poetzl, Joachim wrote: > > > Hi Rohan Mahy, all, > > > > response to your answer (see below): > > > > What is the use of standards, RFCs and all the discussions on the > > list, if an implementation and any implementer can choose what ever > > data it/he want?s to store or not? The behaviour of an > implementation > > should somehow be predictable and fixed in a document which should > > state a clear particular behaviour. > > The IETF does not standardize services or implementations, it > standardizes protocols. Protocol specifications tell you how to react > to messages you receive from the network, and what you are legally > permitted to send. Sometimes they also make additional > recommendations, but they do not try to limit what services you can > build. We've been doing this very successfully for a very > long time in > computer time scales. > > > It is clearly said in 13.2.2.3 of RFC3261, that after > having received > > the 486 a standard SIP client considers the INVITE transaction > > completed and all early dialogs are considered terminated upon > > reception of the non-2xx final response. > > yes. the SIP transaction is terminated and the dialogs are > terminated. > However if an application wants to store a copy of the last > contacts > tried, or store my grandmother's shoe size, it is free to do > that, and > in no way restricted by the SIP specification. To take your argument > to the absurd extreme no SIP proxy or user agent is allowed > to perform > logging or accounting, because the SIP specification doesn't say you > can make a copy of data from data structures which are mentioned in > the spec. > > thx, > -r > > > So there is no freedom to store anything arbitrarily. > > Some views on that? > > > > Thanks in advance > > > > --snip > > > > no. the data about the *dialog* is deleted. You are free to keep > > whatever data around you would like. > > > >> 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. > > > > it doesn't *have* to keep any data. it *wants* to keep the data, > > because it wants to invoke another SIP primitive. > > > > --snap > > > > > > > > > > Best Regards > > > > Joachim Potzl > > Deutsche Telekom AG > > T-Com Zentrale > > T38-13; Signalling, Gateways and Switching Systems > > 64307 DARMSTADT, GERMANY > > Phone: +49 6151 83-2134 > > Fax: +49 6151 83-4577 > > PCFax: +49 521 52244 983 > > mailto:joachim.poetzl@telekom.de > > > > > > > > > > > > > > > > > > > > > > > > -----Ursprungliche Nachricht----- > > Von: Rohan Mahy [mailto:rohan@cisco.com] > > Gesendet: Sonntag, 20. Juli 2003 05:18 > > An: Stupka Jean-Marie > > Cc: 'Alan Johnston'; 'Jonathan Rosenberg'; 'sipping@ietf.org' > > Betreff: Re: AW: AW: AW: [Sipping] Question on INVITE > Initiated Dialog > > Event P ackage and Automatic Callback > > > > > > > > On Friday, July 18, 2003, at 11:25 AM, Stupka Jean-Marie wrote: > > > >> Hi Alan, all, > >> > >> Thanks for your answer. Having seen your comments, I think that my > >> previous mail was somewhat unclear. Let me clarify my concerns with > >> the flows below. > >> > >> > >> A GW / B > >> | | > >> | INVITE F1 | > >> |--------------->| > >> |486 Busy Here F2| > >> |<---------------| User B is busy > >> | ACK F3 | > >> |--------------->| > >> | | > >> | | > >> > >> User A calls user B which is either a SIP client (B) or a PSTN > >> subscriber behind a Gateway (GW). User B is initially busy > when User A > >> calls. > >> > >> The dialog initiated by the INVITE terminates upon reception of the > >> 486. After having received the 486, a standard SIP client -- i.e. a > >> client compliant to RFC3261 -- considers the INVITE transaction > >> completed and generates the ACK for the response (this behavior is > >> described in 13.2.2.3 of RFC3261). > >> > >> 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? > > > > no. the data about the *dialog* is deleted. You are free to keep > > whatever data around you would like. > > > >> 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. > > > > it doesn't *have* to keep any data. it *wants* to keep the data, > > because it wants to invoke another SIP primitive. > > > > thanks, > > -rohan > > > >> For the reason above, a procedure is needed to keep the > >> dialog/transaction open after a 486. Of course it would only make > >> sense to keep the dialog if an automatic callback is possible, e.g. > >> not precluded by other services at the remote user side, lacking > >> network resources, etc. This should be indicated to the > A's SIP UA. If > >> automatic callback is possible, then the dialog (the transaction > >> having the call data) shall not be terminated upon > reception of a 486, > >> leaving user A the possibility to request automatic callback. > >> If user A does not request automatic callback within a > reasonable time > >> interval (about 10-15s) the dialog terminates. > >> If user A does request automatic callback then a SUBSCRIBE (F4) is > >> sent on the already existing dialog that was initiated by the > >> preceding INVITE (F1). Sending the SUBSCRIBE within the dialog > >> initiated by the INVITE of the preceding call attempt > would ease the > >> implementation because the call data are available within > this dialog > >> at the SIP user side and at its peer (e.g. the gateway in > the PSTN). > >> The call data can then be re-used for the SUBSCRIBE request and for > >> the subsequent call when user B gets free. > >> > >> The flow then looks like this: > >> > >> > >> A GW / B > >> | | > >> | INVITE F1 | > >> |--------------->| > >> |486 Busy Here F2| > >> |<---------------| User B is busy > >> T |(Autom.Callback | T Timer for automatic callback > >> | | possible) | | > >> | | ACK F3 | | > >> | |--------------->| | > >> | | | | > >> ==> | | | | User A requests > automatic callback > >> | | | | > >> | | SUBSCRIBE F4 | | > >> v |--------------->| v > >> | 200 OK F5 | > >> |<---------------| > >> | NOTIFY F6 | > >> |<---------------| > >> | 200 OK F7 | > >> |--------------->| > >> | | > >> | NOTIFY F8 | <== User B is now available > >> |<---------------| > >> | 200 OK F9 | > >> |--------------->| > >> | | > >> | INVITE F10 | > >> |--------------->| Session setup successfully > >> | 180 Ringing F11| > >> |<---------------| > >> | 200 OK F12 | > >> |<---------------| > >> | ACK F13 | > >> |--------------->| > >> | Media Session | > >> |<==============>| > >> | | > >> > >> User A calls user B which is either a SIP client (B) or a PSTN > >> subscriber behind a Gateway (GW). User B is initially busy > when user A > >> calls. > >> > >> - F1 INVITE creates a new dialog between A and GW/B (let's say D1) > >> > >> - F2 486 Busy Here: automatic callback is possible. > >> GW/B indicates to A that automatic callback is possible > and starts a > >> timer in order to retain the dialog and call data for a possible > >> request for automatic callback. > >> When receiving a 486 with the indication automatic > callback possible, > >> A starts a timer in order to retain the dialog and call data giving > >> user A the possibility to request automatic callback. > >> If the timer expires (no callback request has arrived) then the > >> dialog/transaction is terminated at A and GW/B. > >> > >> - User A requests automatic callback: A stops the timer and sends a > >> SUBSCRIBE request to GW/B (F4) within the dialog (D1) > initiated by the > >> preceding INVITE. There is one hand no necessity to open a > new dialog, > >> and one the other hand, sending the SUBSCRIBE within the dialog > >> initiated by the INVITE of the preceding call attempt > would ease the > >> implementation because the call data are available within > this dialog > >> at the SIP user side and at its peer (e.g. the gateway in the PSTN) > >> > >> - F4 SUBSCRIBE: GW/B stops the timer and starts monitoring > B states. > >> F5, F6, F7, F8, F9 as in 2.17 of > >> draft-ietf-sipping-service-examples-04.txt > >> > >> - F10 INVITE: A sends the INVITE within the still open dialog (D1) > >> initiated by F1 (reason given above) > >> > >> - F11, etc. as in 2.17 > >> > >> Summary: > >> - There is a need to retain dialogs initiated by an INVITE > after a 486 > >> message when automatic callback is possible > >> - It is desirable that the SUBSCRIBE request and a subsequent call > >> set-up triggered by the NOTIFY uses the pre-existing > dialog initiated > >> by the preceding INVITE. > >> > >> I hope I have clarified my concerns. > >> > >> Regards, > >> Jean-Marie > >> > >> > >> > >>> -----Ursprungliche Nachricht----- > >>> Von: Alan Johnston [mailto:alan.johnston@mci.com] > >>> Gesendet: Donnerstag, 17. Juli 2003 11:04 > >>> An: Stupka Jean-Marie; Rohan Mahy > >>> Cc: 'Jonathan Rosenberg'; 'sipping@ietf.org' > >>> Betreff: Re: AW: AW: [Sipping] Question on INVITE Initiated > >>> Dialog Event > >>> Package and Automatic Callback > >>> > >>> > >>> Hi Jean-Marie, > >>> > >>> Comments below. > >>> > >>> Thanks, > >>> Alan Johnston > >>> MCI > >>> > >>> At 10:21 AM 7/17/2003 +0200, Stupka Jean-Marie wrote: > >>>> Hi Alan, > >>>> > >>>> The flow 2.17 of draft-ietf-sipping-service-examples-04.txt > >>> is a good > >>>> example to show what is wrong. After the 486 message and > the ACK the > >>>> transaction is terminated: 13.2.2.3 of RFC3261 says "All > >>> early dialogs are > >>>> considered terminated upon reception of the non-2xx > final response". > >>> > >>> In this flow, the dialog between Alice and Bob does terminate > >>> with the > >>> INVITE/486/ACK exchange. However, Bob has a dialog with > >>> another user, say > >>> Carol (perhaps the flow should show this for clarity?). If > >>> Bob was not > >>> currently involved in a dialog, the 486 would not have been > >>> sent, right? > >> > >> Right. > >> > >>> > >>>> As a consequence, all data related to the previous call > >>> attempt are lost > >>>> (why and how long should a SIP client keep this data?). > >>> This is at least > >>>> conforming RFC3261. > >>> > >>> Bob is in a dialog with Carol and keeps this dialog state for > >>> as long as > >>> the session exists (as long as Bob is busy). > >> > >> Right. > >> > >>> > >>>> Therefore, the SUBSCRIBE message shown in the flow is just > >>> not possible, > >>>> as the destination address (Bob's address or user > number) is no more > >>>> existing at the SIP user side. > >>> > >>> I don't know what you mean here. Bob still exists - he is still > >>> sip:bob@biloxi.example.com, right? As a result, Bob can receive a > >>> SUBSCRIBE request from Alice. Alice does not specify any > >>> call-id, to-tag, > >>> or from-tag Event parameters, so that means that Alice is > requesting > >>> information about ANY dialogs that Bob is currently active > >>> in. (Alice is > >>> not requesting information about only dialogs with Alice - > >>> this information > >>> would be redundant since if Alice is in the dialog, Alice > >>> would already > >>> know the state and dialog identifiers.) All the NOTIFYs > that Alice > >>> receives provides information about the dialog between > Bob and Carol. > >>> > >> > >> See explanation and flows above. > >> > >>>> Keeping the data for a short period of time after a 486 > >>> would help, but I > >>>> wouldn't say that this is an implementation matter, the > >>> behavior of a SIP > >>>> client needs to be predictable, i.e. standardized. > >>> > >>> Dialog state does need to be kept for 32 seconds after sending a > >>> non-success final response in case of the loss of the 486 > >>> which would be > >>> detected by the failure to receive an ACK. However, this has > >>> no bearing on > >>> this scenario. > >> > >> See explanation and flows above. > >> > >>> > >>>> Coming back to my initial concern, the PSTN call completion > >>> application > >>>> given as an example in > >>> draft-ietf-sipping-dialog-package-02.txt. Sending a > >>>> SUBSCRIBE to the Dialog Package within the dialog initiated > >>> by the INVITE > >>>> of the preceding call attempt would ease the implementation > >>> because the > >>>> call data are available within this dialog at the SIP user > >>> side and at its > >>>> peer (e.g. the gateway in the PSTN). This is in my > understanding the > >>>> benefit of draft-ietf-sipping-dialog-package-02.txt. > >>> > >>> Are you saying that you would like Alice to be able to send a > >>> SUBSCRIBE to > >>> Bob within the dialog between Bob and Carol? This is not > >>> possible - a > >>> dialog is between two peers - a third party can not > inject messages. > >>> > >> > >> Of course not, see explanation and flows above. > >> > >>> > >>>> A possible solution would be to keep for a short period of > >>> time the dialog > >>>> with the data of the previous call attempt (i.e. the called > >>> user number, > >>>> the bearer description, ...) at the user agent after a 486 > >>> is received if > >>>> an automatic callback is possible (e.g. not precluded by > >>> other services at > >>>> the remote user side, lacking network resources, etc.). > >>> > >>> Are you perhaps concerned about authorizing the subscription? > >>> That is, Bob > >>> only accepts a SUBSCRIBE from Alice if Alice has previously > >>> just made a > >>> call attempt (sent an INVITE and received a 486 busy)? If > >>> this is what you > >>> want, I'm not sure the exact benefit of this. > >> > >> Not at all my concern. > >> > >>> > >>>> Then the called user number and other data from the > >>> preceding call attempt > >>>> could be re-used for the SUBSCRIBE request and for the > >>> subsequent call > >>>> when the remote user gets free. This would require to extend > >>> the 486 with > >>>> a "Automatic Callback Possible" indication, or to introduce > >>> a new message > >>>> with this meaning and the procedure of retaining data - a > >>> change to RFC3261. > >>>> > >>>> Any view on that? > >>>> > >>>> Thanks, > >>>> Jean-Marie > >>>> > >>>> > >>>> -----Ursprungliche Nachricht----- > >>>> Von: Alan Johnston [mailto:alan.johnston@mci.com] > >>>> Gesendet: Mittwoch, 16. Juli 2003 20:39 > >>>> An: Rohan Mahy; Stupka Jean-Marie > >>>> Cc: 'Jonathan Rosenberg'; 'sipping@ietf.org' > >>>> Betreff: Re: AW: [Sipping] Question on INVITE Initiated > Dialog Event > >>>> Package a nd Automatic C allback > >>>> > >>>> > >>>> Hi Jean-Marie, > >>>> > >>>> The SIP Service Examples section 2.17 shows exactly this > flow with a > >>>> SUBSCRIBE outside of the dialog (which ended with the 486). > >>>> > >>>> Thanks, > >>>> Alan Johnston > >>>> MCI > >>>> > >>>> At 05:21 AM 7/15/2003 -0700, Rohan Mahy wrote: > >>>>> Jean-Marie, > >>>>> > >>>>> It seems perfectly reasonable to send a SUBSCRIBE to the > >>> dialog package > >>>>> outside of a dialog. The default behavior would be to > >>> send a list of > >>>>> dialogs but with no dialog information or peer > >>> information. I believe > >>>>> this is sufficient to build a callback service. > >>>>> > >>>>> thanks, > >>>>> -rohan > >>>>> > >>>>> > >>>>> > >>>>> On Tuesday, July 15, 2003, at 02:53 AM, Stupka Jean-Marie wrote: > >>>>> > >>>>>> Jonathan, > >>>>>> > >>>>>> I doubt that sending the SUBSCRIBE request for the dialog > >>> package outside > >>>>>> of any dialog is possible in case of automatic > callback, since the > >>>>>> required data are no more available. > >>>>>> > >>>>>> The problem is that when a 486 is received, the dialog > >>> initiated by the > >>>>>> INVITE terminates and, the data related to that dialog > >>> (including the > >>>>>> called user number) disappear. Therefore it is no more > >>> possible to send > >>>>>> the SUBSCRIBE to request automatic callback for this > destination. > >>>>>> > >>>>>> A possible solution would be to keep for a short period > >>> of time the data > >>>>>> of the previous call attempt (i.e. the called user > >>> number, the bearer > >>>>>> description, ...) at the user agent after a 486 is > >>> received. This would > >>>>>> allow the user agent to re-use the called user number and > >>> other data from > >>>>>> the preceding call attempt for the SUBSCRIBE request > and for the > >>>>>> subsequent call after the remote user is free. However, > >>> the procedure of > >>>>>> retaining data is not foreseen in RFC 3261. > >>>>>> > >>>>>> A better (more economical and user friendly) solution > >>> would be to keep at > >>>>>> the user agent only when an automatic callback is > >>> possible (e.g. not > >>>>>> precluded by other services at the remote user side, > >>> lacking network > >>>>>> resources, etc.). This would require to extend the 486 > >>> with a "Automatic > >>>>>> Callback Possible" indication, or to introduce a new > >>> message with this > >>>> meaning. > >>>>>> > >>>>>> Jean-Marie > >>>>>> > >>>>>> -----Ursprungliche Nachricht----- > >>>>>> Von: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > >>>>>> Gesendet: Montag, 14. Juli 2003 10:18 > >>>>>> An: Stupka Jean-Marie > >>>>>> Cc: 'sipping@ietf.org' > >>>>>> Betreff: Re: [Sipping] Question on INVITE Initiated > >>> Dialog Event Package > >>>>>> and Automatic C allback > >>>>>> > >>>>>> > >>>>>> The dialog package can be used by subscriptions made both > >>> within, and > >>>>>> outside, of a dialog. So, in the case of automatic > callback, the > >>>>>> caller would, after receiving a 486, send a SUBSCRIBE > >>> request for the > >>>>>> dialog package, and do so outside of any dialog. > >>>>>> > >>>>>> -Jonathan R. > >>>>>> > >>>>>> Stupka Jean-Marie wrote: > >>>>>> > >>>>>>> Hello All, > >>>>>>> > >>>>>>> As said in RFC 3265 it is possible to create an event > >>> subscription > >>>>>>> within a pre-existing dialog, e.g. a dialog created > by an INVITE. > >>>>>>> In my understanding, this is the intention of > >>>>>>> draft-ietf-sipping-dialog-package-02.txt. > >>>>>>> > >>>>>>> According to the (PSTN) Automatic Callback given as example > >>>>>>> application in the introduction of this draft, user A > >>> can request a > >>>>>>> callback when user B hangs-up. User A off course > needs to get the > >>>>>>> information that user B is busy before requesting the > automatic > >>>>>>> callback, i.e. receive a "486 Busy Here" message. However, all > >>>>>>> early dialogs are considered terminated upon reception > >>> of a non-2xx > >>>>>>> final response (13.2.2.3 of RFC 3261). As > consequence, the dialog > >>>>>>> and thus the data of the preceding call attempt are no more > >>>>>>> available and the callback cannot be requested. > >>>>>>> > >>>>>>> Can somebody provide clarification of the applicability > >>> of RFC 3265 > >>>>>>> and the draft-ietf-sipping-dialog-package-02.txt to Automatic > >>>>>>> Callback? > >>>>>>> > >>>>>>> Regards, > >>>>>>> > >>>>>>> Jean-Marie > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > Sipping mailing > >>>>>>> list https://www1.ietf.org/mailman/listinfo/sipping > This list is > >>>>>>> for NEW development of the 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 > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 22 12:19: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 MAA18694 for ; Tue, 22 Jul 2003 12:19: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 19ezrI-0005Zb-5T for sipping-archive@odin.ietf.org; Tue, 22 Jul 2003 12:19:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MGJOJM021419 for sipping-archive@odin.ietf.org; Tue, 22 Jul 2003 12:19:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ezrI-0005ZO-1K for sipping-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 12:19: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 MAA18677 for ; Tue, 22 Jul 2003 12:19:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ezrG-0005nN-00 for sipping-web-archive@ietf.org; Tue, 22 Jul 2003 12:19:22 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ezrA-0005nG-00 for sipping-web-archive@ietf.org; Tue, 22 Jul 2003 12:19:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ezqv-0005Xp-IO; Tue, 22 Jul 2003 12: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 19ezqt-0005XZ-By for sipping@optimus.ietf.org; Tue, 22 Jul 2003 12:18: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 MAA18646 for ; Tue, 22 Jul 2003 12:18:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ezqr-0005mx-00 for sipping@ietf.org; Tue, 22 Jul 2003 12:18:57 -0400 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail2.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 19ezqg-0005mN-00 for sipping@ietf.org; Tue, 22 Jul 2003 12:18:47 -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 h6MGI7BD012700 for ; Tue, 22 Jul 2003 18:18:07 +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 SAA10825 for ; Tue, 22 Jul 2003 18:18:07 +0200 (MET DST) Received: from bst.bsf.alcatel.fr ([155.132.76.46]) by mail (8.8.8+Sun/) with ESMTP id SAA10805; Tue, 22 Jul 2003 18:18:06 +0200 (MET DST) Message-ID: <3F1D63C2.627B6A9F@bst.bsf.alcatel.fr> Date: Tue, 22 Jul 2003 18:18:10 +0200 From: Rey Jean-Francois X-Mailer: Mozilla 4.7 [fr] (WinNT; I) X-Accept-Language: fr MIME-Version: 1.0 To: john.elwell@siemens.com CC: sipping@ietf.org Content-Type: text/plain; charset=iso-8859-1 X-Virus-Scanned: by amavisd-new Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by smail2.alcatel.fr id h6MGI7BD012700 Content-Transfer-Encoding: quoted-printable Subject: [Sipping] 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: quoted-printable Content-Transfer-Encoding: quoted-printable Hi John and all, I've been reading the draft-ietf-sipping-qsig2sip-01.txt. The document is= very useful. Please find some minor comments/questions on the draft : #1 - Page 4 - Introduction The document states : "This document specifies signalling interworking for basic services=20 that provide a bi-directional transfer capability for speech, DTMF,=20 facsimile and modem media" There are different drafts and RFCs dealing with DTMF, facsimile and mode= m media. It's not really explained further down in the text. What about cla= rifying it or removing it ? #2 - Page 10 - 7 General requirements "In addition, the gateway SHALL support SIP TU behaviour for a UA in acco= rdance 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 rem= oved. #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 ? #4 - Page 10 - 7 General requirements "As a result of DNS look-up by the gateway in order to determine where=20 to send a SIP INVITE request, a number of candidate destinations can=20 be attempted in sequence. The way in which this is handled by the=20 gateway is outside the scope of this specification. However, any=20 behaviour specified in this document on receipt of a SIP final=20 response SHOULD apply only when there are no more candidate=20 destinations to try." Does it mean that the ingress gateway SHOULD try the next retrieved addre= sses if the first one responded 484 for instance ? I guess that rfc3263 narrows t= he scope to "network" or "component" failures. #5 - Page 13 - 8.2.1.1 Receipt of QSIG SETUP message "If information in the QSIG SETUP message is unsuitable for generating=20 any of the mandatory fields in a SIP INVITE request (e.g., if a=20 Request-URI cannot be derived from the QSIG Called party number=20 information element)" I agree in theory, but what could prevent from deriving a R-URI in the re= al world ? #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=20 answer information in a reliable provisional response and can be " I agree that reliable provisional response are better, but why use reliab= le here ? If a UA that does not support PRACK sends a 183 with a SDP body, the me= dia stream is established too. #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=20 gateway SHALL send a SIP ACK request." What happens on the QSIG side ? #8 - Page 23 - 8.3.9 "If a gateway receives a SIP INVITE request with the same Call-ID as=20 an existing call for which the QSIG state is overlap sending and = with=20 updated Request-URI and To fields from which a called party numbe= r=20 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".=20 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. #9 - Page 24 - 8.3.9 "If a gateway receives a SIP INVITE request for a new dialog with the=20 same Call-ID as an existing SIP INVITE request for which the gate= way=20 has not yet sent a final response and failing to meet the other=20 conditions above concerning overlap sending, the gateway SHALL=20 respond to the new request with a SIP 485 (Ambiguous) response." It's not very important, but could you explain the motivation of this sen= tence. Is it related to the merged requests ? #10 - Page 24 - 8.4.1=20 "as specified in table 1." Why aren't some status codes symetric in table 1 and table 2. For instanc= e=20 - 408 Request timeout maps 102 Recovery on timer expiry and=20 - 102 Recovery on timer expiry maps 504 Server time-out. BTW, I like the way table 2 is similar to what RFC3398 describes. #11 - Page 24- 8.4.1 Very minor comment. It's obvious that the 200 responses are related to th= e INVITE transaction, but this is not written. #12 - Page 27 - 8.4.4 What is the meaning of () in table 2=20 403 Forbidden 21 (Call rejected)=20 404 Not found 1 (Unallocated number)=20 -- 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 ? #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 peopl= e might get confused by the slight difference in the mapping of the messages of t= he "ISDN PBX" examples of the call-flow draft ? -- And there are some minor editorial bugs : #1 Page 4 :=20 Annex A =FB Example message sequences..............................40=20 ^^_ inconsistent character Annex B =FB Change log.............................................53 ^^_ inconsitent character #2 Page 4=20 1 Introduction=20 QSIG is twice between double quotes. It is not consistent with the rest o= f the document #3 - Page 7 figure 1 is broken because of it is at the end of the page + Figure 1 =FB Environment ^^^ #4 - Page 9 Figure 2 =FB Protocol model ^^^ #5 - Page 13 - 8.2.1.1 Receipt of QSIG SETUP message=20 gateway SHALL initiate QSIG call clearing procedures using cause=20 value 28 =F4invalid number format (address incomplete)=F6.=20 ^^^ ^^^ #6 - Page 18 - 8.2.2.2.7 Receipt of a SIP 4xx, 5xx or 6xx final response The NOTEs are not tagged with a number as anywhere else in the document w= hen there are more than one of them in a section. #7 - Page 25 RFC-3261 is usually referred as [10] in the document. No hyphen is used. = (idem in 8.4.2, 8.4.3, 8.4.4) + Table 1 =FB Mapping of QSIG Cause Value to SIP 4xx-6xx responses ^^^ +=20 Usually the Table legend is below the table itself (as for figures) #8 - 10.1 Derivation of QSIG Bearer capability information element only =E6audio=C6 then the Bearer capability information element SHALL BE ^^ ^^ + Table 3 =FB Bearer capability encoding for =E6audio=C6 transfer=20 ^^ ^^ ^^ #9 - 10.2 Derivation of media type in SDP=20 Table 4 =FB Media type setting in SDP based on Bearer capability ^^ #10 - 13 Normative References Networks (PISN) =FB Addressing=F6 (also published by ECMA as Standard ^^ ^^ [13] J. Peterson, =F4A Privacy Mechanism for the Session Initiation=20 ^^ Protocol (SIP)=F6, RFC 3323=20 ^^ [14] C. Jennings, J. Peterson, M. Watson, =F4Private Extensions to the=20 ^^ Session Initiation Protocol (SIP) for Asserted Identity within=20 Trusted Networks=F6, RFC 3325=20 ^^ [17] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)=F6, ^^ [19] G. Camarillo, A. Roach, J. Peterson, L. Ong, =F4Mapping of=20 ^^ Integrated Services Digital Network (ISDN) User Part (ISUP) Overl= ap=20 Signalling to the Session Initiation Protocol=F6, draft-ietf-sipp= ing- ^^ #11 Annex A (informative) =FB Example message sequences=20 ^^ Figure X =FB Typical message sequence for=20 ^^ #12 - Page 47 - Figure 7 Message #11 should be labelled 4-200 OK as it is the response to 4-PRACK #13 - Page 48 - Figure 8 Message #7 should be labelled QSIG SETUP ACK ^^ #14 - Page 49 - Figure 9 Indentation problem #15=20 Annex B (temporary) =FB Change log ^^ Regards, Jean-Francois. -- Jean-Francois REY ALCATEL _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 22 14:21: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 OAA21666 for ; Tue, 22 Jul 2003 14:21: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 19f1lD-00024O-CD for sipping-archive@odin.ietf.org; Tue, 22 Jul 2003 14:21:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MILFkT007955 for sipping-archive@odin.ietf.org; Tue, 22 Jul 2003 14:21:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f1lD-00024E-9R for sipping-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 14:21: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 OAA21641 for ; Tue, 22 Jul 2003 14:21:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f1lA-0006Ud-00 for sipping-web-archive@ietf.org; Tue, 22 Jul 2003 14:21:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19f1l5-0006Ua-00 for sipping-web-archive@ietf.org; Tue, 22 Jul 2003 14:21:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f1kz-00023A-EI; Tue, 22 Jul 2003 14: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 19f1kI-00022M-3j for sipping@optimus.ietf.org; Tue, 22 Jul 2003 14:20: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 OAA21617 for ; Tue, 22 Jul 2003 14:20:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f1kF-0006TZ-00 for sipping@ietf.org; Tue, 22 Jul 2003 14:20:15 -0400 Received: from bay8-f17.bay8.hotmail.com ([64.4.27.17] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19f1k4-0006SZ-00 for sipping@ietf.org; Tue, 22 Jul 2003 14:20:04 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 22 Jul 2003 11:18:10 -0700 Received: from 64.32.181.163 by by8fd.bay8.hotmail.msn.com with HTTP; Tue, 22 Jul 2003 18:18:09 GMT X-Originating-IP: [64.32.181.163] X-Originating-Email: [ramrajprabu@hotmail.com] From: "RamrajPrabu Balasubramanian" To: shulin@blueslice.com, sipping@ietf.org Subject: Re: [Sipping] Stateless Proxy Date: Tue, 22 Jul 2003 11:18:09 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Jul 2003 18:18:10.0366 (UTC) FILETIME=[9B54B5E0:01C3507D] Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 shu-lin, Suppose UA1 has sent a request to UA2 thro the proxy and has recvd a 100 trying , it will then not retx the request since it got the provisional response. Now if the proxy becomes stateless and forwards the request to the other UA2 and the response to that gets lost, we will be in trouble. the UA1 will nomore retx the request because it will be happy that it got the 100 trying. and according to UA2 it has already responded . so UA1 will be stuck if the proxy went stateless after the 100 trying. ( this problem shouldnt exists if the request is an INVITE, the response retx till the ACK on the UA2 side will help it ). -ramraj >From: "Shu-Lin CHen" >To: >Subject: [Sipping] Stateless Proxy >Date: Mon, 21 Jul 2003 14:32:24 -0400 > > >Hi: >It is mentioned in RFC3261 that a Stateful Proxy cannot switch to >Stateless mode if 100 Trying was sent initially. Why should >100 Trying prevent the proxy from switching mode? > > >Thanks. > >shu-lin chen > > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 22 15:05: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 PAA22861 for ; Tue, 22 Jul 2003 15:05: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 19f2Rk-0003rV-K2 for sipping-archive@odin.ietf.org; Tue, 22 Jul 2003 15:05:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MJ5CuE014839 for sipping-archive@odin.ietf.org; Tue, 22 Jul 2003 15:05:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f2Rk-0003rG-GJ for sipping-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 15:05: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 PAA22804 for ; Tue, 22 Jul 2003 15:05:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f2Rh-0006jS-00 for sipping-web-archive@ietf.org; Tue, 22 Jul 2003 15:05:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19f2Rb-0006jP-00 for sipping-web-archive@ietf.org; Tue, 22 Jul 2003 15:05:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f2RZ-0003qI-9N; Tue, 22 Jul 2003 15: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 19f2RG-0003pu-Q5 for sipping@optimus.ietf.org; Tue, 22 Jul 2003 15:04: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 PAA22756 for ; Tue, 22 Jul 2003 15:04:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f2RC-0006jI-00 for sipping@ietf.org; Tue, 22 Jul 2003 15:04:38 -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 19f2R1-0006jC-00 for sipping@ietf.org; Tue, 22 Jul 2003 15:04:27 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 22 Jul 2003 12:04:27 -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 h6MJ3W89029119; Tue, 22 Jul 2003 12:03:32 -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 AJL82495; Tue, 22 Jul 2003 11:59:37 -0700 (PDT) Date: Tue, 22 Jul 2003 21:05:37 +0200 Subject: Re: [Sipping] Update to caller preferences use cases Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: A vWijk , jdrosen@dynamicsoft.com, guido.gybels@rnid.org.uk, sipping@ietf.org, frank.shearar@rnid.org.uk, james.hamlin@rnid.org.uk, mike.spanner@rnid.org.uk To: Paul Kyzivat From: Rohan Mahy In-Reply-To: <3F153F9B.2080107@cisco.com> Message-Id: <7AE98505-BC77-11D7-B1E0-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, July 16, 2003, at 02:05 PM, Paul Kyzivat wrote: > I think this scenario may be better solved with preconditions - a new > kind of precondition for an acceptable mix of media being available. YUCK. Preconditions is like a strong drug with a lot of negative side-effects. We should be very careful when prescribing it. I don't think it is warranted here. I think ordinary offer/answer negotiation can give us what we need here. thx, -r > This avoids even alerted called parties if a satisfactory arrangement > can't be made. This doesn't exclude using callerprefs to help, such as > in picking the order in which to try devices, but does make it > secondary. > > Today we get away without preconditions on media because generally > there is only one important medium. Many UAs will fail a call if no > media are negotiated, effectively implementing a rudimentary form of > precondition. But that is going to work going forward - there are > beginning to be interesting call flows that have no media. > > So in this case the hearing impared user's UA can first initiate a > call with precondition for streaming text media. If that succeeds, > fine. If not, it can try again - setting up a relay and sending a > voice invite that splices in the relay. > > Paul > > A vWijk wrote: >> Jonathan, >> In this case you are only looking at the relay invocation at the >> callee's side. >> Thus the deaf user must always register him or herself at a selected >> relay service. >> This solution will surely work, but I am not happy with this >> registering with the relay itself. It still does not solve incoming >> relay calls to the exact requirements of the receiving user. >> About your other suggestion: >> > not sure its practical or useful, though, so please comment on that. >> Consider a caller that is hearing impaired. Before making a call, >> they contact a relay service. This relay service will receive audio >> and transform it to streaming text. Of course the caller can also >> receive streaming text directly from the called party. So, in their >> invite, they have an m-line for audio, and an m-line for streaming >> text. They add a caller preference to have their call routed to a >> device that supports streaming text. In this way, if a called party >> happens to be able to do both audio on one device, or streaming text >> on another, the call is routed to the device that can do streaming >> text. >> It feels farfetched to me, so please comment. >> Thanks, >> Jonathan R.> >> If I understand this correctly, you state here that receiving >> streamed text (RFC 2793) can be a caller preference to ensure when a >> text call is initiated, that the correct terminal is selected. That >> is a good idea. It gives the users more flexibility. >> And this allows the user who owns 3 phones, 2 cheap wallmart phones >> without any screen and keyboard and one normal IP telephone with a >> screen and keyboard to receive text calls on the right phone. >> And perhaps also in this way that the user is only logged in a non >> text terminal, that the relay service or the caller can see that >> setting up a text call won't work? >> And that the relay then kicks in and converts audio to text and vice >> versa. >> I think that this is indeed useful. This will allow a relay service >> at least know which kind of media can be sent. E.g a terminal has no >> video ability but it has text. The relay can fallback to text in that >> case. Even if the caller uses a video connection and communicates via >> signlanguage. >> (or the video caller can also switch to text and skip the relay). >> This is useful at this level. So, this can be added as an example. It >> does not offer flexibility of voice carry over or hearing carry over >> and such. But for the basics it is useful. >> Greetz >> Arnoud >> <<< Jonathan Rosenberg 7/16 8:54a >>> >> inline. >> Guido Gybels wrote: >>> Jonathan: >>> >>> <<* added a hearing impaired use case>> >>> >>> First of all, I think it is extremely useful to have some use cases >>> for deaf and hard of hearing people in the draft. Some >>> comments/questions: >>> >>> 1) If I understand the case correctly, the relay service needs to >>> issue a registration on behalf of the user, indicating that this >>> registration accepts audio. One of the problems with that scenario >>> is that this seems to suggest that the user must register through >>> the relay in order to be able to receive incoming calls. I'm not so >>> sure how practical that is, especially with regard to roaming users >>> (how would they discover the relay in the network?). Some thoughts >>> on this would be welcome. >> I thought about this use case some more, and I actually concluded >> that this service is really not a CALLER PREFERENCE service. Its not >> about the caller preference at all. Its about a routing application >> on the callee side which sends incoming audio calls to a relay, and >> incoming messaging calls to a user. Something like that is best >> implemented through servlets on the callee side, or something. Its >> not a caller preference at all. So, I would like to remove this case >> altogether, and find something which is really an example of a caller >> preference. >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the 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 Tue Jul 22 15:14: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 PAA23916 for ; Tue, 22 Jul 2003 15:14: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 19f2aP-0004dK-3g for sipping-archive@odin.ietf.org; Tue, 22 Jul 2003 15:14:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MJE9fe017803 for sipping-archive@odin.ietf.org; Tue, 22 Jul 2003 15:14:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f2aP-0004d4-0M for sipping-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 15: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 PAA23843 for ; Tue, 22 Jul 2003 15:14:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f2aN-0006nY-00 for sipping-web-archive@ietf.org; Tue, 22 Jul 2003 15:14:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19f2aI-0006nV-00 for sipping-web-archive@ietf.org; Tue, 22 Jul 2003 15: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 19f2aH-0004ah-1R; Tue, 22 Jul 2003 15: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 19f2Zb-0004Yx-KR for sipping@optimus.ietf.org; Tue, 22 Jul 2003 15:13: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 PAA23755 for ; Tue, 22 Jul 2003 15:13:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f2Za-0006n8-00 for sipping@ietf.org; Tue, 22 Jul 2003 15:13:18 -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 19f2ZP-0006mf-00 for sipping@ietf.org; Tue, 22 Jul 2003 15:13:07 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 22 Jul 2003 12:13:24 -0700 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 h6MJCUuG007563; Tue, 22 Jul 2003 12:12:30 -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 AJL83950; Tue, 22 Jul 2003 12:08:31 -0700 (PDT) Date: Tue, 22 Jul 2003 21:14:32 +0200 Subject: Re: [Sipping] How to report DTMF - conclusion of the app interaction design team: SIP MESSAGE Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Jonathan Rosenberg , sipping To: Paul Kyzivat From: Rohan Mahy In-Reply-To: <3F169D88.20003@cisco.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 Thursday, July 17, 2003, at 02:58 PM, Paul Kyzivat wrote: > > > Jonathan Rosenberg wrote: >> 7. SIP MESSAGE >> Send a SIP MESSAGE request from the client to the application, >> containing the digit sequence to report. >> This was a bit of a bending of the semantic of MESSAGE, which is >> really meant for conveying information for display to a user. >> However, the issue is mostly philosophical in nature. We didnt see >> any particular technical issue that would prevent this from working, >> unlike all of the above ones which had technical issues. > > Adam gave some good examples of bad things that might happen if the > UAS was confused and attempted to render this to a user. But there are > mechanisms already in place to deal with this. > > For one thing, the application already has an opportunity to pick the > address to which the MESSAGEs are sent. So it should be able to ensure > that the recipient knows these messages shouldn't be displayed > directly to an end-user. > > Beyond that, there is the Content-Disposition header, which seems > intended for purposes like this. In the normal use of MESSAGE for IM, > the obvious content type is "render". Here we don't want that, so we > should pick some other content type. Paul, small comment here. KPML *is* rendered to the user. The distinction that you are seeking between "just through this up on the display/speaker" vs. "interpret this markup and show the result to the user" does not exist and in fact is the antithesis of the motivation for the term render. You "render" HTML and XML+XSL and VoiceXML to a user. KPML should be no different. thanks, -rohan > Sip takes Content-Disposition from RFC 2183, and extends the valid set > of values. Sip specific values are: session, alert, icon, render, > while 2183 values are inline and attachment. It isn't entirely clear > how any of these apply to MESSAGE. The following is a shot at defining > them: > > - session: as defined in 3261, this is N/A for MESSAGE. > But by extension it might actually be appropriate here. > - alert: N/A? > - icon: N/A? > - render: clearly appropriate - display content to recipient user > - inline: In the case of email, this means the body should be > displayed with the containing document. When this is used > with MESSAGE it *could* be viewed as being processed > internally by the application. > So this is a possibility. > - attachment: In case of email this means to not display with the > enclosing message, and often is used for transferring > files. This probably has good meaning for file transfer in > IM. > > The prudent course might be to define a new disposition specifically > for this purpose - perhaps "application", aligning it well with the > use of App-Info to initiate the process. > > Bottom line - I think MESSAGE is quite suitable for the DTMF reports. > > Paul > > > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Tue Jul 22 15:42: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 PAA24758 for ; Tue, 22 Jul 2003 15:42: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 19f31X-0006Ba-Mj for sipping-archive@odin.ietf.org; Tue, 22 Jul 2003 15:42:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MJgB5n023739 for sipping-archive@odin.ietf.org; Tue, 22 Jul 2003 15:42:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f31W-00068G-S7 for sipping-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 15: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 PAA24724 for ; Tue, 22 Jul 2003 15:42:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f31V-0006wv-00 for sipping-web-archive@ietf.org; Tue, 22 Jul 2003 15:42:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19f31P-0006ws-00 for sipping-web-archive@ietf.org; Tue, 22 Jul 2003 15:42:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f31O-00066H-A4; Tue, 22 Jul 2003 15: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 19f31G-00065x-MT for sipping@optimus.ietf.org; Tue, 22 Jul 2003 15:41: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 PAA24715 for ; Tue, 22 Jul 2003 15:41:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f31F-0006wd-00 for sipping@ietf.org; Tue, 22 Jul 2003 15:41:53 -0400 Received: from pmesmtp01.wcom.com ([199.249.20.1]) by ietf-mx with esmtp (Exim 4.12) id 19f314-0006wI-00 for sipping@ietf.org; Tue, 22 Jul 2003 15:41:42 -0400 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HIF009H6Y3LMW@firewall.wcom.com> for sipping@ietf.org; Tue, 22 Jul 2003 19:28:43 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HIF00K01Y2XMI@pmismtp01.wcomnet.com>; Tue, 22 Jul 2003 19:28:41 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.129.49]) by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HIF00JOFY3A1V@pmismtp01.wcomnet.com>; Tue, 22 Jul 2003 19:28:26 +0000 (GMT) Date: Tue, 22 Jul 2003 14:28:24 -0500 From: Alan Johnston Subject: Re: AW: AW: AW: [Sipping] Question on INVITE Initiated Dialog Event Package and Automatic Callback In-reply-to: <4A3384433CE2AB46A63468CB207E209D097CC8@zoe.office.snowshor e.com> X-Sender: Alan.Johnston@pop.mcit.com To: Eric Burger , Stupka Jean-Marie Cc: Jonathan Rosenberg , Rohan Mahy , sipping@ietf.org Message-id: <5.2.1.1.0.20030722142243.02243cd0@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=iso-8859-1; format=flowed 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 agree 100% with Eric. No dialog information storage is needed or required for this service. Thanks, Alan Johnston MCI At 05:43 AM 7/18/2003 -0400, Eric Burger wrote: >[sorry for the formatting -- Web Outlook at VIE] > >I don't understand why there is a need to have the callback in the same=20 >dialog. It is a different call. It is up to the UAC to know it tried a=20 >location, got a 486, and should try again later. As Alan wrote, you don't= =20 >need to be in a dialog to subscribe to the dialog state. > >I am trying to understand the request. If it is to simply save on the=20 >ACK, it is not worth it. Is it to have something special going on at the= =20 >UAS? For example, only accept an INVITE from a camped-on caller? There=20 >are better ways of doing that, driven by the UA's, as well. > > >-----Urspr=C3=BCngliche Nachricht----- >Von: Stupka Jean-Marie [mailto:jean-marie.stupka@siemens.com] >Gesendet: Fr 18.07.2003 05:25 >An: 'Alan Johnston' >Cc: 'Jonathan Rosenberg'; Rohan Mahy; 'sipping@ietf.org' >Betreff: AW: AW: AW: [Sipping] Question on INVITE Initiated Dialog Event=20 >Package and Automatic Callback > > > > Hi Alan, all, > > Thanks for your answer. Having seen your comments, I think that=20 > my previous mail was somewhat unclear. Let me clarify my concerns with=20 > the flows below. > > > A GW / B > | | > | INVITE F1 | > |--------------->| > |486 Busy Here F2| > |<---------------| User B is busy > | ACK F3 | > |--------------->| > | | > | | > > User A calls user B which is either a SIP client (B) or a PSTN=20 > subscriber behind a Gateway (GW). User B is initially busy when User A= calls. > > The dialog initiated by the INVITE terminates upon reception of=20 > the 486. After having received the 486, a standard SIP client -- i.e. a=20 > client compliant to RFC3261 -- considers the INVITE transaction completed= =20 > and generates the ACK for the response (this behavior is described in=20 > 13.2.2.3 of RFC3261). > > The transaction being terminated, the data of the call attempt=20 > are deleted and thus the data (including user B's number) are no more=20 > available for a subsequent automatic callback request, right? > If I am wrong, could you please show me where it is said in=20 > RFC3261 that a SIP user agent has to keep data of a transaction that is=20 > terminated. > > For the reason above, a procedure is needed to keep the=20 > dialog/transaction open after a 486. Of course it would only make sense=20 > to keep the dialog if an automatic callback is possible, e.g. not=20 > precluded by other services at the remote user side, lacking network=20 > resources, etc. This should be indicated to the A's SIP UA. If automatic= =20 > callback is possible, then the dialog (the transaction having the call=20 > data) shall not be terminated upon reception of a 486, leaving user A the= =20 > possibility to request automatic callback. > If user A does not request automatic callback within a reasonable= =20 > time interval (about 10-15s) the dialog terminates. > If user A does request automatic callback then a SUBSCRIBE (F4)=20 > is sent on the already existing dialog that was initiated by the=20 > preceding INVITE (F1). Sending the SUBSCRIBE within the dialog initiated= =20 > by the INVITE of the preceding call attempt would ease the implementation= =20 > because the call data are available within this dialog at the SIP user=20 > side and at its peer (e.g. the gateway in the PSTN). The call data can=20 > then be re-used for the SUBSCRIBE request and for the subsequent call=20 > when user B gets free. > > The flow then looks like this: > > > A GW / B > | | > | INVITE F1 | > |--------------->| > |486 Busy Here F2| > |<---------------| User B is busy > T |(Autom.Callback | T Timer for automatic callback > | | possible) | | > | | ACK F3 | | > | |--------------->| | > | | | | > =3D=3D> | | | | User A requests automatic= callback > | | | | > | | SUBSCRIBE F4 | | > v |--------------->| v > | 200 OK F5 | > |<---------------| > | NOTIFY F6 | > |<---------------| > | 200 OK F7 | > |--------------->| > | | > | NOTIFY F8 | <=3D=3D User B is now available > |<---------------| > | 200 OK F9 | > |--------------->| > | | > | INVITE F10 | > |--------------->| Session setup successfully > | 180 Ringing F11| > |<---------------| > | 200 OK F12 | > |<---------------| > | ACK F13 | > |--------------->| > | Media Session | > |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > | | > > User A calls user B which is either a SIP client (B) or a PSTN=20 > subscriber behind a Gateway (GW). User B is initially busy when user A= calls. > > - F1 INVITE creates a new dialog between A and GW/B (let's say D1) > > - F2 486 Busy Here: automatic callback is possible. > GW/B indicates to A that automatic callback is possible and=20 > starts a timer in order to retain the dialog and call data for a possible= =20 > request for automatic callback. > When receiving a 486 with the indication automatic callback=20 > possible, A starts a timer in order to retain the dialog and call data=20 > giving user A the possibility to request automatic callback. > If the timer expires (no callback request has arrived) then the=20 > dialog/transaction is terminated at A and GW/B. > > - User A requests automatic callback: A stops the timer and sends= =20 > a SUBSCRIBE request to GW/B (F4) within the dialog (D1) initiated by the= =20 > preceding INVITE. There is one hand no necessity to open a new dialog,=20 > and one the other hand, sending the SUBSCRIBE within the dialog initiated= =20 > by the INVITE of the preceding call attempt would ease the implementation= =20 > because the call data are available within this dialog at the SIP user=20 > side and at its peer (e.g. the gateway in the PSTN) > > - F4 SUBSCRIBE: GW/B stops the timer and starts monitoring B= states. > F5, F6, F7, F8, F9 as in 2.17 of=20 > draft-ietf-sipping-service-examples-04.txt > > - F10 INVITE: A sends the INVITE within the still open dialog=20 > (D1) initiated by F1 (reason given above) > > - F11, etc. as in 2.17 > > Summary: > - There is a need to retain dialogs initiated by an INVITE after= =20 > a 486 message when automatic callback is possible > - It is desirable that the SUBSCRIBE request and a subsequent=20 > call set-up triggered by the NOTIFY uses the pre-existing dialog=20 > initiated by the preceding INVITE. > > I hope I have clarified my concerns. > > Regards, > Jean-Marie > > > > > -----Ursprungliche Nachricht----- > > Von: Alan Johnston [mailto:alan.johnston@mci.com] > > Gesendet: Donnerstag, 17. Juli 2003 11:04 > > An: Stupka Jean-Marie; Rohan Mahy > > Cc: 'Jonathan Rosenberg'; 'sipping@ietf.org' > > Betreff: Re: AW: AW: [Sipping] Question on INVITE Initiated > > Dialog Event > > Package and Automatic Callback > > > > > > Hi Jean-Marie, > > > > Comments below. > > > > Thanks, > > Alan Johnston > > MCI > > > > At 10:21 AM 7/17/2003 +0200, Stupka Jean-Marie wrote: > > >Hi Alan, > > > > > >The flow 2.17 of draft-ietf-sipping-service-examples-04.txt > > is a good > > >example to show what is wrong. After the 486 message and the=20 > ACK the > > >transaction is terminated: 13.2.2.3 of RFC3261 says "All > > early dialogs are > > >considered terminated upon reception of the non-2xx final=20 > response". > > > > In this flow, the dialog between Alice and Bob does terminate > > with the > > INVITE/486/ACK exchange. However, Bob has a dialog with > > another user, say > > Carol (perhaps the flow should show this for clarity?). If > > Bob was not > > currently involved in a dialog, the 486 would not have been > > sent, right? > > Right. > > > > > > As a consequence, all data related to the previous call > > attempt are lost > > > (why and how long should a SIP client keep this data?). > > This is at least > > > conforming RFC3261. > > > > Bob is in a dialog with Carol and keeps this dialog state for > > as long as > > the session exists (as long as Bob is busy). > > Right. > > > > > >Therefore, the SUBSCRIBE message shown in the flow is just > > not possible, > > >as the destination address (Bob's address or user number) is=20 > no more > > >existing at the SIP user side. > > > > I don't know what you mean here. Bob still exists - he is still > > sip:bob@biloxi.example.com, right? As a result, Bob can receive= a > > SUBSCRIBE request from Alice. Alice does not specify any > > call-id, to-tag, > > or from-tag Event parameters, so that means that Alice is=20 > requesting > > information about ANY dialogs that Bob is currently active > > in. (Alice is > > not requesting information about only dialogs with Alice - > > this information > > would be redundant since if Alice is in the dialog, Alice > > would already > > know the state and dialog identifiers.) All the NOTIFYs that= Alice > > receives provides information about the dialog between Bob and= =20 > Carol. > > > > See explanation and flows above. > > > >Keeping the data for a short period of time after a 486 > > would help, but I > > >wouldn't say that this is an implementation matter, the > > behavior of a SIP > > >client needs to be predictable, i.e. standardized. > > > > Dialog state does need to be kept for 32 seconds after sending a > > non-success final response in case of the loss of the 486 > > which would be > > detected by the failure to receive an ACK. However, this has > > no bearing on > > this scenario. > > See explanation and flows above. > > > > > >Coming back to my initial concern, the PSTN call completion > > application > > >given as an example in > > draft-ietf-sipping-dialog-package-02.txt. Sending a > > >SUBSCRIBE to the Dialog Package within the dialog initiated > > by the INVITE > > >of the preceding call attempt would ease the implementation > > because the > > >call data are available within this dialog at the SIP user > > side and at its > > >peer (e.g. the gateway in the PSTN). This is in my=20 > understanding the > > >benefit of draft-ietf-sipping-dialog-package-02.txt. > > > > Are you saying that you would like Alice to be able to send a > > SUBSCRIBE to > > Bob within the dialog between Bob and Carol? This is not > > possible - a > > dialog is between two peers - a third party can not inject=20 > messages. > > > > Of course not, see explanation and flows above. > > > > > >A possible solution would be to keep for a short period of > > time the dialog > > >with the data of the previous call attempt (i.e. the called > > user number, > > >the bearer description, ...) at the user agent after a 486 > > is received if > > >an automatic callback is possible (e.g. not precluded by > > other services at > > >the remote user side, lacking network resources, etc.). > > > > Are you perhaps concerned about authorizing the subscription? > > That is, Bob > > only accepts a SUBSCRIBE from Alice if Alice has previously > > just made a > > call attempt (sent an INVITE and received a 486 busy)? If > > this is what you > > want, I'm not sure the exact benefit of this. > > Not at all my concern. > > > > > >Then the called user number and other data from the > > preceding call attempt > > >could be re-used for the SUBSCRIBE request and for the > > subsequent call > > >when the remote user gets free. This would require to extend > > the 486 with > > >a "Automatic Callback Possible" indication, or to introduce > > a new message > > >with this meaning and the procedure of retaining data - a > > change to RFC3261. > > > > > >Any view on that? > > > > > >Thanks, > > >Jean-Marie > > > > > > > > >-----Ursprungliche Nachricht----- > > >Von: Alan Johnston [mailto:alan.johnston@mci.com] > > >Gesendet: Mittwoch, 16. Juli 2003 20:39 > > >An: Rohan Mahy; Stupka Jean-Marie > > >Cc: 'Jonathan Rosenberg'; 'sipping@ietf.org' > > >Betreff: Re: AW: [Sipping] Question on INVITE Initiated Dialog= =20 > Event > > >Package a nd Automatic C allback > > > > > > > > >Hi Jean-Marie, > > > > > >The SIP Service Examples section 2.17 shows exactly this flow= =20 > with a > > >SUBSCRIBE outside of the dialog (which ended with the 486). > > > > > >Thanks, > > >Alan Johnston > > >MCI > > > > > >At 05:21 AM 7/15/2003 -0700, Rohan Mahy wrote: > > > >Jean-Marie, > > > > > > > >It seems perfectly reasonable to send a SUBSCRIBE to the > > dialog package > > > >outside of a dialog. The default behavior would be to > > send a list of > > > >dialogs but with no dialog information or peer > > information. I believe > > > >this is sufficient to build a callback service. > > > > > > > >thanks, > > > >-rohan > > > > > > > > > > > > > > > >On Tuesday, July 15, 2003, at 02:53 AM, Stupka Jean-Marie= wrote: > > > > > > > >>Jonathan, > > > >> > > > >>I doubt that sending the SUBSCRIBE request for the dialog > > package outside > > > >>of any dialog is possible in case of automatic callback,=20 > since the > > > >>required data are no more available. > > > >> > > > >>The problem is that when a 486 is received, the dialog > > initiated by the > > > >>INVITE terminates and, the data related to that dialog > > (including the > > > >>called user number) disappear. Therefore it is no more > > possible to send > > > >>the SUBSCRIBE to request automatic callback for this=20 > destination. > > > >> > > > >>A possible solution would be to keep for a short period > > of time the data > > > >>of the previous call attempt (i.e. the called user > > number, the bearer > > > >>description, ...) at the user agent after a 486 is > > received. This would > > > >>allow the user agent to re-use the called user number and > > other data from > > > >>the preceding call attempt for the SUBSCRIBE request and=20 > for the > > > >>subsequent call after the remote user is free. However, > > the procedure of > > > >>retaining data is not foreseen in RFC 3261. > > > >> > > > >>A better (more economical and user friendly) solution > > would be to keep at > > > >>the user agent only when an automatic callback is > > possible (e.g. not > > > >>precluded by other services at the remote user side, > > lacking network > > > >>resources, etc.). This would require to extend the 486 > > with a "Automatic > > > >>Callback Possible" indication, or to introduce a new > > message with this > > > meaning. > > > >> > > > >>Jean-Marie > > > >> > > > >>-----Ursprungliche Nachricht----- > > > >>Von: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > >>Gesendet: Montag, 14. Juli 2003 10:18 > > > >>An: Stupka Jean-Marie > > > >>Cc: 'sipping@ietf.org' > > > >>Betreff: Re: [Sipping] Question on INVITE Initiated > > Dialog Event Package > > > >>and Automatic C allback > > > >> > > > >> > > > >>The dialog package can be used by subscriptions made both > > within, and > > > >>outside, of a dialog. So, in the case of automatic=20 > callback, the > > > >>caller would, after receiving a 486, send a SUBSCRIBE > > request for the > > > >>dialog package, and do so outside of any dialog. > > > >> > > > >>-Jonathan R. > > > >> > > > >>Stupka Jean-Marie wrote: > > > >> > > > >>>Hello All, > > > >>> > > > >>>As said in RFC 3265 it is possible to create an event > > subscription > > > >>>within a pre-existing dialog, e.g. a dialog created by an= =20 > INVITE. > > > >>>In my understanding, this is the intention of > > > >>>draft-ietf-sipping-dialog-package-02.txt. > > > >>> > > > >>>According to the (PSTN) Automatic Callback given as example > > > >>>application in the introduction of this draft, user A > > can request a > > > >>>callback when user B hangs-up. User A off course needs to= =20 > get the > > > >>>information that user B is busy before requesting the=20 > automatic > > > >>>callback, i.e. receive a "486 Busy Here" message. However,= all > > > >>>early dialogs are considered terminated upon reception > > of a non-2xx > > > >>>final response (13.2.2.3 of RFC 3261). As consequence, the= =20 > dialog > > > >>>and thus the data of the preceding call attempt are no more > > > >>>available and the callback cannot be requested. > > > >>> > > > >>>Can somebody provide clarification of the applicability > > of RFC 3265 > > > >>>and the draft-ietf-sipping-dialog-package-02.txt to= Automatic > > > >>>Callback? > > > >>> > > > >>>Regards, > > > >>> > > > >>>Jean-Marie > > > >>> > > > >>> > > > >>>_______________________________________________ Sipping=20 > mailing > > > >>>list https://www1.ietf.org/mailman/listinfo/sipping This= =20 > list is > > > >>>for NEW development of the application of SIP Use > > > >>>sip-implementors@cs.columbia.edu for questions on current= =20 > 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)=20 > 952-5050 > > > >>http://www.jdrosen.net PHONE: (973)=20 > 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=20 > 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=20 > 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 > > > >J*i=8Ax&j)b=9E=20 >b=B2=D8m=B6=9B?=FF0=D6'=AD~=8A=E0=FEf=A2=ADf=A7=FEX=AC=B6)=DF=A3=FB"=A6=98= =A7=818b=B2X=AC=B6+=A2=B3DY=D7=AFzZ)=99=E9=ED=A1=FBay=AAi=AD'=B6*'=A1=F4=88= =3DK=B2*b=9A=99^=99=E9=ED=A2=BB=B1=CA%=BAf=E2i=E7n~=8A=EA=B9=EB-=8A=89=EC=A2= w.=AE=B7=A7=B6=C8=A9R=C7=AC=8A=98=9E=B5=FA+=81=FA+=9D=ECz=F7=A5=A2=99=9E=9E= =DB(}=CA+y" _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 23 02:44:47 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 CAA03631 for ; Wed, 23 Jul 2003 02:44: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 19fDMK-0003Q5-21 for sipping-archive@odin.ietf.org; Wed, 23 Jul 2003 02:44:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6N6iJSP013141 for sipping-archive@odin.ietf.org; Wed, 23 Jul 2003 02:44:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fDMJ-0003Ps-7C for sipping-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 02:44: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 CAA03622 for ; Wed, 23 Jul 2003 02:44:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fDMF-0002LG-00 for sipping-web-archive@ietf.org; Wed, 23 Jul 2003 02:44:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fDM9-0002LD-00 for sipping-web-archive@ietf.org; Wed, 23 Jul 2003 02:44:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fDM2-0003MO-Ac; Wed, 23 Jul 2003 02: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 19fDLw-0003Ls-RR for sipping@optimus.ietf.org; Wed, 23 Jul 2003 02:43: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 CAA03617 for ; Wed, 23 Jul 2003 02:43:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fDLt-0002L6-00 for sipping@ietf.org; Wed, 23 Jul 2003 02:43: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 19fDLi-0002Kd-00 for sipping@ietf.org; Wed, 23 Jul 2003 02:43:42 -0400 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 h6N6gjuG021000; Tue, 22 Jul 2003 23:42:45 -0700 (PDT) Received: from ORANLT.cisco.com (rtp-vpn2-55.cisco.com [10.82.240.55]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGI27773; Tue, 22 Jul 2003 23:42:41 -0700 (PDT) Date: Wed, 23 Jul 2003 02:29:20 -0400 From: "David R. Oran" To: Rohan Mahy , Paul Kyzivat cc: A vWijk , jdrosen@dynamicsoft.com, guido.gybels@rnid.org.uk, sipping@ietf.org, frank.shearar@rnid.org.uk, james.hamlin@rnid.org.uk, mike.spanner@rnid.org.uk Subject: Re: [Sipping] Update to caller preferences use cases Message-ID: <79116373.1058927360@localhost> In-Reply-To: <7AE98505-BC77-11D7-B1E0-0003938AF740@cisco.com> References: <7AE98505-BC77-11D7-B1E0-0003938AF740@cisco.com> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 Tuesday, July 22, 2003 9:05 PM +0200 Rohan Mahy wrote: > > On Wednesday, July 16, 2003, at 02:05 PM, Paul Kyzivat wrote: > >> I think this scenario may be better solved with preconditions - a new >> kind of precondition for an acceptable mix of media being available. > > YUCK. Preconditions is like a strong drug with a lot of negative > side-effects. We should be very careful when prescribing it. I don't > think it is warranted here. I think ordinary offer/answer negotiation can > give us what we need here. > I think I agree with Rohan here. Preconditions are for "Captian Picard" style situations, where you need the endpoints and possibly some elements in the path to "make it so" before the call can proceed. In the case of media mix, it's either available or it isn't and any tuning of the warp engines during call establishment is unlikely to do the trick. Offer-answer will fail and you can try again based on what the answer says is do-able. Dave. > thx, > -r > >> This avoids even alerted called parties if a satisfactory arrangement >> can't be made. This doesn't exclude using callerprefs to help, such as >> in picking the order in which to try devices, but does make it >> secondary. >> >> Today we get away without preconditions on media because generally >> there is only one important medium. Many UAs will fail a call if no >> media are negotiated, effectively implementing a rudimentary form of >> precondition. But that is going to work going forward - there are >> beginning to be interesting call flows that have no media. >> >> So in this case the hearing impared user's UA can first initiate a >> call with precondition for streaming text media. If that succeeds, >> fine. If not, it can try again - setting up a relay and sending a >> voice invite that splices in the relay. >> >> Paul >> >> A vWijk wrote: >>> Jonathan, >>> In this case you are only looking at the relay invocation at the >>> callee's side. >>> Thus the deaf user must always register him or herself at a selected >>> relay service. >>> This solution will surely work, but I am not happy with this >>> registering with the relay itself. It still does not solve incoming >>> relay calls to the exact requirements of the receiving user. >>> About your other suggestion: >>> >> not sure its practical or useful, though, so please comment on that. >>> Consider a caller that is hearing impaired. Before making a call, >>> they contact a relay service. This relay service will receive audio >>> and transform it to streaming text. Of course the caller can also >>> receive streaming text directly from the called party. So, in their >>> invite, they have an m-line for audio, and an m-line for streaming >>> text. They add a caller preference to have their call routed to a >>> device that supports streaming text. In this way, if a called party >>> happens to be able to do both audio on one device, or streaming text >>> on another, the call is routed to the device that can do streaming >>> text. >>> It feels farfetched to me, so please comment. >>> Thanks, >>> Jonathan R.> >>> If I understand this correctly, you state here that receiving >>> streamed text (RFC 2793) can be a caller preference to ensure when a >>> text call is initiated, that the correct terminal is selected. That >>> is a good idea. It gives the users more flexibility. >>> And this allows the user who owns 3 phones, 2 cheap wallmart phones >>> without any screen and keyboard and one normal IP telephone with a >>> screen and keyboard to receive text calls on the right phone. >>> And perhaps also in this way that the user is only logged in a non >>> text terminal, that the relay service or the caller can see that >>> setting up a text call won't work? >>> And that the relay then kicks in and converts audio to text and vice >>> versa. >>> I think that this is indeed useful. This will allow a relay service >>> at least know which kind of media can be sent. E.g a terminal has no >>> video ability but it has text. The relay can fallback to text in that >>> case. Even if the caller uses a video connection and communicates via >>> signlanguage. >>> (or the video caller can also switch to text and skip the relay). >>> This is useful at this level. So, this can be added as an example. It >>> does not offer flexibility of voice carry over or hearing carry over >>> and such. But for the basics it is useful. >>> Greetz >>> Arnoud >>> <<< Jonathan Rosenberg 7/16 8:54a >>> >>> inline. >>> Guido Gybels wrote: >>>> Jonathan: >>>> >>>> <<* added a hearing impaired use case>> >>>> >>>> First of all, I think it is extremely useful to have some use cases >>>> for deaf and hard of hearing people in the draft. Some >>>> comments/questions: >>>> >>>> 1) If I understand the case correctly, the relay service needs to >>>> issue a registration on behalf of the user, indicating that this >>>> registration accepts audio. One of the problems with that scenario >>>> is that this seems to suggest that the user must register through >>>> the relay in order to be able to receive incoming calls. I'm not so >>>> sure how practical that is, especially with regard to roaming users >>>> (how would they discover the relay in the network?). Some thoughts >>>> on this would be welcome. >>> I thought about this use case some more, and I actually concluded >>> that this service is really not a CALLER PREFERENCE service. Its not >>> about the caller preference at all. Its about a routing application >>> on the callee side which sends incoming audio calls to a relay, and >>> incoming messaging calls to a user. Something like that is best >>> implemented through servlets on the callee side, or something. Its >>> not a caller preference at all. So, I would like to remove this case >>> altogether, and find something which is really an example of a caller >>> preference. >>> _______________________________________________ >>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>> This list is for NEW development of the 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 > ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@cisco.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 Jul 23 08:44: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 IAA09888 for ; Wed, 23 Jul 2003 08:44: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 19fIyb-0007Ra-GZ for sipping-archive@odin.ietf.org; Wed, 23 Jul 2003 08:44:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NCiDSp028608 for sipping-archive@odin.ietf.org; Wed, 23 Jul 2003 08: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 19fIyZ-0007RL-U4 for sipping-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 08:44: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 IAA09884 for ; Wed, 23 Jul 2003 08:44:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fIyY-0004HW-00 for sipping-web-archive@ietf.org; Wed, 23 Jul 2003 08:44:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fIyT-0004HT-00 for sipping-web-archive@ietf.org; Wed, 23 Jul 2003 08:44:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fIyP-0007QT-CX; Wed, 23 Jul 2003 08: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 19fIxk-0007Q7-S9 for sipping@optimus.ietf.org; Wed, 23 Jul 2003 08:43: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 IAA09879 for ; Wed, 23 Jul 2003 08:43:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fIxj-0004HO-00 for sipping@ietf.org; Wed, 23 Jul 2003 08:43:19 -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 19fIxY-0004HE-00 for sipping@ietf.org; Wed, 23 Jul 2003 08:43:08 -0400 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 h6NCgFuD024674; Wed, 23 Jul 2003 05:42:15 -0700 (PDT) Received: from cisco.com ([161.44.79.176]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAX24489; Wed, 23 Jul 2003 08:42:01 -0400 (EDT) Message-ID: <3F1E8299.7020905@cisco.com> Date: Wed, 23 Jul 2003 08:42:01 -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: Rohan Mahy CC: Jonathan Rosenberg , sipping Subject: Re: [Sipping] How to report DTMF - conclusion of the app interaction design team: SIP MESSAGE 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 Rohan - see below. Paul Rohan Mahy wrote: > > On Thursday, July 17, 2003, at 02:58 PM, Paul Kyzivat wrote: > >> >> >> Jonathan Rosenberg wrote: >> >>> 7. SIP MESSAGE >>> Send a SIP MESSAGE request from the client to the application, >>> containing the digit sequence to report. >>> This was a bit of a bending of the semantic of MESSAGE, which is >>> really meant for conveying information for display to a user. >>> However, the issue is mostly philosophical in nature. We didnt see >>> any particular technical issue that would prevent this from working, >>> unlike all of the above ones which had technical issues. >> >> >> Adam gave some good examples of bad things that might happen if the >> UAS was confused and attempted to render this to a user. But there are >> mechanisms already in place to deal with this. >> >> For one thing, the application already has an opportunity to pick the >> address to which the MESSAGEs are sent. So it should be able to ensure >> that the recipient knows these messages shouldn't be displayed >> directly to an end-user. >> >> Beyond that, there is the Content-Disposition header, which seems >> intended for purposes like this. In the normal use of MESSAGE for IM, >> the obvious content type is "render". Here we don't want that, so we >> should pick some other content type. > > > Paul, > > small comment here. KPML *is* rendered to the user. The distinction > that you are seeking between "just through this up on the > display/speaker" vs. "interpret this markup and show the result to the > user" does not exist and in fact is the antithesis of the motivation > for the term render. You "render" HTML and XML+XSL and VoiceXML to a > user. KPML should be no different. I think we are talking about different things. AFAIK this discussion is about how the results of processing the KPML are reported back. I agree the KPML is rendered, but the results aren't (at least necessarily) rendered to the requesting application's "user". I don't really see a big problem with using MESSAGE here even without content-disposition, but some people do, so I am proposing a way out of the perceived problem. 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 Wed Jul 23 09:00: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 JAA10450 for ; Wed, 23 Jul 2003 09:00: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 19fJE8-00083b-VA for sipping-archive@odin.ietf.org; Wed, 23 Jul 2003 09:00:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ND0Ghx030971 for sipping-archive@odin.ietf.org; Wed, 23 Jul 2003 09:00:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJE8-00083S-Ou for sipping-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 09:00: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 JAA10368 for ; Wed, 23 Jul 2003 09:00:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fJE7-0004NS-00 for sipping-web-archive@ietf.org; Wed, 23 Jul 2003 09:00:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fJDt-0004N3-00 for sipping-web-archive@ietf.org; Wed, 23 Jul 2003 09:00:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJDt-0007y3-Lw; Wed, 23 Jul 2003 09: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 19fJDi-0007x7-2k for sipping@optimus.ietf.org; Wed, 23 Jul 2003 08:59: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 IAA10293 for ; Wed, 23 Jul 2003 08:59:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fJDg-0004MJ-00 for sipping@ietf.org; Wed, 23 Jul 2003 08:59:48 -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 19fJDV-0004Lj-00 for sipping@ietf.org; Wed, 23 Jul 2003 08:59:37 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 23 Jul 2003 06:00:06 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6NCwvuG007618; Wed, 23 Jul 2003 05:58:58 -0700 (PDT) Received: from cisco.com ([161.44.79.176]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAX25574; Wed, 23 Jul 2003 08:58:56 -0400 (EDT) Message-ID: <3F1E8690.2050400@cisco.com> Date: Wed, 23 Jul 2003 08:58:56 -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: "David R. Oran" CC: Rohan Mahy , A vWijk , jdrosen@dynamicsoft.com, guido.gybels@rnid.org.uk, sipping@ietf.org, frank.shearar@rnid.org.uk, james.hamlin@rnid.org.uk, mike.spanner@rnid.org.uk Subject: Re: [Sipping] Update to caller preferences use cases References: <7AE98505-BC77-11D7-B1E0-0003938AF740@cisco.com> <79116373.1058927360@localhost> 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 If you can rely on a UAS refusing a call without alerting when none of the offered media match then I agree you can do these cases decently without preconditions. I'm not sure that is a reasonable assumption. Certainly there are now call flows that start out with a no-media offer, so UAS's should accept those. And a UAS that is offered multiple media is generally expected to accept the subset it supports. The logical conclusion is that a UAS should accept a call even if the supported subset of media is null. I think this means the callee is then alerted. If a caller wants to try an easy case, (e.g. end-end text), and then if that fails try a harder approach (e.g. allocate a relay and invite for voice thru the relay), then it needs a way to get the first attempt to terminate without alerting. I realize preconditions are strong medicine, but they are the only obvious way to avoid alerting. Some more specification around what UASs should do about alerting and accepting/rejecting calls in these fringe cases would help in deciding if simple techniques can be used reliably. Paul David R. Oran wrote: > --On Tuesday, July 22, 2003 9:05 PM +0200 Rohan Mahy > wrote: > >> >> On Wednesday, July 16, 2003, at 02:05 PM, Paul Kyzivat wrote: >> >>> I think this scenario may be better solved with preconditions - a new >>> kind of precondition for an acceptable mix of media being available. >> >> >> YUCK. Preconditions is like a strong drug with a lot of negative >> side-effects. We should be very careful when prescribing it. I don't >> think it is warranted here. I think ordinary offer/answer negotiation can >> give us what we need here. >> > I think I agree with Rohan here. Preconditions are for "Captian Picard" > style situations, where you need the endpoints and possibly some > elements in the path to "make it so" before the call can proceed. In the > case of media mix, it's either available or it isn't and any tuning of > the warp engines during call establishment is unlikely to do the trick. > Offer-answer will fail and you can try again based on what the answer > says is do-able. > > Dave. > >> thx, >> -r >> >>> This avoids even alerted called parties if a satisfactory arrangement >>> can't be made. This doesn't exclude using callerprefs to help, such as >>> in picking the order in which to try devices, but does make it >>> secondary. >>> >>> Today we get away without preconditions on media because generally >>> there is only one important medium. Many UAs will fail a call if no >>> media are negotiated, effectively implementing a rudimentary form of >>> precondition. But that is going to work going forward - there are >>> beginning to be interesting call flows that have no media. >>> >>> So in this case the hearing impared user's UA can first initiate a >>> call with precondition for streaming text media. If that succeeds, >>> fine. If not, it can try again - setting up a relay and sending a >>> voice invite that splices in the relay. >>> >>> Paul >>> >>> A vWijk wrote: >>> >>>> Jonathan, >>>> In this case you are only looking at the relay invocation at the >>>> callee's side. >>>> Thus the deaf user must always register him or herself at a selected >>>> relay service. >>>> This solution will surely work, but I am not happy with this >>>> registering with the relay itself. It still does not solve incoming >>>> relay calls to the exact requirements of the receiving user. >>>> About your other suggestion: >>>> >>> not sure its practical or useful, though, so please comment on that. >>>> Consider a caller that is hearing impaired. Before making a call, >>>> they contact a relay service. This relay service will receive audio >>>> and transform it to streaming text. Of course the caller can also >>>> receive streaming text directly from the called party. So, in their >>>> invite, they have an m-line for audio, and an m-line for streaming >>>> text. They add a caller preference to have their call routed to a >>>> device that supports streaming text. In this way, if a called party >>>> happens to be able to do both audio on one device, or streaming text >>>> on another, the call is routed to the device that can do streaming >>>> text. >>>> It feels farfetched to me, so please comment. >>>> Thanks, >>>> Jonathan R.> >>>> If I understand this correctly, you state here that receiving >>>> streamed text (RFC 2793) can be a caller preference to ensure when a >>>> text call is initiated, that the correct terminal is selected. That >>>> is a good idea. It gives the users more flexibility. >>>> And this allows the user who owns 3 phones, 2 cheap wallmart phones >>>> without any screen and keyboard and one normal IP telephone with a >>>> screen and keyboard to receive text calls on the right phone. >>>> And perhaps also in this way that the user is only logged in a non >>>> text terminal, that the relay service or the caller can see that >>>> setting up a text call won't work? >>>> And that the relay then kicks in and converts audio to text and vice >>>> versa. >>>> I think that this is indeed useful. This will allow a relay service >>>> at least know which kind of media can be sent. E.g a terminal has no >>>> video ability but it has text. The relay can fallback to text in that >>>> case. Even if the caller uses a video connection and communicates via >>>> signlanguage. >>>> (or the video caller can also switch to text and skip the relay). >>>> This is useful at this level. So, this can be added as an example. It >>>> does not offer flexibility of voice carry over or hearing carry over >>>> and such. But for the basics it is useful. >>>> Greetz >>>> Arnoud >>>> <<< Jonathan Rosenberg 7/16 8:54a >>> >>>> inline. >>>> Guido Gybels wrote: >>>> >>>>> Jonathan: >>>>> >>>>> <<* added a hearing impaired use case>> >>>>> >>>>> First of all, I think it is extremely useful to have some use cases >>>>> for deaf and hard of hearing people in the draft. Some >>>>> comments/questions: >>>>> >>>>> 1) If I understand the case correctly, the relay service needs to >>>>> issue a registration on behalf of the user, indicating that this >>>>> registration accepts audio. One of the problems with that scenario >>>>> is that this seems to suggest that the user must register through >>>>> the relay in order to be able to receive incoming calls. I'm not so >>>>> sure how practical that is, especially with regard to roaming users >>>>> (how would they discover the relay in the network?). Some thoughts >>>>> on this would be welcome. >>>> >>>> I thought about this use case some more, and I actually concluded >>>> that this service is really not a CALLER PREFERENCE service. Its not >>>> about the caller preference at all. Its about a routing application >>>> on the callee side which sends incoming audio calls to a relay, and >>>> incoming messaging calls to a user. Something like that is best >>>> implemented through servlets on the callee side, or something. Its >>>> not a caller preference at all. So, I would like to remove this case >>>> altogether, and find something which is really an example of a caller >>>> preference. >>>> _______________________________________________ >>>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>>> This list is for NEW development of the 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 >> > > > > ------------------------ > David R. Oran > Cisco Systems > 7 Ladyslipper Lane > Acton, MA 01720 > Office: +1 978 264 2048 > VoIP: +1 408 571 4576 > Email: oran@cisco.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 Jul 23 09:05: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 JAA10719 for ; Wed, 23 Jul 2003 09:05: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 19fJIq-0008UE-Mj for sipping-archive@odin.ietf.org; Wed, 23 Jul 2003 09:05:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ND58mi032616 for sipping-archive@odin.ietf.org; Wed, 23 Jul 2003 09:05:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJIq-0008To-JB for sipping-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 09:05: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 JAA10702 for ; Wed, 23 Jul 2003 09:05:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fJIp-0004Rw-00 for sipping-web-archive@ietf.org; Wed, 23 Jul 2003 09:05:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fJIj-0004Rt-00 for sipping-web-archive@ietf.org; Wed, 23 Jul 2003 09:05:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJIj-0008Pa-RF; Wed, 23 Jul 2003 09: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 19fJI1-0008Os-RT for sipping@optimus.ietf.org; Wed, 23 Jul 2003 09: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 JAA10688 for ; Wed, 23 Jul 2003 09:04:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fJI0-0004Ri-00 for sipping@ietf.org; Wed, 23 Jul 2003 09:04:16 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19fJHp-0004Rf-00 for sipping@ietf.org; Wed, 23 Jul 2003 09:04:05 -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; Wed, 23 Jul 2003 14:06:43 +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] How to report DTMF - conclusion of the app interaction design team: SIP MESSAGE Date: Wed, 23 Jul 2003 14:02:45 +0100 Message-ID: <45730E094814E44488F789C1CDED27AE0219B04C@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Sipping] How to report DTMF - conclusion of the app interaction design team: SIP MESSAGE Thread-Index: AcNRF+68DvouNfLQShKVjrFxsqxhIwAAiyLA From: "Chris Boulton" To: "Paul Kyzivat" , "Rohan Mahy" Cc: "Jonathan Rosenberg" , "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 I don't really see this as a major problem either BUT I still don't like the fact that we are 'bending' the use of MESSAGE in the first place. By defining a new METHOD, all of these discussions go away. Chris. >-----Original Message----- >From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >Sent: 23 July 2003 13:42 >To: Rohan Mahy >Cc: Jonathan Rosenberg; sipping >Subject: Re: [Sipping] How to report DTMF - conclusion of the app >interaction design team: SIP MESSAGE > >Rohan - see below. > > Paul > >Rohan Mahy wrote: >> >> On Thursday, July 17, 2003, at 02:58 PM, Paul Kyzivat wrote: >> >>> >>> >>> Jonathan Rosenberg wrote: >>> >>>> 7. SIP MESSAGE >>>> Send a SIP MESSAGE request from the client to the application, >>>> containing the digit sequence to report. >>>> This was a bit of a bending of the semantic of MESSAGE, which is >>>> really meant for conveying information for display to a user. >>>> However, the issue is mostly philosophical in nature. We didnt see >>>> any particular technical issue that would prevent this from working, >>>> unlike all of the above ones which had technical issues. >>> >>> >>> Adam gave some good examples of bad things that might happen if the >>> UAS was confused and attempted to render this to a user. But there are >>> mechanisms already in place to deal with this. >>> >>> For one thing, the application already has an opportunity to pick the >>> address to which the MESSAGEs are sent. So it should be able to ensure >>> that the recipient knows these messages shouldn't be displayed >>> directly to an end-user. >>> >>> Beyond that, there is the Content-Disposition header, which seems >>> intended for purposes like this. In the normal use of MESSAGE for IM, >>> the obvious content type is "render". Here we don't want that, so we >>> should pick some other content type. >> >> >> Paul, >> >> small comment here. KPML *is* rendered to the user. The distinction >> that you are seeking between "just through this up on the >> display/speaker" vs. "interpret this markup and show the result to the >> user" does not exist and in fact is the antithesis of the motivation >> for the term render. You "render" HTML and XML+XSL and VoiceXML to a >> user. KPML should be no different. > >I think we are talking about different things. AFAIK this discussion is >about how the results of processing the KPML are reported back. I agree >the KPML is rendered, but the results aren't (at least necessarily) >rendered to the requesting application's "user". > >I don't really see a big problem with using MESSAGE here even without >content-disposition, but some people do, so I am proposing a way out of >the perceived problem. > > Paul > > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Jul 23 09:55: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 JAA12855 for ; Wed, 23 Jul 2003 09:55: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 19fK5H-0002b7-Fz for sipping-archive@odin.ietf.org; Wed, 23 Jul 2003 09:55:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NDtBtG009979 for sipping-archive@odin.ietf.org; Wed, 23 Jul 2003 09:55:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fK5H-0002as-Bg for sipping-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 09:55: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 JAA12851 for ; Wed, 23 Jul 2003 09:55:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fK5F-0004qj-00 for sipping-web-archive@ietf.org; Wed, 23 Jul 2003 09:55:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fK59-0004qg-00 for sipping-web-archive@ietf.org; Wed, 23 Jul 2003 09:55:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fK58-0002Y7-10; Wed, 23 Jul 2003 09:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fK4W-0002Vr-Aa for sipping@optimus.ietf.org; Wed, 23 Jul 2003 09:54: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 JAA12842 for ; Wed, 23 Jul 2003 09:54:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fK4U-0004qS-00 for sipping@ietf.org; Wed, 23 Jul 2003 09:54:22 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19fK4J-0004qI-00 for sipping@ietf.org; Wed, 23 Jul 2003 09:54:11 -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 h6NDrGiJ015732 for ; Wed, 23 Jul 2003 09:53:16 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jul 2003 08:53:16 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86234@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: sipping Date: Wed, 23 Jul 2003 08:53:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] DTMF: Why Not A New Method? Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Chris Boulton writes: > By defining a new METHOD, all of these discussions go away. Excellent point. I have raised some very concrete and technical problems with the use of both implicit subscriptions and MESSAGE. The sole expressed objection to using a new method has been a rather indistinct and wishy-washy, "that seems too specialized." Can anyone express something more than an extremely vague sense of unease with using a new method? If not, can we *please* move along in the most obvious direction which has no outstanding technical objections? /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 Jul 23 10:21: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 KAA14733 for ; Wed, 23 Jul 2003 10:21: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 19fKUQ-00046H-Ti for sipping-archive@odin.ietf.org; Wed, 23 Jul 2003 10:21:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NELAqv015757 for sipping-archive@odin.ietf.org; Wed, 23 Jul 2003 10:21:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKUQ-000464-Qt for sipping-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 10:21: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 KAA14710 for ; Wed, 23 Jul 2003 10:21:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fKUO-00050y-00 for sipping-web-archive@ietf.org; Wed, 23 Jul 2003 10:21:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fKUI-00050v-00 for sipping-web-archive@ietf.org; Wed, 23 Jul 2003 10:21:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKUI-00042i-7O; Wed, 23 Jul 2003 10:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKTz-00042F-NK for sipping@optimus.ietf.org; Wed, 23 Jul 2003 10:20: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 KAA14695 for ; Wed, 23 Jul 2003 10:20:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fKTx-00050a-00 for sipping@ietf.org; Wed, 23 Jul 2003 10:20:41 -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 19fKTm-0004zt-00 for sipping@ietf.org; Wed, 23 Jul 2003 10:20:30 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 23 Jul 2003 07:25:43 -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 h6NEJB89023047; Wed, 23 Jul 2003 07:19:11 -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 AJM80401; Wed, 23 Jul 2003 07:15:10 -0700 (PDT) Date: Wed, 23 Jul 2003 16:21:19 +0200 Subject: Re: [Sipping] Re: Comments on draft-ietf-sipping-cc-conferencing-01 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Alan Johnston , Eric Burger , sipping To: Michael Hammer From: Rohan Mahy In-Reply-To: <4.3.2.7.2.20030717113237.00b1fee0@cia.cisco.com> Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) 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 Concealing the fact that you are in a conference does not meet the=20 IETF-definition of wiretapping, as one of the parties on the=20 communication is aware of what is going on. Please, see my=20 discussion on this in the Join draft (snippet provided below). thanks, -rohan This primitive can be used to create services which are used for=20 monitoring purposes, however these services do not meet the definition=20= of a wiretap according to RFC2804[14]. The definition from RFC2804 is=20 included here: Wiretapping is what occurs when information passed across the Internet from one party to one or more other parties is delivered to a third party: 1. Without the sending party knowing about the third party 2. Without any of the recipient parties knowing about the delivery to the third party 3. When the normal expectation of the sender is that the transmitted information will only be seen by the recipient parties or parties obliged to keep the information in confidence 4. When the third party acts deliberately to target the transmission of the first party, either because he is of interest, or because the second party's reception is of interest. Specifically, item 2 of this definition does not apply to this=20 extension, as one party is always aware of a Join request and can even=20= decline such requests. In addition, in many applications of this=20 primitive, some or all of the other items may not apply. For example,=20 in many call centers which handle financial transactions, all=20 conversations are recorded with the full knowledge and expectation of=20 all parties involved. On Thursday, July 17, 2003, at 05:36 PM, Michael Hammer wrote: > At 01:51 PM 7/16/2003 -0500, Alan Johnston wrote: > > Section 4.2: > How else, in the SIP world, would a focus bring a user agent into the=20= > conference other than by INVITE?=A0 Maybe the SHOULD here is the=20 > inclusion of the ;isfocus parameter.=A0 That said, why is it not MUST? > > > Yes, the SHOULD relates to the isfocus parameter.=A0 It is not a MUST=20= > because a focus may wish to conceal the fact that it is a focus. > > > Some places have requirements that a participant in a call be notified=20= > if there are others eavesdropping on the call.=A0 This strikes me as a=20= > form of wire-tapping.=A0 Could you elaborate on why a focus would want=20= > to conceal that fact? > > Mike _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 24 13:11: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 NAA16023 for ; Thu, 24 Jul 2003 13:11: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 19fjc8-00010t-Ap for sipping-archive@odin.ietf.org; Thu, 24 Jul 2003 13:10:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OHAmkt003889 for sipping-archive@odin.ietf.org; Thu, 24 Jul 2003 13:10:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fjc8-00010e-6q for sipping-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 13:10:48 -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 NAA16004 for ; Thu, 24 Jul 2003 13:10: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 19fjbO-0000xv-Gp; Thu, 24 Jul 2003 13: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 19fjaV-0000vy-MO for sipping@optimus.ietf.org; Thu, 24 Jul 2003 13:09: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 NAA15923 for ; Thu, 24 Jul 2003 13:09:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fjaT-0007ji-00 for sipping@ietf.org; Thu, 24 Jul 2003 13:09:05 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19fjaJ-0007h5-00 for sipping@ietf.org; Thu, 24 Jul 2003 13:08: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 h6OH67iJ019933 for ; Thu, 24 Jul 2003 13:06:07 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jul 2003 12:06:05 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E8624D@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'sipping@ietf.org'" Cc: Jonathan Rosenberg Date: Thu, 24 Jul 2003 12:06: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] Comment on GRUU requirements Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , While thinking about some of the applications for which GRUUs would be useful, it occurred to me that many of them work (or at least, work better) if a GRUU can be identified as such by simple examination. For example, let's say I send an INVITE message and receive a 200 response containing: Contact: If I want to be able to send an out-of-dialog request that I want to go to the same device that my INVITE went to, I don't know whether I can do so. On the other hand, if I can look for a URI parameter that indicates that the URI has GRUU properties: Contact: ...then I *know* that sending a request to it will arrive at the appropriate device, even if it's not in the same dialog. I would like to see a requirement added along the lines of: REQ xx: It must be possible for any recipient of a URI to determine by examination whether it is a GRUU. /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 Jul 24 16:14:55 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 QAA28216 for ; Thu, 24 Jul 2003 16:14:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fmTs-0001kj-TG for sipping-archive@odin.ietf.org; Thu, 24 Jul 2003 16:14:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OKESlM006736 for sipping-archive@odin.ietf.org; Thu, 24 Jul 2003 16:14:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fmTs-0001kZ-PV for sipping-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 16:14: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 QAA28201 for ; Thu, 24 Jul 2003 16:14:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fmTq-0001m0-00 for sipping-web-archive@ietf.org; Thu, 24 Jul 2003 16:14:27 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fmTl-0001lw-00 for sipping-web-archive@ietf.org; Thu, 24 Jul 2003 16:14:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fmTR-0001jY-OO; Thu, 24 Jul 2003 16: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 19fmSe-0001iO-Hu for sipping@optimus.ietf.org; Thu, 24 Jul 2003 16:13: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 QAA28164 for ; Thu, 24 Jul 2003 16:13:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fmSc-0001lp-00 for sipping@ietf.org; Thu, 24 Jul 2003 16:13:10 -0400 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx with esmtp (Exim 4.12) id 19fmSR-0001lm-00 for sipping@ietf.org; Thu, 24 Jul 2003 16:12:59 -0400 Received: from zcard307.ca.nortel.com (americasm07.nt.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6OKC2P26882; Thu, 24 Jul 2003 16:12:02 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PFQ8H5DT; Thu, 24 Jul 2003 16:12:02 -0400 Received: from nortelnetworks.com (acart1cb.ca.nortel.com [47.129.129.54]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3RVWPG5H; Thu, 24 Jul 2003 16:12:02 -0400 Message-ID: <3F203D8D.6070203@nortelnetworks.com> Date: Thu, 24 Jul 2003 16:11:57 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Stupka Jean-Marie CC: "Poetzl, Joachim" , sipping@ietf.org Subject: Re: ... [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 Just to be absolutely clear here: what Rohan is saying is that activation of the ACB service at the UAC is an user interface issue. For instance, I can imagine a feature button labelled "Camp-on", if I have the right term. The action taken by the user terminal when the feature button is pressed (according to the application logic programmed into it) is to issue a SUBSCRIBE for state to the last address called. This is strictly a matter of user terminal design, which might be standardized by the TIA, but certainly not by the IETF. What is susceptible of standardization is what happens at a gateway when it receives such a SUBSCRIBE request. This has to be interworked to the IN on the PSTN side. It seems likely you would pursue this aspect in the ITU-T rather than in SIPPING. 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 > > > > [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 Thu Jul 24 16:24: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 QAA28621 for ; Thu, 24 Jul 2003 16:24: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 19fmdH-0002QZ-6y for sipping-archive@odin.ietf.org; Thu, 24 Jul 2003 16:24:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OKOBAD009325 for sipping-archive@odin.ietf.org; Thu, 24 Jul 2003 16:24:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fmdH-0002QJ-2E for sipping-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 16:24: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 QAA28600 for ; Thu, 24 Jul 2003 16:24:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fmdF-0001sJ-00 for sipping-web-archive@ietf.org; Thu, 24 Jul 2003 16:24:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fmd9-0001sD-00 for sipping-web-archive@ietf.org; Thu, 24 Jul 2003 16:24:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fmd7-0002Jt-BT; Thu, 24 Jul 2003 16: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 19fmc8-0002Ho-N6 for sipping@optimus.ietf.org; Thu, 24 Jul 2003 16: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 QAA28518 for ; Thu, 24 Jul 2003 16:22:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fmc6-0001rP-00 for sipping@ietf.org; Thu, 24 Jul 2003 16:22:58 -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 19fmbw-0001nw-00 for sipping@ietf.org; Thu, 24 Jul 2003 16:22:48 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6OKIb89026572; Thu, 24 Jul 2003 13:18:37 -0700 (PDT) Received: from cisco.com ([161.44.79.176]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAY64957; Thu, 24 Jul 2003 16:18:35 -0400 (EDT) Message-ID: <3F203F1B.3010702@cisco.com> Date: Thu, 24 Jul 2003 16:18:35 -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: Adam Roach CC: sipping Subject: Re: [Sipping] DTMF: Why Not A New Method? References: <9BF66EBF6BEFD942915B4D4D45C051F3E86234@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: > Chris Boulton writes: > >>By defining a new METHOD, all of these discussions go away. > > > Excellent point. > > I have raised some very concrete and technical problems with the > use of both implicit subscriptions and MESSAGE. > > The sole expressed objection to using a new method has been a > rather indistinct and wishy-washy, "that seems too specialized." > > Can anyone express something more than an extremely vague > sense of unease with using a new method? > > If not, can we *please* move along in the most obvious direction > which has no outstanding technical objections? I have no technical objections to this. IMO it is as if we have a truck for carrying apples, and have decided we need a different truck to carry oranges. 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 Thu Jul 24 16:24: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 QAA28622 for ; Thu, 24 Jul 2003 16:24: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 19fmdH-0002Qo-9L for sipping-archive@odin.ietf.org; Thu, 24 Jul 2003 16:24:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OKOBCJ009340 for sipping-archive@odin.ietf.org; Thu, 24 Jul 2003 16:24:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fmdH-0002QK-4e for sipping-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 16:24: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 QAA28602 for ; Thu, 24 Jul 2003 16:24:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fmdF-0001sG-00 for sipping-web-archive@ietf.org; Thu, 24 Jul 2003 16:24:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fmd9-0001sC-00 for sipping-web-archive@ietf.org; Thu, 24 Jul 2003 16:24:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fmd8-0002K6-6T; Thu, 24 Jul 2003 16:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fmct-0002JU-76 for sipping@optimus.ietf.org; Thu, 24 Jul 2003 16:23: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 QAA28573 for ; Thu, 24 Jul 2003 16:23:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fmcr-0001rv-00 for sipping@ietf.org; Thu, 24 Jul 2003 16:23:45 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19fmcf-0001r9-00 for sipping@ietf.org; Thu, 24 Jul 2003 16:23:34 -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 h6OKMFiJ020412; Thu, 24 Jul 2003 16:22:15 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jul 2003 15:22:13 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86255@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Paul Kyzivat'" , Adam Roach Cc: sipping Subject: RE: [Sipping] DTMF: Why Not A New Method? Date: Thu, 24 Jul 2003 15:22: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: , Paul Kyzivat [mailto:pkyzivat@cisco.com] writes: > Adam Roach wrote: > > Can anyone express something more than an extremely vague > > sense of unease with using a new method? > > > > If not, can we *please* move along in the most obvious direction > > which has no outstanding technical objections? > > I have no technical objections to this. Good. Anyone else? /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 Jul 24 16:27: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 QAA28793 for ; Thu, 24 Jul 2003 16:27: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 19fmg9-0002kJ-Fd for sipping-archive@odin.ietf.org; Thu, 24 Jul 2003 16:27:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OKR9li010549 for sipping-archive@odin.ietf.org; Thu, 24 Jul 2003 16:27:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fmg8-0002k4-VC for sipping-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 16:27: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 QAA28777 for ; Thu, 24 Jul 2003 16:27:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fmg6-0001ud-00 for sipping-web-archive@ietf.org; Thu, 24 Jul 2003 16:27:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fmg1-0001ua-00 for sipping-web-archive@ietf.org; Thu, 24 Jul 2003 16:27:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fmg2-0002gt-1S; Thu, 24 Jul 2003 16:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fmfP-0002gW-V5 for sipping@optimus.ietf.org; Thu, 24 Jul 2003 16:26: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 QAA28729 for ; Thu, 24 Jul 2003 16:26:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fmfO-0001td-00 for sipping@ietf.org; Thu, 24 Jul 2003 16:26:22 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19fmfC-0001tW-00 for sipping@ietf.org; Thu, 24 Jul 2003 16:26: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 h6OKPRiJ020428; Thu, 24 Jul 2003 16:25:27 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jul 2003 15:25:25 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86256@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Paul Kyzivat'" , Adam Roach Cc: sipping Subject: RE: [Sipping] DTMF: Why Not A New Method? Date: Thu, 24 Jul 2003 15:25:24 -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: , > IMO it is as if we have a truck for carrying apples, and have > decided we need a different truck to carry oranges. The point that I have been trying to make is that your truck re-use scheme is just great until someone tries to back an apple truck full of oranges up to an applesauce factory, and everyone is left wondering why the applesauce is all runny, bitter, stringy and orange this time around. /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 Jul 24 16:38: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 QAA29399 for ; Thu, 24 Jul 2003 16:38: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 19fmqp-0003Yu-9v for sipping-archive@odin.ietf.org; Thu, 24 Jul 2003 16:38:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OKcB2K013688 for sipping-archive@odin.ietf.org; Thu, 24 Jul 2003 16:38:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fmqp-0003Yh-6B for sipping-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 16:38: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 QAA29319 for ; Thu, 24 Jul 2003 16:38:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fmqn-0001zu-00 for sipping-web-archive@ietf.org; Thu, 24 Jul 2003 16:38:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fmqh-0001zr-00 for sipping-web-archive@ietf.org; Thu, 24 Jul 2003 16:38:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fmqf-0003W9-AJ; Thu, 24 Jul 2003 16:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fmq9-0003Oo-1P for sipping@optimus.ietf.org; Thu, 24 Jul 2003 16:37: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 QAA29262 for ; Thu, 24 Jul 2003 16:37:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fmq6-0001zZ-00 for sipping@ietf.org; Thu, 24 Jul 2003 16:37:27 -0400 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 19fmpw-0001z1-00 for sipping@ietf.org; Thu, 24 Jul 2003 16:37:16 -0400 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 26094; Thu, 24 Jul 2003 16:35:34 -0400 (EDT) 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: Thu, 24 Jul 2003 16:36:24 -0400 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F65F2@zoe.office.snowshore.com> Thread-Topic: [Sipping] DTMF: Why Not A New Method? Thread-Index: AcNRIhAazihDSKw5Shy0aFau5EnCHQA3+50w From: "Eric Burger" To: "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 As promised in Vienna, a draft will be forthcoming. With text, people = can pick out what's good or bad... > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Wed, July 23, 2003 9:53 AM > To: sipping > Subject: [Sipping] DTMF: Why Not A New Method? >=20 >=20 > Chris Boulton writes: > > By defining a new METHOD, all of these discussions go away. >=20 > Excellent point. >=20 > I have raised some very concrete and technical problems with the > use of both implicit subscriptions and MESSAGE. >=20 > The sole expressed objection to using a new method has been a > rather indistinct and wishy-washy, "that seems too specialized." >=20 > Can anyone express something more than an extremely vague > sense of unease with using a new method? >=20 > If not, can we *please* move along in the most obvious direction > which has no outstanding technical objections? >=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 From exim@www1.ietf.org Thu Jul 24 16:40: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 QAA29499 for ; Thu, 24 Jul 2003 16:40: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 19fmsk-0003nj-7q for sipping-archive@odin.ietf.org; Thu, 24 Jul 2003 16:40:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OKeAud014611 for sipping-archive@odin.ietf.org; Thu, 24 Jul 2003 16:40:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fmsj-0003na-UL for sipping-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 16: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 QAA29470 for ; Thu, 24 Jul 2003 16:40:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fmsh-00021t-00 for sipping-web-archive@ietf.org; Thu, 24 Jul 2003 16:40:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fmsb-00021n-00 for sipping-web-archive@ietf.org; Thu, 24 Jul 2003 16:40:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fmsc-0003kB-9w; Thu, 24 Jul 2003 16: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 19fmsP-0003jb-31 for sipping@optimus.ietf.org; Thu, 24 Jul 2003 16:39: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 QAA29461 for ; Thu, 24 Jul 2003 16:39:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fmsN-00021V-00 for sipping@ietf.org; Thu, 24 Jul 2003 16:39:47 -0400 Received: from [204.57.52.4] (helo=commserver.iperia.com) by ietf-mx with esmtp (Exim 4.12) id 19fmsC-00020o-00 for sipping@ietf.org; Thu, 24 Jul 2003 16:39:36 -0400 Received: by COMMSERVER with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jul 2003 16:38:29 -0400 Message-ID: <1A69639B9B6AD511812B00B0D0DE19F60A3E99@COMMSERVER> From: Gordon Ledgard To: "'Adam Roach'" , "'Paul Kyzivat'" Cc: sipping Subject: RE: [Sipping] DTMF: Why Not A New Method? Date: Thu, 24 Jul 2003 16:38:24 -0400 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: , Lest we get lost in the metaphors, the real questions are these: 1) Is there something wrong with the Subscribe/Notify methodology that makes DTMF difficult or impossible? 2) Is there a way to solve the problems presented by S/N by using a new method, or are the problems inherent in the protocol? If the answer to 2) is "yes" then a new method is warranted. If the anwer to 2) is "no", you are just making another truck with the same problems as the old truck. Gordon -----Original Message----- From: Adam Roach [mailto:adam@dynamicsoft.com] Sent: Thursday, July 24, 2003 4:25 PM To: 'Paul Kyzivat'; Adam Roach Cc: sipping Subject: RE: [Sipping] DTMF: Why Not A New Method? > IMO it is as if we have a truck for carrying apples, and have > decided we need a different truck to carry oranges. The point that I have been trying to make is that your truck re-use scheme is just great until someone tries to back an apple truck full of oranges up to an applesauce factory, and everyone is left wondering why the applesauce is all runny, bitter, stringy and orange this time around. /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 Jul 24 16:41: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 QAA29561 for ; Thu, 24 Jul 2003 16:41: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 19fmtg-00042j-59 for sipping-archive@odin.ietf.org; Thu, 24 Jul 2003 16:41:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OKf8wE015535 for sipping-archive@odin.ietf.org; Thu, 24 Jul 2003 16:41:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fmtg-00042U-1Y for sipping-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 16:41: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 QAA29537 for ; Thu, 24 Jul 2003 16:41:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fmtd-00022p-00 for sipping-web-archive@ietf.org; Thu, 24 Jul 2003 16:41:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fmtY-00022m-00 for sipping-web-archive@ietf.org; Thu, 24 Jul 2003 16: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 19fmtZ-0003uA-9V; Thu, 24 Jul 2003 16: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 19fmsj-0003nV-Pi for sipping@optimus.ietf.org; Thu, 24 Jul 2003 16: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 QAA29469 for ; Thu, 24 Jul 2003 16:40:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fmsh-00021e-00 for sipping@ietf.org; Thu, 24 Jul 2003 16:40:07 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19fmsW-000217-00 for sipping@ietf.org; Thu, 24 Jul 2003 16:39:56 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6OKcEpr019010; Thu, 24 Jul 2003 13:38:17 -0700 (PDT) Received: from cisco.com ([161.44.79.176]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAY67085; Thu, 24 Jul 2003 16:38:13 -0400 (EDT) Message-ID: <3F2043B4.1030306@cisco.com> Date: Thu, 24 Jul 2003 16:38:12 -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: Adam Roach CC: sipping Subject: Re: [Sipping] DTMF: Why Not A New Method? References: <9BF66EBF6BEFD942915B4D4D45C051F3E86256@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 Well, in my trucking company we don't just leave loaded trucks sitting around for people to take where they will. Instead, we take orders for trucks of apples or oranges, and we deliver them to where the order said to deliver them. And we include a packing slip saying what is contained. If the acme fruit packing company orders oranges from me, and I deliver them, with a packing slip that says oranges, then the acme people should know not to make applesauce out of them, even if I send the same truck that sometimes delivers apples. Paul Adam Roach wrote: >>IMO it is as if we have a truck for carrying apples, and have >>decided we need a different truck to carry oranges. > > > The point that I have been trying to make is that your truck > re-use scheme is just great until someone tries to back an > apple truck full of oranges up to an applesauce factory, and > everyone is left wondering why the applesauce is all runny, > bitter, stringy and orange this time around. > > /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 Jul 24 16:41: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 QAA29576 for ; Thu, 24 Jul 2003 16:41: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 19fmth-00046N-PH for sipping-archive@odin.ietf.org; Thu, 24 Jul 2003 16:41:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OKf9mF015751 for sipping-archive@odin.ietf.org; Thu, 24 Jul 2003 16:41:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fmth-00045B-Hc for sipping-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 16:41: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 QAA29541 for ; Thu, 24 Jul 2003 16:41:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fmtf-00022u-00 for sipping-web-archive@ietf.org; Thu, 24 Jul 2003 16:41:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fmtZ-00022q-00 for sipping-web-archive@ietf.org; Thu, 24 Jul 2003 16: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 19fmta-0003zY-EH; Thu, 24 Jul 2003 16:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fmtO-0003te-J3 for sipping@optimus.ietf.org; Thu, 24 Jul 2003 16:40: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 QAA29522 for ; Thu, 24 Jul 2003 16:40:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fmtM-00022T-00 for sipping@ietf.org; Thu, 24 Jul 2003 16:40:48 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19fmtB-00021W-00 for sipping@ietf.org; Thu, 24 Jul 2003 16:40:37 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6OKdFX26894; Thu, 24 Jul 2003 15:39:16 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <301T5RVP>; Thu, 24 Jul 2003 15:39:16 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF578AE3@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Adam Roach'" , "'Paul Kyzivat'" Cc: sipping Subject: RE: [Sipping] DTMF: Why Not A New Method? Date: Thu, 24 Jul 2003 15:39:15 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , I fully agree with Adam. Reusing MESSAGE just opens the door for other uses in this gray zone and introduces the potential for other "misuses". The reuse of MESSAGE creates a situation much like that which currently exists with INFO. I find this particularly ironic given that this solution is intended to replace all the exisiting and differing proprietary mechanisms for DTMF based on INFO. Mary. -----Original Message----- From: Adam Roach [mailto:adam@dynamicsoft.com] Sent: Thursday, July 24, 2003 3:25 PM To: 'Paul Kyzivat'; Adam Roach Cc: sipping Subject: RE: [Sipping] DTMF: Why Not A New Method? > IMO it is as if we have a truck for carrying apples, and have > decided we need a different truck to carry oranges. The point that I have been trying to make is that your truck re-use scheme is just great until someone tries to back an apple truck full of oranges up to an applesauce factory, and everyone is left wondering why the applesauce is all runny, bitter, stringy and orange this time around. /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 Jul 24 16:44: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 QAA29698 for ; Thu, 24 Jul 2003 16:44: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 19fmwb-0004N0-O3 for sipping-archive@odin.ietf.org; Thu, 24 Jul 2003 16:44:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OKi9EC016799 for sipping-archive@odin.ietf.org; Thu, 24 Jul 2003 16: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 19fmwb-0004Ms-2O for sipping-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 16: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 QAA29660 for ; Thu, 24 Jul 2003 16:44:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fmwY-00025D-00 for sipping-web-archive@ietf.org; Thu, 24 Jul 2003 16:44:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fmwT-00025A-00 for sipping-web-archive@ietf.org; Thu, 24 Jul 2003 16:44:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fmwU-0004Jh-4B; Thu, 24 Jul 2003 16: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 19fmvr-0004Gt-EX for sipping@optimus.ietf.org; Thu, 24 Jul 2003 16:43: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 QAA29650 for ; Thu, 24 Jul 2003 16:43:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fmvp-000252-00 for sipping@ietf.org; Thu, 24 Jul 2003 16:43:21 -0400 Received: from [204.57.52.4] (helo=commserver.iperia.com) by ietf-mx with esmtp (Exim 4.12) id 19fmve-00024g-00 for sipping@ietf.org; Thu, 24 Jul 2003 16:43:10 -0400 Received: by COMMSERVER with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jul 2003 16:42:28 -0400 Message-ID: <1A69639B9B6AD511812B00B0D0DE19F60A3E9A@COMMSERVER> From: Gordon Ledgard To: Gordon Ledgard , "'Adam Roach'" , "'Paul Kyzivat'" Cc: sipping Subject: RE: [Sipping] DTMF: Why Not A New Method? Date: Thu, 24 Jul 2003 16:42:21 -0400 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 meant MESSAGE of course. -----Original Message----- From: Gordon Ledgard [mailto:gledgard@iperia.com] Sent: Thursday, July 24, 2003 4:38 PM To: 'Adam Roach'; 'Paul Kyzivat' Cc: sipping Subject: RE: [Sipping] DTMF: Why Not A New Method? Lest we get lost in the metaphors, the real questions are these: 1) Is there something wrong with the Subscribe/Notify methodology that makes DTMF difficult or impossible? 2) Is there a way to solve the problems presented by S/N by using a new method, or are the problems inherent in the protocol? If the answer to 2) is "yes" then a new method is warranted. If the anwer to 2) is "no", you are just making another truck with the same problems as the old truck. Gordon -----Original Message----- From: Adam Roach [mailto:adam@dynamicsoft.com] Sent: Thursday, July 24, 2003 4:25 PM To: 'Paul Kyzivat'; Adam Roach Cc: sipping Subject: RE: [Sipping] DTMF: Why Not A New Method? > IMO it is as if we have a truck for carrying apples, and have > decided we need a different truck to carry oranges. The point that I have been trying to make is that your truck re-use scheme is just great until someone tries to back an apple truck full of oranges up to an applesauce factory, and everyone is left wondering why the applesauce is all runny, bitter, stringy and orange this time around. /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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 24 16:56: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 QAA00178 for ; Thu, 24 Jul 2003 16:56: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 19fn8E-0004zA-AQ for sipping-archive@odin.ietf.org; Thu, 24 Jul 2003 16:56:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OKuAFE019158 for sipping-archive@odin.ietf.org; Thu, 24 Jul 2003 16:56:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fn8E-0004yv-4b for sipping-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 16:56: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 QAA00138 for ; Thu, 24 Jul 2003 16:56:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fn8B-0002C2-00 for sipping-web-archive@ietf.org; Thu, 24 Jul 2003 16:56:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fn86-0002Bz-00 for sipping-web-archive@ietf.org; Thu, 24 Jul 2003 16:56:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fn85-0004uJ-Sj; Thu, 24 Jul 2003 16: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 19fn7k-0004tt-Uu for sipping@optimus.ietf.org; Thu, 24 Jul 2003 16:55: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 QAA00118 for ; Thu, 24 Jul 2003 16:55:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fn7i-0002Bv-00 for sipping@ietf.org; Thu, 24 Jul 2003 16:55:38 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19fn7X-0002Bk-00 for sipping@ietf.org; Thu, 24 Jul 2003 16:55:27 -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 h6OKsiiJ020493; Thu, 24 Jul 2003 16:54:44 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jul 2003 15:54:42 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86258@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Gordon Ledgard'" , Adam Roach , "'Paul Kyzivat'" Cc: sipping Subject: RE: [Sipping] DTMF: Why Not A New Method? Date: Thu, 24 Jul 2003 15:54:41 -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: , > 1) Is there something wrong with the Subscribe/Notify > methodology that makes DTMF difficult or impossible? **EXPLICIT** subscriptions work just fine (although we need to add a mechanism to get a SIP GRUU from the endpoint to the KPML server; and this, of course, would make such a solution predicated on a deployed GRUU architecture.) **IMPLICIT** subscriptions are broken in all sorts of horrible and nasty ways, several of which I posted to the list earlier. /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 Jul 24 16:58: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 QAA00292 for ; Thu, 24 Jul 2003 16:58: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 19fnA9-0005Dg-KM for sipping-archive@odin.ietf.org; Thu, 24 Jul 2003 16:58:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OKw9Bh020058 for sipping-archive@odin.ietf.org; Thu, 24 Jul 2003 16:58:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fnA8-0005DR-0e for sipping-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 16:58: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 QAA00282 for ; Thu, 24 Jul 2003 16:58:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fnA5-0002DY-00 for sipping-web-archive@ietf.org; Thu, 24 Jul 2003 16:58:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fnA0-0002DV-00 for sipping-web-archive@ietf.org; Thu, 24 Jul 2003 16:58:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fnA1-0005AB-FF; Thu, 24 Jul 2003 16: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 19fn9s-00058f-0T for sipping@optimus.ietf.org; Thu, 24 Jul 2003 16:57: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 QAA00260 for ; Thu, 24 Jul 2003 16:57:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fn9o-0002Cz-00 for sipping@ietf.org; Thu, 24 Jul 2003 16:57:48 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19fn9d-0002Cm-00 for sipping@ietf.org; Thu, 24 Jul 2003 16:57:37 -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 h6OKutiJ020504; Thu, 24 Jul 2003 16:56:55 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jul 2003 15:56:53 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86259@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Gordon Ledgard'" , Adam Roach , "'Paul Kyzivat'" Cc: sipping Subject: RE: [Sipping] DTMF: Why Not A New Method? Date: Thu, 24 Jul 2003 15:56:52 -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: , 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 > -----Original Message----- > From: Gordon Ledgard [mailto:gledgard@iperia.com] > Sent: Thursday, July 24, 2003 15:42 > To: Gordon Ledgard; 'Adam Roach'; 'Paul Kyzivat' > Cc: sipping > Subject: RE: [Sipping] DTMF: Why Not A New Method? > > > > I meant MESSAGE of course. > > > -----Original Message----- > From: Gordon Ledgard [mailto:gledgard@iperia.com] > Sent: Thursday, July 24, 2003 4:38 PM > To: 'Adam Roach'; 'Paul Kyzivat' > Cc: sipping > Subject: RE: [Sipping] DTMF: Why Not A New Method? > > > > Lest we get lost in the metaphors, the real questions are these: > > 1) Is there something wrong with the Subscribe/Notify > methodology that makes > > DTMF difficult or impossible? > > 2) Is there a way to solve the problems presented by S/N by > using a new > method, or are the problems inherent in the protocol? > > If the answer to 2) is "yes" then a new method is warranted. > If the anwer to 2) is "no", you are just making another truck > with the same problems as the old truck. > > Gordon > > > > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Thursday, July 24, 2003 4:25 PM > To: 'Paul Kyzivat'; Adam Roach > Cc: sipping > Subject: RE: [Sipping] DTMF: Why Not A New Method? > > > > IMO it is as if we have a truck for carrying apples, and have > > decided we need a different truck to carry oranges. > > The point that I have been trying to make is that your truck > re-use scheme is just great until someone tries to back an > apple truck full of oranges up to an applesauce factory, and > everyone is left wondering why the applesauce is all runny, > bitter, stringy and orange this time around. > > /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 > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 24 17:01: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 RAA00652 for ; Thu, 24 Jul 2003 17:01: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 19fnCU-0005XS-Q6 for sipping-archive@odin.ietf.org; Thu, 24 Jul 2003 17:00:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OL0Yu3021288 for sipping-archive@odin.ietf.org; Thu, 24 Jul 2003 17:00:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fnCU-0005XH-MC for sipping-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 17:00: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 RAA00493 for ; Thu, 24 Jul 2003 17:00: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 19fnBy-0005Kg-9L; Thu, 24 Jul 2003 17: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 19fnBR-0005JS-Dc for sipping@optimus.ietf.org; Thu, 24 Jul 2003 16:59: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 QAA00316 for ; Thu, 24 Jul 2003 16:59:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fnBP-0002EP-00 for sipping@ietf.org; Thu, 24 Jul 2003 16:59:27 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19fnBE-0002E4-00 for sipping@ietf.org; Thu, 24 Jul 2003 16:59:16 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6OKwWX29582; Thu, 24 Jul 2003 15:58:33 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <301T5SDW>; Thu, 24 Jul 2003 15:58:33 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF578AE5@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Rohan Mahy'" , sipping@ietf.org Date: Thu, 24 Jul 2003 15:58:24 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [Sipping] RE: sec-inserted Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , I agree with Rohan's point; I've not been thrilled overall with the current approach in the draft and I think it's been problematic trying to couple the solution with the need to protect an "identity" rather than generic data added by an intermediary. As far as what a proxy adds to the sipfrag, that's an excellent question also applicable to the current approach. As Rohan suggests, there's got to be some headers at a minimum specified, but as you can tell from the current approach, the only ones that have been identified are: From and Call-ID (and the related header that is being protected). So, are those sufficient and/or are there scenarios where you couldn't use those? Additional feedback from the WG would definitely be appreciated; my current plan will be to approach this from a more generic perspective (and thus achieving more of the middle-to-end security approach that was discussed briefly at IETF-57). Thanks, Mary. -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com] Sent: Saturday, July 19, 2003 12:58 PM To: sipping@ietf.org Cc: Barnes, Mary [NGC:B602:EXCH]; rohan@cisco.com Subject: sec-inserted Hi, Regarding the sec-inserted draft, I'm not especially fond of the token name "aiihb". I like the idea of creating a new Content-Disposition type for protecting intermediary SIP content, but I would like to use a different name and make the mechanism a bit more generic. Specifically, I don't see any reason to restrict the intermediary content to identities. Maybe this is just a "proxy asserted sipfrag" or "pas". A proxy could then assert that it was responsible for a particular sipfrag, or that it can authenticate parts of the sipfrag? the real question is what are the semantics on the body. Does a proxy put in only stuff it added? obviously not, because it needs to include headers that tie the body to the message for replay prevention. What existing stuff does it include? For headers with multiple header field values can it just include one? (probably a good idea if we ever do this for Via.) these are the questions I want to explore. 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 Thu Jul 24 21:31: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 VAA07976 for ; Thu, 24 Jul 2003 21:31: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 19frQP-0000t3-8O for sipping-archive@odin.ietf.org; Thu, 24 Jul 2003 21:31:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P1VD5e003405 for sipping-archive@odin.ietf.org; Thu, 24 Jul 2003 21:31:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19frQP-0000sq-4F for sipping-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 21:31: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 VAA07926 for ; Thu, 24 Jul 2003 21:31:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19frQM-0003ip-00 for sipping-web-archive@ietf.org; Thu, 24 Jul 2003 21:31:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19frQG-0003im-00 for sipping-web-archive@ietf.org; Thu, 24 Jul 2003 21:31:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19frQD-0000rh-SA; Thu, 24 Jul 2003 21:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19frPh-0000od-BD for sipping@optimus.ietf.org; Thu, 24 Jul 2003 21:30: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 VAA07884 for ; Thu, 24 Jul 2003 21:30:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19frPe-0003i7-00 for sipping@ietf.org; Thu, 24 Jul 2003 21:30:26 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19frPT-0003hB-00 for sipping@ietf.org; Thu, 24 Jul 2003 21:30:15 -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 h6P1Rwpr013224; Thu, 24 Jul 2003 18:28:00 -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 AJO94854; Thu, 24 Jul 2003 18:23:45 -0700 (PDT) Date: Fri, 25 Jul 2003 03:30:10 +0200 Subject: Re: [Sipping] DTMF: Why Not A New Method? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Adam Roach , sipping To: Paul Kyzivat From: Rohan Mahy In-Reply-To: <3F2043B4.1030306@cisco.com> Message-Id: <87CD2383-BE3F-11D7-B1E0-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 Paul, Sounds like a nice trucking company. Unfortunately, I don't think its an accurate analogy for SIP. thanks, -rohan On Thursday, July 24, 2003, at 10:38 PM, Paul Kyzivat wrote: > Well, in my trucking company we don't just leave loaded trucks sitting > around for people to take where they will. Instead, we take orders for > trucks of apples or oranges, and we deliver them to where the order > said to deliver them. And we include a packing slip saying what is > contained. > > If the acme fruit packing company orders oranges from me, and I > deliver them, with a packing slip that says oranges, then the acme > people should know not to make applesauce out of them, even if I send > the same truck that sometimes delivers apples. > > Paul > > Adam Roach wrote: >>> IMO it is as if we have a truck for carrying apples, and have >>> decided we need a different truck to carry oranges. >> The point that I have been trying to make is that your truck >> re-use scheme is just great until someone tries to back an >> apple truck full of oranges up to an applesauce factory, and >> everyone is left wondering why the applesauce is all runny, >> bitter, stringy and orange this time around. >> /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 Fri Jul 25 11:22: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 LAA08987 for ; Fri, 25 Jul 2003 11:22: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 19g4Og-0000e3-Ma for sipping-archive@odin.ietf.org; Fri, 25 Jul 2003 11:22:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PFMIRT002475 for sipping-archive@odin.ietf.org; Fri, 25 Jul 2003 11:22:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g4Og-0000dq-JJ for sipping-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 11:22: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 LAA08969 for ; Fri, 25 Jul 2003 11:22:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g4Of-00013o-00 for sipping-web-archive@ietf.org; Fri, 25 Jul 2003 11:22:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19g4OZ-00013i-00 for sipping-web-archive@ietf.org; Fri, 25 Jul 2003 11:22:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g4OQ-0000bT-5c; Fri, 25 Jul 2003 11:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g4O0-0000at-OU for sipping@optimus.ietf.org; Fri, 25 Jul 2003 11:21: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 LAA08942 for ; Fri, 25 Jul 2003 11:21:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g4Nz-000138-00 for sipping@ietf.org; Fri, 25 Jul 2003 11:21:35 -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 19g4Np-00012g-00 for sipping@ietf.org; Fri, 25 Jul 2003 11:21:25 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 25 Jul 2003 08:22:08 -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 h6PFKTQk008122; Fri, 25 Jul 2003 08:20:30 -0700 (PDT) Received: from [10.0.1.6] (sjc-vpn1-716.cisco.com [10.21.98.204]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGK75969; Fri, 25 Jul 2003 08:20:28 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 24 Jul 2003 15:48:29 -0700 Subject: Re: [Sipping] Re: Call Waiting - who does the tone From: Cullen Jennings To: Henry Sinnreich , Alan Hawrylyshen , Message-ID: In-Reply-To: <000301c33512$9014edc0$248823a6@hsinnreich2> 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 Completely agree with Henry and point out that even my two line PSTN phone implements this in the phone. Cullen On 6/17/03 13:53, "Henry Sinnreich" wrote: > There is another argument for call waiting to be implemented in the > endpoints: No extra integration testing and regression testing by > service provider labs with many other network elements - a very costly > proposition if done for every call feature. My personal two cents. >=20 > Thanks, Henry >=20 > Henry Sinnreich > MCI > 400 International Parkway > Richardson, Texas 75081 > USA >=20 > Have you disconnected the PBX? >=20 >=20 >> -----Original Message----- >> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] >> On Behalf Of Alan Hawrylyshen >> Sent: Monday, June 16, 2003 5:01 PM >> To: 'sipping@ietf.org' >> Subject: [Sipping] Re: Call Waiting - who does the tone >>=20 >>=20 >> On Saturday, Jun 14, 2003, at 01:27 Canada/Mountain, Satish Bansal! >> wrote: >>>=20 >>> There could be two options. First as you said,=A0 a dump phone should >>> handle call waiting. It would mean that we are making=A0 end nodes >>> intelligent. >>>=20 >>> Second option is that intelligence is in the=A0 network, the inbound >>> proxy should be call statefull and should use 3pcc for >> playing tone &=20 >>> annc. through a server to=A0 the party. >>=20 >> Certainly both solutions work, but keeping the implementation of this >> feature in the UA would be , in my opinion, more in keeping with the >> SIP design philosophies of keeping the core relatively free of >> complexity. With this support in the end-UAs you will see >> better user=20 >> experiences in mixed domain deployments (e.g. receipt of a call via >> direct URL dialing while in a pre-existing session >> established through >> the proxy handling your registered AOR). >>=20 >> Although it raises the bar a little bit for the UA implementors, I >> certainly feel that it will scale better and reduce the >> overall cost to=20 >> maintain and deploy the =92core=92 portion of a SIP network >> infrastructure. >>=20 >> I would agree w/ Brian on this; this could be appropriate for >> inclusion=20 >> in a BCP document. >>=20 >> De-lurking, >>=20 >> Alan Hawrylyshen Jasomi Networks Inc. >> sip:alan@jasomi.com mailto:alan@jasomi.com >>=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 >=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 Jul 25 11:22: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 LAA09002 for ; Fri, 25 Jul 2003 11:22: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 19g4Ok-0000eJ-8C for sipping-archive@odin.ietf.org; Fri, 25 Jul 2003 11:22:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PFMMPM002494 for sipping-archive@odin.ietf.org; Fri, 25 Jul 2003 11:22:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g4Ok-0000e9-2v for sipping-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 11:22: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 LAA08973 for ; Fri, 25 Jul 2003 11:22:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g4Of-00013l-00 for sipping-web-archive@ietf.org; Fri, 25 Jul 2003 11:22:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19g4OZ-00013h-00 for sipping-web-archive@ietf.org; Fri, 25 Jul 2003 11:22:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g4OQ-0000bd-Sk; Fri, 25 Jul 2003 11:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g4O1-0000ay-Vm for sipping@optimus.ietf.org; Fri, 25 Jul 2003 11:21: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 LAA08945 for ; Fri, 25 Jul 2003 11:21:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g4O1-00013B-00 for sipping@ietf.org; Fri, 25 Jul 2003 11:21:37 -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 19g4Nq-00012f-00 for sipping@ietf.org; Fri, 25 Jul 2003 11:21:26 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 25 Jul 2003 08:22:04 -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 h6PFKP89010377; Fri, 25 Jul 2003 08:20:26 -0700 (PDT) Received: from [10.0.1.6] (sjc-vpn1-716.cisco.com [10.21.98.204]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGK75961; Fri, 25 Jul 2003 08:20:24 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 24 Jul 2003 15:17:04 -0700 Subject: Re: [Sipping] How to report DTMF - conclusion of the app interact ion design team: SIP MESSAGE From: Cullen Jennings To: Adam Roach , Paul Kyzivat , Jonathan Rosenberg CC: sipping Message-ID: In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3EE601D@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 7/18/03 0:12, "Adam Roach" wrote: > Paul Kyzivat [mailto:pkyzivat@cisco.com] writes: > >> For one thing, the application already has an opportunity to pick the >> address to which the MESSAGEs are sent. So it should be able >> to ensure >> that the recipient knows these messages shouldn't be >> displayed directly >> to an end-user. > > The problem really is one of a slippery slope. You already > heard a participant get up in the meeting and suggest that > MESSAGE should be the mechanism by which a server pushes a > KPML script to a UA. This is just one use case away from > sending a MESSAGE to a UA from which no message has yet been > received, which will undoubtedly cause the relic I described > earlier. > I don't think I understand the scenario you are getting at here. Are you saying that the UA will just automatically send any key press to whatever UA it is talking to with no KPML - sort of like the old DTMF over INFO idea? I'd agree this was really broken but if someone did it, rendering the key presses would probably be about as good a semantic as any. This could all be mitigated by the choice of the body in the message. Anyways, everything to do with DTMF is sort of a slippery slope no matter which direction we go. I would consider anything that created "automatic" KPML subscription very broken. >> Beyond that, there is the Content-Disposition header, which seems >> intended for purposes like this. In the normal use of MESSAGE for IM, >> the obvious content type is "render". Here we don't want that, so we >> should pick some other content type. > > Without well-defined semantics in the MESSAGE RFC, I can > confidently assert that many, if not most, UAs will not bother > with checking the Content-Disposition when they receive a MESSAGE. > MESSAGE has an explicit render semantic built in. > Agreed I wonder what a PSTN GW should do if it receives a IM with a plain text body that contains "7" - it could "render it". Ooh that is gross :-) _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 25 11:33: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 LAA09362 for ; Fri, 25 Jul 2003 11:33: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 19g4ZE-0001YO-5k for sipping-archive@odin.ietf.org; Fri, 25 Jul 2003 11:33:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PFXCgP005966 for sipping-archive@odin.ietf.org; Fri, 25 Jul 2003 11: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 19g4ZC-0001Y9-Jt for sipping-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 11:33: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 LAA09348 for ; Fri, 25 Jul 2003 11:33:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g4ZB-0001BD-00 for sipping-web-archive@ietf.org; Fri, 25 Jul 2003 11:33:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19g4Z5-0001BA-00 for sipping-web-archive@ietf.org; Fri, 25 Jul 2003 11: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 19g4Z3-0001Uw-Nz; Fri, 25 Jul 2003 11: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 19g4YE-0001UQ-1D for sipping@optimus.ietf.org; Fri, 25 Jul 2003 11: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 LAA09318 for ; Fri, 25 Jul 2003 11:32:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g4YD-0001Aj-00 for sipping@ietf.org; Fri, 25 Jul 2003 11:32:09 -0400 Received: from mail.siemenscom.com ([12.146.131.10]) by ietf-mx with esmtp (Exim 4.12) id 19g4Y2-0001AW-00 for sipping@ietf.org; Fri, 25 Jul 2003 11:31:58 -0400 Received: from mail-stc.rolm.com (mail-stc.siemenscom.com [165.218.65.50]) by mail.siemenscom.com (8.9.3p2/8.9.3) with ESMTP id IAA26678; Fri, 25 Jul 2003 08:30:12 -0700 (PDT) Received: from stca200a.bus.sc.rolm.com (stca200a.bus.sc.rolm.com [165.218.68.180]) by mail-stc.rolm.com (8.11.6/8.11.6) with ESMTP id h6PFI7Z03177; Fri, 25 Jul 2003 08:18:08 -0700 (PDT) Received: by stca200a.bus.sc.rolm.com with Internet Mail Service (5.5.2653.19) id <3TAK0N5T>; Fri, 25 Jul 2003 08:31:31 -0700 Message-ID: <7A25937D23A1E64C8E93CB4A50509C2A01EA3C0A@stca204a.bus.sc.rolm.com> From: "Stevens, Del" To: "'Cullen Jennings'" , Henry Sinnreich , Alan Hawrylyshen , sipping@ietf.org Subject: RE: [Sipping] Re: Call Waiting - who does the tone Date: Fri, 25 Jul 2003 08:31:29 -0700 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 Don't forget to consider emergency service (E911) requirements. A user connected to 911 cannot be interrupted by call waiting. If the UA is responsible for the tone it will also be responsible for knowing local country requirements for emergency service. Del Stevens Siemens Network Convergence 5500 Broken Sound Blvd Boca Raton, FL 33487 -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Thursday, July 24, 2003 6:48 PM To: Henry Sinnreich; Alan Hawrylyshen; sipping@ietf.org Subject: Re: [Sipping] Re: Call Waiting - who does the tone Completely agree with Henry and point out that even my two line PSTN = phone implements this in the phone. Cullen On 6/17/03 13:53, "Henry Sinnreich" wrote: > There is another argument for call waiting to be implemented in the > endpoints: No extra integration testing and regression testing by > service provider labs with many other network elements - a very = costly > proposition if done for every call feature. My personal two cents. >=20 > Thanks, Henry >=20 > Henry Sinnreich > MCI > 400 International Parkway > Richardson, Texas 75081 > USA >=20 > Have you disconnected the PBX? >=20 >=20 >> -----Original Message----- >> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] >> On Behalf Of Alan Hawrylyshen >> Sent: Monday, June 16, 2003 5:01 PM >> To: 'sipping@ietf.org' >> Subject: [Sipping] Re: Call Waiting - who does the tone >>=20 >>=20 >> On Saturday, Jun 14, 2003, at 01:27 Canada/Mountain, Satish Bansal! >> wrote: >>>=20 >>> There could be two options. First as you said,=A0 a dump phone = should >>> handle call waiting. It would mean that we are making=A0 end nodes >>> intelligent. >>>=20 >>> Second option is that intelligence is in the=A0 network, the = inbound >>> proxy should be call statefull and should use 3pcc for >> playing tone &=20 >>> annc. through a server to=A0 the party. >>=20 >> Certainly both solutions work, but keeping the implementation of = this >> feature in the UA would be , in my opinion, more in keeping with the >> SIP design philosophies of keeping the core relatively free of >> complexity. With this support in the end-UAs you will see >> better user=20 >> experiences in mixed domain deployments (e.g. receipt of a call via >> direct URL dialing while in a pre-existing session >> established through >> the proxy handling your registered AOR). >>=20 >> Although it raises the bar a little bit for the UA implementors, I >> certainly feel that it will scale better and reduce the >> overall cost to=20 >> maintain and deploy the 'core' portion of a SIP network >> infrastructure. >>=20 >> I would agree w/ Brian on this; this could be appropriate for >> inclusion=20 >> in a BCP document. >>=20 >> De-lurking, >>=20 >> Alan Hawrylyshen Jasomi Networks Inc. >> sip:alan@jasomi.com mailto:alan@jasomi.com >>=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 >=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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 25 13:32: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 NAA13415 for ; Fri, 25 Jul 2003 13:32: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 19g6QL-0000Ud-JU for sipping-archive@odin.ietf.org; Fri, 25 Jul 2003 13:32:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PHW9Q5001889 for sipping-archive@odin.ietf.org; Fri, 25 Jul 2003 13:32:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g6QL-0000UO-FY for sipping-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 13:32: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 NAA13404 for ; Fri, 25 Jul 2003 13:32:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g6QJ-0002DF-00 for sipping-web-archive@ietf.org; Fri, 25 Jul 2003 13:32:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19g6QI-0002DC-00 for sipping-web-archive@ietf.org; Fri, 25 Jul 2003 13:32:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g6QD-0000TS-Io; Fri, 25 Jul 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 19g6Pn-0000T6-Pe for sipping@optimus.ietf.org; Fri, 25 Jul 2003 13:31: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 NAA13384 for ; Fri, 25 Jul 2003 13:31:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g6Pl-0002D7-00 for sipping@ietf.org; Fri, 25 Jul 2003 13:31:33 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19g6Pk-0002D3-00 for sipping@ietf.org; Fri, 25 Jul 2003 13:31:33 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA26414; Fri, 25 Jul 2003 13:31:00 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA27376; Fri, 25 Jul 2003 13:31:01 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <3P1M549H>; Fri, 25 Jul 2003 13:31:00 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5C53@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Stevens, Del'" , "'Cullen Jennings'" , Henry Sinnreich , Alan Hawrylyshen , sipping@ietf.org Subject: RE: [Sipping] Re: Call Waiting - who does the tone Date: Fri, 25 Jul 2003 13:30:55 -0400 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 think there are several reasons for the phone understanding that a particular call is an emergency call, but I'm not sure how it will figure it out. Then again, having the "network" handling call waiting tone just moves the problem. If this is a hard requirement, it means we have to somehow mark emergency calls. In general, doing that reliably without a spoof attack possibility is pretty hard. Brian > -----Original Message----- > From: Stevens, Del [mailto:Del.Stevens@icn.siemens.com] > Sent: Friday, July 25, 2003 11:31 AM > To: 'Cullen Jennings'; Henry Sinnreich; Alan Hawrylyshen; > sipping@ietf.org > Subject: RE: [Sipping] Re: Call Waiting - who does the tone >=20 >=20 > Don't forget to consider emergency service (E911) requirements. A = user > connected to 911 cannot be interrupted by call waiting. If the UA is > responsible for the tone it will also be responsible for knowing = local > country requirements for emergency service. >=20 > Del Stevens > Siemens Network Convergence > 5500 Broken Sound Blvd > Boca Raton, FL 33487 >=20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Thursday, July 24, 2003 6:48 PM > To: Henry Sinnreich; Alan Hawrylyshen; sipping@ietf.org > Subject: Re: [Sipping] Re: Call Waiting - who does the tone >=20 >=20 >=20 > Completely agree with Henry and point out that even my two=20 > line PSTN phone > implements this in the phone. >=20 > Cullen >=20 >=20 > On 6/17/03 13:53, "Henry Sinnreich" wrote: >=20 > > There is another argument for call waiting to be implemented in the > > endpoints: No extra integration testing and regression testing by > > service provider labs with many other network elements - a=20 > very costly > > proposition if done for every call feature. My personal two cents. > >=20 > > Thanks, Henry > >=20 > > Henry Sinnreich > > MCI > > 400 International Parkway > > Richardson, Texas 75081 > > USA > >=20 > > Have you disconnected the PBX? > >=20 > >=20 > >> -----Original Message----- > >> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > >> On Behalf Of Alan Hawrylyshen > >> Sent: Monday, June 16, 2003 5:01 PM > >> To: 'sipping@ietf.org' > >> Subject: [Sipping] Re: Call Waiting - who does the tone > >>=20 > >>=20 > >> On Saturday, Jun 14, 2003, at 01:27 Canada/Mountain, Satish = Bansal! > >> wrote: > >>>=20 > >>> There could be two options. First as you said,=A0 a dump=20 > phone should > >>> handle call waiting. It would mean that we are making=A0 end = nodes > >>> intelligent. > >>>=20 > >>> Second option is that intelligence is in the=A0 network, the = inbound > >>> proxy should be call statefull and should use 3pcc for > >> playing tone &=20 > >>> annc. through a server to=A0 the party. > >>=20 > >> Certainly both solutions work, but keeping the=20 > implementation of this > >> feature in the UA would be , in my opinion, more in=20 > keeping with the > >> SIP design philosophies of keeping the core relatively free of > >> complexity. With this support in the end-UAs you will see > >> better user=20 > >> experiences in mixed domain deployments (e.g. receipt of a call = via > >> direct URL dialing while in a pre-existing session > >> established through > >> the proxy handling your registered AOR). > >>=20 > >> Although it raises the bar a little bit for the UA implementors, I > >> certainly feel that it will scale better and reduce the > >> overall cost to=20 > >> maintain and deploy the 'core' portion of a SIP network > >> infrastructure. > >>=20 > >> I would agree w/ Brian on this; this could be appropriate for > >> inclusion=20 > >> in a BCP document. > >>=20 > >> De-lurking, > >>=20 > >> Alan Hawrylyshen Jasomi Networks Inc. > >> sip:alan@jasomi.com mailto:alan@jasomi.com > >>=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 > >=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 >=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 >=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 Sun Jul 27 22:08: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 WAA02071 for ; Sun, 27 Jul 2003 22:08: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 19gxQt-0008CQ-Sf for sipping-archive@odin.ietf.org; Sun, 27 Jul 2003 22:08:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6S28FRX031514 for sipping-archive@odin.ietf.org; Sun, 27 Jul 2003 22: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 19gxQt-0008CD-OQ for sipping-web-archive@optimus.ietf.org; Sun, 27 Jul 2003 22: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 WAA02055 for ; Sun, 27 Jul 2003 22:08:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19gxQq-0002Vs-00 for sipping-web-archive@ietf.org; Sun, 27 Jul 2003 22:08:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19gxQq-0002Vo-00 for sipping-web-archive@ietf.org; Sun, 27 Jul 2003 22:08:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gxQf-0008BL-33; Sun, 27 Jul 2003 22: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 19gxQJ-00089X-Bt for sipping@optimus.ietf.org; Sun, 27 Jul 2003 22:07: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 WAA02034 for ; Sun, 27 Jul 2003 22:07:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19gxQG-0002Vf-00 for sipping@ietf.org; Sun, 27 Jul 2003 22:07: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 19gxQF-0002V9-01 for sipping@ietf.org; Sun, 27 Jul 2003 22:07:35 -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 h6S279uD021818; Sun, 27 Jul 2003 19:07:10 -0700 (PDT) Received: from [10.0.1.2] (sjc-vpn3-952.cisco.com [10.21.67.184]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGM11028; Sun, 27 Jul 2003 19:07:08 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 27 Jul 2003 19:05:10 -0700 Subject: Re: [Sipping] Diversion header From: Cullen Jennings To: Romel Khan , Message-ID: In-Reply-To: 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 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 > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 28 04:39: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 EAA23958 for ; Mon, 28 Jul 2003 04:39: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 19h3XG-0005Ia-EM for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 04:39:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6S8dEPq020365 for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 04:39:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h3XG-0005IO-2e for sipping-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 04:39: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 EAA23925 for ; Mon, 28 Jul 2003 04:39:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19h3XD-0007AB-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 04:39:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19h3XC-0007A8-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 04:39:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h3X5-0005HD-1d; Mon, 28 Jul 2003 04: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 19h3WU-0005FQ-Sh for sipping@optimus.ietf.org; Mon, 28 Jul 2003 04:38: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 EAA23869 for ; Mon, 28 Jul 2003 04:38:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19h3WR-00078u-00 for sipping@ietf.org; Mon, 28 Jul 2003 04:38:23 -0400 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx with esmtp (Exim 4.12) id 19h3WR-00078q-00 for sipping@ietf.org; Mon, 28 Jul 2003 04:38:23 -0400 Received: by fox.iptel.org (Postfix, from userid 103) id 039316B4; Mon, 28 Jul 2003 10:34:02 +0200 (CEST) Received: from jku07.iptel.org (dial43.cesnet.cz [195.113.150.43]) by fox.iptel.org (Postfix) with ESMTP id 7530D685; Mon, 28 Jul 2003 10:33:52 +0200 (CEST) Message-Id: <5.2.0.9.0.20030728101717.00ba8370@localhost> X-Sender: jiri@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 28 Jul 2003 10:17:51 +0200 To: Jonathan Rosenberg , sipping From: Jiri Kuthan Subject: Re: [Sipping] Update to 3pcc Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-5.7 required=5.0 tests=BAYES_00,EMAIL_ATTRIBUTION 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'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 From exim@www1.ietf.org Mon Jul 28 13:47: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 NAA13881 for ; Mon, 28 Jul 2003 13:47: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 19hC5U-0008LY-8V for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 13:47:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SHl8ip032080 for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 13:47:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hC5U-0008LL-5L for sipping-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 13:47: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 NAA13863 for ; Mon, 28 Jul 2003 13:47:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hC5R-00068l-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 13:47:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hC5R-00068i-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 13:47:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hC5O-0008KS-BJ; Mon, 28 Jul 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 19hC4f-0008K3-Kv for sipping@optimus.ietf.org; Mon, 28 Jul 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 NAA13841 for ; Mon, 28 Jul 2003 13:46:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hC4d-00068a-00 for sipping@ietf.org; Mon, 28 Jul 2003 13:46:15 -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 19hC4c-00068F-00 for sipping@ietf.org; Mon, 28 Jul 2003 13:46:14 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 28 Jul 2003 10:45:45 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6SHjg89029371; Mon, 28 Jul 2003 10:45:42 -0700 (PDT) Received: from cisco.com ([161.44.79.125]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ABA72788; Mon, 28 Jul 2003 13:45:36 -0400 (EDT) Message-ID: <3F256140.7070906@cisco.com> Date: Mon, 28 Jul 2003 13:45:36 -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: Jiri Kuthan CC: Jonathan Rosenberg , sipping Subject: Re: [Sipping] Update to 3pcc References: <5.2.0.9.0.20030728101717.00ba8370@localhost> 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 Jiri, REFER is tempting as an alternative to a b2bua for click-to-dial, but I suspect there are practical difficulties to its use. The details may vary depending on how you imagine using it. The simplest approach is presumably to have the click-to-dial server simply send a REFER to one party, refering them to the other party. Issues with this: - the referred endpoint probably needs to alert its user and await an answer before ending the invite. Such behavior isn't standardized, and its likely that many/most UAs don't do this. - in cases where billing is involved, somebody is going to be billed for the call. It isn't clear how you can build a click-to-dial server so that the "right" thing happens, whatever that is. - in general, authorization for such a REFER isn't likely to be granted to just anybody. While it may be possible to set up a specific arrangement for this between the click-to-dial server and the referee, that would require some propriatary work. I suppose another way to handle this would be to have the click-to-dial server send an invite to the referee, either medialess or with media black-holed. Then it could send a refer within that dialog. This would resolve the alerting issue, and transform the other issues into familiar ones having to do with transfer. Issues with this: - afaik billing and authorization issues for refer aren't fully solved. - if this approach is done with black hole media then it has the same problems you were hoping to avoid. I think the b2bua approach to click-to-dial has the best chance of working. This is more likely if 0.0.0.0 is used as the black-hole address. It is less likely if .invalid is used as the black-hole address. Paul Jiri Kuthan wrote: > 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 > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 28 15:46: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 PAA18316 for ; Mon, 28 Jul 2003 15:46: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 19hDvs-0004sa-7p for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 15:45:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SJjKd1018750 for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 15:45:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDvs-0004sL-4U for sipping-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 15:45: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 PAA18217 for ; Mon, 28 Jul 2003 15:45:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hDvq-00075A-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 15:45:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hDvn-00074p-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 15:45:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDve-0004fd-Su; Mon, 28 Jul 2003 15:45:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eHIz-0004NW-NG for sipping@optimus.ietf.org; Sun, 20 Jul 2003 12:45: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 MAA22570 for ; Sun, 20 Jul 2003 12:44:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eHIy-0003XJ-00 for sipping@ietf.org; Sun, 20 Jul 2003 12:45:00 -0400 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx with esmtp (Exim 4.12) id 19eHIn-0003Wv-00 for sipping@ietf.org; Sun, 20 Jul 2003 12:44:49 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Sun, 20 Jul 2003 18:43:57 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Sun, 20 Jul 2003 18:43:57 +0200 Message-Id: <43240544763FB8479F1529372F6197CF053CC8CE@G8PQC.blf01.telekom.de> From: "Liess, Laura" To: aboba@internaut.com Cc: hgs@cs.columbia.edu, sipping@ietf.org, "Dumler, Alexander" , "Wolff, Christian" Subject: AW: AW: [Sipping] FYI: RADIUS & SIP Date: Sun, 20 Jul 2003 18:43:39 +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: , Draft-sterman-aaa-sip-01.txt for authentication and draft-schulzrinne-accounting-sip-01.txt for accounting would be fine. Thanks, Laura >-----Ursprungliche Nachricht----- >Von: Bernard Aboba [mailto:aboba@internaut.com] >Gesendet: Sonntag, 20. Juli 2003 05:37 >An: Liess, Laura >Cc: hgs@cs.columbia.edu; sipping@ietf.org; Dumler, Alexander; Wolff, >Christian >Betreff: Re: AW: [Sipping] FYI: RADIUS & SIP > > >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 From exim@www1.ietf.org Mon Jul 28 15:46:01 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 PAA18332 for ; Mon, 28 Jul 2003 15:46:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDw5-0004uc-VQ for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 15:45:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SJjXD2018876 for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 15:45:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDw5-0004uN-SD for sipping-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 15:45: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 PAA18241 for ; Mon, 28 Jul 2003 15:45:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hDw2-000767-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 15:45:30 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hDvq-00074t-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 15:45:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDvZ-0004ci-G8; Mon, 28 Jul 2003 15: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 19d8KH-0007nC-SK for sipping@optimus.ietf.org; Thu, 17 Jul 2003 08:57: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 IAA04593 for ; Thu, 17 Jul 2003 08:57:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d8KG-00068o-00 for sipping@ietf.org; Thu, 17 Jul 2003 08:57:36 -0400 Received: from iere.net.avaya.com ([198.152.12.101]) by ietf-mx with esmtp (Exim 4.12) id 19d8K5-00068H-00 for sipping@ietf.org; Thu, 17 Jul 2003 08:57:25 -0400 Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h6HCraa23050 for ; Thu, 17 Jul 2003 08:53:36 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h6HCrZs23026 for ; Thu, 17 Jul 2003 08:53:35 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C34C62.E54BD471" Date: Thu, 17 Jul 2003 15:56:53 +0300 Message-ID: Thread-Topic: RTCP Summary Reports Thread-Index: AcNMYuTbD0/es8pUREG4G/SQ86/dlg== From: "Romascanu, Dan (Dan)" To: Subject: [Sipping] RTCP Summary Reports Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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_01C34C62.E54BD471 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Please have a look at the RAQMON work that I mentioned in the meeting = today. I think this comes pretty close to what is needed. http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-rmonmib-raqm= on-framework-02.txt http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-rmonmib-raqm= on-pdu-02.txt http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-rmonmib-raqm= on-mib-01.txt Regards, Dan ------_=_NextPart_001_01C34C62.E54BD471 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable RTCP Summary Reports

Please have a look at the = RAQMON work that I mentioned in the meeting today. I think this comes = pretty close to what is needed.

http://www.ietf.cnri.reston.va.us/internet-d= rafts/draft-ietf-rmonmib-raqmon-framework-02.txt

http://www.ietf.cnri.reston.va.us/internet-drafts/= draft-ietf-rmonmib-raqmon-pdu-02.txt

http://www.ietf.cnri.reston.va.us/internet-drafts/= draft-ietf-rmonmib-raqmon-mib-01.txt

Regards,

Dan



------_=_NextPart_001_01C34C62.E54BD471-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 28 15:46:01 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 PAA18317 for ; Mon, 28 Jul 2003 15:46: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 19hDvr-0004sD-Va for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 15:45:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SJjJYt018734 for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 15:45:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDvr-0004s5-Eo for sipping-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 15:45: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 PAA18213 for ; Mon, 28 Jul 2003 15:45:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hDvp-00074y-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 15:45:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hDvn-00074o-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 15:45:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDva-0004d7-TP; Mon, 28 Jul 2003 15: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 19dSGd-0007j5-B9 for sipping@optimus.ietf.org; Fri, 18 Jul 2003 06:15: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 GAA25870 for ; Fri, 18 Jul 2003 06:15:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dSGZ-0007Rd-00 for sipping@ietf.org; Fri, 18 Jul 2003 06:15:07 -0400 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx with esmtp (Exim 4.12) id 19dSGO-0007Qs-00 for sipping@ietf.org; Fri, 18 Jul 2003 06:14:56 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 18 Jul 2003 11:44:20 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Jul 2003 11:44:20 +0200 Message-Id: <43240544763FB8479F1529372F6197CF053CC8CD@G8PQC.blf01.telekom.de> From: "Liess, Laura" To: hgs@cs.columbia.edu, sipping@ietf.org, aboba@internaut.com Cc: "Dumler, Alexander" , "Wolff, Christian" Subject: AW: [Sipping] FYI: RADIUS & SIP Date: Fri, 18 Jul 2003 11:44:10 +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: , 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 From exim@www1.ietf.org Mon Jul 28 15:46: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 PAA18362 for ; Mon, 28 Jul 2003 15:46: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 19hDvy-0004t7-Nv for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 15:45:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SJjQem018776 for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 15:45:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDvy-0004sc-IM for sipping-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 15:45: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 PAA18220 for ; Mon, 28 Jul 2003 15:45:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hDvq-00075J-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 15:45:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hDvn-00074q-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 15:45:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDve-0004fE-3m; Mon, 28 Jul 2003 15:45:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dlLF-0005E3-V7 for sipping@optimus.ietf.org; Sat, 19 Jul 2003 02:37: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 CAA07084 for ; Sat, 19 Jul 2003 02:37:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dlLC-0007Af-00 for sipping@ietf.org; Sat, 19 Jul 2003 02:37:10 -0400 Received: from mta07.mx.cix.co.uk ([212.241.168.137]) by ietf-mx with esmtp (Exim 4.12) id 19dlL1-0007A1-00 for sipping@ietf.org; Sat, 19 Jul 2003 02:36:59 -0400 Received: from hitachi (adsl-216-100-136-203.dsl.snfc21.pacbell.net [216.100.136.203]) by mta07.mx.cix.co.uk (8.11.3/CIX/8.11.3) with SMTP id h6J6ZXB02455; Sat, 19 Jul 2003 07:35:34 +0100 X-Envelope-From: asaks@waitrose.com Message-ID: <004f01c34dbf$56bfab80$6501a8c0@hitachi> Reply-To: "Andrea Saks" From: "Andrea Saks" To: , , =?Windows-1252?Q?Gunnar_Hellstr=F6m?= , "Paul E. Jones" Cc: , , , , , , , "James Hamlin" , , , "'Rajesh Kumar'" , , , , "Mike Spanner" , "Guido Gybels" , "Henry Sinnreich" References: <002c01c34d8e$1cd6cd80$0401a8c0@packetizer.org> Subject: Re: [Sipping] Re: items for vor voting in the BOF Date: Sat, 19 Jul 2003 07:30:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mta07.mx.cix.co.uk id h6J6ZXB02455 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 Paul is absolutely right. Just to let all of you know I think this littl= e outcome in my opinion is in direct violation of some ADA legislation in t= he USA that includes both IP and telecoms in its mandate. I have just been brought up to speed in the USA during my participation at the ITU worksho= p at the TDI convention this past week. Australian participation was presen= t as well. I will be informing all my contacts including those at the Justi= ce department, FCC and State department and ITU of the results of this meeting. Contray to Guido wanting to restrict I want it all out in the open!!So Guido's glee may be in vain. It certainly is premature . I do not think t= his outcome will stand. And as I have said before it seems unlikely ETSI will take a strong view either. I think any attempt to try and separate Europe from the USA is futile both in spirit and in practical terms and defeats the whole exerci= se of compatibility and communication for the deaf on a world wide basis. . The USA Canada and Australia comprise the largest body of Textphone users= in the world. The RNID does not speak for the world nor should it and nor will it. Paul is also right that work on reflectors is as valid as physi= cal presence and those experienced in standards work know that to be true. Hearing people do not have to give up their devices why should the deaf.= We all use different devices and systems at different times as appropriate. Why should we have to give up anything because a few want to change the world with a "perfect device" that unfortunately very few people will buy. People with marketing experience will also know that people will buy the cheaper ones without support .. And since standards are voluntary it might ignored all together. All you are creating in theory is the next legacy device if it even gets made. The systems and all devices that a= re created like IP phone must support all legacy devices and only then c= an true migration happen. People who fail to understand history are doomed t= o repeat its mistakes. In this case I suspect a lot of people do not even k= now that this tactic has been attempted before and failed and not just in th= e deaf world. This messenger will be back to you all after I have illuminated consulted) with) the bodies above to the "wisdom"of this adhoc group. Andrea J Saks Telecommunications Specialist for the Deaf Rockville, The Quarry Brockhampton Gloucestershire GL 54 5XL United Kingdom Tel +44 1242 820800 Minicom +44 1242 820623 ( V21 and Baudot only) Fax +44 1242 821171 Mobile +44 7956 222916 asaks @ waitrose.com ----- Original Message ----- From: Paul E. Jones To: Gunnar Hellstr=F6m ; ; Cc: Henry Sinnreich ; Guido Gybels ; Mike Spanner ; ; ; ; 'Rajesh Kumar' ; ; ; James Hamlin ; ; ; ; = ; ; ; ; Andrea Saks Sent: Saturday, July 19, 2003 1:38 AM Subject: Re: [Sipping] Re: items for vor voting in the BOF Gunnar, I made a couple of typos that, perhaps, might make a difference to you. The results stated that an RJ-11 interface was a "may". *If* it supports= an RJ-11, then it *may* support RFC 2793 and *must* support pass-through. I typed a bit too fast below. What I intended to say what that we should have made support for pass-through a *must* in all cases where RFC 2793 i= s not supported. However, we should separate that requirement from whether there is an RJ-11, 2.5mm audio jack, or acoustic coupling. Below, you wrote: "most textphone users are nowadays used to let the textphone do the dialing and answering..." I would tend to think that wi= ll continue to be true in the following two cases: 1) The new textphone is an IP textphone (this includes any standard IP phone with native RFC 2793 support) 2) The textphone is plugged into a residential gateway (in this case, the textphone is the same technology as used today.) What is excluded from support is the class of phones that you find on the shelf at Wal-Mart that will not have a suitable display nor an interface = for a display and keyboard. I've said before that I think there will be such= a class of devices and I think we'd be foolish not give that consideration. As it is now, there is the potential for millions of IP phones to be produced that have absolutely no support for text, nor an interface for connecting with legacy TTY devices. Are you willing to allow the production of 100,000,000 IP phones that hav= e no means of doing text telephony? According to the ad-hoc group, this is acceptable. Paul ----- Original Message ----- From: "Gunnar Hellstr=F6m" To: "Paul E. Jones" ; ; Cc: "Henry Sinnreich" ; "Guido Gybels" ; "Mike Spanner" ; ; ; ; "'Rajesh Kumar'" ; ; ; "James Hamlin" ; ; ; ; = ; ; ; ; "Andrea Saks" Sent: Friday, July 18, 2003 6:00 PM Subject: SV: [Sipping] Re: items for vor voting in the BOF > If the outcome of the text discussion in sipdev is what is reported by Paul, > I think it is a reasonable result, and I hope it will have the desired > effect on products and implementations. > > It is true that displays can be arranged in other ways than having it o= n the > telephone itself, so the hook to the presence of a display seems in fac= t > superfluous. > > I am prepared to accept this for now. But I hope that other accessibili= ty > requirements emerge and make the standardised interface to user interfa= ce > devices a reality. That would include the audio channels, that, if provided > without sidetone, can be used either for hearing aid connection or for audio > based textphone connection if there would be any wish to use that mode. > > By the way, most textphone users are nowadays used to let the textphone= do > the dialling and answering, so the use of an audio based textphone on a pure > audio connection will not be understood and appreciated by many users. They > maintain a phonebook in the textphone and let the textphone also act as= an > answering machine. All these functions are lost if you connect it to th= e > audio channels directly. > > When will there be test partners in SIPPIT for the agreed functionality= ? > > Regards > > Gunnar > > ------------------------------------------- > Gunnar Hellstr=F6m, Omnitor, Renathv=E4gen 2 > SE 121 37 Johanneshov, SWEDEN > Tel: +46 8 556 002 03 Mob: +46 708204288 > e-mail: gunnar.hellstrom@omnitor.se > web: www.omnitor.se > > > > -----Ursprungligt meddelande----- > > Fr=E5n: Paul E. Jones [mailto:paulej@packetizer.com] > > Skickat: den 18 juli 2003 17:05 > > Till: guido.gybels@rnid.org.uk; gv@trace.wisc.edu > > Kopia: Henry Sinnreich; Gunnar Hellstrom; Guido Gybels; Mike Spanner; > > andreas.piirimets@omnitor.se; gv@trace.wisc.edu; trefor@trefor.plus.c= om; > > 'Rajesh Kumar'; marcelo@envilogg.se; jorgen.bjorkner@hotsip.com; Jame= s > > Hamlin; Erik.Zetterstrom@omnitor.se; hwildfeu@cisco.com; > > barry.dingle@bigfoot.com.au; mgarakan@cisco.com; oran@cisco.com; > > rohan@cisco.com; sipping@ietf.org; Andrea Saks > > =C4mne: Re: [Sipping] Re: items for vor voting in the BOF > > > > > > Guido, > > > > I wish I could have attended, but I was attending a TDI conference he= re 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 hav= e > > 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 > > > > > _______________________________________________ > > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sippin= g > > > This list is for NEW development of the 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 Jul 28 15:46:06 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 PAA18366 for ; Mon, 28 Jul 2003 15:46: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 19hDw1-0004tQ-Fz for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 15:45:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SJjTlN018802 for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 15:45:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDw1-0004tA-B9 for sipping-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 15:45: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 PAA18223 for ; Mon, 28 Jul 2003 15:45:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hDvr-00075L-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 15:45:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hDvn-00074r-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 15:45:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDvg-0004gR-HI; Mon, 28 Jul 2003 15:45:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19edgY-00042d-EV for sipping@optimus.ietf.org; Mon, 21 Jul 2003 12:38: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 MAA02979 for ; Mon, 21 Jul 2003 12:38:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19edgW-0004Q2-00 for sipping@ietf.org; Mon, 21 Jul 2003 12:38:48 -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 19edgJ-0004OT-00 for sipping@ietf.org; Mon, 21 Jul 2003 12:38:35 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 21 Jul 2003 09:34:11 -0700 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6LGXYh8022504; Mon, 21 Jul 2003 09:33:34 -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 AHV46959; Mon, 21 Jul 2003 09:33:32 -0700 (PDT) Message-Id: <4.3.2.7.2.20030721122729.048f8ae8@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 21 Jul 2003 12:33:32 -0400 To: "Poetzl, Joachim" From: Michael Hammer Subject: Re: AW: AW: AW: AW: [Sipping] Question on INVITE Initiated Dialog Eve nt P ackage and Automatic Callback Cc: rohan@cisco.com, alan.johnston@mci.com, jdrosen@dynamicsoft.com, sipping@ietf.org, jean-marie.stupka@siemens.com In-Reply-To: <53CD1252F68ED61183F5000347AE5F55030AA385@G8PPZ.blf01.telek om.de> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_11314659==_.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: , --=====================_11314659==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Joachim, By your line of reasoning, I would presume that logging any incoming or outgoing calls that failed to complete would also be out of the question. Such a service would be an implementation detail, as not all phones might have that logging feature. That such a feature is not mandated by RFC-3261 and that all phones are not identical does not detract from the market. While the dialog (i.e. the relationship with the far end) has terminated, the saving of any information gleaned during the brief duration of that dialog is not prohibited. Clearing dialog state and clearing derived information are two different things. Mike At 05:17 PM 7/21/2003 +0200, Poetzl, Joachim wrote: >Hi Rohan Mahy, all, > >response to your answer (see below): > >What is the use of standards, RFCs and all the discussions on the list, if >an implementation and any implementer can choose what ever data it/he >want?s to store or not? The behaviour of an implementation should somehow >be predictable and fixed in a document which should state a clear >particular behaviour. > >It is clearly said in 13.2.2.3 of RFC3261, that after having received the >486 a standard SIP client considers the INVITE transaction completed and >all early dialogs are considered terminated upon reception of the non-2xx >final response. > >So there is no freedom to store anything arbitrarily. > >Some views on that? > >Thanks in advance > >--snip > >no. the data about the *dialog* is deleted. You are free to keep >whatever data around you would like. > > > 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. > >it doesn't *have* to keep any data. it *wants* to keep the data, >because it wants to invoke another SIP primitive. > >--snap > > > > >Best Regards > >Joachim Potzl >Deutsche Telekom AG >T-Com Zentrale >T38-13; Signalling, Gateways and Switching Systems >64307 DARMSTADT, GERMANY >Phone: +49 6151 83-2134 >Fax: +49 6151 83-4577 >PCFax: +49 521 52244 983 >mailto:joachim.poetzl@telekom.de > > > > > > > > > > > >-----Ursprungliche Nachricht----- >Von: Rohan Mahy [mailto:rohan@cisco.com] >Gesendet: Sonntag, 20. Juli 2003 05:18 >An: Stupka Jean-Marie >Cc: 'Alan Johnston'; 'Jonathan Rosenberg'; 'sipping@ietf.org' >Betreff: Re: AW: AW: AW: [Sipping] Question on INVITE Initiated Dialog >Event P ackage and Automatic Callback > > > >On Friday, July 18, 2003, at 11:25 AM, Stupka Jean-Marie wrote: > > > Hi Alan, all, > > > > Thanks for your answer. Having seen your comments, I think that my > > previous mail was somewhat unclear. Let me clarify my concerns with > > the flows below. > > > > > > A GW / B > > | | > > | INVITE F1 | > > |--------------->| > > |486 Busy Here F2| > > |<---------------| User B is busy > > | ACK F3 | > > |--------------->| > > | | > > | | > > > > User A calls user B which is either a SIP client (B) or a PSTN > > subscriber behind a Gateway (GW). User B is initially busy when User A > > calls. > > > > The dialog initiated by the INVITE terminates upon reception of the > > 486. After having received the 486, a standard SIP client -- i.e. a > > client compliant to RFC3261 -- considers the INVITE transaction > > completed and generates the ACK for the response (this behavior is > > described in 13.2.2.3 of RFC3261). > > > > 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? > >no. the data about the *dialog* is deleted. You are free to keep >whatever data around you would like. > > > 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. > >it doesn't *have* to keep any data. it *wants* to keep the data, >because it wants to invoke another SIP primitive. > >thanks, >-rohan > > > For the reason above, a procedure is needed to keep the > > dialog/transaction open after a 486. Of course it would only make > > sense to keep the dialog if an automatic callback is possible, e.g. > > not precluded by other services at the remote user side, lacking > > network resources, etc. This should be indicated to the A's SIP UA. If > > automatic callback is possible, then the dialog (the transaction > > having the call data) shall not be terminated upon reception of a 486, > > leaving user A the possibility to request automatic callback. > > If user A does not request automatic callback within a reasonable time > > interval (about 10-15s) the dialog terminates. > > If user A does request automatic callback then a SUBSCRIBE (F4) is > > sent on the already existing dialog that was initiated by the > > preceding INVITE (F1). Sending the SUBSCRIBE within the dialog > > initiated by the INVITE of the preceding call attempt would ease the > > implementation because the call data are available within this dialog > > at the SIP user side and at its peer (e.g. the gateway in the PSTN). > > The call data can then be re-used for the SUBSCRIBE request and for > > the subsequent call when user B gets free. > > > > The flow then looks like this: > > > > > > A GW / B > > | | > > | INVITE F1 | > > |--------------->| > > |486 Busy Here F2| > > |<---------------| User B is busy > > T |(Autom.Callback | T Timer for automatic callback > > | | possible) | | > > | | ACK F3 | | > > | |--------------->| | > > | | | | > > ==> | | | | User A requests automatic callback > > | | | | > > | | SUBSCRIBE F4 | | > > v |--------------->| v > > | 200 OK F5 | > > |<---------------| > > | NOTIFY F6 | > > |<---------------| > > | 200 OK F7 | > > |--------------->| > > | | > > | NOTIFY F8 | <== User B is now available > > |<---------------| > > | 200 OK F9 | > > |--------------->| > > | | > > | INVITE F10 | > > |--------------->| Session setup successfully > > | 180 Ringing F11| > > |<---------------| > > | 200 OK F12 | > > |<---------------| > > | ACK F13 | > > |--------------->| > > | Media Session | > > |<==============>| > > | | > > > > User A calls user B which is either a SIP client (B) or a PSTN > > subscriber behind a Gateway (GW). User B is initially busy when user A > > calls. > > > > - F1 INVITE creates a new dialog between A and GW/B (let's say D1) > > > > - F2 486 Busy Here: automatic callback is possible. > > GW/B indicates to A that automatic callback is possible and starts a > > timer in order to retain the dialog and call data for a possible > > request for automatic callback. > > When receiving a 486 with the indication automatic callback possible, > > A starts a timer in order to retain the dialog and call data giving > > user A the possibility to request automatic callback. > > If the timer expires (no callback request has arrived) then the > > dialog/transaction is terminated at A and GW/B. > > > > - User A requests automatic callback: A stops the timer and sends a > > SUBSCRIBE request to GW/B (F4) within the dialog (D1) initiated by the > > preceding INVITE. There is one hand no necessity to open a new dialog, > > and one the other hand, sending the SUBSCRIBE within the dialog > > initiated by the INVITE of the preceding call attempt would ease the > > implementation because the call data are available within this dialog > > at the SIP user side and at its peer (e.g. the gateway in the PSTN) > > > > - F4 SUBSCRIBE: GW/B stops the timer and starts monitoring B states. > > F5, F6, F7, F8, F9 as in 2.17 of > > draft-ietf-sipping-service-examples-04.txt > > > > - F10 INVITE: A sends the INVITE within the still open dialog (D1) > > initiated by F1 (reason given above) > > > > - F11, etc. as in 2.17 > > > > Summary: > > - There is a need to retain dialogs initiated by an INVITE after a 486 > > message when automatic callback is possible > > - It is desirable that the SUBSCRIBE request and a subsequent call > > set-up triggered by the NOTIFY uses the pre-existing dialog initiated > > by the preceding INVITE. > > > > I hope I have clarified my concerns. > > > > Regards, > > Jean-Marie > > > > > > > >> -----Ursprungliche Nachricht----- > >> Von: Alan Johnston [mailto:alan.johnston@mci.com] > >> Gesendet: Donnerstag, 17. Juli 2003 11:04 > >> An: Stupka Jean-Marie; Rohan Mahy > >> Cc: 'Jonathan Rosenberg'; 'sipping@ietf.org' > >> Betreff: Re: AW: AW: [Sipping] Question on INVITE Initiated > >> Dialog Event > >> Package and Automatic Callback > >> > >> > >> Hi Jean-Marie, > >> > >> Comments below. > >> > >> Thanks, > >> Alan Johnston > >> MCI > >> > >> At 10:21 AM 7/17/2003 +0200, Stupka Jean-Marie wrote: > >>> Hi Alan, > >>> > >>> The flow 2.17 of draft-ietf-sipping-service-examples-04.txt > >> is a good > >>> example to show what is wrong. After the 486 message and the ACK the > >>> transaction is terminated: 13.2.2.3 of RFC3261 says "All > >> early dialogs are > >>> considered terminated upon reception of the non-2xx final response". > >> > >> In this flow, the dialog between Alice and Bob does terminate > >> with the > >> INVITE/486/ACK exchange. However, Bob has a dialog with > >> another user, say > >> Carol (perhaps the flow should show this for clarity?). If > >> Bob was not > >> currently involved in a dialog, the 486 would not have been > >> sent, right? > > > > Right. > > > >> > >>> As a consequence, all data related to the previous call > >> attempt are lost > >>> (why and how long should a SIP client keep this data?). > >> This is at least > >>> conforming RFC3261. > >> > >> Bob is in a dialog with Carol and keeps this dialog state for > >> as long as > >> the session exists (as long as Bob is busy). > > > > Right. > > > >> > >>> Therefore, the SUBSCRIBE message shown in the flow is just > >> not possible, > >>> as the destination address (Bob's address or user number) is no more > >>> existing at the SIP user side. > >> > >> I don't know what you mean here. Bob still exists - he is still > >> sip:bob@biloxi.example.com, right? As a result, Bob can receive a > >> SUBSCRIBE request from Alice. Alice does not specify any > >> call-id, to-tag, > >> or from-tag Event parameters, so that means that Alice is requesting > >> information about ANY dialogs that Bob is currently active > >> in. (Alice is > >> not requesting information about only dialogs with Alice - > >> this information > >> would be redundant since if Alice is in the dialog, Alice > >> would already > >> know the state and dialog identifiers.) All the NOTIFYs that Alice > >> receives provides information about the dialog between Bob and Carol. > >> > > > > See explanation and flows above. > > > >>> Keeping the data for a short period of time after a 486 > >> would help, but I > >>> wouldn't say that this is an implementation matter, the > >> behavior of a SIP > >>> client needs to be predictable, i.e. standardized. > >> > >> Dialog state does need to be kept for 32 seconds after sending a > >> non-success final response in case of the loss of the 486 > >> which would be > >> detected by the failure to receive an ACK. However, this has > >> no bearing on > >> this scenario. > > > > See explanation and flows above. > > > >> > >>> Coming back to my initial concern, the PSTN call completion > >> application > >>> given as an example in > >> draft-ietf-sipping-dialog-package-02.txt. Sending a > >>> SUBSCRIBE to the Dialog Package within the dialog initiated > >> by the INVITE > >>> of the preceding call attempt would ease the implementation > >> because the > >>> call data are available within this dialog at the SIP user > >> side and at its > >>> peer (e.g. the gateway in the PSTN). This is in my understanding the > >>> benefit of draft-ietf-sipping-dialog-package-02.txt. > >> > >> Are you saying that you would like Alice to be able to send a > >> SUBSCRIBE to > >> Bob within the dialog between Bob and Carol? This is not > >> possible - a > >> dialog is between two peers - a third party can not inject messages. > >> > > > > Of course not, see explanation and flows above. > > > >> > >>> A possible solution would be to keep for a short period of > >> time the dialog > >>> with the data of the previous call attempt (i.e. the called > >> user number, > >>> the bearer description, ...) at the user agent after a 486 > >> is received if > >>> an automatic callback is possible (e.g. not precluded by > >> other services at > >>> the remote user side, lacking network resources, etc.). > >> > >> Are you perhaps concerned about authorizing the subscription? > >> That is, Bob > >> only accepts a SUBSCRIBE from Alice if Alice has previously > >> just made a > >> call attempt (sent an INVITE and received a 486 busy)? If > >> this is what you > >> want, I'm not sure the exact benefit of this. > > > > Not at all my concern. > > > >> > >>> Then the called user number and other data from the > >> preceding call attempt > >>> could be re-used for the SUBSCRIBE request and for the > >> subsequent call > >>> when the remote user gets free. This would require to extend > >> the 486 with > >>> a "Automatic Callback Possible" indication, or to introduce > >> a new message > >>> with this meaning and the procedure of retaining data - a > >> change to RFC3261. > >>> > >>> Any view on that? > >>> > >>> Thanks, > >>> Jean-Marie > >>> > >>> > >>> -----Ursprungliche Nachricht----- > >>> Von: Alan Johnston [mailto:alan.johnston@mci.com] > >>> Gesendet: Mittwoch, 16. Juli 2003 20:39 > >>> An: Rohan Mahy; Stupka Jean-Marie > >>> Cc: 'Jonathan Rosenberg'; 'sipping@ietf.org' > >>> Betreff: Re: AW: [Sipping] Question on INVITE Initiated Dialog Event > >>> Package a nd Automatic C allback > >>> > >>> > >>> Hi Jean-Marie, > >>> > >>> The SIP Service Examples section 2.17 shows exactly this flow with a > >>> SUBSCRIBE outside of the dialog (which ended with the 486). > >>> > >>> Thanks, > >>> Alan Johnston > >>> MCI > >>> > >>> At 05:21 AM 7/15/2003 -0700, Rohan Mahy wrote: > >>>> Jean-Marie, > >>>> > >>>> It seems perfectly reasonable to send a SUBSCRIBE to the > >> dialog package > >>>> outside of a dialog. The default behavior would be to > >> send a list of > >>>> dialogs but with no dialog information or peer > >> information. I believe > >>>> this is sufficient to build a callback service. > >>>> > >>>> thanks, > >>>> -rohan > >>>> > >>>> > >>>> > >>>> On Tuesday, July 15, 2003, at 02:53 AM, Stupka Jean-Marie wrote: > >>>> > >>>>> Jonathan, > >>>>> > >>>>> I doubt that sending the SUBSCRIBE request for the dialog > >> package outside > >>>>> of any dialog is possible in case of automatic callback, since the > >>>>> required data are no more available. > >>>>> > >>>>> The problem is that when a 486 is received, the dialog > >> initiated by the > >>>>> INVITE terminates and, the data related to that dialog > >> (including the > >>>>> called user number) disappear. Therefore it is no more > >> possible to send > >>>>> the SUBSCRIBE to request automatic callback for this destination. > >>>>> > >>>>> A possible solution would be to keep for a short period > >> of time the data > >>>>> of the previous call attempt (i.e. the called user > >> number, the bearer > >>>>> description, ...) at the user agent after a 486 is > >> received. This would > >>>>> allow the user agent to re-use the called user number and > >> other data from > >>>>> the preceding call attempt for the SUBSCRIBE request and for the > >>>>> subsequent call after the remote user is free. However, > >> the procedure of > >>>>> retaining data is not foreseen in RFC 3261. > >>>>> > >>>>> A better (more economical and user friendly) solution > >> would be to keep at > >>>>> the user agent only when an automatic callback is > >> possible (e.g. not > >>>>> precluded by other services at the remote user side, > >> lacking network > >>>>> resources, etc.). This would require to extend the 486 > >> with a "Automatic > >>>>> Callback Possible" indication, or to introduce a new > >> message with this > >>> meaning. > >>>>> > >>>>> Jean-Marie > >>>>> > >>>>> -----Ursprungliche Nachricht----- > >>>>> Von: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > >>>>> Gesendet: Montag, 14. Juli 2003 10:18 > >>>>> An: Stupka Jean-Marie > >>>>> Cc: 'sipping@ietf.org' > >>>>> Betreff: Re: [Sipping] Question on INVITE Initiated > >> Dialog Event Package > >>>>> and Automatic C allback > >>>>> > >>>>> > >>>>> The dialog package can be used by subscriptions made both > >> within, and > >>>>> outside, of a dialog. So, in the case of automatic callback, the > >>>>> caller would, after receiving a 486, send a SUBSCRIBE > >> request for the > >>>>> dialog package, and do so outside of any dialog. > >>>>> > >>>>> -Jonathan R. > >>>>> > >>>>> Stupka Jean-Marie wrote: > >>>>> > >>>>>> Hello All, > >>>>>> > >>>>>> As said in RFC 3265 it is possible to create an event > >> subscription > >>>>>> within a pre-existing dialog, e.g. a dialog created by an INVITE. > >>>>>> In my understanding, this is the intention of > >>>>>> draft-ietf-sipping-dialog-package-02.txt. > >>>>>> > >>>>>> According to the (PSTN) Automatic Callback given as example > >>>>>> application in the introduction of this draft, user A > >> can request a > >>>>>> callback when user B hangs-up. User A off course needs to get the > >>>>>> information that user B is busy before requesting the automatic > >>>>>> callback, i.e. receive a "486 Busy Here" message. However, all > >>>>>> early dialogs are considered terminated upon reception > >> of a non-2xx > >>>>>> final response (13.2.2.3 of RFC 3261). As consequence, the dialog > >>>>>> and thus the data of the preceding call attempt are no more > >>>>>> available and the callback cannot be requested. > >>>>>> > >>>>>> Can somebody provide clarification of the applicability > >> of RFC 3265 > >>>>>> and the draft-ietf-sipping-dialog-package-02.txt to Automatic > >>>>>> Callback? > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>>> Jean-Marie > >>>>>> > >>>>>> > >>>>>> _______________________________________________ Sipping mailing > >>>>>> list https://www1.ietf.org/mailman/listinfo/sipping This list is > >>>>>> for NEW development of the 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 > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP --=====================_11314659==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Joachim,

By your line of reasoning, I would presume that logging any incoming or outgoing calls that failed to complete would also be out of the question.  Such a service would be an implementation detail, as not all phones might have that logging feature.  That such a feature is not mandated by RFC-3261 and that all phones are not identical does not detract from the market.

While the dialog (i.e. the relationship with the far end) has terminated, the saving of any information gleaned during the brief duration of that dialog is not prohibited.  Clearing dialog state and clearing derived information are two different things.

Mike


At 05:17 PM 7/21/2003 +0200, Poetzl, Joachim wrote:
Hi Rohan Mahy, all,

response to your answer (see below):

What is the use of standards, RFCs and all the discussions on the list, if an implementation and any implementer can choose what ever data it/he want?s to store or not? The behaviour of an implementation should somehow be predictable and fixed in a document which should state a clear particular behaviour.

It is clearly said in 13.2.2.3 of RFC3261, that after having received the 486 a standard SIP client considers the INVITE transaction completed and all early dialogs are considered terminated upon reception of the non-2xx final response.

So there is no freedom to store anything arbitrarily.

Some views on that?

Thanks in advance

--snip

no.  the data about the *dialog* is deleted. You are free to keep
whatever data around you would like.

> 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.

it doesn't *have* to keep any data.  it *wants* to keep the data,
because it wants to invoke another SIP primitive.

--snap




Best Regards
 
Joachim Potzl
Deutsche Telekom AG
T-Com Zentrale
T38-13; Signalling, Gateways and Switching Systems
64307 DARMSTADT, GERMANY
Phone:  +49 6151 83-2134
Fax:      +49 6151 83-4577
PCFax:  +49 521 52244 983
mailto:joachim.poetzl@telekom.de











-----Ursprungliche Nachricht-----
Von: Rohan Mahy [mailto:rohan@cisco.com]
Gesendet: Sonntag, 20. Juli 2003 05:18
An: Stupka Jean-Marie
Cc: 'Alan Johnston'; 'Jonathan Rosenberg'; 'sipping@ietf.org'
Betreff: Re: AW: AW: AW: [Sipping] Question on INVITE Initiated Dialog
Event P ackage and Automatic Callback



On Friday, July 18, 2003, at 11:25 AM, Stupka Jean-Marie wrote:

> Hi Alan, all,
>
> Thanks for your answer. Having seen your comments, I think that my
> previous mail was somewhat unclear. Let me clarify my concerns with
> the flows below.
>
>
>           A             GW / B
>           |            &nb= sp;   |
>           |    INVITE F1   |
>           |--------------->|
>           |486 Busy Here F2|
>           |<---------------|    User B is busy
>           |     ACK F3     |
>           |--------------->|
>           |            &nb= sp;   |
>           |            &nb= sp;   |
>
> User A calls user B which is either a SIP client (B) or a PSTN=20
> subscriber behind a Gateway (GW). User B is initially busy when User A
> calls.
>
> The dialog initiated by the INVITE terminates upon reception of the
> 486. After having received the 486, a standard SIP client -- i.e. a
> client compliant to RFC3261 -- considers the INVITE transaction
> completed and generates the ACK for the response (this behavior is
> described in 13.2.2.3 of RFC3261).
>
> 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?

no.  the data about the *dialog* is deleted. You are free to keep
whatever data around you would like.

> 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.

it doesn't *have* to keep any data.  it *wants* to keep the data,
because it wants to invoke another SIP primitive.

thanks,
-rohan

> For the reason above, a procedure is needed to keep the
> dialog/transaction open after a 486. Of course it would only make
> sense to keep the dialog if an automatic callback is possible, e.g.
> not precluded by other services at the remote user side, lacking
> network resources, etc. This should be indicated to the A's SIP UA. If
> automatic callback is possible, then the dialog (the transaction
> having the call data) shall not be terminated upon reception of a 486,
> leaving user A the possibility to request automatic callback.
> If user A does not request automatic callback within a reasonable time
> interval (about 10-15s) the dialog terminates.
> If user A does request automatic callback then a SUBSCRIBE (F4) is
> sent on the already existing dialog that was initiated by the
> preceding INVITE (F1). Sending the SUBSCRIBE within the dialog=20
> initiated by the INVITE of the preceding call attempt would ease the
> implementation because the call data are available within this dialog
> at the SIP user side and at its peer (e.g. the gateway in the PSTN).
> The call data can then be re-used for the SUBSCRIBE request and for
> the subsequent call when user B gets free.
>
> The flow then looks like this:
>
>
>           A             GW / B
>           |            &nb= sp;   |
>           |    INVITE F1   |
>           |--------------->|
>           |486 Busy Here F2|
>           |<---------------|      User B is busy
>      T    |(Autom.Callback |   T  Timer for automatic callback
>      |    |   possible)    |   |
>      |    |     ACK F3     |   |
>      |    |--------------->|   |
>      |    |            &nb= sp;   |   |
> =3D=3D>  |    |            &nb= sp;   |   |  User A requests automatic callback
>      |    |            &nb= sp;   |   |
>      |    |  SUBSCRIBE F4  |   |
>      v    |--------------->|   v
>           |   200 OK F5    |
>           |<---------------|
>           |    NOTIFY F6   |
>           |<---------------|
>           |   200 OK F7    |
>           |--------------->|
>           |            &nb= sp;   |
>           |    NOTIFY F8   |  <=3D=3D User B is now available
>           |<---------------|
>           |   200 OK F9    |
>           |--------------->|
>           |            &nb= sp;   |
>           |   INVITE F10   |
>           |--------------->|      Session setup successfully
>           | 180 Ringing F11|
>           |<---------------|
>           |   200 OK F12   |
>           |<---------------|
>           |     ACK F13    |
>           |--------------->|
>           |  Media Session |
>           |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|
>           |            &nb= sp;   |
>
> User A calls user B which is either a SIP client (B) or a PSTN=20
> subscriber behind a Gateway (GW). User B is initially busy when user A
> calls.
>
> - F1 INVITE creates a new dialog between A and GW/B (let's say D1)
>
> - F2 486 Busy Here: automatic callback is possible.
> GW/B indicates to A that automatic callback is possible and starts a
> timer in order to retain the dialog and call data for a possible
> request for automatic callback.
> When receiving a 486 with the indication automatic callback possible,
> A starts a timer in order to retain the dialog and call data giving
> user A the possibility to request automatic callback.
> If the timer expires (no callback request has arrived) then the
> dialog/transaction is terminated at A and GW/B.
>
> - User A requests automatic callback: A stops the timer and sends a
> SUBSCRIBE request to GW/B (F4) within the dialog (D1) initiated by the
> preceding INVITE. There is one hand no necessity to open a new dialog,
> and one the other hand, sending the SUBSCRIBE within the dialog
> initiated by the INVITE of the preceding call attempt would ease the
> implementation because the call data are available within this dialog
> at the SIP user side and at its peer (e.g. the gateway in the PSTN)
>
> - F4 SUBSCRIBE: GW/B stops the timer and starts monitoring B states.
> F5, F6, F7, F8, F9 as in 2.17 of
> draft-ietf-sipping-service-examples-04.txt
>
> - F10 INVITE: A sends the INVITE within the still open dialog (D1)
> initiated by F1 (reason given above)
>
> - F11, etc. as in 2.17
>
> Summary:
> - There is a need to retain dialogs initiated by an INVITE after a 486
> message when automatic callback is possible
> - It is desirable that the SUBSCRIBE request and a subsequent call
> set-up triggered by the NOTIFY uses the pre-existing dialog initiated
> by the preceding INVITE.
>
> I hope I have clarified my concerns.
>
> Regards,
> Jean-Marie
>
>
>
>> -----Ursprungliche Nachricht-----
>> Von: Alan Johnston [mailto:alan.johnston@mci.com]
>> Gesendet: Donnerstag, 17. Juli 2003 11:04
>> An: Stupka Jean-Marie; Rohan Mahy
>> Cc: 'Jonathan Rosenberg'; 'sipping@ietf.org'
>> Betreff: Re: AW: AW: [Sipping] Question on INVITE=20 Initiated
>> Dialog Event
>> Package and Automatic Callback
>>
>>
>> Hi Jean-Marie,
>>
>> Comments below.
>>
>> Thanks,
>> Alan Johnston
>> MCI
>>
>> At 10:21 AM 7/17/2003 +0200, Stupka Jean-Marie wrote:
>>> Hi Alan,
>>>
>>> The flow 2.17 of draft-ietf-sipping-service-examples-04.txt
>> is a good
>>> example to show what is wrong. After the 486 message and the ACK the
>>> transaction is terminated: 13.2.2.3 of RFC3261 says "All
>> early dialogs are
>>> considered terminated upon reception of the non-2xx final response".
>>
>> In this flow, the dialog between Alice and Bob does terminate
>> with the
>> INVITE/486/ACK exchange.  However, Bob has a dialog with
>> another user, say
>> Carol (perhaps the flow should show this for clarity?).  If
>> Bob was not
>> currently involved in a dialog, the 486 would not have=20 been
>> sent, right?
>
> Right.
>
>>
>>>  As a consequence, all data related to the previous call
>> attempt are lost
>>> (why and how long should a SIP client keep this=20 data?).
>> This is at least
>>> conforming RFC3261.
>>
>> Bob is in a dialog with Carol and keeps this dialog state for
>> as long as
>> the session exists (as long as Bob is busy).
>
> Right.
>
>>
>>> Therefore, the SUBSCRIBE message shown in the flow is just
>> not possible,
>>> as the destination address (Bob's address or user number) is no more
>>> existing at the SIP user side.
>>
>> I don't know what you mean here.  Bob still exists - he is still
>> sip:bob@biloxi.example.com, right?  As a result, Bob can receive a
>> SUBSCRIBE request from Alice.  Alice does not specify any
>> call-id, to-tag,
>> or from-tag Event parameters, so that means that Alice is requesting
>> information about ANY dialogs that Bob is currently active
>> in.  (Alice is
>> not requesting information about only dialogs with Alice -
>> this information
>> would be redundant since if Alice is in the dialog, Alice
>> would already
>> know the state and dialog identifiers.)  All the NOTIFYs that Alice
>> receives provides information about the dialog between Bob and Carol.
>>
>
> See explanation and flows above.
>
>>> Keeping the data for a short period of time after a=20 486
>> would help, but I
>>> wouldn't say that this is an implementation matter,=20 the
>> behavior of a SIP
>>> client needs to be predictable, i.e. standardized.
>>
>> Dialog state does need to be kept for 32 seconds after sending a
>> non-success final response in case of the loss of the 486
>> which would be
>> detected by the failure to receive an ACK.  However, this has
>> no bearing on
>> this scenario.
>
> See explanation and flows above.
>
>>
>>> Coming back to my initial concern, the PSTN call completion
>> application
>>> given as an example in
>> draft-ietf-sipping-dialog-package-02.txt. Sending a
>>> SUBSCRIBE to the Dialog Package within the dialog initiated
>> by the INVITE
>>> of the preceding call attempt would ease the implementation
>> because the
>>> call data are available within this dialog at the SIP user
>> side and at its
>>> peer (e.g. the gateway in the PSTN). This is in my understanding the
>>> benefit of draft-ietf-sipping-dialog-package-02.txt.
>>
>> Are you saying that you would like Alice to be able to send a
>> SUBSCRIBE to
>> Bob within the dialog between Bob and Carol?  This is not
>> possible - a
>> dialog is between two peers - a third party can not inject messages.
>>
>
> Of course not, see explanation and flows above.
>
>>
>>> A possible solution would be to keep for a short period of
>> time the dialog
>>> with the data of the previous call attempt (i.e. the called
>> user number,
>>> the bearer description, ...) at the user agent after a 486
>> is received if
>>> an automatic callback is possible (e.g. not precluded by
>> other services at
>>> the remote user side, lacking network resources,=20 etc.).
>>
>> Are you perhaps concerned about authorizing the subscription?
>>  That is, Bob
>> only accepts a SUBSCRIBE from Alice if Alice has=20 previously
>> just made a
>> call attempt (sent an INVITE and received a 486 busy)?  If
>> this is what you
>> want, I'm not sure the exact benefit of this.
>
> Not at all my concern.
>
>>
>>> Then the called user number and other data from the
>> preceding call attempt
>>> could be re-used for the SUBSCRIBE request and for the
>> subsequent call
>>> when the remote user gets free. This would require to extend
>> the 486 with
>>> a "Automatic Callback Possible" indication, or to introduce
>> a new message
>>> with this meaning and the procedure of retaining data - a
>> change to RFC3261.
>>>
>>> Any view on that?
>>>
>>> Thanks,
>>> Jean-Marie
>>>
>>>
>>> -----Ursprungliche Nachricht-----
>>> Von: Alan Johnston [mailto:alan.johnston@mci.com]
>>> Gesendet: Mittwoch, 16. Juli 2003 20:39
>>> An: Rohan Mahy; Stupka Jean-Marie
>>> Cc: 'Jonathan Rosenberg'; 'sipping@ietf.org'
>>> Betreff: Re: AW: [Sipping] Question on INVITE Initiated Dialog Event
>>> Package a nd Automatic C allback
>>>
>>>
>>> Hi Jean-Marie,
>>>
>>> The SIP Service Examples section 2.17 shows exactly this flow with a
>>> SUBSCRIBE outside of the dialog (which ended with the 486).
>>>
>>> Thanks,
>>> Alan Johnston
>>> MCI
>>>
>>> At 05:21 AM 7/15/2003 -0700, Rohan Mahy wrote:
>>>> Jean-Marie,
>>>>
>>>> It seems perfectly reasonable to send a SUBSCRIBE to the
>> dialog package
>>>> outside of a dialog.  The default behavior would be to
>> send a list of
>>>> dialogs but with no dialog information or peer
>> information.  I believe
>>>> this is sufficient to build a callback service.
>>>>
>>>> thanks,
>>>> -rohan
>>>>
>>>>
>>>>
>>>> On Tuesday, July 15, 2003, at 02:53 AM, Stupka Jean-Marie wrote:
>>>>
>>>>> Jonathan,
>>>>>
>>>>> I doubt that sending the SUBSCRIBE request for the dialog
>> package outside
>>>>> of any dialog is possible in case of automatic callback, since the
>>>>> required data are no more available.
>>>>>
>>>>> The problem is that when a 486 is received, the dialog
>> initiated by the
>>>>> INVITE terminates and, the data related to that dialog
>> (including the
>>>>> called user number) disappear. Therefore it is no more
>> possible to send
>>>>> the SUBSCRIBE to request automatic callback for this destination.
>>>>>
>>>>> A possible solution would be to keep for a short period
>> of time the data
>>>>> of the previous call attempt (i.e. the called user
>> number, the bearer
>>>>> description, ...) at the user agent after a 486 is
>> received. This would
>>>>> allow the user agent to re-use the called user number and
>> other data from
>>>>> the preceding call attempt for the SUBSCRIBE request and for the
>>>>> subsequent call after the remote user is free. However,
>> the procedure of
>>>>> retaining data is not foreseen in RFC 3261.
>>>>>
>>>>> A better (more economical and user friendly) solution
>> would be to keep at
>>>>> the user agent only when an automatic callback is
>> possible (e.g. not
>>>>> precluded by other services at the remote user side,
>> lacking network
>>>>> resources, etc.). This would require to extend the 486
>> with a "Automatic
>>>>> Callback Possible" indication, or to introduce a new
>> message with this
>>> meaning.
>>>>>
>>>>> Jean-Marie
>>>>>
>>>>> -----Ursprungliche Nachricht-----
>>>>> Von: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
>>>>> Gesendet: Montag, 14. Juli 2003 10:18
>>>>> An: Stupka Jean-Marie
>>>>> Cc: 'sipping@ietf.org'
>>>>> Betreff: Re: [Sipping] Question on INVITE Initiated
>> Dialog Event Package
>>>>> and Automatic C allback
>>>>>
>>>>>
>>>>> The dialog package can be used by subscriptions made both
>> within, and
>>>>> outside, of a dialog. So, in the case of automatic callback, the
>>>>> caller would, after receiving a 486, send a SUBSCRIBE
>> request for the
>>>>> dialog package, and do so outside of any dialog.
>>>>>
>>>>> -Jonathan R.
>>>>>
>>>>> Stupka Jean-Marie wrote:
>>>>>
>>>>>> Hello All,
>>>>>>
>>>>>> As said in RFC 3265 it is possible to create an event
>> subscription
>>>>>> within a pre-existing dialog, e.g. a dialog created by an INVITE.
>>>>>> In my understanding, this is the intention of
>>>>>> draft-ietf-sipping-dialog-package-02.txt.
>>>>>>
>>>>>> According to the (PSTN) Automatic Callback given as example
>>>>>> application in the introduction of this draft, user A
>> can request a
>>>>>> callback when user B hangs-up. User A off course needs to get the
>>>>>> information that user B is busy before requesting the automatic
>>>>>> callback, i.e. receive a "486 Busy Here" message. However, all
>>>>>> early dialogs are considered terminated upon reception
>> of a non-2xx
>>>>>> final response (13.2.2.3 of RFC 3261). As consequence, the dialog
>>>>>> and thus the data of the preceding call attempt are no more
>>>>>> available and the callback cannot be requested.
>>>>>>
>>>>>> Can somebody provide clarification of the applicability
>> of RFC 3265
>>>>>> and the draft-ietf-sipping-dialog-package-02.txt to Automatic
>>>>>> Callback?
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Jean-Marie
>>>>>>
>>>>>>
>>>>>> _______________________________________________ Sipping mailing
>>>>>> list  https://www1.ietf.org/mailman/listinfo/sipping This list is
>>>>>> for NEW development of the 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.           &nbs= p;    600 Lanidex Plaza
>>>>> Chief Technology= Officer           &n= bsp;        Parsippany,
>> NJ 07054-2711
>>>>> dynamicsoft
>>>>>= jdrosen@dynamicsoft.com        &nbs= p;           = FAX:   (973) 952-5050
>>>>> http://www.jdrosen.net     &nbs= p;            &n= bsp;  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

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP=
=00 --=====================_11314659==_.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 Mon Jul 28 15:46: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 PAA18458 for ; Mon, 28 Jul 2003 15:46: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 19hDwH-0004ws-E1 for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 15:45:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SJjjLC019018 for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 15:45:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDwH-0004we-9y for sipping-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 15: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 PAA18280 for ; Mon, 28 Jul 2003 15:45:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hDwE-00076c-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 15:45:42 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hDvx-00074s-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 15:45:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDva-0004cu-6R; Mon, 28 Jul 2003 15: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 19dJVg-0008MA-2O for sipping@optimus.ietf.org; Thu, 17 Jul 2003 20:54: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 UAA28992 for ; Thu, 17 Jul 2003 20:54:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dJVd-00034G-00 for sipping@ietf.org; Thu, 17 Jul 2003 20:54:05 -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 19dJVT-00033u-00 for sipping@ietf.org; Thu, 17 Jul 2003 20:53:55 -0400 Received: from berlin (berlin.packetizer.org [192.168.1.4]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id h6I0qdMd031488; Thu, 17 Jul 2003 20:52:39 -0400 Message-ID: <038d01c34cc6$e4a9ba70$0401a8c0@packetizer.org> From: "Paul E. Jones" To: , Cc: "'Henry Sinnreich'" , "'Gunnar Hellstrom'" , , , , , , "'Rajesh Kumar'" , , , "'James Hamlin'" , , , , , , , , "Andrea Saks" References: <60ab7dbc.a335acbc.8165f00@imap01.eu.blackberry.net> Date: Thu, 17 Jul 2003 20:52:38 -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: items for vor voting in the BOF Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 Guido, While I guess it might be a bit late now, I still disagree that Gunnar's original question #3 is acceptable. It spoke only of RJ-11, got off onto a fax (T.38) tangent, etc. We need to know a few things quite explicitly: 1) Do we or do we not want to allow for the interconnection of a legacy TTY device. (This is separate from the method of connection.) If so, (and I argue that we do): 2) Do we terminate the TTY signal and send RFC 2793? 3) Do we allow the TTY signal to be passed through as audio? 3) Do we want to provide an RJ-11 for interconnection? 4) Do we want to provide a 2.5mm audio jack for interconnection? Each of these should be answered independently and hinge on (1), which I would guess most people will say "yes" to, while I know you'd say "no" to it. Providing an IP phone that allows an interconnection to a TTY device with a 2.5mm audio jack and passing the media over the voice path, for example, while not the exact step you want to take, will likely lead to a higher assurance that all phones are accessible. I just do not believe we will see every phone manufacturer supporting RFC 2793 and providing some textual input method (screen and keyboard). Paul ----- Original Message ----- From: "Guido Gybels" To: Cc: "'Henry Sinnreich'" ; "'Gunnar Hellstrom'" ; ; ; ; ; ; "'Rajesh Kumar'" ; ; ; "'James Hamlin'" ; ; ; ; ; ; ; ; Sent: Monday, July 14, 2003 4:47 AM Subject: RE: items for vor voting in the BOF > Gregg, > > I think Gunnar's version was quite clear and straight > forward, I don't think we should complicate things any > further. So, I would suggest we use Gunnar's version. > > Guido > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 28 15:46: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 PAA18463 for ; Mon, 28 Jul 2003 15:46: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 19hDwH-0004xU-TK for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 15:45:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SJjjFA019053 for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 15:45:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDwH-0004x4-Ow for sipping-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 15: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 PAA18300 for ; Mon, 28 Jul 2003 15:45:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hDwF-00076j-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 15:45:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hDvx-00074u-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 15:45:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDvi-0004hH-9X; Mon, 28 Jul 2003 15:45:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ezIa-0003xT-E3 for sipping@optimus.ietf.org; Tue, 22 Jul 2003 11:43: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 LAA17781 for ; Tue, 22 Jul 2003 11:43:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ezIZ-0005Za-00 for sipping@ietf.org; Tue, 22 Jul 2003 11:43:31 -0400 Received: from eins.siemens.at ([193.81.246.11]) by ietf-mx with esmtp (Exim 4.12) id 19ezIO-0005Z9-00 for sipping@ietf.org; Tue, 22 Jul 2003 11:43:20 -0400 Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id h6MFgLcJ030519 for ; Tue, 22 Jul 2003 17:42:21 +0200 Received: from vies141a.sie.siemens.at (atws15tc.sie.siemens.at [158.226.135.41]) by scesie13.sie.siemens.at (8.12.9/8.12.1) with ESMTP id h6MFgJmv014091 for ; Tue, 22 Jul 2003 17:42:20 +0200 (MET DST) Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jul 2003 17:43:25 +0200 Message-ID: From: Stach Thomas To: "'sipping@ietf.org'" Subject: [Sipping] WGLC for Q.SIP-SIP mapping draft Date: Tue, 22 Jul 2003 17:43:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35067.F8EDBF50" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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_01C35067.F8EDBF50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello John, I had a detailed look into the qsig2sip draft, and found only some = minor issues, which can easily be clarifed. In my opinion the draft is mature = and should take its way onwards. In Section 8.1 4th para is stated: "The processing of any valid QSIG message that does not satisfy any of=20 these conditions is outside the scope of this specification." This seems to be a little bit vague for somebody not familiar with = QSIG.=20 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]." 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." Editorial nits & bits: Page 2: new www address of ECMA www.ecma-international.org There are spurious non-ASCII characters in the text. I found some at = the following places: Captions of all figures 1-14 just after the figure numbers. Captions of all tables 1-4 just after the table numbers. Page 13: Section 8.2.1.1 4th para last line after "value 28 =F4" and = "(address incomplete)=F6"=20 Page 13: Section 8.2.1.3 2nd para: delete the comma in (e.g., ring-back tone)=20 Page 35: caption of table 3 p. 35 "for =E6audio=C6 transfer"=20 Page 35: in table 4 replace .-law by mu-law Page 39: The references in section 13 show non-ASCII in items 1,13,14 = (2x), 17, 19 Page 40: "Annex A (informative) =FB Example ...", see also the = corresponding line in the TOC (page 4) Figures 1, 3, 5, 6 (caption), 8, 9, 11, 12 are stretching across a page break. May be you want to start them on top of the next page.=20 Figure 9 shows unnecessary line breaks between "IP" and "NETWORK" and = before ">|4" and "|5"=20 RFC 3261 is references by its item number from the Reference list i.e. = [10] as well as by "RFC-3261" (4x). May be you want to change the latter = also to [10]. There are several orphan headings/widow lines on the bottom/top of a = page. May be you want to put them on top/bottom of the next/previous page. E.g. 8.2.1.1, 8.2.2.1, 8.2.2.2.2., 8.2.2.2.6, 9.1.3.1, 11, 13 (e-mail address) Regards Thomas=20 ------_=_NextPart_001_01C35067.F8EDBF50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1My4xMiI+DQo8VElUTEU+IFtTaXBw aW5nXSBXR0xDIGZvciBRLlNJUC1TSVAgbWFwcGluZyBkcmFmdDwvVElUTEU+DQo8L0hFQUQ+DQo8 Qk9EWT4NCg0KPFA+PEZPTlQgU0laRT0yPkhlbGxvIEpvaG4sPC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj5JIGhhZCBhIGRldGFpbGVkIGxvb2sgaW50byB0aGUgcXNpZzJzaXAgZHJhZnQsIGFuZCBm b3VuZCBvbmx5IHNvbWUgbWlub3IgaXNzdWVzLCB3aGljaCBjYW4gZWFzaWx5IGJlIGNsYXJpZmVk LiBJbiBteSBvcGluaW9uIHRoZSBkcmFmdCBpcyBtYXR1cmUgYW5kIHNob3VsZCB0YWtlIGl0cyB3 YXkgb253YXJkcy48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+SW4gU2VjdGlvbiA4LjEg NHRoIHBhcmEgaXMgc3RhdGVkOjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+JnF1b3Q7VGhlIHBy b2Nlc3Npbmcgb2YgYW55IHZhbGlkIFFTSUcgbWVzc2FnZSB0aGF0IGRvZXMgbm90IHNhdGlzZnkg YW55IG9mIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+dGhlc2UgY29uZGl0aW9ucyBpcyBvdXRz aWRlIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24uJnF1b3Q7PC9GT05UPg0KPEJSPjxG T05UIFNJWkU9Mj5UaGlzIHNlZW1zIHRvIGJlIGEgbGl0dGxlIGJpdCB2YWd1ZSBmb3Igc29tZWJv ZHkgbm90IGZhbWlsaWFyIHdpdGggUVNJRy4gPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5TaW5j ZSB0aGUgaW50ZXJ3b3JraW5nIG9ubHkgY29tcHJpc2VzIFFTSUcgQmFzaWMgQ2FsbCwgeW91IGNv dWxkIGJlIG1vcmUgc3BlY2lmaWMgYW5kIG1lbnRpb24gdGhlIHVuY29uc2lkZXJlZCBmZWF0dXJl cyBwcm92aWRlZCBieSBJU08gMTE1ODIgYnkgYWRkaW5nOjwvRk9OVD48L1A+DQoNCjxQPjxGT05U IFNJWkU9Mj4mcXVvdDtUaGlzIGluY2x1ZGVzIGEgUVNJRyBTRVRVUCBtZXNzYWdlIGludGVuZGVk IHRvIGVzdGFibGlzaCBhIGNhbGwtaW5kZXBlbmRlbnQgc2lnbmFsbGluZyBjb25uZWN0aW9uIGFu ZCZuYnNwOyBjb25uZWN0aW9ubGVzcyB0cmFuc3BvcnQgYXMgc3BlY2lmaWVkIGluIFszXS4mcXVv dDs8L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+VGhlIFFTSUcgU0VUVVAgbWVzc2FnZSBt YXkgb3B0aW9uYWxseSB0cmFuc3BvcnQgSExDIGFuZCBMTEMgSW5mb3JtYXRpb24gZWxlbWVudHMg d2hpY2ggYXJlIG5vdCBtZW50aW9uZWQgaW4gdGhlIGRyYWZ0LiBZb3UgbWlnaHQgd2FudCB0byBh ZGQgc29tZXRoaW5nIGxpa2UgaW50byBzZWN0aW9uIDEwOjwvRk9OVD48L1A+DQoNCjxQPjxGT05U IFNJWkU9Mj4mcXVvdDtUaGUgZ2F0ZXdheSBTSE9VTEQgKG9yIFNIQUxMKD8pKSBub3QgaW5jbHVk ZSBhIExvdyBsYXllciBjb21wYXRpYmlsaXR5IGluIHRoZSBRU0lHIFNFVFVQIG1lc3NhZ2UuIFRo ZSBnYXRld2F5IFNIT1VMRCBub3QgaW5jbHVkZSBhIEhpZ2ggbGF5ZXIgY29tcGF0aWJpbGl0eSBp bmZvcm1hdGlvbiBlbGVtZW50IGluIHRoZSBRU0lHIFNFVFVQIG1lc3NhZ2UuPC9GT05UPjwvUD4N Cg0KPFA+PEZPTlQgU0laRT0yPk5PVEU6IEluY2x1c2lvbiBvZiBhIEhMQyBpbiB0aGUgUVNJRyBT RVRVUCBtZXNzYWdlIG1pZ2h0IGJlIHVzZWZ1bCwgaWYgdGhlIGdhdGV3YXkga25vd3MgcHJpb3Ig dG8gc2VuZGluZyB0aGUgUVNJRyBTRVRVUCBtZXNzYWdlIHRoYXQgZmF4IGlzIGJlaW5nIHRyYW5z bWl0dGVkIChlLmcuLCBiZWNhdXNlIG9mIGEgY29ycmVzcG9uZGluZyBTRFAgb2ZmZXIpLCBpdCBt YXkgaW5jbHVkZSBpbiB0aGUgUVNJRyBTRVRVUCBtZXNzYWdlIGEgSGlnaCBsYXllciBjb21wYXRp YmlsaXR5IGluZm9ybWF0aW9uIGVsZW1lbnQgaW5kaWNhdGluZyBncm91cCAzIGZheC4mcXVvdDs8 L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+RWRpdG9yaWFsIG5pdHMgJmFtcDsgYml0czo8 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlBhZ2UgMjogbmV3IHd3dyBhZGRyZXNzIG9mIEVDTUEg d3d3LmVjbWEtaW50ZXJuYXRpb25hbC5vcmc8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9 Mj5UaGVyZSBhcmUgc3B1cmlvdXMgbm9uLUFTQ0lJIGNoYXJhY3RlcnMgaW4gdGhlIHRleHQuIEkg Zm91bmQgc29tZSBhdCB0aGUgZm9sbG93aW5nIHBsYWNlczo8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la RT0yPkNhcHRpb25zIG9mIGFsbCBmaWd1cmVzIDEtMTQganVzdCBhZnRlciB0aGUgZmlndXJlIG51 bWJlcnMuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5DYXB0aW9ucyBvZiBhbGwgdGFibGVzIDEt NCBqdXN0IGFmdGVyIHRoZSB0YWJsZSBudW1iZXJzLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ UGFnZSAxMzogU2VjdGlvbiA4LjIuMS4xIDR0aCBwYXJhIGxhc3QgbGluZSBhZnRlciAmcXVvdDt2 YWx1ZSAyOCD0JnF1b3Q7IGFuZCAmcXVvdDsoYWRkcmVzcyBpbmNvbXBsZXRlKfYmcXVvdDsgPC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj5QYWdlIDEzOiBTZWN0aW9uIDguMi4xLjMgMm5kIHBhcmE6 IGRlbGV0ZSB0aGUgY29tbWEgaW4gKGUuZy4sIHJpbmctYmFjayB0b25lKSA8L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPlBhZ2UgMzU6IGNhcHRpb24gb2YgdGFibGUgMyBwLiAzNSAmcXVvdDtmb3Ig 5mF1ZGlvxiB0cmFuc2ZlciZxdW90OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlBhZ2UgMzU6 IGluIHRhYmxlIDQgcmVwbGFjZSAuLWxhdyBieSBtdS1sYXc8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la RT0yPlBhZ2UgMzk6IFRoZSByZWZlcmVuY2VzIGluIHNlY3Rpb24gMTMgc2hvdyBub24tQVNDSUkg aW4gaXRlbXMgMSwxMywxNCAoMngpLCAxNywgMTk8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlBh Z2UgNDA6ICZxdW90O0FubmV4IEEgKGluZm9ybWF0aXZlKSD7IEV4YW1wbGUgLi4uJnF1b3Q7LCBz ZWUgYWxzbyB0aGUgY29ycmVzcG9uZGluZyBsaW5lIGluIHRoZSBUT0MgKHBhZ2UgNCk8L0ZPTlQ+ DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5GaWd1cmVzIDEsIDMsIDUsIDYgKGNhcHRpb24pLCA4 LCA5LCAxMSwgMTIgYXJlIHN0cmV0Y2hpbmcgYWNyb3NzIGEgcGFnZSBicmVhay4gTWF5IGJlIHlv dSB3YW50IHRvIHN0YXJ0IHRoZW0gb24gdG9wIG9mIHRoZSBuZXh0IHBhZ2UuIDwvRk9OVD48L1A+ DQoNCjxQPjxGT05UIFNJWkU9Mj5GaWd1cmUgOSBzaG93cyB1bm5lY2Vzc2FyeSBsaW5lIGJyZWFr cyBiZXR3ZWVuICZxdW90O0lQJnF1b3Q7IGFuZCAmcXVvdDtORVRXT1JLJnF1b3Q7IGFuZCBiZWZv cmUgJnF1b3Q7Jmd0O3w0JnF1b3Q7IGFuZCAmcXVvdDt8NSZxdW90OyA8L0ZPTlQ+DQo8L1A+DQoN CjxQPjxGT05UIFNJWkU9Mj5SRkMgMzI2MSBpcyByZWZlcmVuY2VzIGJ5IGl0cyBpdGVtIG51bWJl ciBmcm9tIHRoZSBSZWZlcmVuY2UgbGlzdCBpLmUuIFsxMF0gYXMgd2VsbCBhcyBieSAmcXVvdDtS RkMtMzI2MSZxdW90OyAoNHgpLiBNYXkgYmUgeW91IHdhbnQgdG8gY2hhbmdlIHRoZSBsYXR0ZXIg YWxzbyB0byBbMTBdLjwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5UaGVyZSBhcmUgc2V2 ZXJhbCBvcnBoYW4gaGVhZGluZ3Mvd2lkb3cgbGluZXMgb24gdGhlIGJvdHRvbS90b3Agb2YgYSBw YWdlLiBNYXkgYmUgeW91IHdhbnQgdG8gcHV0IHRoZW0gb24gdG9wL2JvdHRvbSBvZiB0aGUgbmV4 dC9wcmV2aW91cyBwYWdlLjwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5FLmcuIDguMi4x LjEsIDguMi4yLjEsIDguMi4yLjIuMi4sIDguMi4yLjIuNiwgOS4xLjMuMSwgMTEsIDEzIChlLW1h aWwgYWRkcmVzcyk8L0ZPTlQ+DQo8L1A+DQo8QlI+DQoNCjxQPjxGT05UIFNJWkU9Mj5SZWdhcmRz PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5UaG9tYXMgPC9GT05UPg0KPC9QPg0KDQo8L0JPRFk+ DQo8L0hUTUw+ ------_=_NextPart_001_01C35067.F8EDBF50-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 28 15:46: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 PAA18460 for ; Mon, 28 Jul 2003 15:46: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 19hDwH-0004xD-QJ for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 15:45:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SJjjwi019036 for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 15:45:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDwH-0004wx-M9 for sipping-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 15: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 PAA18291 for ; Mon, 28 Jul 2003 15:45:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hDwF-00076h-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 15:45:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hDvs-00075K-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 15:45:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDvl-0004iU-0E; Mon, 28 Jul 2003 15:45:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h8WK-0006c8-Vr for sipping@optimus.ietf.org; Mon, 28 Jul 2003 09:58: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 JAA01411 for ; Mon, 28 Jul 2003 09:58:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19h8WI-0002cA-00 for sipping@ietf.org; Mon, 28 Jul 2003 09:58:35 -0400 Received: from ns.ivd.nl ([193.67.37.226]) by ietf-mx with esmtp (Exim 4.12) id 19h8WH-0002c6-00 for sipping@ietf.org; Mon, 28 Jul 2003 09:58:34 -0400 Received: (from root@localhost) by ns.ivd.nl (8.9.3c/8.6.12) id PAA18906 for ; Mon, 28 Jul 2003 15:59:50 +0200 (CEST) Received: by ns.ivd.nl (TUNIX txp2/smap) for id sma018681; Mon, 28 Jul 03 15:58:43 +0200 Received: from IVD-Message_Server by mailserver.viataal.nl with Novell_GroupWise; Mon, 28 Jul 2003 15:59:54 +0200 Message-Id: X-Mailer: Novell GroupWise 5.5.5 Date: Mon, 28 Jul 2003 15:59:35 +0200 From: "A vWijk" To: , , Cc: , , , , , , , , , , , , , , , , Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: [Sipping] 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: quoted-printable Content-Transfer-Encoding: quoted-printable 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?=20 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 implementati= on 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). >=20 > greetz >=20 > 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. =20 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 Mon Jul 28 15:46: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 PAA18503 for ; Mon, 28 Jul 2003 15:46: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 19hDwJ-0004xx-EL for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 15:45:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SJjlPQ019083 for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 15:45:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDwJ-0004xE-8n for sipping-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 15:45: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 PAA18287 for ; Mon, 28 Jul 2003 15:45:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hDwE-00076d-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 15:45:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hDvx-00074v-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 15:45:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDvf-0004g2-KO; Mon, 28 Jul 2003 15:45:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eK3L-0000EX-9X for sipping@optimus.ietf.org; Sun, 20 Jul 2003 15: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 PAA26490 for ; Sun, 20 Jul 2003 15:40:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eK3J-0004hV-00 for sipping@ietf.org; Sun, 20 Jul 2003 15:41:02 -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 19eK39-0004h9-00 for sipping@ietf.org; Sun, 20 Jul 2003 15:40:51 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 20 Jul 2003 12:40:38 -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 h6KJeBuJ029650; Sun, 20 Jul 2003 12:40:11 -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 AJJ76263; Sun, 20 Jul 2003 12:36:33 -0700 (PDT) Date: Sun, 20 Jul 2003 21:42:14 +0200 Subject: Re: [Sipping] Re: items for vor voting in the BOF Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: , , =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= , "Paul E. Jones" , , , , , , , "James Hamlin" , , , "'Rajesh Kumar'" , , , "Mike Spanner" , "Henry Sinnreich" , "Andrea Saks" To: rohan@cisco.com From: Rohan Mahy In-Reply-To: <004f01c34dbf$56bfab80$6501a8c0@hitachi> Message-Id: <43485833-BAEA-11D7-B1E0-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 I have created a new mailing list to discuss the sipdev document, and I have subscribed everyone on this thread. The mailing list should be active within 72 hours. I will post an announcement to sipping@ietf.org informing folks of the existence of this new list. To subscribe from another address, send email to mailer@cisco.com with no subject. the body of your email should be: subscribe sipdev To unsubscribe send to the same address: unsubscribe sipdev To send mail to the list send to sipdev@external.cisco.com many 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 Mon Jul 28 15:46: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 PAA18540 for ; Mon, 28 Jul 2003 15:46: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 19hDwO-0004yQ-N6 for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 15:46:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SJjqCa019112 for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 15:45:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDwO-0004yB-G0 for sipping-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 15:45: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 PAA18256 for ; Mon, 28 Jul 2003 15:45:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hDw4-000764-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 15:45:32 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hDvr-000755-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 15:45:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDvh-0004gq-FQ; Mon, 28 Jul 2003 15:45:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efhx-0000r6-H4 for sipping@optimus.ietf.org; Mon, 21 Jul 2003 14:48: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 OAA06736 for ; Mon, 21 Jul 2003 14:48:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19efhu-0005OG-00 for sipping@ietf.org; Mon, 21 Jul 2003 14:48:22 -0400 Received: from mta08.mx.cix.co.uk ([212.241.168.138] helo=mua01.mx.cix.co.uk) by ietf-mx with esmtp (Exim 4.12) id 19efhi-0005O4-00 for sipping@ietf.org; Mon, 21 Jul 2003 14:48:10 -0400 Received: from hitachi (adsl-216-100-136-229.dsl.snfc21.pacbell.net [216.100.136.229]) by mua01.mx.cix.co.uk (8.11.3/CIX/8.11.3) with SMTP id h6LIlAK28698; Mon, 21 Jul 2003 19:47:10 +0100 X-Envelope-From: asaks@waitrose.com Message-ID: <004c01c34fb7$eb5a9ee0$6501a8c0@hitachi> Reply-To: "Andrea Saks" From: "Andrea Saks" To: "Rohan Mahy" Cc: , , =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= , "Paul E. Jones" , , , , , , , "James Hamlin" , , , "'Rajesh Kumar'" , , , "Mike Spanner" , "Henry Sinnreich" , "Amanda Grace" , "Andrew J Lange" , , "John Combs" , "Don Pitchford" , "Nancy J Bloch" , "Jim House" , "Claude Stout" , "Bill Pechey" , "Simao Campos-Neto" , "George Skorkowski" , "Colwell Kevin" , "Robert Engelke" , "Karen Peltz Straus" , "Keith Chu" , "'Judy Harkins'" , "Dick Brandt" , "Fred Lucas" , "Tracy Annear" , "Thomas McLaughlin" , "Michael J Ellis" References: <1473ACF5-BAEA-11D7-B1E0-0003938AF740@cisco.com> Subject: Re: [Sipping] Re: items for vor voting in the BOF Date: Mon, 21 Jul 2003 19:42:24 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0049_01C34FC0.35AF4560" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0049_01C34FC0.35AF4560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Rohan, I have answered you in your text with different font for clarity and = have added those people I gave you earlier. I realise that you are = trying to do the right thing have no fear. See below. The main point is that you just can't predict what people will do, buy = or make and use and under what circumstances. In the case of = accessibility,it is best to have all bases covered. Andrea ----- Original Message ----- From: Rohan Mahy To: Andrea Saks Cc: ; ; Gunnar Hellstr=F6m ; Paul E. Jones ; ; ; ; ; ; ; James Hamlin ; ; ; 'Rajesh Kumar' ; ; ; Mike Spanner ; Henry Sinnreich Sent: Sunday, July 20, 2003 8:40 PM Subject: Re: [Sipping] Re: items for vor voting in the BOF Hi Andrea, Nothing about the sipdev recommendations directs anyone to build a device which violates local laws where the product is sold. I believe that the recommendations proposed at the adhoc address additional functionality which would apply to most IP telephony devices, and in many cases are consistent with the spirit and the letter of various local regulations. Andrea responds I am sure that your intentions are not to discriminate. There are no = laws pertaining to the building of devices as standards are voluntary. = There in lies the rub. If you leave an out or make one product exempt = you create a loophole for others to make a cheap phones that do not = support TTY. It makes more sense to me to include all the IP phones. I = have been told ( In fact we all have)by Guido in his correspondence it = that he is determined to not allow TTY to use IP phones which I find = personally unacceptable. His reasoning I think is that if he restricts = TTY access TTY will die. I doubt that will be the outcome and history = has supported my view. The RNID did try this very same tactic before. = Now this was before Guido's time. You all have seen my email regarding = that and caused many technical problems with the relay system which only = now have been mostly sorted. As we all know Baudot was not stamped out = in Great Britain. It is still is the way the UK Deaf people = communicate with USA deaf people for live real time conversation even = though the RNID was still saying the offical code for Great Britain was = V21 up until a couple of years ago. People did and bought what they = wanted to use. I didn't hold a gun to their heads.=20 There is no need to exclude anything or anyone and you are correct I = want to see something added. I am consulting with others as I always do = as what the wording will be. Rohan continues: As I have said before, based on anecdotal evidence, I believe that most SIP telephony devices have either a display or an RJ-11 interface, and that phones with displays will continue to be the norm. For example, Cisco has sold nearly 2 million IP phones, an overwhelming percentage of which (more than 99.999%) have displays or an RJ-11 port. Rounding out the top 4 in market share (in no particular order) are Pingtel, Mitel, and 3COM, who I believe only have IP phones with displays or telephony adapters with an RJ-11 interface. To convince me that we are abandoning a relevant market, you would need to provide some feasible market data which contradicts this anecdotal evidence. Andrea responds Civil rights has nothng to do with a market but with accessiblity. As = for statistics, accessiblity is not about numbers it is about rights. I = could manipulate statisics but I think here you have to use common = sense.=20 But lets look at numbers for second. Most people use and accept a = rough guide of 1% of an given population has a hearing loss which = interferes in using the telephone conventionally. TTY use is greater in = the USA, Canada and Australia by virtue of the size of the countries' = population..So the percentage will have more people within it right? Now = lets go to China and the EAST. Now we are getting really big. Big = populations also but it is where a lot of IP phones are made and will be = made. What is the market motivation? Make the cheapest and make a lot = of them. Isn't it where most IP phones are made? Where does Cisco = contract it manufacturing?? Lets go back to the West and with Baby boomers. Huge population but = they are retiring. Noise pollution was the norm when they were growing = up and working. Let me paint some scenarios. The sixties and huge = speaker stacks that people used to stand right next to and it continues = today with House music. ( I did that and I have lost the top range of = my hearing because if it) Walkmans in the ears! Lovely! Protective head = gear in the he workplace has only been in place for the last 20 years or = so. Old age and deterioration here we come! Baby boomers big nmbers = coming up and I was born in 47 and it is happening to me!. So deafness = is on the rise. Now some of these people will be from hearing culture = not be in deaf culture and will not know much about any of these issues. = The average Joe will buy the cheapest thing. Maybe these people will = not buy a TTY who knows. But the rub is you just do not know. Also = for every deaf person you have a lot people who support and know a deaf = person. Some will have their own TTY because they do not what to go = through the relay. Families grow up move away and there are load of = mixed families. deaf children are mostly born to hearing parents and not = the other way arround. Everyone pre Internet has TTY or some sort if = they have anything at all. That is a lot of people world wide. But do = they register?? Nope but TDI had a phone book of TTY users including the = FEDS which might be useful for you to look at. Paul Jones has a = copy..Or better yet ask Claude Stout Executive Director of TDI for a = copy. execdir@tdi-online.org I am also teacher of computer applications in the UK to older people age = range 40 to 60 years on average at a technical college. I teach people = how to use Word,Access, Excel, Desktop publishing, PowerPoint etc. and = to how use Windows explorer to file and access data. I also teachpeople = how to use email programs,browsers and search engines. A lot of these = people are not computer literate at all when they first come in . It = was not subject offered at school when they were there. There is great = interest to learn but the mainstream of that age group are not already = literate by their past education.=20 Then we have the elderly who are already on TTY and Deaf. They will not = change easily to new technology.That will be the largest part of the TTY = population as the young will be naturally migrating and have already = migrated to IP solutions. My 83 year Mother went on email but decided = she preferred TTY and fax. TTY is simple to use. . She liked real = time conversation . Boot up time is a problem especially with = emergencies in this case. Little kids can use TTY. It is just "phone" = for many of us. An Elderly person like my Mom might buy a new phone and = at 83 Is she going to know what phone to buy and why? =20 The Deaf also have portable TTY devices that are acoustically coupled = and they are still the cheapest device to buy for means of = communication for deaf people if they want real time detailed = conversation character by character if they can't for whatever reason = have a computer or an IP phone with all the "gubbins". Hotels are all = over the world are going to buy the cheapest phones too. These phones = can be and for the most part acoustically coupled. It is not perfect = but it works especially when in Europe where there are not many relay = services for the deaf. Only the UK uses a V.18 platform in its relay = service with TextDirect. Is the deaf person going to know why his = portable TTY doesn't work with the telephone handset without a screen?? = Doubt it. I think it is possible you have with the omission of including all IP = phones actually is giving license for industry to ignore making the IP = phone you want. TTY's have been arround a long time. They are reliable = and people are not inclined to give them up. This tactic is not going = to stop there use as we will have the gateways and ToIP is continuing is = TR301. None of you are giving up the voice telephone if you are hearing. = The TTY is our telephone. Why do we have to give it up because a = misguided view that it is old. Even the old carbon phones with pulse = still work. Used one yesterday at an 88 year old's house in San = Francisco. I know we have the will go through gateways. But there will = be no uniform predictability of which ones will be in place or where = they will be in the globe and for that matter where the controller will = be located either. This also affects in what devices will work through = what if you catch my drift.There is no need to exclude TTY. Let it live. = It will die out in its own good time with migration. =20 Rohan If you still feel strongly that there are requirements which are missing, please propose some text to that end. I do but I do not work alone. I do not have the right to decide. I = would like to make sure that what ever is proposed will have not have = technical problems associated with it. I am consulting several = colleagues before I give you anything. Thanks for the space. thanks, -rohan On Saturday, July 19, 2003, at 08:30 AM, Andrea Saks wrote: > Paul is absolutely right. Just to let all of you know I think this > little > outcome in my opinion is in direct violation of some ADA legislation > in the > USA that includes both IP and telecomm in its mandate. I have just > been > brought up to speed in the USA during my participation at the ITU > workshop > at the TDI convention this past week. Australian participation was > present > as well. I will be informing all my contacts including those at the > Justice > department, FCC and State department and ITU of the results of this > meeting. > > Contray to Guido wanting to restrict I want it all out in the = open!!So > Guido's glee may be in vain. It certainly is premature . I do not > think this > outcome will stand. > > And as I have said before it seems unlikely ETSI will take a strong > view > either. I think any attempt to try and separate Europe from the USA = is > futile both in spirit and in practical terms and defeats the whole > exercise > of compatibility and communication for the deaf on a world wide basis. > . > The USA Canada and Australia comprise the largest body of Textphone > users in > the world. The RNID does not speak for the world nor should it and > nor > will it. Paul is also right that work on reflectors is as valid as > physical > presence and those experienced in standards work know that to be true. > > Hearing people do not have to give up their devices why should the > deaf. We > all use different devices and systems at different times as > appropriate. > Why should we have to give up anything because a few want to change > the > world with a "perfect device" that unfortunately very few people will > buy. > People with marketing experience will also know that people will buy > the > cheaper ones without support .. And since standards are voluntary it > might ignored all together. All you are creating in theory is the = next > legacy device if it even gets made. The systems and all devices > that are > created like IP phone must support all legacy devices and only > then can > true migration happen. People who fail to understand history are > doomed to > repeat its mistakes. In this case I suspect a lot of people do not > even know > that this tactic has been attempted before and failed and not just in > the > deaf world. > > This messenger will be back to you all after I have illuminated > consulted) with) the bodies above to the "wisdom"of this adhoc group. > > Andrea J Saks > Telecommunications Specialist for the Deaf > Rockville, The Quarry > Brockhampton > Gloucestershire GL 54 5XL > United Kingdom > > Tel +44 1242 820800 > Minicom +44 1242 820623 ( V21 and Baudot only) > Fax +44 1242 821171 > Mobile +44 7956 222916 > > asaks @ waitrose.com > > ----- Original Message ----- > From: Paul E. Jones > To: Gunnar Hellstr=F6m ; > ; > Cc: Henry Sinnreich ; Guido Gybels > ; Mike Spanner ; > ; ; > ; 'Rajesh Kumar' ; > ; ; James Hamlin > ; ; > ; ; > ; > ; ; ; Andrea Saks > > Sent: Saturday, July 19, 2003 1:38 AM > Subject: Re: [Sipping] Re: items for vor voting in the BOF > > > Gunnar, > > I made a couple of typos that, perhaps, might make a difference to = you. > > The results stated that an RJ-11 interface was a "may". *If* it > supports an > RJ-11, then it *may* support RFC 2793 and *must* support pass-through. > > I typed a bit too fast below. What I intended to say what that we > should > have made support for pass-through a *must* in all cases where RFC > 2793 is > not supported. However, we should separate that requirement from > whether > there is an RJ-11, 2.5mm audio jack, or acoustic coupling. > > Below, you wrote: "most textphone users are nowadays used to let the > textphone do the dialing and answering..." I would tend to think that > will > continue to be true in the following two cases: > 1) The new textphone is an IP textphone (this includes > any standard IP phone with native RFC 2793 support) > 2) The textphone is plugged into a residential gateway > (in this case, the textphone is the same technology as used > today.) > > What is excluded from support is the class of phones that you find on > the > shelf at Wal-Mart that will not have a suitable display nor an > interface for > a display and keyboard. I've said before that I think there will be > such a > class of devices and I think we'd be foolish not give that > consideration. > As it is now, there is the potential for millions of IP phones to be > produced that have absolutely no support for text, nor an interface = for > connecting with legacy TTY devices. > > Are you willing to allow the production of 100,000,000 IP phones that > have > no means of doing text telephony? According to the ad-hoc group, this > is > acceptable. > > Paul > > ----- Original Message ----- > From: "Gunnar Hellstr=F6m" > To: "Paul E. Jones" ; > ; > > Cc: "Henry Sinnreich" ; "Guido Gybels" > ; "Mike Spanner" ; > ; ; > ; "'Rajesh Kumar'" ; > ; ; "James Hamlin" > ; ; > ; ; > ; > ; ; ; "Andrea Saks" > > Sent: Friday, July 18, 2003 6:00 PM > Subject: SV: [Sipping] Re: items for vor voting in the BOF > > >> If the outcome of the text discussion in sipdev is what is reported = by > Paul, >> I think it is a reasonable result, and I hope it will have the = desired >> effect on products and implementations. >> >> It is true that displays can be arranged in other ways than having it >> on > the >> telephone itself, so the hook to the presence of a display seems in >> fact >> superfluous. >> >> I am prepared to accept this for now. But I hope that other >> accessibility >> requirements emerge and make the standardised interface to user >> interface >> devices a reality. That would include the audio channels, that, if > provided >> without sidetone, can be used either for hearing aid connection or = for > audio >> based textphone connection if there would be any wish to use that >> mode. >> >> By the way, most textphone users are nowadays used to let the >> textphone do >> the dialling and answering, so the use of an audio based textphone on >> a > pure >> audio connection will not be understood and appreciated by many = users. > They >> maintain a phonebook in the textphone and let the textphone also act >> as an >> answering machine. All these functions are lost if you connect it to >> the >> audio channels directly. >> >> When will there be test partners in SIPPIT for the agreed >> functionality? >> >> Regards >> >> Gunnar >> >> ------------------------------------------- >> Gunnar Hellstr=F6m, Omnitor, Renathv=E4gen 2 >> SE 121 37 Johanneshov, SWEDEN >> Tel: +46 8 556 002 03 Mob: +46 708204288 >> e-mail: gunnar.hellstrom@omnitor.se >> web: www.omnitor.se >> >> >>> -----Ursprungligt meddelande----- >>> Fr=E5n: Paul E. Jones [mailto:paulej@packetizer.com] >>> Skickat: den 18 juli 2003 17:05 >>> Till: guido.gybels@rnid.org.uk; gv@trace.wisc.edu >>> Kopia: Henry Sinnreich; Gunnar Hellstrom; Guido Gybels; Mike = Spanner; >>> andreas.piirimets@omnitor.se; gv@trace.wisc.edu; >>> 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; >>> rohan@cisco.com; sipping@ietf.org; Andrea Saks >>> =C4mne: Re: [Sipping] Re: items for vor voting in the BOF >>> >>> >>> 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 >>> >>>> _______________________________________________ >>>> Sipping mailing list = https://www1.ietf.org/mailman/listinfo/sipping >>>> This list is for NEW development of the 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_000_0049_01C34FC0.35AF4560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Rohan,

I have answered you in = your text=20 with different font for clarity and have added those people I gave you=20 earlier.  I realise that you are trying to do the right thing have = no fear.=20 See below.
The main point is that you just can't = predict what=20 people will do, buy or make and  use and under what = circumstances. =20 In the case of accessibility,it is best to have all bases = covered.
 
Andrea
 


----- Original Message = -----
From: Rohan=20 Mahy <rohan@cisco.com>
To: Andrea=20 Saks <asaks@waitrose.com>
Cc:=20 <gv@trace.wisc.edu>; = <guido.gybels@rnid.org.uk>= ; Gunnar=20 Hellstr=F6m
<gunnar.hellstrom@omnitor.se>;=20 Paul E. Jones <paulej@packetizer.com>;
&= lt;sipping@ietf.org>; <oran@cisco.com>; <mgarakan@cisco.com>;
<barry.dingle@bigfoot.com.au>;=20 <hwildfeu@cisco.com>;
<Erik.Zetterstrom@omnitor.se>;=20 James Hamlin <James.Hamlin@rnid.org.uk>= ;
<jorgen.bjorkner@hotsip.com= >;=20 <marcelo@envilogg.se>; = 'Rajesh=20 Kumar'
<rkumar@cisco.com>; <trefor@trefor.plus.com>;<andreas.piirimets@omnitor.se= >;=20 Mike Spanner <mike.spanner@rnid.org.uk>= ;
Henry=20 Sinnreich <Henry.Sinnreich@mci.com>Sent:=20 Sunday, July 20, 2003 8:40 PM
Subject: Re: [Sipping] Re: items for = vor voting=20 in the BOF


Hi Andrea,

Nothing about the sipdev = recommendations=20 directs anyone to build a
device which violates local laws where the = product=20 is sold. I believe
that the recommendations proposed at the adhoc = address=20 additional
functionality which would apply to most IP telephony = devices, and=20 in
many cases are consistent with the spirit and the letter of=20 various
local regulations.
 
Andrea responds
 
I am sure that your intentions = are not to=20 discriminate. There are no laws pertaining to the building of devices as = standards are voluntary. There in lies the rub.  If you leave an=20 out or make one product exempt you create a loophole for others to = make a=20 cheap phones that do not support TTY.  It makes more sense to me to = include=20 all the IP phones.  I have been told  ( In fact we all have)by = Guido in his correspondence  it that he is determined to not = allow TTY=20 to use IP phones which I find personally unacceptable.  His = reasoning I=20 think is that if he restricts  TTY access TTY will die.  = I=20 doubt  that will be the outcome and history has supported my view. = The RNID=20 did try this very same tactic before.  Now this was before = Guido's=20 time. You all have seen my email regarding that and caused many = technical=20 problems with the relay system which only now have been mostly = sorted. As=20 we all know Baudot was not stamped out in Great Britain.   It = is still=20 is the way the UK Deaf people communicate with USA deaf people for live = real=20 time conversation even though the RNID was still saying the offical code = for=20 Great Britain was V21 up until a couple of years ago. People did = and bought=20 what they wanted to use. I didn't hold a gun to their heads. =
 
There is no need to exclude = anything or=20 anyone and you are correct I want to see something added.  I am = consulting=20 with others as I always do as what the wording will be.
 
 Rohan continues:
 
As I have said before, based on = anecdotal evidence,=20 I believe that most
SIP telephony devices have either a display or an = RJ-11=20 interface, and
that phones with displays will continue to be the = norm. For=20 example,
Cisco has sold nearly 2 million IP phones, an overwhelming=20 percentage
of which (more than 99.999%) have displays or an RJ-11 = port.=20 Rounding
out the top 4 in market share (in no particular order) are=20 Pingtel,
Mitel, and 3COM, who I believe only have IP phones with = displays=20 or
telephony adapters with an RJ-11 interface.  To convince me = that we=20 are
abandoning a relevant market, you would need to provide some=20 feasible
market data which contradicts this anecdotal = evidence.
 
 
Andrea responds
 
Civil rights has nothng to do = with a market=20 but  with accessiblity. As for statistics, accessiblity is not = about=20 numbers it is about  rights. I could manipulate statisics but I = think here=20 you have to use common sense.
 
But lets look at = numbers for=20 second. Most  = people use and=20 accept  a rough guide of 1% of an given population has a hearing = loss which=20 interferes in using the telephone conventionally.  TTY use is = greater in=20 the USA, Canada and  Australia by virtue of  the size of the=20 countries' population..So the percentage will have more people within it = right? Now lets go to China and the EAST.  Now we are=20 getting  really big. Big populations also but it is where a lot of = IP=20 phones are made and will be made. What  is = the =20 market motivation? Make the cheapest and make  a lot of them. = Isn't it=20 where most IP phones are made?  Where does Cisco contract it=20 manufacturing??
 
Lets go back to the West  = and=20 with  Baby boomers.  Huge population but they are = retiring. =20 Noise pollution was the norm when they were growing up and = working. =20 Let me paint some scenarios. The sixties and huge speaker stacks = that=20 people used to stand right next to and it continues today with House=20 music.   ( I did that and I have lost the top range of my = hearing=20 because if it) Walkmans in the ears! Lovely!  Protective head gear = in the=20 he workplace has only been in place for the last 20 years or = so.  Old=20 age and deterioration here we come! Baby boomers big nmbers coming = up and=20 I was born in 47 and it is happening to me!. So deafness is on the rise. = Now=20 some of  these people will be from hearing culture not be in deaf = culture=20 and will not know much about any of these issues.  The average = Joe=20 will buy the cheapest thing.  Maybe these people will not buy = a TTY=20 who knows.    But  the rub is you just do not know. = Also for=20 every deaf person you have a lot people who support and know a deaf=20 person.  Some will have their own TTY because they do not what to = go=20 through the relay. Families grow up move away and there are load of = mixed=20 families. deaf children are mostly born to hearing parents and not the = other way=20 arround.  Everyone pre Internet has TTY or some sort if they have = anything=20 at all.  That is a lot of people world wide.  But do they = register??=20 Nope but TDI had a phone book of TTY users including the FEDS which = might=20 be useful for you to look at. Paul  Jones has a copy..Or better yet = ask=20 Claude Stout Executive Director of TDI for a copy. execdir@tdi-online.org<= /DIV>
 
I am also teacher of computer = applications=20 in the UK to older people age range 40 to 60 years on average at a = technical=20 college. I teach people how to use Word,Access, Excel, Desktop = publishing,=20 PowerPoint etc. and to how use  Windows explorer to file and access = data. I also teachpeople how to use email programs,browsers and = search=20 engines. A lot of these people are not computer literate at all when = they =20 first come in . It was not  subject offered at school when they = were=20 there.  There is great interest to learn but the mainstream of that = age=20 group are not already literate by their past education.
 
Then we have the elderly who = are already on=20 TTY and Deaf. They will not change easily to new technology.That will be = the=20 largest part of the TTY population as the young will be naturally = migrating=20 and have already migrated to IP solutions.  My 83 year Mother went = on=20 email but decided she preferred TTY and fax.  TTY is simple to = use.  . She liked real time conversation .  Boot up time is a = problem=20 especially with emergencies in this case. Little kids can use = TTY.  It=20 is just "phone" for many of us. An Elderly person like my Mom might = buy a=20 new phone and at 83  Is she going to know what phone to buy = and=20 why? 
 
The  Deaf also have = portable =20 TTY devices that are acoustically coupled and they are still the = cheapest =20 device to buy for means of communication for deaf people if they want = real time=20 detailed conversation character by character if they can't for whatever = reason=20 have a computer or an IP phone with all the "gubbins". Hotels are all = over the=20 world are going to buy the cheapest phones too.  These phones can = be and=20 for the most part acoustically coupled.  It is not perfect but it = works=20 especially when in Europe where there are not many relay services for = the=20 deaf.  Only the UK uses a V.18 platform in its relay service with=20 TextDirect. Is the deaf person going to know why his  portable TTY = doesn't=20 work with the telephone handset without a screen?? Doubt = it.
 
 I think it is = possible you have=20 with the omission of including all IP phones actually is = giving=20 license for industry to ignore making the IP phone you want. = TTY's have been arround a long time.  They are reliable = and people=20 are not inclined to give them up.  This tactic is not going to stop = there=20 use as we will have the gateways and ToIP is continuing is = TR301. None=20 of you are giving up the voice telephone if you are hearing.  The = TTY is=20 our telephone. Why do we have to give it up because a misguided view = that it is=20 old.  Even the old carbon phones with pulse still work.  Used = one=20 yesterday at an 88 year old's house in San Francisco. I know we  = have the=20 will go through gateways.  But there will be no uniform = predictability of=20 which ones will be in place or where they will be in the globe and for = that=20 matter where the controller will be located either.  This = also=20 affects  in what devices will work through what if you catch my = drift.There=20 is no need to exclude TTY. Let it live.  It will die out in its own = good=20 time with migration. 
 
Rohan

If you still feel strongly = that there=20 are requirements which are
missing, please propose some text to that=20 end.
 
I = do but I do not=20 work alone.  I do not have the right to decide.  I would like = to make=20 sure that what ever is proposed will have not have technical problems=20 associated with it. I am consulting several colleagues before I = give you=20 anything.  Thanks for the=20 space.

thanks,
-rohan


On Saturday, July 19, = 2003, at=20 08:30 AM, Andrea Saks wrote:

> Paul is absolutely right.  = Just to=20 let all of you know I think this
> little
> outcome in my = opinion is=20 in direct violation of some ADA legislation
> in the
> = USA =20 that includes both IP and telecomm in its mandate. I have just
>=20 been
> brought up to speed in the USA during my participation at = the=20 ITU
> workshop
> at the TDI convention this past week. = Australian=20 participation was
> present
> as well. I will be informing = all my=20 contacts including those at the
> Justice
> department, FCC=20 and  State department and ITU of the results of this
>=20 meeting.
>
>  Contray to Guido wanting to restrict I = want it=20 all out in the open!!So
> Guido's glee may be in vain. It = certainly is=20 premature . I do not
> think this
> outcome will=20 stand.
>
> And as I have said before it seems unlikely ETSI = will=20 take a strong
> view
> either.  I think any attempt to = try and=20 separate Europe from the USA is
> futile both in spirit and in = practical=20 terms and defeats the whole
> exercise
> of compatibility = and=20 communication for the deaf on a world wide basis.
> .
> The = USA=20 Canada and Australia comprise the largest body of Textphone
> = users=20 in
> the world.  The RNID does not speak for the world = nor =20 should it and
> nor
> will it.  Paul is also right that = work on=20 reflectors is as valid as
> physical
> presence and those=20 experienced in standards work know that to be true.
>
> = Hearing=20 people do not have to give up their  devices why should the
> = deaf.=20 We
> all use different devices and systems at different times = as
>=20 appropriate.
> Why should we have to give up anything because a = few =20 want to change
> the
> world with a "perfect device" that=20 unfortunately very few people will
> buy.
> People with = marketing=20 experience will also know that people  will buy
> the
> = cheaper=20 ones without support ..  And since standards are voluntary = it
> might=20 ignored all together.  All you are creating in theory is the = next
>=20 legacy device if it even gets made.  The systems and   = all=20 devices
> that are
> created  like IP phone  must = support=20 all  legacy devices  and only
> then can
> true = migration=20 happen. People who fail to understand history are
> doomed = to
>=20 repeat its mistakes. In this case I suspect a lot of people do = not
> even=20 know
> that this tactic has been attempted before and failed  = and not=20 just in
> the
> deaf world.
>
> This messenger = will=20 be  back to you all after I have illuminated
>  = consulted) with)=20 the bodies above to the "wisdom"of this adhoc group.
>
> = Andrea J=20 Saks
> Telecommunications Specialist for the Deaf
> = Rockville, The=20 Quarry
> Brockhampton
> Gloucestershire GL 54 5XL
> = United=20 Kingdom
>
> Tel  +44 1242 820800
> Minicom +44 = 1242=20 820623  ( V21 and Baudot only)
> Fax +44 1242 821171
> = Mobile=20 +44 7956 222916
>
> asaks @ waitrose.com
>
> = -----=20 Original Message -----
> From: Paul E. Jones <paulej@packetizer.com>
&g= t; To:=20 Gunnar Hellstr=F6m <gunnar.hellstrom@omnitor.se>;
>=20 <guido.gybels@rnid.org.uk>= ;=20 <gv@trace.wisc.edu>
> Cc:=20 Henry Sinnreich <Henry.Sinnreich@mci.com>; = Guido=20 Gybels
> <Guido.Gybels@rnid.org.uk>= ; Mike=20 Spanner <mike.spanner@rnid.org.uk>= ;
>=20 <andreas.piirimets@omnitor.se= >;=20 <gv@trace.wisc.edu>;
> = <trefor@trefor.plus.com>; = 'Rajesh=20 Kumar' <rkumar@cisco.com>;
>=20 <marcelo@envilogg.se>; = <jorgen.bjorkner@hotsip.com= >;=20 James Hamlin
> <James.Hamlin@rnid.org.uk>= ; <Erik.Zetterstrom@omnitor.se>;
>=20 <hwildfeu@cisco.com>; = <barry.dingle@bigfoot.com.au>;
>=20 <mgarakan@cisco.com>;
>=20 <oran@cisco.com>; <rohan@cisco.com>; <sipping@ietf.org>; Andrea = Saks
>=20 <asaks@waitrose.com>
> = Sent:=20 Saturday, July 19, 2003 1:38 AM
> Subject: Re: [Sipping] Re: items = for vor=20 voting in the BOF
>
>
> Gunnar,
>
> I made = a=20 couple of typos that, perhaps, might make a difference to = you.
>
>=20 The results stated that an RJ-11 interface was a "may".  *If* = it
>=20 supports an
> RJ-11, then it *may* support RFC 2793 and *must* = support=20 pass-through.
>
> I typed a bit too fast below.  What I = intended to say what that we
> should
> have made support = for=20 pass-through a *must* in all cases where RFC
> 2793 is
> not = supported.  However, we should separate that requirement = from
>=20 whether
> there is an RJ-11, 2.5mm audio jack, or acoustic=20 coupling.
>
> Below, you wrote: "most textphone users are = nowadays=20 used to let the
> textphone do the dialing and answering..."  = I would=20 tend to think that
> will
> continue to be true in the = following two=20 cases:
>   1) The new textphone is an IP textphone (this = includes
>      any standard IP phone = with native=20 RFC 2793 support)
>   2) The textphone is plugged into a = residential gateway
>      (in this case, = the=20 textphone is the same technology as=20 used
>       today.)
>
> = What is=20 excluded from support is the class of phones that you find on
>=20 the
> shelf at Wal-Mart that will not have a suitable display nor=20 an
> interface for
> a display and keyboard.  I've said = before=20 that I think there will be
> such a
> class of devices and I = think=20 we'd be foolish not give that
> consideration.
> As it is = now, there=20 is the potential for millions of IP phones to be
> produced that = have=20 absolutely no support for text, nor an interface for
> connecting = with=20 legacy TTY devices.
>
> Are you willing to allow the = production of=20 100,000,000 IP phones that
> have
> no means of doing text=20 telephony?  According to the ad-hoc group, this
> is
>=20 acceptable.
>
> Paul
>
> ----- Original Message=20 -----
> From: "Gunnar Hellstr=F6m" <gunnar.hellstrom@omnitor.se>
>=20 To: "Paul E. Jones" <paulej@packetizer.com>;
&= gt;=20 <guido.gybels@rnid.org.uk>= ;
>=20 <gv@trace.wisc.edu>
> Cc:=20 "Henry Sinnreich" <Henry.Sinnreich@mci.com>; = "Guido=20 Gybels"
> <Guido.Gybels@rnid.org.uk>= ; "Mike=20 Spanner" <mike.spanner@rnid.org.uk>= ;
>=20 <andreas.piirimets@omnitor.se= >;=20 <gv@trace.wisc.edu>;
> = <trefor@trefor.plus.com>; = "'Rajesh=20 Kumar'" <rkumar@cisco.com>;
>=20 <marcelo@envilogg.se>; = <jorgen.bjorkner@hotsip.com= >;=20 "James Hamlin"
> <James.Hamlin@rnid.org.uk>= ; <Erik.Zetterstrom@omnitor.se>;
>=20 <hwildfeu@cisco.com>; = <barry.dingle@bigfoot.com.au>;
>=20 <mgarakan@cisco.com>;
>=20 <oran@cisco.com>; <rohan@cisco.com>; <sipping@ietf.org>; "Andrea = Saks"
>=20 <asaks@waitrose.com>
> = Sent:=20 Friday, July 18, 2003 6:00 PM
> Subject: SV: [Sipping] Re: items = for vor=20 voting in the BOF
>
>
>> If the outcome of the text = discussion in sipdev is what is reported by
> Paul,
>> I = think it=20 is a reasonable result, and I hope it will have the desired
>> = effect=20 on products and implementations.
>>
>> It is true that = displays can be arranged in other ways than having it
>> = on
>=20 the
>> telephone itself, so the hook to the presence of a = display seems=20 in
>> fact
>> superfluous.
>>
>> I = am=20 prepared to accept this for now. But I hope that other
>>=20 accessibility
>> requirements emerge and make the standardised=20 interface to user
>> interface
>> devices a reality. = That=20 would include the audio channels, that, if
> provided
>> = without=20 sidetone, can be used either for hearing aid connection or for
>=20 audio
>> based  textphone connection if there would be any = wish to=20 use that
>> mode.
>>
>> By the way, most = textphone=20 users are nowadays used to let the
>> textphone do
>> = the=20 dialling and answering, so the use of an audio based textphone = on
>>=20 a
> pure
>> audio connection will not be understood and=20 appreciated by many users.
> They
>> maintain a phonebook = in the=20 textphone and let the textphone also act
>> as an
>> = answering=20 machine. All these functions are lost if you connect it to
>>=20 the
>> audio channels directly.
>>
>> When = will there=20 be test partners in SIPPIT for the agreed
>>=20 functionality?
>>
>> Regards
>>
>>=20 Gunnar
>>
>>=20 -------------------------------------------
>> Gunnar = Hellstr=F6m,=20 Omnitor, Renathv=E4gen 2
>> SE 121 37 Johanneshov, = SWEDEN
>>=20 Tel: +46 8 556 002 03  Mob: +46 708204288
>> e-mail: gunnar.hellstrom@omnitor.se
>>=20 web: www.omnitor.se
>>
>>=
>>>=20 -----Ursprungligt meddelande-----
>>> Fr=E5n: Paul E. Jones = [mailto:paulej@packetizer.com]>>>=20 Skickat: den 18 juli 2003 17:05
>>> Till: guido.gybels@rnid.org.uk; = gv@trace.wisc.edu
>>> = Kopia:=20 Henry Sinnreich; Gunnar Hellstrom; Guido Gybels; Mike = Spanner;
>>>=20 andreas.piirimets@omnitor.se= ;=20 gv@trace.wisc.edu;
>>> = trefor@trefor.plus.com;
>= ;>>=20 'Rajesh Kumar'; marcelo@envilogg.se; jorgen.bjorkner@hotsip.com= ;
>>>=20 James
>>> Hamlin; Erik.Zetterstrom@omnitor.se; hwildfeu@cisco.com;
>>>= ; barry.dingle@bigfoot.com.au; mgarakan@cisco.com; oran@cisco.com;
>>> rohan@cisco.com; sipping@ietf.org; Andrea = Saks
>>>=20 =C4mne: Re: [Sipping] Re: items for vor voting in the=20 BOF
>>>
>>>
>>>=20 Guido,
>>>
>>> I wish I could have attended, but = I was=20 attending a TDI conference
>>> here
> = in
>>> the=20 US.  I couldn't be in both places at the same time, though=20 I
>>> wish I
>>> could.  I was disheartened = that=20 the questions were not presented as I
>>> proposed.  = You should=20 know that, supposedly, work gets done over
>>> the=20 e-mail
>>> reflector, not only in the meeting, so not being = there=20 should not
>>> have
>>> lessened my input on the = matter.
>>>
>>> Looking at the results of the = ad-hoc=20 reported by Rohan, I see:
>>>   1) *If* an IP = phone=20 supports a display (and keyboard??),=20 it
>>>      must support RFC=20 2793
>>>   2) IP phones *should* provide a way to = input=20 text
>>>   3) IP phones *may* provide an RJ-11 = interface=20 and *must*
>>>      support=20 pass-through.
>>>
>>> Now, my concerns are=20 several.  It appears that you have absolutely no
>>>=20 requirement for the mass of products that do not sport a = display
>>>=20 to support
>>> text in either relay or pass-through = mode. =20 Further, there is no
>>> mention of
>>> a 2.5mm = jack=20 being an option.  Question 3, as I mentioned,
>>> = "pressured"=20 folks
>>> more than it should.  There should have been = no=20 reason to require
>>> support of
>>> = pass-through, at=20 the very least.
>>>
>>> I told you that my = questions=20 were to ensure that we at least get
>>> support = for
>>>=20 text on every phone in one way or another.  It looks like=20 you
>>> lost.  Company
>>> X is now free to = build=20 an IP phone without any text support.  I'm
>>> not=20 really
>>> happy about that and I certainly don't see why = you should=20 be.
>>>
>>> = Paul
>>>
>>>>=20 _______________________________________________
>>>> = Sipping=20 mailing list  https://www1.ietf= .org/mailman/listinfo/sipping
>>>>=20 This list is for NEW development of the application of = SIP
>>>>=20 Use sip-implementors@cs.colu= mbia.edu=20 for questions on current sip
>>>> Use sip@ietf.org for new developments of = core=20 SIP
>>>>
>>>
>>>
>>>>>
>>
>>
>
>
>
>
>= ;
>
>




------=_NextPart_000_0049_01C34FC0.35AF4560-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 28 16:03: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 QAA19290 for ; Mon, 28 Jul 2003 16:03: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 19hED3-0008Ix-FY for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 16:03:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SK35aw031917 for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 16:03:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hED3-0008Ii-BX for sipping-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 16:03: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 QAA19244 for ; Mon, 28 Jul 2003 16:03:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hED1-0007Pj-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 16:03:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hED1-0007Pg-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 16:03:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hED0-0008Fa-2p; Mon, 28 Jul 2003 16:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hECV-0008Cs-7f for sipping@optimus.ietf.org; Mon, 28 Jul 2003 16:02: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 QAA19227 for ; Mon, 28 Jul 2003 16:02:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hECT-0007PL-00 for sipping@ietf.org; Mon, 28 Jul 2003 16:02:29 -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 19hECS-0007P7-00 for sipping@ietf.org; Mon, 28 Jul 2003 16:02:28 -0400 Received: from localhost (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6SK1wPm001807 for ; Mon, 28 Jul 2003 15:01:58 -0500 From: Dean Willis To: sipping@ietf.org Content-Type: text/plain Message-Id: <1059422518.1349.17.camel@bdsl.greycouncil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 28 Jul 2003 15:01:58 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Reminder about list policy Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 Since Gonzalo is on vacation, I'm filling in and doing mailman administration for the SIPPING list. Normally, this involves deleting about 50 spam messages aday. However, I just "approved" a bunch of real SIPPING messages that had gotten flagged for moderator approvals. NOTE: If you post a message to the list, and it doesn't seem to "go through", it MAY be becuse something about the message got sent it to the moderator and the moderator hasn't gotten to it yet. It is generally not necessary to resubmit the message, especially a few hundred times . . . If these seems to be happening to you , the following may help. I observed three common causes for these messages to have gone to the moderator. 1) The messages appear to be from people who are working in SIPPING, but were not posted from accounts subscribed to the SIPPING list. If you post from an account thats's not subscribed, your message goes to the moderator for approval. 2) The messages were too long, as in > 40KB. Please, folks, don't just keep hitting "reply" on a monster thread. Excerpt out the part's you're commenting on, and attribute them correctly, as in: -------------- Bozo the Clown said: > Yesterday I was gluing on my nose, and thought this might > qualify me to join the IESG. After all, they all seem to > have their noses glued on pretty well. Thanks, Bozo, and welcome to the IETF! Glad to have you with us. What sort of adhesive do you use, and where can I buy some? --------------- 3) The recipient list was too large. I'm not sure exactly what the threshold is, but again this grows when people do a "reply all" on a hot topic. If you're engaging in a major discourse, try limiting the "To" field to just the mailing list address plus the address of the person you're responding to. Thanks, all! -- 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 Mon Jul 28 16:34: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 PAA18365 for ; Mon, 28 Jul 2003 15:46: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 19hDw5-0004uM-Pp for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 15:45:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SJjXLi018860 for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 15:45:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDw5-0004u7-Ke for sipping-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 15:45: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 PAA18250 for ; Mon, 28 Jul 2003 15:45:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hDw3-00076A-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 15:45:31 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hDvy-00075G-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 15:45:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDvk-0004i5-5G; Mon, 28 Jul 2003 15:45:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g4OF-0000b7-Qe for sipping@optimus.ietf.org; Fri, 25 Jul 2003 11:23: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 LAA08958 for ; Fri, 25 Jul 2003 11:21:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g4OE-00013O-00 for sipping@ietf.org; Fri, 25 Jul 2003 11:21:51 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19g4O4-00012l-00 for sipping@ietf.org; Fri, 25 Jul 2003 11:21:40 -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 h6PFKNpp024433; Fri, 25 Jul 2003 08:20:24 -0700 (PDT) Received: from [10.0.1.6] (sjc-vpn1-716.cisco.com [10.21.98.204]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGK75929; Fri, 25 Jul 2003 08:20:18 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 24 Jul 2003 14:47:43 -0700 From: Cullen Jennings To: A vWijk , , CC: , , , , , , , , , , , , , , , , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] 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 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 Mon Jul 28 16:34: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 PAA18363 for ; Mon, 28 Jul 2003 15:46: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 19hDvy-0004sy-Mm for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 15:45:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SJjQUJ018768 for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 15:45:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDvy-0004sd-IT for sipping-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 15:45: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 PAA18212 for ; Mon, 28 Jul 2003 15:45:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hDvp-000757-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 15:45:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hDvn-00074n-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 15:45:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDvd-0004ep-A0; Mon, 28 Jul 2003 15: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 19ddSR-0007Cz-Iu for sipping@optimus.ietf.org; Fri, 18 Jul 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 SAA15629 for ; Fri, 18 Jul 2003 18:12:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ddSO-0003vy-00 for sipping@ietf.org; Fri, 18 Jul 2003 18:12:04 -0400 Received: from mail3.pi.se ([195.7.64.137]) by ietf-mx with esmtp (Exim 4.12) id 19ddSD-0003vu-00 for sipping@ietf.org; Fri, 18 Jul 2003 18:11:53 -0400 Received: from VAIOMHP (h158n2fls31o265.telia.com [217.208.189.158]) (authenticated) by mail3.pi.se (8.11.2/8.11.2) with ESMTP id h6IM0bU02615; Sat, 19 Jul 2003 00:00:37 +0200 (CEST) From: =?Windows-1252?Q?Gunnar_Hellstr=F6m?= To: "Paul E. Jones" , , Cc: "Henry Sinnreich" , "Guido Gybels" , "Mike Spanner" , , , , "'Rajesh Kumar'" , , , "James Hamlin" , , , , , , , , "Andrea Saks" Subject: SV: [Sipping] Re: items for vor voting in the BOF Date: Sat, 19 Jul 2003 00:00:28 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <007d01c34d3d$f092eb50$0401a8c0@packetizer.org> Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.pi.se id h6IM0bU02615 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 If the outcome of the text discussion in sipdev is what is reported by Pa= ul, I think it is a reasonable result, and I hope it will have the desired effect on products and implementations. It is true that displays can be arranged in other ways than having it on = the telephone itself, so the hook to the presence of a display seems in fact superfluous. I am prepared to accept this for now. But I hope that other accessibility requirements emerge and make the standardised interface to user interface devices a reality. That would include the audio channels, that, if provid= ed without sidetone, can be used either for hearing aid connection or for au= dio based textphone connection if there would be any wish to use that mode. By the way, most textphone users are nowadays used to let the textphone d= o the dialling and answering, so the use of an audio based textphone on a p= ure audio connection will not be understood and appreciated by many users. Th= ey maintain a phonebook in the textphone and let the textphone also act as a= n answering machine. All these functions are lost if you connect it to the audio channels directly. When will there be test partners in SIPPIT for the agreed functionality? Regards Gunnar ------------------------------------------- Gunnar Hellstr=F6m, Omnitor, Renathv=E4gen 2 SE 121 37 Johanneshov, SWEDEN Tel: +46 8 556 002 03 Mob: +46 708204288 e-mail: gunnar.hellstrom@omnitor.se web: www.omnitor.se > -----Ursprungligt meddelande----- > Fr=E5n: Paul E. Jones [mailto:paulej@packetizer.com] > Skickat: den 18 juli 2003 17:05 > Till: guido.gybels@rnid.org.uk; gv@trace.wisc.edu > Kopia: Henry Sinnreich; Gunnar Hellstrom; Guido Gybels; Mike Spanner; > andreas.piirimets@omnitor.se; gv@trace.wisc.edu; 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; > rohan@cisco.com; sipping@ietf.org; Andrea Saks > =C4mne: Re: [Sipping] Re: items for vor voting in the BOF > > > 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 > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the 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 Jul 28 16:34: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 PAA18364 for ; Mon, 28 Jul 2003 15:46: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 19hDw3-0004ti-Mo for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 15:45:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SJjVGl018820 for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 15:45:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDw3-0004tT-Ix for sipping-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 15:45: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 PAA18230 for ; Mon, 28 Jul 2003 15:45:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hDw2-000760-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 15:45:30 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hDvn-00074m-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 15:45:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDvb-0004e1-Li; Mon, 28 Jul 2003 15: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 19dWpL-0001xV-OO for sipping@optimus.ietf.org; Fri, 18 Jul 2003 11:07: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 LAA03442 for ; Fri, 18 Jul 2003 11:07:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dWpJ-0001Y2-00 for sipping@ietf.org; Fri, 18 Jul 2003 11:07:17 -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 19dWp8-0001Xf-00 for sipping@ietf.org; Fri, 18 Jul 2003 11:07:06 -0400 Received: from berlin (berlin.packetizer.org [192.168.1.4]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id h6IF4nMd007173; Fri, 18 Jul 2003 11:04:49 -0400 Message-ID: <007d01c34d3d$f092eb50$0401a8c0@packetizer.org> From: "Paul E. Jones" To: , Cc: "Henry Sinnreich" , "Gunnar Hellstrom" , "Guido Gybels" , "Mike Spanner" , , , , "'Rajesh Kumar'" , , , "James Hamlin" , , , , , , , , "Andrea Saks" References: <1204311701-1058509975-cardhu_blackberry.rim.net-20506-@engine02.bwc.prod.uk.blackberry> Subject: Re: [Sipping] Re: items for vor voting in the BOF Date: Fri, 18 Jul 2003 11:04:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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 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. > > < 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 From exim@www1.ietf.org Mon Jul 28 16:34: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 PAA18381 for ; Mon, 28 Jul 2003 15:46:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDw8-0004vB-2W for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 15:45:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SJjac8018913 for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 15:45:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDw7-0004uy-Vi for sipping-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 15:45: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 PAA18245 for ; Mon, 28 Jul 2003 15:45:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hDw3-000762-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 15:45:31 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hDvp-00075N-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 15:45:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDvj-0004hg-7H; Mon, 28 Jul 2003 15:45:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fDkg-0004Wx-8u for sipping@optimus.ietf.org; Wed, 23 Jul 2003 03:09: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 DAA04097 for ; Wed, 23 Jul 2003 03:09:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fDkc-0002Uy-00 for sipping@ietf.org; Wed, 23 Jul 2003 03:09:26 -0400 Received: from eins.siemens.at ([193.81.246.11]) by ietf-mx with esmtp (Exim 4.12) id 19fDkR-0002Ue-00 for sipping@ietf.org; Wed, 23 Jul 2003 03:09:15 -0400 Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id h6N78DcJ019883; Wed, 23 Jul 2003 09:08:13 +0200 Received: from vies141a.sie.siemens.at (atws15tc.sie.siemens.at [158.226.135.41]) by scesie13.sie.siemens.at (8.12.9/8.12.1) with ESMTP id h6N75Mn1020951; Wed, 23 Jul 2003 09:08:01 +0200 (MET DST) Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jul 2003 09:06:15 +0200 Message-ID: From: Stach Thomas To: ELWELL JOHN , "'sipping@ietf.org'" Cc: "'Rohan Mahy'" , "'Dean Willis'" , "'Gonzalo Camarillo'" Subject: WG: [Sipping] WGLC for Q.SIP-SIP mapping draft Date: Wed, 23 Jul 2003 09:06:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C350E8.E23B7CD0" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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_01C350E8.E23B7CD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, as it seems that my mail from yesterday didn't get forwarded on the = sipping list. I'm just trying once again. Regards=20 Thomas -----Urspr=FCngliche Nachricht----- Von: Stach Thomas=20 Gesendet am: Dienstag, 22. Juli 2003 17:43 An: 'sipping@ietf.org' Betreff: [Sipping] WGLC for Q.SIP-SIP mapping draft Hello John, I had a detailed look into the qsig2sip draft, and found only some = minor issues, which can easily be clarifed. In my opinion the draft is mature = and should take its way onwards. In Section 8.1 4th para is stated: "The processing of any valid QSIG message that does not satisfy any of=20 these conditions is outside the scope of this specification." This seems to be a little bit vague for somebody not familiar with = QSIG.=20 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]." 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." Editorial nits & bits: Page 2: new www address of ECMA www.ecma-international.org There are spurious non-ASCII characters in the text. I found some at = the following places: Captions of all figures 1-14 just after the figure numbers. Captions of all tables 1-4 just after the table numbers. Page 13: Section 8.2.1.1 4th para last line after "value 28 =F4" and = "(address incomplete)=F6"=20 Page 13: Section 8.2.1.3 2nd para: delete the comma in (e.g., ring-back tone)=20 Page 35: caption of table 3 p. 35 "for =E6audio=C6 transfer"=20 Page 35: in table 4 replace .-law by mu-law Page 39: The references in section 13 show non-ASCII in items 1,13,14 = (2x), 17, 19 Page 40: "Annex A (informative) =FB Example ...", see also the = corresponding line in the TOC (page 4) Figures 1, 3, 5, 6 (caption), 8, 9, 11, 12 are stretching across a page break. May be you want to start them on top of the next page.=20 Figure 9 shows unnecessary line breaks between "IP" and "NETWORK" and = before ">|4" and "|5"=20 RFC 3261 is references by its item number from the Reference list i.e. = [10] as well as by "RFC-3261" (4x). May be you want to change the latter = also to [10]. There are several orphan headings/widow lines on the bottom/top of a = page. May be you want to put them on top/bottom of the next/previous page. E.g. 8.2.1.1, 8.2.2.1, 8.2.2.2.2., 8.2.2.2.6, 9.1.3.1, 11, 13 (e-mail address) Regards Thomas=20 ------_=_NextPart_001_01C350E8.E23B7CD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1My4xMiI+DQo8VElUTEU+V0c6ICBb U2lwcGluZ10gV0dMQyBmb3IgUS5TSVAtU0lQIG1hcHBpbmcgZHJhZnQ8L1RJVExFPg0KPC9IRUFE Pg0KPEJPRFk+DQoNCjxQPjxGT05UIFNJWkU9Mj5IZWxsbyw8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxG T05UIFNJWkU9Mj5hcyBpdCBzZWVtcyB0aGF0IG15IG1haWwgZnJvbSB5ZXN0ZXJkYXkgZGlkbid0 IGdldCBmb3J3YXJkZWQgb24gdGhlIHNpcHBpbmcgbGlzdC4gSSdtIGp1c3QgdHJ5aW5nIG9uY2Ug YWdhaW4uPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+UmVnYXJkcyA8L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPlRob21hczwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPi0t LS0tVXJzcHL8bmdsaWNoZSBOYWNocmljaHQtLS0tLTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ Vm9uOiBTdGFjaCBUaG9tYXMgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5HZXNlbmRldCBhbTog RGllbnN0YWcsIDIyLiBKdWxpIDIwMDMgMTc6NDM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPkFu OiAnc2lwcGluZ0BpZXRmLm9yZyc8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPkJldHJlZmY6IFtT aXBwaW5nXSBXR0xDIGZvciBRLlNJUC1TSVAgbWFwcGluZyBkcmFmdDwvRk9OVD4NCjwvUD4NCg0K PFA+PEZPTlQgU0laRT0yPkhlbGxvIEpvaG4sPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5JIGhh ZCBhIGRldGFpbGVkIGxvb2sgaW50byB0aGUgcXNpZzJzaXAgZHJhZnQsIGFuZCBmb3VuZCBvbmx5 IHNvbWUgbWlub3IgaXNzdWVzLCB3aGljaCBjYW4gZWFzaWx5IGJlIGNsYXJpZmVkLiBJbiBteSBv cGluaW9uIHRoZSBkcmFmdCBpcyBtYXR1cmUgYW5kIHNob3VsZCB0YWtlIGl0cyB3YXkgb253YXJk cy48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+SW4gU2VjdGlvbiA4LjEgNHRoIHBhcmEg aXMgc3RhdGVkOjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+JnF1b3Q7VGhlIHByb2Nlc3Npbmcg b2YgYW55IHZhbGlkIFFTSUcgbWVzc2FnZSB0aGF0IGRvZXMgbm90IHNhdGlzZnkgYW55IG9mIDwv Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+dGhlc2UgY29uZGl0aW9ucyBpcyBvdXRzaWRlIHRoZSBz Y29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24uJnF1b3Q7PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9 Mj5UaGlzIHNlZW1zIHRvIGJlIGEgbGl0dGxlIGJpdCB2YWd1ZSBmb3Igc29tZWJvZHkgbm90IGZh bWlsaWFyIHdpdGggUVNJRy4gPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5TaW5jZSB0aGUgaW50 ZXJ3b3JraW5nIG9ubHkgY29tcHJpc2VzIFFTSUcgQmFzaWMgQ2FsbCwgeW91IGNvdWxkIGJlIG1v cmUgc3BlY2lmaWMgYW5kIG1lbnRpb24gdGhlIHVuY29uc2lkZXJlZCBmZWF0dXJlcyBwcm92aWRl ZCBieSBJU08gMTE1ODIgYnkgYWRkaW5nOjwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj4m cXVvdDtUaGlzIGluY2x1ZGVzIGEgUVNJRyBTRVRVUCBtZXNzYWdlIGludGVuZGVkIHRvIGVzdGFi bGlzaCBhIGNhbGwtaW5kZXBlbmRlbnQgc2lnbmFsbGluZyBjb25uZWN0aW9uIGFuZCZuYnNwOyBj b25uZWN0aW9ubGVzcyB0cmFuc3BvcnQgYXMgc3BlY2lmaWVkIGluIFszXS4mcXVvdDs8L0ZPTlQ+ PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+VGhlIFFTSUcgU0VUVVAgbWVzc2FnZSBtYXkgb3B0aW9u YWxseSB0cmFuc3BvcnQgSExDIGFuZCBMTEMgSW5mb3JtYXRpb24gZWxlbWVudHMgd2hpY2ggYXJl IG5vdCBtZW50aW9uZWQgaW4gdGhlIGRyYWZ0LiBZb3UgbWlnaHQgd2FudCB0byBhZGQgc29tZXRo aW5nIGxpa2UgaW50byBzZWN0aW9uIDEwOjwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj4m cXVvdDtUaGUgZ2F0ZXdheSBTSE9VTEQgKG9yIFNIQUxMKD8pKSBub3QgaW5jbHVkZSBhIExvdyBs YXllciBjb21wYXRpYmlsaXR5IGluIHRoZSBRU0lHIFNFVFVQIG1lc3NhZ2UuIFRoZSBnYXRld2F5 IFNIT1VMRCBub3QgaW5jbHVkZSBhIEhpZ2ggbGF5ZXIgY29tcGF0aWJpbGl0eSBpbmZvcm1hdGlv biBlbGVtZW50IGluIHRoZSBRU0lHIFNFVFVQIG1lc3NhZ2UuPC9GT05UPjwvUD4NCg0KPFA+PEZP TlQgU0laRT0yPk5PVEU6IEluY2x1c2lvbiBvZiBhIEhMQyBpbiB0aGUgUVNJRyBTRVRVUCBtZXNz YWdlIG1pZ2h0IGJlIHVzZWZ1bCwgaWYgdGhlIGdhdGV3YXkga25vd3MgcHJpb3IgdG8gc2VuZGlu ZyB0aGUgUVNJRyBTRVRVUCBtZXNzYWdlIHRoYXQgZmF4IGlzIGJlaW5nIHRyYW5zbWl0dGVkIChl LmcuLCBiZWNhdXNlIG9mIGEgY29ycmVzcG9uZGluZyBTRFAgb2ZmZXIpLCBpdCBtYXkgaW5jbHVk ZSBpbiB0aGUgUVNJRyBTRVRVUCBtZXNzYWdlIGEgSGlnaCBsYXllciBjb21wYXRpYmlsaXR5IGlu Zm9ybWF0aW9uIGVsZW1lbnQgaW5kaWNhdGluZyBncm91cCAzIGZheC4mcXVvdDs8L0ZPTlQ+PC9Q Pg0KDQo8UD48Rk9OVCBTSVpFPTI+RWRpdG9yaWFsIG5pdHMgJmFtcDsgYml0czo8L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPlBhZ2UgMjogbmV3IHd3dyBhZGRyZXNzIG9mIEVDTUEgd3d3LmVjbWEt aW50ZXJuYXRpb25hbC5vcmc8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5UaGVyZSBh cmUgc3B1cmlvdXMgbm9uLUFTQ0lJIGNoYXJhY3RlcnMgaW4gdGhlIHRleHQuIEkgZm91bmQgc29t ZSBhdCB0aGUgZm9sbG93aW5nIHBsYWNlczo8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPkNhcHRp b25zIG9mIGFsbCBmaWd1cmVzIDEtMTQganVzdCBhZnRlciB0aGUgZmlndXJlIG51bWJlcnMuPC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj5DYXB0aW9ucyBvZiBhbGwgdGFibGVzIDEtNCBqdXN0IGFm dGVyIHRoZSB0YWJsZSBudW1iZXJzLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+UGFnZSAxMzog U2VjdGlvbiA4LjIuMS4xIDR0aCBwYXJhIGxhc3QgbGluZSBhZnRlciAmcXVvdDt2YWx1ZSAyOCD0 JnF1b3Q7IGFuZCAmcXVvdDsoYWRkcmVzcyBpbmNvbXBsZXRlKfYmcXVvdDsgPC9GT05UPg0KPEJS PjxGT05UIFNJWkU9Mj5QYWdlIDEzOiBTZWN0aW9uIDguMi4xLjMgMm5kIHBhcmE6IGRlbGV0ZSB0 aGUgY29tbWEgaW4gKGUuZy4sIHJpbmctYmFjayB0b25lKSA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la RT0yPlBhZ2UgMzU6IGNhcHRpb24gb2YgdGFibGUgMyBwLiAzNSAmcXVvdDtmb3Ig5mF1ZGlvxiB0 cmFuc2ZlciZxdW90OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlBhZ2UgMzU6IGluIHRhYmxl IDQgcmVwbGFjZSAuLWxhdyBieSBtdS1sYXc8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlBhZ2Ug Mzk6IFRoZSByZWZlcmVuY2VzIGluIHNlY3Rpb24gMTMgc2hvdyBub24tQVNDSUkgaW4gaXRlbXMg MSwxMywxNCAoMngpLCAxNywgMTk8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlBhZ2UgNDA6ICZx dW90O0FubmV4IEEgKGluZm9ybWF0aXZlKSD7IEV4YW1wbGUgLi4uJnF1b3Q7LCBzZWUgYWxzbyB0 aGUgY29ycmVzcG9uZGluZyBsaW5lIGluIHRoZSBUT0MgKHBhZ2UgNCk8L0ZPTlQ+DQo8L1A+DQoN CjxQPjxGT05UIFNJWkU9Mj5GaWd1cmVzIDEsIDMsIDUsIDYgKGNhcHRpb24pLCA4LCA5LCAxMSwg MTIgYXJlIHN0cmV0Y2hpbmcgYWNyb3NzIGEgcGFnZSBicmVhay4gTWF5IGJlIHlvdSB3YW50IHRv IHN0YXJ0IHRoZW0gb24gdG9wIG9mIHRoZSBuZXh0IHBhZ2UuIDwvRk9OVD48L1A+DQoNCjxQPjxG T05UIFNJWkU9Mj5GaWd1cmUgOSBzaG93cyB1bm5lY2Vzc2FyeSBsaW5lIGJyZWFrcyBiZXR3ZWVu ICZxdW90O0lQJnF1b3Q7IGFuZCAmcXVvdDtORVRXT1JLJnF1b3Q7IGFuZCBiZWZvcmUgJnF1b3Q7 Jmd0O3w0JnF1b3Q7IGFuZCAmcXVvdDt8NSZxdW90OyA8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05U IFNJWkU9Mj5SRkMgMzI2MSBpcyByZWZlcmVuY2VzIGJ5IGl0cyBpdGVtIG51bWJlciBmcm9tIHRo ZSBSZWZlcmVuY2UgbGlzdCBpLmUuIFsxMF0gYXMgd2VsbCBhcyBieSAmcXVvdDtSRkMtMzI2MSZx dW90OyAoNHgpLiBNYXkgYmUgeW91IHdhbnQgdG8gY2hhbmdlIHRoZSBsYXR0ZXIgYWxzbyB0byBb MTBdLjwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5UaGVyZSBhcmUgc2V2ZXJhbCBvcnBo YW4gaGVhZGluZ3Mvd2lkb3cgbGluZXMgb24gdGhlIGJvdHRvbS90b3Agb2YgYSBwYWdlLiBNYXkg YmUgeW91IHdhbnQgdG8gcHV0IHRoZW0gb24gdG9wL2JvdHRvbSBvZiB0aGUgbmV4dC9wcmV2aW91 cyBwYWdlLjwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5FLmcuIDguMi4xLjEsIDguMi4y LjEsIDguMi4yLjIuMi4sIDguMi4yLjIuNiwgOS4xLjMuMSwgMTEsIDEzIChlLW1haWwgYWRkcmVz cyk8L0ZPTlQ+DQo8L1A+DQo8QlI+DQoNCjxQPjxGT05UIFNJWkU9Mj5SZWdhcmRzPC9GT05UPg0K PEJSPjxGT05UIFNJWkU9Mj5UaG9tYXMgPC9GT05UPg0KPC9QPg0KDQo8L0JPRFk+DQo8L0hUTUw+ ------_=_NextPart_001_01C350E8.E23B7CD0-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 28 16:34: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 PAA18367 for ; Mon, 28 Jul 2003 15:46: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 19hDw6-0004uu-Bg for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 15:45:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SJjYqq018895 for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 15:45:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDw6-0004ud-6X for sipping-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 15: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 PAA18259 for ; Mon, 28 Jul 2003 15:45:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hDw4-000761-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 15:45:32 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hDvo-000759-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 15:45:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hDvc-0004eQ-Fy; Mon, 28 Jul 2003 15:45:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dbTl-0003DC-5J for sipping@optimus.ietf.org; Fri, 18 Jul 2003 16:05: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 QAA11869 for ; Fri, 18 Jul 2003 16:05:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dbTj-0003E3-00 for sipping@ietf.org; Fri, 18 Jul 2003 16:05: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 19dbTU-0003Bw-00 for sipping@ietf.org; Fri, 18 Jul 2003 16:05:04 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 18 Jul 2003 13:07:15 -0700 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6IK25uD012377; Fri, 18 Jul 2003 13:02:05 -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 AHN69832; Fri, 18 Jul 2003 13:02:03 -0700 (PDT) Message-Id: <4.3.2.7.2.20030718155134.00b12038@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 18 Jul 2003 16:02:03 -0400 To: Stupka Jean-Marie From: Michael Hammer Subject: Re: AW: AW: AW: [Sipping] Question on INVITE Initiated Dialog Event P ackage and Automatic Callback Cc: "'Alan Johnston'" , "'Jonathan Rosenberg'" , Rohan Mahy , "'sipping@ietf.org'" In-Reply-To: <931A17FBB884D411B02B0008C70D9E2ABF1324@mchh243e.mchh.sieme ns.de> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_17664349==_.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: , --=====================_17664349==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Jean-Marie, The fact that A may want to reserve some media resources may be an implementation detail. Requiring the GW to maintain state for a failed call is probably not the best use of media resources for the GW. Better to release those media reserved, and only let A separately request SUBSCRIPTION dialog be established to report on availability of user B. When B's media resources free up, then A can re-submit the INVITE. It's probably less brittle that way. Mike At 11:25 AM 7/18/2003 +0200, Stupka Jean-Marie wrote: >Hi Alan, all, > >Thanks for your answer. Having seen your comments, I think that my >previous mail was somewhat unclear. Let me clarify my concerns with the >flows below. > > > A GW / B > | | > | INVITE F1 | > |--------------->| > |486 Busy Here F2| > |<---------------| User B is busy > | ACK F3 | > |--------------->| > | | > | | > >User A calls user B which is either a SIP client (B) or a PSTN subscriber >behind a Gateway (GW). User B is initially busy when User A calls. > >The dialog initiated by the INVITE terminates upon reception of the 486. >After having received the 486, a standard SIP client -- i.e. a client >compliant to RFC3261 -- considers the INVITE transaction completed and >generates the ACK for the response (this behavior is described in 13.2.2.3 >of RFC3261). > >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. > >For the reason above, a procedure is needed to keep the dialog/transaction >open after a 486. Of course it would only make sense to keep the dialog if >an automatic callback is possible, e.g. not precluded by other services at >the remote user side, lacking network resources, etc. This should be >indicated to the A's SIP UA. If automatic callback is possible, then the >dialog (the transaction having the call data) shall not be terminated upon >reception of a 486, leaving user A the possibility to request automatic >callback. >If user A does not request automatic callback within a reasonable time >interval (about 10-15s) the dialog terminates. >If user A does request automatic callback then a SUBSCRIBE (F4) is sent on >the already existing dialog that was initiated by the preceding INVITE >(F1). Sending the SUBSCRIBE within the dialog initiated by the INVITE of >the preceding call attempt would ease the implementation because the call >data are available within this dialog at the SIP user side and at its peer >(e.g. the gateway in the PSTN). The call data can then be re-used for the >SUBSCRIBE request and for the subsequent call when user B gets free. > >The flow then looks like this: > > > A GW / B > | | > | INVITE F1 | > |--------------->| > |486 Busy Here F2| > |<---------------| User B is busy > T |(Autom.Callback | T Timer for automatic callback > | | possible) | | > | | ACK F3 | | > | |--------------->| | > | | | | >==> | | | | User A requests automatic callback > | | | | > | | SUBSCRIBE F4 | | > v |--------------->| v > | 200 OK F5 | > |<---------------| > | NOTIFY F6 | > |<---------------| > | 200 OK F7 | > |--------------->| > | | > | NOTIFY F8 | <== User B is now available > |<---------------| > | 200 OK F9 | > |--------------->| > | | > | INVITE F10 | > |--------------->| Session setup successfully > | 180 Ringing F11| > |<---------------| > | 200 OK F12 | > |<---------------| > | ACK F13 | > |--------------->| > | Media Session | > |<==============>| > | | > >User A calls user B which is either a SIP client (B) or a PSTN subscriber >behind a Gateway (GW). User B is initially busy when user A calls. > >- F1 INVITE creates a new dialog between A and GW/B (let's say D1) > >- F2 486 Busy Here: automatic callback is possible. >GW/B indicates to A that automatic callback is possible and starts a timer >in order to retain the dialog and call data for a possible request for >automatic callback. >When receiving a 486 with the indication automatic callback possible, A >starts a timer in order to retain the dialog and call data giving user A >the possibility to request automatic callback. >If the timer expires (no callback request has arrived) then the >dialog/transaction is terminated at A and GW/B. > >- User A requests automatic callback: A stops the timer and sends a >SUBSCRIBE request to GW/B (F4) within the dialog (D1) initiated by the >preceding INVITE. There is one hand no necessity to open a new dialog, and >one the other hand, sending the SUBSCRIBE within the dialog initiated by >the INVITE of the preceding call attempt would ease the implementation >because the call data are available within this dialog at the SIP user >side and at its peer (e.g. the gateway in the PSTN) > >- F4 SUBSCRIBE: GW/B stops the timer and starts monitoring B states. >F5, F6, F7, F8, F9 as in 2.17 of draft-ietf-sipping-service-examples-04.txt > >- F10 INVITE: A sends the INVITE within the still open dialog (D1) >initiated by F1 (reason given above) > >- F11, etc. as in 2.17 > >Summary: >- There is a need to retain dialogs initiated by an INVITE after a 486 >message when automatic callback is possible >- It is desirable that the SUBSCRIBE request and a subsequent call set-up >triggered by the NOTIFY uses the pre-existing dialog initiated by the >preceding INVITE. > >I hope I have clarified my concerns. > >Regards, >Jean-Marie > > > > > -----Ursprungliche Nachricht----- > > Von: Alan Johnston [mailto:alan.johnston@mci.com] > > Gesendet: Donnerstag, 17. Juli 2003 11:04 > > An: Stupka Jean-Marie; Rohan Mahy > > Cc: 'Jonathan Rosenberg'; 'sipping@ietf.org' > > Betreff: Re: AW: AW: [Sipping] Question on INVITE Initiated > > Dialog Event > > Package and Automatic Callback > > > > > > Hi Jean-Marie, > > > > Comments below. > > > > Thanks, > > Alan Johnston > > MCI > > > > At 10:21 AM 7/17/2003 +0200, Stupka Jean-Marie wrote: > > >Hi Alan, > > > > > >The flow 2.17 of draft-ietf-sipping-service-examples-04.txt > > is a good > > >example to show what is wrong. After the 486 message and the ACK the > > >transaction is terminated: 13.2.2.3 of RFC3261 says "All > > early dialogs are > > >considered terminated upon reception of the non-2xx final response". > > > > In this flow, the dialog between Alice and Bob does terminate > > with the > > INVITE/486/ACK exchange. However, Bob has a dialog with > > another user, say > > Carol (perhaps the flow should show this for clarity?). If > > Bob was not > > currently involved in a dialog, the 486 would not have been > > sent, right? > >Right. > > > > > > As a consequence, all data related to the previous call > > attempt are lost > > > (why and how long should a SIP client keep this data?). > > This is at least > > > conforming RFC3261. > > > > Bob is in a dialog with Carol and keeps this dialog state for > > as long as > > the session exists (as long as Bob is busy). > >Right. > > > > > >Therefore, the SUBSCRIBE message shown in the flow is just > > not possible, > > >as the destination address (Bob's address or user number) is no more > > >existing at the SIP user side. > > > > I don't know what you mean here. Bob still exists - he is still > > sip:bob@biloxi.example.com, right? As a result, Bob can receive a > > SUBSCRIBE request from Alice. Alice does not specify any > > call-id, to-tag, > > or from-tag Event parameters, so that means that Alice is requesting > > information about ANY dialogs that Bob is currently active > > in. (Alice is > > not requesting information about only dialogs with Alice - > > this information > > would be redundant since if Alice is in the dialog, Alice > > would already > > know the state and dialog identifiers.) All the NOTIFYs that Alice > > receives provides information about the dialog between Bob and Carol. > > > >See explanation and flows above. > > > >Keeping the data for a short period of time after a 486 > > would help, but I > > >wouldn't say that this is an implementation matter, the > > behavior of a SIP > > >client needs to be predictable, i.e. standardized. > > > > Dialog state does need to be kept for 32 seconds after sending a > > non-success final response in case of the loss of the 486 > > which would be > > detected by the failure to receive an ACK. However, this has > > no bearing on > > this scenario. > >See explanation and flows above. > > > > > >Coming back to my initial concern, the PSTN call completion > > application > > >given as an example in > > draft-ietf-sipping-dialog-package-02.txt. Sending a > > >SUBSCRIBE to the Dialog Package within the dialog initiated > > by the INVITE > > >of the preceding call attempt would ease the implementation > > because the > > >call data are available within this dialog at the SIP user > > side and at its > > >peer (e.g. the gateway in the PSTN). This is in my understanding the > > >benefit of draft-ietf-sipping-dialog-package-02.txt. > > > > Are you saying that you would like Alice to be able to send a > > SUBSCRIBE to > > Bob within the dialog between Bob and Carol? This is not > > possible - a > > dialog is between two peers - a third party can not inject messages. > > > >Of course not, see explanation and flows above. > > > > > >A possible solution would be to keep for a short period of > > time the dialog > > >with the data of the previous call attempt (i.e. the called > > user number, > > >the bearer description, ...) at the user agent after a 486 > > is received if > > >an automatic callback is possible (e.g. not precluded by > > other services at > > >the remote user side, lacking network resources, etc.). > > > > Are you perhaps concerned about authorizing the subscription? > > That is, Bob > > only accepts a SUBSCRIBE from Alice if Alice has previously > > just made a > > call attempt (sent an INVITE and received a 486 busy)? If > > this is what you > > want, I'm not sure the exact benefit of this. > >Not at all my concern. > > > > > >Then the called user number and other data from the > > preceding call attempt > > >could be re-used for the SUBSCRIBE request and for the > > subsequent call > > >when the remote user gets free. This would require to extend > > the 486 with > > >a "Automatic Callback Possible" indication, or to introduce > > a new message > > >with this meaning and the procedure of retaining data - a > > change to RFC3261. > > > > > >Any view on that? > > > > > >Thanks, > > >Jean-Marie > > > > > > > > >-----Ursprungliche Nachricht----- > > >Von: Alan Johnston [mailto:alan.johnston@mci.com] > > >Gesendet: Mittwoch, 16. Juli 2003 20:39 > > >An: Rohan Mahy; Stupka Jean-Marie > > >Cc: 'Jonathan Rosenberg'; 'sipping@ietf.org' > > >Betreff: Re: AW: [Sipping] Question on INVITE Initiated Dialog Event > > >Package a nd Automatic C allback > > > > > > > > >Hi Jean-Marie, > > > > > >The SIP Service Examples section 2.17 shows exactly this flow with a > > >SUBSCRIBE outside of the dialog (which ended with the 486). > > > > > >Thanks, > > >Alan Johnston > > >MCI > > > > > >At 05:21 AM 7/15/2003 -0700, Rohan Mahy wrote: > > > >Jean-Marie, > > > > > > > >It seems perfectly reasonable to send a SUBSCRIBE to the > > dialog package > > > >outside of a dialog. The default behavior would be to > > send a list of > > > >dialogs but with no dialog information or peer > > information. I believe > > > >this is sufficient to build a callback service. > > > > > > > >thanks, > > > >-rohan > > > > > > > > > > > > > > > >On Tuesday, July 15, 2003, at 02:53 AM, Stupka Jean-Marie wrote: > > > > > > > >>Jonathan, > > > >> > > > >>I doubt that sending the SUBSCRIBE request for the dialog > > package outside > > > >>of any dialog is possible in case of automatic callback, since the > > > >>required data are no more available. > > > >> > > > >>The problem is that when a 486 is received, the dialog > > initiated by the > > > >>INVITE terminates and, the data related to that dialog > > (including the > > > >>called user number) disappear. Therefore it is no more > > possible to send > > > >>the SUBSCRIBE to request automatic callback for this destination. > > > >> > > > >>A possible solution would be to keep for a short period > > of time the data > > > >>of the previous call attempt (i.e. the called user > > number, the bearer > > > >>description, ...) at the user agent after a 486 is > > received. This would > > > >>allow the user agent to re-use the called user number and > > other data from > > > >>the preceding call attempt for the SUBSCRIBE request and for the > > > >>subsequent call after the remote user is free. However, > > the procedure of > > > >>retaining data is not foreseen in RFC 3261. > > > >> > > > >>A better (more economical and user friendly) solution > > would be to keep at > > > >>the user agent only when an automatic callback is > > possible (e.g. not > > > >>precluded by other services at the remote user side, > > lacking network > > > >>resources, etc.). This would require to extend the 486 > > with a "Automatic > > > >>Callback Possible" indication, or to introduce a new > > message with this > > > meaning. > > > >> > > > >>Jean-Marie > > > >> > > > >>-----Ursprungliche Nachricht----- > > > >>Von: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > >>Gesendet: Montag, 14. Juli 2003 10:18 > > > >>An: Stupka Jean-Marie > > > >>Cc: 'sipping@ietf.org' > > > >>Betreff: Re: [Sipping] Question on INVITE Initiated > > Dialog Event Package > > > >>and Automatic C allback > > > >> > > > >> > > > >>The dialog package can be used by subscriptions made both > > within, and > > > >>outside, of a dialog. So, in the case of automatic callback, the > > > >>caller would, after receiving a 486, send a SUBSCRIBE > > request for the > > > >>dialog package, and do so outside of any dialog. > > > >> > > > >>-Jonathan R. > > > >> > > > >>Stupka Jean-Marie wrote: > > > >> > > > >>>Hello All, > > > >>> > > > >>>As said in RFC 3265 it is possible to create an event > > subscription > > > >>>within a pre-existing dialog, e.g. a dialog created by an INVITE. > > > >>>In my understanding, this is the intention of > > > >>>draft-ietf-sipping-dialog-package-02.txt. > > > >>> > > > >>>According to the (PSTN) Automatic Callback given as example > > > >>>application in the introduction of this draft, user A > > can request a > > > >>>callback when user B hangs-up. User A off course needs to get the > > > >>>information that user B is busy before requesting the automatic > > > >>>callback, i.e. receive a "486 Busy Here" message. However, all > > > >>>early dialogs are considered terminated upon reception > > of a non-2xx > > > >>>final response (13.2.2.3 of RFC 3261). As consequence, the dialog > > > >>>and thus the data of the preceding call attempt are no more > > > >>>available and the callback cannot be requested. > > > >>> > > > >>>Can somebody provide clarification of the applicability > > of RFC 3265 > > > >>>and the draft-ietf-sipping-dialog-package-02.txt to Automatic > > > >>>Callback? > > > >>> > > > >>>Regards, > > > >>> > > > >>>Jean-Marie > > > >>> > > > >>> > > > >>>_______________________________________________ Sipping mailing > > > >>>list https://www1.ietf.org/mailman/listinfo/sipping This list is > > > >>>for NEW development of the 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 --=====================_17664349==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jean-Marie,

The fact that A may want to reserve some media resources may be an implementation detail.  Requiring the GW to maintain state for a failed call is probably not the best use of media resources for the GW.  Better to release those media reserved, and only let A separately request SUBSCRIPTION dialog be established to report on availability of user B.  When B's media resources free up, then A can re-submit the INVITE.  It's probably less brittle that=20 way.

Mike

At 11:25 AM 7/18/2003 +0200, Stupka Jean-Marie wrote:
Hi Alan, all,

Thanks for your answer. Having seen your comments, I think that my previous mail was somewhat unclear. Let me clarify my concerns with the flows below.


          A             GW / B
          |            &nb= sp;   |
          |    INVITE F1   |
          |--------------->|
          |486 Busy Here F2|
          |<---------------|    User B is busy
          |     ACK F3     |
          |--------------->|
          |            &nb= sp;   |
          |            &nb= sp;   |

User A calls user B which is either a SIP client (B) or a PSTN subscriber behind a Gateway (GW). User B is initially busy when User A calls.

The dialog initiated by the INVITE terminates upon reception of the 486. After having received the 486, a standard SIP client -- i.e. a client compliant to RFC3261 -- considers the INVITE transaction completed and generates the ACK for the response (this behavior is described in 13.2.2.3 of RFC3261).

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.

For the reason above, a procedure is needed to keep the dialog/transaction open after a 486. Of course it would only make sense to keep the dialog if an automatic callback is possible, e.g. not precluded by other services at the remote user side, lacking network resources, etc. This should be indicated to the A's SIP UA. If automatic callback is possible, then the dialog (the transaction having the call data) shall not be terminated upon reception of a 486, leaving user A the possibility to request automatic callback.
If user A does not request automatic callback within a reasonable time interval (about 10-15s) the dialog terminates.
If user A does request automatic callback then a SUBSCRIBE (F4) is sent on the already existing dialog that was initiated by the preceding INVITE (F1). Sending the SUBSCRIBE within the dialog initiated by the INVITE of the preceding call attempt would ease the implementation because the call data are available within this dialog at the SIP user side and at its peer (e.g. the gateway in the PSTN). The call data can then be re-used for the SUBSCRIBE request and for the subsequent call when user B gets free.

The flow then looks like this:


          A             GW / B
          |            &nb= sp;   |
          |    INVITE F1   |
          |--------------->|
          |486 Busy Here F2|
          |<---------------|      User B is busy
     T    |(Autom.Callback |   T  Timer for automatic callback
     |    |   possible)    |   |
     |    |     ACK F3     |   |
     |    |--------------->|   |
     |    |            &nb= sp;   |   |
=3D=3D>  |    |            &nb= sp;   |   |  User A requests automatic callback
     |    |            &nb= sp;   |   |
     |    |  SUBSCRIBE F4  |   |
     v    |--------------->|   v
          |   200 OK F5    |
          |<---------------|
          |    NOTIFY F6   |
          |<---------------|
          |   200 OK F7    |
          |--------------->|
          |            &nb= sp;   |
          |    NOTIFY F8   |  <=3D=3D User B is now available
          |<---------------|
          |   200 OK F9    |
          |--------------->|
          |            &nb= sp;   |
          |   INVITE F10   |
          |--------------->|      Session setup successfully
          | 180 Ringing F11|
          |<---------------|
          |   200 OK F12   |
          |<---------------|
          |     ACK F13    |
          |--------------->|
          |  Media Session |
          |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|
          |            &nb= sp;   |

User A calls user B which is either a SIP client (B) or a PSTN subscriber behind a Gateway (GW). User B is initially busy when user A calls.

- F1 INVITE creates a new dialog between A and GW/B (let's say D1)

- F2 486 Busy Here: automatic callback is possible.
GW/B indicates to A that automatic callback is possible and starts a timer in order to retain the dialog and call data for a possible request for automatic callback.
When receiving a 486 with the indication automatic callback possible, A starts a timer in order to retain the dialog and call data giving user A the possibility to request automatic callback.
If the timer expires (no callback request has arrived) then the dialog/transaction is terminated at A and GW/B.

- User A requests automatic callback: A stops the timer and sends a SUBSCRIBE request to GW/B (F4) within the dialog (D1) initiated by the preceding INVITE. There is one hand no necessity to open a new dialog, and one the other hand, sending the SUBSCRIBE within the dialog initiated by the INVITE of the preceding call attempt would ease the implementation because the call data are available within this dialog at the SIP user side and at its peer (e.g. the gateway in the PSTN)

- F4 SUBSCRIBE: GW/B stops the timer and starts monitoring B states.
F5, F6, F7, F8, F9 as in 2.17 of draft-ietf-sipping-service-examples-04.txt

- F10 INVITE: A sends the INVITE within the still open dialog (D1) initiated by F1 (reason given above)

- F11, etc. as in 2.17

Summary:
- There is a need to retain dialogs initiated by an INVITE after a 486 message when automatic callback is possible
- It is desirable that the SUBSCRIBE request and a subsequent call set-up triggered by the NOTIFY uses the pre-existing dialog initiated by the preceding INVITE.

I hope I have clarified my concerns.

Regards,
Jean-Marie



> -----Ursprungliche Nachricht-----
> Von: Alan Johnston [mailto:alan.johnston@mci.com]
> Gesendet: Donnerstag, 17. Juli 2003 11:04
> An: Stupka Jean-Marie; Rohan Mahy
> Cc: 'Jonathan Rosenberg'; 'sipping@ietf.org'
> Betreff: Re: AW: AW: [Sipping] Question on INVITE Initiated
> Dialog Event
> Package and Automatic Callback
>
>
> Hi Jean-Marie,
>
> Comments below.
>
> Thanks,
> Alan Johnston
> MCI
>
> At 10:21 AM 7/17/2003 +0200, Stupka Jean-Marie wrote:
> >Hi Alan,
> >
> >The flow 2.17 of draft-ietf-sipping-service-examples-04.txt
> is a good
> >example to show what is wrong. After the 486 message and the ACK the
> >transaction is terminated: 13.2.2.3 of RFC3261 says "All
> early dialogs are
> >considered terminated upon reception of the non-2xx final response".
>
> In this flow, the dialog between Alice and Bob does terminate
> with the
> INVITE/486/ACK exchange.  However, Bob has a dialog with
> another user, say
> Carol (perhaps the flow should show this for clarity?).  If
> Bob was not
> currently involved in a dialog, the 486 would not have been
> sent, right?

Right.

>
> >  As a consequence, all data related to the previous call
> attempt are lost
> > (why and how long should a SIP client keep this data?).
> This is at least
> > conforming RFC3261.
>
> Bob is in a dialog with Carol and keeps this dialog state for
> as long as
> the session exists (as long as Bob is busy).

Right.

>
> >Therefore, the SUBSCRIBE message shown in the flow is just=20
> not possible,
> >as the destination address (Bob's address or user number) is no more
> >existing at the SIP user side.
>
> I don't know what you mean here.  Bob still exists - he is still
> sip:bob@biloxi.example.com, right?  As a result, Bob can receive a
> SUBSCRIBE request from Alice.  Alice does not specify any=20
> call-id, to-tag,
> or from-tag Event parameters, so that means that Alice is requesting
> information about ANY dialogs that Bob is currently active
> in.  (Alice is
> not requesting information about only dialogs with Alice -
> this information
> would be redundant since if Alice is in the dialog, Alice
> would already
> know the state and dialog identifiers.)  All the NOTIFYs that Alice
> receives provides information about the dialog between Bob and Carol.
>

See explanation and flows above.

> >Keeping the data for a short period of time after a 486
> would help, but I
> >wouldn't say that this is an implementation matter, the
> behavior of a SIP
> >client needs to be predictable, i.e. standardized.
>
> Dialog state does need to be kept for 32 seconds after sending a
> non-success final response in case of the loss of the 486
> which would be
> detected by the failure to receive an ACK.  However, this has
> no bearing on
> this scenario.

See explanation and flows above.

>
> >Coming back to my initial concern, the PSTN call completion
> application
> >given as an example in
> draft-ietf-sipping-dialog-package-02.txt. Sending a
> >SUBSCRIBE to the Dialog Package within the dialog initiated
> by the INVITE
> >of the preceding call attempt would ease the implementation
> because the
> >call data are available within this dialog at the SIP user=20
> side and at its
> >peer (e.g. the gateway in the PSTN). This is in my understanding the
> >benefit of draft-ietf-sipping-dialog-package-02.txt.
>
> Are you saying that you would like Alice to be able to send a
> SUBSCRIBE to
> Bob within the dialog between Bob and Carol?  This is not=20
> possible - a
> dialog is between two peers - a third party can not inject messages.
>

Of course not, see explanation and flows above.

>
> >A possible solution would be to keep for a short period of=20
> time the dialog
> >with the data of the previous call attempt (i.e. the called
> user number,
> >the bearer description, ...) at the user agent after a 486=20
> is received if
> >an automatic callback is possible (e.g. not precluded by
> other services at
> >the remote user side, lacking network resources, etc.).
>
> Are you perhaps concerned about authorizing the subscription?
>  That is, Bob
> only accepts a SUBSCRIBE from Alice if Alice has previously
> just made a
> call attempt (sent an INVITE and received a 486 busy)?  If
> this is what you
> want, I'm not sure the exact benefit of this.

Not at all my concern.

>
> >Then the called user number and other data from the
> preceding call attempt
> >could be re-used for the SUBSCRIBE request and for the
> subsequent call
> >when the remote user gets free. This would require to extend
> the 486 with
> >a "Automatic Callback Possible" indication, or to introduce
> a new message
> >with this meaning and the procedure of retaining data - a
> change to RFC3261.
> >
> >Any view on that?
> >
> >Thanks,
> >Jean-Marie
> >
> >
> >-----Ursprungliche Nachricht-----
> >Von: Alan Johnston [mailto:alan.johnston@mci.com]
> >Gesendet: Mittwoch, 16. Juli 2003 20:39
> >An: Rohan Mahy; Stupka Jean-Marie
> >Cc: 'Jonathan Rosenberg'; 'sipping@ietf.org'
> >Betreff: Re: AW: [Sipping] Question on INVITE Initiated Dialog Event
> >Package a nd Automatic C allback
> >
> >
> >Hi Jean-Marie,
> >
> >The SIP Service Examples section 2.17 shows exactly this flow with a
> >SUBSCRIBE outside of the dialog (which ended with the=20 486).
> >
> >Thanks,
> >Alan Johnston
> >MCI
> >
> >At 05:21 AM 7/15/2003 -0700, Rohan Mahy wrote:
> > >Jean-Marie,
> > >
> > >It seems perfectly reasonable to send a SUBSCRIBE to the
> dialog package
> > >outside of a dialog.  The default behavior would be to
> send a list of
> > >dialogs but with no dialog information or peer
> information.  I believe
> > >this is sufficient to build a callback service.
> > >
> > >thanks,
> > >-rohan
> > >
> > >
> > >
> > >On Tuesday, July 15, 2003, at 02:53 AM, Stupka Jean-Marie wrote:
> > >
> > >>Jonathan,
> > >>
> > >>I doubt that sending the SUBSCRIBE request for the dialog
> package outside
> > >>of any dialog is possible in case of automatic callback, since the
> > >>required data are no more available.
> > >>
> > >>The problem is that when a 486 is received, the dialog
> initiated by the
> > >>INVITE terminates and, the data related to that dialog
> (including the
> > >>called user number) disappear. Therefore it is no more
> possible to send
> > >>the SUBSCRIBE to request automatic callback for this destination.
> > >>
> > >>A possible solution would be to keep for a short period
> of time the data
> > >>of the previous call attempt (i.e. the called user
> number, the bearer
> > >>description, ...) at the user agent after a 486 is
> received. This would
> > >>allow the user agent to re-use the called user number and
> other data from
> > >>the preceding call attempt for the SUBSCRIBE request and for the
> > >>subsequent call after the remote user is free. However,
> the procedure of
> > >>retaining data is not foreseen in RFC 3261.
> > >>
> > >>A better (more economical and user friendly) solution
> would be to keep at
> > >>the user agent only when an automatic callback is=20
> possible (e.g. not
> > >>precluded by other services at the remote user side,
> lacking network
> > >>resources, etc.). This would require to extend the 486
> with a "Automatic
> > >>Callback Possible" indication, or to introduce a new
> message with this
> > meaning.
> > >>
> > >>Jean-Marie
> > >>
> > >>-----Ursprungliche Nachricht-----
> > >>Von: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> > >>Gesendet: Montag, 14. Juli 2003 10:18
> > >>An: Stupka Jean-Marie
> > >>Cc: 'sipping@ietf.org'
> > >>Betreff: Re: [Sipping] Question on INVITE Initiated
> Dialog Event Package
> > >>and Automatic C allback
> > >>
> > >>
> > >>The dialog package can be used by subscriptions made both
> within, and
> > >>outside, of a dialog. So, in the case of automatic callback, the
> > >>caller would, after receiving a 486, send a SUBSCRIBE
> request for the
> > >>dialog package, and do so outside of any dialog.
> > >>
> > >>-Jonathan R.
> > >>
> > >>Stupka Jean-Marie wrote:
> > >>
> > >>>Hello All,
> > >>>
> > >>>As said in RFC 3265 it is possible to create an event
> subscription
> > >>>within a pre-existing dialog, e.g. a dialog created by an INVITE.
> > >>>In my understanding, this is the intention of
> > >>>draft-ietf-sipping-dialog-package-02.txt.
> > >>>
> > >>>According to the (PSTN) Automatic Callback given as example
> > >>>application in the introduction of this draft, user A
> can request a
> > >>>callback when user B hangs-up. User A off course needs to get the
> > >>>information that user B is busy before requesting the automatic
> > >>>callback, i.e. receive a "486 Busy Here" message. However, all
> > >>>early dialogs are considered terminated upon reception
> of a non-2xx
> > >>>final response (13.2.2.3 of RFC 3261). As consequence, the dialog
> > >>>and thus the data of the preceding call attempt are no more
> > >>>available and the callback cannot be requested.
> > >>>
> > >>>Can somebody provide clarification of the applicability
> of RFC 3265
> > >>>and the draft-ietf-sipping-dialog-package-02.txt to Automatic
> > >>>Callback?
> > >>>
> > >>>Regards,
> > >>>
> > >>>Jean-Marie
> > >>>
> > >>>
> > >>>_______________________________________________ Sipping mailing
> > >>>list  https://www1.ietf.org/mailman/listinfo/sipping This list is
> > >>>for NEW development of the 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.           &nbs= p;    600 Lanidex Plaza
> > >>Chief Technology= Officer           &n= bsp;        Parsippany,
> NJ 07054-2711
> > >>dynamicsoft
> >= >>jdrosen@dynamicsoft.com       &n= bsp;            = FAX:   (973) 952-5050
> > >>http://www.jdrosen.net     &nbs= p;            &n= bsp;  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
--=====================_17664349==_.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 Mon Jul 28 17:33: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 RAA21439 for ; Mon, 28 Jul 2003 17:33: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 19hFcF-0005kN-2s for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 17:33:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SLXBOR022092 for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 17: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 19hFcE-0005kF-Sf for sipping-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 17:33: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 RAA21433 for ; Mon, 28 Jul 2003 17:33:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hFcC-0000HB-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 17:33:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hFcB-0000H8-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 17: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 19hFc5-0005gR-Jz; Mon, 28 Jul 2003 17: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 19hFby-0005gE-NU for sipping@optimus.ietf.org; Mon, 28 Jul 2003 17:32: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 RAA21425 for ; Mon, 28 Jul 2003 17:32:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hFbw-0000Gy-00 for sipping@ietf.org; Mon, 28 Jul 2003 17:32:52 -0400 Received: from ns2.research.bell-labs.com ([204.178.16.49] helo=crufty.research.bell-labs.com) by ietf-mx with esmtp (Exim 4.12) id 19hFbv-0000Gv-00 for sipping@ietf.org; Mon, 28 Jul 2003 17:32:51 -0400 Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h6SLWk9Y019685; Mon, 28 Jul 2003 17:32:46 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h6SLWd1u078881; Mon, 28 Jul 2003 17:32:40 -0400 (EDT) Received: from bell-labs.com (volker-hopc [135.180.240.186]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h6SLWdh2010836; Mon, 28 Jul 2003 17:32:39 -0400 (EDT) Message-ID: <3F25962A.4030103@bell-labs.com> Date: Mon, 28 Jul 2003 17:31:22 -0400 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sipping Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Static and dynamic policies requirement Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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, would it make sense to include requirements for the support of static and dynamic policies in the policy requirements draft? These requirements could look like the following: REQ-POL-14: The solution should allow the specification of dynamic policies on a call-by-call basis. REQ-POL-15: The solution should allow the specification of static policies, which are applicable to certain calls for a given time. Thanks, Volker -- Volker Hilt Bell Labs / Lucent Technologies phone: +1 732 332 6432 101 Crawfords Corner Rd email: volkerh@bell-labs.com Holmdel, NJ 07733 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 28 18:40: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 SAA23855 for ; Mon, 28 Jul 2003 18:40: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 19hGf3-00086F-6S for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 18:40:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SMe99u031131 for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 18:40:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hGf3-000862-3c for sipping-web-archive@optimus.ietf.org; Mon, 28 Jul 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 SAA23832 for ; Mon, 28 Jul 2003 18:40:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hGf0-0000f8-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 18:40:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hGez-0000f5-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 18:40:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hGew-00084V-2b; Mon, 28 Jul 2003 18: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 19hGec-00083p-13 for sipping@optimus.ietf.org; Mon, 28 Jul 2003 18:39: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 SAA23795 for ; Mon, 28 Jul 2003 18:39:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hGeZ-0000eG-00 for sipping@ietf.org; Mon, 28 Jul 2003 18:39:39 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19hGeY-0000e7-00 for sipping@ietf.org; Mon, 28 Jul 2003 18:39:38 -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 h6SMcmSK007106; Mon, 28 Jul 2003 18:38:56 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jul 2003 17:38:47 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E8626A@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Cullen Jennings'" , Romel Khan , sipping@ietf.org Subject: RE: [Sipping] Diversion header Date: Mon, 28 Jul 2003 17:38: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: , Cullen Jennings [mailto:fluffy@cisco.com] writes: > Give some careful thought to if the "To" header meets your > needs and if it does use - The To header is widely implemented :-) There are some heavy caveats to be noted here. Of primary note is that the "To" header is merely going to represent what URI the UAC thought it was sending the initial request of the call to. This may or may not be something that makes sense in your context. Consider, for example, that my device might have an interface that most comfortably allows me to input numerical digits. It then takes these digits and, by default, sends them to a proxy local to my site. I have, in this example, set up my local proxy to take any one- or two-digit extensions, perform a lookup in a local "speed dial" table, and retarget the request accordingly. In this case, you may well get a request with a "To" header field like: "To: " or "To: ". That probably doesn't get you quite as much information as you'd like, since the mapping of the "To" field to anything relevant to anyone other than me isn't something you have access to. Myriad other such cases exist. So, while Cullen is right that you can (generally) look at the "To" header to find out what the original response Request-URI probably was, the practical truth is that you typically can't rely on that information to be useful from a service perspective. /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 Jul 28 22:45: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 WAA27970 for ; Mon, 28 Jul 2003 22:45: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 19hKUC-0006vG-6n for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 22:45:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6T2jCg2026607 for sipping-archive@odin.ietf.org; Mon, 28 Jul 2003 22:45:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hKUB-0006v4-JI for sipping-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 22:45: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 WAA27941 for ; Mon, 28 Jul 2003 22:45:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hKU8-000269-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 22:45:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hKU7-000265-00 for sipping-web-archive@ietf.org; Mon, 28 Jul 2003 22:45:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hKU1-0006u4-Tj; Mon, 28 Jul 2003 22: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 19hKTi-0006tF-15 for sipping@optimus.ietf.org; Mon, 28 Jul 2003 22:44: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 WAA27921 for ; Mon, 28 Jul 2003 22:44:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hKTe-00025b-00 for sipping@ietf.org; Mon, 28 Jul 2003 22:44:38 -0400 Received: from pmesmtp01.wcom.com ([199.249.20.1]) by ietf-mx with esmtp (Exim 4.12) id 19hKTd-00025W-00 for sipping@ietf.org; Mon, 28 Jul 2003 22:44:37 -0400 Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HIR00159LVT23@firewall.wcom.com> for sipping@ietf.org; Tue, 29 Jul 2003 02:35:54 +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 <0HIR00B01LVTHZ@dgismtp04.wcomnet.com>; Tue, 29 Jul 2003 02:35:53 +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 <0HIR007FZLVO6W@dgismtp04.wcomnet.com>; Tue, 29 Jul 2003 02:35:53 +0000 (GMT) Date: Mon, 28 Jul 2003 21:35:48 -0500 From: Henry Sinnreich Subject: RE: AW: [Sipping] FYI: RADIUS & SIP In-reply-to: To: "'Bernard Aboba'" Cc: hgs@cs.columbia.edu, sipping@ietf.org, "'Dumler, Alexander'" , "'Liess, Laura'" , "'Wolff, Christian'" Message-id: <0HIR007G2LVS6W@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: AcNVeasukyAsSAVmQc2VUnVd1qnOSw== 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, 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. Incidentally, the latest Wi-Fi online documents at microsoft.com also show RADIUS for AAA and at other sites, such as Cisco you will find the same for SIP and Wi-Fi for example. Pushing DIAMETER by the IETF seems uncomprehensible to me, especially in the era of web services, such as .NET and other. Could you explain your reasons for pushing DIAMETER vs. RADIUS (99.99% of installed base) or vs. web services? 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 Bernard Aboba > Sent: Saturday, July 19, 2003 10:37 PM > To: Liess, Laura > Cc: hgs@cs.columbia.edu; sipping@ietf.org; Dumler, Alexander; > Wolff, Christian > Subject: Re: AW: [Sipping] FYI: RADIUS & SIP > > 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 > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 29 06:23: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 GAA17654 for ; Tue, 29 Jul 2003 06:23: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 19hRdR-0005hz-B2 for sipping-archive@odin.ietf.org; Tue, 29 Jul 2003 06:23:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TANDFw021939 for sipping-archive@odin.ietf.org; Tue, 29 Jul 2003 06: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 19hRdR-0005hm-6x for sipping-web-archive@optimus.ietf.org; Tue, 29 Jul 2003 06: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 GAA17650 for ; Tue, 29 Jul 2003 06:23:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hRdN-00043S-00 for sipping-web-archive@ietf.org; Tue, 29 Jul 2003 06:23:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hRdM-00043P-00 for sipping-web-archive@ietf.org; Tue, 29 Jul 2003 06:23:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hRdG-0005gr-7d; Tue, 29 Jul 2003 06: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 19hRd6-0005gP-Qj for sipping@optimus.ietf.org; Tue, 29 Jul 2003 06: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 GAA17647 for ; Tue, 29 Jul 2003 06:22:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hRd2-00043I-00 for sipping@ietf.org; Tue, 29 Jul 2003 06:22:48 -0400 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx with esmtp (Exim 4.12) id 19hRd1-00043F-00 for sipping@ietf.org; Tue, 29 Jul 2003 06:22:47 -0400 Received: by fox.iptel.org (Postfix, from userid 103) id A577B685; Tue, 29 Jul 2003 12:18:23 +0200 (CEST) Received: from jku07.iptel.org (dial43.cesnet.cz [195.113.150.43]) by fox.iptel.org (Postfix) with ESMTP id 06401688; Tue, 29 Jul 2003 12:18:17 +0200 (CEST) Message-Id: <5.2.0.9.0.20030729113614.00b5db90@localhost> X-Sender: jiri@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 29 Jul 2003 12:13:49 +0200 To: Paul Kyzivat From: Jiri Kuthan Subject: Re: [Sipping] Update to 3pcc Cc: Jonathan Rosenberg , sipping In-Reply-To: <3F256140.7070906@cisco.com> References: <5.2.0.9.0.20030728101717.00ba8370@localhost> 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 07:45 PM 7/28/2003, Paul Kyzivat wrote: >Jiri, > >REFER is tempting as an alternative to a b2bua for click-to-dial, but I suspect there are practical difficulties to its use. Paul, I'm glad you raised the practicability issue -- you may want to learn that REFER-based click-to-dial works even with your company's SIP phones. Feel free to subscribe to iptel.org, use web-based phonebook and watch SIP signaling. The phonebook uses REFER for c-t-d. Running code available at our site. That's it. The essential argument however is arhictectural. REFER c-t-d doesn't take a "middlebox" b2bua whose use has severe architectural limitations, see me previous email. More replies to your comments follow inline -- I think most of confusion comes from lack of distinction between user interface and protocol aspects. Thanks, -Jiri > The details may vary depending on how you imagine using it. > >The simplest approach is presumably to have the click-to-dial server simply send a REFER to one party, refering them to the other party. Issues with this: > >- the referred endpoint probably needs to alert its user and await an answer before ending the invite. Such behavior isn't standardized, and its likely that many/most UAs don't do this. Well, that's been IETF way of doing things -- product features are not standardized, protocols are. REFER protocol specification explicitly legalizes out-of-dialog use and there are more uses coming for it (conferencing, for example). Device's policy for dealing with such requests is a product feature. Alerting a user seems like a perfectly reasonable user-interface design choice but again: that's out of scope of protocol specification. I agree phones accepting out-of-dialog REFERs are hard to find if there are any at all. That's very likely to change as the apps come in. We use in the meantime a hack: our CTD wraps the REFER in a dummy call with no media. (I don't want to make advertising to brave SIP phone companies but let me name at least few examples which are known to work: cisco, mitel, pingtel, grandstream). >- in cases where billing is involved, somebody is going to be billed for the call. It isn't clear how you can build a click-to-dial server so that the "right" thing happens, whatever that is. I don't understand this sentence -- perhaps you want to explain what "right thing" means and what the compelling problem is. >- in general, authorization for such a REFER isn't likely to be granted to just anybody. While it may be possible to set up a specific arrangement for this between the click-to-dial server and the referee, that would require some propriatary work. Like above: product features are out-of-scope. My user-interface preference is it is all very much like processing of unsolicited incoming calls. A telephone may prompt its user if an INVITE or REFER or perhaps even FOOBAR comes in. It may alert, flesh, open up a window, vibrate, yell, whatsoever. Other telephones may accept any or no REFERs but I wouldn't buy such. >I suppose another way to handle this would be to have the click-to-dial server send an invite to the referee, either medialess or with media black-holed. Then it could send a refer within that dialog. This would resolve the alerting issue, and transform the other issues into familiar ones having to do with transfer. Issues with this: Yes, that's what we do now. I think it is rather a temporary hack for now, but I like it still better than B2BUA. (Temporary hack with long-term plan over misconcepted architecture.) >- afaik billing and authorization issues for refer aren't fully solved. I can't comment as I don't know what the billing and authorization issues are. >- if this approach is done with black hole media then it has the same problems you were hoping to avoid. That's true but as said, the INVITE wrapper is imho a temporary hack. >I think the b2bua approach to click-to-dial has the best chance of working. This is more likely if 0.0.0.0 is used as the black-hole address. It is less likely if .invalid is used as the black-hole address. Hard-to-agree: running code for refer-based ctd is outthere and it does not suffer from b2bua's architectural shortcomings. -- > Paul > >Jiri Kuthan wrote: >>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 From exim@www1.ietf.org Tue Jul 29 10:42: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 KAA25121 for ; Tue, 29 Jul 2003 10:42: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 19hVfy-0005D8-PM for sipping-archive@odin.ietf.org; Tue, 29 Jul 2003 10:42:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TEg6ZF020027 for sipping-archive@odin.ietf.org; Tue, 29 Jul 2003 10:42:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hVfy-0005Cw-Kv for sipping-web-archive@optimus.ietf.org; Tue, 29 Jul 2003 10:42: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 KAA25113 for ; Tue, 29 Jul 2003 10:42:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hVfw-00069w-00 for sipping-web-archive@ietf.org; Tue, 29 Jul 2003 10:42:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hVfv-00069t-00 for sipping-web-archive@ietf.org; Tue, 29 Jul 2003 10:42:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hVfs-0005C3-Vx; Tue, 29 Jul 2003 10:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hVfP-0005Be-6u for sipping@optimus.ietf.org; Tue, 29 Jul 2003 10:41: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 KAA25105 for ; Tue, 29 Jul 2003 10:41:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hVfM-00069f-00 for sipping@ietf.org; Tue, 29 Jul 2003 10:41:28 -0400 Received: from rainier.illuminet.com ([12.41.110.52]) by ietf-mx with esmtp (Exim 4.12) id 19hVfM-00069X-00 for sipping@ietf.org; Tue, 29 Jul 2003 10:41:28 -0400 Received: from oly1wnexc02.corp.illuminet.com (oly1wnexc02.corp.illuminet.com [10.55.13.13]) by rainier.illuminet.com (8.8.8/8.8.8) with ESMTP id HAA14498; Tue, 29 Jul 2003 07:39:12 -0700 (PDT) Received: by oly1wnexc02.corp.illuminet.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jul 2003 07:39:12 -0700 Message-ID: <318266A4431BC549B4C4D6FD3EA6E24D012CE69E@ove1wnexm01.corp.illuminet.com> From: "McCandless, Kevin" To: "'Liess, Laura'" , hgs@cs.columbia.edu, sipping@ietf.org, aboba@internaut.com Cc: "Dumler, Alexander" , "Wolff, Christian" Subject: RE: [Sipping] FYI: RADIUS & SIP Date: Tue, 29 Jul 2003 07:39:08 -0700 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: , 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 From exim@www1.ietf.org Tue Jul 29 11: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 LAA26617 for ; Tue, 29 Jul 2003 11: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 19hWYB-0007KG-2t for sipping-archive@odin.ietf.org; Tue, 29 Jul 2003 11:38:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TFc77B028154 for sipping-archive@odin.ietf.org; Tue, 29 Jul 2003 11:38:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hWYA-0007K1-Vw for sipping-web-archive@optimus.ietf.org; Tue, 29 Jul 2003 11:38: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 LAA26609 for ; Tue, 29 Jul 2003 11:38:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hWY9-0006d1-00 for sipping-web-archive@ietf.org; Tue, 29 Jul 2003 11:38:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hWY9-0006cy-00 for sipping-web-archive@ietf.org; Tue, 29 Jul 2003 11:38:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hWY5-0007Ix-UG; Tue, 29 Jul 2003 11:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hWXY-0007CS-S7 for sipping@optimus.ietf.org; Tue, 29 Jul 2003 11:37: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 LAA26571 for ; Tue, 29 Jul 2003 11:37:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hWXX-0006cs-00 for sipping@ietf.org; Tue, 29 Jul 2003 11:37:27 -0400 Received: from pmesmtp02.wcom.com ([199.249.20.2]) by ietf-mx with esmtp (Exim 4.12) id 19hWXX-0006cN-00 for sipping@ietf.org; Tue, 29 Jul 2003 11:37:27 -0400 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HIS006KFLT9F2@firewall.wcom.com> for sipping@ietf.org; Tue, 29 Jul 2003 15:31:57 +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 <0HIS00701LKVMD@pmismtp02.wcomnet.com>; Tue, 29 Jul 2003 15:31:57 +0000 (GMT) Received: from hsinnreich2 ([166.50.122.155]) by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HIS006PFLSLCV@pmismtp02.wcomnet.com>; Tue, 29 Jul 2003 15:31:38 +0000 (GMT) Date: Tue, 29 Jul 2003 10:31:33 -0500 From: Henry Sinnreich Subject: RE: AW: [Sipping] FYI: RADIUS & SIP In-reply-to: To: "'Bernard Aboba'" , "'Henry Sinnreich'" Cc: hgs@cs.columbia.edu, sipping@ietf.org, "'Dumler, Alexander'" , "'Liess, Laura'" , "'Wolff, Christian'" Message-id: <0HIS006PNLSOCV@pmismtp02.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: AcNVljigO8gbHOfES9qkQDxk1OyW1wATfuXw 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 > Is this sufficient or is something else needed too? 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 complaints? Thanks, Henry > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Tuesday, July 29, 2003 12:29 AM > To: Henry Sinnreich > Cc: hgs@cs.columbia.edu; sipping@ietf.org; 'Dumler, > Alexander'; 'Liess, Laura'; 'Wolff, Christian' > Subject: RE: AW: [Sipping] FYI: RADIUS & SIP > > > 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 Tue Jul 29 13:34: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 NAA01892 for ; Tue, 29 Jul 2003 13:34: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 19hYMR-00048x-Id for sipping-archive@odin.ietf.org; Tue, 29 Jul 2003 13:34:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6THY7Pq015926 for sipping-archive@odin.ietf.org; Tue, 29 Jul 2003 13:34:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hYMR-00048n-Fq for sipping-web-archive@optimus.ietf.org; Tue, 29 Jul 2003 13:34: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 NAA01864 for ; Tue, 29 Jul 2003 13:34:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hYMP-0000Hq-00 for sipping-web-archive@ietf.org; Tue, 29 Jul 2003 13:34:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hYMO-0000Hn-00 for sipping-web-archive@ietf.org; Tue, 29 Jul 2003 13:34:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hYMK-00047p-IX; Tue, 29 Jul 2003 13:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hYLV-00042E-1r for sipping@optimus.ietf.org; Tue, 29 Jul 2003 13:33: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 NAA01822 for ; Tue, 29 Jul 2003 13:33:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hYLS-0000Gu-00 for sipping@ietf.org; Tue, 29 Jul 2003 13:33:07 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19hYLS-0000GX-00 for sipping@ietf.org; Tue, 29 Jul 2003 13:33:06 -0400 Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6THWX6Y003334; Tue, 29 Jul 2003 13:32:33 -0400 (EDT) Message-ID: <3F26AFAF.2000202@dynamicsoft.com> Date: Tue, 29 Jul 2003 13:32:31 -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@ietf.org'" References: <9BF66EBF6BEFD942915B4D4D45C051F3E8624D@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E8624D@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: Comment on GRUU requirements Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Two points to make here: First, I am not sure that we actually want to place the GRUU in the contact header field. If we do that, we end up with double record routing and the elimination of end-to-end signaling once the call is set up. What I mean by double record-routing is this. Lets say A calls B. B's proxy record-routes. The INVITE gets to B. B inserts a GRUU in the Contact in the 200 OK. Now, when A does a re-INVITE, it goes to B's proxy (due to the record-route), and then AGAIN to a proxy (possibly a different one) because of the GRUU in the r-uri. I think we need to think of a GRUU as an AOR, its just that its an AOR that routes to a specific device instance. Contact header field should be used as its currently used - the URI to reach this device within the context of this dialog. Secondly, that said, I do agree we need to hand out GRUUs. I don't think its a URI parameter. I think that it would be contextual. We definitely need to be able to hand them out between peers in a dialog, in which case a new header could be used to carry them. They could also be embedded in web pages, in which case the context is the surrounding anchor text, meant for human consumption. To facilitate further discussion, I've written up a brief requirements document on GRUU. I added some requrements to distribute GRUUs between peers in a dialog. Until it appears in the archives, you can pick it up at: http://www.jdrosen.net/papers/draft-ietf-sipping-gruu-reqs-00.txt http://www.jdrosen.net/papers/draft-ietf-sipping-gruu-reqs-00.html Thanks, Jonathan R. Adam Roach wrote: > While thinking about some of the applications for which > GRUUs would be useful, it occurred to me that many of > them work (or at least, work better) if a GRUU can be > identified as such by simple examination. > > For example, let's say I send an INVITE message and > receive a 200 response containing: > > Contact: > > If I want to be able to send an out-of-dialog request that > I want to go to the same device that my INVITE went to, > I don't know whether I can do so. On the other hand, if > I can look for a URI parameter that indicates that the > URI has GRUU properties: > > Contact: > > ...then I *know* that sending a request to it will arrive > at the appropriate device, even if it's not in the same > dialog. > > I would like to see a requirement added along the lines > of: > > REQ xx: It must be possible for any recipient of a URI > to determine by examination whether it is a GRUU. > > /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 Tue Jul 29 13:54: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 NAA02433 for ; Tue, 29 Jul 2003 13:54: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 19hYfn-0005ER-B1 for sipping-archive@odin.ietf.org; Tue, 29 Jul 2003 13:54:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6THs7X2020105 for sipping-archive@odin.ietf.org; Tue, 29 Jul 2003 13:54:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hYfn-0005EC-6W for sipping-web-archive@optimus.ietf.org; Tue, 29 Jul 2003 13:54: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 NAA02417 for ; Tue, 29 Jul 2003 13:54:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hYfk-0000RP-00 for sipping-web-archive@ietf.org; Tue, 29 Jul 2003 13:54:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hYfj-0000RM-00 for sipping-web-archive@ietf.org; Tue, 29 Jul 2003 13:54:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hYfh-0005B1-CW; Tue, 29 Jul 2003 13:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hYen-00053C-JA for sipping@optimus.ietf.org; Tue, 29 Jul 2003 13:53: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 NAA02366 for ; Tue, 29 Jul 2003 13:52:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hYei-0000Qy-00 for sipping@ietf.org; Tue, 29 Jul 2003 13:53:00 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19hYeh-0000Qo-00 for sipping@ietf.org; Tue, 29 Jul 2003 13:52:59 -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 h6THqTSK009054 for ; Tue, 29 Jul 2003 13:52:29 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jul 2003 12:52:29 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E8626E@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Jonathan Rosenberg , Adam Roach Cc: "'sipping@ietf.org'" Date: Tue, 29 Jul 2003 12:52:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] RE: Comment on GRUU requirements Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] writes: > I do agree we need to hand out GRUUs. I don't think its a URI > parameter. I think that it would be contextual. We definitely > need to be able to hand them out between peers in a dialog, > in which case a new header could be used to carry them. That addresses precisely the problem I was trying to solve. /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 Jul 29 14:13:02 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 OAA03407 for ; Tue, 29 Jul 2003 14:13:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hYxh-0006Fm-Bp for sipping-archive@odin.ietf.org; Tue, 29 Jul 2003 14:12:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TICbTT024039 for sipping-archive@odin.ietf.org; Tue, 29 Jul 2003 14:12:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hYxh-0006Fe-2z for sipping-web-archive@optimus.ietf.org; Tue, 29 Jul 2003 14:12: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 OAA03392 for ; Tue, 29 Jul 2003 14:12: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 19hYx8-000675-4x; Tue, 29 Jul 2003 14:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hYwu-00066c-J6 for sipping@optimus.ietf.org; Tue, 29 Jul 2003 14:11:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03384; Tue, 29 Jul 2003 14:11:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hYws-0000gu-00; Tue, 29 Jul 2003 14:11:46 -0400 Received: from gateway.hns.com ([208.236.67.13]) by ietf-mx with esmtp (Exim 4.12) id 19hYwr-0000gr-00; Tue, 29 Jul 2003 14:11:45 -0400 Received: from excore8.hns.com (excore8.hns.com [139.85.52.156]) by gateway.hns.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h6TIBeo5000665; Tue, 29 Jul 2003 14:11:40 -0400 (EDT) Received: from atlas (atlas-179.hns.com [139.85.179.149]) by excore8.hns.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h6TIBWjM007368; Tue, 29 Jul 2003 14:11:34 -0400 (EDT) To: Jonathan Rosenberg Cc: Adam Roach , "'sipping@ietf.org'" , sipping-admin@ietf.org Subject: Re: [Sipping] Re: Comment on GRUU requirements MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Arjun Roychowdhury" Date: Tue, 29 Jul 2003 14:11:31 -0400 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.12 |February 13, 2003) at 07/29/2003 02:09:35 PM, Serialize complete at 07/29/2003 02:09:35 PM 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: , quick questions: 1. Why does the peer need to know a URI is a GRUU or not ? (stated both in Adam's mail below as well as REQ-8 in the draft). If a UA that is handing out its URI wants to be globally reachable, why cannot it just make sure its URI is a GRUU for that dialog or the required scope of life ? 2. In the definition of 'instance-routing' of the draft, it states 'when a call is made to a GRUU, the routing logic is much more static. It has to cause the call to be delivered to a very specific UA instance.' I am confused by the definition of 'much more static'. As of today, given a URI a proxy applies some routing logic. At the least, it would simply forward it based on the incoming URI or it may decide to apply some 'service logic'. If it did apply a service logic, (eg say, CPL) the outgoing URI depends on the script. So, 2.1) Is this GRUU addition going to add another angle to how proxies are supposed to route ? 2.2) Is this GRUU additon going to force proxies not to recognize a 'new type' of URI for which it may need to apply special (maybe limited) routing logic ? In short, my concern is what this addition does for intermediary routers and servers and if at all its possible to push the complexity of all this to the endpoints making the intermediaries unaware of the type of the SIP uri. (GRUU or not). regds arjun -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301 212 7860 Jonathan Rosenberg Sent by: sipping-admin@ietf.org 07/29/2003 01:32 PM To: Adam Roach cc: "'sipping@ietf.org'" Subject: [Sipping] Re: Comment on GRUU requirements Two points to make here: First, I am not sure that we actually want to place the GRUU in the contact header field. If we do that, we end up with double record routing and the elimination of end-to-end signaling once the call is set up. What I mean by double record-routing is this. Lets say A calls B. B's proxy record-routes. The INVITE gets to B. B inserts a GRUU in the Contact in the 200 OK. Now, when A does a re-INVITE, it goes to B's proxy (due to the record-route), and then AGAIN to a proxy (possibly a different one) because of the GRUU in the r-uri. I think we need to think of a GRUU as an AOR, its just that its an AOR that routes to a specific device instance. Contact header field should be used as its currently used - the URI to reach this device within the context of this dialog. Secondly, that said, I do agree we need to hand out GRUUs. I don't think its a URI parameter. I think that it would be contextual. We definitely need to be able to hand them out between peers in a dialog, in which case a new header could be used to carry them. They could also be embedded in web pages, in which case the context is the surrounding anchor text, meant for human consumption. To facilitate further discussion, I've written up a brief requirements document on GRUU. I added some requrements to distribute GRUUs between peers in a dialog. Until it appears in the archives, you can pick it up at: http://www.jdrosen.net/papers/draft-ietf-sipping-gruu-reqs-00.txt http://www.jdrosen.net/papers/draft-ietf-sipping-gruu-reqs-00.html Thanks, Jonathan R. Adam Roach wrote: > While thinking about some of the applications for which > GRUUs would be useful, it occurred to me that many of > them work (or at least, work better) if a GRUU can be > identified as such by simple examination. > > For example, let's say I send an INVITE message and > receive a 200 response containing: > > Contact: > > If I want to be able to send an out-of-dialog request that > I want to go to the same device that my INVITE went to, > I don't know whether I can do so. On the other hand, if > I can look for a URI parameter that indicates that the > URI has GRUU properties: > > Contact: > > ...then I *know* that sending a request to it will arrive > at the appropriate device, even if it's not in the same > dialog. > > I would like to see a requirement added along the lines > of: > > REQ xx: It must be possible for any recipient of a URI > to determine by examination whether it is a GRUU. > > /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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 29 14:14: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 OAA03468 for ; Tue, 29 Jul 2003 14:14: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 19hYz7-0006O5-16 for sipping-archive@odin.ietf.org; Tue, 29 Jul 2003 14:14:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TIE4xr024547 for sipping-archive@odin.ietf.org; Tue, 29 Jul 2003 14: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 19hYz6-0006Nq-T3 for sipping-web-archive@optimus.ietf.org; Tue, 29 Jul 2003 14: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 OAA03445 for ; Tue, 29 Jul 2003 14:13:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hYz4-0000i0-00 for sipping-web-archive@ietf.org; Tue, 29 Jul 2003 14:14:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hYz3-0000hx-00 for sipping-web-archive@ietf.org; Tue, 29 Jul 2003 14:14:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hYz3-0006HV-7h; Tue, 29 Jul 2003 14: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 19hYyg-0006Gd-Qo for sipping@optimus.ietf.org; Tue, 29 Jul 2003 14:13: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 OAA03435 for ; Tue, 29 Jul 2003 14:13:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hYye-0000hj-00 for sipping@ietf.org; Tue, 29 Jul 2003 14:13:36 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19hYyd-0000hR-00 for sipping@ietf.org; Tue, 29 Jul 2003 14:13:35 -0400 Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6TICt6Y003358; Tue, 29 Jul 2003 14:12:56 -0400 (EDT) Message-ID: <3F26B925.1010306@dynamicsoft.com> Date: Tue, 29 Jul 2003 14:12:53 -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: "Liess, Laura" , hgs@cs.columbia.edu, sipping@ietf.org, "Dumler, Alexander" , "Wolff, Christian" Subject: Re: AW: [Sipping] FYI: RADIUS & SIP References: <43240544763FB8479F1529372F6197CF053CC8CD@G8PQC.blf01.telekom.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 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 From exim@www1.ietf.org Tue Jul 29 14:29: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 OAA03884 for ; Tue, 29 Jul 2003 14:29: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 19hZDf-00070V-Cp for sipping-archive@odin.ietf.org; Tue, 29 Jul 2003 14:29:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TIT7K6026934 for sipping-archive@odin.ietf.org; Tue, 29 Jul 2003 14:29:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hZDf-00070L-A2 for sipping-web-archive@optimus.ietf.org; Tue, 29 Jul 2003 14:29: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 OAA03865 for ; Tue, 29 Jul 2003 14:29:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hZDc-0000o8-00 for sipping-web-archive@ietf.org; Tue, 29 Jul 2003 14:29:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hZDc-0000o5-00 for sipping-web-archive@ietf.org; Tue, 29 Jul 2003 14:29:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hZDZ-0006zS-6l; Tue, 29 Jul 2003 14: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 19hZD6-0006xc-6X for sipping@optimus.ietf.org; Tue, 29 Jul 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 OAA03824 for ; Tue, 29 Jul 2003 14:28:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hZD3-0000nm-00 for sipping@ietf.org; Tue, 29 Jul 2003 14:28:29 -0400 Received: from pmesmtp01.wcom.com ([199.249.20.1]) by ietf-mx with esmtp (Exim 4.12) id 19hZD2-0000nM-00 for sipping@ietf.org; Tue, 29 Jul 2003 14:28:28 -0400 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HIS00L9LTR078@firewall.wcom.com> for sipping@ietf.org; Tue, 29 Jul 2003 18:23:25 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HIS00501TR033@pmismtp01.wcomnet.com>; Tue, 29 Jul 2003 18:23:24 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.128.90]) by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HIS00482TQY9O@pmismtp01.wcomnet.com>; Tue, 29 Jul 2003 18:23:24 +0000 (GMT) Date: Tue, 29 Jul 2003 13:23:02 -0500 From: Alan Johnston Subject: Re: [Sipping] Re: Comment on GRUU requirements In-reply-to: <3F26AFAF.2000202@dynamicsoft.com> X-Sender: Alan.Johnston@pop.mcit.com To: Jonathan Rosenberg , Adam Roach Cc: "'sipping@ietf.org'" Message-id: <5.2.1.1.0.20030729132008.0245a110@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: <" <9BF66EBF6BEFD942915B4D4D45C051F3E8624D"@dyn-tx-exch-001.dynamicsoft.com> <9BF66EBF6BEFD942915B4D4D45C051F3E8624D@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: , At 01:32 PM 7/29/2003 -0400, Jonathan Rosenberg wrote: >Two points to make here: > >First, I am not sure that we actually want to place the GRUU in the >contact header field. If we do that, we end up with double record routing >and the elimination of end-to-end signaling once the call is set up. What >I mean by double record-routing is this. Lets say A calls B. B's proxy >record-routes. The INVITE gets to B. B inserts a GRUU in the Contact in >the 200 OK. Now, when A does a re-INVITE, it goes to B's proxy (due to the >record-route), and then AGAIN to a proxy (possibly a different one) >because of the GRUU in the r-uri. 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. If we are not trying to solve these cases, what cases are we trying to solve here? Thanks, Alan Johnston MCI (snip) >Thanks, >Jonathan R. > >Adam Roach wrote: > >>While thinking about some of the applications for which >>GRUUs would be useful, it occurred to me that many of >>them work (or at least, work better) if a GRUU can be >>identified as such by simple examination. >>For example, let's say I send an INVITE message and >>receive a 200 response containing: >> Contact: >>If I want to be able to send an out-of-dialog request that >>I want to go to the same device that my INVITE went to, >>I don't know whether I can do so. On the other hand, if >>I can look for a URI parameter that indicates that the >>URI has GRUU properties: >> Contact: >>...then I *know* that sending a request to it will arrive >>at the appropriate device, even if it's not in the same >>dialog. >>I would like to see a requirement added along the lines >>of: >> REQ xx: It must be possible for any recipient of a URI >> to determine by examination whether it is a GRUU. >>/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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 29 15: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 PAA05757 for ; Tue, 29 Jul 2003 15: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 19hZuF-0000Ak-QK for sipping-archive@odin.ietf.org; Tue, 29 Jul 2003 15:13:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TJD77d000655 for sipping-archive@odin.ietf.org; Tue, 29 Jul 2003 15:13:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hZuF-0000AU-M0 for sipping-web-archive@optimus.ietf.org; Tue, 29 Jul 2003 15:13: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 PAA05695 for ; Tue, 29 Jul 2003 15:13:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hZuE-00012Q-00 for sipping-web-archive@ietf.org; Tue, 29 Jul 2003 15:13:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hZuD-00012N-00 for sipping-web-archive@ietf.org; Tue, 29 Jul 2003 15: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 19hZu7-00009b-HF; Tue, 29 Jul 2003 15: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 19hZtD-00008p-41 for sipping@optimus.ietf.org; Tue, 29 Jul 2003 15:12: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 PAA05586 for ; Tue, 29 Jul 2003 15:11:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hZtB-00012I-00 for sipping@ietf.org; Tue, 29 Jul 2003 15:12:01 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19hZtB-000128-00 for sipping@ietf.org; Tue, 29 Jul 2003 15:12:01 -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 h6TJBVSK009268 for ; Tue, 29 Jul 2003 15:11:31 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jul 2003 14:11:30 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86271@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'sipping@ietf.org'" Subject: RE: [Sipping] Re: Comment on GRUU requirements Date: Tue, 29 Jul 2003 14:11:22 -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: , Arjun Roychowdhury [mailto:aroychow@hns.com] writes: > 1. Why does the peer need to know a URI is a GRUU or not ? > (stated both in > Adam's mail below as well as REQ-8 in the draft). I believe you need to re-read my earlier mail and Jonathan's draft a bit more closely. The stated reason for needing to do this is so that once I am in a dialog, I can send an out-of- dialog request guaranteed to be received by the same UA that the dialog connects me to. /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 Jul 29 15:37: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 PAA06753 for ; Tue, 29 Jul 2003 15:37: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 19haHZ-0001Hh-RC for sipping-archive@odin.ietf.org; Tue, 29 Jul 2003 15:37:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TJbDPW004931 for sipping-archive@odin.ietf.org; Tue, 29 Jul 2003 15: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 19haHZ-0001HS-GK for sipping-web-archive@optimus.ietf.org; Tue, 29 Jul 2003 15: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 PAA06731 for ; Tue, 29 Jul 2003 15:37:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19haHY-0001Fd-00 for sipping-web-archive@ietf.org; Tue, 29 Jul 2003 15:37:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19haHX-0001Fa-00 for sipping-web-archive@ietf.org; Tue, 29 Jul 2003 15:37:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19haHO-0001G0-1g; Tue, 29 Jul 2003 15: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 19haHH-0001F8-4x for sipping@optimus.ietf.org; Tue, 29 Jul 2003 15:36: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 PAA06725; Tue, 29 Jul 2003 15:36:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19haHD-0001FU-00; Tue, 29 Jul 2003 15:36:51 -0400 Received: from gateway.hns.com ([208.236.67.14]) by ietf-mx with esmtp (Exim 4.12) id 19haHC-0001FF-00; Tue, 29 Jul 2003 15:36:50 -0400 Received: from excore8.hns.com (excore8.hns.com [139.85.52.126]) by gateway.hns.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h6TJaWo5014721; Tue, 29 Jul 2003 15:36:32 -0400 (EDT) Received: from atlas (atlas-179.hns.com [139.85.179.149]) by excore8.hns.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h6TJaQjK026194; Tue, 29 Jul 2003 15:36:26 -0400 (EDT) To: Adam Roach Cc: "'sipping@ietf.org'" , sipping-admin@ietf.org Subject: RE: [Sipping] Re: Comment on GRUU requirements MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Arjun Roychowdhury" Date: Tue, 29 Jul 2003 15:36:23 -0400 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.12 |February 13, 2003) at 07/29/2003 03:34:27 PM, Serialize complete at 07/29/2003 03:34:27 PM 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, I did read that point. Let me re-phrase : If a UA wanted to be globablly reachable, is it enough for it to make sure the URI it advertises is a GRUU as opposed to the sender wanting to know if it really is a GRUU ? Instead of the sender "wanting to make sure that any out-of-band message it sends goes to the same UA that the dialog connects it to' can't the owner of the URI take this decision - ie 'if I want to be reached at the same UA then I would respond , say in Contact, with a GRUU. Its not upto the peer to reach me at my instance, its upto me to allow that if I want' -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301 212 7860 Adam Roach Sent by: sipping-admin@ietf.org 07/29/2003 03:11 PM To: "'sipping@ietf.org'" cc: Subject: RE: [Sipping] Re: Comment on GRUU requirements Arjun Roychowdhury [mailto:aroychow@hns.com] writes: > 1. Why does the peer need to know a URI is a GRUU or not ? > (stated both in > Adam's mail below as well as REQ-8 in the draft). I believe you need to re-read my earlier mail and Jonathan's draft a bit more closely. The stated reason for needing to do this is so that once I am in a dialog, I can send an out-of- dialog request guaranteed to be received by the same UA that the dialog connects me to. /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 Jul 29 17:07: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 RAA09480 for ; Tue, 29 Jul 2003 17:07: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 19hbgf-0005ff-6N for sipping-archive@odin.ietf.org; Tue, 29 Jul 2003 17:07:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TL7Dtr021791 for sipping-archive@odin.ietf.org; Tue, 29 Jul 2003 17:07:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hbgf-0005fO-0o for sipping-web-archive@optimus.ietf.org; Tue, 29 Jul 2003 17: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 RAA09461 for ; Tue, 29 Jul 2003 17:07:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hbgc-0001sV-00 for sipping-web-archive@ietf.org; Tue, 29 Jul 2003 17:07:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hbgc-0001sR-00 for sipping-web-archive@ietf.org; Tue, 29 Jul 2003 17:07:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hbgU-0005bN-0T; Tue, 29 Jul 2003 17:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hbgI-0005ad-7r for sipping@optimus.ietf.org; Tue, 29 Jul 2003 17:06: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 RAA09442 for ; Tue, 29 Jul 2003 17:06:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hbgG-0001s7-00 for sipping@ietf.org; Tue, 29 Jul 2003 17:06:48 -0400 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 19hbgE-0001rq-00 for sipping@ietf.org; Tue, 29 Jul 2003 17:06:47 -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 h6TL66a02324; Tue, 29 Jul 2003 14:06:06 -0700 (PDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jul 2003 14:06:06 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D209EBE7D4@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'John ELWELL (john.elwell@siemenscomms.co.uk)'" , "'sipping@ietf.org'" Cc: "'gonzalo.camarillo@ericsson.com'" , "'dean.willis@softarmor.com'" , "'rohan@cisco.com'" Date: Tue, 29 Jul 2003 14:06:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35615.39E6361A" Subject: [Sipping] 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_01C35615.39E6361A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I had volunteered for the formal review of = draft-ietf-sipping-qsig2sip-01. I have a few technical comments (somewhat minor), and a few editorial comments. Technical --------- - Section 8.3.1, page 19 =20 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=20 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. - 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=20 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=20 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).=20 Paragraphs 3 and 4 shall thus be modified as follows: "...SDP answer=20 information SHOULD be included in the SIP 18x provisional response if the SDP information is available." =20 - Section 8.3.5, page 22, NOTE 3 Remove NOTE 3 since the the INVITE will not necessarily be rejected = (as per the comment on 8.3.1 above). - Section 8.3.6, page 23, NOTE 3 Remove NOTE 3 since the the INVITE will not necessarily be rejected = (as per the comment on 8.3.1 above). Editorial --------- - I belive the Footer should say "Elwell et al." instead of "Elwell et = alia" - A number of Figures are cut on page boundaries. It would be more = readable if they were not cut on page boundary. - Throughout the document, do a "search-and-replace" of=20 - =FB for - - =F6 for " - =F4 for " - Section 8.2.1.3, page 13 For clarity, add the words "in-band" after the words "MAY supply" on = the third line of the first bulleted item. - Section 8.3.1, page 19, in NOTE 2 For clarity, add the words "in-band" after "to ensure that" on the = fifth line. - Section 8.3.6, page 22, Note 1 For clarity, reword to "In this case, SDP answer information is = expected in the SIP ACK, as described in 13.2.1/[10]. - Section 10.1, page 35 Replace =E6audio=C6 with "audio" in 2 locations. Replace .-law with = mu-law. ------_=_NextPart_001_01C35615.39E6361A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable WGLC for draft-ietf-sipping-qsig2sip-01

I had volunteered for the formal review of = draft-ietf-sipping-qsig2sip-01.

I have a few technical comments (somewhat minor), and = a few editorial comments.

Technical
---------

- 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.


- 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."
 

- Section 8.3.5, page 22, NOTE 3

  Remove NOTE 3 since the the INVITE will not = necessarily be rejected (as
  per the comment on 8.3.1 above).


- Section 8.3.6, page 23, NOTE 3

  Remove NOTE 3 since the the INVITE will not = necessarily be rejected (as
  per the comment on 8.3.1 above).



Editorial
---------

- I belive the Footer should say "Elwell et = al." instead of "Elwell et alia"

- A number of Figures are cut on page boundaries. It = would be more readable
  if they were not cut on page boundary.

- Throughout the document, do a = "search-and-replace" of
  - =FB for -
  - =F6 for "
  - =F4 for "

- Section 8.2.1.3, page 13
  For clarity, add the words = "in-band" after the words "MAY supply" on = the
  third line of the first bulleted item.

- Section 8.3.1, page 19, in NOTE 2
  For clarity, add the words = "in-band" after "to ensure that" on the fifth = line.

- Section 8.3.6, page 22, Note 1
  For clarity, reword to "In this case, = SDP answer information is expected in
  the SIP ACK, as described in = 13.2.1/[10].

- Section 10.1, page 35
  Replace =E6audio=C6 with "audio" in = 2 locations. Replace .-law with mu-law.

------_=_NextPart_001_01C35615.39E6361A-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 29 17:42: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 RAA10847 for ; Tue, 29 Jul 2003 17:42: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 19hcEY-0007ra-Kt for sipping-archive@odin.ietf.org; Tue, 29 Jul 2003 17:42:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TLgEVQ030220 for sipping-archive@odin.ietf.org; Tue, 29 Jul 2003 17:42:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hcEY-0007rL-Hf for sipping-web-archive@optimus.ietf.org; Tue, 29 Jul 2003 17:42: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 RAA10802 for ; Tue, 29 Jul 2003 17:42:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hcEW-0002A2-00 for sipping-web-archive@ietf.org; Tue, 29 Jul 2003 17:42:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hcEV-00029z-00 for sipping-web-archive@ietf.org; Tue, 29 Jul 2003 17: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 19hcEL-0007l2-Vl; Tue, 29 Jul 2003 17: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 19hcDt-0007kc-Pz for sipping@optimus.ietf.org; Tue, 29 Jul 2003 17:41: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 RAA10784 for ; Tue, 29 Jul 2003 17:41:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hcDr-00029Y-00 for sipping@ietf.org; Tue, 29 Jul 2003 17:41:31 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19hcDq-00029P-00 for sipping@ietf.org; Tue, 29 Jul 2003 17:41: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 h6TLemSK009818; Tue, 29 Jul 2003 17:40:52 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jul 2003 16:40:48 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86278@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Arjun Roychowdhury'" , Adam Roach Cc: "'sipping@ietf.org'" Subject: RE: [Sipping] Re: Comment on GRUU requirements Date: Tue, 29 Jul 2003 16:40:45 -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, the UA can make a choice as to whether it advertises such a URI. However, the sender of a request frequently needs to know whether an advertised URI has GRUU properties. Many requests would make no sense otherwise. Currently, the only way that SIP allows requestors to ensure this property is by sending the request in an existing dialog. This is why we have the ability, in RFC 3265, to share dialogs between SUBSCRIBE requests and INVITE requests. The problem is that doing so is very awkward, and creates quite a few subtle issues. On the other hand, if we had GRUUs exchanged during call setup, we could forgo this silliness altogether. Admittedly, it's a bit late for SUB/NOT (although I would like to move towards deprecating this behavior at some point), but that doesn't mean that the next time we need this property that we should go down the path of dialog reuse. /a P.S. Copying sipping-admin on these messages is completely pointless, since the chairs undoubtedly subscribe to the mailing list. It is also, I'm certain, annoying for Rohan, Dean, and Gonzalo. > -----Original Message----- > From: Arjun Roychowdhury [mailto:aroychow@hns.com] > Sent: Tuesday, July 29, 2003 14:36 > To: Adam Roach > Cc: 'sipping@ietf.org'; sipping-admin@ietf.org > Subject: RE: [Sipping] Re: Comment on GRUU requirements > > > Yes, I did read that point. > > Let me re-phrase : > > If a UA wanted to be globablly reachable, is it enough for it > to make sure > the URI it advertises is a GRUU as opposed > to the sender wanting to know if it really is a GRUU ? > > Instead of the sender "wanting to make sure that any > out-of-band message > it sends goes to the same UA that the dialog connects it to' > can't the owner of the URI take this decision - ie 'if I want to be > reached at the same UA then I would respond , say in Contact, with > a GRUU. Its not upto the peer to reach me at my instance, its > upto me to > allow that if I want' > > > > > -- > Arjun Roychowdhury @ Hughes Software Systems > 11717 Exploration Lane, Germantown MD 20876 > (O): 301 212 7860 > > > > > Adam Roach > 07/29/2003 03:11 PM > > > To: "'sipping@ietf.org'" > cc: > Subject: RE: [Sipping] Re: Comment on GRUU requirements > > > Arjun Roychowdhury [mailto:aroychow@hns.com] writes: > > > 1. Why does the peer need to know a URI is a GRUU or not ? > > (stated both in > > Adam's mail below as well as REQ-8 in the draft). > > I believe you need to re-read my earlier mail and Jonathan's > draft a bit more closely. The stated reason for needing to do > this is so that once I am in a dialog, I can send an out-of- > dialog request guaranteed to be received by the same UA that > the dialog connects me to. > > /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 Jul 29 18:10: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 SAA12429 for ; Tue, 29 Jul 2003 18:10: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 19hcfA-0001Hl-BW for sipping-archive@odin.ietf.org; Tue, 29 Jul 2003 18:09:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TM9igQ004935 for sipping-archive@odin.ietf.org; Tue, 29 Jul 2003 18:09:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hcfA-0001HW-58 for sipping-web-archive@optimus.ietf.org; Tue, 29 Jul 2003 18:09: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 SAA12355 for ; Tue, 29 Jul 2003 18:09:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hcf7-0002Pc-00 for sipping-web-archive@ietf.org; Tue, 29 Jul 2003 18:09:41 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hcf6-0002PZ-00 for sipping-web-archive@ietf.org; Tue, 29 Jul 2003 18:09:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hceT-00018p-GG; Tue, 29 Jul 2003 18: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 19hcdi-00017h-Cn for sipping@optimus.ietf.org; Tue, 29 Jul 2003 18:08: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 SAA12200 for ; Tue, 29 Jul 2003 18:08:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hcdf-0002P9-00 for sipping@ietf.org; Tue, 29 Jul 2003 18:08:11 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19hcde-0002OY-00 for sipping@ietf.org; Tue, 29 Jul 2003 18:08:11 -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 h6TM7dSK009861; Tue, 29 Jul 2003 18:07:40 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jul 2003 17:07:38 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E8627A@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Alan Johnston'" , Jonathan Rosenberg , Adam Roach Cc: "'sipping@ietf.org'" Subject: RE: [Sipping] Re: Comment on GRUU requirements Date: Tue, 29 Jul 2003 17:07:32 -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: , 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? I have to admit that the property that all requests in a dialog are required to go through my GRUU server just because I happen to support GRUUs seems a bit intrusive. /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 Jul 29 19:23: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 TAA15026 for ; Tue, 29 Jul 2003 19:23: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 19hdoD-0004hw-U3 for sipping-archive@odin.ietf.org; Tue, 29 Jul 2003 19:23:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TNN9hp018090 for sipping-archive@odin.ietf.org; Tue, 29 Jul 2003 19:23:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdoD-0004hh-Qw for sipping-web-archive@optimus.ietf.org; Tue, 29 Jul 2003 19:23: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 TAA15020 for ; Tue, 29 Jul 2003 19:23:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hdoC-0002sY-00 for sipping-web-archive@ietf.org; Tue, 29 Jul 2003 19:23:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hdoB-0002sV-00 for sipping-web-archive@ietf.org; Tue, 29 Jul 2003 19:23:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdo5-0004gm-T6; Tue, 29 Jul 2003 19: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 19hdns-0004gS-FR for sipping@optimus.ietf.org; Tue, 29 Jul 2003 19:22:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15013 for ; Tue, 29 Jul 2003 19:22:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hdnq-0002sN-00 for sipping@ietf.org; Tue, 29 Jul 2003 19:22:47 -0400 Received: from gateway.hns.com ([208.236.67.13]) by ietf-mx with esmtp (Exim 4.12) id 19hdnq-0002sK-00 for sipping@ietf.org; Tue, 29 Jul 2003 19:22:46 -0400 Received: from excore8.hns.com (excore8.hns.com [139.85.52.126]) by gateway.hns.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h6TNMco5016280; Tue, 29 Jul 2003 19:22:39 -0400 (EDT) Received: from atlas (atlas.hns.com [139.85.177.110]) by excore8.hns.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h6TNMVjK009284; Tue, 29 Jul 2003 19:22:32 -0400 (EDT) To: Adam Roach Cc: Adam Roach , "'sipping@ietf.org'" Subject: RE: [Sipping] Re: Comment on GRUU requirements MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Arjun Roychowdhury" Date: Tue, 29 Jul 2003 19:22:28 -0400 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.12 |February 13, 2003) at 07/29/2003 07:20:33 PM, Serialize complete at 07/29/2003 07:20:33 PM Content-Type: text/plain; charset="us-ascii" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , On the other hand, if we had GRUUs exchanged during call setup, we could forgo this silliness altogether. Admittedly, it's a bit late for SUB/NOT (although I would like to move towards deprecating this behavior at some point), but that doesn't mean that the next time we need this property that we should go down the path of dialog reuse. ARC> Valid point. I would like to hear about how (if at all) the GRUUs affect routing policies at the proxy (my first set of Qs). P.S. Copying sipping-admin on these messages is completely pointless, since the chairs undoubtedly subscribe to the mailing list. It is also, I'm certain, annoying for Rohan, Dean, and Gonzalo. ARC> Well, pointless or not, I dont insert 'sipping-admin' because I love that ID. It seems if you hit a reply-all with history for a mail that has a 'Sender:sipping-admin@xxx' (the case when the mail reflector sends the mail out), lotus notes inserts that id into the cc list. I wonder if the sender: field can be modified to have the list it to avoid this problem. -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301 212 7860 > -----Original Message----- > From: Arjun Roychowdhury [mailto:aroychow@hns.com] > Sent: Tuesday, July 29, 2003 14:36 > To: Adam Roach > Cc: 'sipping@ietf.org'; sipping-admin@ietf.org > Subject: RE: [Sipping] Re: Comment on GRUU requirements > > > Yes, I did read that point. > > Let me re-phrase : > > If a UA wanted to be globablly reachable, is it enough for it > to make sure > the URI it advertises is a GRUU as opposed > to the sender wanting to know if it really is a GRUU ? > > Instead of the sender "wanting to make sure that any > out-of-band message > it sends goes to the same UA that the dialog connects it to' > can't the owner of the URI take this decision - ie 'if I want to be > reached at the same UA then I would respond , say in Contact, with > a GRUU. Its not upto the peer to reach me at my instance, its > upto me to > allow that if I want' > > > > > -- > Arjun Roychowdhury @ Hughes Software Systems > 11717 Exploration Lane, Germantown MD 20876 > (O): 301 212 7860 > > > > > Adam Roach > 07/29/2003 03:11 PM > > > To: "'sipping@ietf.org'" > cc: > Subject: RE: [Sipping] Re: Comment on GRUU requirements > > > Arjun Roychowdhury [mailto:aroychow@hns.com] writes: > > > 1. Why does the peer need to know a URI is a GRUU or not ? > > (stated both in > > Adam's mail below as well as REQ-8 in the draft). > > I believe you need to re-read my earlier mail and Jonathan's > draft a bit more closely. The stated reason for needing to do > this is so that once I am in a dialog, I can send an out-of- > dialog request guaranteed to be received by the same UA that > the dialog connects me to. > > /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 Wed Jul 30 04:12: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 EAA23447 for ; Wed, 30 Jul 2003 04:12: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 19hm4A-00088c-FA for sipping-archive@odin.ietf.org; Wed, 30 Jul 2003 04:12:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6U8CAPX031278 for sipping-archive@odin.ietf.org; Wed, 30 Jul 2003 04: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 19hm4A-00088P-4p for sipping-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 04: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 EAA23402 for ; Wed, 30 Jul 2003 04:12:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hm46-0005uS-00 for sipping-web-archive@ietf.org; Wed, 30 Jul 2003 04:12:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hm45-0005uP-00 for sipping-web-archive@ietf.org; Wed, 30 Jul 2003 04:12:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hm41-00087S-CB; Wed, 30 Jul 2003 04: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 19hm3T-00086X-9V for sipping@optimus.ietf.org; Wed, 30 Jul 2003 04:11: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 EAA23383 for ; Wed, 30 Jul 2003 04:11:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hm3P-0005ty-00 for sipping@ietf.org; Wed, 30 Jul 2003 04:11:23 -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 19hm3O-0005to-00 for sipping@ietf.org; Wed, 30 Jul 2003 04:11:23 -0400 Received: by n171-18.deltathree.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jul 2003 11:10:52 +0300 Message-ID: From: David Schwartz To: "'sipping@ietf.org'" Date: Wed, 30 Jul 2003 11:10:45 +0300 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [Sipping] Re: Update to 3pcc Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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 From exim@www1.ietf.org Wed Jul 30 04:29: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 EAA23749 for ; Wed, 30 Jul 2003 04:29: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 19hmKa-000093-H7 for sipping-archive@odin.ietf.org; Wed, 30 Jul 2003 04:29:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6U8T8eu000552 for sipping-archive@odin.ietf.org; Wed, 30 Jul 2003 04:29:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hmKZ-00008p-Ay for sipping-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 04:29: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 EAA23725 for ; Wed, 30 Jul 2003 04:29:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hmKV-0005zH-00 for sipping-web-archive@ietf.org; Wed, 30 Jul 2003 04:29:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hmKV-0005zE-00 for sipping-web-archive@ietf.org; Wed, 30 Jul 2003 04:29:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hmKV-00007v-Rs; Wed, 30 Jul 2003 04:29:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hmJU-00005I-Ly for sipping@optimus.ietf.org; Wed, 30 Jul 2003 04:28: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 EAA23721 for ; Wed, 30 Jul 2003 04:27:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hmJQ-0005zA-00 for sipping@ietf.org; Wed, 30 Jul 2003 04:27:56 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 19hmJP-0005z7-00 for sipping@ietf.org; Wed, 30 Jul 2003 04:27:55 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id h6U8RvC10615 for ; Wed, 30 Jul 2003 10:27:57 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id h6U8RuG00996 for ; Wed, 30 Jul 2003 10:27:56 +0200 (MEST) Received: from mchh273e.demchh201e.icn.siemens.de (mchh273e.mchh.siemens.de [139.21.200.83]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id KAA27598 for ; Wed, 30 Jul 2003 10:27:56 +0200 (MET DST) Received: by mchh273e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Wed, 30 Jul 2003 10:27:19 +0200 Message-ID: <5B788FC2CAFBD6118BAE0030848B025C416E3D@LNN201E> From: Marjou Xavier To: "'sipping@ietf.org'" Date: Wed, 30 Jul 2003 10:27:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Sipping] New status for conference package ? Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 draft-ietf-sipping-conference-package-01 indicates 4 statuses concerning the status user in the conference: active, departed, booted, and failed. Suppose a user-A invites (via a focus) a group made of user-B and user-C. If user-B immediatly accepts the call, while user-B takes time to answer, it would be nice to be able to update SIP terminals of user-A and user-B with the information that user-C is beeing invited. Why not define a new "pending" status for it ? Xavier _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 30 11: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 LAA04573 for ; Wed, 30 Jul 2003 11: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 19hshO-0004Bn-Ls for sipping-archive@odin.ietf.org; Wed, 30 Jul 2003 11:17:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UFH6ET016099 for sipping-archive@odin.ietf.org; Wed, 30 Jul 2003 11:17:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hshO-0004Ba-Ih for sipping-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 11:17: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 LAA04544 for ; Wed, 30 Jul 2003 11:17:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hshN-00010F-00 for sipping-web-archive@ietf.org; Wed, 30 Jul 2003 11:17:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hshN-00010C-00 for sipping-web-archive@ietf.org; Wed, 30 Jul 2003 11: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 19hshJ-00048M-FC; Wed, 30 Jul 2003 11: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 19hsgl-00046P-As for sipping@optimus.ietf.org; Wed, 30 Jul 2003 11:16: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 LAA04482 for ; Wed, 30 Jul 2003 11:15:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hsfo-0000ze-00 for sipping@ietf.org; Wed, 30 Jul 2003 11:15:28 -0400 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by ietf-mx with esmtp (Exim 4.12) id 19hsfn-0000yv-00 for sipping@ietf.org; Wed, 30 Jul 2003 11:15:27 -0400 Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HIU006EZFFK2A@firewall.wcom.com> for sipping@ietf.org; Wed, 30 Jul 2003 15:09:20 +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 <0HIU00M01FD36V@dgismtp02.wcomnet.com>; Wed, 30 Jul 2003 15:09:20 +0000 (GMT) Received: from hsinnreich2 ([166.50.96.166]) by dgismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HIU00KGHFF7LM@dgismtp02.wcomnet.com>; Wed, 30 Jul 2003 15:09:09 +0000 (GMT) Date: Wed, 30 Jul 2003 10:09:05 -0500 From: Henry Sinnreich Subject: RE: [Sipping] Re: Update to 3pcc In-reply-to: To: "'David Schwartz'" , sipping@ietf.org Message-id: <0HIU00KGIFF7LM@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: AcNWcm/kv2QEe/R3SJmYEhJlnVuWpwAN8xcw 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 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 From exim@www1.ietf.org Wed Jul 30 11:50: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 LAA05706 for ; Wed, 30 Jul 2003 11:50: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 19htDO-0005UZ-D0 for sipping-archive@odin.ietf.org; Wed, 30 Jul 2003 11:50:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UFoAK9021110 for sipping-archive@odin.ietf.org; Wed, 30 Jul 2003 11:50:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htDO-0005UP-6y for sipping-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 11: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 LAA05695 for ; Wed, 30 Jul 2003 11:50:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19htDN-0001FO-00 for sipping-web-archive@ietf.org; Wed, 30 Jul 2003 11:50:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19htDM-0001FL-00 for sipping-web-archive@ietf.org; Wed, 30 Jul 2003 11:50:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htDF-0005TU-Fh; Wed, 30 Jul 2003 11: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 19htCW-0005Si-0G for sipping@optimus.ietf.org; Wed, 30 Jul 2003 11: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 LAA05637 for ; Wed, 30 Jul 2003 11:49:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19htCU-0001FF-00 for sipping@ietf.org; Wed, 30 Jul 2003 11:49:14 -0400 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by ietf-mx with esmtp (Exim 4.12) id 19htCT-0001EX-00 for sipping@ietf.org; Wed, 30 Jul 2003 11:49:14 -0400 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HIU0035SGYBHO@firewall.wcom.com> for sipping@ietf.org; Wed, 30 Jul 2003 15:42:12 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HIU00J01GSXB7@pmismtp01.wcomnet.com>; Wed, 30 Jul 2003 15:42:11 +0000 (GMT) Received: from hsinnreich2 ([166.35.136.95]) by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HIU00J0ZGWUQZ@pmismtp01.wcomnet.com>; Wed, 30 Jul 2003 15:41:20 +0000 (GMT) Date: Wed, 30 Jul 2003 10:41:18 -0500 From: Henry Sinnreich Subject: RE: [Sipping] Re: Update to 3pcc - corrected In-reply-to: To: "'David Schwartz'" , sipping@ietf.org Message-id: <0HIU00J10GWUQZ@pmismtp01.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: AcNWcm/kv2QEe/R3SJmYEhJlnVuWpwAN8xcw 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 (Correction, sorry )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 collection alternatives: CDRs in the gateways. If the calls are between two IP endpoints, flat rate is a good option. The centralized controller is a soulmate of the B2BUA, and both have some tremendous drawbacks compared to REFER: - breaks the e2e trust model and security, such as S/MIME. How many B2BUAs would one have to trust in an interdomain call? - 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? I add the above to Jiri's and Jonathan's comments. I will take REFER any time instead. (Am actually not sure which is more evil, the central controler AKA 'softswitch' or the B2BUA) 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 From exim@www1.ietf.org Wed Jul 30 12:09: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 MAA06535 for ; Wed, 30 Jul 2003 12:09: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 19htVi-00071y-My for sipping-archive@odin.ietf.org; Wed, 30 Jul 2003 12:09:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UG96Q8027020 for sipping-archive@odin.ietf.org; Wed, 30 Jul 2003 12: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 19htVi-00071j-K1 for sipping-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 12:09: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 MAA06507 for ; Wed, 30 Jul 2003 12:09:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19htVh-0001QJ-00 for sipping-web-archive@ietf.org; Wed, 30 Jul 2003 12:09:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19htVg-0001QG-00 for sipping-web-archive@ietf.org; Wed, 30 Jul 2003 12:09:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htVe-00070q-3e; Wed, 30 Jul 2003 12:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htV3-0006y0-S2 for sipping@optimus.ietf.org; Wed, 30 Jul 2003 12: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 MAA06481 for ; Wed, 30 Jul 2003 12:08:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19htV2-0001QC-00 for sipping@ietf.org; Wed, 30 Jul 2003 12:08:24 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19htV1-0001Pq-00 for sipping@ietf.org; Wed, 30 Jul 2003 12:08:23 -0400 Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6UG7k6Y004013; Wed, 30 Jul 2003 12:07:46 -0400 (EDT) Message-ID: <3F27ED50.1040207@dynamicsoft.com> Date: Wed, 30 Jul 2003 12:07:44 -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: Volker Hilt CC: sipping References: <3F25962A.4030103@bell-labs.com> In-Reply-To: <3F25962A.4030103@bell-labs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: Static and dynamic policies requirement Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 Yes, I think it makes sense. To back this up a little, we have applications that clearly require dynamic policies, and ones where static is far preferable. For policies where the information doesn't change, dynamic policies are expensive - causing continuous transmission of the information during call setup, and possible adding to call setup latencies. Take, for example, whether or not to use a media intermediary. In many cases, the desire for this is constant. For example, where an enterprise has a NAT which needs to be traversed. In that case, it can be done with a static policy. This policy would inform the UA of the TURN relay its supposed to contact in advance of the call. In other cases, its dynamic. For example, in a roaming scenario, whether a local relay is used or not varies on a call by call basis depending where the user is. ALso, if there are multiple operators on the call path, and each has a policy for a media relay (though I think this is an awful thing to do in general), thats not known till the call is made. So, for the case of media relays, we have cases where static is what we want, and where dynamic is what we want. One of the issues I had been struggling with for a bit was the apparent overlap between ICE/TURN and session policy (assuming dynamic only, which is how the current document is structured). Both seemed to be ways for media to flow through an intermediary. The difference is exactly static vs. dynamic. WHen static policies are used, the user is informed about the relay (i.e., TURN server) through provisioning. When dynamic policies are used, the user is informed about the relay through the dynamic session policy mechanism. In this case TURN isn't needed to provision the relay; the proxy does it directly (though I suppose session policy could give out a turn relay address - need to think about that). Allowed codecs are another example where a static session policy is probably better, since the information is not likely to change on a call by call basis. So, the question then, is what additional requirements do we have for supporting static policies? I would say: * The mechanism must provide the ability to inform the UA about the set of session policies when the device starts up * The mechanism must allow the provider to change the static policies at least a few times a day * The mechanism must allow the static policies to vary on a user by user basis * The mechanism must provide a way to inform the client about changes in session policies when they occur An interesting question is what we mean by "provider". Is this the home provider (i.e., owner of the namespace in which the UAs AOR resides) or visiting one or both? -Jonathan R. Volker Hilt wrote: > Jonathan, > > would it make sense to include requirements for the support of static > and dynamic policies in the policy requirements draft? These > requirements could look like the following: > > REQ-POL-14: The solution should allow the specification of dynamic > policies on a call-by-call basis. > > REQ-POL-15: The solution should allow the specification of static > policies, which are applicable to certain calls for a given time. > > Thanks, > > Volker > -- 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 Jul 30 12:15: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 MAA06752 for ; Wed, 30 Jul 2003 12:15: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 19htbV-0007JQ-53 for sipping-archive@odin.ietf.org; Wed, 30 Jul 2003 12:15:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UGF58S028102 for sipping-archive@odin.ietf.org; Wed, 30 Jul 2003 12:15:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htbV-0007JB-1m for sipping-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 12:15: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 MAA06735 for ; Wed, 30 Jul 2003 12:14:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19htbT-0001Sn-00 for sipping-web-archive@ietf.org; Wed, 30 Jul 2003 12:15:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19htbS-0001Sk-00 for sipping-web-archive@ietf.org; Wed, 30 Jul 2003 12: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 19htbQ-0007Hz-OP; Wed, 30 Jul 2003 12:15:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htak-0007D8-4W for sipping@optimus.ietf.org; Wed, 30 Jul 2003 12:14: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 MAA06647 for ; Wed, 30 Jul 2003 12:14:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19htai-0001Rt-00 for sipping@ietf.org; Wed, 30 Jul 2003 12:14:16 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19htah-0001Ri-00 for sipping@ietf.org; Wed, 30 Jul 2003 12:14:16 -0400 Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6UGDi6Y004020; Wed, 30 Jul 2003 12:13:44 -0400 (EDT) Message-ID: <3F27EEB5.80506@dynamicsoft.com> Date: Wed, 30 Jul 2003 12:13:41 -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: "'Alan Johnston'" , "'sipping@ietf.org'" Subject: Re: [Sipping] Re: Comment on GRUU requirements References: <9BF66EBF6BEFD942915B4D4D45C051F3E8627A@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E8627A@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: > 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. 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. -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 Jul 30 12:24: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 MAA07061 for ; Wed, 30 Jul 2003 12:24: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 19htkI-0007jA-HZ for sipping-archive@odin.ietf.org; Wed, 30 Jul 2003 12:24:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UGOA16029698 for sipping-archive@odin.ietf.org; Wed, 30 Jul 2003 12:24:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htkI-0007iv-EE for sipping-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 12:24: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 MAA07022 for ; Wed, 30 Jul 2003 12:24:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19htkG-0001Y4-00 for sipping-web-archive@ietf.org; Wed, 30 Jul 2003 12:24:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19htkG-0001Y1-00 for sipping-web-archive@ietf.org; Wed, 30 Jul 2003 12:24:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htk9-0007hv-7E; Wed, 30 Jul 2003 12: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 19htjD-0007hN-Gl for sipping@optimus.ietf.org; Wed, 30 Jul 2003 12:23: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 MAA07005 for ; Wed, 30 Jul 2003 12:22:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19htjC-0001Xn-00 for sipping@ietf.org; Wed, 30 Jul 2003 12:23:02 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19htjB-0001XY-00 for sipping@ietf.org; Wed, 30 Jul 2003 12:23:01 -0400 Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6UGMM6Y004026; Wed, 30 Jul 2003 12:22:23 -0400 (EDT) Message-ID: <3F27F0BC.4000107@dynamicsoft.com> Date: Wed, 30 Jul 2003 12:22:20 -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: Arjun Roychowdhury CC: Adam Roach , "'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 inline. Arjun Roychowdhury wrote: > quick questions: > > 1. Why does the peer need to know a URI is a GRUU or not ? (stated both in > Adam's mail below as well as REQ-8 in the draft). > If a UA that is handing out its URI wants to be globally reachable, why > cannot it just make sure its URI is a GRUU for that dialog or > the required scope of life ? I think Adam has addressed this, but let me give my take. When a peer wants to send a request to a UA out of a dialog, it needs to know what URI to use. Does it use the Contact header from the peer? To/From? Well, it should use the GRUU wherever it gets put, and if there is not a gruu, it needs to use one of the tricks that Alan has documented in his transfer draft. So, the processing at the peer needs to make a decision on the approach based on whether it has a GRUU or not, and thus it needs to know. > > 2. In the definition of 'instance-routing' of the draft, it states > 'when a call is made to a GRUU, the routing logic is much more static. It > has to cause the call to be delivered to a very specific UA instance.' Yes. > > I am confused by the definition of 'much more static'. As of today, given > a URI a proxy applies some routing logic. At the least, > it would simply forward it based on the incoming URI or it may decide to > apply some 'service logic'. If it did apply a service logic, > (eg say, CPL) the outgoing URI depends on the script. So, > > 2.1) Is this GRUU addition going to add another angle to how > proxies are supposed to route ? No. Its merely a subset of whats already possible today. You can already have a URI that is globally routable and routes to a specific next hop URI that represents a device. > 2.2) Is this GRUU additon going to force proxies not to recognize > a 'new type' of URI for which it may need to apply special > (maybe limited) routing logic ? No. Its just another URI. It just so happens that the services associated with it are not as broad as they may be with some other URIs. But, the services that can be attached to it are just a subset of a what a proxy already does. Generally speaking, proxies need to understand what services need to be offered to URIs under their administratiev domain. Not all services can be randomly applied to all URIs. Policy and authorization will dicate which URIs can have which services. For example, if a user has not paid for call forwarding, they may not be allowed to have a call forwarding script/service associated with their AOR. A GRUU is no different. Its a URI in that domain associated with a subset of the overall services. > > In short, my concern is what this addition does for intermediary routers > and servers and if at all its possible to push the complexity > of all this to the endpoints making the intermediaries unaware of the type > of the SIP uri. (GRUU or not). No, thats bad. The proxies NEED to know. That is the entire premise behind the leasing approach. They need to know since otherwise routing is unreliable. They need to know since you may WANT to have services associated with GRUUs (i.e., applying call blocking services to GRUUs as 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 Jul 30 12:37: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 MAA07553 for ; Wed, 30 Jul 2003 12:37: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 19htwm-0008RU-Gm for sipping-archive@odin.ietf.org; Wed, 30 Jul 2003 12:37:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UGb4dx032450 for sipping-archive@odin.ietf.org; Wed, 30 Jul 2003 12:37:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htwm-0008RJ-Cs for sipping-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 12:37: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 MAA07538 for ; Wed, 30 Jul 2003 12:36:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19htwk-0001fL-00 for sipping-web-archive@ietf.org; Wed, 30 Jul 2003 12:37:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19htwk-0001fI-00 for sipping-web-archive@ietf.org; Wed, 30 Jul 2003 12:37:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htwj-0008Pt-IM; Wed, 30 Jul 2003 12: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 19htwF-0008Nf-Nm for sipping@optimus.ietf.org; Wed, 30 Jul 2003 12: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 MAA07517 for ; Wed, 30 Jul 2003 12:36:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19htwE-0001er-00 for sipping@ietf.org; Wed, 30 Jul 2003 12:36:30 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19htwD-0001eo-00 for sipping@ietf.org; Wed, 30 Jul 2003 12:36:29 -0400 Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6UGZx6Y004033; Wed, 30 Jul 2003 12:35:59 -0400 (EDT) Message-ID: <3F27F3EC.4060907@dynamicsoft.com> Date: Wed, 30 Jul 2003 12:35:56 -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: Marjou Xavier CC: "'sipping@ietf.org'" Subject: Re: [Sipping] New status for conference package ? References: <5B788FC2CAFBD6118BAE0030848B025C416E3D@LNN201E> In-Reply-To: <5B788FC2CAFBD6118BAE0030848B025C416E3D@LNN201E> 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 Marjou Xavier wrote: > The draft-ietf-sipping-conference-package-01 indicates 4 statuses > concerning the status user in the conference: active, departed, > booted, and failed. > > Suppose a user-A invites (via a focus) a group made of user-B and > user-C. If user-B immediatly accepts the call, while user-B takes > time to answer, I think you mean user-C takes time to answer. > it would be nice to be able to update SIP terminals > of user-A and user-B with the information that user-C is beeing > invited. Why not define a new "pending" status for it ? Right now, "active" would cover that. The text says active means that the DIALOG is active. That occurs the moment a non-100 1xx comes from the invited user - i.e., while they are ringing. However, I agree this doesnt make sense. We already have dialog information attached, from which you can get dialog status. What we need here is conferencing application status. I think what you are looking for is a status like "attempting to add". A user could be in this state even if there is not a SIP call attempt in progress. For example, the server policy might be to periodically (say, every 5m) call the user if the previous attempt failed. Throughout this potentially long period of attempts, the status would be "attempting to add". This is probably different still from the case where a user dials in, but the moderator needs to approve them to join the conference. Here, their sip dialog is active, but they are connected to a music on hold source. However, the conference state is "awaiting moderator approval". So, unless there are objections, I'll: * change active to refer to participation, not dialog state * add "attempting to add" and "awaiting moderator approval" as additional states. 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 Wed Jul 30 12:58:23 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 MAA08071 for ; Wed, 30 Jul 2003 12:58:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huH0-0000xe-Il for sipping-archive@odin.ietf.org; Wed, 30 Jul 2003 12:57:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UGvwo5003690 for sipping-archive@odin.ietf.org; Wed, 30 Jul 2003 12:57:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huH0-0000xQ-DX for sipping-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 12: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 MAA08049 for ; Wed, 30 Jul 2003 12:57:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19huG9-0001lp-00 for sipping-web-archive@ietf.org; Wed, 30 Jul 2003 12:57:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19huG8-0001lm-00 for sipping-web-archive@ietf.org; Wed, 30 Jul 2003 12:57:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huG6-0000oh-3c; Wed, 30 Jul 2003 12: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 19huFO-0000mA-EA for sipping@optimus.ietf.org; Wed, 30 Jul 2003 12:56: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 MAA08016 for ; Wed, 30 Jul 2003 12:56:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19huFM-0001lD-00 for sipping@ietf.org; Wed, 30 Jul 2003 12:56:16 -0400 Received: from smtp-05.inode.at ([62.99.194.7] helo=smtp.inode.at) by ietf-mx with esmtp (Exim 4.12) id 19huFL-0001lA-00 for sipping@ietf.org; Wed, 30 Jul 2003 12:56:15 -0400 Received: from ap1.stiwoll.mah.priv.at ([62.99.233.53]:29367 helo=mah9.eunet.at) by smtp.inode.at with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.10) id 19huFC-0000Me-00; Wed, 30 Jul 2003 18:56:06 +0200 Message-Id: <5.2.0.9.2.20030730002949.043edc48@mail.inode.at> X-Sender: mah#inode.at@mail.inode.at (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 30 Jul 2003 18:55:02 +0200 To: Jonathan Rosenberg , Bernard Aboba From: Michael Haberler 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: multipart/mixed; x-avg-checked=avg-ok-717A6E0D; boundary="=======51A719FE=======" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --=======51A719FE======= Content-Type: text/plain; x-avg-checked=avg-ok-717A6E0D; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit 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 > --=======51A719FE=======-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 30 16:22: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 QAA16489 for ; Wed, 30 Jul 2003 16:22: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 19hxSh-0002Ta-0S for sipping-archive@odin.ietf.org; Wed, 30 Jul 2003 16:22:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UKMEvc009518 for sipping-archive@odin.ietf.org; Wed, 30 Jul 2003 16:22:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hxSg-0002TR-On for sipping-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 16:22: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 QAA16484 for ; Wed, 30 Jul 2003 16:22:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hxSe-0003Hm-00 for sipping-web-archive@ietf.org; Wed, 30 Jul 2003 16:22:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hxSe-0003Hj-00 for sipping-web-archive@ietf.org; Wed, 30 Jul 2003 16:22:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hxST-0002SY-J4; Wed, 30 Jul 2003 16: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 19hxRa-0002SC-EB for sipping@optimus.ietf.org; Wed, 30 Jul 2003 16:21: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 QAA16467 for ; Wed, 30 Jul 2003 16:21:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hxRY-0003HU-00 for sipping@ietf.org; Wed, 30 Jul 2003 16:21:04 -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 19hxRX-0003Gs-00 for sipping@ietf.org; Wed, 30 Jul 2003 16:21:03 -0400 Received: from txdwillis (bdsl.66.12.12.254.gte.net [66.12.12.254]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6UKKIJn002161 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 30 Jul 2003 15:20:19 -0500 From: "Dean Willis" To: Cc: , Date: Wed, 30 Jul 2003 15:20:08 -0500 Message-ID: <005001c356d7$f92c4010$ee036e3f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: quoted-printable Subject: [Sipping] Draft Minutes for SIPPING WG Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 Draft minutes are posted at: http://www.softarmor.com/sipping/meets/ietf57/notes/minutes-sipping-ietf5= 7.h tml Please pay special attention to the "Action Items" section at the end. Please report any errors or omissions to me ASAP. Text version follows: ------------------------------------------------------ Draft Minutes, SIPPING WG, IETF 57 Notes by Tom Taylor, AC Mahendran, and Hisham Khartabil Minutes edited by Dean Willis Chat room moderation by Brian Rosen Meetings chaired by Gonzalo Camarillo, Rohan Mahy, Dean Willis Session 1, July 14, 2003 1930-2200 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Topic: Agenda --------------------- Agenda accepted as previously posted. Topic: Announcements and Status ---------------------------------- Chairs mention the SIP device reqts ad hoc 10-11 am Thur room J241/1, = and that the QoS promotion scheme draft will be discussed in Friday's TSVWG meeting. Slides presented reviewing status of working group documents. pres-chairs-SIPPING-WG-status-ietf-57.ppt Topic: SIP to QSIG Mapping ------------------------------ Relevant document: draft-ietf-sipping-qsig2sip Slides presented pres-elwell-qsig2sip-ietf-57.ppt Discussion led by John Elwell Issue: We need more qualified reviewers for this work. A hand-poll taken = in the room indicated about a dozen people claiming to be familar with = QSIG. We discussed possibly working with external SDOs on this. Discussion indicated that ECMA is the likely SDO. John Elwell took the action item = of providing a list of ECMA contacts to Allison Mankin. No conclusion. Actions: Francois Audet to formally review document. Topic: Dialog Package ----------------------- Relevant document: draft-ietf-sipping-dialog-package Slides presented: pres-rosenberg-dialog-pkg-ietf-57.ppt Discussion led by Jonathan Rosenberg Status: Went through WGLC. Minor comments incorporated. Unable to = restrict a particular XML type in XML -- has only the accompanying text to = provide the constraint. Issue: extensions proposed (Sean Olson). Question: what to do with = them? Extend scope of main package, reject them, or document them separately? Issue: "on hold". Not clear what "on hold" means, since media can flow anyway. Suggestion that this isn't a dialog state. Conclusion: Rough consensus that we are not ready to advance the dialog package at the present time. Concerned parties instructed to discuss = and report back to Thursday mtg. Topic: Discussion of Configuration Issues ------------------------------------------ Relevant documents: draft-ietf-sipping-config-framework draft-ietf-sipping-ua-prof-framewk-reqs draft-ietf-simple-xcap-package Slides presented: pres-petrie-config-fw-issues-ietf-57.ppt pres-mahy-config-issues-ietf-57.ppt Some open issues w/ profiles. No discussion. No conclusion on = framrework or profiles. Issue: potential conflict between XCAP package (SIMPLE work item) and sip-config. XCAP fits into framework: config retrieval, change notif, = config upload. Differences in many details. Do they share the same = requirements? Do they share the same solution? Should they be unified? Proposal to unify led to comment that config is a much more general = problem -- it may not be reasonable to use SIP for notifications in view of a = more general model coming perhaps out of netconf. This may reflect the views = of a number of people in the IETF at large. We will need to have a clear explanation of scope. Key point: all of the entities involved have SIP addrs. Fairly tightly scoped. Proposal: merge or reorg the two drafts. Need an author w/more cycles. Poll indicated rough consensus in favour, with some hums opposed. Locus = of work to be discussed w/ ADs, noting two different areas are involved. Conclusion: Chairs to discuss with ADs. Topic: Session Policy and Middle Box Issues ---------------------------------------------- Relevant Document: draft-ietf-sipping-session-policy-req-00.txt Discussion led by Jonathan Rosenberg Issue: Dynamic vs static policies -- Allison: not necessarily either/or -- Jonathan just concerned to eliminate unnecessary reqts -- CALEA an arg against dynamic policies Rohan volunteers to work on mechanism if he has some help. Questions on reqt for enforcement of policy. Audience asked to review = text and submit desired changes. No conclusion. Editors note: 3GPP is expecting some results here. Topic: URI Leasing and GRUUS ---------------------------------- Relevant document: draft-rosenberg-sipping-lease-00.txt An informal group met prior to this meeting. They noted that embedded = route headers prevent proxy application of policy and user services, and that leasing has a couple of other advantages. This groups conclusion is = that leasing seems to be the way to go. There appear to be some open issues = wrt GRUU grants. The author will add requirement that leasing be stateless = to the requirements doc. Conclusion: Agreed that requirements shall address stateless leasing. Consensus that work will continue with leasing model at this time. Topic: Firewall and NAT Traversal ------------------------------------ Relevant Document: draft-rosenberg-sipping-ice-00.txt Slides presented in: pres-rosenberg-sipping-nat-stuff-ietf-57.ppt Status report ice-01 addresses concerns raised in IETF 56 -- backward compatibility --- case that breaks bkwd compatibility is multihomed host. alt = framework vs. alt attribute being taken into off-line discussion ice-01 has ~50 pages of example flows -- proposed replacement of sipping-nat-scenarios -- ice algorithm works out -- troublesome case is v4-v6 -- need add call flow between ice and non-ice hosts Question from chair: if Jonathan adds the required cases, is this a sufficient replacement for what we have now in the sipping-nat-scenarios document? Consensus is that it is adequate, provided that we add text to allow alternate approaches (such as ALG, MIDCOM) and add cases for MSRP relay. Francois Audet volunteered to send text relating to alternate approaches. Process open issues: 1. Do we proceed, and if so, in which WG? -- main ice behaviour -- mmusic? -- SDP extensions -- mmusic -- preconditions -- if people care, would go to sip (poss mmusic) -- usage scenarios -- repl sipping-nat-scenarios -- sipping Conclusion: Hums indicated a consensus to do core ICE behavior and SDP changes in MMUSIC, usage scenarios in SIPPING, and preconditions work in = SIP if needed. Chairs are to discuss division of work with ADs. Topic: Adding Realm Identifier for Private Addresses ------------------------------------------------------ Relevant Document: draft-audet-sipping-add-realm-00.txt Slides presented in: pres-audet-sipping-add-realm-ietf-57.ppt Notes: Adds explicit realm identifier for private (i.e. "local") = addresses into SDP. Useful in case both endpoints have a priori knowledge that = they are in the same realm -- can avoid ICE. Need to configure realm only if multiple media terminations behind the same NAT which will communicate with each other. Proposes SDP attribute. Configuration mech out of scope of current = draft. Discussion on network toplogy and applicability indicated that some additional clarity is needed. How does this relate to phone-context? Conclusion: Requires further list dicussion. Burden of proof is on = Francois to say it is worth varying from general application of ICE. Topic: Open Issues from Conferencing Design Team ----------------------------------------------------- Relevant documents: draft-ietf-sipping-conferencing-framework draft-ietf-sipping-cc-conferencing SIP draft-ietf-sipping-conferencing-requirements Slides presented in: pres-levin-conf team-update-ietf-57.ppt Discussion led by Orit Levin Status: Conceptual issues resolved: basic conf by SIP, adv would use = XCON (they hope). Design team work is almost complete and they welcome = general comments. If XCON forms a working group, it may be possible to reduce = the scope of draft-ietf-sipping-conferencing-requirements to "just the SIP requirements."=20 Open issues with draft-ietf-sipping-conferencing-requirements: Focus discovery. Open issues with draft-ietf-sipping-cc-conferncing: add details for = selected msgs in presented call flows, or move into sip draft for mechanisms. Open issues with draft-ietf-sipping-conference-package: Needs another = rev e.g. re sidebar conversations Looking to future draft on implementation = of sidebar Topic: Open Issues from Transcoding/Deaf Design Team --------------------------------------------------------- Relevant Document: draft-camarillo-sip-deaf-02.txt Slides presented in: pres-camarillo-transcoding-emergency.ppt Discussion led by Gonzalo Camarillo. Status: Resuming design team meetings. Transcoding has dependencies = which may be isolated in a separate draft. No conclusion. Topic: Report from Energency Calling Design Team ---------------------------------------------------- Slides presented in: pres-camarillo-transcoding-emergency.ppt Discussion led by Gonzalo Camarillo Status: Scenarios doc to appear within a couple of weeks. Topic: Requirements for SIP Service Configuration --------------------------------------------------- Note: This has some bearing on 3GPP's use of SIP. Proposal: Extend config framework to include service info. Open issue: Which server to contact for data manipulation (XCAP)? Open issue: Download conference-factory URI for automatic conf creation No conclusion. Session 2, Thursday, July 17, 2003, 1300-1500 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Topic: Agenda and Status ---------------------------------- Review requested for new digest-AKA draft. Topic: Open Issues from Application Interaction Design Team --------------------------------------------------------------- Relevant Documents: draft-rosenberg-sipping-app-interaction-framework-00 draft-jennings-sip-app-info-01 draft-burger-sipping-kpml-02 Slides presented in: pres-rosenberg-sipping-day2-ietf-57.ppt Discussion led by Jonathan Rosenberg Issues: KPML DTMF reporting problem . INFO ( Cannot work within call dialog) . NOTIFY w implicit subscription . Explicit subscription from application . HTTP . New method? . MESSAGE Design team reluctantly chose MESSAGE! Proposal: . Continue to hammer out the open issue . Adopt the framework and KPML as SIPPING items. Conclusions: a) Hum on "This is interesting work and that we should adopt the = framework" - Accepted. b) Hum on "All who believe KPML should be accepted as WI" - accepted. c) Chairs will ask the AD to adopt framework and KPML as WG items. d) The KPML reporting issue will be discussed more on the mailing list. =20 Topic: Early Media ------------------- Relevant document: draft-camarillo-sipping-early-media-02.txt Discussion led by Gonzalo Camarillo Status:=20 Changes since last rev include clarifying which features are specific to early media and which ones to SIP and other editorial changes. To be done: Align application server model section with app design team No conclusions. Topic: Conveying Tones in SIP ------------------------------- Relevant document: draft-mahy-sipping-tones-00.txt Discussion led by Rohan Mahy Issue: How to provide tones? Options discussed include =20 1) In RTP a. Speech codec - poor choice b. Using audio/tone AVT payload c. Using audio/telephone-event AVT payload =20 2) Referenced externally by URI with Alert-info or message/external 3) In a SIP header (proposed back in Nov 2000) 4) In the session description 5) In SIP body a. Use Content-Disposition: Render If in a body, What body types are available? 1) Traditional a. Wav, au, mp3 2) Audio/tone 3) Audio/tone-info+xml 4) Many more. 5) XML based: Audio/tone-info+xml Discussions: -Use of midi was suggested by Henning. Conclusions: The issue on tones will be discussed more on the list. Topic: Network Announcements --------------------------------- Relevant document: draft-burger-sipping-netann-06 Discussion led by Eric Burger. Open Issues: 1) Early media: Punt. No definitions for early media Makes 487/409 problem go away. 2) Media on hold Punt. Local matter 3) Multiple media streams Punt. Netann is about objects not streams Only composite objects for multimedia 4) VoiceXML keyword without value Generate 404 with explanation. Poll taken for adoption as a working group item indicated little = support. However, the work is not seen as being in opposition to chartered work. Conclusions: The draft will be submitted for publication as an = individual contribution. Topic: Event Filtering and Throttling ------------------------------------ Relevant document: draft-niemi-sipping-event-throttle-reqs-01.txt Slides presnted in: pres-niemi-event-throttle-ietf-57.ppt pres-niemi-sipping-ietf57-throttles-17072003.ppt Discussion led by Aki Niemi =20 Changes: 1) Updated model. A throttle defines minimum time period between two notifications 2) Updated use cases 3) Refined requirements 4) Aligned language with model Open issues: 1) Should use cases be more elaborate? Proposal: No 2) Are Requirements are solid enough? Seem to be. 3) Is scope for work well defined? Seem to be. Discussions: - It was suggested that it would be worth noting in the draft about = the type of buffering needed (like LIFO, FIFO etc) Conclusion: Chairs will recommended to the ADs to adopt this draft as = WG item. Topic: DPNSS to SIP Interworking ------------------------------------ Relevant document: draft-mukundan-sipping-dpnss-02.txt Slides presented in: pres-mukundan-sipping-dpnss-ietf-57.ppt =20 Discussion led by Ranjith Mukundan Difference between DPNSS MIME and QSIG/ISUP MIME 1) Similar to RFC 3204 (MIME for ISUP/QSIG 2) Mandates single binary coded octet message length field 3) Specifies message buffering option 4) Mandates single DPNSS call per SIP dialog Discussions: - Henning indicated that this doesn't work with the MIME model. - Some were skeptical about the usefulness of doing this work. - There was a feeling that the group did not have enough expertise to = take on this work. - Gonzallo indicated that solving the MIME type is reasonable but the translation work is a tough thing to do. Conclusions: This will NOT be taken as WG item and it will proceed as an individual contribution. Topic: Discussion of End-to-Middle Security --------------------------------------------- Relevant document: draft-ono-sipping-end-middle-security-00.txt Slides presented in: pres-ono-end2middle-ietf-57.ppt Discussion led by Kumiko Ono Issues:=20 1) End-to-end encryption may conflict with some features provided by intermediaries 2 )Use cases: a. Logging services (IM logging, other logging) b. Hotspot service c. Connecting to home SIP server via partially trusted proxy 3) Session-policy 4) Transcoding Proposed Mechanism: . Allows a UA to disclose data to selected intermediaries . End-to-middle encryption uses S/MIME CMS Enveloped data for intermediaries. Discussions: - People felt that this is a very interesting WI. - Jonathan R said that we need to add more use cases to explain the problem of addressing data for intermediaries by user-agent. Conclusions: 1) There was consensus in the room that work has enough interest in = the group. 2) There was consensus that the requirements on end-to-middle & middle-to-end security should to be taken on as WG item. Topic: Phone-related Status and Presence ------------------------------------------ Relevant document: draft-rosenberg-peterson-simple-pidf-phone Slides presented in: pres-rosenberg-sipping-day2-ietf-57.ppt Discussion led by Jonathan Rosenberg Discussions: -Difference between human presence vs device presence. - Rohan said that states like dialing/ringing etc are not applicable to device or user; these are particular to a call/dialog. Some of the raw = data is useful, but presence may not be right place for it. - Henning: Information like line-state etc are not too useful as = presence information. Conclusions: a) Hum on "Dealing with presence issues of phone" as useful work = indicated a consensus.. b) Jonathan proposed to develop more use cases for the draft. c) Is this a SIMPLE or SIPPING activity? Chairs to discuss with SIMPLE chairs. Topic: Session Diagnostics in SIP ---------------------------------- Relevant document: draft-johnston-sipping-rtcp-summary-00.txt Slides presented in: pres-johnston-sipping-rtcp-summary-ietf57.ppt Discussion led by Alan Johnston =20 Summary: 1) Delivery of RTCP summary reports to third parties a. Logging is main motivation 2) Three alternatives a. Forking RTCP to multiple locations b. Carrying in SIP header in BYE c. Event package (preferred) Discussions: 1) Should RTCP be transferred to third parties? 2) What is the purpose of this? If this is for fault management or performance management, this is not needed. SNMP management tools should = be sufficient. 3) How does this compare to RMON? Conclusions: This will be deferred to this to the list. Alan is asked to investigate RMON work and provide some comparison here. ACTION ITEMS ------------------- 1) John Elwell volunteered to provide a list of ECMA contacts for QSIG = to SIP work o Allison Mankin. 2) Chairs to discuss netconf and XCAP reconciliation proposals with ADs. 3) Francois Audet volunteered to review the qsig2sip document and = respons on-list. 4) Francois Audet volunteered to send text relating to alternate = approaches such as ALG and MIDCOM for the ICE usage scenarios document. 5) Chairs to discuss moving some ICE work into MMUSIC and SIP with ADs. 6) Chairs to discuss adding draft-rosenberg-sipping-app-interaction-framework-00 and draft-burger-sipping-kpml-02 as WG items with ADs. 7) Chairs to work withs AD to add charter item(s) for end-to-middle and middle-to-end security requirements. 8) SIPPING chairs to discuss phone-presence with SIMPLE chairs and ADs = to dtermine where thiswork belongs. 9) Alan Johnston was asked to consider how RMON work relates to proposed RTCP summary work and report to the mailing list. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 30 18:04: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 SAA20298 for ; Wed, 30 Jul 2003 18:04: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 19hz3F-0007PA-NU for sipping-archive@odin.ietf.org; Wed, 30 Jul 2003 18:04:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UM45Ml028458 for sipping-archive@odin.ietf.org; Wed, 30 Jul 2003 18:04:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hz3F-0007Ov-JF for sipping-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 18:04: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 SAA20219 for ; Wed, 30 Jul 2003 18:03:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hz3C-0004FC-00 for sipping-web-archive@ietf.org; Wed, 30 Jul 2003 18:04:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hz3C-0004F8-00 for sipping-web-archive@ietf.org; Wed, 30 Jul 2003 18:04:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hz3B-0007MZ-Iw; Wed, 30 Jul 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 19hz2J-0007Kr-9p for sipping@optimus.ietf.org; Wed, 30 Jul 2003 18:03: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 SAA20097 for ; Wed, 30 Jul 2003 18:03:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hz1v-0004E8-00 for sipping@ietf.org; Wed, 30 Jul 2003 18:02:43 -0400 Received: from ns1.research.bell-labs.com ([204.178.16.6] helo=dirty.research.bell-labs.com) by ietf-mx with esmtp (Exim 4.12) id 19hz1l-0004E2-00 for sipping@ietf.org; Wed, 30 Jul 2003 18:02:33 -0400 Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h6UM2HHa011209; Wed, 30 Jul 2003 18:02:17 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h6UM2A1u092334; Wed, 30 Jul 2003 18:02:11 -0400 (EDT) Received: from bell-labs.com (volker-hopc [135.180.240.186]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h6UM2Ah2019513; Wed, 30 Jul 2003 18:02:10 -0400 (EDT) Message-ID: <3F284015.5000604@bell-labs.com> Date: Wed, 30 Jul 2003 18:00:53 -0400 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sipping Subject: Re: [Sipping] Re: Static and dynamic policies requirement References: <3F25962A.4030103@bell-labs.com> <3F27ED50.1040207@dynamicsoft.com> In-Reply-To: <3F27ED50.1040207@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: > Take, for example, whether or not to use a media intermediary. In many > cases, the desire for this is constant. For example, where an enterprise > has a NAT which needs to be traversed. In that case, it can be done with > a static policy. This policy would inform the UA of the TURN relay its > supposed to contact in advance of the call. In other cases, its dynamic. > For example, in a roaming scenario, whether a local relay is used or not > varies on a call by call basis depending where the user is. ALso, if > there are multiple operators on the call path, and each has a policy for > a media relay (though I think this is an awful thing to do in general), > thats not known till the call is made. > Yes, true. > Allowed codecs are another example where a static session policy is > probably better, since the information is not likely to change on a call > by call basis. > An interesting question (admittedly more relevant for a solution than for the requirements) is: how does the UA actually apply static policies? Are these policies worked into the SDP announcement before it is send out, i.e. the SDP announcement contains the changes requested by the policy? Or does the UA create its regular SDP announcement and adds a separate policy object (i.e. an MFO), so that the original announcement and the static policies remain separate? The first option seems makes sense since it is a little simpler and saves a couple of bits. Furthermore, I'm not sure what the benefits of exposing the static policies to proxies along the call path are. However, letting the UA send out the SDP announcement and the policy in separate objects seems to be a more transparent approach. A related issue is: how are the static policies of the UA receiving an SDP offer handled? A simple solution to this would be that the UA just applies its static policies to the SDP answer (or would add a corresponding MFO object to the answer). An interesting issue is that the static policies of the caller and callee are now covered without the need for additional policy negotiation during call set up (assuming that there are no dynamic policies). Only transit networks would not have the chance to specify static policies in this case. > So, the question then, is what additional requirements do we have for > supporting static policies? I would say: > > * The mechanism must provide the ability to inform the UA about the set > of session policies when the device starts up > > * The mechanism must allow the provider to change the static policies at > least a few times a day > > * The mechanism must allow the static policies to vary on a user by user > basis The mechanism should certainly allow a provider to specify different static policies for different (local) users. The policies might for example depend on the services a specific user has subscribed to. Maybe it would also make sense to specify different static policies for different call destinations (i.e. remote users). For example, it would make sense to apply a static policy for NAT traversal only to those calls that actually need to cross the NAT (i.e. are not staying inside the local network). > * The mechanism must provide a way to inform the client about changes in > session policies when they occur I'm not sure if we need this requirement. Static policies could have a timeout after which they need to be renewed. If a static policy is changed, all UAs will learn the new policy at the time they renew their policies. During the transition period, some UAs will use the old policy and some will use the new policy. If this is not acceptable, a proxy can still request the use of new policy via the dynamic mechanism. This of course assumes that dynamic policies can override static policies (which seems to be reasonable in general). > An interesting question is what we mean by "provider". Is this the home > provider (i.e., owner of the namespace in which the UAs AOR resides) or > visiting one or both? > Hmmm, I guess both could have policies that are of interest to the user. The home provider could have policies needed for a certain service (e.g. always route the media stream to the call recording service I have subscribed to) whereas the visiting provider might have policies relevant for the access network (e.g. a restricted set of codecs). -- Volker -- Volker Hilt Bell Labs / Lucent Technologies phone: +1 732 332 6432 101 Crawfords Corner Rd email: volkerh@bell-labs.com Holmdel, NJ 07733 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 31 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 DAA13937 for ; Thu, 31 Jul 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 19i7R0-00009S-8U for sipping-archive@odin.ietf.org; Thu, 31 Jul 2003 03:01:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6V71AcB000576 for sipping-archive@odin.ietf.org; Thu, 31 Jul 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 19i7R0-00009D-3c for sipping-web-archive@optimus.ietf.org; Thu, 31 Jul 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 DAA13927 for ; Thu, 31 Jul 2003 03:01:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i7Qw-0000Dh-00 for sipping-web-archive@ietf.org; Thu, 31 Jul 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 19i7Qv-0000De-00 for sipping-web-archive@ietf.org; Thu, 31 Jul 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 19i7Qs-00008D-U3; Thu, 31 Jul 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 19i7QZ-00007K-Et for sipping@optimus.ietf.org; Thu, 31 Jul 2003 03:00: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 DAA13905 for ; Thu, 31 Jul 2003 03:00:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i7QV-0000DL-00 for sipping@ietf.org; Thu, 31 Jul 2003 03:00:39 -0400 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx with esmtp (Exim 4.12) id 19i7QU-0000D9-00 for sipping@ietf.org; Thu, 31 Jul 2003 03:00:38 -0400 Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP for sipping@ietf.org; Thu, 31 Jul 2003 09:00:08 +0200 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jul 2003 09:00:05 +0200 Message-Id: From: "Beck01, Wolfgang" To: sipping@ietf.org Subject: RE: AW: [Sipping] FYI: RADIUS & SIP Date: Thu, 31 Jul 2003 09:00:03 +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: , > 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 and 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. Having something like SIM cards in SIP phones is a good idea. However, the GSM SIM card security mechanisms are obscure and have been broken. The flaws are not a show stopper for GSM, but I doubt that is a good idea to reuse broken algorithms. > Plus, SIM-based authentication could be used as a bootstrap > mechanism for X.509 certficate distribution and therefore for > TLS mutual authentication. > I support this, but I fear ISIMs will be cheaper as they are already standardized and will be promoted by the UMTS providers. > 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 you mean informational RfC 3310? -- 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 Thu Jul 31 07:09: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 HAA20497 for ; Thu, 31 Jul 2003 07:09: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 19iBIz-0002mN-AW for sipping-archive@odin.ietf.org; Thu, 31 Jul 2003 07:09:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VB99kF010678 for sipping-archive@odin.ietf.org; Thu, 31 Jul 2003 07: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 19iBIz-0002m9-6X for sipping-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 07:09: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 HAA20490 for ; Thu, 31 Jul 2003 07:09:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iBIv-0002Hg-00 for sipping-web-archive@ietf.org; Thu, 31 Jul 2003 07:09:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iBIu-0002Hd-00 for sipping-web-archive@ietf.org; Thu, 31 Jul 2003 07:09:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iBIr-0002lF-IV; Thu, 31 Jul 2003 07: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 19iBHu-0002gT-58 for sipping@optimus.ietf.org; Thu, 31 Jul 2003 07:08: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 HAA20435 for ; Thu, 31 Jul 2003 07:07:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iBHp-0002Gq-00 for sipping@ietf.org; Thu, 31 Jul 2003 07:07:57 -0400 Received: from dakiya.austria.eu.net ([193.154.160.117]) by ietf-mx with esmtp (Exim 4.12) id 19iBHp-0002Gn-00 for sipping@ietf.org; Thu, 31 Jul 2003 07:07:57 -0400 Received: from mah9.eunet.at (A054P024.tele2-dipool.highway.telekom.at [80.121.134.216]) by dakiya.austria.eu.net (Postfix) with ESMTP id 2AFA24E744; Thu, 31 Jul 2003 14:06:48 +0200 (MEST) Message-Id: <5.2.0.9.2.20030731125131.0302c938@mail.inode.at> X-Sender: mah#inode.at@mail.inode.at (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 31 Jul 2003 13:07:56 +0200 To: "Beck01, Wolfgang" , sipping@ietf.org From: Michael Haberler Subject: RE: AW: [Sipping] FYI: RADIUS & SIP In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-712E2E30; boundary="=======20EB272F=======" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --=======20EB272F======= Content-Type: text/plain; x-avg-checked=avg-ok-712E2E30; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable At 09:00 31.07.2003 +0200, Beck01, Wolfgang wrote: > > 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 and 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. > >Having something like SIM cards in SIP phones is a good idea. >However, the GSM SIM card security mechanisms are obscure and The GSM SIM authentication method is plain CHAP, which is not obsure at=20 all, as is the spec. The *sample algorithm* used to compute response and session key in an early= =20 spec (COMP128-1) is indeed "obsure" and has been broken. However, the algorithm is an operator's choice, and many operators have=20 opted to use different algor=EDthms which have *not* been broken. >have been broken. The flaws are not a show stopper for GSM, >but I doubt that is a good idea to reuse broken algorithms. The right of any operator to shoot themselves in the foot is unlimited, but= =20 there's no requirement in the spec to do so. Use any recent algorithm and=20 you're fine, within the limits of single-sided CHAP. > > Plus, SIM-based authentication could be used as a bootstrap > > mechanism for X.509 certficate distribution and therefore for > > TLS mutual authentication. > > >I support this, but I fear ISIMs will be cheaper as they are >already standardized and will be promoted by the UMTS providers. The point isnt about cost of an ISIM vs classic SIM, it is about the=20 authentication centers and billing capabilites of *existing* mobile=20 operators. Existing or second SIM cards =B4could be used for combined= SIP/LAN=20 access authentication say as a second line service. The same sets could be= =20 used as ISP VoIP service terminals. The hardware isnt quite there yet, and= =20 the operators might not understand this fully yet, but the market window is= =20 wide open. Just because somebody invents the ISIM or USIM, that doesnt mean the whole= =20 lot of GSM operators will run out and upgrade to UMTS authentication=20 capabilities. In fact both UMTS operators in Austria have opted to stay=20 with GSM SIM authentication! There goes your ISIM method. The WLAN folks=20 have figured that out and came up with EAP/SIM - because if the would=20 insist to use I/USIMs exlusively they wouldnt sell a single piece of=20 hardware for a loooong time. -Michael Haberler --=======20EB272F=======-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 31 08:47: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 IAA23208 for ; Thu, 31 Jul 2003 08:47: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 19iCpp-0006up-09 for sipping-archive@odin.ietf.org; Thu, 31 Jul 2003 08:47:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VCl816026577 for sipping-archive@odin.ietf.org; Thu, 31 Jul 2003 08:47:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iCpo-0006ua-Sx for sipping-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 08:47: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 IAA23194 for ; Thu, 31 Jul 2003 08:47:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iCpn-0003FG-00 for sipping-web-archive@ietf.org; Thu, 31 Jul 2003 08:47:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iCpm-0003FD-00 for sipping-web-archive@ietf.org; Thu, 31 Jul 2003 08: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 19iCph-0006tf-H0; Thu, 31 Jul 2003 08: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 19iCp0-0006ss-5z for sipping@optimus.ietf.org; Thu, 31 Jul 2003 08: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 IAA23174 for ; Thu, 31 Jul 2003 08:46:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iCoy-0003Eg-00 for sipping@ietf.org; Thu, 31 Jul 2003 08:46:16 -0400 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx with esmtp (Exim 4.12) id 19iCox-0003E4-00 for sipping@ietf.org; Thu, 31 Jul 2003 08:46:16 -0400 Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP for sipping@ietf.org; Thu, 31 Jul 2003 14:45:35 +0200 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jul 2003 14:45:35 +0200 Message-Id: From: "Beck01, Wolfgang" To: sipping@ietf.org Subject: RE: AW: [Sipping] FYI: RADIUS & SIP Date: Thu, 31 Jul 2003 14:45:33 +0200 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 > The *sample algorithm* used to compute response and session key in > an early spec (COMP128-1) is indeed "obsure" and has been broken. >=20 > However, the algorithm is an operator's choice, and many operators > have opted to use different algor=EDthms which have *not* been = broken. Thanks for the clarification. Coming back to the original question, a RADIUS server would have to support several challenge/response schemes: - CHAP (available in today's RADIUS servers, but not in today's SIP = phones) - HTTP Digest (Sterman draft, available in some RADIUS servers and most = SIP phones) - the GSM SIM A3 algorithm du jour - 3GPP ISIM AKA if the provider does not have an alternative GSM authentication infrastructure. > > > Plus, SIM-based authentication could be used as a bootstrap > > > mechanism for X.509 certficate distribution and therefore for > > > TLS mutual authentication. > > > > >I support this, but I fear ISIMs will be cheaper as they are > >already standardized and will be promoted by the UMTS providers. >=20 > [...]There goes your ISIM method. I did not compare SIM with ISIM AKA, but ISIM with smartcards holding = x509 certificates. This thread was about the question how existing RADIUS infrastructures = can be extended to support SIP. Your proposal is about the question how SIP should be extended to be able to reuse a existing GSM authentication infrastructures. This is reasonable for a mobile operator but not for = an ISP. However, using smart cards (SIM, ISIM, Cryptoflex etc) makes sense for = ISPs, too. It's easier to tell the customer: "insert this card here" instead = of saying: "go to menu x, item y and enter a password longer than 5 = characters with at least 2 numerics, don't choose your aunt's surname and change = it every 8 weeks ...". Interoperability with existing GSM is in this case = not as important as it is for mobile operators. -- 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 Thu Jul 31 09:59:47 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 JAA26103 for ; Thu, 31 Jul 2003 09:59: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 19iDxi-0001Dk-2I for sipping-archive@odin.ietf.org; Thu, 31 Jul 2003 09:59:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VDxMFt004688 for sipping-archive@odin.ietf.org; Thu, 31 Jul 2003 09:59:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iDxh-0001DX-Vi for sipping-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 09:59: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 JAA26085 for ; Thu, 31 Jul 2003 09:59:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iDxf-0003ys-00 for sipping-web-archive@ietf.org; Thu, 31 Jul 2003 09:59:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iDxf-0003yp-00 for sipping-web-archive@ietf.org; Thu, 31 Jul 2003 09:59:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iDxM-000188-Ti; Thu, 31 Jul 2003 09:59:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iDx2-00017j-RE for sipping@optimus.ietf.org; Thu, 31 Jul 2003 09:58:40 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26027; Thu, 31 Jul 2003 09:58:35 -0400 (EDT) Message-Id: <200307311358.JAA26027@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 31 Jul 2003 09:58:35 -0400 Subject: [Sipping] I-D ACTION:draft-rosenberg-sipping-gruu-reqs-00.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Construction and Usage of Globally Routable User Agent (UA) URIs for the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-rosenberg-sipping-gruu-reqs-00.txt Pages : 10 Date : 2003-7-31 Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI which can be used by anyone on the Internet to route a call to that specific UA instance. A URI which routes to a specific UA instance is called a Globally Routable UA URI (GRUU). This document presents some motivating use cases for GRUUs, and presents some requirements for their construction and usage. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-gruu-reqs-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rosenberg-sipping-gruu-reqs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rosenberg-sipping-gruu-reqs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-31101337.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosenberg-sipping-gruu-reqs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosenberg-sipping-gruu-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-31101337.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 Thu Jul 31 10:06: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 KAA26629 for ; Thu, 31 Jul 2003 10:06: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 19iE4M-0001Vy-U5 for sipping-archive@odin.ietf.org; Thu, 31 Jul 2003 10:06:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VE6E4P005816 for sipping-archive@odin.ietf.org; Thu, 31 Jul 2003 10:06:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iE4M-0001Vj-QS for sipping-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 10:06: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 KAA26557 for ; Thu, 31 Jul 2003 10:06:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iE4K-00042e-00 for sipping-web-archive@ietf.org; Thu, 31 Jul 2003 10:06:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iE4K-00042b-00 for sipping-web-archive@ietf.org; Thu, 31 Jul 2003 10:06:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iE49-0001QL-8d; Thu, 31 Jul 2003 10:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iE3z-0001Py-Gv for sipping@optimus.ietf.org; Thu, 31 Jul 2003 10:05: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 KAA26509 for ; Thu, 31 Jul 2003 10:05:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iE3x-00042A-00 for sipping@ietf.org; Thu, 31 Jul 2003 10:05:49 -0400 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by ietf-mx with esmtp (Exim 4.12) id 19iE3w-00041r-00 for sipping@ietf.org; Thu, 31 Jul 2003 10:05:48 -0400 Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HIW00E8371EHX@firewall.wcom.com> for sipping@ietf.org; Thu, 31 Jul 2003 14:03:14 +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 <0HIW00M0171EU8@dgismtp01.wcomnet.com>; Thu, 31 Jul 2003 14:03:14 +0000 (GMT) Received: from hsinnreich2 ([166.50.135.133]) by dgismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HIW00M3K71CDD@dgismtp01.wcomnet.com>; Thu, 31 Jul 2003 14:03:14 +0000 (GMT) Date: Thu, 31 Jul 2003 09:03:14 -0500 From: Henry Sinnreich Subject: RE: [Sipping] Re: Static and dynamic policies requirement In-reply-to: <3F27ED50.1040207@dynamicsoft.com> To: "'Jonathan Rosenberg'" Cc: "'sipping'" Message-id: <0HIW00M3N71DDD@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: AcNWtPrmF1i+8xYDSlOewLtEL/QDmAAtqDqQ Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > * The 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.. Maybe it makes sense after all to have the I-D elevated to a SIPPING WG item :-) Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of Jonathan Rosenberg > Sent: Wednesday, July 30, 2003 11:08 AM > To: Volker Hilt > Cc: sipping > Subject: [Sipping] Re: Static and dynamic policies requirement > > Yes, I think it makes sense. > > To back this up a little, we have applications that clearly > require dynamic policies, and ones where static is far > preferable. For policies where the information doesn't > change, dynamic policies are expensive - causing continuous > transmission of the information during call setup, and > possible adding to call setup latencies. > > Take, for example, whether or not to use a media > intermediary. In many cases, the desire for this is constant. > For example, where an enterprise has a NAT which needs to be > traversed. In that case, it can be done with a static policy. > This policy would inform the UA of the TURN relay its > supposed to contact in advance of the call. In other cases, > its dynamic. For example, in a roaming scenario, whether a > local relay is used or not varies on a call by call basis > depending where the user is. ALso, if there are multiple > operators on the call path, and each has a policy for a media > relay (though I think this is an awful thing to do in > general), thats not known till the call is made. > > So, for the case of media relays, we have cases where static > is what we want, and where dynamic is what we want. One of > the issues I had been struggling with for a bit was the > apparent overlap between ICE/TURN and session policy > (assuming dynamic only, which is how the current document is > structured). Both seemed to be ways for media to flow through > an intermediary. The difference is exactly static vs. > dynamic. WHen static policies are used, the user is informed > about the relay (i.e., TURN server) through provisioning. > When dynamic policies are used, the user is informed about > the relay through the dynamic session policy mechanism. In > this case TURN isn't needed to provision the relay; the proxy > does it directly (though I suppose session policy could give > out a turn relay address - need to think about that). > > Allowed codecs are another example where a static session > policy is probably better, since the information is not > likely to change on a call by call basis. > > So, the question then, is what additional requirements do we > have for supporting static policies? I would say: > > * The mechanism must provide the ability to inform the UA > about the set of session policies when the device starts up > > * The mechanism must allow the provider to change the static > policies at least a few times a day > > * The mechanism must allow the static policies to vary on a > user by user basis > > * The mechanism must provide a way to inform the client about > changes in session policies when they occur > > An interesting question is what we mean by "provider". Is > this the home provider (i.e., owner of the namespace in which > the UAs AOR > resides) or visiting one or both? > > -Jonathan R. > > Volker Hilt wrote: > > > Jonathan, > > > > would it make sense to include requirements for the support > of static > > and dynamic policies in the policy requirements draft? These > > requirements could look like the following: > > > > REQ-POL-14: The solution should allow the specification of dynamic > > policies on a call-by-call basis. > > > > REQ-POL-15: The solution should allow the specification of static > > policies, which are applicable to certain calls for a given time. > > > > Thanks, > > > > Volker > > > > -- > 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 Jul 31 10:41: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 KAA29877 for ; Thu, 31 Jul 2003 10:41: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 19iEbi-0003UL-J3 for sipping-archive@odin.ietf.org; Thu, 31 Jul 2003 10:40:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VEegb8013405 for sipping-archive@odin.ietf.org; Thu, 31 Jul 2003 10:40:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEbi-0003U8-FP for sipping-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 10:40: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 KAA29851 for ; Thu, 31 Jul 2003 10:40:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iEbg-0004gk-00 for sipping-web-archive@ietf.org; Thu, 31 Jul 2003 10:40:40 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iEbf-0004gh-00 for sipping-web-archive@ietf.org; Thu, 31 Jul 2003 10:40:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEb3-0003LC-To; Thu, 31 Jul 2003 10:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEac-0003Jn-4p for sipping@optimus.ietf.org; Thu, 31 Jul 2003 10:39: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 KAA29763 for ; Thu, 31 Jul 2003 10:39:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iEaZ-0004fO-00 for sipping@ietf.org; Thu, 31 Jul 2003 10:39:31 -0400 Received: from marionberry.cc.columbia.edu ([128.59.59.100] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19iEaY-0004fL-00 for sipping@ietf.org; Thu, 31 Jul 2003 10:39:30 -0400 Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h6VEdT1s002085 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 31 Jul 2003 10:39:29 -0400 (EDT) Message-ID: <3F292A21.2070806@cs.columbia.edu> Date: Thu, 31 Jul 2003 10:39:29 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Beck01, Wolfgang" CC: 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 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 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 Beck01, Wolfgang wrote: > However, using smart cards (SIM, ISIM, Cryptoflex etc) makes sense for ISPs, > too. It's easier to tell the customer: "insert this card here" instead of > saying: "go to menu x, item y and enter a password longer than 5 characters > with at least 2 numerics, don't choose your aunt's surname and change it > every 8 weeks ...". Interoperability with existing GSM is in this case not > as important as it is for mobile operators. Don't SIM cards also have PINs? Thus, you still have to tell the customer "don't choose the last four digits of your social security number or 1234"... Obviously, requiring both "something you have" and "something you know" is more secure than jut "something you know". 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." _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 31 10:42: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 KAA29927 for ; Thu, 31 Jul 2003 10:42: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 19iEdK-0003ex-Mu for sipping-archive@odin.ietf.org; Thu, 31 Jul 2003 10:42:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VEgMn2014061 for sipping-archive@odin.ietf.org; Thu, 31 Jul 2003 10:42:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEdK-0003eh-HO for sipping-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 10:42: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 KAA29909 for ; Thu, 31 Jul 2003 10:42:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iEdI-0004hy-00 for sipping-web-archive@ietf.org; Thu, 31 Jul 2003 10:42:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iEdH-0004hv-00 for sipping-web-archive@ietf.org; Thu, 31 Jul 2003 10:42:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEd0-0003Z8-8v; Thu, 31 Jul 2003 10: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 19iEcg-0003Yf-LU for sipping@optimus.ietf.org; Thu, 31 Jul 2003 10:41: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 KAA29894 for ; Thu, 31 Jul 2003 10:41:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iEce-0004hM-00 for sipping@ietf.org; Thu, 31 Jul 2003 10:41:40 -0400 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx with esmtp (Exim 4.12) id 19iEcd-0004hF-00 for sipping@ietf.org; Thu, 31 Jul 2003 10:41:39 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 31 Jul 2003 16:41:08 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jul 2003 16:41:07 +0200 Message-Id: <43240544763FB8479F1529372F6197CF053CC8FE@G8PQC.blf01.telekom.de> From: "Liess, Laura" 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 Date: Thu, 31 Jul 2003 16:41: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: , 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 From exim@www1.ietf.org Thu Jul 31 11:09:15 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 LAA00955 for ; Thu, 31 Jul 2003 11:09: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 19iF2w-0005TE-Ml for sipping-archive@odin.ietf.org; Thu, 31 Jul 2003 11:08:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VF8o4r021029 for sipping-archive@odin.ietf.org; Thu, 31 Jul 2003 11:08:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iF2w-0005T6-Hm for sipping-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 11:08: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 LAA00924 for ; Thu, 31 Jul 2003 11:08:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iF2t-0004vj-00 for sipping-web-archive@ietf.org; Thu, 31 Jul 2003 11:08:48 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iF2t-0004vg-00 for sipping-web-archive@ietf.org; Thu, 31 Jul 2003 11:08:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iF2A-0005GQ-Dm; Thu, 31 Jul 2003 11:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iF1f-0005CN-Rh for sipping@optimus.ietf.org; Thu, 31 Jul 2003 11:07: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 LAA00884 for ; Thu, 31 Jul 2003 11:07:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iF1b-0004v3-00 for sipping@ietf.org; Thu, 31 Jul 2003 11:07:27 -0400 Received: from chntex04.is.dyncorp.com ([131.131.133.208]) by ietf-mx with esmtp (Exim 4.12) id 19iF1b-0004v0-00 for sipping@ietf.org; Thu, 31 Jul 2003 11:07:27 -0400 Received: by chntex04.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id <3S5QM77F>; Thu, 31 Jul 2003 11:05:20 -0400 Message-ID: <5EA16A28B747E34FB90B578E6C5DDE8915AAAA@chntex04.is.dyncorp.com> From: "Gunn, Janet" To: "'Henning Schulzrinne'" , "Beck01, Wolfgang" Cc: sipping@ietf.org Subject: RE: AW: [Sipping] FYI: RADIUS & SIP Date: Thu, 31 Jul 2003 11:05:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , The SIM card in my GSM phone doesn't have a PIN associated with it. Or if it does, I have no idea what it is and have never needed to use it. It has all sorts of "secret codes" as part of the authorization process, but I, the human, never deal with them. I think the model would be a "SIM card" that you keep in your wallet, like a credit card, and use on whatever "phone" you want. And/or have multiple SIM cards- one/some that you leave in your "regular phone(s)", and one you keep in your wallet. -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Thursday, July 31, 2003 10:39 AM To: Beck01, Wolfgang Cc: sipping@ietf.org Subject: Re: AW: [Sipping] FYI: RADIUS & SIP Don't SIM cards also have PINs? Thus, you still have to tell the customer "don't choose the last four digits of your social security number or 1234"... Obviously, requiring both "something you have" and "something you know" is more secure than jut "something you know". 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." _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 Jul 31 11:16: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 LAA01236 for ; Thu, 31 Jul 2003 11:16:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iF9Y-0005pE-FX for sipping-archive@odin.ietf.org; Thu, 31 Jul 2003 11:15:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VFFeo4022386 for sipping-archive@odin.ietf.org; Thu, 31 Jul 2003 11:15:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iF9Y-0005oz-BG for sipping-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 11:15: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 LAA01183 for ; Thu, 31 Jul 2003 11:15:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iF9X-0004zd-00 for sipping-web-archive@ietf.org; Thu, 31 Jul 2003 11:15:39 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iF9W-0004za-00 for sipping-web-archive@ietf.org; Thu, 31 Jul 2003 11:15:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iF8v-0005ie-A0; Thu, 31 Jul 2003 11:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iF8D-0005hu-QH for sipping@optimus.ietf.org; Thu, 31 Jul 2003 11:14: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 LAA01124 for ; Thu, 31 Jul 2003 11:14:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iF8C-0004yq-00 for sipping@ietf.org; Thu, 31 Jul 2003 11:14:16 -0400 Received: from marionberry.cc.columbia.edu ([128.59.59.100] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19iF8C-0004yn-00 for sipping@ietf.org; Thu, 31 Jul 2003 11:14:16 -0400 Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h6VFE91s018887 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 31 Jul 2003 11:14:10 -0400 (EDT) Message-ID: <3F293241.4040507@cs.columbia.edu> Date: Thu, 31 Jul 2003 11:14:09 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Gunn, Janet" CC: "Beck01, Wolfgang" , sipping@ietf.org Subject: Re: AW: [Sipping] FYI: RADIUS & SIP References: <5EA16A28B747E34FB90B578E6C5DDE8915AAAA@chntex04.is.dyncorp.com> In-Reply-To: <5EA16A28B747E34FB90B578E6C5DDE8915AAAA@chntex04.is.dyncorp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It then becomes like a credit card - if I have it in my possession, I can make calls around the world. Who is going to foot the bill for this? Gunn, Janet wrote: > The SIM card in my GSM phone doesn't have a PIN associated with it. Or if > it does, I have no idea what it is and have never needed to use it. It has > all sorts of "secret codes" as part of the authorization process, but I, the > human, never deal with them. > > I think the model would be a "SIM card" that you keep in your wallet, like a > credit card, and use on whatever "phone" you want. And/or have multiple SIM > cards- one/some that you leave in your "regular phone(s)", and one you keep > in your wallet. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 31 13: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 NAA05162 for ; Thu, 31 Jul 2003 13: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 19iHEi-000498-3s for sipping-archive@odin.ietf.org; Thu, 31 Jul 2003 13:29:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VHT8FT015932 for sipping-archive@odin.ietf.org; Thu, 31 Jul 2003 13:29:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iHEi-00048t-0e for sipping-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 13:29: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 NAA05131 for ; Thu, 31 Jul 2003 13:29:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iHEf-0005rp-00 for sipping-web-archive@ietf.org; Thu, 31 Jul 2003 13:29:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iHEf-0005rm-00 for sipping-web-archive@ietf.org; Thu, 31 Jul 2003 13:29:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iHEb-00047n-B9; Thu, 31 Jul 2003 13: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 19iHDv-000476-6n for sipping@optimus.ietf.org; Thu, 31 Jul 2003 13:28: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 NAA05085 for ; Thu, 31 Jul 2003 13:28:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iHDt-0005rH-00 for sipping@ietf.org; Thu, 31 Jul 2003 13:28:17 -0400 Received: from dakiya.austria.eu.net ([193.154.160.117]) by ietf-mx with esmtp (Exim 4.12) id 19iHDr-0005rE-00 for sipping@ietf.org; Thu, 31 Jul 2003 13:28:15 -0400 Received: from mah9.eunet.at (unknown [212.119.128.110]) by dakiya.austria.eu.net (Postfix) with ESMTP id AAB7D4EADD; Thu, 31 Jul 2003 20:26:59 +0200 (MEST) Message-Id: <5.2.0.9.2.20030731161030.042c1528@mail.inode.at> X-Sender: mah#inode.at@mail.inode.at (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 31 Jul 2003 19:28:07 +0200 To: "Beck01, Wolfgang" , sipping@ietf.org From: Michael Haberler Subject: RE: AW: [Sipping] FYI: RADIUS & SIP In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-712E2E30; boundary="=======1C547156=======" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --=======1C547156======= Content-Type: text/plain; x-avg-checked=avg-ok-712E2E30; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit At 14:45 31.07.2003 +0200, Beck01, Wolfgang wrote: >Thanks for the clarification. Coming back to the original question, a >RADIUS server would have to support several challenge/response schemes: >- CHAP (available in today's RADIUS servers, but not in today's SIP phones) >- HTTP Digest (Sterman draft, available in some RADIUS servers and most >SIP phones) >- the GSM SIM A3 algorithm du jour >- 3GPP ISIM AKA >if the provider does not have an alternative GSM authentication >infrastructure. HTTP Digest is largely CHAP as is GSM SIM, and with a minor modification the Sterman draft can cover GSM authentication in a basic configuration as well. For better security properties like in EAP/SIM we would need a separate authentication method, as this cant be easily retrofitted into HTTP digest and HTTP EAP did not make it. The difference is in challenge computation - the Sterman draft locally computes a challenge, challenges the client, receives the response and sense challenge and response to the RADIUS server for authentication. 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. This triplet can be gatewayed to a RADIUS server through an SS7 MAP gateway (this is what the EAP-SIM WLAN RADIUS infrastructure does). So the Radius server must first fetch a triplet after he has received the authentication user id (the IMSI, International Mobile Subscriber Identity), and use the challenge from that triplet. So there's some RADIUS work, and more with HTTP AKA. We have currently a project with iptel.org to implement a prototype to study basic feasability of SIP client authentication with SIM cards. This thread was about the question how existing RADIUS infrastructures can >be extended to support SIP. Your proposal is about the question how SIP >should be extended to be able to reuse a existing GSM authentication >infrastructures. This is reasonable for a mobile operator but not for an >ISP. I believe the GSM authentication method is one of our few viable options to bootstrap better stuff, like X.509 certificates, off it. For instance, in an authenticated context one could download a certificate over the air into the card, or even SIM Toolkit application, or client configuration data. Once you have a certificate you use it with TLS. This would give mobile operators who want it a second line service, and an ISP the choice to authenticate himself against his own Radius+database, or sell the customers to a mobile operator - if there is a common standard without user base migration. I dont believe a "standalone" ISP-only authentication smart card method will get off the ground easily. >However, using smart cards (SIM, ISIM, Cryptoflex etc) makes sense for ISPs, >too. It's easier to tell the customer: "insert this card here" instead of >saying: "go to menu x, item y and enter a password longer than 5 characters >with at least 2 numerics, don't choose your aunt's surname and change it >every 8 weeks ...". Interoperability with existing GSM is in this case not >as important as it is for mobile operators. This is psychologically very important - you dont have to explain what a SIM card is - it is deja vu for the consumer. You're just distributing an "Internet SIM card", which has a number and an account associated with it. Technically I would agree on the interoperability, but not on the market devlopment aspect. Mobile operators are also wonderful billing and authentication machines. -Micahel Haberler --=======1C547156=======-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 31 13:46: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 NAA05826 for ; Thu, 31 Jul 2003 13:46: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 19iHV8-0005J3-5y for sipping-archive@odin.ietf.org; Thu, 31 Jul 2003 13:46:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VHk69P020391 for sipping-archive@odin.ietf.org; Thu, 31 Jul 2003 13:46:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iHV8-0005In-1q for sipping-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 13:46: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 NAA05765 for ; Thu, 31 Jul 2003 13:46:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iHV5-00064A-00 for sipping-web-archive@ietf.org; Thu, 31 Jul 2003 13:46:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iHV4-000646-00 for sipping-web-archive@ietf.org; Thu, 31 Jul 2003 13: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 19iHV4-0005H4-Rf; Thu, 31 Jul 2003 13: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 19iHUe-0005FP-E0 for sipping@optimus.ietf.org; Thu, 31 Jul 2003 13:45: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 NAA05744 for ; Thu, 31 Jul 2003 13:45:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iHUc-00063w-00 for sipping@ietf.org; Thu, 31 Jul 2003 13:45:34 -0400 Received: from relay12.austria.eu.net ([193.154.160.116]) by ietf-mx with esmtp (Exim 4.12) id 19iHUa-00063t-00 for sipping@ietf.org; Thu, 31 Jul 2003 13:45:33 -0400 Received: from mah9.eunet.at (unknown [212.119.128.110]) by relay12.austria.eu.net (Postfix) with ESMTP id 156C5C4082; Thu, 31 Jul 2003 19:45:31 +0200 (CEST) Message-Id: <5.2.0.9.2.20030731193850.04374660@mail.inode.at> X-Sender: mah#inode.at@mail.inode.at (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 31 Jul 2003 19:44:08 +0200 To: Henning Schulzrinne , "Gunn, Janet" From: Michael Haberler Subject: Re: AW: [Sipping] FYI: RADIUS & SIP Cc: "Beck01, Wolfgang" , sipping@ietf.org In-Reply-To: <3F293241.4040507@cs.columbia.edu> References: <5EA16A28B747E34FB90B578E6C5DDE8915AAAA@chntex04.is.dyncorp.com> <5EA16A28B747E34FB90B578E6C5DDE8915AAAA@chntex04.is.dyncorp.com> Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-712E2E30; boundary="=======3C481BFA=======" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --=======3C481BFA======= Content-Type: text/plain; x-avg-checked=avg-ok-712E2E30; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit The GSM operators have been through this many moons ago, through the courts and all. This is established legal ground. There is a pin code by default on GSM SIM cards. It is the protection for your account from stealing the phone (or card). This is also why you usually have three tries on the PIN, and then the card locks up until you unlock it with a another "more powerful" PIN unlock code. You fail here as well a few times the card permanently disables itself. You can remove the PIN code, however you cannot complain to your phone company because you didnt make all those calls on your bill if you do. Its your responsibility if you opt out of PIN code protection. -Michael At 11:14 31.07.2003 -0400, Henning Schulzrinne wrote: >It then becomes like a credit card - if I have it in my possession, I can >make calls around the world. Who is going to foot the bill for this? > >Gunn, Janet wrote: > >>The SIM card in my GSM phone doesn't have a PIN associated with it. Or if >>it does, I have no idea what it is and have never needed to use it. It has >>all sorts of "secret codes" as part of the authorization process, but I, the >>human, never deal with them. >>I think the model would be a "SIM card" that you keep in your wallet, like a >>credit card, and use on whatever "phone" you want. And/or have multiple SIM >>cards- one/some that you leave in your "regular phone(s)", and one you keep >>in your wallet. > > > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP > > --=======3C481BFA=======-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application 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 Jul 31 14:34: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 NAA05825 for ; Thu, 31 Jul 2003 13:46: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 19iHV8-0005Io-1e for sipping-archive@odin.ietf.org; Thu, 31 Jul 2003 13:46:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VHk67e020375 for sipping-archive@odin.ietf.org; Thu, 31 Jul 2003 13:46:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iHV7-0005IY-Ue for sipping-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 13:46: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 NAA05762 for ; Thu, 31 Jul 2003 13:46:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iHV5-00064D-00 for sipping-web-archive@ietf.org; Thu, 31 Jul 2003 13:46:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iHV4-000647-00 for sipping-web-archive@ietf.org; Thu, 31 Jul 2003 13: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 19iHV4-0005GV-1o; Thu, 31 Jul 2003 13: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 19iHUU-0005Cn-9C for sipping@optimus.ietf.org; Thu, 31 Jul 2003 13:45: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 NAA05734 for ; Thu, 31 Jul 2003 13:45:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iHUS-00063q-00 for sipping@ietf.org; Thu, 31 Jul 2003 13:45:24 -0400 Received: from relay12.austria.eu.net ([193.154.160.116]) by ietf-mx with esmtp (Exim 4.12) id 19iHUQ-00063n-00 for sipping@ietf.org; Thu, 31 Jul 2003 13:45:23 -0400 Received: from mah9.eunet.at (unknown [212.119.128.110]) by relay12.austria.eu.net (Postfix) with ESMTP id B8D5FC406B; Thu, 31 Jul 2003 19:45:18 +0200 (CEST) Message-Id: <5.2.0.9.2.20030731180124.04345b40@mail.inode.at> X-Sender: mah#inode.at@mail.inode.at (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 31 Jul 2003 19:37:18 +0200 To: "Gunn, Janet" , "'Henning Schulzrinne'" , "Beck01, Wolfgang" From: Michael Haberler Subject: RE: AW: [Sipping] FYI: RADIUS & SIP Cc: sipping@ietf.org In-Reply-To: <5EA16A28B747E34FB90B578E6C5DDE8915AAAA@chntex04.is.dyncorp .com> Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-712E2E30; boundary="=======1B116C58=======" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --=======1B116C58======= Content-Type: text/plain; x-avg-checked=avg-ok-712E2E30; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit At 11:05 31.07.2003 -0400, Gunn, Janet wrote: >The SIM card in my GSM phone doesn't have a PIN associated with it. Or if It does, or it aint a GSM SIM card, however asking for the PIN code may be turned off. See http://www.ttfn.net/techno/smartcards/gsm11-11.pdf for the basics. I've collected some introductory material at http://www.mah.priv.at/siptrust/doit/sim.html . >I think the model would be a "SIM card" that you keep in your wallet, like a >credit card, and use on whatever "phone" you want. And/or have multiple SIM >cards- one/some that you leave in your "regular phone(s)", and one you keep >in your wallet. I was assuming a personal phone user context, like a WiFi SIP handset, with a SIM card permanently inserted into it - much like a cellular. But it is not uncommon to find PBX extensions in large organizations which use smart cards inserted in the phone for accounting purposes. I dont think this is very appealing. -Michael Haberler >-----Original Message----- >From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >Sent: Thursday, July 31, 2003 10:39 AM >To: Beck01, Wolfgang >Cc: sipping@ietf.org >Subject: Re: AW: [Sipping] FYI: RADIUS & SIP > > > > >Don't SIM cards also have PINs? Thus, you still have to tell the >customer "don't choose the last four digits of your social security >number or 1234"... Obviously, requiring both "something you have" and >"something you know" is more secure than jut "something you know". > >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." > > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the 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 --=======1B116C58=======-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP