From mailnull@www1.ietf.org Mon Jun 2 04:04:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27220 for ; Mon, 2 Jun 2003 04:04:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5284NI20814 for sipping-archive@odin.ietf.org; Mon, 2 Jun 2003 04:04:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5284NB20811 for ; Mon, 2 Jun 2003 04:04: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 EAA27191 for ; Mon, 2 Jun 2003 04:04:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MkH5-0000lq-00 for sipping-web-archive@ietf.org; Mon, 02 Jun 2003 04:02:35 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MkH5-0000ln-00 for sipping-web-archive@ietf.org; Mon, 02 Jun 2003 04:02:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5283OB20637; Mon, 2 Jun 2003 04:03:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RB0LB07471 for ; Tue, 27 May 2003 07:00: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 GAA07550; Tue, 27 May 2003 06:59:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Kc9p-00036Y-00; Tue, 27 May 2003 06:58:17 -0400 Received: from uni03du.unity.ncsu.edu ([152.1.13.103]) by ietf-mx with esmtp (Exim 4.12) id 19Kc9o-00036V-00; Tue, 27 May 2003 06:58:17 -0400 Received: (from prsinha@localhost) by uni03du.unity.ncsu.edu (8.8.4/EC02Jan97) id GAA01101; Tue, 27 May 2003 06:59:49 -0400 (EDT) Date: Tue, 27 May 2003 06:59:49 -0400 (EDT) From: Prabhas Ranjan Sinha To: Henry Sinnreich cc: "'Santharam, Arun [NTWK SVCS]'" , "'Rajarshi Chakraborty'" , drage@lucent.com, ashishn@mahindrabt.com, sip@ietf.org, sipping@ietf.org Subject: Re: [Sip] RE: [Sipping] RE: SIP mobility in WLAN In-Reply-To: <001001c31fb0$5e437450$307b32a6@hsinnreich2> Message-ID: References: <001001c31fb0$5e437450$307b32a6@hsinnreich2> 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: , > > The other alternative is to have application layer mobility for SIP as > published in several papers at Columbia University and Telcordia. I > don't believe you need mobile IP for all scenarios or that is the best > option under all circumstances. > > The last word on this may not be over yet. > > Henry Henry, Could you please elaborate on it more w.r.t pros and cons or refer me to to any publication which can talk about it ? I have read that people forsee that Mobile IP could be the most suitable mechanism for mobility across multiple subnets of WLAN network. Prabhas > > > -----Original Message----- > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > On Behalf Of Santharam, Arun [NTWK SVCS] > > Sent: Monday, May 19, 2003 1:35 PM > > To: Rajarshi Chakraborty; drage@lucent.com; > > ashishn@mahindrabt.com; sip@ietf.org > > Cc: sipping@ietf.org > > Subject: [Sipping] RE: SIP mobility in WLAN > > > > > > > > If we follow the SIP implementation on Mobile IP then the SIP > > stack should not have to bother about the mobility aspect. > > The SIP stack should be notified of IP changes/handoff > > information (if relevant for the SIP stack) by the underlying > > stack. This may prompt a SIP registration and subsequent call flows. > > > > My 2 cents ... > > arun > > > > > > > -----Original Message----- > > > From: Rajarshi Chakraborty [mailto:rajarshi_chakraborty@hotmail.com] > > > Sent: Sunday, May 18, 2003 11:42 PM > > > To: drage@lucent.com; ashishn@mahindrabt.com; Santharam, Arun > > > [NTWK SVCS]; sip@ietf.org > > > Cc: sipping@ietf.org > > > Subject: SIP mobility in WLAN > > > > > > > > > Hi, > > > > > > Where can I get call-flows for SIP session management in a > > > wireless LAN > > > (802.11)? 3GPP only addresses the issues for cellular > > > networks. Or are they > > > too trivial to be addressed specially? I am specially interested in > > > situations of handoffs (in this case, the IP changes as soon > > > as the host > > > shifts from the zone around one hotspot to another). Should > > > SIP bother at > > > all to detect IP changes or should the control be completely > > > outside SIP? I > > > mean should it be some other module that has the > > > responsibility of informing > > > the SIP stack in the mobile host about the IP changes, so > > > that the host may > > > then send a re-INVITE with a new SDP but the call still > > > remains active? > > > > > > regards > > > Rajarshi > > > > > > > > > Rajarshi Chakraborty > > > B-196, IIT Campus, > > > Kharagpur, > > > West Bengal, India > > > PIN-721302 > > > > > > > > > > > > > > > > > > ----Original Message Follows---- > > > From: "Drage, Keith (Keith)" > > > To: "'Ashish Naik'" , "Santharam, > > > Arun [CC]" > > > , "Sip@Ietf. Org" > > > Subject: RE: [Sip] Session Mobility in SIP > > > Date: Thu, 8 May 2003 14:42:24 +0100 > > > > > > Your best starting point to see the architecture is 3GPP TS > > > 23.228, with > > > reference to 3GPP TS 23.002 to see how these entities fit > > > together into the > > > entire 3GPP architecture. > > > > > > The SIP protocol application is covered in 3GPP TS 24.229 > > > with example flows > > > in 3GPP TS 24.228. > > > > > > These documents may be found at: > > > > > > ftp://ftp.3gpp.org/Specs/latest/Rel-5/ > > > > > > > > > 3GPP uses these specifications over GPRS to provide mobility. > > > > > > There is a parallel set of 3GPP2 specifications, > > > substantially of common > > > text, that uses the same architecture over mobile IP, instead > > > of GPRS. These > > > documents are currently in 3GPP2 comment and review. > > > > > > regards > > > > > > Keith > > > > > > > > > > > > > > > Keith Drage > > > Lucent Technologies > > > Tel: +44 1793 776249 > > > Email: drage@lucent.com > > > > > > -----Original Message----- > > > From: Ashish Naik [mailto:ashishn@mahindrabt.com] > > > Sent: 08 May 2003 06:23 > > > To: Santharam, Arun [CC]; Sip@Ietf. Org > > > Subject: RE: [Sip] Session Mobility in SIP > > > > > > > > > ok. Is there any specific document on IETF and 3GPP that can > > > explain how it > > > is being addressed ? > > > > > > > > > Ragards, > > > Ashish Naik > > > CoE Mobile Computing > > > ----------------------------------- > > > Phone 4018100 Ext 3070 > > > > > > > > > -----Original Message----- > > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf > > > Of Santharam, > > > Arun [CC] > > > Sent: Wednesday, April 09, 2003 9:42 PM > > > To: Ashish Naik; Sip@Ietf. Org > > > Subject: RE: [Sip] Session Mobility in SIP > > > > > > > > > > > > Ashish, > > > > > > > > > > > > Please find comments inline. > > > > > > > > > > > > Thank you > > > > > > arun > > > > > > > > > > > > -----Original Message----- > > > From: Ashish Naik [mailto:ashishn@mahindrabt.com] > > > Sent: Wednesday, April 09, 2003 4:01 AM > > > To: Sip@Ietf. Org > > > Subject: [Sip] Session Mobility in SIP > > > > > > > > > > > > How is SIP going to address session mobility ? Is there any > > > initiative taken > > > up for this ? > > > > > > > > > > > > > This has been addressed in 3GPP standards. Please refer to > > > the 3GPP All > > > IP architecture specifications. > > > > > > > > > > > > SIP is said to be a better alternative than Mobile IP. Can I > > > have some > > > latest development document references ? > > > > > > > > > > > > > > > > > > > SIP is not going to replace Mobile IP. It is going to > > > leverage Mobile IP > > > for session management in 3G wireless networks. > > > > > > > > > > > > > > > > > > Regards, > > > Ashish Naik > > > ------------------- > > > CoE Mobile Computing > > > Phone: 4018100 Ext 3070 > > > > > > > > > > > > > > > ********************************************************* > > > Disclaimer > > > > > > This message (including any attachments) contains confidential > > > information intended for a specific individual and purpose, and is > > > protected by law. If you are not the intended recipient, you should > > > delete this message and are hereby notified that > > > any disclosure, copying, or distribution of this > > > message, or the taking of any action based on it, > > > is strictly prohibited. > > > > > > ********************************************************* > > > Visit us at http://www.mahindrabt.com > > > > > > > > > > > > > > > ********************************************************* > > > Disclaimer > > > > > > This message (including any attachments) contains confidential > > > information intended for a specific individual and purpose, and is > > > protected by law. If you are not the intended recipient, you should > > > delete this message and are hereby notified that > > > any disclosure, copying, or distribution of this > > > message, or the taking of any action based on it, > > > is strictly prohibited. > > > > > > ********************************************************* > > > Visit us at http://www.mahindrabt.com > > > > > > _________________________________________________________________ > > > Mobile, masti, magic! Cool ringtones & logos. > > > http://www.msn.co.in/mobile/ > > > Get noticed > > > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current > > sip Use sip@ietf.org for new developments of core SIP > > > > _______________________________________________ > 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 > Prabhas +++++++++++++ CSEL Technology Enterprise Programme London Business School Baker Street, London NW1 6DD ***************************************** There is no wisdom greater than kindness. ***************************************** _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jun 2 04:04:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27234 for ; Mon, 2 Jun 2003 04:04:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5284Pq20830 for sipping-archive@odin.ietf.org; Mon, 2 Jun 2003 04:04:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5284PB20827 for ; Mon, 2 Jun 2003 04:04: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 EAA27195 for ; Mon, 2 Jun 2003 04:04:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MkH7-0000lx-00 for sipping-web-archive@ietf.org; Mon, 02 Jun 2003 04:02:37 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MkH6-0000lu-00 for sipping-web-archive@ietf.org; Mon, 02 Jun 2003 04:02:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5283UB20676; Mon, 2 Jun 2003 04:03:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RDjpB20343 for ; Tue, 27 May 2003 09:45: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 JAA11460; Tue, 27 May 2003 09:45:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KekO-0004Kj-00; Tue, 27 May 2003 09:44:12 -0400 Received: from tssg.wit.ie ([193.1.185.11] helo=mail.tssg.org) by ietf-mx with esmtp (Exim 4.12) id 19KekK-0004KW-00; Tue, 27 May 2003 09:44:08 -0400 Received: from boolard (unknown [10.37.1.56]) by mail.tssg.org (Postfix) with SMTP id 689801809A; Tue, 27 May 2003 14:46:26 +0100 (IST) From: "Shane McCormack" To: , Date: Tue, 27 May 2003 14:50:08 +0100 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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Subject: [Sipping] Number of registered UAs Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk 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, Is it possible to calculate how many UA's a particular user in the network has either through registration details or otherwise? Regards Shane Shane McCormack Research Assistant, TSSG, Confederation House, Waterford Business Park, Cork Road, Waterford, Co. Waterford. Phone: +353 51 302927 Fax: +353 51 302901 Mobile: +353 87 9955505 http://www.tssg.org MSN: mccormackshane@hotmail.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jun 2 04:04:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27248 for ; Mon, 2 Jun 2003 04:04:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5284Rt20849 for sipping-archive@odin.ietf.org; Mon, 2 Jun 2003 04:04:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5284RB20846 for ; Mon, 2 Jun 2003 04:04: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 EAA27199 for ; Mon, 2 Jun 2003 04:04:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MkH9-0000m3-00 for sipping-web-archive@ietf.org; Mon, 02 Jun 2003 04:02:39 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MkH9-0000m0-00 for sipping-web-archive@ietf.org; Mon, 02 Jun 2003 04:02:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5283aB20718; Mon, 2 Jun 2003 04:03:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RGKWB00368 for ; Tue, 27 May 2003 12:20: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 MAA18748 for ; Tue, 27 May 2003 12:20:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KhA7-0005vF-00 for sipping@ietf.org; Tue, 27 May 2003 12:18:55 -0400 Received: from pmesmtp01.wcom.com ([199.249.20.1]) by ietf-mx with esmtp (Exim 4.12) id 19KhA6-0005v8-00 for sipping@ietf.org; Tue, 27 May 2003 12:18:55 -0400 Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HFJ002DKZZLP7@firewall.wcom.com> for sipping@ietf.org; Tue, 27 May 2003 16:18:57 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HFJ00A01ZWW59@dgismtp03.wcomnet.com>; Tue, 27 May 2003 16:18:57 +0000 (GMT) Received: from hsinnreich2 ([166.35.136.36]) by dgismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HFJ0089CZXOYV@dgismtp03.wcomnet.com>; Tue, 27 May 2003 16:18:12 +0000 (GMT) Date: Tue, 27 May 2003 11:17:49 -0500 From: Henry Sinnreich Subject: RE: [Sipping] Text support in SIP phones In-reply-to: To: "=?iso-8859-1?Q?'Gunnar_Hellstr=F6m'?=" , "'Sipping@Ietf. Org'" , "'Sipforum-Discussion@Lists. Su. Se'" Cc: "'Henry Sinnreich'" Message-id: <002501c3246b$929cdc40$248823a6@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 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4RGKcB00369 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h5283aB20718 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5284RB20846 Content-Transfer-Encoding: 8bit Gunnar, this all seems very reasonable, and I will try to insert it properly. Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of Gunnar Hellström > Sent: Thursday, May 22, 2003 6:54 PM > To: 'Sipping@Ietf. Org'; Sipforum-Discussion@Lists. Su. Se > Cc: Henry Sinnreich > Subject: [Sipping] Text support in SIP phones > > > Sorry, I missed out the reference to the SIP device specification. > > Henry and all, > > Some time ago, I suggested addition of support for real time > text communication to the SIP device specification > http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-00.txt > > This was the simple part of the proposal: > > > SIP-zz, digital text support: SIP telephone devices MUST support > > real time text conversation using RFC 2793 [y] for the > text stream. > > It MUST be possible to use text simultaneously with voice. > > > > > > > > --------------------------------------------- > > In 4.11 Ringer Behaviour : add the section below for the > purpose of > > deaf, hearing impaired, deaf-blind people and people in the > garden and > > noisy > > locations: > > > > SIP Telephony devices MUST provide an external interface to an > > external alerting system. > > > > > > > > Add to References > > ----------------- > > [y] G. Hellstrom: "RTP Payload for Text Conversation.", RFC 2793, > > IETF, May 2000. > > > > -------------------------------------------------------------- > > The reception of this proposal was very positive. > Now, I would like to see the final formulation, and check > that we agree on it. > > I regard this requirement to be very light. In the Interface > section ( e.g. > Int-2) , there is already mentioning of mandatory text input > mechanisms, and assumptions that a display would be normal, > since handling of phone books and buddy lists are mandatory. > To re-use these text interface devices during the call for > standardised text conversation purposes seems straightforward. > > It could be wise to add the T.140 text presentation protocol > as a codec to the codec section. The normal SDP used together > with RFC2793 for text could also be specified. Do you want to do that? > > > ----- > > We also need to check the ideas around the other proposed > requirements: The requirement to include text telephone modem > in all designs where an RJ11 phone connector exists, and the > requirement to support RFC 3351. I suggest that we start with > the straightforward and mainstream requirement above. Is that > accepted as it is? > > > Regards > > Gunnar > ------------------------------------------- > Gunnar Hellström, Omnitor, Renathvägen 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 mailnull@www1.ietf.org Mon Jun 2 04:05:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27265 for ; Mon, 2 Jun 2003 04:05:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5284Xt20875 for sipping-archive@odin.ietf.org; Mon, 2 Jun 2003 04:04:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5284XB20872 for ; Mon, 2 Jun 2003 04:04: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 EAA27206 for ; Mon, 2 Jun 2003 04:04:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MkHG-0000mE-00 for sipping-web-archive@ietf.org; Mon, 02 Jun 2003 04:02:46 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MkHF-0000mB-00 for sipping-web-archive@ietf.org; Mon, 02 Jun 2003 04:02:45 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5283dB20740; Mon, 2 Jun 2003 04:03:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RLFHB23655 for ; Tue, 27 May 2003 17:15: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 RAA02892 for ; Tue, 27 May 2003 17:15:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KllL-0001gr-00 for sipping@ietf.org; Tue, 27 May 2003 17:13:39 -0400 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by ietf-mx with esmtp (Exim 4.12) id 19KllK-0001gU-00 for sipping@ietf.org; Tue, 27 May 2003 17:13:38 -0400 Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.wcom.com (Iplanet MTA) with ESMTP id <0HFK00GKHDOAA9@firewall.wcom.com> for sipping@ietf.org; Tue, 27 May 2003 21:14:35 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HFK00101DEW37@dgismtp03.wcomnet.com>; Tue, 27 May 2003 21:14:34 +0000 (GMT) Received: from hsinnreich2 ([166.35.136.36]) by dgismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HFK00LOWDMFIZ@dgismtp03.wcomnet.com>; Tue, 27 May 2003 21:13:36 +0000 (GMT) Date: Tue, 27 May 2003 16:13:28 -0500 From: Henry Sinnreich In-reply-to: <5.2.0.9.2.20030525161330.0355dac8@pop.mcilink.com> To: Henning Schulzrinne , pkzivat@cisco.com, vkg@lucent.com, jdrosen@dynamicsoft.com, sipping@ietf.org Message-id: <000601c32494$d72d3610$248823a6@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] Security and privacy in Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk 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 I-D provides excellent rich presence information, but should expand on the required specifics for matching security and privacy protection. Section 9, Security Considerations says "Compared to PIDF, this presence document format reveals additional information that can be highly sensitive. Beyond traditional security measures to protect confidentiality and integrity, systems should offer a means to selectively reveal information to particular watchers and to inspect the information that is being published, particularly if it is generated automatically from other sources, such as calendars or sensors." I believe expanding on this and providing some criteria to differentiate between types of watchers, with detailed examples would fill the gap. Thanks, Henry Henry Sinnreich MCI 400 International Parkway Richardson, Texas 75081 USA _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jun 2 04:05:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27305 for ; Mon, 2 Jun 2003 04:05:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5284nr20907 for sipping-archive@odin.ietf.org; Mon, 2 Jun 2003 04:04:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5284mB20904 for ; Mon, 2 Jun 2003 04:04: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 EAA27211 for ; Mon, 2 Jun 2003 04:04:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MkHV-0000mL-00 for sipping-web-archive@ietf.org; Mon, 02 Jun 2003 04:03:01 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MkHU-0000mI-00 for sipping-web-archive@ietf.org; Mon, 02 Jun 2003 04:03:00 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5283XB20698; Mon, 2 Jun 2003 04:03:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RFoeB30132 for ; Tue, 27 May 2003 11:50: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 LAA17755; Tue, 27 May 2003 11:50:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KghE-0005eA-00; Tue, 27 May 2003 11:49:04 -0400 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by ietf-mx with esmtp (Exim 4.12) id 19KghD-0005dv-00; Tue, 27 May 2003 11:49:03 -0400 Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0HFJ0084JYNJX4@firewall.wcom.com>; Tue, 27 May 2003 15:50:07 +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 <0HFJ00701YJRL5@dgismtp04.wcomnet.com>; Tue, 27 May 2003 15:50:07 +0000 (GMT) Received: from hsinnreich2 ([166.35.136.36]) by dgismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HFJ005P7YMQYU@dgismtp04.wcomnet.com>; Tue, 27 May 2003 15:49:43 +0000 (GMT) Date: Tue, 27 May 2003 10:49:39 -0500 From: Henry Sinnreich Subject: RE: [Sip] RE: [Sipping] RE: SIP mobility in WLAN In-reply-to: To: "'Prabhas Ranjan Sinha'" , "'Henry Sinnreich'" Cc: "'Santharam, Arun [NTWK SVCS]'" , "'Rajarshi Chakraborty'" , drage@lucent.com, ashishn@mahindrabt.com, sip@ietf.org, sipping@ietf.org Message-id: <000301c32467$97b24520$248823a6@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 Please check www.research.telcordia.com/sip-mobile and http://www.cs.columbia.edu/~hgs/papers/Schu0007_Application.pdf Thanks, Henry > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Prabhas Ranjan Sinha > Sent: Tuesday, May 27, 2003 6:00 AM > To: Henry Sinnreich > Cc: 'Santharam, Arun [NTWK SVCS]'; 'Rajarshi Chakraborty'; > drage@lucent.com; ashishn@mahindrabt.com; sip@ietf.org; > sipping@ietf.org > Subject: Re: [Sip] RE: [Sipping] RE: SIP mobility in WLAN > > > > > > > The other alternative is to have application layer mobility > for SIP as > > published in several papers at Columbia University and Telcordia. I > > don't believe you need mobile IP for all scenarios or that > is the best > > option under all circumstances. > > > > The last word on this may not be over yet. > > > > Henry > > Henry, > Could you please elaborate on it more w.r.t pros and cons or > refer me to to any publication which can talk about it ? I > have read that people forsee that Mobile IP could be the most > suitable mechanism for mobility across multiple subnets of > WLAN network. > > Prabhas > > > > > > > > > > > -----Original Message----- > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On > > > Behalf Of Santharam, Arun [NTWK SVCS] > > > Sent: Monday, May 19, 2003 1:35 PM > > > To: Rajarshi Chakraborty; drage@lucent.com; > ashishn@mahindrabt.com; > > > sip@ietf.org > > > Cc: sipping@ietf.org > > > Subject: [Sipping] RE: SIP mobility in WLAN > > > > > > > > > > > > If we follow the SIP implementation on Mobile IP then the > SIP stack > > > should not have to bother about the mobility aspect. The > SIP stack > > > should be notified of IP changes/handoff information (if relevant > > > for the SIP stack) by the underlying stack. This may prompt a SIP > > > registration and subsequent call flows. > > > > > > My 2 cents ... > > > arun > > > > > > > > > > -----Original Message----- > > > > From: Rajarshi Chakraborty > > > > [mailto:rajarshi_chakraborty@hotmail.com] > > > > Sent: Sunday, May 18, 2003 11:42 PM > > > > To: drage@lucent.com; ashishn@mahindrabt.com; Santharam, Arun > > > > [NTWK SVCS]; sip@ietf.org > > > > Cc: sipping@ietf.org > > > > Subject: SIP mobility in WLAN > > > > > > > > > > > > Hi, > > > > > > > > Where can I get call-flows for SIP session management in a > > > > wireless LAN (802.11)? 3GPP only addresses the issues > for cellular > > > > networks. Or are they > > > > too trivial to be addressed specially? I am specially > interested in > > > > situations of handoffs (in this case, the IP changes as soon > > > > as the host > > > > shifts from the zone around one hotspot to another). Should > > > > SIP bother at > > > > all to detect IP changes or should the control be completely > > > > outside SIP? I > > > > mean should it be some other module that has the > > > > responsibility of informing > > > > the SIP stack in the mobile host about the IP changes, so > > > > that the host may > > > > then send a re-INVITE with a new SDP but the call still > > > > remains active? > > > > > > > > regards > > > > Rajarshi > > > > > > > > > > > > Rajarshi Chakraborty > > > > B-196, IIT Campus, > > > > Kharagpur, > > > > West Bengal, India > > > > PIN-721302 > > > > > > > > > > > > > > > > > > > > > > > > ----Original Message Follows---- > > > > From: "Drage, Keith (Keith)" > > > > To: "'Ashish Naik'" , "Santharam, > > > > Arun [CC]" > > > > , "Sip@Ietf. Org" > > > > Subject: RE: [Sip] Session Mobility in SIP > > > > Date: Thu, 8 May 2003 14:42:24 +0100 > > > > > > > > Your best starting point to see the architecture is 3GPP TS > > > > 23.228, with reference to 3GPP TS 23.002 to see how > these entities > > > > fit together into the > > > > entire 3GPP architecture. > > > > > > > > The SIP protocol application is covered in 3GPP TS 24.229 with > > > > example flows in 3GPP TS 24.228. > > > > > > > > These documents may be found at: > > > > > > > > ftp://ftp.3gpp.org/Specs/latest/Rel-5/ > > > > > > > > > > > > 3GPP uses these specifications over GPRS to provide mobility. > > > > > > > > There is a parallel set of 3GPP2 specifications, > substantially of > > > > common text, that uses the same architecture over mobile IP, > > > > instead of GPRS. These > > > > documents are currently in 3GPP2 comment and review. > > > > > > > > regards > > > > > > > > Keith > > > > > > > > > > > > > > > > > > > > Keith Drage > > > > Lucent Technologies > > > > Tel: +44 1793 776249 > > > > Email: drage@lucent.com > > > > > > > > -----Original Message----- > > > > From: Ashish Naik [mailto:ashishn@mahindrabt.com] > > > > Sent: 08 May 2003 06:23 > > > > To: Santharam, Arun [CC]; Sip@Ietf. Org > > > > Subject: RE: [Sip] Session Mobility in SIP > > > > > > > > > > > > ok. Is there any specific document on IETF and 3GPP that can > > > > explain how it is being addressed ? > > > > > > > > > > > > Ragards, > > > > Ashish Naik > > > > CoE Mobile Computing > > > > ----------------------------------- > > > > Phone 4018100 Ext 3070 > > > > > > > > > > > > -----Original Message----- > > > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On > Behalf Of > > > > Santharam, Arun [CC] > > > > Sent: Wednesday, April 09, 2003 9:42 PM > > > > To: Ashish Naik; Sip@Ietf. Org > > > > Subject: RE: [Sip] Session Mobility in SIP > > > > > > > > > > > > > > > > Ashish, > > > > > > > > > > > > > > > > Please find comments inline. > > > > > > > > > > > > > > > > Thank you > > > > > > > > arun > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Ashish Naik [mailto:ashishn@mahindrabt.com] > > > > Sent: Wednesday, April 09, 2003 4:01 AM > > > > To: Sip@Ietf. Org > > > > Subject: [Sip] Session Mobility in SIP > > > > > > > > > > > > > > > > How is SIP going to address session mobility ? Is there any > > > > initiative taken up for this ? > > > > > > > > > > > > > > > > > This has been addressed in 3GPP standards. Please > refer to the > > > > 3GPP All IP architecture specifications. > > > > > > > > > > > > > > > > SIP is said to be a better alternative than Mobile IP. > Can I have > > > > some latest development document references ? > > > > > > > > > > > > > > > > > > > > > > > > > SIP is not going to replace Mobile IP. It is going > to leverage > > > > Mobile IP for session management in 3G wireless networks. > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > Ashish Naik > > > > ------------------- > > > > CoE Mobile Computing > > > > Phone: 4018100 Ext 3070 > > > > > > > > > > > > > > > > > > > > ********************************************************* > > > > Disclaimer > > > > > > > > This message (including any attachments) contains confidential > > > > information intended for a specific individual and > purpose, and is > > > > protected by law. If you are not the intended recipient, you > > > > should delete this message and are hereby notified that any > > > > disclosure, copying, or distribution of this message, or the > > > > taking of any action based on it, is strictly prohibited. > > > > > > > > ********************************************************* > > > > Visit us at http://www.mahindrabt.com > > > > > > > > > > > > > > > > > > > > ********************************************************* > > > > Disclaimer > > > > > > > > This message (including any attachments) contains confidential > > > > information intended for a specific individual and > purpose, and is > > > > protected by law. If you are not the intended recipient, you > > > > should delete this message and are hereby notified that any > > > > disclosure, copying, or distribution of this message, or the > > > > taking of any action based on it, is strictly prohibited. > > > > > > > > ********************************************************* > > > > Visit us at http://www.mahindrabt.com > > > > > > > > > _________________________________________________________________ > > > > Mobile, masti, magic! Cool ringtones & logos. > > > > http://www.msn.co.in/mobile/ Get noticed > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > > 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 > > > > Prabhas > +++++++++++++ > CSEL Technology Enterprise Programme > London Business School > Baker Street, London NW1 6DD > ***************************************** > There is no wisdom greater than kindness. > ***************************************** > _______________________________________________ > 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 > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jun 2 06:18:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00563 for ; Mon, 2 Jun 2003 06:18:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h52AHr431854 for sipping-archive@odin.ietf.org; Mon, 2 Jun 2003 06:17:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52AHrB31851 for ; Mon, 2 Jun 2003 06:17: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 GAA00549 for ; Mon, 2 Jun 2003 06:17:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MmMF-0001aj-00 for sipping-web-archive@ietf.org; Mon, 02 Jun 2003 06:16:03 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MmME-0001ag-00 for sipping-web-archive@ietf.org; Mon, 02 Jun 2003 06:16:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52ADvB31724; Mon, 2 Jun 2003 06:13:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52AD0B31674 for ; Mon, 2 Jun 2003 06: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 GAA00497 for ; Mon, 2 Jun 2003 06:12:53 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MmHV-0001a0-00 for sipping@ietf.org; Mon, 02 Jun 2003 06:11:09 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19MmHU-0001Zx-00 for sipping@ietf.org; Mon, 02 Jun 2003 06:11:09 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h52ACnD17383 for ; Mon, 2 Jun 2003 13:12:49 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 2 Jun 2003 13:12:48 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 2 Jun 2003 13:12:48 +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" Subject: RE: [Sipping] Security and privacy in Date: Mon, 2 Jun 2003 13:12:47 +0300 Message-ID: Thread-Topic: [Sipping] Security and privacy in Thread-Index: AcMo3uQJFFvN8T9JR+e3ElIK/AI1SQADqQSQ To: , , , , , X-OriginalArrivalTime: 02 Jun 2003 10:12:48.0766 (UTC) FILETIME=[84D9B1E0:01C328EF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h52AD0B31675 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Henry, What you are requesting falls more in the area of SIMPLE data manipulation and XCAP work, see: http://www.ietf.org/internet-drafts/draft-ietf-simple-data-req-02.txt (especially requirements in Chapter 5), and http://www.ietf.org/internet-drafts/draft-rosenberg-simple-xcap-00.txt It is true that there is still work to be done on how to actually address tuples and other parts of the PIDF/RPIDS documents in the authorization policy definitions. I guess this would be part of the "what is tuple" discussion in SIMPLE mailing list. Markus > -----Original Message----- > From: ext Henry Sinnreich [mailto:Henry.Sinnreich@mci.com] > Sent: 28 May, 2003 00:13 > To: Henning Schulzrinne; pkzivat@cisco.com; vkg@lucent.com; > jdrosen@dynamicsoft.com; sipping@ietf.org > Subject: [Sipping] Security and privacy in > > > > The I-D provides excellent rich > presence information, but should expand on the required specifics for > matching security and privacy protection. > > Section 9, Security Considerations says > > "Compared to PIDF, this presence document format reveals additional > information that can be highly sensitive. Beyond traditional security > measures to protect confidentiality and integrity, systems > should offer > a means to selectively reveal information to particular > watchers and to > inspect the information that is being published, particularly if it is > generated automatically from other sources, such as calendars or > sensors." > > I believe expanding on this and providing some criteria to > differentiate > between types of watchers, with detailed examples would fill the gap. > > Thanks, Henry > > Henry Sinnreich > MCI > 400 International Parkway > Richardson, Texas 75081 > USA > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jun 2 09:37:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06828 for ; Mon, 2 Jun 2003 09:37:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h52DaoT13707 for sipping-archive@odin.ietf.org; Mon, 2 Jun 2003 09:36:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52DaoB13704 for ; Mon, 2 Jun 2003 09:36: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 JAA06813 for ; Mon, 2 Jun 2003 09:36:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MpSm-00033T-00 for sipping-web-archive@ietf.org; Mon, 02 Jun 2003 09:35:00 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MpSm-00033P-00 for sipping-web-archive@ietf.org; Mon, 02 Jun 2003 09:35:00 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52DZjB13646; Mon, 2 Jun 2003 09:35:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52DY2B13591 for ; Mon, 2 Jun 2003 09:34: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 JAA06759 for ; Mon, 2 Jun 2003 09:33:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MpQ5-00032f-00 for sipping@ietf.org; Mon, 02 Jun 2003 09:32:13 -0400 Received: from mailgate.siemenscomms.co.uk ([194.129.217.115]) by ietf-mx with esmtp (Exim 4.12) id 19MpQ4-00032V-00 for sipping@ietf.org; Mon, 02 Jun 2003 09:32:12 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #45905) id <0HFU00C01WA00X@siemenscomms.co.uk> for sipping@ietf.org; Mon, 02 Jun 2003 14:32:33 +0100 (BST) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #45905) with ESMTP id <0HFU00BCKW6GWB@siemenscomms.co.uk> for sipping@ietf.org; Mon, 02 Jun 2003 14:30:16 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Mon, 02 Jun 2003 14:30:54 +0100 Content-return: allowed Date: Mon, 02 Jun 2003 14:31:14 +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: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Subject: [Sipping] Tunnelling QSIG over 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 I am exploring ways of tunnelling QSIG over SIP making use of the MIME type already defined for this purpose. One scenario of interest involves significant QSIG traffic between a given pair of gateways, and to support this efficiently a single SIP dialog is used to transport multiple QSIG calls. The dialog would be established on a semi-permanent basis and QSIG calls would be established and released on demand over this dialog. The main difficulty is the fact that each QSIG call will require a pair of RTP streams and therefore call establishment or call clearing will require an update to the session description (by means of UPDATE or re-INVITE). The question is how to represent the session, which at any instant will comprise n pairs of RTP streams, and relate these streams to QSIG channels. A possible solution is to use multiple m= (typically m=audio) lines, where the first m= line corresponds to channel 1, the second to channel 2, etc. The last m= line would correspond to the highest numbered QSIG channel in use. Any unused channels within the range would be marked as inactive (a=inactive). This convention would need to be understood only by the gateways concerned. I would welcome any comments on this proposal, or any alternative solutions. John Elwell (john.elwell@siemens.com) _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jun 2 17:24:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24707 for ; Mon, 2 Jun 2003 17:24:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h52LNko24272 for sipping-archive@odin.ietf.org; Mon, 2 Jun 2003 17:23:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52LNkB24269 for ; Mon, 2 Jun 2003 17:23: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 RAA24688 for ; Mon, 2 Jun 2003 17:23:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Mwke-0006ct-00 for sipping-web-archive@ietf.org; Mon, 02 Jun 2003 17:21:56 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Mwke-0006cq-00 for sipping-web-archive@ietf.org; Mon, 02 Jun 2003 17:21:56 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52LMbB24165; Mon, 2 Jun 2003 17:22:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52LL5B24044 for ; Mon, 2 Jun 2003 17: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 RAA24589 for ; Mon, 2 Jun 2003 17:21:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Mwi3-0006ah-00 for sipping@ietf.org; Mon, 02 Jun 2003 17:19:15 -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 19Mwi2-0006aI-00 for sipping@ietf.org; Mon, 02 Jun 2003 17:19:14 -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 h52LKR6n003028 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 2 Jun 2003 16:20:28 -0500 From: "Dean Willis" To: "'Shane McCormack'" , Date: Mon, 2 Jun 2003 16:20:13 -0500 Message-ID: <04d201c3294c$c35385b0$ee036e3f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [Sipping] RE: [Sip] Number of registered UAs Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sahne asked: > HI all, > > Is it possible to calculate how many UA's a particular user > in the network has either through registration details or otherwise? > > Regards > Shane Depends on what you mean by "the network". The general answer is "no", and is akin to trying to calculate the number of physical addresses that a person might have based on the sounds made by a cricket during last week's thunderstorm ,i.e., not causal in any way I understand the term. But assuming you mean "registering with a specific domain", then one MIGHT be able to tell based on several factors, potentially including the registrations (and duraction and content thereof) observed for a particular Address-of-Record. I would like to suggest that perhaps this list, and the SIP list, are not the right place to ask very basic questions about SIP. The sip-implementors list is probably the place to go, although I'm beginning to wonder if we don't need a fourth list for FAQ-type discussions. Anybody want to volunteer to maintain a really big FAQ? -- Dean _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jun 3 07:53:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28009 for ; Tue, 3 Jun 2003 07:53:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53Bqvh04883 for sipping-archive@odin.ietf.org; Tue, 3 Jun 2003 07:52:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53BqvB04880 for ; Tue, 3 Jun 2003 07:52: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 HAA27988 for ; Tue, 3 Jun 2003 07:52:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NAJn-0004Gb-00 for sipping-web-archive@ietf.org; Tue, 03 Jun 2003 07:51:08 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NAJn-0004GY-00 for sipping-web-archive@ietf.org; Tue, 03 Jun 2003 07:51:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53Bq3B04786; Tue, 3 Jun 2003 07:52:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53BlpB04500 for ; Tue, 3 Jun 2003 07:47:51 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27533; Tue, 3 Jun 2003 07:47:49 -0400 (EDT) Message-Id: <200306031147.HAA27533@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 03 Jun 2003 07:47:49 -0400 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-aaa-req-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 : Authentication, Authorization and Accounting Requirements for the Session Initiation Protocol Author(s) : J. Loughney, G. Camarillo Filename : draft-ietf-sipping-aaa-req-03.txt Pages : 14 Date : 2003-6-2 As SIP services are deployed on the Internet, there is a need for authentication, authorization and accounting of SIP sessions. This document sets out the basic requirements for this work. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-aaa-req-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-aaa-req-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-aaa-req-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-6-2145745.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-aaa-req-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-aaa-req-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-2145745.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jun 3 09:18:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03448 for ; Tue, 3 Jun 2003 09:18:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53DI3l13204 for sipping-archive@odin.ietf.org; Tue, 3 Jun 2003 09:18:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53DI3B13201 for ; Tue, 3 Jun 2003 09:18:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03435 for ; Tue, 3 Jun 2003 09:17:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NBe8-0005r9-00 for sipping-web-archive@ietf.org; Tue, 03 Jun 2003 09:16:12 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NBe7-0005r6-00 for sipping-web-archive@ietf.org; Tue, 03 Jun 2003 09:16:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53DDjB12866; Tue, 3 Jun 2003 09:13:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53DC2B12787 for ; Tue, 3 Jun 2003 09: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 JAA03238 for ; Tue, 3 Jun 2003 09:11:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NBYJ-0005nn-00 for sipping@ietf.org; Tue, 03 Jun 2003 09:10:11 -0400 Received: from oe-mp2pub.managedmail.com ([206.46.164.23] helo=oe-mp2.bizmailsrvcs.net) by ietf-mx with esmtp (Exim 4.12) id 19NBYI-0005nj-00 for sipping@ietf.org; Tue, 03 Jun 2003 09:10:10 -0400 Received: from SRINI ([24.225.150.136]) by oe-mp2.bizmailsrvcs.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP id <20030603131123.DMIX28782.oe-mp2.bizmailsrvcs.net@SRINI>; Tue, 3 Jun 2003 08:11:23 -0500 From: "Srini Guda" To: "'simon issa'" , Subject: RE: [Sipping] Simple Date: Tue, 3 Jun 2003 09:12:50 -0400 Message-ID: <001b01c329d1$d5a6d4d0$0463a8c0@SRINI> 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.4522.1200 Importance: Normal In-Reply-To: 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 Simon You might want to look at the GNU oSIP Library. http://www.fsf.org/software/osip/ Srini -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of simon issa Sent: Saturday, May 31, 2003 7:49 AM To: sipping@ietf.org Subject: [Sipping] Simple Dear Sirs, As a BS telecommunication senior I have my project based on SIP/SIMPLE and I would like to ask some questions. To your knowledge , is there any SIMPLE library , because I need SIMPLE library in my project not all the SIP library. To your knowledge also , is there a good descriptive sip library , describing the use and the goal of the functions, also theirs arguments , is there any examples (programs) of the use of that library ? any help would be appreciated. Thanks in advance . Regards. _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jun 3 15:32:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21512 for ; Tue, 3 Jun 2003 15:32:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53JVcI20716 for sipping-archive@odin.ietf.org; Tue, 3 Jun 2003 15:31:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53JVcB20713 for ; Tue, 3 Jun 2003 15:31: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 PAA21486 for ; Tue, 3 Jun 2003 15:31:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NHTg-000202-00 for sipping-web-archive@ietf.org; Tue, 03 Jun 2003 15:29:48 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NHTf-0001zy-00 for sipping-web-archive@ietf.org; Tue, 03 Jun 2003 15:29:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53JQrB20484; Tue, 3 Jun 2003 15:26:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53JM9B20212 for ; Tue, 3 Jun 2003 15:22:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21292 for ; Tue, 3 Jun 2003 15:22:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NHKV-0001wL-00 for sipping@ietf.org; Tue, 03 Jun 2003 15:20:19 -0400 Received: from vmmrnat.verisignmail.com ([216.168.230.187] helo=vmmr8.verisignmail.com) by ietf-mx with esmtp (Exim 4.12) id 19NHKV-0001wH-00 for sipping@ietf.org; Tue, 03 Jun 2003 15:20:19 -0400 Received: from ms5.verisignmail.com (ms5.verisignmail.com [216.168.230.178] (may be forged)) by vmmr8.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id AMD29572; Tue, 3 Jun 2003 15:22:05 -0400 (EDT) Received: from ms5.verisignmail.com (localhost.verisignmail.com [127.0.0.1]) by ms5.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id AIA85957; Tue, 3 Jun 2003 15:22:05 -0400 (EDT) Message-Id: <200306031922.AIA85957@ms5.verisignmail.com> Received: from 198.151.13.8 by ms5.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with HTTP/1.1; Tue, 3 Jun 2003 14:22:05 -0500 Date: Tue, 3 Jun 2003 14:22:05 -0500 From: John Galgay To: sipping@ietf.org X-Mailer: Webmail Mirapoint Direct 3.2.2-GA MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] (no subject) Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit unsubscribe toseam jgalgay@jjg-enterprises.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jun 4 02:07:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15417 for ; Wed, 4 Jun 2003 02:07:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5466aT04768 for sipping-archive@odin.ietf.org; Wed, 4 Jun 2003 02:06:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5466aB04753 for ; Wed, 4 Jun 2003 02:06: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 CAA14889 for ; Wed, 4 Jun 2003 02:06:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NRO6-0006Kf-00 for sipping-web-archive@ietf.org; Wed, 04 Jun 2003 02:04:42 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NRO5-0006Kc-00 for sipping-web-archive@ietf.org; Wed, 04 Jun 2003 02:04:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5463jB01788; Wed, 4 Jun 2003 02:03:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54627B01554 for ; Wed, 4 Jun 2003 02:02: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 CAA10318 for ; Wed, 4 Jun 2003 02:02:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NRJl-0006IF-00 for sipping@ietf.org; Wed, 04 Jun 2003 02:00:13 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19NRJk-0006Hv-00 for sipping@ietf.org; Wed, 04 Jun 2003 02:00:12 -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 h5461Njc009882; Tue, 3 Jun 2003 23:01:24 -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 AHT56120; Tue, 3 Jun 2003 22:57:10 -0700 (PDT) Date: Tue, 3 Jun 2003 14:18:25 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: rohan@cisco.com, alan.johnston@wcom.com, "'sipping@ietf.org'" To: "'Jonathan Rosenberg'" From: Rohan Mahy Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Sipping] proposed enhancement 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 Hi, There have been many requests for the dialog package to express the concept of hold. The problem is that nobody had an especially good definition of what "on-hold" meant. Some suggested that all media streams being inactive implied that you are "held", but this doesn't work for a service such as music-on-hold. I believe that folks actually want a slightly different concept--that the semantics we want instead are already described in the call control framework: > Participants may also be active or passive. Active participants are > expected to be intelligent enough to leave a conversation space when > they no longer desire to participate. (An attentive human participant > is obviously active.) Some robotic participants (such as a voice > messaging system, an instant messaging agent, or a voice dialog > system) may be active participants if they can leave the conversation > space when there is no human interaction. Other robots (for example > our tone generating robot from the previous example) are passive > participants. A human participant "on-hold" is passive. I think we should add a new attribute to the dialog package that expresses this property. My proposal is to express this property only for the local side of each dialog by adding an attribute to the state tag in the dialog-info notification body. The example below includes a proposed (optional) participation attribute in the state tag. confirmed Participation status could change during a session without otherwise changing the state of the call. confirmed this proposal would of course require a small addition to the XML schema to support the new attribute: comments welcome. thanks, -rohan _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jun 4 02:12:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19643 for ; Wed, 4 Jun 2003 02:12:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h546BiL10536 for sipping-archive@odin.ietf.org; Wed, 4 Jun 2003 02:11:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h546BiB10533 for ; Wed, 4 Jun 2003 02:11: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 CAA19559 for ; Wed, 4 Jun 2003 02:11:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NRT4-0006Nh-00 for sipping-web-archive@ietf.org; Wed, 04 Jun 2003 02:09:50 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NRT3-0006Ne-00 for sipping-web-archive@ietf.org; Wed, 04 Jun 2003 02:09:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54667B04403; Wed, 4 Jun 2003 02:06:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54635B01732 for ; Wed, 4 Jun 2003 02: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 CAA11349 for ; Wed, 4 Jun 2003 02:03:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NRKi-0006Il-00 for sipping@ietf.org; Wed, 04 Jun 2003 02:01:12 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by ietf-mx with esmtp (Exim 4.12) id 19NRKh-0006IO-00 for sipping@ietf.org; Wed, 04 Jun 2003 02:01:11 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h5462SI2028491; Tue, 3 Jun 2003 23:02:29 -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 AHT56157; Tue, 3 Jun 2003 22:57:43 -0700 (PDT) Date: Tue, 3 Jun 2003 14:37:05 -0700 Subject: Re: [Sipping] Tunnelling QSIG over SIP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'sipping@ietf.org'" To: "Elwell, John" From: Rohan Mahy In-Reply-To: Message-Id: <8558F7A5-960B-11D7-AAC4-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, June 2, 2003, at 06:31 AM, Elwell, John wrote: > I am exploring ways of tunnelling QSIG over SIP making use of the MIME > type > already defined for this purpose. One scenario of interest involves > significant QSIG traffic between a given pair of gateways, and to > support > this efficiently a single SIP dialog is used to transport multiple QSIG > calls. The dialog would be established on a semi-permanent basis and > QSIG > calls would be established and released on demand over this dialog. > > The main difficulty is the fact that each QSIG call will require a > pair of > RTP streams and therefore call establishment or call clearing will > require > an update to the session description (by means of UPDATE or > re-INVITE). The > question is how to represent the session, which at any instant will > comprise > n pairs of RTP streams, and relate these streams to QSIG channels. A > possible solution is to use multiple m= (typically m=audio) lines, > where the > first m= line corresponds to channel 1, the second to channel 2, etc. > The > last m= line would correspond to the highest numbered QSIG channel in > use. rather than using specific m-lines, you could use the flow, group, and media-stream id concepts defined here: draft-ietf-mmusic-fid-0?.txt (i'm on an airplane) thx, -r > Any unused channels within the range would be marked as inactive > (a=inactive). This convention would need to be understood only by the > gateways concerned. > > I would welcome any comments on this proposal, or any alternative > solutions. > > John Elwell (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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jun 4 02:14:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19869 for ; Wed, 4 Jun 2003 02:14:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h546Drh13258 for sipping-archive@odin.ietf.org; Wed, 4 Jun 2003 02:13:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h546DrB13255 for ; Wed, 4 Jun 2003 02:13: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 CAA19814 for ; Wed, 4 Jun 2003 02:13:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NRV9-0006PE-00 for sipping-web-archive@ietf.org; Wed, 04 Jun 2003 02:11:59 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NRV8-0006PB-00 for sipping-web-archive@ietf.org; Wed, 04 Jun 2003 02:11:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5467vB06495; Wed, 4 Jun 2003 02:07:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5463RB01778 for ; Wed, 4 Jun 2003 02:03: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 CAA11712 for ; Wed, 4 Jun 2003 02:03:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NRL3-0006Ir-00 for sipping@ietf.org; Wed, 04 Jun 2003 02:01:33 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19NRL2-0006Ii-00 for sipping@ietf.org; Wed, 04 Jun 2003 02:01:32 -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 h5462kOo004456; Tue, 3 Jun 2003 23:02:46 -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 AHT56200; Tue, 3 Jun 2003 22:58:44 -0700 (PDT) Date: Tue, 3 Jun 2003 14:51:58 -0700 Subject: Re: [Sipping] Bug report: sipping-service-example-04 Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "sipping@ietf.org" To: y01317@njupt.edu.cn From: Rohan Mahy In-Reply-To: Message-Id: <99CF54EC-960D-11D7-AAC4-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, May 28, 2003, at 07:57 AM, FengZhang wrote: > Hi all, > > I think this is an error: > > In section 2.17 Automatic Redial, the message F4 SUBSCRIBE is : > > F4 SUBSCRIBE Alice -> Bob > > SUBSCRIBE sip:bob@biloxi.example.com SIP/2.0 > Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 > Max-Forwards: 70 > From: Alice ;tag=837348234 > To: Bob > Call-ID: 4524526232@atlanta.example.com > CSeq: 1 SUBSCRIBE > Contact: alice@client.atlanta.example.com > Event: dialog > Subscription-State: active;expires=3600 > Accept: application/dialog-info+xml > Content-Length: 0 > > > I think the "Subscription-State" header is unwanted. correct. good catch. Subscription-State only belongs in NOTIFY requests. > BTW, I think this call flow should add another two messages: NOTIFY > & 200 OK , these two messages can tell that the subscription which > created by Alice is terminated. Maybe like this way: Bob has no way to know that Alice wants the subscription to terminate early. Instead, Alice should unsubscribe. Then Bob will inform Alice that the subscription is over. thanks, -rohan > Alice Bob > | | > | INVITE F1 | > |--------------->| > |486 Busy Here F2| > |<---------------| Bob is busy > | ACK F3 | > |--------------->| > | SUBSCRIBE F4 | > |--------------->| > | 200 OK F5 | > |<---------------| > | NOTIFY F6 | > |<---------------| > | 200 OK F7 | > |--------------->| > | | > | NOTIFY F8 | Bob is now available > |<---------------| > | 200 OK F9 | > |--------------->| > | | SUBSCRIBE -> <- 200 OK > |<--NOTIFY-------| <------- here should we add these two > messages? > |---- 200 OK --->| > | | > | INVITE F10 | > |--------------->| Session setup successfully > | 180 Ringing F11| > |<---------------| > | 200 OK F12 | > |<---------------| > | ACK F13 | > |--------------->| > | Media Session | > |<==============>| > | | > > Regards. > > $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!(BFengZhang > $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!(By01317@njupt.edu.cn > $B!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!(B2003-05-28 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jun 4 02:16:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20875 for ; Wed, 4 Jun 2003 02:16:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h546FiM13663 for sipping-archive@odin.ietf.org; Wed, 4 Jun 2003 02:15:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h546FiB13660 for ; Wed, 4 Jun 2003 02:15: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 CAA20490 for ; Wed, 4 Jun 2003 02:15:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NRWw-0006Q6-00 for sipping-web-archive@ietf.org; Wed, 04 Jun 2003 02:13:50 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NRWw-0006Q3-00 for sipping-web-archive@ietf.org; Wed, 04 Jun 2003 02:13:50 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5469nB07576; Wed, 4 Jun 2003 02:09:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5463vB01791 for ; Wed, 4 Jun 2003 02:03: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 CAA12248 for ; Wed, 4 Jun 2003 02:03:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NRLX-0006J4-00 for sipping@ietf.org; Wed, 04 Jun 2003 02:02:03 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19NRLW-0006Io-00 for sipping@ietf.org; Wed, 04 Jun 2003 02:02:02 -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 h5461SOo003633; Tue, 3 Jun 2003 23:01: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.3-GR) with ESMTP id AHT56148; Tue, 3 Jun 2003 22:57:37 -0700 (PDT) Date: Tue, 3 Jun 2003 14:30:46 -0700 Subject: Re: [Sipping] SIP and TCP transport.... Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Sarkar, Uttam" , "'sipping@ietf.org'" To: Jonathan Rosenberg From: Rohan Mahy In-Reply-To: <3ED843E4.1000408@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 Sarkar, On Friday, May 30, 2003, at 10:55 PM, Jonathan Rosenberg wrote: > Sarkar, Uttam wrote: >> Hi All, >> I have posted this messgage to the sip-implementors list. There might >> have >> been a discussion already regarding this. >> When transport is TCP, do you keep the socket connection open till >> the call >> is active or you close the socket once party A and party B are >> connected. > > The specification only requires that you keep a connection open until > there have been 64*T1 seconds of inactivity. However, genreally > speaking it is good to keep the connections open for as long as you > have resources, since they could potentially be reused down the road. > >> When you get BYE or other sip Message from either end, then you open >> new >> socket connection to the other side to send that request. I would >> appreciate >> your inputs. > > Generally there is a separate connection used for requests in each > direction. > see also the connection reuse draft for a proposal to allow sharing connections in both directions. draft-ietf-sipping-connect-reuse-reqs-00.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 mailnull@www1.ietf.org Wed Jun 4 02:17:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22101 for ; Wed, 4 Jun 2003 02:17:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h546HK213801 for sipping-archive@odin.ietf.org; Wed, 4 Jun 2003 02:17:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h546HJB13796 for ; Wed, 4 Jun 2003 02:17: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 CAA21736 for ; Wed, 4 Jun 2003 02:17:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NRYQ-0006Qo-00 for sipping-web-archive@ietf.org; Wed, 04 Jun 2003 02:15:22 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NRYP-0006Qk-00 for sipping-web-archive@ietf.org; Wed, 04 Jun 2003 02:15:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h546BdB10509; Wed, 4 Jun 2003 02:11:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5465QB02436 for ; Wed, 4 Jun 2003 02:05: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 CAA13824 for ; Wed, 4 Jun 2003 02:05:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NRMy-0006Jh-00 for sipping@ietf.org; Wed, 04 Jun 2003 02:03:33 -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 19NRMy-0006Jd-00 for sipping@ietf.org; Wed, 04 Jun 2003 02:03:32 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h5465I0J025694; Wed, 4 Jun 2003 08:05:18 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 4 Jun 2003 08:06:17 +0200 Message-ID: From: "Gonzalo Camarillo Gonzalez (LMF)" To: "'sipping@ietf.org'" Cc: "Dean Willis (E-mail)" , "Rohan Mahy (E-mail)" Date: Wed, 4 Jun 2003 08:05:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] SIPPING Archives Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Folks, FYI: after having some problems with the SIPPING archives, they should be up and running again now. Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jun 4 03:03:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06027 for ; Wed, 4 Jun 2003 03:03:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5473IO17958 for sipping-archive@odin.ietf.org; Wed, 4 Jun 2003 03:03:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5473IB17955 for ; Wed, 4 Jun 2003 03: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 DAA06021 for ; Wed, 4 Jun 2003 03:03:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NSGx-00072V-00 for sipping-web-archive@ietf.org; Wed, 04 Jun 2003 03:01:23 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NSGw-00072S-00 for sipping-web-archive@ietf.org; Wed, 04 Jun 2003 03:01:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5470TB17811; Wed, 4 Jun 2003 03:00:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h546xuB17757 for ; Wed, 4 Jun 2003 02:59:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05929 for ; Wed, 4 Jun 2003 02:59:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NSDh-00070c-00 for sipping@ietf.org; Wed, 04 Jun 2003 02:58:01 -0400 Received: from krr.debis.hu ([195.228.20.2] helo=ns.t-systems.co.hu) by ietf-mx with esmtp (Exim 4.12) id 19NSDg-00070Z-00 for sipping@ietf.org; Wed, 04 Jun 2003 02:58:00 -0400 Received: from MAILSRV.uns.t-systems.tss ([172.16.1.64]) by ns.t-systems.co.hu (8.9.3p2/8.9.3/Debian 8.9.3-21) with ESMTP id JAA02740; Wed, 4 Jun 2003 09:33:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] proposed enhancement to dialog package Date: Wed, 4 Jun 2003 08:59:38 +0200 Message-ID: <29026DD9543DBF4BB2B4F9325683E47A0D5B8E@MAILSRV.uns.t-systems.tss> Thread-Topic: [Sipping] proposed enhancement to dialog package Thread-Index: AcMqYQD0ZEM1toOzSQ+y1dYUORWG4wAAhZYQ From: =?iso-8859-1?Q?Szel=E9nyi_Csaba?= To: "Rohan Mahy" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h546xuB17758 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, | | There have been many requests for the dialog package to express the | concept of hold. The problem is that nobody had an especially good | definition of what "on-hold" meant. Some suggested that all media | streams being inactive implied that you are "held", but this doesn't | work for a service such as music-on-hold. ..... | | I think we should add a new attribute to the dialog package that | expresses this property. My proposal is to express this | property only | for the local side of each dialog by adding an attribute to | the state | tag in the dialog-info notification body. The example below IMHO the 'hold' and 'music-on-hold' functionalities are the same: 'hold' delivers 'silence' type of music. So the hold functionality should be implemented in a way, that the streams transport something different then the recorded media: music or silence. From philosophical view: the hold functions (simple hold and music-on-hold) should be additions to the normal protocol, i.e. this type of functions should be marked with extra header (the two types with one, the name could be 'hold'), and the normal behavior should not be marked with anything. (This way also the earlier implementations could work further.) Your suggestion has a philosophy like there were two types of operations: normal and hold. I don't think this is the philosophy of hold functionalities in traditional telephony. Csaba _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jun 4 07:13:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11412 for ; Wed, 4 Jun 2003 07:13:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54BCvw05007 for sipping-archive@odin.ietf.org; Wed, 4 Jun 2003 07:12:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54BCvB05004 for ; Wed, 4 Jun 2003 07:12: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 HAA11407 for ; Wed, 4 Jun 2003 07:12:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NWAc-0000gf-00 for sipping-web-archive@ietf.org; Wed, 04 Jun 2003 07:11:06 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NWAc-0000gc-00 for sipping-web-archive@ietf.org; Wed, 04 Jun 2003 07:11:06 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54B9gB04855; Wed, 4 Jun 2003 07:09:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54B86B04724 for ; Wed, 4 Jun 2003 07:08: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 HAA11234 for ; Wed, 4 Jun 2003 07:07:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NW5q-0000e8-00 for sipping@ietf.org; Wed, 04 Jun 2003 07:06:11 -0400 Received: from mailgate.siemenscomms.co.uk ([194.129.217.115]) by ietf-mx with esmtp (Exim 4.12) id 19NW5q-0000dZ-00 for sipping@ietf.org; Wed, 04 Jun 2003 07:06:10 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #45905) id <0HFY00J01EVFOM@siemenscomms.co.uk> for sipping@ietf.org; Wed, 04 Jun 2003 12:06:51 +0100 (BST) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #45905) with ESMTP id <0HFY00J8DEVFIY@siemenscomms.co.uk>; Wed, 04 Jun 2003 12:06:51 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Wed, 04 Jun 2003 12:07:28 +0100 Content-return: allowed Date: Wed, 04 Jun 2003 12:07:51 +0100 From: "Elwell, John" Subject: RE: [Sipping] Tunnelling QSIG over SIP To: "'Rohan Mahy'" Cc: "'sipping@ietf.org'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk 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, Thanks for this information. The draft concerned has now become RFC3388. The grouping defined there is applicable only to streams requiring lip synch and flow identification. The latter is explicitly not intended for parallel encoding. However, the MID (Media Identification) attribute may be a way of associating a media stream with a QSIG channel, rather than relying on the order of m= lines. This would also eliminate the need to keep m= lines for channels that are no longer in use, and therefore the number of m= lines would always equal the number of active QSIG channels. John Elwell (john.elwell@siemens.com) > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: 03 June 2003 22:37 > To: Elwell, John > Cc: 'sipping@ietf.org' > Subject: Re: [Sipping] Tunnelling QSIG over SIP > > > > On Monday, June 2, 2003, at 06:31 AM, Elwell, John wrote: > > > I am exploring ways of tunnelling QSIG over SIP making use > of the MIME > > type > > already defined for this purpose. One scenario of interest involves > > significant QSIG traffic between a given pair of gateways, and to > > support > > this efficiently a single SIP dialog is used to transport > multiple QSIG > > calls. The dialog would be established on a semi-permanent > basis and > > QSIG > > calls would be established and released on demand over this dialog. > > > > The main difficulty is the fact that each QSIG call will require a > > pair of > > RTP streams and therefore call establishment or call clearing will > > require > > an update to the session description (by means of UPDATE or > > re-INVITE). The > > question is how to represent the session, which at any instant will > > comprise > > n pairs of RTP streams, and relate these streams to QSIG channels. A > > possible solution is to use multiple m= (typically m=audio) lines, > > where the > > first m= line corresponds to channel 1, the second to > channel 2, etc. > > The > > last m= line would correspond to the highest numbered QSIG > channel in > > use. > > rather than using specific m-lines, you could use the flow, > group, and > media-stream id concepts defined here: > > draft-ietf-mmusic-fid-0?.txt (i'm on an airplane) > > thx, > -r > > > Any unused channels within the range would be marked as inactive > > (a=inactive). This convention would need to be understood > only by the > > gateways concerned. > > > > I would welcome any comments on this proposal, or any alternative > > solutions. > > > > John Elwell (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 > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jun 4 10:14:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21799 for ; Wed, 4 Jun 2003 10:14:46 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54EELr19236 for sipping-archive@odin.ietf.org; Wed, 4 Jun 2003 10:14:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54EELB19233 for ; Wed, 4 Jun 2003 10:14: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 KAA21743 for ; Wed, 4 Jun 2003 10:14:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NZ07-0003BR-00 for sipping-web-archive@ietf.org; Wed, 04 Jun 2003 10:12:27 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NZ06-0003BO-00 for sipping-web-archive@ietf.org; Wed, 04 Jun 2003 10:12:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54E6oB17913; Wed, 4 Jun 2003 10:06:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54E5SB17829 for ; Wed, 4 Jun 2003 10:05: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 KAA20652 for ; Wed, 4 Jun 2003 10:05:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NYrW-00035Y-00 for sipping@ietf.org; Wed, 04 Jun 2003 10:03:34 -0400 Received: from terra.polito.it ([130.192.3.81] helo=polito.it) by ietf-mx with esmtp (Exim 4.12) id 19NYrV-00035V-00 for sipping@ietf.org; Wed, 04 Jun 2003 10:03:33 -0400 Received: from [130.192.1.125] (account d004316 HELO polito.it) by polito.it (CommuniGate Pro SMTP 4.1b7) with ESMTP-TLS id 7991499; Wed, 04 Jun 2003 15:58:27 +0200 Message-ID: <3EDDFBC4.5000701@polito.it> Date: Wed, 04 Jun 2003 16:01:40 +0200 From: Marco Aime User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202 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] questions on SIP and AKA Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk 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'm wondering about implications of selecting AKA as the preferred (or unique?) strong authentication method for SIP messages AKA is defined with a precise authentication model in mind, the one currently used in mobile telephony networks: - the "Home Domain" delegates the "Visited Domain" for User authentication (this require the network domain to be completely trusted). AKA add network authentication... - no data privacy nor integrity is achieved between User and the "Home Domain". AKA could change this... Is this the current model for SIP authentication? AKA can derive session keys (CK and IK): between whom? -if between the User and the "Home Domain" (like in TS 24.228) we could get in troubles with scenarios with hierarchical registration (how authenticate local REGISTERs?) - if between User and "Visited Domain" we are in the traditional authentication model and we loose User-to-"Home Domain" privacy/integrity AKA does not seem particularly fit for multi-layer authentication models (User-to-"Home Domain", "Visited Domain"-"Home Domain", User-"Visted Domain"), at least I was not able to find some references... (as it sounds rigth) the recent draft-ietf-sipping-aaa-req-03.txt does not define any trust model among User "Home Domain" and "Visited Domain": selecting AKA is going to do it? Am I missing something? thanks in advance bye Marco -- ------------------------------------------------------------------ Marco AIME Dipartimento di Automatica e Informatica Politecnico di Torino Addr: Via Cardinal Massaia 83, Torino, Italy Tel: +39 011 22102-44 Fax: +39 011 22102-29 Mail: m.aime@polito.it (marcodomenico.aime@polito.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 mailnull@www1.ietf.org Wed Jun 4 10:39:31 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 KAA23741 for ; Wed, 4 Jun 2003 10:39:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54Ed7b21919 for sipping-archive@odin.ietf.org; Wed, 4 Jun 2003 10:39:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54Ed7B21916 for ; Wed, 4 Jun 2003 10:39: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 KAA23708 for ; Wed, 4 Jun 2003 10:39:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NZO3-0003aS-00 for sipping-web-archive@ietf.org; Wed, 04 Jun 2003 10:37:12 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NZO3-0003aP-00 for sipping-web-archive@ietf.org; Wed, 04 Jun 2003 10:37:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54EWQB20380; Wed, 4 Jun 2003 10:32:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54EVaB20268 for ; Wed, 4 Jun 2003 10:31: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 KAA22747 for ; Wed, 4 Jun 2003 10:31:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NZGn-0003LQ-00 for sipping@ietf.org; Wed, 04 Jun 2003 10:29:41 -0400 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 19NZGm-0003LN-00 for sipping@ietf.org; Wed, 04 Jun 2003 10:29:40 -0400 Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id F263E6A902; Wed, 4 Jun 2003 17:31:28 +0300 (EEST) Message-ID: <3EDE025A.4070903@piuha.net> Date: Wed, 04 Jun 2003 17:29:46 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marco Aime Cc: sipping@ietf.org Subject: Re: [Sipping] questions on SIP and AKA References: <3EDDFBC4.5000701@polito.it> In-Reply-To: <3EDDFBC4.5000701@polito.it> 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 Marco Aime wrote: > I'm wondering about implications of selecting AKA as the preferred (or > unique?) strong authentication method for SIP messages I don't think any IETF document has claimed specific preference for the use of Digest AKA against other potential mechanisms. AKA is most useful when you have existing SIM cards in your device and when your security model matches what can be arranged with it. And quite clearly, the amount of protection offered solely by Digest is very minimal, so typically Digest AKA would be used in connection with other mechanisms. So, depending on what you want to do, you may wish to employ AKA with say TLS, or you might want to employ TLS only in a SIP trapezoid model, or you might do TLS and S/MIME. --Jari _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jun 4 12:32:36 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 MAA29975 for ; Wed, 4 Jun 2003 12:32:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54GWBT31878 for sipping-archive@odin.ietf.org; Wed, 4 Jun 2003 12:32:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54GWAB31875 for ; Wed, 4 Jun 2003 12: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 MAA29945 for ; Wed, 4 Jun 2003 12:32:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nb9W-0005Hi-00 for sipping-web-archive@ietf.org; Wed, 04 Jun 2003 12:30:18 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Nb9V-0005Hf-00 for sipping-web-archive@ietf.org; Wed, 04 Jun 2003 12:30:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54GPYB31615; Wed, 4 Jun 2003 12:25:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54GMsB31469 for ; Wed, 4 Jun 2003 12:22: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 MAA29630 for ; Wed, 4 Jun 2003 12:22:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nb0X-0005Bc-00 for sipping@ietf.org; Wed, 04 Jun 2003 12:21:01 -0400 Received: from terra.polito.it ([130.192.3.81] helo=polito.it) by ietf-mx with esmtp (Exim 4.12) id 19Nb0X-0005BZ-00 for sipping@ietf.org; Wed, 04 Jun 2003 12:21:01 -0400 Received: from [130.192.1.125] (HELO polito.it) by polito.it (CommuniGate Pro SMTP 4.1b7) with ESMTP-TLS id 7996961; Wed, 04 Jun 2003 18:15:55 +0200 Message-ID: <3EDE1C01.6060702@polito.it> Date: Wed, 04 Jun 2003 18:19:13 +0200 From: Marco Aime User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jari.arkko@piuha.net CC: sipping@ietf.org Subject: Re: [Sipping] questions on SIP and AKA References: <3EDDFBC4.5000701@polito.it> <3EDE025A.4070903@piuha.net> In-Reply-To: <3EDE025A.4070903@piuha.net> 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 Jari Arkko wrote: > Marco Aime wrote: > >> I'm wondering about implications of selecting AKA as the preferred (or >> unique?) strong authentication method for SIP messages > > > I don't think any IETF document has claimed specific preference > for the use of Digest AKA against other potential mechanisms. AKA is > most useful when you have existing SIM cards in your device and when > your security model matches what can be arranged with it. right, what I meant was wether the WG has investigated (or is invetigating) how the currently available authentication mechanisms for SIP impact authentication/authorization models among Users, Home Domains, etc... > And quite clearly, the amount of protection offered solely > by Digest is very minimal, so typically Digest AKA would > be used in connection with other mechanisms. > > So, depending on what you want to do, you may wish to > employ AKA with say TLS, or you might want to employ > TLS only in a SIP trapezoid model, or you might do TLS > and S/MIME. right, but TLS, as well as ipsec, can provide for hop-by-hop security features: (not assuming a PKI) you need, at least, to integrate them with AAA to get an authentication/authorization model (as with the ongoing work in other IETF WGs): is it correct? for what concern S/MIME, I was just pointing at authentication/authorization schema based on S/MIME-like mechanisms: is there (or the was) some investigation on this topic? thanks bye marco > > --Jari > > > > > -- ------------------------------------------------------------------ Marco AIME Dipartimento di Automatica e Informatica Politecnico di Torino Addr: Via Cardinal Massaia 83, Torino, Italy Tel: +39 011 22102-44 Fax: +39 011 22102-29 Mail: m.aime@polito.it (marcodomenico.aime@polito.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 mailnull@www1.ietf.org Thu Jun 5 00:53:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25441 for ; Thu, 5 Jun 2003 00:53:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h554qhQ19054 for sipping-archive@odin.ietf.org; Thu, 5 Jun 2003 00:52:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h554qgB19051 for ; Thu, 5 Jun 2003 00:52: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 AAA25434 for ; Thu, 5 Jun 2003 00:52:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nmi8-0002ua-00 for sipping-web-archive@ietf.org; Thu, 05 Jun 2003 00:50:48 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Nmi8-0002uW-00 for sipping-web-archive@ietf.org; Thu, 05 Jun 2003 00:50:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h554o2B18936; Thu, 5 Jun 2003 00:50:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h554hRB18749 for ; Thu, 5 Jun 2003 00:43: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 AAA25333; Thu, 5 Jun 2003 00:43:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NmZB-0002st-00; Thu, 05 Jun 2003 00:41:33 -0400 Received: from law12-f89.law12.hotmail.com ([64.4.19.89] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19NmZA-0002se-00; Thu, 05 Jun 2003 00:41:33 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 4 Jun 2003 21:42:53 -0700 Received: from 193.220.224.9 by lw12fd.law12.hotmail.msn.com with HTTP; Thu, 05 Jun 2003 04:42:53 GMT X-Originating-IP: [193.220.224.9] X-Originating-Email: [rajarshi_chakraborty@hotmail.com] From: "Rajarshi Chakraborty" To: sip@ietf.org, sipping@ietf.org Date: Thu, 05 Jun 2003 04:42:53 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 05 Jun 2003 04:42:53.0590 (UTC) FILETIME=[ED3ECB60:01C32B1C] Subject: [Sipping] reference to papers on SIP mobility Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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, Would any sort of discussion on mobility using SIP, in reference to external papers, be appreciated in the SIP or SIPPING group? By external, I mean papers which are not simply IETF drafts n RFCs, but those maintained in sites like Telcordia, universities, etc. regards Rajarshi Rajarshi Chakraborty B-196, IIT Campus, Kharagpur, West Bengal, India PIN-721302 _________________________________________________________________ Staying fit. It's about being happy! http://server1.msn.co.in/features/stayingfit/index.asp Check out the new mantra. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jun 5 07:54:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16695 for ; Thu, 5 Jun 2003 07:54:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55BsFA27404 for sipping-archive@odin.ietf.org; Thu, 5 Jun 2003 07:54:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55BsFB27401 for ; Thu, 5 Jun 2003 07:54: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 HAA16683 for ; Thu, 5 Jun 2003 07:54:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NtI5-0005Ef-00 for sipping-web-archive@ietf.org; Thu, 05 Jun 2003 07:52:21 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NtI4-0005Ec-00 for sipping-web-archive@ietf.org; Thu, 05 Jun 2003 07:52:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55BpWB27322; Thu, 5 Jun 2003 07:51:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55BmCB27077 for ; Thu, 5 Jun 2003 07: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 HAA16511 for ; Thu, 5 Jun 2003 07:48:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NtCF-0005DF-00 for sipping@ietf.org; Thu, 05 Jun 2003 07:46:19 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19NtCE-0005DC-00 for sipping@ietf.org; Thu, 05 Jun 2003 07:46:18 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h55Bmjbj018328; Thu, 5 Jun 2003 13:48:45 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 5 Jun 2003 13:49:10 +0200 Message-ID: From: "Gonzalo Camarillo Gonzalez (LMF)" To: "'Elwell, John'" , "'Rohan Mahy'" Cc: "'sipping@ietf.org'" Subject: RE: [Sipping] Tunnelling QSIG over SIP Date: Thu, 5 Jun 2003 13:47:44 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens.com] Sent: Wednesday, June 04, 2003 2:08 PM To: 'Rohan Mahy' Cc: 'sipping@ietf.org' Subject: RE: [Sipping] Tunnelling QSIG over SIP John, >Thanks for this information. The draft concerned has now become RFC3388. The >grouping defined there is applicable only to streams requiring lip synch and >flow identification. The latter is explicitly not intended for parallel >encoding. > >However, the MID (Media Identification) attribute may be a way of >associating a media stream with a QSIG channel, rather than relying on the >order of m= lines. This would also eliminate the need to keep m= lines for >channels that are no longer in use, and therefore the number of m= lines >would always equal the number of active QSIG channels. The grouping framework defined in RFC 3388 allows you to group any number of m lines for any purpose you want to define. However, if you want to change how the offer/answer model works, using mid attributes to map media lines rather than their position in their SDP, you will have to define a new option tag (for Require). Otherwise, user agents that did not support this extension would become confused pretty soon (e.g-, after the first re-INVITE). Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jun 5 12:29:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05457 for ; Thu, 5 Jun 2003 12:28:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55GSXD19269 for sipping-archive@odin.ietf.org; Thu, 5 Jun 2003 12:28:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55GSXB19266 for ; Thu, 5 Jun 2003 12:28: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 MAA05452 for ; Thu, 5 Jun 2003 12:28:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NxZW-0000sa-00 for sipping-web-archive@ietf.org; Thu, 05 Jun 2003 12:26:38 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NxZW-0000sX-00 for sipping-web-archive@ietf.org; Thu, 05 Jun 2003 12:26:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55GPnB19147; Thu, 5 Jun 2003 12:25:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55GOMB19050 for ; Thu, 5 Jun 2003 12:24: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 MAA05367 for ; Thu, 5 Jun 2003 12:24:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NxVT-0000rB-00 for sipping@ietf.org; Thu, 05 Jun 2003 12:22:27 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19NxVS-0000qw-00 for sipping@ietf.org; Thu, 05 Jun 2003 12:22:26 -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 h55GNlOo007295; Thu, 5 Jun 2003 09:23:47 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHV06395; Thu, 5 Jun 2003 09:19:45 -0700 (PDT) Date: Thu, 5 Jun 2003 09:24:33 -0700 Subject: Re: [Sipping] Tunnelling QSIG over SIP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'Elwell, John'" , "'sipping@ietf.org'" To: "Gonzalo Camarillo Gonzalez (LMF)" From: Rohan Mahy In-Reply-To: Message-Id: <30DDF566-9772-11D7-9B0B-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, June 5, 2003, at 04:47 AM, Gonzalo Camarillo Gonzalez (LMF) wrote: > > > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Wednesday, June 04, 2003 2:08 PM > To: 'Rohan Mahy' > Cc: 'sipping@ietf.org' > Subject: RE: [Sipping] Tunnelling QSIG over SIP > John, > >> Thanks for this information. The draft concerned has now become >> RFC3388. The >> grouping defined there is applicable only to streams requiring lip >> synch and >> flow identification. The latter is explicitly not intended for >> parallel >> encoding. >> >> However, the MID (Media Identification) attribute may be a way of >> associating a media stream with a QSIG channel, rather than relying >> on the >> order of m= lines. This would also eliminate the need to keep m= >> lines for >> channels that are no longer in use, and therefore the number of m= >> lines >> would always equal the number of active QSIG channels. > > The grouping framework defined in RFC 3388 allows you to group any > number of m lines for any purpose you want to define. However, if you > want to change how the offer/answer model works, using mid attributes > to map media lines rather than their position in their SDP, you will > have to define a new option tag (for Require). Otherwise, user agents > that did not support this extension would become confused pretty soon > (e.g-, after the first re-INVITE). Alternatively if you wanted to maintain backward compatibility, you could leave unused m-lines in the session description but set to a=inactive: and with no mid/fid. thanks, -rohan _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jun 5 20:51:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23900 for ; Thu, 5 Jun 2003 20:51:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h560op526601 for sipping-archive@odin.ietf.org; Thu, 5 Jun 2003 20:50:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h560opB26598 for ; Thu, 5 Jun 2003 20:50: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 UAA23897 for ; Thu, 5 Jun 2003 20:50:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19O5Pb-00051b-00 for sipping-web-archive@ietf.org; Thu, 05 Jun 2003 20:48:55 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19O5Pa-00051Y-00 for sipping-web-archive@ietf.org; Thu, 05 Jun 2003 20:48:54 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h560lhB26530; Thu, 5 Jun 2003 20:47:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h560jdB26473 for ; Thu, 5 Jun 2003 20:45: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 UAA23842 for ; Thu, 5 Jun 2003 20:45:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19O5KZ-0004zx-00 for sipping@ietf.org; Thu, 05 Jun 2003 20:43:43 -0400 Received: from mail26c.sbc-webhosting.com ([216.173.237.166]) by ietf-mx with smtp (Exim 4.12) id 19O5KY-0004zu-00 for sipping@ietf.org; Thu, 05 Jun 2003 20:43:43 -0400 Received: from www.tamura-broad.com (64.143.38.143) by mail26c.sbc-webhosting.com (RS ver 1.0.80vs) with SMTP id 4-096963324; Thu, 5 Jun 2003 20:45:25 -0400 (EDT) Reply-To: From: "Victor A Paulsamy" To: "sipping" Cc: Date: Thu, 5 Jun 2003 17:45:16 -0700 Organization: Tamura Corp Message-ID: <004d01c32bc4$e64f7fe0$4cfea8c0@victorpc> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Loop-Detect: 1 Content-Transfer-Encoding: 7bit Subject: [Sipping] Conference-id 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: 7bit Content-Transfer-Encoding: 7bit Is there any proposal, from with in conference design team and/or otherwise, for "Conference-id: header" in SIP messages? If yes, can it be cited in other works? Thanks in advance. Regards, --victor _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jun 5 22:53:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26257 for ; Thu, 5 Jun 2003 22:53:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h562qgf01987 for sipping-archive@odin.ietf.org; Thu, 5 Jun 2003 22:52:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h562qgB01984 for ; Thu, 5 Jun 2003 22:52: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 WAA26254 for ; Thu, 5 Jun 2003 22:52:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19O7JU-0005cN-00 for sipping-web-archive@ietf.org; Thu, 05 Jun 2003 22:50:44 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19O7JT-0005cK-00 for sipping-web-archive@ietf.org; Thu, 05 Jun 2003 22:50:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h562naB01864; Thu, 5 Jun 2003 22:49:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h562mGB01810 for ; Thu, 5 Jun 2003 22:48: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 WAA26192; Thu, 5 Jun 2003 22:48:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19O7FB-0005aQ-00; Thu, 05 Jun 2003 22:46:18 -0400 Received: from [208.236.67.14] (helo=gateway.hns.com) by ietf-mx with esmtp (Exim 4.12) id 19O7FB-0005aM-00; Thu, 05 Jun 2003 22:46:17 -0400 Received: from excore8.hns.com (excore8.hns.com [139.85.52.156]) by gateway.hns.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h562m2eY004103; Thu, 5 Jun 2003 22:48:03 -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 h562lvie021184; Thu, 5 Jun 2003 22:47:57 -0400 (EDT) To: Cc: "sipping" , sipping-admin@ietf.org, victor@tamura-broad.com Subject: Re: [Sipping] Conference-id header? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Arjun Roychowdhury" Date: Thu, 5 Jun 2003 22:47:54 -0400 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.12 |February 13, 2003) at 06/05/2003 10:45:59 PM, Serialize complete at 06/05/2003 10:45:59 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: , Victor, doesn't the conference-uri as defined in framework-00.txt server the purpose of the conference-id you are looking for ? Or do you require something else ? (http://www.ietf.org/internet-drafts/draft-ietf-sipping-conferencing-framework-00.txt) To my knowledge, its been suggested that URIs would be used to uniquely identify conference instances. regds arjun -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301 212 7860 "Victor A Paulsamy" Sent by: sipping-admin@ietf.org 06/05/2003 08:45 PM Please respond to victor To: "sipping" cc: Subject: [Sipping] Conference-id header? Is there any proposal, from with in conference design team and/or otherwise, for "Conference-id: header" in SIP messages? If yes, can it be cited in other works? Thanks in advance. Regards, --victor _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jun 6 02:34:36 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 CAA11992 for ; Fri, 6 Jun 2003 02:34:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h566YBq26520 for sipping-archive@odin.ietf.org; Fri, 6 Jun 2003 02:34:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h566YAB26517 for ; Fri, 6 Jun 2003 02:34: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 CAA11980 for ; Fri, 6 Jun 2003 02:34:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OAlo-0006rT-00 for sipping-web-archive@ietf.org; Fri, 06 Jun 2003 02:32:12 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OAlo-0006rP-00 for sipping-web-archive@ietf.org; Fri, 06 Jun 2003 02:32:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h566VCB26456; Fri, 6 Jun 2003 02:31:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h566TiB26298 for ; Fri, 6 Jun 2003 02:29: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 CAA11910 for ; Fri, 6 Jun 2003 02:29:39 -0400 (EDT) From: victor@tamura-broad.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OAhW-0006Yo-00 for sipping@ietf.org; Fri, 06 Jun 2003 02:27:46 -0400 Received: from mail26a.sbc-webhosting.com ([216.173.237.164]) by ietf-mx with smtp (Exim 4.12) id 19OAhV-0006Yh-00 for sipping@ietf.org; Fri, 06 Jun 2003 02:27:45 -0400 Received: from mmm2625.sbc-webhosting.com (216.173.237.75) by mail26a.sbc-webhosting.com (RS ver 1.0.80vs) with SMTP id 0-033104965; Fri, 6 Jun 2003 02:29:25 -0400 (EDT) Received: (tamura@localhost) by localhost (8.11.6) id h566TPx64164; Fri, 6 Jun 2003 06:29:25 GMT Message-Id: <200306060629.h566TPx64164@mmm2625.sbc-webhosting.com> X-Authentication-Warning: mmm2625.sbc-webhosting.com: tamura set sender to victor@tamura-broad.com using -f Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 To: aroychow@hns.com, sipping@ietf.org, sipping-admin@ietf.org, victor@tamura-broad.com, victor@tamura-broad.com Cc: victor@tamura-broad.com Subject: RE: Re: [Sipping] Conference-id header? Date: Fri, 6 Jun 2003 02:29:24 -0400 X-Mailer: AutoBahn Webmail X-Originating-Ip: 68.134.168.157 X-Loop-Detect: 1 Content-Transfer-Encoding: 8bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Arjun, >doesn't the conference-uri as defined in >framework-00.txt server the >purpose of the conference-id you are looking for ? >Or do you require >something else ? Not the URI; but Conference-id header. This is required for identifying a specific conference that's set up on the spur of the moment; full-mesh, for instance. Regards, --victor _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jun 6 04:41:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14179 for ; Fri, 6 Jun 2003 04:41:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h568fQh03744 for sipping-archive@odin.ietf.org; Fri, 6 Jun 2003 04:41:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h568fQB03741 for ; Fri, 6 Jun 2003 04:41: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 EAA14170 for ; Fri, 6 Jun 2003 04:41:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OCl0-0007Pk-00 for sipping-web-archive@ietf.org; Fri, 06 Jun 2003 04:39:30 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OCl0-0007Ph-00 for sipping-web-archive@ietf.org; Fri, 06 Jun 2003 04:39:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h568cjB03569; Fri, 6 Jun 2003 04:38:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h568ZOB02534 for ; Fri, 6 Jun 2003 04:35: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 EAA14061 for ; Fri, 6 Jun 2003 04:35:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OCfA-0007Nk-00 for sipping@ietf.org; Fri, 06 Jun 2003 04:33:28 -0400 Received: from relay2.clb.oleane.net ([213.56.31.22]) by ietf-mx with esmtp (Exim 4.12) id 19OCf9-0007Na-00 for sipping@ietf.org; Fri, 06 Jun 2003 04:33:27 -0400 Received: from oleane ([194.250.212.114]) by relay2.clb.oleane.net with SMTP id h568YZlK015995 for ; Fri, 6 Jun 2003 10:34:49 +0200 Message-ID: <009101c32c07$2bd553e0$0601a8c0@oleane.com> From: "Peter Lewis" To: Date: Fri, 6 Jun 2003 10:38:53 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0076_01C32C17.D3050F60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [Sipping] International SIP 2004, January 20-23, Paris France Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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_0076_01C32C17.D3050F60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 International SIP 2004, January 20-23, Paris France After a setback in 2002 over 2001, explained by the difficult economic = context plaguing the telecom industry, International SIP 2003 clearly = recaptured the interest of the VoIP community.=20 Don't miss the 2004 edition. The call for papers dead line has been extended to June 15. Please get all details at: http://www.upperside.fr/sip2004/sip2004cfp.htm ------=_NextPart_000_0076_01C32C17.D3050F60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
International SIP 2004, January 20-23, Paris=20 France
 
After a setback in 2002 over 2001, explained by the = difficult=20 economic context plaguing the telecom industry, International SIP 2003 = clearly=20 recaptured the interest of the VoIP community.
Don't miss the 2004=20 edition.
 
The call for papers dead line has been extended to = June=20 15.
Please get all details at:
http://www.uppers= ide.fr/sip2004/sip2004cfp.htm
 
------=_NextPart_000_0076_01C32C17.D3050F60-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jun 6 08:26:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19650 for ; Fri, 6 Jun 2003 08:26:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56CPaY18549 for sipping-archive@odin.ietf.org; Fri, 6 Jun 2003 08:25:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56CPZB18546 for ; Fri, 6 Jun 2003 08:25: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 IAA19641 for ; Fri, 6 Jun 2003 08:25:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OGFv-00017y-00 for sipping-web-archive@ietf.org; Fri, 06 Jun 2003 08:23:39 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OGFv-00017v-00 for sipping-web-archive@ietf.org; Fri, 06 Jun 2003 08:23:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56CMZB18451; Fri, 6 Jun 2003 08:22:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56CKvB18370 for ; Fri, 6 Jun 2003 08:20: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 IAA19376; Fri, 6 Jun 2003 08:20:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OGBR-000124-00; Fri, 06 Jun 2003 08:19:01 -0400 Received: from [208.236.67.14] (helo=gateway.hns.com) by ietf-mx with esmtp (Exim 4.12) id 19OGBQ-00011i-00; Fri, 06 Jun 2003 08:19:00 -0400 Received: from excore8.hns.com (excore8.hns.com [139.85.52.156]) by gateway.hns.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h56CKleY019930; Fri, 6 Jun 2003 08:20:48 -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 h56CKfie026891; Fri, 6 Jun 2003 08:20:41 -0400 (EDT) To: victor@tamura-broad.com Cc: sipping@ietf.org, sipping-admin@ietf.org, victor@tamura-broad.com Subject: RE: Re: [Sipping] Conference-id header? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Arjun Roychowdhury" Date: Fri, 6 Jun 2003 08:20:36 -0400 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.12 |February 13, 2003) at 06/06/2003 08:18:43 AM, Serialize complete at 06/06/2003 08:18:43 AM Content-Type: multipart/alternative; boundary="=_alternative 0043CC0585256D3D_=" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 multipart message in MIME format. --=_alternative 0043CC0585256D3D_= Content-Type: text/plain; charset="us-ascii" Aha-ok, I forgot the 'full-mesh' part. Almost all of the sipping discussion so far has been for centrally hosted conferences. For centrally hosted conferences, even if they are adhoc - the conf-uri is the unique identifier. I am not aware of any such SIP header, but I would assume some line in the SDP could be used for the same ? Again, guess its not a standardized whay. Since any endpoint can send an INVITE to any other ep in a full mesh ,there is no guarantee that any 'identifying' attributes in one leg will be retained across in the other leg. regds arjun -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301 212 7860 victor@tamura-broad.com Sent by: sipping-admin@ietf.org 06/06/2003 02:29 AM To: aroychow@hns.com, sipping@ietf.org, sipping-admin@ietf.org, victor@tamura-broad.com, victor@tamura-broad.com cc: victor@tamura-broad.com Subject: RE: Re: [Sipping] Conference-id header? Arjun, >doesn't the conference-uri as defined in >framework-00.txt server the >purpose of the conference-id you are looking for ? >Or do you require >something else ? Not the URI; but Conference-id header. This is required for identifying a specific conference that's set up on the spur of the moment; full-mesh, for instance. Regards, --victor _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --=_alternative 0043CC0585256D3D_= Content-Type: text/html; charset="us-ascii"
Aha-ok,
I forgot the 'full-mesh' part. Almost all of the sipping discussion so far has been for centrally hosted conferences.
For centrally hosted conferences, even if they are adhoc - the conf-uri is the unique identifier.

I am not aware of any such SIP header, but I would assume some line in the SDP could be used for the same ? Again, guess
its not a standardized whay. Since any endpoint can send an INVITE to any other ep in a full mesh ,there is no guarantee that
any 'identifying' attributes in one leg will be retained across in the other leg.

regds
arjun

--
Arjun Roychowdhury @ Hughes Software Systems
11717 Exploration Lane, Germantown MD 20876
(O): 301 212 7860  


victor@tamura-broad.com
Sent by: sipping-admin@ietf.org

06/06/2003 02:29 AM

       
        To:        aroychow@hns.com, sipping@ietf.org, sipping-admin@ietf.org, victor@tamura-broad.com, victor@tamura-broad.com
        cc:        victor@tamura-broad.com
        Subject:        RE: Re: [Sipping] Conference-id header?



Arjun,

>doesn't the conference-uri as defined in
>framework-00.txt server the
>purpose of the conference-id you are looking for ?
>Or do you require
>something else ?

Not the URI; but Conference-id header.

This is required for identifying a specific conference that's set up on the spur of the moment; full-mesh, for instance.

Regards,

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

--=_alternative 0043CC0585256D3D_=-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jun 6 12:51:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02143 for ; Fri, 6 Jun 2003 12:51:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56Gp1n09256 for sipping-archive@odin.ietf.org; Fri, 6 Jun 2003 12:51:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56Gp1B09253 for ; Fri, 6 Jun 2003 12:51: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 MAA02073 for ; Fri, 6 Jun 2003 12:50:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OKOm-00044D-00 for sipping-web-archive@ietf.org; Fri, 06 Jun 2003 12:49:04 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OKOl-000447-00 for sipping-web-archive@ietf.org; Fri, 06 Jun 2003 12:49:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56GibB08976; Fri, 6 Jun 2003 12:44:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56GfDB08847 for ; Fri, 6 Jun 2003 12:41: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 MAA01820 for ; Fri, 6 Jun 2003 12:41:09 -0400 (EDT) From: victor@tamura-broad.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OKFI-0003zl-00 for sipping@ietf.org; Fri, 06 Jun 2003 12:39:17 -0400 Received: from mail26a.sbc-webhosting.com ([216.173.237.164]) by ietf-mx with smtp (Exim 4.12) id 19OKFG-0003zg-00 for sipping@ietf.org; Fri, 06 Jun 2003 12:39:15 -0400 Received: from mmm2625.sbc-webhosting.com (216.173.237.75) by mail26a.sbc-webhosting.com (RS ver 1.0.80vs) with SMTP id 1-0805127661; Fri, 6 Jun 2003 12:41:02 -0400 (EDT) Received: (tamura@localhost) by localhost (8.11.6) id h56Gf2v18190; Fri, 6 Jun 2003 16:41:02 GMT Message-Id: <200306061641.h56Gf2v18190@mmm2625.sbc-webhosting.com> X-Authentication-Warning: mmm2625.sbc-webhosting.com: tamura set sender to victor@tamura-broad.com using -f Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 To: aroychow@hns.com, sipping@ietf.org, sipping-admin@ietf.org, victor@tamura-broad.com, victor@tamura-broad.com Subject: RE: RE: Re: [Sipping] Conference-id header? Date: Fri, 6 Jun 2003 12:41:01 -0400 X-Mailer: AutoBahn Webmail X-Originating-Ip: 68.134.168.171 X-Loop-Detect: 1 Content-Transfer-Encoding: 8bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit >----- ------- Original Message ------- ----- >From: aroychow@hns.com >To: victor@tamura-broad.com >Sent: Fri, 6 Jun 2003 08:20:36 > >Aha-ok, >I forgot the 'full-mesh' part. Almost all of the >sipping discussion so far >has been for centrally hosted conferences. >For centrally hosted conferences, even if they are >adhoc - the conf-uri is >the unique identifier. > >I am not aware of any such SIP header, but I would >assume some line in the >SDP could be used for the same ? Again, guess If available information is used to compose an id, it's an easy guess for an attacker who intercepts the transaction. On the other hand, even if it is computed in the fashion that other globally unique headers are, the attacker can still get hold of it! >its not a standardized whay. Since any endpoint can >send an INVITE to any >other ep in a full mesh ,there is no guarantee that > >any 'identifying' attributes in one leg will be >retained across in the >other leg. > It has to be mandated in a full-mesh conferencing. Regards, --victor _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jun 6 13:12:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02698 for ; Fri, 6 Jun 2003 13:12:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56HBcu11099 for sipping-archive@odin.ietf.org; Fri, 6 Jun 2003 13:11:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56HBcB11096 for ; Fri, 6 Jun 2003 13:11: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 NAA02684 for ; Fri, 6 Jun 2003 13:11:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OKii-0004FB-00 for sipping-web-archive@ietf.org; Fri, 06 Jun 2003 13:09:40 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OKih-0004F8-00 for sipping-web-archive@ietf.org; Fri, 06 Jun 2003 13:09:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56H62B09932; Fri, 6 Jun 2003 13:06:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56H3LB09802 for ; Fri, 6 Jun 2003 13:03: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 NAA02481; Fri, 6 Jun 2003 13:03:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OKai-0004B9-00; Fri, 06 Jun 2003 13:01:24 -0400 Received: from gateway.hns.com ([208.236.67.13]) by ietf-mx with esmtp (Exim 4.12) id 19OKag-0004B5-00; Fri, 06 Jun 2003 13:01:23 -0400 Received: from excore8.hns.com (excore8.hns.com [139.85.52.126]) by gateway.hns.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h56H39eY028976; Fri, 6 Jun 2003 13:03:09 -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 h56H2xig022857; Fri, 6 Jun 2003 13:03:02 -0400 (EDT) To: victor@tamura-broad.com Cc: sipping@ietf.org, sipping-admin@ietf.org, victor@tamura-broad.com Subject: RE: RE: Re: [Sipping] Conference-id header? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Arjun Roychowdhury" Date: Fri, 6 Jun 2003 13:03:01 -0400 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.12 |February 13, 2003) at 06/06/2003 01:01:04 PM, Serialize complete at 06/06/2003 01:01:04 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: , - If available information is used to compose an id, it's an easy guess for an attacker who intercepts the transaction. On the other hand, even if it is computed in the fashion that other globally unique headers are, the attacker can still get hold of it! ARC> I feel we are mixing two things here. 'Computing' or 'intercepting' a conference-ID should have nothing to do with being able to attack an existing conference. To me, being able to 'get' a conference ID simply tells you that a conference is being hosted here. It does not necessarily allow you to enter one. Since this is IP, any attacker can intercept any-thing unless the message is encrypted end-end (and ofcourse, even if its end-end, with significant more difficulty). For example, an attacker can intercept the Call-ID/CS/From/To value of a message flowing across. That does not imply he can barge into a call. Whether he can or not depends on the network security implemented. Also, typically conferences URI _may_ have a variable entity to it - ie a portion of the URI _may_ be computed as a fn(time,pid,eth0-id), for example. What that means is for a particular conference in a domain hss.hns.com, the first conference may have the URI 232423sscvdxsdfsdfdsf@conf.hss.hns.com and the next one may have sdvbvw254545@conf.hss.hns.com where the 'user' part is not using static data, which makes guessing a little more challenging. How you generate a conference URI that handles a conference is not specifically defined - it just needs to be routable. You can add your own algorithmic inputs to it to make it more dynamic based. I would expect authorization to be a separate entity -> irrespective of the fact that as person has managed to intercept a conf-id, that user should be authenticated with as strong an authentication scheme as appropriate in the designated network. With respect to your comment of mandating a conference-id for a full-mesh conference, Ill leave it to the experts here to comment on that -> Ive never thought much into full-mesh scenarios. regds arjun _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jun 6 16:14:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10933 for ; Fri, 6 Jun 2003 16:14:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56KDwx26062 for sipping-archive@odin.ietf.org; Fri, 6 Jun 2003 16:13:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56KDwB26059 for ; Fri, 6 Jun 2003 16:13: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 QAA10924 for ; Fri, 6 Jun 2003 16:13:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ONZ9-000634-00 for sipping-web-archive@ietf.org; Fri, 06 Jun 2003 16:11:59 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ONZ9-00062z-00 for sipping-web-archive@ietf.org; Fri, 06 Jun 2003 16:11:59 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56K6tB24869; Fri, 6 Jun 2003 16:06:55 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56K4dB24714 for ; Fri, 6 Jun 2003 16:04: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 QAA10443 for ; Fri, 6 Jun 2003 16:04:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ONQ9-0005v6-00 for sipping@ietf.org; Fri, 06 Jun 2003 16:02:41 -0400 Received: from mail26b.sbc-webhosting.com ([216.173.237.165]) by ietf-mx with smtp (Exim 4.12) id 19ONQ7-0005v0-00 for sipping@ietf.org; Fri, 06 Jun 2003 16:02:40 -0400 Received: from www.tamura-broad.com (64.143.38.143) by mail26b.sbc-webhosting.com (RS ver 1.0.80vs) with SMTP id 4-0157289864; Fri, 6 Jun 2003 16:04:25 -0400 (EDT) Reply-To: From: "Victor A Paulsamy" To: "'Arjun Roychowdhury'" Cc: , Subject: RE: RE: Re: [Sipping] Conference-id header? Date: Fri, 6 Jun 2003 13:04:15 -0700 Organization: Tamura Corp Message-ID: <000b01c32c66$cf2f5d60$4cfea8c0@victorpc> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal X-Loop-Detect: 1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h56K4dB24718 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Arjun, Thanks for the thoughts, inline ... -----Original Message----- >From: Arjun Roychowdhury [mailto:aroychow@hns.com] >ARC> I feel we are mixing two things here. 'Computing' or 'intercepting' a >conference-ID should >have nothing to do with being able to attack an existing conference. >To me, being able to 'get' a conference ID simply tells you that a >conference is being hosted here. >It does not necessarily allow you to enter one. A full-mesh conferencing starts off with a simple two party call. Consider that UAC is inviting a new user or the new user contacts UAC. The UAC grants the new user a conference membership by choosing a conference id and passing it over to the new one along with UAS's AOR. Since the new one gained a membership, it sends the UAS (assume that it know this id by some means) a request to join the conference that contains this id. The UAS can infer, from the id, that the new one is a member of the conference and this request cannot be declined (to set up a full-mesh). Otherwise, it's up to the UAS to grant it a membership. Hence, a conference-id, indeed, allows one to enter a specific conference, in full-mesh. Unlike, a conference-uri, it's non-routable (it doesn't deduce to any particular UA). This is the right thing, because every one has to establish a dialog with every one else (no central controller). >With respect to your comment of mandating a conference-id for a full-mesh >conference, Ill leave it to the experts >here to comment on that -> Ive never thought much into full-mesh >scenarios. For the aforementioned reason, it has to be mandated. Regards, --victor _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jun 6 16:50:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12308 for ; Fri, 6 Jun 2003 16:50:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56KoOV28921 for sipping-archive@odin.ietf.org; Fri, 6 Jun 2003 16:50:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56KoNB28918 for ; Fri, 6 Jun 2003 16:50: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 QAA12281 for ; Fri, 6 Jun 2003 16:50:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OO8P-0006Mk-00 for sipping-web-archive@ietf.org; Fri, 06 Jun 2003 16:48:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OO8P-0006Mh-00 for sipping-web-archive@ietf.org; Fri, 06 Jun 2003 16:48:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56KjWB28630; Fri, 6 Jun 2003 16:45:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56KfUB28439 for ; Fri, 6 Jun 2003 16:41: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 QAA11766; Fri, 6 Jun 2003 16:41:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ONzo-0006HZ-00; Fri, 06 Jun 2003 16:39:32 -0400 Received: from gateway.hns.com ([208.236.67.13]) by ietf-mx with esmtp (Exim 4.12) id 19ONzn-0006HW-00; Fri, 06 Jun 2003 16:39:32 -0400 Received: from excore8.hns.com (excore8.hns.com [139.85.52.126]) by gateway.hns.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h56KfOeY002002; Fri, 6 Jun 2003 16:41:24 -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 h56KfIie008899; Fri, 6 Jun 2003 16:41:18 -0400 (EDT) To: Cc: sipping@ietf.org, sipping-admin@ietf.org Subject: RE: RE: Re: [Sipping] Conference-id header? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Arjun Roychowdhury" Date: Fri, 6 Jun 2003 16:41:15 -0400 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.12 |February 13, 2003) at 06/06/2003 04:39:20 PM, Serialize complete at 06/06/2003 04:39:20 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: , Victor, I think we are speaking past each other in some issues - I apologize if my mail was not clear (I have this problem often :-). With respect to the conference-ID, what I interpreted from the previous mail was that you were concerned that if a person got to know a conference identifier, he could enter any conference. What I suggested was that whether a user is _allowed_ to enter a given conference, does not necessarily have to depend _only_ on the ID being provided. Similar to regular SIP calls, if you are worried about authentication, you will not soley rely on conference-id being the only means of identification. Therefore, even if rogueA got the ID of a particular conference, his INVITE may be challenged by a participant who its sent to with this identification. The above does not really depend on whether a conference is meshed or centralized. For example, in the paper that Jonathan L. subsequenty posted (http://www1.cs.columbia.edu/~lennox/fullmesh.pdf), he has suggested a public key mechanism for the end-system (which either stays for one conference, or longer , as his footnote suggests). That to me is a better mechanism for user verification than trying to make the conf-uri non-traceable/guessable. Back to your original Q: I do agree, that one does need a unique conference-identifier, and no such standard method/header has been specified today. Now Ill shut up :-) regds arjun -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301 212 7860 "Victor A Paulsamy" 06/06/2003 04:04 PM Please respond to victor To: "'Arjun Roychowdhury'" cc: , Subject: RE: RE: Re: [Sipping] Conference-id header? Arjun, Thanks for the thoughts, inline ... -----Original Message----- >From: Arjun Roychowdhury [mailto:aroychow@hns.com] >ARC> I feel we are mixing two things here. 'Computing' or 'intercepting' a >conference-ID should >have nothing to do with being able to attack an existing conference. >To me, being able to 'get' a conference ID simply tells you that a >conference is being hosted here. >It does not necessarily allow you to enter one. A full-mesh conferencing starts off with a simple two party call. Consider that UAC is inviting a new user or the new user contacts UAC. The UAC grants the new user a conference membership by choosing a conference id and passing it over to the new one along with UAS's AOR. Since the new one gained a membership, it sends the UAS (assume that it know this id by some means) a request to join the conference that contains this id. The UAS can infer, from the id, that the new one is a member of the conference and this request cannot be declined (to set up a full-mesh). Otherwise, it's up to the UAS to grant it a membership. Hence, a conference-id, indeed, allows one to enter a specific conference, in full-mesh. Unlike, a conference-uri, it's non-routable (it doesn't deduce to any particular UA). This is the right thing, because every one has to establish a dialog with every one else (no central controller). >With respect to your comment of mandating a conference-id for a full-mesh >conference, Ill leave it to the experts >here to comment on that -> Ive never thought much into full-mesh >scenarios. For the aforementioned reason, it has to be mandated. Regards, --victor _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jun 6 17:49:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14913 for ; Fri, 6 Jun 2003 17:49:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56Ln7E01585 for sipping-archive@odin.ietf.org; Fri, 6 Jun 2003 17:49:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56Ln7B01582 for ; Fri, 6 Jun 2003 17:49: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 RAA14902 for ; Fri, 6 Jun 2003 17:49:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OP3D-0006wu-00 for sipping-web-archive@ietf.org; Fri, 06 Jun 2003 17:47:07 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OP3D-0006wr-00 for sipping-web-archive@ietf.org; Fri, 06 Jun 2003 17:47:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56LjuB01480; Fri, 6 Jun 2003 17:45:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56LiUB01413 for ; Fri, 6 Jun 2003 17:44: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 RAA14778 for ; Fri, 6 Jun 2003 17:44:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OOyl-0006vM-00 for sipping@ietf.org; Fri, 06 Jun 2003 17:42:31 -0400 Received: from mail26d.sbc-webhosting.com ([216.173.237.167]) by ietf-mx with smtp (Exim 4.12) id 19OOyj-0006vG-00 for sipping@ietf.org; Fri, 06 Jun 2003 17:42:29 -0400 Received: from www.tamura-broad.com (64.143.38.143) by mail26d.sbc-webhosting.com (RS ver 1.0.80vs) with SMTP id 0767735855; Fri, 6 Jun 2003 17:44:16 -0400 (EDT) Reply-To: From: "Victor A Paulsamy" To: "'Arjun Roychowdhury'" Cc: , Subject: RE: RE: Re: [Sipping] Conference-id header? Date: Fri, 6 Jun 2003 14:44:07 -0700 Organization: Tamura Corp Message-ID: <000c01c32c74$c241da70$4cfea8c0@victorpc> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal X-Loop-Detect: 1 Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >even if rogueA got the ID of a particular conference, his INVITE may be >challenged by a participant who its sent to with this identification. >The above does not really depend on whether a conference is meshed or >centralized. Agreed. >For example, in the paper that Jonathan L. subsequenty posted >(http://www1.cs.columbia.edu/~lennox/fullmesh.pdf), he has suggested >a public key mechanism for the end-system (which either stays for one >conference, or longer , as his footnote suggests). That to me >is a better mechanism for user verification than trying to make the >conf-uri non-traceable/guessable. Me too! And that's why I touched upon the problems of both guessable and non-guessable ids in one of the previous posts. Now, it's time for me to go! Regards, --victor _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jun 6 18:07:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15792 for ; Fri, 6 Jun 2003 18:07:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56M74P02443 for sipping-archive@odin.ietf.org; Fri, 6 Jun 2003 18:07:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56M74B02439 for ; Fri, 6 Jun 2003 18:07:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15712 for ; Fri, 6 Jun 2003 18:06:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OPKa-00072g-00 for sipping-web-archive@ietf.org; Fri, 06 Jun 2003 18:05:04 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OPKZ-00072d-00 for sipping-web-archive@ietf.org; Fri, 06 Jun 2003 18:05:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56M46B02213; Fri, 6 Jun 2003 18:04:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56M1vB02086 for ; Fri, 6 Jun 2003 18:01: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 SAA15227 for ; Fri, 6 Jun 2003 18:01:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OPFd-00071B-00 for sipping@ietf.org; Fri, 06 Jun 2003 17:59:57 -0400 Received: from mail26c.sbc-webhosting.com ([216.173.237.166]) by ietf-mx with smtp (Exim 4.12) id 19OPFc-000716-00 for sipping@ietf.org; Fri, 06 Jun 2003 17:59:56 -0400 Received: from www.tamura-broad.com (64.143.38.143) by mail26c.sbc-webhosting.com (RS ver 1.0.80vs) with SMTP id 0-0847656900; Fri, 6 Jun 2003 18:01:41 -0400 (EDT) Reply-To: From: "Victor A Paulsamy" To: "'Arjun Roychowdhury'" Cc: , Subject: RE: RE: Re: [Sipping] Conference-id header? Date: Fri, 6 Jun 2003 15:01:31 -0700 Organization: Tamura Corp Message-ID: <000d01c32c77$30ebdc80$4cfea8c0@victorpc> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal X-Loop-Detect: 1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h56M1vB02091 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit >suggested was that whether a user is _allowed_ >to enter a given conference, does not necessarily have to depend _only_ on >the ID being provided. Similar to regular SIP calls, What I tried to convey was that, in a full-mesh, the id suggests to the recipient that the sender is a party to the conference and hence, this request has to be acceded to, based on the results of authentication. Hope things are clear, now. Regards, --victor _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jun 6 19:33:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18490 for ; Fri, 6 Jun 2003 19:33:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56NWdm07877 for sipping-archive@odin.ietf.org; Fri, 6 Jun 2003 19:32:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56NWdB07874 for ; Fri, 6 Jun 2003 19:32: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 TAA18478 for ; Fri, 6 Jun 2003 19:32:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OQfS-0007aC-00 for sipping-web-archive@ietf.org; Fri, 06 Jun 2003 19:30:42 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OQfR-0007a9-00 for sipping-web-archive@ietf.org; Fri, 06 Jun 2003 19:30:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56NMYB07491; Fri, 6 Jun 2003 19:22:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56NLhB07430 for ; Fri, 6 Jun 2003 19:21: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 TAA18291 for ; Fri, 6 Jun 2003 19:21:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OQUs-0007Vl-00 for sipping@ietf.org; Fri, 06 Jun 2003 19:19:46 -0400 Received: from [65.200.90.207] (helo=mailserver.sylantro.com) by ietf-mx with smtp (Exim 4.12) id 19OQUr-0007VZ-00 for sipping@ietf.org; Fri, 06 Jun 2003 19:19:45 -0400 Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Fri, 06 Jun 2003 16:21:02 -0700 X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Received: by mailserver.sylantro.com with Internet Mail Service ( 5.5.2653.19) id ; Fri, 6 Jun 2003 16:21:02 -0700 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD023BCA82@mailserver.sylantro.com> From: "Venkatesh Venkataramanan" To: "'sipping@ietf.org'" Date: Fri, 6 Jun 2003 16:21:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 12FFFE5447361-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Call Pick Up call flow in the sipping-service-examples and The SI P Replaces 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: 7bit Content-Transfer-Encoding: 7bit Hi: Per section 2.16 of the http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-examples-04.t xt draft, call pick up is acheived by using a INVITE with Replaces header. An INVITE with Replaces header is also used for consultative transfers. A UA that receives the a INVITE with Replaces header attempts to match an existing dialog with details provided in the replaces header and if found accept the same, it then proceeds to tear down the existing dialog. However, the call flow for pick up presented in 2.16 is prone to race conditions which could produce undesirable end user behavior. Per the example in 2.16: 1. Alice calls Bob. Bob's phone is ringing. 2. Carol decides to pick the call. 3. Carol sends a SUBSCRIBE to Bob's dialog state. Bob's UA sends out a NOTIFY providing the dialog details. 4. Carol initiates a INVITE with Replaces header. However, between step 3 and step 4, it could so happen that Bob decided to pickup his phone to answer the call. The call is established and the two start talking..... Now the INVITE with Replaces (step 4) comes along. Alice's UA accepts this request, tears down the session with Bob and the call gets established with Carol. This produces undesirable results from a end user perspective. Would it be a good idea to extend the Replaces header to contain the dialog state based on the dialog state draft as well so that the recipient can compare the dialog identifiers AND the dialog state to decide whether to allow the same or not? regards, Venkatesh _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jun 6 20:53:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19855 for ; Fri, 6 Jun 2003 20:53:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h570qiU13168 for sipping-archive@odin.ietf.org; Fri, 6 Jun 2003 20:52:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h570qiB13165 for ; Fri, 6 Jun 2003 20:52: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 UAA19824 for ; Fri, 6 Jun 2003 20:52:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ORuv-0000C8-00 for sipping-web-archive@ietf.org; Fri, 06 Jun 2003 20:50:45 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ORuu-0000C5-00 for sipping-web-archive@ietf.org; Fri, 06 Jun 2003 20:50:44 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h570nRB13055; Fri, 6 Jun 2003 20:49:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h570m1B13015 for ; Fri, 6 Jun 2003 20:48: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 UAA19764 for ; Fri, 6 Jun 2003 20:47:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ORqM-0000AH-00 for sipping@ietf.org; Fri, 06 Jun 2003 20:46:02 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19ORqM-0000AE-00 for sipping@ietf.org; Fri, 06 Jun 2003 20:46:02 -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 h570lOjc009377; Fri, 6 Jun 2003 17:47:24 -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 AHW70284; Fri, 6 Jun 2003 17:43:10 -0700 (PDT) Date: Fri, 6 Jun 2003 17:48:17 -0700 Subject: Re: [Sipping] [Sipping]Questions on draft-ietf-sipping-connect-re use-reqs-00 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'sipping@ietf.org'" To: Nicole Johnson From: Rohan Mahy In-Reply-To: <53F74F5A7B94D511841C00B0D0AB16F8B8E554@baker.datcon.co.uk> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Nicole, On Thursday, May 22, 2003, at 05:12 AM, Nicole Johnson wrote: > Thanks for the clarification. > > I have two comments about the second security mechanism discussed in > section > 4.1 of this draft. > > 1. The draft states that, for a server to accept an alias, the target > address of that alias must previously have been registered with the > server. > However, this mechanism is only as secure as the REGISTER itself. For > example, if the REGISTER is not integrity-checked, a man-in-the-middle > could > alter the contact address in the REGISTER. the attack you describe is on the Registration function. The alias is at least as secure as the registration policy of the registrar. > I think the draft should recommend that the REGISTER also be > integrity-checked using S/MIME and a sipfrag bodypart containing the > Contact. I would be happy to propose some text. Alternatively, if I > have > misunderstood the proposed mechanism, please let me know where I have > gone > wrong. Digest actually works fine here. > 2. It is not clear how this mechanism could be used to reuse > connections > between two proxies in a secure manner. Would each proxy have to > REGISTER > its address with the other? no, TLS mutual authentication is more than sufficient in this case. thanks, -rohan > Thanks, > Nicole > > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Tuesday, May 20, 2003 9:09 PM > To: Nicole Johnson > Cc: 'sipping@ietf.org' > Subject: Re: [Sipping] [Sipping]Questions on > draft-ietf-sipping-connect-reuse-reqs-00 > > > Hi, > > On Thursday, May 15, 2003, at 07:23 AM, Nicole Johnson wrote: > >> I have a couple of questions about >> draft-ietf-sipping-connect-reuse-reqs-00. > >> 1. Intended scope of alias parameter. >> >> Is the aim of this draft to enable connections to be reused within a >> single >> dialog, or across multiple dialogs, i.e. can an alias learned within >> the >> scope of one dialog be used in another? Is the alias parameter valid >> on >> out-of-dialog requests? > > across multiple dialogs. it would work on out-of-dialog requests (ex: > OPTIONS). > perhaps these should be explicit requirements? > >> 2. Target address fails to authenticate. >> >> If a server receives a request containing the alias parameter and the >> target >> address of the request fails authentication, how should the server >> react? > > it should not create the alias. > >> It could drop the message, respond to the target address with a "not >> authorized" response, or continue processing the request as if the >> "alias" >> parameter was not present. Is there a recommended behaviour? > > the behavior for handling the request should then do whatever normally > happens when a request without an alias parameter arrives with failed > or missing authentication. frequently this is fine and will result in > a digest authentication challenge (401 or 407). > > hope this makes sense. > > thanks, > -rohan > >> Thanks, >> Nicole >> >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jun 9 03:02:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22875 for ; Mon, 9 Jun 2003 03:02:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h59722D06231 for sipping-archive@odin.ietf.org; Mon, 9 Jun 2003 03:02:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59721B06228 for ; Mon, 9 Jun 2003 03:02: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 DAA22867 for ; Mon, 9 Jun 2003 03:01:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PGdI-0000MT-00 for sipping-web-archive@ietf.org; Mon, 09 Jun 2003 02:59:56 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PGdH-0000MP-00 for sipping-web-archive@ietf.org; Mon, 09 Jun 2003 02:59:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h596wTB06068; Mon, 9 Jun 2003 02:58:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h596tuB05983 for ; Mon, 9 Jun 2003 02:55: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 CAA22766 for ; Mon, 9 Jun 2003 02:55:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PGXO-0000LH-00 for sipping@ietf.org; Mon, 09 Jun 2003 02:53:50 -0400 Received: from j1www001.uniden.co.jp ([210.81.104.201] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19PGXN-0000LE-00 for sipping@ietf.org; Mon, 09 Jun 2003 02:53:49 -0400 Received: from [192.168.100.38] (NW-EMB-NS25-2.uniden.co.jp [192.168.0.34] (may be forged)) by j1www001.uniden.co.jp (8.9.3+3.2W/3.7W) with ESMTP id PAA12246 for ; Mon, 9 Jun 2003 15:51:39 +0900 Date: Mon, 09 Jun 2003 15:58:26 +0900 From: Chinatsu Tatsumi To: sipping@ietf.org Subject: [Sipping] Subscription of dialog information to a stateful proxy Message-Id: <20030609155343.6831.CTATSUMI@netwinners.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.10 Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello All, A stateful proxy has dialog information on its clients. If a UA apply for subscription of dialog information to the stateful proxy ( using draft-ietf-sipping-dialog-package-01.txt method ) , can the proxy notify dialog information on its clients? Regards, Chinatsu -- Chinatsu Tatsumi _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jun 9 10:42:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07311 for ; Mon, 9 Jun 2003 10:42:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h59EgQG07050 for sipping-archive@odin.ietf.org; Mon, 9 Jun 2003 10:42:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59EgQB07047 for ; Mon, 9 Jun 2003 10:42: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 KAA07275 for ; Mon, 9 Jun 2003 10:42:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PNop-0003y8-00 for sipping-web-archive@ietf.org; Mon, 09 Jun 2003 10:40:20 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PNop-0003y5-00 for sipping-web-archive@ietf.org; Mon, 09 Jun 2003 10:40:19 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59Ec2B06834; Mon, 9 Jun 2003 10:38:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59EW0B05723 for ; Mon, 9 Jun 2003 10:32: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 KAA06842; Mon, 9 Jun 2003 10:31:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PNek-0003sL-00; Mon, 09 Jun 2003 10:29:54 -0400 Received: from [61.144.161.2] (helo=mta0.huawei.com) by ietf-mx with esmtp (Exim 4.12) id 19PNei-0003sG-00; Mon, 09 Jun 2003 10:29:53 -0400 Received: from Natarajucl1127 (mta0.huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HG700FVCXJQYU@mta0.huawei.com>; Mon, 09 Jun 2003 22:28:40 +0800 (CST) Date: Mon, 09 Jun 2003 19:59:58 +0530 From: "Nataraju A.B." To: SIP , SIPPING Message-id: <003c01c32e93$9b6c44a0$3802120a@in.huawei.com> Organization: HTIPL MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: multipart/alternative; boundary="Boundary_(ID_qTOuGtaSXpaO8PJIpnUV2g)" X-Priority: 3 X-MSMail-priority: Normal Subject: [Sipping] Fw: Is there a freeeware available for conversion between feature predicate and feature parameters........... Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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_qTOuGtaSXpaO8PJIpnUV2g) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Regards, -Nataraju A.B. May you live as long as you wish and love as long as you live. --Robert A. Heinlein Time Enough for Love. ----- Original Message ----- From: Nataraju A.B. To: SIP Implementors Sent: Monday, June 09, 2003 5:04 PM Subject: Is there a freeeware available for conversion between feature predicate and feature parameters........... Hi All, is there a freeware or general guidelines available for converion between feature predicate and feature parameters. Thanx in advance, Regards, -Nataraju A.B. --Boundary_(ID_qTOuGtaSXpaO8PJIpnUV2g) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
 
Regards,
-Nataraju A.B.
May you live as long as you wish and love as long as you live.
--Robert A. Heinlein Time Enough for Love.
----- Original Message -----
Sent: Monday, June 09, 2003 5:04 PM
Subject: Is there a freeeware available for conversion between feature predicate and feature parameters...........

 
Hi All,
 
is there a freeware or general guidelines available for converion between feature predicate and feature parameters.
 
Thanx in advance,
 
Regards,
-Nataraju A.B.
--Boundary_(ID_qTOuGtaSXpaO8PJIpnUV2g)-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jun 9 20:07:31 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 UAA25776 for ; Mon, 9 Jun 2003 20:07:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5A074I15961 for sipping-archive@odin.ietf.org; Mon, 9 Jun 2003 20:07:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A074B15958 for ; Mon, 9 Jun 2003 20:07:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25772 for ; Mon, 9 Jun 2003 20:07:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PWdI-00007B-00 for sipping-web-archive@ietf.org; Mon, 09 Jun 2003 20:05:00 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PWdH-000078-00 for sipping-web-archive@ietf.org; Mon, 09 Jun 2003 20:04:59 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A05sB15830; Mon, 9 Jun 2003 20:05:54 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A025B15725 for ; Mon, 9 Jun 2003 20:02: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 UAA25716 for ; Mon, 9 Jun 2003 20:02:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PWYU-00005u-00 for sipping@ietf.org; Mon, 09 Jun 2003 20:00:02 -0400 Received: from sc015pub.verizon.net ([206.46.170.59]) by ietf-mx with esmtp (Exim 4.12) id 19PWYS-00005Y-00 for sipping@ietf.org; Mon, 09 Jun 2003 20:00:00 -0400 Received: from [66.138.147.160] (port=9199 helo=Vpbitowh) by sc015pub.verizon.net with smtp (Exim 4.14) id 19PWZk-0000st-SD for sipping@ietf.org; Mon, 09 Jun 2003 19:01:21 -0500 From: taylor To: sipping@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=K56A5480Hh4a8J8i462640Y42S3 Message-Id: Date: Mon, 09 Jun 2003 19:01:21 -0500 Subject: [Sipping] FlashName Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --K56A5480Hh4a8J8i462640Y42S3 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable --K56A5480Hh4a8J8i462640Y42S3 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: NAME.exe, Content-Type: audio/x-midi] The attachment file in the message has been removed by eManager. --K56A5480Hh4a8J8i462640Y42S3 Content-Type: application/octet-stream; name=frontpage[1].jpg Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAARgAA/+4ADkFkb2JlAGTAAAAA Af/bAIQABAMDAwMDBAMDBAYEAwQGBwUEBAUHCAYGBwYGCAoICQkJCQgKCgwMDAwMCgwMDQ0M DBERERERFBQUFBQUFBQUFAEEBQUIBwgPCgoPFA4ODhQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU/8AAEQgAvQCKAwERAAIRAQMRAf/EAMMAAAEE AwEBAAAAAAAAAAAAAAUCBAYHAQMIAAkBAQACAwEBAAAAAAAAAAAAAAABBQMEBgIHEAACAgEC BQIDAwUMBQoHAQABAgMEBREGACESEwcxIkEUCFEyFWFCI5PTcYGh0VLSUyRU1RYXkbFiM5SC krJD4yU1VZWl8HJzZEVXGFYRAAIBAgQCBgQLBwMFAAAAAAABAhEDITESBEEFUWEiMhMGcYGR sfChwdFCUpLCMxQV4WKCoiNTB3Ky4vFDcyQW/9oADAMBAAIRAxEAPwDu6jRpPSrO9aJmaJCz FFJJKjmeXAG/8Pof2WH9Wv8AFwB78Pof2WH9Wv8AFwB78Pof2WH9Wv8AFwB78Pof2WH9Wv8A FwAietia0MlmzDXhrwq0k00ioiIiDVmZiAAABqSeIboeoxcmklVsjo3r4vOmm4sAdfT+u0/5 /GLx7f1l7UWf6Rvf7Nz7EvmFf4y8Zf8A+gwP/GU/5/Dx7f1l7Tz+k73+zc+xL5j3+MfGX/n+ C/4yn/P4ePb+svaP0re/2bn2JfMe/wAZeMv/AD/A/wDGU/5/Dx7f1l7R+k73+zc+xL5j3+Mf GX/n+C/4yn/P4ePb+svaP0re/wBm59iXzBbF2dsZyu1vCzUMlVRzE89NobEYkABKloywBAIO n5eMkZxlinU07+3u2JabkXB50kmvePfw+h/ZYf1a/wAXHowHvw+h/ZYf1a/xcAe/D6H9lh/V r/FwB78Pof2WH9Wv8XAHvw+h/ZYf1a/xcAAfl6/9En/ina+6P93/ACf3PycAN964XObj8ZZv AbZyP4TuHJ4eapi8iGaPs2Zq5SNutfcnuI96+5fUcxwBy5su3Nmt6ePMZStbi2XLlNy7gxG9 9mVstZipUcjhMItvsVRFJ0GBpVSyrDUOJCp6l4El1+VKtebzZ4NeSMMxyeeVtfiI8HYmQH7e mSNXGvoRrwIKI3/5J8hV6O5s3U3HkobWTt+RcaKVaw8UePh2hGJMdJAkenbeM1f0rj/e95uv UdPSJJ9u3I7ixm5NqLR3NmVr3d67SxVmL5+YxyUp8NJNYhI10KzOiyS/En7NeAE7B3DuOxs3 ypszyJZybeRsPgLD5VLlj5vE361hL7Q5XGN6JFZVhG0KBUj7ar0huvjDf/Dl6H7i15O//fsf +SH+5ALbVSpkdibOpWa1TNLPicA9zC3K6OsFQZ14Zsh1uujaR6VmRD1dLan2jiktpO3FYPCO H8WfyH1Hdzlb3d+ScrdLl6k4t4y8BNW6Lr7dXhVUzYCxOE2XbzOe25ZxmGxOcubizuL2jkru Ojlx8dipcqGGnYUDTplj7kMTEe3Viur6cYowttuNEnqkoumGDWDLC/uN1C1bvRlcnCNmzO7G M2ptShPVOPXF0lJccK9mouttHZQm2/hN74XH4Sve2/m4s1cr1o1kp5CPLijDYEg5k1yFAYnm uvVqCeJVq3WKmkqxlXqeqnxHme/3dLtzbTlccbtpwTk6Sh4Wtxp+/jh00oNtwbbxe1tv7up5 nF7fo5zbVjBUBPJjEnSeWbCtNPEpjjYhrMq9SyHp6SfUceZ24wjJNRTjpWX7vymbabu5ub1i Vud2ULyvSp4lKJXqReL+hF0pjXrNi7c8aytgdxRQYulsHJVp8PUyNmmGsYLcgoRxCLMI/KdR KGmV5dQGbnpH0sZ8O1hLBReGXdlT6XT0nh7vfrxLLc5X4SU3FSwvWdbdbLXdenstR4LDtVRM tvYG5gfp489YbK061HIY+TcheChqKscsOFgljkr9XuVdQskfoV5emnFny+DjGaao9Ty9COD8 47iG4u7e5CTlGViLTl3u/PvdayZE9lb13g2AwtutlchTqjcaeOosJWlMddMSuzReWyigdQsi yPmfmAev83Xo5cWZwhuv7o3nH4Vo7ph3TnJc2+zdm5CSSG/L3Xu5XO9uy66uo7k0ZMHMgdPL lprwCCD+SfIOB2fsfySmRyOX2jHb3RY3PjHmZsjFtFcglSM2Onq672MDq0jq3UOl1LNzYgSz ank/L4ryB4f2pPmZMnt3cO1RVyU9uZprEmet04snDPNI41JeKF1j5+shGnpoBPvp1u5TIeOW tZnKXMvkDm89B81kJ3sz9illrVOFQzknpWOFRp9uvAgmv978AMs82PyWFXbOWxFvJY6/Tj74 rSJBqvLksnfhkVlIBBQgj4HgCGzbE8azmlal2nkzbx0+QuwXkyEkVo2szCa1yeWWPILJLJLF +jLyFiq8l6QBwJDe4tr4PfNvBZzJYDNm9t42Gwd2lkxj5YHsxmvMwNe/EWLR9Uer68ift4ED THeMdh4uW3LV8f2Wa9UsY62tixXsxyV7sMMFoGOa86B7EdeJbEgXrl6R1s3AkXY8cbQuUsRj 7WzMpLWwWRgzWMDZP3x5CpAK0MzSfiXXIY4lESCVmATlppwBqGyts4LA5nA4TbWRxUuexZwh vSTx5CaOnDDJBBEjT3pWWKATMY4lZUGp0A1PHi5HVFx6UbO03H5e/C9TVolGVOnS60Kxfw3u ttuxbbTd1ipjoKMOLE1bBY+G38jWm76xfMDIGQL3R3GKkFm9TpxW/kJ6dOvClO7w9p3a847Z Xnee0bk5OeN5uOprTXTop3cOpCV8O7vF+XJDfNw27MizyM+BxDRmxFMbAnCNbKCbunuGUDrL fHiP0+da+J/KvhUPzjtNCh+TwSp+NPKmnTWldOnDT3acDM3gzeeVx7UbO9LlqlXpWcXIZcFh 2kFS7ILE6mVrncZndRIZOov1cw2pPEPl82qO5wp3VxPdvzntYT1x2dHqjP8AGlTVFUjhSlEs NNKU4C4/De9YorcD74uWFsS1bNtrWAw9qRpsdXSvXk7k1t26ookUKwb15/eJPHpbCf8Ac/lX DI8PzjtG0/ydNKklS9OKpOTlJUSSo28fZka7Xhnd0wcW9725YHMhs1pNv4h688k6xq8k8PzR SaQrCg7kis/t9eIfL5v/ALn8qJj5y2sctm01Sj8adVStFF0rFdp4JpY5Ekxnjy/U2FufYWUz mXyMu9Ld+bO5cVaEc80GVpLSmiUSWpVRgAHRx906Dp6eR3NtYdlNOWpt1qcvzrm8OY3ISha8 GNuCgop6sE286LpJrhvH208DlcdnaGy7341i4Ia1S7JZrMQa9NccszR/O9oz/LKIDN2+4Y/b 1dPLjaKEbS+Ltiz7ZsbOfYt9dt2WqmShFfWJQmPsG3WijePIq8cMMzNJHCjCNWJ0XnwJHFTx 3s+jbmuVdlZBXsy5WexA19JKsj5/oOQ6675AxFZyillKdIPNQDrwIGZ2TsB6eMwp2jkvlNvZ OpmcXAL7AVchjoFqVpEb8QB0jiiEax69vT83mdRI42ZtzZ3j35q1tLa+UqLkGdZzNfa6vUZ5 LD9C278wj6pZnkfthepm1OvAEt1/J/8Al+BBA/KXmW34rXaeOobVs7ou7hhsdmCnOsMifIxw s3tMbltRJry9AvFtsOXvdKT1KKhTPrNDdbxWHFNVcq/EVlL9Z9mvJJFZ8bX4ZISVlSS/EhQg 6EMDANOLdeXJPK4vh6yufOoL6L+HqJhiPqD27unHiLdBp7VsWSvyNFMtBkLkvcRh7hXVUhI1 GglkB1+ziq3HK71t1txlNRzelpequfqN21v7U6KUoxby7Xv6PWLz/nbe22qxsp43mzuNhUde QxeTjmYKByeWua4miB9fcnT/ALR4bTZ2Nw6eKoS6JRp8dT3udxdsKrt1XSn8yGE31Jbvp7Zl 3hlPF1rG4CMoqT3crBBJLJK4REiiaHuMSTqPaBoDz42o8psyuq1G8pS6o1S9LrQ1ZcxuRt+J K3SPW6fFSpKfDHnP/N69mKX+HZMH+ExQSmSS3Ha7vzDOugCInTp0cYeZcqezjF6tWqvCmRl2 PMVum0lSnw6CBV/q3b/GJ2pd2v22h3JnMLbmitdbri8NFI0FxVZEBexJBPGI2YKDGfd9lGW1 A+n1d+MWxhyT4/NxkLO4qGrXaYio1uOYqUstGwjeoUZg/TrJHz0YkBQPbd+oPbm8qG6rG2sP kzY2niHy+QOQjgr10mAnC1GeOaUmUtWlDFEZAF16jquoUAWM+rDYsyR1svjMnUyy1MdZsxwx wWK7PkYRIRC6zhisbHpPdSNjyIUjgKC4fqz8e2rQoUcLuC5kZuwuNpwVKzS3ZbBi/RwA2gOt O8vUJCmv5vUeXAUBsf1fbQx8OSG5tvZmleqZKzRo1K0MU8lqvDavQJIqvNEySKKEvehcBg/t Tua8BQkl76hcPPsbyNu3bmCvz2/HiTfNUMksNFrEkQchgvckljj0QvrLEjFNCqtqOAoNcl9U exsTlMrhL+EzaZXDWalS7CsNJo1a680SuZ/nBFGiyQPGxmdCWKhQ3UOAoY219RlHdHjbyBvb G4OaTJ+PYsmcnjhIqV5LGP8AmZEhSd9GJ7MMckrdvRe5onWQRwFBOE+qHaeTuVsDJg8w255L dTFPSqwV5IpL0/eScQyPYXWKCSvKjvIEJ01UMDrwFDdi/qh2NlcptLFLhNwVrG9ZE/BHs0Yl jepM0CQ3GKTsexI1hAGQMU93cVOk8BQsv+9+BBQX1H2o6W6PEVmbKQYaKNMuz5K1Gk0UYFer rqsmiktr0rr8Tx1nI46rN5aXLuYL0s57mrpctOunvY+whd/clbN4O/tbL+WMPNTvMlU2fklR BV1TqZFSTqDEjRi3wHIc9eLKFl25q5GxKqxz4+w0J3FODhK7Gj6ilsPT2hJPYbcuamgxteVo 0r46q1m5bRSQGjLlIYw32yP+8eLy9cvpJWoVbWcnSK9PF+pFPat2W34kqJdCq38hbG2fNvjv aeEv4TA7VycCxQPJhr92/wDNzm8EITrCNH2IydC3Yf8Ae45vdcj3G5mp3JxbrjRaaLq6X6S8 23N7O3g4QjKnCrrV9a4eoKjzRtfyht19n+RZbOI7xjJsxzBFaSJg66WOgqQGAPTYjA+2TjWl yjdbG6r23pdS4Ux9nH1ew2I8y228g7V6tpvjnH5166lkfTtsD/A+fz9uploszgMzXrJjriIY 5RJA0rskgUvGT0tqrxyMraH09ONTmnMlu7cU4uE4t1T9XrNnl/L3tZyakpxklRoF4jeX077p 3NNtrceyIMduTK5/Mbfijs49rCWJILt2AzTTJGFj+als2wFY8nZwT6HjnS8G+Vyn0yYDecWL yNO0ujZTYtfAjGyPiXs3bFefJMpEHXNIzzQLI/dcL1+1QepuAMbf8zeEttbKElLZo23kty4J rU2BnrzRwW6VKWesIJbccEgkboMr69DfePUeo8BQJ0P/AOYs1tbf2cwmz6c9LbFJsjna1ii9 JZoqYmeJomlUDpaSjIoZPzl5+vMCK1/JH0uZHaOPyG7tjw463kaDWcjjKdCTIrTEMtoPEbVa NQSDiZm1XTVY/sOhE4h2zu/6VMnJkMBR2zBkr9G5LSjpVMVPrLZrjIXHMTwxkrGGiuGRuQ0L agow1EYjvFeTvp1obQ3dm49tPXwuWr1n3s1PEW7FCy9yusslY2DCkcnYW3qyezTrJVdSeAGc V76Z83by+N23smtm1qlcjueRqNiJFxddp5Z7kfXEzWRFIx64Ix1SNL6MSRwAUyvkLwls/wAd 4remJ2eG2F5HlmwubWvTMEjY2Orkrkss1ZUYzRgLY1C/myEg6DTgATmfK303bQyybrwu2Iru QlyonzWSp0JIpqgoRZeM3kVo/f0NQtKyx6EhjIdfiBb2A8OeHqYw2b2/tTHQGjJ+J4ezDCUa N7CxsrrrodAI4yityTpXpA0HAEh/vfgQcz/V9O9WTxjYSSOIpFlQXmiSxHo0VIENHIGVtfTm OOp5NcuW7F+VuDuyWikU9LeL48KZlNu7Fm/urNu/dVi29dbji5qOC+isXV4esoNbcMiwSHN4 KNlC9SriirDrI6g3TU6WK/Hn6enrx2Ol/Un9r/kce5xr340X7v7B5Uv1rORkrXs/ia1Jar2E txYlDE88GvarmMwRHqfX72hGnrr6cVvMb2429mM9vt535ucYuPiaXGEu9cq28I9Gb6szLalC cmpTjFUbrp4rJZLMUmTEYUrnsG3VyYHEdTKJDo33qenIevP9ziylbx7s/tf8jCrv70fs/wDE H5fLTPH8glrHXqzjqM9OjHWddWJ6OpoI3H2+3lxktW0nWkk+uVflZhuXeFU11L9he/0XxoM/ vEAco61IoPgpZ5gSB6AnT145vzN3LfpfyF/5ffan6i6I/FfiNd2DdybWvruGhfnzSWyuV7Jv 23NiSVYS/ac9x2kC9BVHZmADEnjhTsjZb2B4ryOYqZSxtnJLlK+TsZ2K2kWVg0v3+w9h3aNl DJIa0PXE2sZKD28AD8b4F8HZie1LHtG1E6xivKlyXLVozFJ3SFjSaZU0AkcDoHtB05DQcBUl Vfwv4zqYjN4GvgUTEbjgjqZqt8xaIs14ZZp0RiZSwAexKT0ka9Wh1Gg4EAuf6dvDFgXlfakC x5F5ZLUUVi3FEWsLbRwiRzKsakXrPtjCgdw6DkNBNR9j/CHjDF5F8rSwZS4Z7FpNbdx4opbs NmCcxRNMY4xIlyx1KigEuW+8AQFSKN4Q+nOzWauaFdKlhowKoy96FBJWiFXqSIWl6XMaBJGU BnA92vAVD+G8d+Ftutfmw1enSfKU5sNdlTIT9UlW30ySRBmnJUtqrBk0YfAjgBtF408F29p0 tjJWpWNtY+1asVaTZGd5PnMjDYgsO8psd13lSzOD1ufvajmBoANteC/p1vxXknxtRocnK0to Jl7kas8i2+sJ0WwEVhcs9SR6Ke42o4CpZtXcW0alevSqZagleJVr14ksREKqKAqjRj6ADgQa P734A5v+rgWwPG0lFS1pIsn0BYxKecdPX2kMDy1+HHZ+W6abtcuz9447zHJp2qZ9r7pRLDMW 8damysYgtQtWWq70YYj2mEpYD9GnI6Lz4seb8xt8t27v6XNJ4pS6Wl1keV+SXufb+OyU1alJ NqThXCKbywzBwUkAm4Qfj/UISP8ATrxcxmnbU2qJpPGWVUczcU435WU3OUZSjhGtdLawXqM9 P/3jf+nw/wAfHpKuKVf4jFK44tqTaazrETMGMEii0z6qfb8jFHr/AMoHUfu8SlR5fGR4tVg/ iL++jKMx57eevxrUP+nPxzHmV9i36ZfIdP5bfaueovmTaOSifrlysKSxK8ARshllVYpB7dQb v3yNT1ev2ccMdwG9s0ZcG0teS/WlpOpkYGxasT9xQqg9dqeUhAi8wPjz4EB9cljndY0twtI3 3UEiEn09Br+XgDy5LHOQqXIGYgsAJEJIUak+vwHAGWyFBWCNahVzzCmRQSPT014AGbisLJiV kqydYkmjSOWGR1AYt069UMkbaA+ujfvcAR97M/zFdo2tF5EWNUY2umNwnQSem1pzHUdSNf3+ fAk0CScoYpPmiwjdTIHt9uQLqG0/rZbqI+6fX7vw4AUWszivM8ksbQknuM9tC3UNdAFt8+Z0 0JOnpwIM/NysOvWwZZEZO0rWw+kOif2r2sQVOvqwDHgBAuWp4xVZZTYgYSCRGss45Hl1iyWO v8g8vXgCQc//AHfgDnz6p4LM48dJTcx2e3kRG6uIiNY6mvvJAGo/Lx2Pl1pRu1y7P3jiPMze q1TPt/dKVtUc1Tw145ieSZi9UwlraWVCnu6j2u/x+HGp5ylB8slpXGPCnFHWf4lU15ktKTr2 LnGv0WMGqyJU7hacr29SGtROnNf5A5/vcbvP6Pkk8vw4cP8ASVXkeT/+wtYv8e9xXRcMwVZe wkqvYAGrDS3EE9T+Z97T/Z9eJsSceQpxwa27o6Ovc6SN4o3PO0oTWqMt8k02mmndVU1xXUah BNPTknd7D9QbUmzH0cuX+7J6tPycZfLF2VzltmU3qk9WLq33nxNb/Ilm1t/MO6t2oqEIuFIx pGK/pwyii9PpChEWd3eftrUf+nNx58xvsW/S/kK3yw6zueiPyl2W/wAQndTPA1uSaVFDFHco ACoJ1xjAhdW5k+munHEHeiRBIk0vbrFonidpNYnQsI1AKELivQnVRodWHMA+nAGz5eWvKX+X 7phjXsTSRSCRSWV1QdGMGi+0anXkPh8eAEvHYGpr1tJOeo7DL0RspGi/91trr1aMD+7r8OAM WorfSkqVl75ddZO3I7EPzGjnFnX7xHP4AfHXgQHFkkr7Xi71UXZg5Ro545NOoyEdekdQEaHn r2AP9fAASOrIygwQl+/Gndcxv75+oiRSfww6aaFes8yPUD14Ay1O9HDE5r+1I9JAEIYSFVYh V/C2ZlGoCudPTmNRwJNjQWpJBF8uVI0jfSJiPmHYBl6jjOUeik9z0JPMaHgQa4a10DrmrgLK TpIIS7FvgG1xa8izDX8mp+3gSerwXYn6vl+3PVK+6GNgGKOep+o4oEsAfzTz+GnAgP8A978A UN9T1dLMGwI3dY1Md4GR9elfZU9dATx2Hl10V3+H7xwPmx42V/r+6UhkMdXxu38gYrlW2Hkq ktXMhKn9Ly96Jz41fOU3LlkqprGOfpR1f+H4JeZrSTUuxcyr9R9Rty237+J27j8xdrVIqWVr 92hMju0siqq9RA1Oh9w+8Bxo7/n+x33L91tLFxyvbWFtXY6WlFtpZtJSy+i2a3kzYX7Pm3a3 ZxShdv3tLrnhc9nrMfgd+ttupnrFOvHi7nWlW43c6pJFLAgaHTqHSfUacuMu051sb3LZ7G3d Utxa22qdvjGLgsXhSnajx4onebK/b86xvyhS3PmMVGXS/G/Y/YNqGKuSbd/Gfk4zje40JvFJ v97rp09Y9nV9g42fK3M9otrY2nix8dxlLw9S1adUu1pzoav+T9vdXmLeXdH9NSgtVHSvhQwr lUu/6UYwmb3YR8a9L/pzcb/mPuW/TL5Cg8pyrcu+iPylt2Y8PHK7xz1rEddYxCqCsvWsKN1B erQjTVtdNdOOKPoprLUJHlBerrGgHdY1gjcus9eh6h7xzA9OANtebBCslW3Vq3p0JKubNeEs sh6eXQ3ST7dPXn8eAHIv7XknKChUKQuEWQW4wSh6vcBrz06Ty14ECFvbZYRd7FVEbtP2gLcL LyDdSjQ+mo06tOXABexWjym2YosXUQwtIrfKxvDMnSrknmxKHXT7eAI/EcYUCR9gY0iPvQA1 owk4Gn6RSQwJYyfucCRBGNls2ZjNB3pI+lULUw/S3sUBgfTnqPX+HgDdCm3nM0cuQq1ZJWSM oVgnDHqOp6kP5xHofu8CB0tHbc8ixtl6kjxv25NYYlJcjoVddQAQfs4ASKu31jiAzFdJIJFV maui6FHHQpU6BSD9o+PAkNf3vwIK68w+Nc95Cp7WOElgjGMhnM/zBkGvfSDp6ehG/kH14vuV cxt7TXrTeqmXVX5zl+e8ou7/AMPw3FaNVdVeNOhPoK5i+nryBWZq6WsbJFL23lSRZZYW6SSA 3XARqNT6cWe45xstxDRdtynHoaXzlRsOR802F1XtrfVq4vpRlJPrx0hXMeGPKWWjhhmuYmLH 1YglXHRJI8ES6AERrJA2mug1GvFfYu8nsu5KO37V78R6Y1nTLXR9qnCps/pvOVdhdhuIwnbb cHGUqxbzcXpqm+Ji94c8o5GrVxa28XUxVVdIaKJIa4c9RZ+l4G0Zuo66aDiNvc5PYuzuw29L lyOiUtEVKUKJaG08Y0SVH0I9X+Xc6u3I3HuFqjLWnqlXxK111ce9V1r0ipPCvk+/hotvw3MT j8VF7poF70cc8hIPcZRAwDaj1ULwsXOUWdwtzDb0uxWmM9MVKMceynWtMXgRvuW843iav31P VjJuUm5PDGVY54Im3hbxTuDxvkM1bzlylYjyMUEcIpvKxUws5PV3I4/5XLTXiea8yt7uMVBN aa50+c2eRcmvbGc3ccXqSyrwr0pE5l29k35pkY0Ladbdd7X2jQdOlwaafbxzx1pmTbl+RtRk Qqq3UoE1/mOZ92lwa89OBB58BlJfbNei6A/cXokvL6kkgj5v48ufw58ufAHl27kI5kkjyS9t YyGieS66mXQ9Lc7Z5AnmPiOXAGTt6+hIhvqY+o9Illvse2GBQN/XOegLa/by4AKRYqv+GLjr M0j6+6aSOxYRmkJ1YhzK0gUn83rP2cAIbA4xmLNLa6mAViL1tQQBp6LKB/BwAuPD46MoVksH tgBeq5ZbTpOo+9Kf/jlwA3sbdx8kMywTWFndT22e7cZA/wCbqonHIH4AjgATZ23uGWWR6+Vq wRyqvUpXIO3cVQAepb6aDUa6Afx8AKk27nfkxVjycBfpR+9I146TKFVhoLgYxsAxCGTkT8eA Hn978AVr5O8mby2RkcFidt7PTcMeTxwmjuus5SGaA6OkrRRuACrIy8/5XAlCZPO1U7fTcMGx 8sUjyq4i3j2qA2dXqPY7i6HQKrLoS3qCP5Q0A3zeYrWO8jWtj5TZdl6T5KpjMZl6Ufch/rTo plsmRUCKBIrDpLajX46cAM8h59rRZK7hMf4/zcuUrWrWNieemsVZ7dWTt9Qfn1Q69LGRQfaR pqTwBu2/5r/FYdu2r+0LNWvuPKzYeFBCS9YxtUjWWfqUdILTyaqAfu/7LcAXDar1Ia8kq1oi yjUaoun+rgQNbNG04VsfHSB7yq6zwEgQh9HIKsNW6fu/DXjxLVwBz35Q+sXxD4m3CdoZKKXc e4qX6HNLgqsRr1LK6Bo2eedB1A66ohcr91iGBHHl+JwoelTiWh4w8pbG8ybZ/wAUbDtQWasM pr3q09Xs2q03SG6JYy50JB1DKWU/AnQ8YpXZpKqxPWlVJdIrJVecR1SyuF0+X5aH/lcYZbiS jWizJUFWhpgkklhsSmGprEoYAQcuZ+Pu48x3U2m6LA9O2kwJuHdX+HdkZDdTYupcs054oEgY mrBpPZirh5ZBHMyInc63YI3tB5cblm45xqzHKNHQran9Tu1LGXepJsvLLjCESrbiqrJNLOek MpiYIiqpJAbvEnT7oOoGY80JFmPN2AwowuTsbYtybczUF4RSxRJJkI72Ptiq0DV0Bi6X9zK/ zHw+78eAoMYvP+Dt4DM5GlszInM4KGOxcxc8KRJIvzcNWYQzIshdk7pYAxDqC/AEHgKA6r9S uAnw9bJS7IycdiOSrFnK6xRslRrcckgSJ2CNO4MZXp7ac/UjlqFC78PLjM3iKGZr0uzBkK8V uKKxEqTIk6BwrqNdGAOhGp58CBj/AHvwBW3kTG+dJtxbdyHjO3Gu2K9GscpQllgjEtiKfuFQ JVLaPHojaMOX5eBIPkt/VV2KU5x+Ge9pHJZrRNHHXQsZEdGZrBZ9B0vyAHPkdRpwGBrzVP6n 4Nz7hXbctGTbNvItZxUt14HlhrQ9oxwxqHXSOQBhJ1jq+AC/fIYGyaz9VzwWU+TwQMiERtAE WSMyxJ/uzJYKlo2L9PWNCRz1B4DAn3jLEeQMdWnsb/yst/ITV6sRhkNcxJPAZu7JH8uqgCQN HyPP26/HQATa8NakwH8ngQayYa/duyP0mJJCys2iBFYsWI9Ph68eKLVXjQlHA/i7x4No1twb 4wk+MzdqzlLNq5dztb5lbFB31jETq3JyWJ6vzidfycUk7krk9Tyisus7Hb7WNpaYPGTz40Oi /AmAtPnt47xGEqbexWX+UpQwUmjb52Sn3ZPmpFjRApCTqig6n158hxube3qjiU3NJf1aUyXt LuegrwPB1EBmDa/ucZnt6xpUqteNTTFikiimiD6iYBSSPTTjzHbNJquZLuVAGbq7uxm0slBs YVZ90pNGaQvaisQ0sRm6tGXmIi/T7h7tONizDRGh5k6shmLufUe2SgTMUtvrQFir31qlywql 4xYJLzag9Ik7einn6j04zHkZ27f1ORZLIU8VX23YoR2Zjj7FyR++1dXLRrKsRQDVWQcl1A9f gSGAubHee5cI1mWzTg3VJlWNaSmKkZXFNWmKxS95ZFcRykMigkknmdPeoC5o/qQh25Xjis4W XcUli9841kqIxCRF8ssDRJGB0jvNq6M2nT1fHgBvs3/+k6WVxcG6p8Fc2y1hWv5DudVySvId AsZjEadXP26J9nrqeALO/vfgQM8ksjfhwjizBZqsa97FtEsK+0nR+4w93732cAMrUOShLNGm 45e67DpSetopdhGf3FUHrU/k4AXfS6LI1TcbAyd1lqyVTEmjBgvuIJHLTRdR+XgCvfqTzuS2 j4CymdoSXY8jQlikia7IDZDtOVBkMJ0KjXq0B+6ONixLS2+hMw3lVJdaAKeG/HNjYv4mm5sn Xy8sEZyOZr5ucvJcZAzFu5K8Y6mPKPp5Dlxzju3HFz1OvQXcbUU9NMOkrP6Stx5pPOG8/G9/ NWs/isXi57eMu2pnmdUaeshjdixDcpBof3dPXi5295zsKqKy9aULzowr9Sv1e5HZuezXjfxl iQ25qMUlHMbjur0/Kyzxh1FNAdXdO519Uns6vzW49KCbqeagbxRn8Nvjxq2Zr3KmN/D5IKW8 MZkJez+H2Jj0Leicg9VeYBn6CAyt1KCdNeNN7ZWlWLdC82u+nOVNOqSTeHVmda7UfaWzdlYx amTjmwhXSHJ/9XO7a+4dPVy9ui8/QDmePKu24QWOfpKy7OV2bkwvDuvbFnFzZqHIxPioH7U1 oFuhXAB0PL8o4jx7OnVwy4mNQlWgzpb72Rk6eQyFHLwWKeLRZMhMhYrCj66FuXx0PGFbnbyT eOHpPXhzQKysuz/IGxcjHXz5pbbvWIoWzFSwKzJJHNFoqyvpoWcCP8uunG7t5wlCsMjHNNPE qCj4b2VWnkfJeYrkkbS9NJIstDExghQHplaSWQyOCx6mHSOjRen48bB5JlQ8F4DK7drV6e9s zfqtkbuV/F6tyMyTy2xFEyGWJdCsRgAQD7p5fk4CpoX6Z8T3C8u8M/Y0keSN7FoTSx93udfR I4JUkP0no05ctOAqP8H9PWIw+UTJ2Nz5vLlPmglfJ2RZiAuV5azaK6kAqkzBCNNP9OoVNO3v p0xu38xh8sN2Zy/HhbEM9bH3J0kqlKqBIY+30gAIB7Svpqft4CpY3978CANnvwLWicnh8pfs inAgmxqzle2xZgjdmRNdGTUgj4r9vAA+KXbCQGWHB7hFeVuy1ULb5lGWcSFe71L7lGh1Gp5c +BIfxu19t5ehWvClfrKQ5igt2LcU8fu0JKmYkE9AIP2cAQ7ztjMdR8ZPj+20mPkv1hPFM7zl lkc9YJlLk6/l42ttHVJpcU/ca24lpim+DXvKbzNPFLXpVMVtalJtq1bSfI1dOVovCUE6nUDV dfc5I6NPTjkFF01N0aOwTi1gsGZ+lnGYWLyruzNYavDDXt156cHY9y9inLWQKrepXUa8+L7Z 2Zqxrk83T3ts5/d3oO9oissfckjlP6iugfUV5EZgSRko9NNf7LBxtI1mRTbG6chtXKHJ0UEk M8MlLIVJeaT1ZuRVxpyIOjI3qrAHj06STi+Jn2u5ntb0bsM4uvp6V6HkWdsDzLndj5WjsHJ3 O94jzVoTYqtL+kOLkncjWGQ+5Yw76SRklQD1DQ661jt+Jbx78X8Pai15rZt2dzqtfg3Upw9D zX8MqxZ09lt24XDeOc9tCGG1cvR34psjZrxH5Skk/Z7QmnbRTJJp+jhi65G1Ht058VkoVg48 ap/EV+tKXqGPhXJYDcnjnyZZwFhboWpFHMsbI7qVSdgGVWYqeXo2h48PbOMZ1TyX+49602qF seCMZG/imOhPLNTV705MsbdmUMJlYAMddNSNOLjZxpbSNa6+0StsdjwUk1zo6nkXkXIUqRqD oD7T1dK/A6cbhiCePariG/Q/itxJ0Ur3VlnjTQtqByAVvt/e4AJDNQlOsVbX3OsoYHDjmQB0 nQ6nTkOANZ3BAtcWWqXFjJ6SGgZWB5eqnQ/H+DgDx3BB3uyKdxjopLLXcqOoa6H4gj7COAGX 978ANslFg3gx8l3F08jkEgh91uHrZIOk81cQy/nDkvL14AaSRbdifQbdxhlV+3N+hOqqBprq Kh10Ylf4eBIUjzLUEelBjoYIasTmCGFpRH01zpIqha/SAo+6B974DgQRDypEd3bLlph/lI0u UXM0UcllgS2rgxlYjouvrqft5cZ7F3w56qVMN614kdNSn91eMc1mqcuG2jvB9v4CWNTPUu44 Su5dR1rXnWTVQSfeoPI6jjRuWISm5JZupvQvzjBRrlgTnwN4mx2wpIr+OzkeQ0qTw2Kpj7Vj rmkjcvIhdihBQjTnyI58bimlaVtdNTUca3NfVQ4E+pKV4vqI8hyL7k/Ek1X7P6rBx5RLZBIb 0U1YwxxOXB10ClgdPtIHHvUkgk3khjbNl4DA0UzxqS/S6MFDH1IHHnVHpR70XKUo6F//AE9+ N6/kbYu8N1ZrOZzEZfbl2tWxE9S80VYm3AIiXgKswaNRoGBUMp6fhxpblqFtyjSq6TPt7Dnc UZVVSXf5SNsvbST7NyO6s73Lyzbj25tl5K9i/CBpFII4FZQYDzPdD9eunLiut7h3Vi4mxuNh +Ximm3idSeFKq0fHtrbuUuZF2ikS7ZsZWrKlyM5CZm+WaC7CXZY+jt9xk0f1AHFlt3WCZoyr XEkyUYlqOk8KSV0ImsSJFCntJDDpQUB1dYHNdPUcbBBqhpVokVkRNZJDKlUww/oyCEBVRjtA QA3qP4+ANkdSutiOKAQBgnYCLHATqNTqSMedNHHX66a/6OANK1IonMsIrho06JYjDEAB94gl Mb8dNOBA7xvyFWeU2KNS1NLJz7qKGjGpBOsVFOZ/O6vj8eAD/wDe/AAzJzxQWcezSIkiU4Zl ZjACoQkdREtmA6DX10I4AYJNjpXLTrG0rSMsa96squWjYIOV1+eq/Z+9wAia13Yq5naP5lUl ijUSQOFSE6ABvmxq6n/Xz4EjHPWKU22LrSzoFFqj1us1aMuwfpUFxdI1Yr6Ow1PLRvgBFV6c lYrV8NItywrtFFWhuV5JhA+rEoqXdHI0Z39PX4kcAWptXbNbA0PxB1k/FLMIFgzkFo+pi5Re bFRzAI6j90fZwIOHfNf09b/3J5h3lufCU6UtPI3kliaxchrv0/LwrzWUjQaj19ONd+Jq6iyt y26iq970Eex304+UKckyZnHVK8dLqluoLkDNHDEQruVGpKjUcwNOY+0caW4s3n3F8Zv2d3to 95v2F67P8JbRo/LvnI67oWEbt+jl92mvtAGrHTjQhy+++/7zHd5hBvse4vLb/wDlttakuGxK wRxZBg/QYtBMyEoNfaF5FSOfx43I7ScYOKWZWzvucqthahndrpMy4vtRXbkvyixovaZ5Y/zN CBoR1cYfyd5LBL2h3VKibwAlOHd0Ee8Mhu2lDDTe5VjwoR4GMmPrzaq8hEi6N7tT1uP3uLTa W5QtJSzxMN1pywyMvcxKpNN1xCWUKHJmqOFeEFWOnz5UdaFtF+BB42jGIS7ikMDzpA0koQyu ktVfvKNFfS7yPR0BT8fX8nADuGWlZuVheeuY7YQyIj111k1ZT19Fz3aAaAoG9fTXlwBoSxjG 9ztHI+oRystWMDqbVFdRf5+4enPXpP28CBaPUWUxWZI5uat9+rF0sCEXVRf1IIX4rry4Ekl/ vfgQNcg8hjpJUNhLaV67l1aT5boYMvSViljPV+7y4AZixbWQi0bXQURe3C9hH7jNoGYmwdBo p/KeXACmlyNawkySvI0CsUdzakUx/DqQWCHPu01PqddOACVTPXgJvxGsZ01/QCrF0senq16l klIPoNNDwA4h3BSbtyJRsK0xYMe2mq9teZYhz8OXAG4ZZL6TwJWsQlYu4skyBUYdXT7SGOv2 8ANrO28RbvPkZ8fYNxyCZVsyR81II0VJgB6D4cAJj2xhophPHjrAkUKBrakI0Qhl9pn05FR8 OANZ2jgTGkRxlho4+roU2pTp1+o5z+n5PhwBgbP2+NdMXOOoKrf1qXmFBA1/T8/XgB5iMLj8 EZTi8fNEZwglL2Gm6u2CF17srcwD68AE/mJ/7JJ/zo/53AGO/N/ZH/50f87gDPfm/sj8/wDa j/ncAYM0xGhqyAHlqGjB/gfgCPz4HG2Hiee5kw0I6Aq5SaMHQk+4JOoYjX1PE0FTZLiaTw9v 57IrEI1iYrkGDHoKkMX7vV1e3QnXnz19eFBUV/e/EAZ5DENcbH2JABVlrQ12cCORkcBnVulq sx0BI9xkA/c+IDKKvKIWMqF5ZXME4ZCw6zr0tqMaOogqPUdPM668CTSK2tYRGmhkk6ilmTqE kbxt7lXTG6FWAB1dfjy4EG+OmhZJiGmi6ltydyL78AbRtdMcp6tV1KghvTnwBiOjZjkZyw7U g7j2FVRIiuNSyqccAxHQVC66kevqOACuJgx8XWaduzYMdftJHYrJAiICre0ivCRrqOWun5OA KnyHjLbNXdG4s9Q3du/FXsvZs2L8OPgumBf0j9ccXbrEGPrLugBYEnUa6jgSPE8MX80sM2H8 n7tqQVC1WbuSzxM6aKwVO52j0gNproy6/lUghUK3fAlWbMXs1jd6bkxFrIx1ktjH3vl1kapF HErt0KCSVjGvP11+08BURn/AVfL5HM5WjvHPYm1l54rZjq2dIEmhiWJSUHSW1KKzHqBOg5jg Kjp/DOUnxGKx8/kjda2sfHOlm7XvtE1qSxKJeuQN1t+j0KRDr9qnQ66cAa8j4Plt06GKp71z uPxcTWJcstey62cjJYr1q5M8quoI1gaRgUPU0jenPUBrn/FMWYt5G5L5B3dVp3ZXSTHV7U4q xh+6pjji7Z0j58vUch+TgDS3ieimKhrf483Yl6GZ7jZkT2BfljsRVqzRNJ2uph/V0On3hqeA Nm2/F/4BnMZmcbv3ctuEXjNfoXzZnrXDKhBEiqsYViSrNI4YaD09CskMqzx3488exVsjld2L Bezdm7dZ5pyyII4pW5JEzclUfH908cVuLn5m5KUm0uB1Wz27s2lBJaqupS31EbW2w3y17alW rBBBYhkmp11CwzxFxydWBHUQPbqDxi2LlbutSrTgOZQjK2nHNYM+gGg/9347k5UZ3VppLj7H zUP4ilaDt0pO2sjJo+hRn56kn9zlwAJEWNpRsLNOO93EMqp36sDs5PQSSrjny9ddB6cAEI7m HrvJHFioY/0aWPfahAZFjMysdXOgBU/6/TgDE9/AVIoWTGxHtAvEi24VKp1uwZdZANCQW/f4 AR3cAIGsfhEHKDV42twk/LydKKQesroxPTrrwAQx0+OuT3bFGgkbRwiJb8UsUokj1UBfYxI5 KNOofDgAbkE2X+J2o48fUt2WeQ3376RSiwrM7KyuV156nUHkeBIzq2drVLcc1XC1UkqMhhlW 7CXRwrfeUvyK6n7eBAag3xFYUulaFYl6u6zXqw6Oj1LaMfb8df4OAMjeyiRoJaaJN1BEUXKx 6j+cB7gdR9mnAC495JMUjjqxmdmVTD85XDKzN09J93r8eAHTZKpmsJcknlhr0+nty2FkSxEu vrqRy0HLgCJtWwcJSaW7TKe9I7J7HbJjI1ProB0Np7j/AK+BIqxWolJXvR10mVZCB1VXcpCi 9Sj9IPVQWJ+A4AMYubb724q1WhAlvqQxCOeJndUKv3AquSVXVW4lEMoyxHmsdVt42bG0DYMN spYkAaTots3SCyN1BCPvdJ+966ccNC1ctVhc7NW36quh3du9aupTtdqlF8SrmU55DzWUzVPG Y6/RpJlXQvLTqqI/fEzKks5XX1C9Wmp0Hrxkjbdy4tOLyIu3YWoapKirVncn978docKPIcRS uQ07k3eE614owYrE8K9IU6arG6qfvHnpwBtiwdGF4nR7JMLmRQ9uy4LMdT1BpCG/cbXgDwwd BeoK1kBh06C3ZAUf7I7nt/5PAArI4LOu8v4VcghQypJEbD3pGCohUhuiynqx15aAj1Hx4AZ1 ttbqEpFvJ1DWZi7LXS/E4bpbTpJusFHWQxA9Ry+PIAjSxeXrWLFm3LC0EsLK0MTWpGMpk6gw 70zIq9P5oj119DpwANnqZNrdlWr2npyz2Ce29qMtq2i6EXVAXQDTRAP5IHAGo1M8vVG8dqQq paORWs+19dQOd73A6sNTz9NeAMPTzAWXpr23Q9pWBayZGUdIbpLX9PUa/wCvXgAu+38gol7F se4MYlea97ZCx0Ootfd6WIIGnPQ/DgBJwOYNl5fnI+3KCGXuXxoenQEL810/wDgB1Vw92tib VETJ8xMT2nWS10IpAUDVp2kXQD8x14AHS4XL04O6kqWGjREEcPzncfRhzYNcUPprz6jr08uA A6rm4JOh8Tk2MMjdM9eR0hYykEMkZyJPQpJ1Ur+4OBIWQZdstC7V7egshXbWVYVhJLasPmyj cuWqodPQj4cCCAbh8YZ7cglnYX8TfWB4K8uPu1kKhpQdUYrzZlA++unw/Lx43FuN+KjJZcTL tbs9vNyg8wHtb6aadWS7ZyV/IrkJ0CG7derbkcSBg4XtqOnTQczzOvGG1trdvJYnvcbi5ewk 8PeXLp+X/wDL8bJrlc7uyFlshm66rVEuNweNmx89itDP2pbPzKlm7iksoKKenXT/AE8YL9x2 7cpLgjZsWlcuQi/pOhFLe6amMw0WTkmxdtepYRIatQLLMBoV0jj1115nT04o7fMbzaq0dXPl G14KXtZEty+WS+Puz4Grj6Fyq1YiF6NaYlX1SUMHj5Dq0ZD+6OLiF2UlUo7mzt27iji6otzL YfetS5uGbD47aViq8tB9uVMmixmOqKbG73+0qMGaYKyHVgEJ+zTjbKgFVK/k2bDZSe/idhR5 iJaL4WKlr2ppTo9yKwZS4VVXknQdT66jgArszB+SbmbE+/dubTqbXXHTSK2EjMsr3meIxgmX q9ioJOa+uvP4cAQHfmX3JF5D2rs3bVqnhMdk8VkcpduDFUbssk1OevEkYE8RCqBN1EjmeNXd 3najVdJm2ttXZtN8AhlNv7/w0cVqfedGWML1vENu4tNVA1JYmM6afk4rL29vQjw9j+csbOzt TlTEi/087+3R5H8Xb93FucYWXM4OxlKuCzD0KtSiwq1o5IpJAkenQjvzbQ+089dOLyLrFNlM 8JNVqbz5B3VHYx1SO141uTkCrOiCRi9nUBjN219nSI5dCOlSx00+6DJ6Lo2rm/FG57FLC0Xw 2V3HLUexaXG1uqt11e0lgq3SyoFeZdEd+rQ/HgDHkbG47AYypYwuNpV5pJysrfKwyExrGzae 9SBzHAgCbAqjObVoZnORVZspdgjtSwVqlRK8IsDrWNGEJLdKkDUnmefAFY788kZTbm/dvYLG 08fBhcnfGJtQWaFdpzJYU9mSNxHyZXADKRoVP2jgA5vncedwkWw4sRY2zjrub/E2yQztECGc UbUBTR4YiIx0FoTqy69zkeoDgSidJ5J8AR1akmQyuAWewkZZoFSSHrdA50dFYBQDrqW5D14A kO2cj4i3pcu0drLjMtPjkiluGrAHjjWdpET9J0dBJMT+0NqPj6jgQHdB/wC78AVJunJ1a2+s tjJ5GWe/gMIleMRvIH/TWw66qpVSR/KI40t62rM2ugsdik79quWopbJU8T/iTbkZxoG3spLe r2cb+mkMlu4OjV4yNBoVQszEDlqPt45m2/6cnTFUaZ9BuLHjQiW472GjopUVxXyVcyxpTQBl aISgMGYackKgpr69R+I4t7EnJ14IpL+mKkqKsvbgdxVimcyOUqYrJ11uYlqte9BLQEskE0la Kwg7jsnWGjlB5a6dWmvIji8OIHrbavOJQ1yoCwHbIx8R6WB9dGY/m+3TXgB5ToZenBIt7Ix2 4VikVYoqq1gCdCCNHbko1AHAFGb1x+Lllx17LCeBhVtVoL9R2injVu3I6h1IKhulST+Tip5j LS4N5Y+0seWrVqSzI/8AOYm5FatZPNZGvWoVwklV5JDDNH29WVhOh1IJ5uP9PFTcktDUs+Bd O3KqcfkC308bRp7V2Ta2u1RIsfka+TyMtOzD8xF27zKQkkJ++nR0qU/OHLjpNs5u3Wefw/6n Nbjw1dpDJL4/hgWJHt7aFSOWWLC4Cs4bqimTbskZFpX6y+mhLDUMdRz6uNgxDvbeFwlK0H2h j8FjciOr3VsJJRYVz0hwWBQhuS/Hn9nABnfVM3alCFwGYSsWGnI+wg8jry58CDni7gE2lhLO Qj3Nlop8BRs4mjjKzy9hIxCY0Va8Q1d+oqVfUn00004Aq5PHOEzW4dg4fZy2Js1ZyFXPZK3J LIHh+SdZLR1ldulwobq6WJ1+HAHZTw46pi8bDehxLO5sQhMqAHKNbSXpjJVvb1KrkfylQ/Dg AFFtbYVy7Xx9bbezJ3kUmKH5SLusgiKRBB2Dy7Og1H5uunIcCSX7e242BsxPRwWExaWFK5OX FxdiRujUxgdMSdQ6mP3vTnwIN/8Ae/AHMf1AZzduB3zQTbmV23ToZXE4lcvFmM9jsRkVhpWJ 5QYYrk0Z0fq0EnSRy04wzhqqmsGjI5tRjp7ydfcBN6ZbG7gx9LI4byBs/HZ5B3JKrbixMhhZ vvIJu+Af/mA45yHLb0W40Tj6TsYc4sStrVWMqY4cSt83sbEwQYyfHeQ9o5TPWYrM2dtNubEw 1YpJZUMUEQeYO5VULM/JeegHx4vIbXRDB4lPc5hG5dq12eB25X85+EoIIo5PJG1hKqKr6ZrH nmqgf03G6UZs/wA+fB//AOydr/8ArVD9twFBMvnTwpLFJHD5J2t3WVgmubx45kcvWbgKHDHi 2PyJ/jls55X8pbcyOJgx9wVILe8cXZqm24XoTsRWmUCQAp1dHtB/Jpxg3VrxbbXHgZdrPwri lR04kv3VnZ9w0b2MwWW2Zga8lWRrFqXd2FmsWpIlPZqwLHN0oGbTWSU6Kup0J04r48v1STm8 OgtL3MVSkE/Wbvpt3Ju7aIy+1/KXkvadTbb4WxTwOfj3NiLmRo23aNYlQx2Szoq9bjufd6QA wHLi5bKJRo60Oo8D5l8M4bEVcbc8sbdylqBSJb9nN0DLKzMW1P6c+mugGvpx5MlAj/nz4P8A /wBk7X/9aoftuAoMr/mvwfceAnyPtdkjLE/99UPUgaf9dwFCq/Ju7/E+WsfN7d3RtHPxWl67 1C1uHE1QllF6EmheWVtGK+2Tl9hHx4Chy/uCl5QbN1d0bO33s3bl3FydnB0sbu7Dj5WsyuZX dnnVX7hbpZdNDz1GmnAih154q8y42La22LPlfyps6PdMNO/BuWhWy2IZJ7L3Aac6yV5gqlYF PWE9pZ/TlyE0LE/z28Gg6/5kbW1Hofxmh+24Chn/AD58H6gf5k7XJPIAZqh+24Cge61/lD/x bq9fh9vAgeV3Iq1RLDVLdmPoMsujlenlyMZ04A2dcf8AQUv1w/ZcAe64/wCgpfrh+y4ASXr/ ABgofrh+y4Ax11v6Ch+uH7LgSZD1/hBQ/emH7LgQL60/oKWn/wBb/suAPB0+EFL9d/2XAGGe P86Cl+/MP2XACOut/QUP1w/ZcAe6639BQ/XD9lwB7rrf0FD9cP2XACg8Pwgo/vTD9lwAvrX+ gp/rv+y4AQzw/nQUf35h+y4AT11v6Ch+uH7LgDxer8YMf+uX9lwAP6rH8hP/ABTX75/3n8n7 vp/tfwcAf//Z --K56A5480Hh4a8J8i462640Y42S3-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jun 10 05:43:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18610 for ; Tue, 10 Jun 2003 05:43:08 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5A9ghH02735 for sipping-archive@odin.ietf.org; Tue, 10 Jun 2003 05:42:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A9ghB02732 for ; Tue, 10 Jun 2003 05:42: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 FAA18606 for ; Tue, 10 Jun 2003 05:42:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PfcK-0003JR-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 05:40:36 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PfcK-0003JN-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 05:40:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A9egB02581; Tue, 10 Jun 2003 05:40:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A9ZiB01410 for ; Tue, 10 Jun 2003 05:35: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 FAA18528 for ; Tue, 10 Jun 2003 05:35:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PfVa-0003Hg-00 for sipping@ietf.org; Tue, 10 Jun 2003 05:33:38 -0400 Received: from harjus.tutpro.com ([192.98.100.3] ident=mail) by ietf-mx with esmtp (Exim 4.12) id 19PfVZ-0003Hb-00 for sipping@ietf.org; Tue, 10 Jun 2003 05:33:37 -0400 Received: from jh by harjus.tutpro.com with local (Exim 3.35 #1 (Debian)) id 19PfXQ-0000BV-00 for ; Tue, 10 Jun 2003 12:35:32 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16101.42596.853961.933496@harjus.tutpro.com> Date: Tue, 10 Jun 2003 12:35:32 +0300 To: sipping@ietf.org X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen Content-Transfer-Encoding: 7bit Subject: [Sipping] refer and pstn Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk 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 noticed that some sip/pstn gws on the market support refer method. i consider this very dangerous because pstn gw has no way that i know of asking the original pstn caller to accept or reject the referral. things get even worse when these implementations do not send the resulting new request to the proxy, but directly to pstn. if any of the vendors of these gws are listening, i would like to understand what is your logic when you have implemented refer method UAS or if the authors of the refer rfc are listening, how you thought it could be properly used by sip UASes that are pstn gws. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jun 10 07:51:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21477 for ; Tue, 10 Jun 2003 07:51:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5ABopQ12873 for sipping-archive@odin.ietf.org; Tue, 10 Jun 2003 07:50:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ABopB12870 for ; Tue, 10 Jun 2003 07:50: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 HAA21378 for ; Tue, 10 Jun 2003 07:50:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PhcN-00041p-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 07:48:47 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PhcM-00041m-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 07:48:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ABngB12802; Tue, 10 Jun 2003 07:49:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ABmTB12728 for ; Tue, 10 Jun 2003 07:48: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 HAA21141 for ; Tue, 10 Jun 2003 07:48:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pha5-00040k-00 for sipping@ietf.org; Tue, 10 Jun 2003 07:46:25 -0400 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19Pha4-00040S-00 for sipping@ietf.org; Tue, 10 Jun 2003 07:46:24 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by auemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h5ABlsg11619 for ; Tue, 10 Jun 2003 06:47:54 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jun 2003 12:47:52 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00439ED51@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Rohan Mahy'" , "'Jonathan Rosenberg'" Cc: alan.johnston@wcom.com, "'sipping@ietf.org'" Subject: RE: [Sipping] proposed enhancement to dialog package Date: Tue, 10 Jun 2003 12:47:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , I fail to see how thw property you are proposing correlates in some way to any concept of hold. I agree that "hold" has many meanings, based on which type of signalling you are using. To clarify, the prime function of hold in the PSTN was never to interrupt the communication, that was a side effect of grabbing the access resources to signal to another party. Thus for ISDN, hold therefore was only a removal of access resources (the bearer) so that that bearer could be reused for another call; again the side effect was to interrupt the communication. The sole function of hold for SIP is to interrupt the communication. Certainly, if an ISDN user places another user on hold, I would regard neither user as "passive" as you seem to be defining here. If we are going to do this, can we make sure we define the semantics correctly. Otherwise we will surely create confusion, particularly if people try and equate this concept with that of hold, and in particular with the PSTN concept. regards Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: 03 June 2003 22:18 > To: 'Jonathan Rosenberg' > Cc: rohan@cisco.com; alan.johnston@wcom.com; 'sipping@ietf.org' > Subject: [Sipping] proposed enhancement to dialog package > > > Hi, > > There have been many requests for the dialog package to express the > concept of hold. The problem is that nobody had an especially good > definition of what "on-hold" meant. Some suggested that all media > streams being inactive implied that you are "held", but this doesn't > work for a service such as music-on-hold. > > I believe that folks actually want a slightly different concept--that > the semantics we want instead are already described in the > call control > framework: > > > Participants may also be active or passive. Active participants are > > expected to be intelligent enough to leave a conversation > space when > > they no longer desire to participate. (An attentive human > participant > > is obviously active.) Some robotic participants (such as a voice > > messaging system, an instant messaging agent, or a voice dialog > > system) may be active participants if they can leave the > conversation > > space when there is no human interaction. Other robots (for example > > our tone generating robot from the previous example) are passive > > participants. A human participant "on-hold" is passive. > > I think we should add a new attribute to the dialog package that > expresses this property. My proposal is to express this property only > for the local side of each dialog by adding an attribute to the state > tag in the dialog-info notification body. The example below > includes a > proposed (optional) participation attribute in the state tag. > > > version="3" > state="partial" > entity="sip:caller@bar.com"> > local-tag="123" remote-tag="789" direction="initiator"> > confirmed > > > > Participation status could change during a session without otherwise > changing the state of the call. > > > version="4" > state="partial" > entity="sip:caller@bar.com"> > local-tag="123" remote-tag="789" direction="initiator"> > confirmed > > > > > this proposal would of course require a small addition to the XML > schema to support the new attribute: > > > > > > > > > > > comments welcome. thanks, > -rohan > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jun 10 09:18:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28370 for ; Tue, 10 Jun 2003 09:18:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5ADHjq20687 for sipping-archive@odin.ietf.org; Tue, 10 Jun 2003 09:17:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ADHjB20684 for ; Tue, 10 Jun 2003 09:17: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 JAA28308 for ; Tue, 10 Jun 2003 09:17:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PiyQ-0005tL-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 09:15:38 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PiyP-0005tF-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 09:15:37 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ADGEB20543; Tue, 10 Jun 2003 09:16:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ADD9B20366 for ; Tue, 10 Jun 2003 09:13:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27922 for ; Tue, 10 Jun 2003 09:13:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pity-0005l5-00 for sipping@ietf.org; Tue, 10 Jun 2003 09:11:03 -0400 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx with esmtp (Exim 4.12) id 19Pitx-0005kW-00 for sipping@ietf.org; Tue, 10 Jun 2003 09:11:02 -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 h5ADCWA24792 for ; Tue, 10 Jun 2003 09:12:32 -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 MLYHWGSV; Tue, 10 Jun 2003 09:12:32 -0400 Received: from nortelnetworks.com (acart1dn.ca.nortel.com [47.129.129.97]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA0SCW; Tue, 10 Jun 2003 09:12:31 -0400 Message-ID: <3EE5D93C.6070104@nortelnetworks.com> Date: Tue, 10 Jun 2003 09:12:28 -0400 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: sipping@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Virus With My Address Forged As Originator Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk 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 E-mail with title "FlashName" contains a virus: Exploit.IFrame.FileDownload (Kaspersky,CA(Vet)) -- as probably most people recognize, if they even saw it. (I've had a few bounces from virus filters.) According to the headers, it originated on a PPPoX connection with IP 66.138.147.160 (address range owned by SBC), then passed through 206.46.170.59, (address range owned by Genuity). My suspicion is that the former is a forgery and the latter is the true origin. Subscribers on those networks might want to check out their machines. Tom Taylor _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jun 10 09:20:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28662 for ; Tue, 10 Jun 2003 09:20:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5ADKNo20883 for sipping-archive@odin.ietf.org; Tue, 10 Jun 2003 09:20:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ADKMB20880 for ; Tue, 10 Jun 2003 09:20: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 JAA28628 for ; Tue, 10 Jun 2003 09:20:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pj0y-0005zN-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 09:18:16 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Pj0x-0005zK-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 09:18:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ADHKB20633; Tue, 10 Jun 2003 09:17:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ADEkB20475 for ; Tue, 10 Jun 2003 09:14:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28029 for ; Tue, 10 Jun 2003 09:14:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PivY-0005mb-00 for sipping@ietf.org; Tue, 10 Jun 2003 09:12:40 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19PivX-0005lo-00 for sipping@ietf.org; Tue, 10 Jun 2003 09:12:39 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h5ADE6A21054 for ; Tue, 10 Jun 2003 08:14:07 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jun 2003 14:14:05 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00439ED53@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Henry Sinnreich'" , =?iso-8859-1?Q?=27Gunn?= =?iso-8859-1?Q?ar_Hellstr=F6m=27?= , "'Sipping@Ietf. Org'" , "'Sipforum-Discussion@Lists. Su. Se'" Subject: RE: [Sipping] Text support in SIP phones Date: Tue, 10 Jun 2003 14:14:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5ADEmB20476 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h5ADHKB20633 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5ADKMB20880 Content-Transfer-Encoding: 8bit I would suggest that treating these sort of things as MUST strength is best left to national regulatory requirements, along with other things like fitness for purpose and so on. I have no objection to their being mentioned. By the way, I understood this document was being progressed as authors individual submission, and was therefore not standards track. Any such MUST would surely need to be qualified anyway. If the purpose of the devise is such that it renders a textual devise irrelevant, then why require one to be fitted. Suppose we were designing a SIP phone for the totally blind, and this was designed to be worn as a headset, a text device would be irrelevant to such a user, and positioning such a device where it could be seen would require an extra box hanging out of the side of the product. regards Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com] > Sent: 27 May 2003 17:18 > To: 'Gunnar Hellström'; 'Sipping@Ietf. Org'; > 'Sipforum-Discussion@Lists. > Su. Se' > Cc: 'Henry Sinnreich' > Subject: RE: [Sipping] Text support in SIP phones > > > Gunnar, this all seems very reasonable, and I will try to insert it > properly. > > Henry > > > -----Original Message----- > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > On Behalf Of Gunnar Hellström > > Sent: Thursday, May 22, 2003 6:54 PM > > To: 'Sipping@Ietf. Org'; Sipforum-Discussion@Lists. Su. Se > > Cc: Henry Sinnreich > > Subject: [Sipping] Text support in SIP phones > > > > > > Sorry, I missed out the reference to the SIP device specification. > > > > Henry and all, > > > > Some time ago, I suggested addition of support for real time > > text communication to the SIP device specification > > > http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-00.txt > > > > This was the simple part of the proposal: > > > > > SIP-zz, digital text support: SIP telephone devices MUST support > > > real time text conversation using RFC 2793 [y] for the > > text stream. > > > It MUST be possible to use text simultaneously with voice. > > > > > > > > > > > > --------------------------------------------- > > > In 4.11 Ringer Behaviour : add the section below for the > > purpose of > > > deaf, hearing impaired, deaf-blind people and people in the > > garden and > > > noisy > > > locations: > > > > > > SIP Telephony devices MUST provide an external interface to an > > > external alerting system. > > > > > > > > > > > > Add to References > > > ----------------- > > > [y] G. Hellstrom: "RTP Payload for Text Conversation.", RFC 2793, > > > IETF, May 2000. > > > > > > -------------------------------------------------------------- > > > > The reception of this proposal was very positive. > > Now, I would like to see the final formulation, and check > > that we agree on it. > > > > I regard this requirement to be very light. In the Interface > > section ( e.g. > > Int-2) , there is already mentioning of mandatory text input > > mechanisms, and assumptions that a display would be normal, > > since handling of phone books and buddy lists are mandatory. > > To re-use these text interface devices during the call for > > standardised text conversation purposes seems straightforward. > > > > It could be wise to add the T.140 text presentation protocol > > as a codec to the codec section. The normal SDP used together > > with RFC2793 for text could also be specified. Do you want > to do that? > > > > > > ----- > > > > We also need to check the ideas around the other proposed > > requirements: The requirement to include text telephone modem > > in all designs where an RJ11 phone connector exists, and the > > requirement to support RFC 3351. I suggest that we start with > > the straightforward and mainstream requirement above. Is that > > accepted as it is? > > > > > > Regards > > > > Gunnar > > ------------------------------------------- > > Gunnar Hellström, Omnitor, Renathvägen 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 mailnull@www1.ietf.org Tue Jun 10 09:43: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 JAA29808 for ; Tue, 10 Jun 2003 09:43:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5ADhWM22975 for sipping-archive@odin.ietf.org; Tue, 10 Jun 2003 09:43:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ADhWB22972 for ; Tue, 10 Jun 2003 09: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 JAA29794 for ; Tue, 10 Jun 2003 09:43:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PjNN-0006Lz-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 09:41:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PjNM-0006Lw-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 09:41:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ADgWB22931; Tue, 10 Jun 2003 09:42:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ADfAB22876 for ; Tue, 10 Jun 2003 09: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 JAA29773 for ; Tue, 10 Jun 2003 09:41:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PjL5-0006LM-00 for sipping@ietf.org; Tue, 10 Jun 2003 09:39:03 -0400 Received: from m5tmail.m5t.com ([66.129.134.18]) by ietf-mx with esmtp (Exim 4.12) id 19PjL4-0006LJ-00 for sipping@ietf.org; Tue, 10 Jun 2003 09:39:02 -0400 Content-Class: urn:content-classes:message Subject: RE: [Sipping] refer and pstn MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 10 Jun 2003 09:39:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: Thread-Topic: [Sipping] refer and pstn thread-index: AcMvNUe7rpiDjItYRhi2n9YujIOdGgAHl/LQ From: "Pascal Dore" To: "Juha Heinanen" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5ADfAB22877 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I think about a scenario like someone who's calling to an enterprise PBX. This call is automatically forward to the receptionist. After asking to talk to Mister X, the receptionist transfer the incomming pstn caller to Mister X. So, if you want to reproduce this with a pstn gateway, the incoming pstn call can be automatically forward to the receptionist ip phone by the pstn-gateway and then, the receptionist with the ip phone will transfer (refer) the incoming call from the pstn-gateway to another sip UA in the company. (kind of IP-PBX scenario). Pascal.D -----Original Message----- From: Juha Heinanen [mailto:jh@tutpro.com] Sent: Tuesday, June 10, 2003 5:36 AM To: sipping@ietf.org Subject: [Sipping] refer and pstn i have noticed that some sip/pstn gws on the market support refer method. i consider this very dangerous because pstn gw has no way that i know of asking the original pstn caller to accept or reject the referral. things get even worse when these implementations do not send the resulting new request to the proxy, but directly to pstn. if any of the vendors of these gws are listening, i would like to understand what is your logic when you have implemented refer method UAS or if the authors of the refer rfc are listening, how you thought it could be properly used by sip UASes that are pstn gws. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jun 10 10:29:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02869 for ; Tue, 10 Jun 2003 10:29:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AET1A26482 for sipping-archive@odin.ietf.org; Tue, 10 Jun 2003 10:29:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AET1B26479 for ; Tue, 10 Jun 2003 10:29: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 KAA02834 for ; Tue, 10 Jun 2003 10:28:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pk5O-0006r6-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 10:26:54 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Pk5N-0006r3-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 10:26:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AERdB26369; Tue, 10 Jun 2003 10:27:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AEQWB26299 for ; Tue, 10 Jun 2003 10: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 KAA02722 for ; Tue, 10 Jun 2003 10:26:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pk2y-0006ph-00 for sipping@ietf.org; Tue, 10 Jun 2003 10:24:24 -0400 Received: from harjus.tutpro.com ([192.98.100.3] ident=mail) by ietf-mx with esmtp (Exim 4.12) id 19Pk2x-0006pd-00 for sipping@ietf.org; Tue, 10 Jun 2003 10:24:24 -0400 Received: from jh by harjus.tutpro.com with local (Exim 3.35 #1 (Debian)) id 19Pk4u-0000gu-00; Tue, 10 Jun 2003 17:26:24 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16101.60048.372701.682549@harjus.tutpro.com> Date: Tue, 10 Jun 2003 17:26:24 +0300 To: "Pascal Dore" Cc: Subject: RE: [Sipping] refer and pstn In-Reply-To: References: X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen 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 Pascal Dore writes: > So, if you want to reproduce this with a pstn gateway, the incoming > pstn call can be automatically forward to the receptionist ip phone > by the pstn-gateway and then, the receptionist with the ip phone will > transfer (refer) the incoming call from the pstn-gateway to another > sip UA in the company. (kind of IP-PBX scenario). that application is fine. problems start when refer-to points to pstn destination. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jun 10 10:45:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03640 for ; Tue, 10 Jun 2003 10:45:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AEjQO28596 for sipping-archive@odin.ietf.org; Tue, 10 Jun 2003 10:45:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AEjQB28593 for ; Tue, 10 Jun 2003 10: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 KAA03589 for ; Tue, 10 Jun 2003 10:45:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PkLG-00072W-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 10:43:18 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PkLF-00072T-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 10:43:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AEiLB28415; Tue, 10 Jun 2003 10:44:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AEdBB28175 for ; Tue, 10 Jun 2003 10:39:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03477 for ; Tue, 10 Jun 2003 10:39:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PkFD-0006zX-00 for sipping@ietf.org; Tue, 10 Jun 2003 10:37:03 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19PkFC-0006zR-00 for sipping@ietf.org; Tue, 10 Jun 2003 10:37:02 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h5AEdmbj007846; Tue, 10 Jun 2003 16:39:48 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 10 Jun 2003 16:40:27 +0200 Message-ID: From: "Christer Holmberg (LMF)" To: "'Juha Heinanen'" , Pascal Dore Cc: sipping@ietf.org Subject: RE: [Sipping] refer and pstn Date: Tue, 10 Jun 2003 16:38:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Hi, >>So, if you want to reproduce this with a pstn gateway, the incoming >>pstn call can be automatically forward to the receptionist ip phone >>by the pstn-gateway and then, the receptionist with the ip >>phone will transfer (refer) the incoming call from the pstn-gateway to another >>sip UA in the company. (kind of IP-PBX scenario). > >that application is fine. problems start when refer-to points to pstn >destination. Just to clarify. You said that the problem was that the calling PSTN user doesn't know he is being transfered, and/or he doesn't know where he's being transfered. Why is that problem different depending on if he is being transfered to another SIP user, or back to another PSTN user? Because there could be cases where there is no SIP signalling, if the MGC does a "local PSTN loopback"? In that case I guess it's more a signalling problem, and not a user problem (the user doesn't know where/when he's being transfered), right? Regards, Christer Holmberg Ericsson Finland > > -- juha > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jun 10 11:22:36 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 LAA05265 for ; Tue, 10 Jun 2003 11:22:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AFM8i31211 for sipping-archive@odin.ietf.org; Tue, 10 Jun 2003 11:22:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AFM8B31208 for ; Tue, 10 Jun 2003 11:22: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 LAA05239 for ; Tue, 10 Jun 2003 11:22:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pkuq-0007Mj-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 11:20:04 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Pkuq-0007Mg-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 11:20:04 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AFKZB31070; Tue, 10 Jun 2003 11:20:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AFHHB30904 for ; Tue, 10 Jun 2003 11:17: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 LAA05067 for ; Tue, 10 Jun 2003 11:17:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pkq9-0007KH-00 for sipping@ietf.org; Tue, 10 Jun 2003 11:15:13 -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 19Pkq8-0007Ji-00 for sipping@ietf.org; Tue, 10 Jun 2003 11:15:12 -0400 Received: from idc1exc0001.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 PAA10963; Tue, 10 Jun 2003 15:16:42 GMT Received: from idc1exc0004.corp.global.level3.com ([10.1.8.20]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 10 Jun 2003 09:16:42 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Sipping] refer and pstn Date: Tue, 10 Jun 2003 09:16:41 -0600 Message-ID: <3DB099919328BA41905F651A6EF83976B4DD64@idc1exc0004.corp.global.level3.com> Thread-Topic: [Sipping] refer and pstn Thread-Index: AcMvYpQYYuNbfi9DTSa0XtmvhsxuAAAAERBA From: "Hearty, John" To: "Juha Heinanen" , "Pascal Dore" Cc: X-OriginalArrivalTime: 10 Jun 2003 15:16:42.0452 (UTC) FILETIME=[4C476140:01C32F63] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5AFHHB30905 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > that application is fine. problems start when refer-to points to pstn > destination. I don't get it. How is that any different from call forwarding services already in the PSTN? They don't ask the caller before forwarding. What are the problems? _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jun 10 11:28:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05533 for ; Tue, 10 Jun 2003 11:28:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AFSGS31551 for sipping-archive@odin.ietf.org; Tue, 10 Jun 2003 11:28:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AFSGB31548 for ; Tue, 10 Jun 2003 11:28: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 LAA05490 for ; Tue, 10 Jun 2003 11:28:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pl0m-0007Pw-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 11:26:12 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Pl0l-0007Pt-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 11:26:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AFQlB31409; Tue, 10 Jun 2003 11:26:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AFJsB31026 for ; Tue, 10 Jun 2003 11:19: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 LAA05169 for ; Tue, 10 Jun 2003 11:19:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pksg-0007Le-00 for sipping@ietf.org; Tue, 10 Jun 2003 11:17:50 -0400 Received: from harjus.tutpro.com ([192.98.100.3] ident=mail) by ietf-mx with esmtp (Exim 4.12) id 19Pksf-0007Lb-00 for sipping@ietf.org; Tue, 10 Jun 2003 11:17:49 -0400 Received: from jh by harjus.tutpro.com with local (Exim 3.35 #1 (Debian)) id 19Pkua-0000jS-00; Tue, 10 Jun 2003 18:19:48 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16101.63252.493598.732927@harjus.tutpro.com> Date: Tue, 10 Jun 2003 18:19:48 +0300 To: "Christer Holmberg (LMF)" Cc: Pascal Dore , sipping@ietf.org Subject: RE: [Sipping] refer and pstn In-Reply-To: References: X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen 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 Christer Holmberg (LMF) writes: > You said that the problem was that the calling PSTN user doesn't know > he is being transfered, and/or he doesn't know where he's being > transfered. Why is that problem different depending on if he is being > transfered to another SIP user, or back to another PSTN user? the problem is quite different from the operator's point of view who is running the pstn gw. if pstn gw gets a refer, it must somehow know that the referred-by is not spoofed and that the referrer is allowed to initiate a call to the refer-to number. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jun 10 11:28: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 LAA05548 for ; Tue, 10 Jun 2003 11:28:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AFSU331571 for sipping-archive@odin.ietf.org; Tue, 10 Jun 2003 11:28:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AFSUB31568 for ; Tue, 10 Jun 2003 11:28: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 LAA05500 for ; Tue, 10 Jun 2003 11:28:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pl10-0007Q9-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 11:26:26 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Pl0z-0007Q6-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 11:26:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AFR2B31453; Tue, 10 Jun 2003 11:27:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AFKoB31084 for ; Tue, 10 Jun 2003 11:20:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05176 for ; Tue, 10 Jun 2003 11:20:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pkta-0007Lk-00 for sipping@ietf.org; Tue, 10 Jun 2003 11:18:46 -0400 Received: from harjus.tutpro.com ([192.98.100.3] ident=mail) by ietf-mx with esmtp (Exim 4.12) id 19PktZ-0007Lh-00 for sipping@ietf.org; Tue, 10 Jun 2003 11:18:46 -0400 Received: from jh by harjus.tutpro.com with local (Exim 3.35 #1 (Debian)) id 19PkvQ-0000jh-00; Tue, 10 Jun 2003 18:20:40 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16101.63304.192326.38608@harjus.tutpro.com> Date: Tue, 10 Jun 2003 18:20:40 +0300 To: "Hearty, John" Cc: "Pascal Dore" , Subject: RE: [Sipping] refer and pstn In-Reply-To: <3DB099919328BA41905F651A6EF83976B4DD64@idc1exc0004.corp.global.level3.com> References: <3DB099919328BA41905F651A6EF83976B4DD64@idc1exc0004.corp.global.level3.com> X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen 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 Hearty, John writes: > I don't get it. How is that any different from call forwarding services > already in the PSTN? They don't ask the caller before forwarding. What > are the problems? see my reply to another message. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jun 10 11:33:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05717 for ; Tue, 10 Jun 2003 11:33:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AFWxe31869 for sipping-archive@odin.ietf.org; Tue, 10 Jun 2003 11:32:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AFWxB31866 for ; Tue, 10 Jun 2003 11:32: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 LAA05678 for ; Tue, 10 Jun 2003 11:32:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pl5K-0007Rw-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 11:30:54 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Pl5K-0007Rt-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 11:30:54 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AFW3B31788; Tue, 10 Jun 2003 11:32:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AFSMB31564 for ; Tue, 10 Jun 2003 11: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 LAA05496 for ; Tue, 10 Jun 2003 11:28:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pl0r-0007Q2-00 for sipping@ietf.org; Tue, 10 Jun 2003 11:26:17 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19Pl0q-0007Pz-00 for sipping@ietf.org; Tue, 10 Jun 2003 11:26:16 -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; Tue, 10 Jun 2003 16:31: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="us-ascii" Subject: RE: [Sipping] refer and pstn Date: Tue, 10 Jun 2003 16:28:10 +0100 Message-ID: <45730E094814E44488F789C1CDED27AE01E22BB0@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Sipping] refer and pstn Thread-Index: AcMvZLIQg94a3tgaSiKkONnNpkV5qgAAB6iA From: "Chris Boulton" To: "Juha Heinanen" , "Christer Holmberg (LMF)" Cc: "Pascal Dore" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5AFSMB31565 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Are these not security issues rather than base protocol problems. Chris. >-----Original Message----- >From: Juha Heinanen [mailto:jh@tutpro.com] >Sent: 10 June 2003 16:20 >To: Christer Holmberg (LMF) >Cc: Pascal Dore; sipping@ietf.org >Subject: RE: [Sipping] refer and pstn > >Christer Holmberg (LMF) writes: > > > You said that the problem was that the calling PSTN user doesn't know > > he is being transfered, and/or he doesn't know where he's being > > transfered. Why is that problem different depending on if he is being > > transfered to another SIP user, or back to another PSTN user? > >the problem is quite different from the operator's point of view who is >running the pstn gw. if pstn gw gets a refer, it must somehow know that >the referred-by is not spoofed and that the referrer is allowed to >initiate a call to the refer-to number. > >-- juha >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jun 10 11:33:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05735 for ; Tue, 10 Jun 2003 11:33:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AFX4s31890 for sipping-archive@odin.ietf.org; Tue, 10 Jun 2003 11:33:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AFX4B31887 for ; Tue, 10 Jun 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 LAA05682 for ; Tue, 10 Jun 2003 11:33:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pl5P-0007S3-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 11:30:59 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Pl5P-0007S0-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 11:30:59 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AFVtB31758; Tue, 10 Jun 2003 11:31:55 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AFOlB31327 for ; Tue, 10 Jun 2003 11:24: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 LAA05323 for ; Tue, 10 Jun 2003 11:24:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PkxP-0007Nt-00 for sipping@ietf.org; Tue, 10 Jun 2003 11:22:43 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by ietf-mx with esmtp (Exim 4.12) id 19PkxO-0007Ne-00 for sipping@ietf.org; Tue, 10 Jun 2003 11:22:42 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h5AFO6I2026658; Tue, 10 Jun 2003 08:24:06 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHY92078; Tue, 10 Jun 2003 08:19:19 -0700 (PDT) Date: Tue, 10 Jun 2003 08:25:05 -0700 Subject: Re: [Sipping] proposed enhancement to dialog package Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'Jonathan Rosenberg'" , alan.johnston@wcom.com, "'sipping@ietf.org'" To: "Drage, Keith (Keith)" From: Rohan Mahy In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439ED51@en0033exch001u.uk.lucent.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 Hi Keith, Hold as a UI concept significantly predated the development of ISDN. In any case, an ISDN user (Alice) who requests an ISDN hold is still a passive participant by my definition. When Alice's call is connected to a conference server and all the active participants say "ok, we're leaving now, good bye", Alice is not active enough to be able to hang up. I agree that whatever we do, we need to describe the semantics very crisply. thanks, -rohan On Tuesday, June 10, 2003, at 04:47 AM, Drage, Keith (Keith) wrote: > I fail to see how thw property you are proposing correlates in some > way to any concept of hold. I agree that "hold" has many meanings, > based on which type of signalling you are using. > > To clarify, the prime function of hold in the PSTN was never to > interrupt the communication, that was a side effect of grabbing the > access resources to signal to another party. Thus for ISDN, hold > therefore was only a removal of access resources (the bearer) so that > that bearer could be reused for another call; again the side effect > was to interrupt the communication. The sole function of hold for SIP > is to interrupt the communication. > > Certainly, if an ISDN user places another user on hold, I would regard > neither user as "passive" as you seem to be defining here. > > If we are going to do this, can we make sure we define the semantics > correctly. Otherwise we will surely create confusion, particularly if > people try and equate this concept with that of hold, and in > particular with the PSTN concept. > > regards > > Keith > > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > >> -----Original Message----- >> From: Rohan Mahy [mailto:rohan@cisco.com] >> Sent: 03 June 2003 22:18 >> To: 'Jonathan Rosenberg' >> Cc: rohan@cisco.com; alan.johnston@wcom.com; 'sipping@ietf.org' >> Subject: [Sipping] proposed enhancement to dialog package >> >> >> Hi, >> >> There have been many requests for the dialog package to express the >> concept of hold. The problem is that nobody had an especially good >> definition of what "on-hold" meant. Some suggested that all media >> streams being inactive implied that you are "held", but this doesn't >> work for a service such as music-on-hold. >> >> I believe that folks actually want a slightly different concept--that >> the semantics we want instead are already described in the >> call control >> framework: >> >>> Participants may also be active or passive. Active participants are >>> expected to be intelligent enough to leave a conversation >> space when >>> they no longer desire to participate. (An attentive human >> participant >>> is obviously active.) Some robotic participants (such as a voice >>> messaging system, an instant messaging agent, or a voice dialog >>> system) may be active participants if they can leave the >> conversation >>> space when there is no human interaction. Other robots (for example >>> our tone generating robot from the previous example) are passive >>> participants. A human participant "on-hold" is passive. >> >> I think we should add a new attribute to the dialog package that >> expresses this property. My proposal is to express this property only >> for the local side of each dialog by adding an attribute to the state >> tag in the dialog-info notification body. The example below >> includes a >> proposed (optional) participation attribute in the state tag. >> >> >> > version="3" >> state="partial" >> entity="sip:caller@bar.com"> >> > local-tag="123" remote-tag="789" direction="initiator"> >> confirmed >> >> >> >> Participation status could change during a session without otherwise >> changing the state of the call. >> >> >> > version="4" >> state="partial" >> entity="sip:caller@bar.com"> >> > local-tag="123" remote-tag="789" direction="initiator"> >> confirmed >> >> >> >> >> this proposal would of course require a small addition to the XML >> schema to support the new attribute: >> >> >> >> >> >> >> >> >> >> >> comments welcome. thanks, >> -rohan >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP >> > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jun 10 11:43:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06100 for ; Tue, 10 Jun 2003 11:43:08 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AFge200985 for sipping-archive@odin.ietf.org; Tue, 10 Jun 2003 11:42:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AFgeB00982 for ; Tue, 10 Jun 2003 11:42: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 LAA06096 for ; Tue, 10 Jun 2003 11:42:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PlEi-0007Y0-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 11:40:36 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PlEh-0007Xx-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 11:40:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AFfMB00862; Tue, 10 Jun 2003 11:41:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AFZrB31988 for ; Tue, 10 Jun 2003 11:35: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 LAA05792 for ; Tue, 10 Jun 2003 11:35:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pl88-0007Tj-00 for sipping@ietf.org; Tue, 10 Jun 2003 11:33:48 -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 19Pl87-0007Tb-00 for sipping@ietf.org; Tue, 10 Jun 2003 11:33:48 -0400 Received: from idc1exc0001.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 PAA22355; Tue, 10 Jun 2003 15:35:19 GMT Received: from idc1exc0004.corp.global.level3.com ([10.1.8.20]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 10 Jun 2003 09:35:19 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Sipping] refer and pstn Date: Tue, 10 Jun 2003 09:35:15 -0600 Message-ID: <3DB099919328BA41905F651A6EF83976B4DD65@idc1exc0004.corp.global.level3.com> Thread-Topic: [Sipping] refer and pstn Thread-Index: AcMvY94TxUZkCZRkRLeH0zZiBDIFTQAAR7qw From: "Hearty, John" To: "Juha Heinanen" Cc: "Pascal Dore" , X-OriginalArrivalTime: 10 Jun 2003 15:35:19.0069 (UTC) FILETIME=[E5D59CD0:01C32F65] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5AFZrB31989 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Juha, Perhaps I missed some other reply, the below is the only reply I saw from you on this thread, which explains nothing. Taking apart the paragraph from your original post: >i have noticed that some sip/pstn gws on the market support refer method. >i consider this very dangerous because pstn gw has no way that i know of >asking the original pstn caller to accept or reject the referral. Again, current PSTN based call forwarding services also do not ask the original PSTN caller to accept or reject the forward. What's different here? >things get even worse when these implementations do not send the resulting new request to the proxy, but directly to pstn. Please explain what is "worse". You don't describe any actual problem here. John > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com] > Sent: Tuesday, June 10, 2003 9:21 AM > To: Hearty, John > Cc: Pascal Dore; sipping@ietf.org > Subject: RE: [Sipping] refer and pstn > > Hearty, John writes: > > > I don't get it. How is that any different from call forwarding > services > > already in the PSTN? They don't ask the caller before forwarding. > What > > are the problems? > > see my reply to another message. > > -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jun 10 11:50:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06289 for ; Tue, 10 Jun 2003 11:50:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AFoK401324 for sipping-archive@odin.ietf.org; Tue, 10 Jun 2003 11:50:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AFoJB01321 for ; Tue, 10 Jun 2003 11:50: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 LAA06272 for ; Tue, 10 Jun 2003 11:50:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PlM6-0007b1-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 11:48:15 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PlM6-0007ay-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 11:48:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AFlCB01192; Tue, 10 Jun 2003 11:47:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AFkLB01141 for ; Tue, 10 Jun 2003 11:46: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 LAA06185 for ; Tue, 10 Jun 2003 11:46:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PlIG-0007Zr-00 for sipping@ietf.org; Tue, 10 Jun 2003 11:44:16 -0400 Received: from harjus.tutpro.com ([192.98.100.3] ident=mail) by ietf-mx with esmtp (Exim 4.12) id 19PlIF-0007Zo-00 for sipping@ietf.org; Tue, 10 Jun 2003 11:44:16 -0400 Received: from jh by harjus.tutpro.com with local (Exim 3.35 #1 (Debian)) id 19PlK8-0000lk-00; Tue, 10 Jun 2003 18:46:12 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16101.64836.892342.884866@harjus.tutpro.com> Date: Tue, 10 Jun 2003 18:46:12 +0300 To: "Chris Boulton" Cc: "Christer Holmberg (LMF)" , "Pascal Dore" , Subject: RE: [Sipping] refer and pstn In-Reply-To: <45730E094814E44488F789C1CDED27AE01E22BB0@gbnewp0758m.eu.ubiquity.net> References: <45730E094814E44488F789C1CDED27AE01E22BB0@gbnewp0758m.eu.ubiquity.net> X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen 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 Chris Boulton writes: > Are these not security issues rather than base protocol problems. i don't know what they are. i was just asking, what were the makers of pstn gws thinking when they included refer UAS capability in their boxes. how is an operator of such a gw suppose to solve these kind of security issues. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jun 10 12:13:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07204 for ; Tue, 10 Jun 2003 12:13:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AGCXH04415 for sipping-archive@odin.ietf.org; Tue, 10 Jun 2003 12:12:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AGCXB04412 for ; Tue, 10 Jun 2003 12:12:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07197 for ; Tue, 10 Jun 2003 12:12:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Plhc-00000P-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 12:10:28 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Plhb-00000M-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 12:10:27 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AGBCB04332; Tue, 10 Jun 2003 12:11:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AG3CB02476 for ; Tue, 10 Jun 2003 12: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 MAA06755 for ; Tue, 10 Jun 2003 12:03:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PlYZ-0007io-00 for sipping@ietf.org; Tue, 10 Jun 2003 12:01:07 -0400 Received: from pmesmtp02.wcom.com ([199.249.20.2]) by ietf-mx with esmtp (Exim 4.12) id 19PlYY-0007i4-00 for sipping@ietf.org; Tue, 10 Jun 2003 12:01:06 -0400 Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0HG900469WIRDW@firewall.wcom.com> for sipping@ietf.org; Tue, 10 Jun 2003 16:01:39 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HG900201WIRGD@dgismtp01.wcomnet.com>; Tue, 10 Jun 2003 16:01:39 +0000 (GMT) Received: from hsinnreich2 ([166.50.153.75]) by dgismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HG90021IWIOCK@dgismtp01.wcomnet.com>; Tue, 10 Jun 2003 16:01:39 +0000 (GMT) Date: Tue, 10 Jun 2003 11:01:35 -0500 From: Henry Sinnreich Subject: RE: [Sipping] Text support in SIP phones In-reply-to: <475FF955A05DD411980D00508B6D5FB00439ED53@en0033exch001u.uk.lucent.com> To: "'Drage, Keith (Keith)'" , "'Henry Sinnreich'" , "=?iso-8859-1?Q?'Gunnar_Hellstr=F6m'?=" , "'Sipping@Ietf. Org'" , "'Sipforum-Discussion@Lists. Su. Se'" Message-id: <000501c32f69$93095600$ea3e573f@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 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5AG3DB02481 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h5AGBCB04332 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5AGCXB04412 Content-Transfer-Encoding: 8bit Keith, thanks for bringing balance, I believe, to this discussion. We could formulate soemthing like "SIP phones that have a text display and advertised as supporting the hearing or speech disabled MUST..." Would this be OK? Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of Drage, Keith (Keith) > Sent: Tuesday, June 10, 2003 8:14 AM > To: 'Henry Sinnreich'; 'Gunnar Hellström'; 'Sipping@Ietf. > Org'; 'Sipforum-Discussion@Lists. Su. Se' > Subject: RE: [Sipping] Text support in SIP phones > > > I would suggest that treating these sort of things as MUST > strength is best left to national regulatory requirements, > along with other things like fitness for purpose and so on. I > have no objection to their being mentioned. By the way, I > understood this document was being progressed as authors > individual submission, and was therefore not standards track. > > Any such MUST would surely need to be qualified anyway. If > the purpose of the devise is such that it renders a textual > devise irrelevant, then why require one to be fitted. Suppose > we were designing a SIP phone for the totally blind, and this > was designed to be worn as a headset, a text device would be > irrelevant to such a user, and positioning such a device > where it could be seen would require an extra box hanging out > of the side of the product. > > regards > > Keith > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > > -----Original Message----- > > From: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com] > > Sent: 27 May 2003 17:18 > > To: 'Gunnar Hellström'; 'Sipping@Ietf. Org'; > > 'Sipforum-Discussion@Lists. > > Su. Se' > > Cc: 'Henry Sinnreich' > > Subject: RE: [Sipping] Text support in SIP phones > > > > > > Gunnar, this all seems very reasonable, and I will try to insert it > > properly. > > > > Henry > > > > > -----Original Message----- > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > > On Behalf Of Gunnar Hellström > > > Sent: Thursday, May 22, 2003 6:54 PM > > > To: 'Sipping@Ietf. Org'; Sipforum-Discussion@Lists. Su. Se > > > Cc: Henry Sinnreich > > > Subject: [Sipping] Text support in SIP phones > > > > > > > > > Sorry, I missed out the reference to the SIP device specification. > > > > > > Henry and all, > > > > > > Some time ago, I suggested addition of support for real time > > > text communication to the SIP device specification > > > > > > http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-00.txt > > > > > > This was the simple part of the proposal: > > > > > > > SIP-zz, digital text support: SIP telephone devices MUST support > > > > real time text conversation using RFC 2793 [y] for the > > > text stream. > > > > It MUST be possible to use text simultaneously with voice. > > > > > > > > > > > > > > > > --------------------------------------------- > > > > In 4.11 Ringer Behaviour : add the section below for the > > > purpose of > > > > deaf, hearing impaired, deaf-blind people and people in the > > > garden and > > > > noisy > > > > locations: > > > > > > > > SIP Telephony devices MUST provide an external interface to an > > > > external alerting system. > > > > > > > > > > > > > > > > Add to References > > > > ----------------- > > > > [y] G. Hellstrom: "RTP Payload for Text Conversation.", > RFC 2793, > > > > IETF, May 2000. > > > > > > > > -------------------------------------------------------------- > > > > > > The reception of this proposal was very positive. > > > Now, I would like to see the final formulation, and check > > > that we agree on it. > > > > > > I regard this requirement to be very light. In the Interface > > > section ( e.g. > > > Int-2) , there is already mentioning of mandatory text input > > > mechanisms, and assumptions that a display would be normal, > > > since handling of phone books and buddy lists are mandatory. > > > To re-use these text interface devices during the call for > > > standardised text conversation purposes seems straightforward. > > > > > > It could be wise to add the T.140 text presentation protocol > > > as a codec to the codec section. The normal SDP used together > > > with RFC2793 for text could also be specified. Do you want > > to do that? > > > > > > > > > ----- > > > > > > We also need to check the ideas around the other proposed > > > requirements: The requirement to include text telephone modem > > > in all designs where an RJ11 phone connector exists, and the > > > requirement to support RFC 3351. I suggest that we start with > > > the straightforward and mainstream requirement above. Is that > > > accepted as it is? > > > > > > > > > Regards > > > > > > Gunnar > > > ------------------------------------------- > > > Gunnar Hellström, Omnitor, Renathvägen 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/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 mailnull@www1.ietf.org Tue Jun 10 13:49:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10742 for ; Tue, 10 Jun 2003 13:49:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AHnGW12505 for sipping-archive@odin.ietf.org; Tue, 10 Jun 2003 13:49:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AHnFB12502 for ; Tue, 10 Jun 2003 13: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 NAA10714 for ; Tue, 10 Jun 2003 13:49:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PnDA-0000wA-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 13:47:08 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PnD9-0000w7-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 13:47:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AHliB12421; Tue, 10 Jun 2003 13:47:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AHkoB12394 for ; Tue, 10 Jun 2003 13:46: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 NAA10578 for ; Tue, 10 Jun 2003 13:46:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PnAp-0000ua-00 for sipping@ietf.org; Tue, 10 Jun 2003 13:44:43 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19PnAo-0000uX-00 for sipping@ietf.org; Tue, 10 Jun 2003 13:44:42 -0400 Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5AHjan08505; Tue, 10 Jun 2003 13:45:36 -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 MLYHX2S1; Tue, 10 Jun 2003 13:45:35 -0400 Received: from nortelnetworks.com (acart1dn.ca.nortel.com [47.129.129.97]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA0S2S; Tue, 10 Jun 2003 13:45:36 -0400 Message-ID: <3EE61932.6000809@nortelnetworks.com> Date: Tue, 10 Jun 2003 13:45:22 -0400 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: Juha Heinanen CC: sipping@ietf.org Subject: Re: [Sipping] refer and pstn References: <16101.42596.853961.933496@harjus.tutpro.com> In-Reply-To: <16101.42596.853961.933496@harjus.tutpro.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 Could I understand what difference there is between accepting a REFER and call transfer in the legacy network? In both cases, the protocol for gaining PSTN user acceptance is for the transferor to ask -- it's not a protocol issue. Juha Heinanen wrote: > i have noticed that some sip/pstn gws on the market support refer > method. i consider this very dangerous because pstn gw has no way that > i know of asking the original pstn caller to accept or reject the > referral. things get even worse when these implementations do not send > the resulting new request to the proxy, but directly to pstn. > > if any of the vendors of these gws are listening, i would like to > understand what is your logic when you have implemented refer method UAS > or if the authors of the refer rfc are listening, how you thought it > could be properly used by sip UASes that are pstn gws. > > -- juha > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jun 10 14:40:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12082 for ; Tue, 10 Jun 2003 14:40:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AIdlc16389 for sipping-archive@odin.ietf.org; Tue, 10 Jun 2003 14:39:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AIdlB16385 for ; Tue, 10 Jun 2003 14:39: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 OAA12071 for ; Tue, 10 Jun 2003 14:39:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Po03-0001Eh-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 14:37:39 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Po02-0001Ee-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 14:37:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AIcTB16355; Tue, 10 Jun 2003 14:38:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AIb7B15687 for ; Tue, 10 Jun 2003 14:37: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 OAA12032 for ; Tue, 10 Jun 2003 14:37:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PnxT-0001E5-00 for sipping@ietf.org; Tue, 10 Jun 2003 14:34:59 -0400 Received: from harjus.tutpro.com ([192.98.100.3] ident=mail) by ietf-mx with esmtp (Exim 4.12) id 19PnxS-0001E2-00 for sipping@ietf.org; Tue, 10 Jun 2003 14:34:59 -0400 Received: from jh by harjus.tutpro.com with local (Exim 3.35 #1 (Debian)) id 19Pnyh-0000qu-00; Tue, 10 Jun 2003 21:36:15 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16102.9503.506053.892241@harjus.tutpro.com> Date: Tue, 10 Jun 2003 21:36:15 +0300 To: Tom Taylor Cc: sipping@ietf.org Subject: Re: [Sipping] refer and pstn In-Reply-To: <3EE61932.6000809@nortelnetworks.com> References: <16101.42596.853961.933496@harjus.tutpro.com> <3EE61932.6000809@nortelnetworks.com> X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen 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 Tom Taylor writes: > Could I understand what difference there is between accepting a REFER > and call transfer in the legacy network? In both cases, the protocol > for gaining PSTN user acceptance is for the transferor to ask -- it's > not a protocol issue. for example, we have remote-party-id (or whatever the corresponding p header is that i have not seen anyone to implement). does that apply also to referred-by? is the proxy allowed to rewrite refer-to header for example after doing an enum query on it? -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jun 10 15:31:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14707 for ; Tue, 10 Jun 2003 15:31:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AJVQ819509 for sipping-archive@odin.ietf.org; Tue, 10 Jun 2003 15:31:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AJVQB19506 for ; Tue, 10 Jun 2003 15:31: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 PAA14685 for ; Tue, 10 Jun 2003 15:31:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Poo5-0001Yi-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 15:29:21 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Poo5-0001Yf-00 for sipping-web-archive@ietf.org; Tue, 10 Jun 2003 15:29:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AJTPB19350; Tue, 10 Jun 2003 15:29:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AJR5B19171 for ; Tue, 10 Jun 2003 15:27:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14488 for ; Tue, 10 Jun 2003 15:27:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pojs-0001WC-00 for sipping@ietf.org; Tue, 10 Jun 2003 15:25:00 -0400 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 19Pojr-0001W2-00 for sipping@ietf.org; Tue, 10 Jun 2003 15:24:59 -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 h5AJPof14855; Tue, 10 Jun 2003 12:25:51 -0700 (PDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jun 2003 12:25:50 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D208F15280@zsc3c030.us.nortel.com> From: "Francois Audet" To: "Tom-PT Taylor" , "'Juha Heinanen'" Cc: "'sipping@ietf.org'" Subject: RE: [Sipping] refer and pstn Date: Tue, 10 Jun 2003 12:25:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32F86.1A5FD6BC" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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_01C32F86.1A5FD6BC Content-Type: text/plain My take is that if you accept REFER without user acknowledgement, regarless of if the use is on PSTN or SIP, you need some sort of trusted relationship with the REFERer. It is not a PSTN gateway issue per se, but it is true that you typically would not have a built-in mechanism for getting end-user acknowledgement in the PSTN. > -----Original Message----- > From: Taylor, Tom-PT [CAR:5N00:EXCH] > Sent: Tuesday, June 10, 2003 10:45 > To: Juha Heinanen > Cc: sipping@ietf.org > Subject: Re: [Sipping] refer and pstn > > > Could I understand what difference there is between accepting > a REFER and call > transfer in the legacy network? In both cases, the protocol > for gaining PSTN user > acceptance is for the transferor to ask -- it's not a protocol issue. > > Juha Heinanen wrote: > > > i have noticed that some sip/pstn gws on the market support refer > > method. i consider this very dangerous because pstn gw has no way > > that i know of asking the original pstn caller to accept or > reject the > > referral. things get even worse when these implementations do not > > send the resulting new request to the proxy, but directly to pstn. > > > > if any of the vendors of these gws are listening, i would like to > > understand what is your logic when you have implemented > refer method > > UAS or if the authors of the refer rfc are listening, how > you thought > > it could be properly used by sip UASes that are pstn gws. > > > > -- juha > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sip@ietf.org for new developments of core SIP > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sip@ietf.org for new developments of core SIP > ------_=_NextPart_001_01C32F86.1A5FD6BC Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sipping] refer and pstn

My take is that if you accept REFER without user = acknowledgement,
regarless of if the use is on PSTN or SIP, you need = some sort
of trusted relationship with the REFERer. It is not = a PSTN
gateway issue per se, but it is true that you = typically would
not have a built-in mechanism for getting end-user = acknowledgement
in the PSTN.

> -----Original Message-----
> From: Taylor, Tom-PT [CAR:5N00:EXCH]
> Sent: Tuesday, June 10, 2003 10:45
> To: Juha Heinanen
> Cc: sipping@ietf.org
> Subject: Re: [Sipping] refer and pstn
>
>
> Could I understand what difference there is = between accepting
> a REFER and call
> transfer in the legacy network?  In both = cases, the protocol
> for gaining PSTN user
> acceptance is for the transferor to ask -- it's = not a protocol issue.
>
> Juha Heinanen wrote:
>
> > i have noticed that some sip/pstn gws on = the market support refer
> > method.  i consider this very = dangerous because pstn gw has no way
> > that i know of asking the original pstn = caller to accept or
> reject the
> > referral.  things get even worse when = these implementations do not
> > send the resulting new request to the = proxy, but directly to pstn.
> >
> > if any of the vendors of these gws are = listening, i would like to
> > understand what is your logic when you = have implemented
> refer method
> > UAS or if the authors of the refer rfc are = listening, how
> you thought
> > it could be properly used by sip UASes = that are pstn gws.
> >
> > -- juha
> > = _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the = application of SIP Use
> > sip-implementors@cs.columbia.edu for = questions on current sip Use
> > sip@ietf.org for new developments of core = SIP
> >
>
> = _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the = application of SIP
> Use sip-implementors@cs.columbia.edu for = questions on current
> sip Use sip@ietf.org for new developments of = core SIP
>

------_=_NextPart_001_01C32F86.1A5FD6BC-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jun 11 01:33:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29790 for ; Wed, 11 Jun 2003 01:33:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5B5WvM27075 for sipping-archive@odin.ietf.org; Wed, 11 Jun 2003 01:32:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B5WvB27072 for ; Wed, 11 Jun 2003 01:32: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 BAA29785 for ; Wed, 11 Jun 2003 01:32:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PyC9-0004fw-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 01:30:49 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PyC8-0004ft-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 01:30:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B5VwB27040; Wed, 11 Jun 2003 01:31:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B5UHB26967 for ; Wed, 11 Jun 2003 01:30: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 BAA29604 for ; Wed, 11 Jun 2003 01:30:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Py9Z-0004cn-00 for sipping@ietf.org; Wed, 11 Jun 2003 01:28:09 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19Py9T-0004ch-00 for sipping@ietf.org; Wed, 11 Jun 2003 01:28:03 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h5B5UUbj014796; Wed, 11 Jun 2003 07:30:31 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 11 Jun 2003 07:31:11 +0200 Message-ID: From: "Christer Holmberg (LMF)" To: "'Francois Audet'" , Tom-PT Taylor , "'Juha Heinanen'" Cc: "'sipping@ietf.org'" Subject: RE: [Sipping] refer and pstn Date: Wed, 11 Jun 2003 07:29:26 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32FDA.6C480CA8" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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_01C32FDA.6C480CA8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Hi Juha, =20 I think it is important to remember that REFER is not the only way to = "transfer" a call. =20 First, during the call setup the gw can receive a 3xx response, which = triggers a new INVITE to a new destination. =20 Second, during the call the gw can receive a re-INVITE, with new remote = IP parameters. So, even if the session from a SIP signalling point of = view is still established with the initial user, the media has actually = been transfered elsewhere. =20 Now, I think it's a pure implementation issue how the gw handles all = these cases, ie if it decides to accept the responses/requests or not. =20 Regards, =20 Christer Holmberg Ericsson Finland =20 =20 =20 -----Original Message----- From: Francois Audet [mailto:audet@nortelnetworks.com] Sent: 10. kes=E4kuuta 2003 22:26 To: Tom-PT Taylor; 'Juha Heinanen' Cc: 'sipping@ietf.org' Subject: RE: [Sipping] refer and pstn My take is that if you accept REFER without user acknowledgement,=20 regarless of if the use is on PSTN or SIP, you need some sort=20 of trusted relationship with the REFERer. It is not a PSTN=20 gateway issue per se, but it is true that you typically would=20 not have a built-in mechanism for getting end-user acknowledgement=20 in the PSTN.=20 > -----Original Message-----=20 > From: Taylor, Tom-PT [CAR:5N00:EXCH]=20 > Sent: Tuesday, June 10, 2003 10:45=20 > To: Juha Heinanen=20 > Cc: sipping@ietf.org=20 > Subject: Re: [Sipping] refer and pstn=20 >=20 >=20 > Could I understand what difference there is between accepting=20 > a REFER and call=20 > transfer in the legacy network? In both cases, the protocol=20 > for gaining PSTN user=20 > acceptance is for the transferor to ask -- it's not a protocol issue. = >=20 > Juha Heinanen wrote:=20 >=20 > > i have noticed that some sip/pstn gws on the market support refer=20 > > method. i consider this very dangerous because pstn gw has no way=20 > > that i know of asking the original pstn caller to accept or=20 > reject the=20 > > referral. things get even worse when these implementations do not=20 > > send the resulting new request to the proxy, but directly to pstn.=20 > >=20 > > if any of the vendors of these gws are listening, i would like to=20 > > understand what is your logic when you have implemented=20 > refer method=20 > > UAS or if the authors of the refer rfc are listening, how=20 > you thought=20 > > it could be properly used by sip UASes that are pstn gws.=20 > >=20 > > -- juha=20 > > _______________________________________________=20 > > Sipping mailing list = https://www1.ietf.org/mailman/listinfo/sipping = =20 > > This list is for NEW development of the application of SIP Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sip@ietf.org for new developments of core SIP=20 > >=20 >=20 > _______________________________________________=20 > Sipping 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.columbia.edu for questions on current=20 > sip Use sip@ietf.org for new developments of core SIP=20 >=20 ------_=_NextPart_001_01C32FDA.6C480CA8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sipping] refer and pstn
 
Hi=20 Juha,
 
I=20 think it is important to remember that REFER is not the only way to = "transfer" a=20 call.
 
First,=20 during the call setup the gw can receive a 3xx response, which = triggers a=20 new INVITE to a new destination.
 
Second, during the call the gw can receive a = re-INVITE,=20 with new remote IP parameters. So, even if the session from a SIP = signalling=20 point of view is still established with the initial user, the = media has=20 actually been transfered elsewhere.
 
Now, I=20 think it's a pure implementation issue how the gw handles all these = cases, ie if=20 it decides to accept the responses/requests or not.
 
Regards,
 
Christer Holmberg
Ericsson Finland
 
 
 
-----Original Message-----
From: Francois Audet=20 [mailto:audet@nortelnetworks.com]
Sent: 10. kes=E4kuuta = 2003=20 22:26
To: Tom-PT Taylor; 'Juha Heinanen'
Cc:=20 'sipping@ietf.org'
Subject: RE: [Sipping] refer and=20 pstn

My take is that if you accept REFER without user=20 acknowledgement,
regarless of if the use is = on PSTN or=20 SIP, you need some sort
of trusted = relationship with=20 the REFERer. It is not a PSTN
gateway issue = per se,=20 but it is true that you typically would
not = have a=20 built-in mechanism for getting end-user acknowledgement =
in the PSTN.

> -----Original Message-----
>=20 From: Taylor, Tom-PT [CAR:5N00:EXCH]
> = Sent:=20 Tuesday, June 10, 2003 10:45
> To: Juha=20 Heinanen
> Cc: sipping@ietf.org =
> Subject: Re: [Sipping] refer and pstn
>=20
>
> Could I = understand=20 what difference there is between accepting
> a=20 REFER and call
> transfer in the legacy=20 network?  In both cases, the protocol
> for=20 gaining PSTN user
> acceptance is for = the=20 transferor to ask -- it's not a protocol issue.
>=20
> Juha Heinanen wrote:
>=20
> > i have noticed that some sip/pstn = gws on the=20 market support refer
> > = method.  i=20 consider this very dangerous because pstn gw has no way =
> > that i know of asking the original pstn caller to = accept or=20
> reject the
> >=20 referral.  things get even worse when these implementations do = not=20
> > send the resulting new request to = the proxy,=20 but directly to pstn.
> > =
> > if any of the vendors of these gws are listening, = i would=20 like to
> > understand what is your = logic when=20 you have implemented
> refer method=20
> > UAS or if the authors of the = refer rfc are=20 listening, how
> you thought =
> > it could be properly used by sip UASes that are = pstn=20 gws.
> >
> > --=20 juha
> >=20 _______________________________________________
>=20 > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping=20
> > This list is for NEW development of the = application=20 of SIP Use
> > = sip-implementors@cs.columbia.edu=20 for questions on current sip Use
> >=20 sip@ietf.org for new developments of core SIP
>=20 >
>
>=20 _______________________________________________
>=20 Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping=20
> This list is for NEW development of the = application of=20 SIP
> Use = sip-implementors@cs.columbia.edu for=20 questions on current
> sip Use = sip@ietf.org for new=20 developments of core SIP
>=20

------_=_NextPart_001_01C32FDA.6C480CA8-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jun 11 02:09: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 CAA10344 for ; Wed, 11 Jun 2003 02:09:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5B698q02126 for sipping-archive@odin.ietf.org; Wed, 11 Jun 2003 02:09:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B696B02122 for ; Wed, 11 Jun 2003 02: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 CAA09796 for ; Wed, 11 Jun 2003 02:09:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pyl7-0004uK-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 02:06:58 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Pyl7-0004uH-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 02:06:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B68OB01865; Wed, 11 Jun 2003 02:08:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B67TB00867 for ; Wed, 11 Jun 2003 02:07: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 CAA08137 for ; Wed, 11 Jun 2003 02:07:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PyjY-0004t8-00 for sipping@ietf.org; Wed, 11 Jun 2003 02:05:20 -0400 Received: from harjus.tutpro.com ([192.98.100.3] ident=mail) by ietf-mx with esmtp (Exim 4.12) id 19PyjY-0004t2-00 for sipping@ietf.org; Wed, 11 Jun 2003 02:05:20 -0400 Received: from jh by harjus.tutpro.com with local (Exim 3.35 #1 (Debian)) id 19PylM-0000B3-00; Wed, 11 Jun 2003 09:07:12 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16102.50960.128643.460657@harjus.tutpro.com> Date: Wed, 11 Jun 2003 09:07:12 +0300 To: "Christer Holmberg (LMF)" Cc: "'Francois Audet'" , Tom-PT Taylor , "'sipping@ietf.org'" Subject: RE: [Sipping] refer and pstn In-Reply-To: References: X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen 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 Christer Holmberg (LMF) writes: > Now, I think it's a pure implementation issue how the gw handles all > these cases, ie if it decides to accept the responses/requests or > not. yes, but the protocol must provide enough information for the gateway to make its decision and i'm not sure if that is the case with refer. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jun 11 02:14:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12117 for ; Wed, 11 Jun 2003 02:14:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5B6DkZ07835 for sipping-archive@odin.ietf.org; Wed, 11 Jun 2003 02:13:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B6DkB07832 for ; Wed, 11 Jun 2003 02:13: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 CAA12067 for ; Wed, 11 Jun 2003 02:13:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pypd-0004wN-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 02:11:37 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Pypc-0004wK-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 02:11:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B6D4B07332; Wed, 11 Jun 2003 02:13:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B6CiB07210 for ; Wed, 11 Jun 2003 02:12: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 CAA11988 for ; Wed, 11 Jun 2003 02:12:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pyod-0004w7-00 for sipping@ietf.org; Wed, 11 Jun 2003 02:10:36 -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 19PyoY-0004w4-00 for sipping@ietf.org; Wed, 11 Jun 2003 02:10:30 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h5B6CD0J000367; Wed, 11 Jun 2003 08:12:13 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 11 Jun 2003 08:13:38 +0200 Message-ID: From: "Christer Holmberg (LMF)" To: "'Juha Heinanen'" Cc: "'Francois Audet'" , Tom-PT Taylor , "'sipping@ietf.org'" Subject: RE: [Sipping] refer and pstn Date: Wed, 11 Jun 2003 08:11:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Hi, >>Now, I think it's a pure implementation issue how the gw >>handles all these cases, ie if it decides to accept the responses/requests or >>not. >yes, but the protocol must provide enough information for the >gateway to make its decision and i'm not sure if that is the case with refer. Exactly what information do you want the protocol to provide? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jun 11 03:14:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27965 for ; Wed, 11 Jun 2003 03:14:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5B7DYY13298 for sipping-archive@odin.ietf.org; Wed, 11 Jun 2003 03:13:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B7DYB13295 for ; Wed, 11 Jun 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 DAA27961 for ; Wed, 11 Jun 2003 03:13:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PzlZ-0005Vd-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 03:11:29 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PzlY-0005Va-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 03:11:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B7CXB13244; Wed, 11 Jun 2003 03:12:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B78ZB13083 for ; Wed, 11 Jun 2003 03: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 DAA27836 for ; Wed, 11 Jun 2003 03:08:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pzgf-0005U0-00 for sipping@ietf.org; Wed, 11 Jun 2003 03:06:25 -0400 Received: from harjus.tutpro.com ([192.98.100.3] ident=mail) by ietf-mx with esmtp (Exim 4.12) id 19Pzge-0005Tx-00 for sipping@ietf.org; Wed, 11 Jun 2003 03:06:24 -0400 Received: from jh by harjus.tutpro.com with local (Exim 3.35 #1 (Debian)) id 19PziY-0000CX-00; Wed, 11 Jun 2003 10:08:22 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16102.54630.772069.225765@harjus.tutpro.com> Date: Wed, 11 Jun 2003 10:08:22 +0300 To: "Christer Holmberg (LMF)" Cc: "'Francois Audet'" , Tom-PT Taylor , "'sipping@ietf.org'" Subject: RE: [Sipping] refer and pstn In-Reply-To: References: X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen 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 Christer Holmberg (LMF) writes: > Exactly what information do you want the protocol to provide? as i mentioned earlier, for example, the gw would like to know if referred-by can be trusted and that the party doing the refer has the right the forward a call to the refer-to number. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jun 11 03:22:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28105 for ; Wed, 11 Jun 2003 03:22:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5B7LpD13649 for sipping-archive@odin.ietf.org; Wed, 11 Jun 2003 03:21:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B7LpB13646 for ; Wed, 11 Jun 2003 03:21: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 DAA28090 for ; Wed, 11 Jun 2003 03:21:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PztZ-0005XZ-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 03:19:45 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PztZ-0005XW-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 03:19:45 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B7L7B13620; Wed, 11 Jun 2003 03:21:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B7KtB13600 for ; Wed, 11 Jun 2003 03:20: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 DAA28080 for ; Wed, 11 Jun 2003 03:20:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pzsf-0005XI-00 for sipping@ietf.org; Wed, 11 Jun 2003 03:18:49 -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 19Pzsa-0005XF-00 for sipping@ietf.org; Wed, 11 Jun 2003 03:18:44 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h5B7KQ0J010887; Wed, 11 Jun 2003 09:20:26 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 11 Jun 2003 09:21:52 +0200 Message-ID: From: "Christer Holmberg (LMF)" To: "'Juha Heinanen'" Cc: "'Francois Audet'" , Tom-PT Taylor , "'sipping@ietf.org'" Subject: RE: [Sipping] refer and pstn Date: Wed, 11 Jun 2003 09:20:08 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Hi, >>Exactly what information do you want the protocol to provide? >as i mentioned earlier, for example, the gw would like to know if >referred-by can be trusted and that the party doing the refer has the >right the forward a call to the refer-to number. That is if the gw cares. The who-is-allowed-to-call-who handling can also be done by a proxy, but that of course require that all INVITEs are sent via that proxy. And, one of your concerns was that the gw doesn't send the INVITE to that proxy, but directly to the new UAS. However, if your network has that kind of functionality in the network, eg in a proxy, I guess you would have to configure that proxy as default outbound proxy, and send all INVITEs (also those triggered by REFER, I'd assume) to that proxy. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jun 11 03:32:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28455 for ; Wed, 11 Jun 2003 03:32:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5B7WAc14024 for sipping-archive@odin.ietf.org; Wed, 11 Jun 2003 03:32:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B7WAB14021 for ; Wed, 11 Jun 2003 03: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 DAA28396 for ; Wed, 11 Jun 2003 03:32:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q03Y-0005d7-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 03:30:04 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Q03X-0005d4-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 03:30:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B7VBB13987; Wed, 11 Jun 2003 03:31:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B7UbB13938 for ; Wed, 11 Jun 2003 03:30: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 DAA28301 for ; Wed, 11 Jun 2003 03:30:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q023-0005bN-00 for sipping@ietf.org; Wed, 11 Jun 2003 03:28:31 -0400 Received: from harjus.tutpro.com ([192.98.100.3] ident=mail) by ietf-mx with esmtp (Exim 4.12) id 19Q022-0005bK-00 for sipping@ietf.org; Wed, 11 Jun 2003 03:28:31 -0400 Received: from jh by harjus.tutpro.com with local (Exim 3.35 #1 (Debian)) id 19Q03u-0000F0-00; Wed, 11 Jun 2003 10:30:26 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16102.55954.101362.375799@harjus.tutpro.com> Date: Wed, 11 Jun 2003 10:30:26 +0300 To: "Christer Holmberg (LMF)" Cc: "'Francois Audet'" , Tom-PT Taylor , "'sipping@ietf.org'" Subject: RE: [Sipping] refer and pstn In-Reply-To: References: X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen 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 Christer Holmberg (LMF) writes: > That is if the gw cares. The who-is-allowed-to-call-who handling can > also be done by a proxy ... exactly, so lets focus on the proxy instead. as i have asked before, how does the proxy know if referred-by has been checked upstream or how can it indicate to downstream if it itself has verified referred-by. that is, what is the equivalent of remote-party-id for referred-by? also, lets assume that the uri in refer-to contains a telephone number. if so, the proxy must make enum query on it. where in the request does the proxy store the result of the enum query? -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jun 11 03:55:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28738 for ; Wed, 11 Jun 2003 03:55:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5B7t1k15702 for sipping-archive@odin.ietf.org; Wed, 11 Jun 2003 03:55:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B7sxB15699 for ; Wed, 11 Jun 2003 03:54: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 DAA28735 for ; Wed, 11 Jun 2003 03:54:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q0Pc-0005jG-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 03:52:52 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Q0Pb-0005jD-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 03:52:51 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B7rgB15617; Wed, 11 Jun 2003 03:53:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B7qgB15577 for ; Wed, 11 Jun 2003 03:52: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 DAA28713 for ; Wed, 11 Jun 2003 03:52:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q0NQ-0005in-00 for sipping@ietf.org; Wed, 11 Jun 2003 03:50:36 -0400 Received: from [217.158.120.227] (helo=rnidmail.rnid.org.uk) by ietf-mx with esmtp (Exim 4.12) id 19Q0NP-0005iW-00 for sipping@ietf.org; Wed, 11 Jun 2003 03:50:35 -0400 Received: from rnid.org.uk (unverified) by rnidmail.rnid.org.uk (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Wed, 11 Jun 2003 08:50:19 +0100 Received: from RNIDMAIL-Message_Server by rnid.org.uk with Novell_GroupWise; Wed, 11 Jun 2003 08:49:54 +0100 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Wed, 11 Jun 2003 08:49:22 +0100 From: "Guido Gybels" To: Cc: , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5B7qgB15578 Subject: [Sipping] RE: Text support in SIP phones Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Keith and all, <> I'm quite surprised, since this must be the first time I see the industry actually asking for more regulation and legislation! It was my impression that free market mechanisms were preferred. I'd like to make it clear that the *current* situation with different national regulation in various countries has seriously hampered the BUSINESS case. If the support for a standardised mechanism for the provision of interactive text is not part of the recommendations in this document, we will end up, as has been proven time and again by history, with non-mainstream, expensive, incompatible solutions. Please note that getting regulation or legislation that imposes the obligation to provide specific services for people with disabilities is not that difficult. But you end up with a plethora of regulations and legislation and the cost of implementing solutions falls on to the service providers and network operators. Again, plenty of evidence. The new regulatory framework in the UK with regard to the provision of mobile text telephony, for example, will result in operators having to invest hundreds of thousands of pounds over the coming months, with no hope of recovering them. The operators have to bear to entire cost of this operation. The reason is that none of their mainstream services is able to support the specific require! ment (why? because GSM/GPRS standards have no standard provision for interactive text), so you end up with these kinds of regulatory solutions. I haven't seen any of the operators in the UK being very happy about this! They would by far prefer to have one mainstream infrastructure that is able to fulfill all the requirements. Also, such solutions, being by definition not part of their standard infrastructure, require network operators to install and maintain proprietary nodes and software in their networks, which as you'll understand, is not exactly favoured by them either. It also is in the continuous danger of being broken by any mainstream developments, installation of new hard- and software on the main network etc, etc. If, however, we are able to think out of the box this time we should be able to prevent this situation from repeating itself by providing a MAINSTREAM solution that will at the same time deal with the problems of specific requirements. SMS on the mobile platform has proved beyond any doubt that there exists a HUGE market, NOT just for people with disabilities, but for ALL users, for texting. The popularity of texting in Europe and Japan is beyond all expectations. It is therefore reasonable to state that the ability to use text to communicate: a) mandatory if you want to roll out next generation services since users will not accept the loss of such service b) has to be part of the standard network and terminal provision: it is unthinkable to operate a modern mobile network that would not support SMS and I am not aware of any handsets currently on the market that do not support SMS. Furthermore, the success of SMS is strongly linked to the fact that it is basic part of the mobile protocols. Every standard GSM supports it since it is part of the standard. Initially, operators blocked access from other providers so that SMS could not be send across network boundaries. It was only when those restrictions were lifted and users could freely send text around that SMS really took off. We should learn valuable lessons from all this. Especially in a moment in time that the telecommunication sector is suffering hard, it is mandatory to get the requirements and standards right. The cost of getting it wrong will be extremely high. Making sure that any future networks and services offer an improved interactive texting feature therefore is extremely sound reasoning. What we are proposing as a solution is extremely light-weight, easy ti implement, readily available, cheap, does not impose any burdens on manufacturers or operators, and most importantly is the best possible solution from a purely BUSINESS point of view. It is one of these rare situations where everybody is a winner. <> I have no objection against qualifying, maybe in the sense that Henry proposes. But the network MUST fully support, in a standardised way, setting up interactive sessions between any two nodes and carrying the conversation. Devices might not have a keyboard or display (although I can't imagine selling a phone without display in these days of mobile communications, except for niche markets and that is not very interesting for manufacturers anyway), but users might opt to fit one later. In short, I strongly suggest we use the MUST. Let's agree on qualifying it if necessary. <> RNID believes that it is far better to design an off-the-shelf device in such a way that it is able to support deaf, hard of hearing, speech impaired or visually impaired people. Deaf, hard of hearing, blind,... people could then easily buy ANY off-the-shelf phone and fit it with a headset, probably connected to the phone via Bluetooth. That would: a) give them the same freedom of choice b) prevent them from being marginalised through the use of special equipment (just think about the link with hearing aids...) Surveys amongst people with disabilities show that this is a major requirement: people with disabilities do not want to be considered "special" users. They want access to the same products and services as any other individual. The provision of such headsets as you mention, BTW, is not only for the benefit of visually impaired people. These days, I see much more non-disabled people walking around with their Bluetooth handsets than visually impaired people. The use of SMS by deaf and hard of hearing people is another such example: no one would claim that SMS is only for those users. Yet, they take advantage of a MAINSTREAM provision which happens to suit their abilities and preferences. Hearing people in noisy circumstances or in situations where they cannot use voice will also revert to text in some circumstances. The whole concept of "special" equipment is well out of fashion these days. Let's build mainstream technology so that it suits as much users as possible, regardless of their abilities and preferences. It will be to the benefit of ALL. 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 ************************************************************************ 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 mailnull@www1.ietf.org Wed Jun 11 06:07:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01281 for ; Wed, 11 Jun 2003 06:07:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5BA6vC24724 for sipping-archive@odin.ietf.org; Wed, 11 Jun 2003 06:06:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BA6vB24721 for ; Wed, 11 Jun 2003 06:06: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 GAA01263 for ; Wed, 11 Jun 2003 06:06:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q2TI-0006IP-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 06:04:48 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Q2TI-0006IK-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 06:04:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BA5NB24663; Wed, 11 Jun 2003 06:05:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BA3CB24577 for ; Wed, 11 Jun 2003 06: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 GAA01182 for ; Wed, 11 Jun 2003 06:03:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q2Pg-0006Hi-00 for sipping@ietf.org; Wed, 11 Jun 2003 06:01:04 -0400 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by ietf-mx with esmtp (Exim 4.12) id 19Q2Pf-0006HY-00 for sipping@ietf.org; Wed, 11 Jun 2003 06:01:03 -0400 Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0HGB00L3GAHME4@firewall.wcom.com> for sipping@ietf.org; Wed, 11 Jun 2003 10:00:59 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HGB00H01AHM7U@dgismtp03.wcomnet.com>; Wed, 11 Jun 2003 10:00:58 +0000 (GMT) Received: from hsinnreich2 ([166.50.128.29]) by dgismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HGB00DD3AEA90@dgismtp03.wcomnet.com>; Wed, 11 Jun 2003 10:00:57 +0000 (GMT) Date: Wed, 11 Jun 2003 04:58:58 -0500 From: Henry Sinnreich Subject: RE: [Sipforum-discussion] RE: [Sipping] Text support in SIP phones In-reply-to: To: "=?iso-8859-1?Q?'Gunnar_Hellstr=F6m'?=" , "'Sipping@Ietf. Org'" , "'Sipforum-Discussion@Lists. Su. Se'" , "'Drage, Keith (Keith)'" Message-id: <001101c33000$57b615b0$1d8032a6@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 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5BA3DB24578 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h5BA5NB24663 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5BA6vB24721 Content-Transfer-Encoding: 8bit Gunnar, thanks for bringing this up! I believe now we can ask for discussion time at the SIPPING WG meeting. Henry > -----Original Message----- > From: sipforum-discussion-admin@lists.su.se > [mailto:sipforum-discussion-admin@lists.su.se] On Behalf Of > Gunnar Hellström > Sent: Tuesday, June 10, 2003 2:42 PM > To: Henry Sinnreich; 'Drage, Keith (Keith)'; 'Sipping@Ietf. > Org'; 'Sipforum-Discussion@Lists. Su. Se' > Subject: SV: [Sipforum-discussion] RE: [Sipping] Text support > in SIP phones > > > I agree that this discussion starts to get balance into the > specification of the real time text conversation feature. > > Firstly, I have discovered that I need to explain again that > what we talk about is a real time, character by character > transmission and display of text. You can see the thought as > it is growing and being formed into text. It is a very direct > way to have contact, and once you have used it, you realize > that in some applications it is essential to have access to > this feature. It has the same immediate flow as audio in > voice telephony and video in video telephony. > > In fact, there is a name for the three media together, it is > called Total Conversation. > > It is true that the force behind defining it has come from > the needs of people with communication related disabilities. > But I am sure that once commonly implemented, it will become > a natural and popular feature that is often used during voice > calls between most users. > > Instant messaging is also a very handy service. But it goes > message by message, and therefore does not have the direct > touch as the real time conversational service in voice, text > and video has. > > > > We have a forerunner in the specification of media for the > SIP based IP Multimedia phone in 3GPP. Maybe we can pick the > same style of specification. In 3GPP TS 26.235, "Packet > switched conversational multimedia applications, default > codecs", it is specified among the enumeration of supported media: > > 6.3 Real time text > 3G PS multimedia terminals offering real time text > conversation should support ITU-T Recommendation T.140 [25] > Text Conversation presentation coding. > > And in the chapter on RTP payload, it is specified: > > 9.2 RTP payload > RTP payload formats specified by IETF shall be used for real > time media streams. RTP payload format for the AMR narrowband > speech codec is specified in annex B. RTP payload format for > the AMR wideband speech codec is specified in annex B. RTP > payload format for the ITU-T Recommendation H.263 [6] video > codec is specified in IETF RFC 2429 [3]. RTP payload format > for the MPEG-4 visual simple profile level 0 is specified in > IETF RFC 3016 [5]. RTP payload format for the ITU-T > Recommendation T.140 [25] text conversation coding is > specified in IETF RFC 2793 [24]. > > In the annex A on specific details, the following is > specified for text: > > A.3 Text > Use of the redundancy coding variant specified in RFC 2793 > [24] is recommended for error resilience. > > -------------------------------- > When this topic was handled in 3GPP, there was opposition > against mentioning the reason for introducing the text > feature as being something specific for disabled people. > > I think that is still valid. > > I suggest that the following formulation is used: > ************************************************************** > ************** > ************************************** > SIP-zz, digital text support: SIP telephone devices SHOULD > support real time text conversation. If text is supported, it > MUST support RFC2793 [y], for text coding and packetization, > and it MUST be possible to use text simultaneously with voice. > ************************************************************** > ************** > ************************************** > > > Gunnar > ------------------------------------------- > Gunnar Hellström, Omnitor, Renathvägen 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ån: sipforum-discussion-admin@lists.su.se > > [mailto:sipforum-discussion-admin@lists.su.se]För Henry Sinnreich > > Skickat: den 10 juni 2003 18:02 > > Till: 'Drage, Keith (Keith)'; 'Henry Sinnreich'; 'Gunnar > Hellström'; > > 'Sipping@Ietf. Org'; 'Sipforum-Discussion@Lists. Su. Se' > > Ämne: [Sipforum-discussion] RE: [Sipping] Text support in SIP phones > > > > > > Keith, thanks for bringing balance, I believe, to this discussion. > > > > We could formulate soemthing like "SIP phones that have a > text display > > and advertised as supporting the hearing or speech disabled MUST..." > > > > Would this be OK? > > > > Henry > > > > > -----Original Message----- > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On > > > Behalf Of Drage, Keith (Keith) > > > Sent: Tuesday, June 10, 2003 8:14 AM > > > To: 'Henry Sinnreich'; 'Gunnar Hellström'; 'Sipping@Ietf. Org'; > > > 'Sipforum-Discussion@Lists. Su. Se' > > > Subject: RE: [Sipping] Text support in SIP phones > > > > > > > > > I would suggest that treating these sort of things as > MUST strength > > > is best left to national regulatory requirements, along > with other > > > things like fitness for purpose and so on. I have no objection to > > > their being mentioned. By the way, I understood this document was > > > being progressed as authors individual submission, and > was therefore > > > not standards track. > > > > > > Any such MUST would surely need to be qualified anyway. If the > > > purpose of the devise is such that it renders a textual devise > > > irrelevant, then why require one to be fitted. Suppose we were > > > designing a SIP phone for the totally blind, and this was > designed > > > to be worn as a headset, a text device would be > irrelevant to such a > > > user, and positioning such a device where it could be seen would > > > require an extra box hanging out of the side of the product. > > > > > > regards > > > > > > Keith > > > > > > Keith Drage > > > Lucent Technologies > > > Tel: +44 1793 776249 > > > Email: drage@lucent.com > > > > > > > -----Original Message----- > > > > From: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com] > > > > Sent: 27 May 2003 17:18 > > > > To: 'Gunnar Hellström'; 'Sipping@Ietf. Org'; > > > > 'Sipforum-Discussion@Lists. Su. Se' > > > > Cc: 'Henry Sinnreich' > > > > Subject: RE: [Sipping] Text support in SIP phones > > > > > > > > > > > > Gunnar, this all seems very reasonable, and I will try > to insert > > > > it properly. > > > > > > > > Henry > > > > > > > > > -----Original Message----- > > > > > From: sipping-admin@ietf.org > [mailto:sipping-admin@ietf.org] On > > > > > Behalf Of Gunnar Hellström > > > > > Sent: Thursday, May 22, 2003 6:54 PM > > > > > To: 'Sipping@Ietf. Org'; Sipforum-Discussion@Lists. Su. Se > > > > > Cc: Henry Sinnreich > > > > > Subject: [Sipping] Text support in SIP phones > > > > > > > > > > > > > > > Sorry, I missed out the reference to the SIP device > > > > > specification. > > > > > > > > > > Henry and all, > > > > > > > > > > Some time ago, I suggested addition of support for real time > > > > > text communication to the SIP device specification > > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-00.tx > > > t > > > > > > > > > > This was the simple part of the proposal: > > > > > > > > > > > SIP-zz, digital text support: SIP telephone devices > MUST support > > > > > > real time text conversation using RFC 2793 [y] for the > > > > > text stream. > > > > > > It MUST be possible to use text simultaneously with voice. > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------- > > > > > > In 4.11 Ringer Behaviour : add the section below for the > > > > > purpose of > > > > > > deaf, hearing impaired, deaf-blind people and people in the > > > > > garden and > > > > > > noisy > > > > > > locations: > > > > > > > > > > > > SIP Telephony devices MUST provide an external > interface to an > > > > > > external alerting system. > > > > > > > > > > > > > > > > > > > > > > > > Add to References > > > > > > ----------------- > > > > > > [y] G. Hellstrom: "RTP Payload for Text Conversation.", > > > RFC 2793, > > > > > > IETF, May 2000. > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > > > > > > The reception of this proposal was very positive. > > > > > Now, I would like to see the final formulation, and > check that > > > > > we agree on it. > > > > > > > > > > I regard this requirement to be very light. In the Interface > > > > > section ( e.g. > > > > > Int-2) , there is already mentioning of mandatory text input > > > > > mechanisms, and assumptions that a display would be normal, > > > > > since handling of phone books and buddy lists are > mandatory. To > > > > > re-use these text interface devices during the call for > > > > > standardised text conversation purposes seems straightforward. > > > > > > > > > > It could be wise to add the T.140 text presentation > protocol as > > > > > a codec to the codec section. The normal SDP used > together with > > > > > RFC2793 for text could also be specified. Do you want > > > > to do that? > > > > > > > > > > > > > > > ----- > > > > > > > > > > We also need to check the ideas around the other proposed > > > > > requirements: The requirement to include text > telephone modem in > > > > > all designs where an RJ11 phone connector exists, and the > > > > > requirement to support RFC 3351. I suggest that we start with > > > > > the straightforward and mainstream requirement above. Is that > > > > > accepted as it is? > > > > > > > > > > > > > > > Regards > > > > > > > > > > Gunnar > > > > > ------------------------------------------- > > > > > Gunnar Hellström, Omnitor, Renathvägen 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/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/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 From mailnull@www1.ietf.org Wed Jun 11 07:24:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02699 for ; Wed, 11 Jun 2003 07:24:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5BBNXu30214 for sipping-archive@odin.ietf.org; Wed, 11 Jun 2003 07:23:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BBNXB30211 for ; Wed, 11 Jun 2003 07:23: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 HAA02671 for ; Wed, 11 Jun 2003 07:23:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q3fT-0006cf-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 07:21:27 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Q3fT-0006cc-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 07:21:27 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BBMdB30177; Wed, 11 Jun 2003 07:22:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BBLiB30124 for ; Wed, 11 Jun 2003 07:21: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 HAA02642; Wed, 11 Jun 2003 07:21:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q3di-0006bn-00; Wed, 11 Jun 2003 07:19:38 -0400 Received: from [217.158.120.227] (helo=rnidmail.rnid.org.uk) by ietf-mx with esmtp (Exim 4.12) id 19Q3dh-0006bj-00; Wed, 11 Jun 2003 07:19:38 -0400 Received: from rnid.org.uk (unverified) by rnidmail.rnid.org.uk (Content Technologies SMTPRS 4.2.5) with SMTP id ; Wed, 11 Jun 2003 12:19:28 +0100 Received: from RNIDMAIL-Message_Server by rnid.org.uk with Novell_GroupWise; Wed, 11 Jun 2003 12:18:53 +0100 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Wed, 11 Jun 2003 12:18:29 +0100 From: "Guido Gybels" To: , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5BBLiB30127 Subject: [Sipping] RE: Text support in SIP phones Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Henry, <> Surely narrowing it down to "and advertised as supporting the hearing or speech disabled" is not acceptable? How many phones (will) advertise themselves as "supporting the hearing or speech disabled"? This is just getting back to what we have today: special markets where the business case sucks and regulation imposed on operators and manufacturers that costs them loads of money, yet fails to provide an equivalent user experience in comparison to mainstream solutions. We need an inclusive mainstream solution. Arnoud, what do you think? 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 ************************************************************************ 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 mailnull@www1.ietf.org Wed Jun 11 07:38:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03333 for ; Wed, 11 Jun 2003 07:38:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5BBcM631669 for sipping-archive@odin.ietf.org; Wed, 11 Jun 2003 07:38:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BBcMB31666 for ; Wed, 11 Jun 2003 07:38: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 HAA03327 for ; Wed, 11 Jun 2003 07:38:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q3to-0006mI-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 07:36:16 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Q3tn-0006mF-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 07:36:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BBbEB31111; Wed, 11 Jun 2003 07:37:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BBahB30693 for ; Wed, 11 Jun 2003 07:36: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 HAA03316 for ; Wed, 11 Jun 2003 07:36:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q3sD-0006m1-00 for sipping@ietf.org; Wed, 11 Jun 2003 07:34:37 -0400 Received: from ns.ivd.nl ([193.67.37.226]) by ietf-mx with esmtp (Exim 4.12) id 19Q3sB-0006ly-00 for sipping@ietf.org; Wed, 11 Jun 2003 07:34:36 -0400 Received: (from root@localhost) by ns.ivd.nl (8.9.3c/8.6.12) id NAA10140 for ; Wed, 11 Jun 2003 13:37:32 +0200 (CEST) Received: by ns.ivd.nl (TUNIX txp2/smap) for id sma009681; Wed, 11 Jun 03 13:36:33 +0200 Received: from IVD-Message_Server by mailserver.viataal.nl with Novell_GroupWise; Wed, 11 Jun 2003 13:37:26 +0200 Message-Id: X-Mailer: Novell GroupWise 5.5.5 Date: Wed, 11 Jun 2003 13:37:05 +0200 From: "A vWijk" To: , Cc: , Subject: [Sipping] RE: Text support in SIP phones Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5BBahB30694 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Keith, Henry and others. As a deaf person myself, with experience and knowledge on what the hearing impaired users really WANT and NEED. I can only say that Guido is absolutely CORRECT! And I fully agree with him. The requirement for real-time text conversation is a MUST. We have to move away from special phones/devices for the handicapped people. As Guido descibed, that will only lead to expensive devices with limited functionality and lagging technology or even complete obsolete technology. With the interworking problems etc etc. This has happened time over time in the past. By the way, when a visually impaired person is using a phone with text receiving capabilities. This user can connect a braille reader if desired and read the text. Always useful for addresses and names etc. Or his/her non handicapped partner needs to borrow the phone after the call. And being blind does not stop such users to type any text to any other user, regardless deafness, blindness or normally hearing. The bottomline is that this text support requirement is for ALL SIP telephony users! NOT only for the hearing impaired, but for every human being. Think of voice menus using text so that selecting the right customer representive will be easier (press 1 for.... press 2 for..... ). Or when exchanging names and addresses, per text is so much easier. Or when calling in a bar. Not being able to hear the phone due the high background noise, you can still communicate per text. Think of the popularity of text messaging, SMS, Instant Messaging. Think of new exiting services like translation interpreters when calling a Mexican businessman, spanish to english translation via text. (we are not like Jonathan who speaks spanish fluently :-) ) That is what we are talking about. It is not a niche market, this is a mainstream market with billions and billions of users benefitting from this text support. And having the complete FREEDOM to buy any SIP telephony device from any manufacturer with whatever functionality you like. greetz Arnoud Drs. Arnoud A. T. van Wijk Viataal Research & Development Afdeling RDS Theerestraat 42 5271 GD Sint-Michielsgestel The Netherlands. Mobile: +31651921948 >>> "Guido Gybels" 06/11/03 09:49am >>> Keith and all, <> I'm quite surprised, since this must be the first time I see the industry actually asking for more regulation and legislation! It was my impression that free market mechanisms were preferred. I'd like to make it clear that the *current* situation with different national regulation in various countries has seriously hampered the BUSINESS case. If the support for a standardised mechanism for the provision of interactive text is not part of the recommendations in this document, we will end up, as has been proven time and again by history, with non-mainstream, expensive, incompatible solutions. Please note that getting regulation or legislation that imposes the obligation to provide specific services for people with disabilities is not that difficult. But you end up with a plethora of regulations and legislation and the cost of implementing solutions falls on to the service providers and network operators. Again, plenty of evidence. The new regulatory framework in the UK with regard to the provision of mobile text telephony, for example, will result in operators having to invest hundreds of thousands of pounds over the coming months, with no hope of recovering them. The operators have to bear to entire cost of this operation. The reason is that none of their mainstream services is able to support the specific require! ment (why? because GSM/GPRS standards have no standard provision for interactive text), so you end up with these kinds of regulatory solutions. I haven't seen any of the operators in the UK being very happy about this! They would by far prefer to have one mainstream infrastructure that is able to fulfill all the requirements. Also, such solutions, being by definition not part of their standard infrastructure, require network operators to install and maintain proprietary nodes and software in their networks, which as you'll understand, is not exactly favoured by them either. It also is in the continuous danger of being broken by any mainstream developments, installation of new hard- and software on the main network etc, etc. If, however, we are able to think out of the box this time we should be able to prevent this situation from repeating itself by providing a MAINSTREAM solution that will at the same time deal with the problems of specific requirements. SMS on the mobile platform has proved beyond any doubt that there exists a HUGE market, NOT just for people with disabilities, but for ALL users, for texting. The popularity of texting in Europe and Japan is beyond all expectations. It is therefore reasonable to state that the ability to use text to communicate: a) mandatory if you want to roll out next generation services since users will not accept the loss of such service b) has to be part of the standard network and terminal provision: it is unthinkable to operate a modern mobile network that would not support SMS and I am not aware of any handsets currently on the market that do not support SMS. Furthermore, the success of SMS is strongly linked to the fact that it is basic part of the mobile protocols. Every standard GSM supports it since it is part of the standard. Initially, operators blocked access from other providers so that SMS could not be send across network boundaries. It was only when those restrictions were lifted and users could freely send text around that SMS really took off. We should learn valuable lessons from all this. Especially in a moment in time that the telecommunication sector is suffering hard, it is mandatory to get the requirements and standards right. The cost of getting it wrong will be extremely high. Making sure that any future networks and services offer an improved interactive texting feature therefore is extremely sound reasoning. What we are proposing as a solution is extremely light-weight, easy ti implement, readily available, cheap, does not impose any burdens on manufacturers or operators, and most importantly is the best possible solution from a purely BUSINESS point of view. It is one of these rare situations where everybody is a winner. <> I have no objection against qualifying, maybe in the sense that Henry proposes. But the network MUST fully support, in a standardised way, setting up interactive sessions between any two nodes and carrying the conversation. Devices might not have a keyboard or display (although I can't imagine selling a phone without display in these days of mobile communications, except for niche markets and that is not very interesting for manufacturers anyway), but users might opt to fit one later. In short, I strongly suggest we use the MUST. Let's agree on qualifying it if necessary. <> RNID believes that it is far better to design an off-the-shelf device in such a way that it is able to support deaf, hard of hearing, speech impaired or visually impaired people. Deaf, hard of hearing, blind,... people could then easily buy ANY off-the-shelf phone and fit it with a headset, probably connected to the phone via Bluetooth. That would: a) give them the same freedom of choice b) prevent them from being marginalised through the use of special equipment (just think about the link with hearing aids...) Surveys amongst people with disabilities show that this is a major requirement: people with disabilities do not want to be considered "special" users. They want access to the same products and services as any other individual. The provision of such headsets as you mention, BTW, is not only for the benefit of visually impaired people. These days, I see much more non-disabled people walking around with their Bluetooth handsets than visually impaired people. The use of SMS by deaf and hard of hearing people is another such example: no one would claim that SMS is only for those users. Yet, they take advantage of a MAINSTREAM provision which happens to suit their abilities and preferences. Hearing people in noisy circumstances or in situations where they cannot use voice will also revert to text in some circumstances. The whole concept of "special" equipment is well out of fashion these days. Let's build mainstream technology so that it suits as much users as possible, regardless of their abilities and preferences. It will be to the benefit of ALL. 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 ************************************************************************ 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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jun 11 08:07: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 IAA04501 for ; Wed, 11 Jun 2003 08:07:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5BC7SR01339 for sipping-archive@odin.ietf.org; Wed, 11 Jun 2003 08:07:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BC7SB01336 for ; Wed, 11 Jun 2003 08:07: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 IAA04484 for ; Wed, 11 Jun 2003 08:07:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q4Lx-0006ws-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 08:05:21 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Q4Lw-0006wp-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 08:05:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BC6OB00453; Wed, 11 Jun 2003 08:06:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BC5aB00417 for ; Wed, 11 Jun 2003 08:05:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04367 for ; Wed, 11 Jun 2003 08:05:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q4KA-0006vp-00 for sipping@ietf.org; Wed, 11 Jun 2003 08:03:30 -0400 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19Q4K9-0006vO-00 for sipping@ietf.org; Wed, 11 Jun 2003 08:03:29 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by auemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h5BC50g12319 for ; Wed, 11 Jun 2003 07:05:01 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 11 Jun 2003 13:04:59 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00439ED5C@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Rohan Mahy'" , "Drage, Keith (Keith)" Cc: "'Jonathan Rosenberg'" , alan.johnston@wcom.com, "'sipping@ietf.org'" Subject: RE: [Sipping] proposed enhancement to dialog package Date: Wed, 11 Jun 2003 13:04:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , See below regards Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: 10 June 2003 16:25 > To: Drage, Keith (Keith) > Cc: 'Jonathan Rosenberg'; alan.johnston@wcom.com; 'sipping@ietf.org' > Subject: Re: [Sipping] proposed enhancement to dialog package > > > Hi Keith, > > Hold as a UI concept significantly predated the development of ISDN. Agreed, and my initial message identified in that case (analogue PSTN terminals) that Hold was originally to recall the register (and there was a manual board equivalent as well) to allow access resources to be used for signalling, as a result of that signalling, the access resources might be used for communication with another party, and only as a by product of that did it necessarily result in loss of communication path with the other party. > In any case, an ISDN user (Alice) who requests an ISDN hold > is still a > passive participant by my definition. When Alice's call is connected > to a conference server and all the active participants say "ok, we're > leaving now, good bye", Alice is not active enough to be able to hang > up. Assuming your last statement still refers to an ISDN user, then I can think of nothing in the above scenario that prevents Alice sending a DISCONNECT, and receiving a RELEASE back. Can you clarify. The DSS1 basic call state machine is totally independent of any subsidiary state machine relating to hold/retrieve. If you are referring to hanging up the conference bridge resources, then this is dependent on the concept of ownership, which varies based on the conference service provided, and also between public and private networks. As a result, I think I am now confused about what you actually mean by passive, can you elaborate further. > > I agree that whatever we do, we need to describe the semantics very > crisply. > > thanks, > -rohan > > > On Tuesday, June 10, 2003, at 04:47 AM, Drage, Keith (Keith) wrote: > > > I fail to see how thw property you are proposing correlates in some > > way to any concept of hold. I agree that "hold" has many meanings, > > based on which type of signalling you are using. > > > > To clarify, the prime function of hold in the PSTN was never to > > interrupt the communication, that was a side effect of grabbing the > > access resources to signal to another party. Thus for ISDN, hold > > therefore was only a removal of access resources (the > bearer) so that > > that bearer could be reused for another call; again the side effect > > was to interrupt the communication. The sole function of > hold for SIP > > is to interrupt the communication. > > > > Certainly, if an ISDN user places another user on hold, I > would regard > > neither user as "passive" as you seem to be defining here. > > > > If we are going to do this, can we make sure we define the > semantics > > correctly. Otherwise we will surely create confusion, > particularly if > > people try and equate this concept with that of hold, and in > > particular with the PSTN concept. > > > > regards > > > > Keith > > > > > > Keith Drage > > Lucent Technologies > > Tel: +44 1793 776249 > > Email: drage@lucent.com > > > >> -----Original Message----- > >> From: Rohan Mahy [mailto:rohan@cisco.com] > >> Sent: 03 June 2003 22:18 > >> To: 'Jonathan Rosenberg' > >> Cc: rohan@cisco.com; alan.johnston@wcom.com; 'sipping@ietf.org' > >> Subject: [Sipping] proposed enhancement to dialog package > >> > >> > >> Hi, > >> > >> There have been many requests for the dialog package to express the > >> concept of hold. The problem is that nobody had an especially good > >> definition of what "on-hold" meant. Some suggested that all media > >> streams being inactive implied that you are "held", but > this doesn't > >> work for a service such as music-on-hold. > >> > >> I believe that folks actually want a slightly different > concept--that > >> the semantics we want instead are already described in the > >> call control > >> framework: > >> > >>> Participants may also be active or passive. Active > participants are > >>> expected to be intelligent enough to leave a conversation > >> space when > >>> they no longer desire to participate. (An attentive human > >> participant > >>> is obviously active.) Some robotic participants (such as a voice > >>> messaging system, an instant messaging agent, or a voice dialog > >>> system) may be active participants if they can leave the > >> conversation > >>> space when there is no human interaction. Other robots > (for example > >>> our tone generating robot from the previous example) are passive > >>> participants. A human participant "on-hold" is passive. > >> > >> I think we should add a new attribute to the dialog package that > >> expresses this property. My proposal is to express this > property only > >> for the local side of each dialog by adding an attribute > to the state > >> tag in the dialog-info notification body. The example below > >> includes a > >> proposed (optional) participation attribute in the state tag. > >> > >> > >> >> version="3" > >> state="partial" > >> entity="sip:caller@bar.com"> > >> >> local-tag="123" remote-tag="789" > direction="initiator"> > >> confirmed > >> > >> > >> > >> Participation status could change during a session without > otherwise > >> changing the state of the call. > >> > >> > >> >> version="4" > >> state="partial" > >> entity="sip:caller@bar.com"> > >> >> local-tag="123" remote-tag="789" > direction="initiator"> > >> confirmed > >> > >> > >> > >> > >> this proposal would of course require a small addition to the XML > >> schema to support the new attribute: > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> comments welcome. thanks, > >> -rohan > >> > >> _______________________________________________ > >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP >> > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jun 11 08:49:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06989 for ; Wed, 11 Jun 2003 08:49:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5BCn1m04483 for sipping-archive@odin.ietf.org; Wed, 11 Jun 2003 08:49:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BCn1B04480 for ; Wed, 11 Jun 2003 08:49: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 IAA06984 for ; Wed, 11 Jun 2003 08:48:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q509-0007jS-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 08:46:53 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Q508-0007jP-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 08:46:52 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BCkDB04388; Wed, 11 Jun 2003 08:46:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BCiIB04268 for ; Wed, 11 Jun 2003 08:44: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 IAA06696 for ; Wed, 11 Jun 2003 08:44:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q4va-0007dz-00 for sipping@ietf.org; Wed, 11 Jun 2003 08:42:10 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19Q4vZ-0007c3-00 for sipping@ietf.org; Wed, 11 Jun 2003 08:42:09 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h5BChdt26734 for ; Wed, 11 Jun 2003 07:43:40 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 11 Jun 2003 13:43:38 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00439ED5D@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Guido Gybels'" , sipping@ietf.org Cc: "Drage, Keith (Keith)" , A.vWijk@viataal.nl Date: Wed, 11 Jun 2003 13:43:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Sipping] RE: Text support in SIP phones Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , First of all, my comment was in response to a comment being made on the sip devices document. I understand the scope of that document to be terminals, not network type equipment, and therefore it is axiomatic that my comment also is within that scope. My comment has nothing whatsoever to do with any requirements, or absence of requirements, for support from network type equipment, which seems to be implied by a substantial part of your response. As regards provision of specialised terminal equipment for disabled, I do agree with you that ideally standard off the shelf equipment should be designed with the disabled in mind, thus allowing the disabled to make use of production level pricing and so on (all the reasons you have quoted). Your comments however do not eliminate the need for specialised equipment to exist, and my comment was trying to identify that writing a straight MUST could preclude some of that equipment from existing, e.g. by virtue of the mandatory provisions for one kind of disability overriding sensible design decisions for the specialised support of another kind of disability. I have no problem with a MUST level requirement that states: If the device supports a means of representing text, the device MUST support I believe Gunnar has identified a number of requirements from 3GPP specifications that provide material for this. The issue comes with what level do we represent a requirement for supporting a means of representing text. My thought process was that trying to identify all the exceptions would be too complicated to enable us to write: IF then device MUST support means of representing text SHOULD allows exceptions, but conveys no meaning about what those exceptions are. This then raised in my mind as to whether this was the appropriate document to try and represent such a requirement in the first place. It is a difficult requirement to represent, and in any case, various national law will have something to say about it anyway. The conclusion I came to was as previously stated, but I have no problem coming to a different conclusion, providing we can made a sensible statement of the requirement. This however is a voluntary standard, and, to my knowledge, will not even be called up by 3GPP SIP specifications, which carry their own requirements in this area. regards Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Guido Gybels [mailto:Guido.Gybels@rnid.org.uk] > Sent: 11 June 2003 08:49 > To: sipping@ietf.org > Cc: drage@lucent.com; A.vWijk@viataal.nl > Subject: RE: Text support in SIP phones > > > Keith and all, > > < strength is best left to national regulatory requirements, > along with other things like fitness for purpose and so on.>> > > I'm quite surprised, since this must be the first time I see > the industry actually asking for more regulation and > legislation! It was my impression that free market mechanisms > were preferred. I'd like to make it clear that the *current* > situation with different national regulation in various > countries has seriously hampered the BUSINESS case. > > If the support for a standardised mechanism for the provision > of interactive text is not part of the recommendations in > this document, we will end up, as has been proven time and > again by history, with non-mainstream, expensive, > incompatible solutions. Please note that getting regulation > or legislation that imposes the obligation to provide > specific services for people with disabilities is not that > difficult. But you end up with a plethora of regulations and > legislation and the cost of implementing solutions falls on > to the service providers and network operators. Again, plenty > of evidence. The new regulatory framework in the UK with > regard to the provision of mobile text telephony, for > example, will result in operators having to invest hundreds > of thousands of pounds over the coming months, with no hope > of recovering them. The operators have to bear to entire cost > of this operation. The reason is that none of their > mainstream services is able to support the specific > requirement (why? because GSM/GPRS standards have no standard > provision for interactive text), so you end up with these > kinds of regulatory solutions. I haven't seen any of the > operators in the UK being very happy about this! They would > by far prefer to have one mainstream infrastructure that is > able to fulfill all the requirements. Also, such solutions, > being by definition not part of their standard > infrastructure, require network operators to install and > maintain proprietary nodes and software in their networks, > which as you'll understand, is not exactly favoured by them > either. It also is in the continuous danger of being broken > by any mainstream developments, installation of new hard- and > software on the main network etc, etc. > > If, however, we are able to think out of the box this time we > should be able to prevent this situation from repeating > itself by providing a MAINSTREAM solution that will at the > same time deal with the problems of specific requirements. > > SMS on the mobile platform has proved beyond any doubt that > there exists a HUGE market, NOT just for people with > disabilities, but for ALL users, for texting. The popularity > of texting in Europe and Japan is beyond all expectations. It > is therefore reasonable to state that the ability to use text > to communicate: > a) mandatory if you want to roll out next generation services > since users will not accept the loss of such service > b) has to be part of the standard network and terminal > provision: it is unthinkable to operate a modern mobile > network that would not support SMS and I am not aware of any > handsets currently on the market that do not support SMS. > > Furthermore, the success of SMS is strongly linked to the > fact that it is basic part of the mobile protocols. Every > standard GSM supports it since it is part of the standard. > Initially, operators blocked access from other providers so > that SMS could not be send across network boundaries. It was > only when those restrictions were lifted and users could > freely send text around that SMS really took off. We should > learn valuable lessons from all this. Especially in a moment > in time that the telecommunication sector is suffering hard, > it is mandatory to get the requirements and standards right. > The cost of getting it wrong will be extremely high. > Making sure that any future networks and services offer an > improved interactive texting feature therefore is extremely > sound reasoning. What we are proposing as a solution is > extremely light-weight, easy ti implement, readily available, > cheap, does not impose any burdens on manufacturers or > operators, and most importantly is the best possible solution > from a purely BUSINESS point of view. It is one of these rare > situations where everybody is a winner. > > < the purpose of the devise is such that it renders a textual > devise irrelevant, then why require one to be fitted.>> > > I have no objection against qualifying, maybe in the sense > that Henry proposes. But the network MUST fully support, in a > standardised way, setting up interactive sessions between any > two nodes and carrying the conversation. Devices might not > have a keyboard or display (although I can't imagine selling > a phone without display in these days of mobile > communications, except for niche markets and that is not very > interesting for manufacturers anyway), but users might opt to > fit one later. > > In short, I strongly suggest we use the MUST. Let's agree on > qualifying it if necessary. > > < blind, and this was designed to be worn as a headset, a text > device would be irrelevant to such a user, and positioning > such a device where it could be seen would require an extra > box hanging out of the side of the product.>> > > RNID believes that it is far better to design an > off-the-shelf device in such a way that it is able to support > deaf, hard of hearing, speech impaired or visually impaired > people. Deaf, hard of hearing, blind,... people could then > easily buy ANY off-the-shelf phone and fit it with a headset, > probably connected to the phone via Bluetooth. That would: > a) give them the same freedom of choice > b) prevent them from being marginalised through the use of > special equipment (just think about the link with hearing aids...) > > Surveys amongst people with disabilities show that this is a > major requirement: people with disabilities do not want to be > considered "special" users. They want access to the same > products and services as any other individual. > > The provision of such headsets as you mention, BTW, is not > only for the benefit of visually impaired people. These days, > I see much more non-disabled people walking around with their > Bluetooth handsets than visually impaired people. The use of > SMS by deaf and hard of hearing people is another such > example: no one would claim that SMS is only for those users. > Yet, they take advantage of a MAINSTREAM provision which > happens to suit their abilities and preferences. Hearing > people in noisy circumstances or in situations where they > cannot use voice will also revert to text in some > circumstances. The whole concept of "special" equipment is > well out of fashion these days. > Let's build mainstream technology so that it suits as much > users as possible, regardless of their abilities and > preferences. It will be to the benefit of ALL. > 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 > > > > ************************************************************** > ********** > 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 mailnull@www1.ietf.org Wed Jun 11 12:48:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16878 for ; Wed, 11 Jun 2003 12:48:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5BGlZb15784 for sipping-archive@odin.ietf.org; Wed, 11 Jun 2003 12:47:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BGlZm15781 for ; Wed, 11 Jun 2003 12:47: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 MAA16857 for ; Wed, 11 Jun 2003 12:47:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q8j2-0001jL-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 12:45:28 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Q8j1-0001jH-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 12:45:27 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BGjEm15655; Wed, 11 Jun 2003 12:45:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BGfGm15310 for ; Wed, 11 Jun 2003 12:41: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 MAA16699 for ; Wed, 11 Jun 2003 12:41:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q8cw-0001h1-00 for sipping@ietf.org; Wed, 11 Jun 2003 12:39:10 -0400 Received: from web41507.mail.yahoo.com ([66.218.93.90]) by ietf-mx with smtp (Exim 4.12) id 19Q8cu-0001gQ-00 for sipping@ietf.org; Wed, 11 Jun 2003 12:39:09 -0400 Message-ID: <20030611164040.4097.qmail@web41507.mail.yahoo.com> Received: from [131.107.3.83] by web41507.mail.yahoo.com via HTTP; Wed, 11 Jun 2003 09:40:40 PDT Date: Wed, 11 Jun 2003 09:40:40 -0700 (PDT) From: Sean Olson Subject: RE: [Sipping] proposed enhancement to dialog package To: "Drage, Keith \(Keith\)" , "'Rohan Mahy'" Cc: "'Jonathan Rosenberg'" , alan.johnston@wcom.com, "'sipping@ietf.org'" In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439ED5C@en0033exch001u.uk.lucent.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 an interesting discussion in an almost academic sense, but it really does not address the reality of the very simple service that is being described here. "hold", "passive", whatever else you want to call it means not sending/receiving media. We've all experienced this. And, yes, this can be independent of the ability to do SIP signaling. I think we are focusing too much on signaling here and not enough on the user experience that is being built. And I certainly don't want a history lesson in ISDN signaling ;-) --- "Drage, Keith (Keith)" wrote: > See below > > regards > > Keith > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > > -----Original Message----- > > From: Rohan Mahy [mailto:rohan@cisco.com] > > Sent: 10 June 2003 16:25 > > To: Drage, Keith (Keith) > > Cc: 'Jonathan Rosenberg'; alan.johnston@wcom.com; > 'sipping@ietf.org' > > Subject: Re: [Sipping] proposed enhancement to > dialog package > > > > > > Hi Keith, > > > > Hold as a UI concept significantly predated the > development of ISDN. > > Agreed, and my initial message identified in that > case (analogue PSTN terminals) that Hold was > originally to recall the register (and there was a > manual board equivalent as well) to allow access > resources to be used for signalling, as a result of > that signalling, the access resources might be used > for communication with another party, and only as a > by product of that did it necessarily result in loss > of communication path with the other party. > > > In any case, an ISDN user (Alice) who requests an > ISDN hold > > is still a > > passive participant by my definition. When > Alice's call is connected > > to a conference server and all the active > participants say "ok, we're > > leaving now, good bye", Alice is not active enough > to be able to hang > > up. > > Assuming your last statement still refers to an ISDN > user, then I can think of nothing in the above > scenario that prevents Alice sending a DISCONNECT, > and receiving a RELEASE back. Can you clarify. The > DSS1 basic call state machine is totally independent > of any subsidiary state machine relating to > hold/retrieve. > > If you are referring to hanging up the conference > bridge resources, then this is dependent on the > concept of ownership, which varies based on the > conference service provided, and also between public > and private networks. > > As a result, I think I am now confused about what > you actually mean by passive, can you elaborate > further. > > > > > > I agree that whatever we do, we need to describe > the semantics very > > crisply. > > > > thanks, > > -rohan > > > > > > On Tuesday, June 10, 2003, at 04:47 AM, Drage, > Keith (Keith) wrote: > > > > > I fail to see how thw property you are proposing > correlates in some > > > way to any concept of hold. I agree that "hold" > has many meanings, > > > based on which type of signalling you are using. > > > > > > To clarify, the prime function of hold in the > PSTN was never to > > > interrupt the communication, that was a side > effect of grabbing the > > > access resources to signal to another party. > Thus for ISDN, hold > > > therefore was only a removal of access resources > (the > > bearer) so that > > > that bearer could be reused for another call; > again the side effect > > > was to interrupt the communication. The sole > function of > > hold for SIP > > > is to interrupt the communication. > > > > > > Certainly, if an ISDN user places another user > on hold, I > > would regard > > > neither user as "passive" as you seem to be > defining here. > > > > > > If we are going to do this, can we make sure we > define the > > semantics > > > correctly. Otherwise we will surely create > confusion, > > particularly if > > > people try and equate this concept with that of > hold, and in > > > particular with the PSTN concept. > > > > > > regards > > > > > > Keith > > > > > > > > > Keith Drage > > > Lucent Technologies > > > Tel: +44 1793 776249 > > > Email: drage@lucent.com > > > > > >> -----Original Message----- > > >> From: Rohan Mahy [mailto:rohan@cisco.com] > > >> Sent: 03 June 2003 22:18 > > >> To: 'Jonathan Rosenberg' > > >> Cc: rohan@cisco.com; alan.johnston@wcom.com; > 'sipping@ietf.org' > > >> Subject: [Sipping] proposed enhancement to > dialog package > > >> > > >> > > >> Hi, > > >> > > >> There have been many requests for the dialog > package to express the > > >> concept of hold. The problem is that nobody had > an especially good > > >> definition of what "on-hold" meant. Some > suggested that all media > > >> streams being inactive implied that you are > "held", but > > this doesn't > > >> work for a service such as music-on-hold. > > >> > > >> I believe that folks actually want a slightly > different > > concept--that > > >> the semantics we want instead are already > described in the > > >> call control > > >> framework: > > >> > > >>> Participants may also be active or passive. > Active > > participants are > > >>> expected to be intelligent enough to leave a > conversation > > >> space when > > >>> they no longer desire to participate. (An > attentive human > > >> participant > > >>> is obviously active.) Some robotic > participants (such as a voice > > >>> messaging system, an instant messaging agent, > or a voice dialog > > >>> system) may be active participants if they can > leave the > > >> conversation > > >>> space when there is no human interaction. > Other robots > > (for example > > >>> our tone generating robot from the previous > example) are passive > > >>> participants. A human participant "on-hold" is > passive. > > >> > > >> I think we should add a new attribute to the > dialog package that > > >> expresses this property. My proposal is to > express this > > property only > > >> for the local side of each dialog by adding an > attribute > > to the state > > >> tag in the dialog-info notification body. The > example below > > >> includes a > > >> proposed (optional) participation attribute in > the state tag. > > >> > > >> > > >> xmlns="urn:ietf:params:xml:ns:dialog-info" > > >> version="3" > > >> state="partial" > > >> entity="sip:caller@bar.com"> > === message truncated === __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.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 mailnull@www1.ietf.org Wed Jun 11 14:00:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19506 for ; Wed, 11 Jun 2003 14:00:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5BHxWU20888 for sipping-archive@odin.ietf.org; Wed, 11 Jun 2003 13:59:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BHxWm20885 for ; Wed, 11 Jun 2003 13:59: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 NAA19498 for ; Wed, 11 Jun 2003 13:59:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q9qf-0002Fq-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 13:57:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Q9qe-0002Fn-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 13:57:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BHvmm20759; Wed, 11 Jun 2003 13:57:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BHuAm20671 for ; Wed, 11 Jun 2003 13: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 NAA19421 for ; Wed, 11 Jun 2003 13:56:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q9nP-0002EV-00 for sipping@ietf.org; Wed, 11 Jun 2003 13:54:03 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19Q9nO-0002EL-00 for sipping@ietf.org; Wed, 11 Jun 2003 13:54:02 -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 h5BHtRCL012892; Wed, 11 Jun 2003 10:55:27 -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 AIA17041; Wed, 11 Jun 2003 10:50:28 -0700 (PDT) Date: Wed, 11 Jun 2003 10:56:20 -0700 Subject: Re: [Sipping] proposed enhancement to dialog package Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Drage, Keith \(Keith\)" , "'Jonathan Rosenberg'" , alan.johnston@wcom.com, "'sipping@ietf.org'" To: Sean Olson From: Rohan Mahy In-Reply-To: <20030611164040.4097.qmail@web41507.mail.yahoo.com> Message-Id: <02277DDC-9C36-11D7-861A-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, June 11, 2003, at 09:40 AM, Sean Olson wrote: > This is an interesting discussion in an almost > academic sense, but it really does not address the > reality of the very simple service that is being > described here. > > "hold", "passive", whatever else you want to call it > means not sending/receiving media. I disagree. If you call someone on the average PBX or Key System, and ask them to put you on hold, you will typically still receive media (music, tones, irritating announcements). Likewise, if you call a call center or a big store, you are likely to wait "on hold" with some type of propaganda, music, or recorded message claiming that you are important. Clearly the user experience of the user-visible feature "Hold" is that hold does not typically equate to "no media". I believe that from a feature perspective the existence or presence of no media being sent/received is irrelevant. It does not affect my perception that I am on hold, nor does it affect the perception of my peer if I am on hold or not, since I can receive or not receive media and still know that I am on hold. My assertion is that what users really want to know is if the other end is actively participating. Do they care if I am still around? Is there the potential for interaction between me and my peer? With this concept, I can build useful features that users can relate to. For example, I would like "passive" participants (participants that cannot interact with me, like inane robots sending me Musak) to be automatically muted in my conference. I would like to express this property. If the name "passive" is too confusing, then feel free to suggest other terms. "interactivity" EQUAL ( "yes" / "no" ) ? thanks, -rohan > We've all > experienced this. And, yes, this can be independent of > the ability to do SIP signaling. > > I think we are focusing too much on signaling here and > not enough on the user experience that is being built. > And I certainly don't want a history lesson in ISDN > signaling ;-) > > > --- "Drage, Keith (Keith)" wrote: >> See below >> >> regards >> >> Keith >> >> Keith Drage >> Lucent Technologies >> Tel: +44 1793 776249 >> Email: drage@lucent.com >> >>> -----Original Message----- >>> From: Rohan Mahy [mailto:rohan@cisco.com] >>> Sent: 10 June 2003 16:25 >>> To: Drage, Keith (Keith) >>> Cc: 'Jonathan Rosenberg'; alan.johnston@wcom.com; >> 'sipping@ietf.org' >>> Subject: Re: [Sipping] proposed enhancement to >> dialog package >>> >>> >>> Hi Keith, >>> >>> Hold as a UI concept significantly predated the >> development of ISDN. >> >> Agreed, and my initial message identified in that >> case (analogue PSTN terminals) that Hold was >> originally to recall the register (and there was a >> manual board equivalent as well) to allow access >> resources to be used for signalling, as a result of >> that signalling, the access resources might be used >> for communication with another party, and only as a >> by product of that did it necessarily result in loss >> of communication path with the other party. >> >>> In any case, an ISDN user (Alice) who requests an >> ISDN hold >>> is still a >>> passive participant by my definition. When >> Alice's call is connected >>> to a conference server and all the active >> participants say "ok, we're >>> leaving now, good bye", Alice is not active enough >> to be able to hang >>> up. >> >> Assuming your last statement still refers to an ISDN >> user, then I can think of nothing in the above >> scenario that prevents Alice sending a DISCONNECT, >> and receiving a RELEASE back. Can you clarify. The >> DSS1 basic call state machine is totally independent >> of any subsidiary state machine relating to >> hold/retrieve. >> >> If you are referring to hanging up the conference >> bridge resources, then this is dependent on the >> concept of ownership, which varies based on the >> conference service provided, and also between public >> and private networks. >> >> As a result, I think I am now confused about what >> you actually mean by passive, can you elaborate >> further. >> >> >>> >>> I agree that whatever we do, we need to describe >> the semantics very >>> crisply. >>> >>> thanks, >>> -rohan >>> >>> >>> On Tuesday, June 10, 2003, at 04:47 AM, Drage, >> Keith (Keith) wrote: >>> >>>> I fail to see how thw property you are proposing >> correlates in some >>>> way to any concept of hold. I agree that "hold" >> has many meanings, >>>> based on which type of signalling you are using. >>>> >>>> To clarify, the prime function of hold in the >> PSTN was never to >>>> interrupt the communication, that was a side >> effect of grabbing the >>>> access resources to signal to another party. >> Thus for ISDN, hold >>>> therefore was only a removal of access resources >> (the >>> bearer) so that >>>> that bearer could be reused for another call; >> again the side effect >>>> was to interrupt the communication. The sole >> function of >>> hold for SIP >>>> is to interrupt the communication. >>>> >>>> Certainly, if an ISDN user places another user >> on hold, I >>> would regard >>>> neither user as "passive" as you seem to be >> defining here. >>>> >>>> If we are going to do this, can we make sure we >> define the >>> semantics >>>> correctly. Otherwise we will surely create >> confusion, >>> particularly if >>>> people try and equate this concept with that of >> hold, and in >>>> particular with the PSTN concept. >>>> >>>> regards >>>> >>>> Keith >>>> >>>> >>>> Keith Drage >>>> Lucent Technologies >>>> Tel: +44 1793 776249 >>>> Email: drage@lucent.com >>>> >>>>> -----Original Message----- >>>>> From: Rohan Mahy [mailto:rohan@cisco.com] >>>>> Sent: 03 June 2003 22:18 >>>>> To: 'Jonathan Rosenberg' >>>>> Cc: rohan@cisco.com; alan.johnston@wcom.com; >> 'sipping@ietf.org' >>>>> Subject: [Sipping] proposed enhancement to >> dialog package >>>>> >>>>> >>>>> Hi, >>>>> >>>>> There have been many requests for the dialog >> package to express the >>>>> concept of hold. The problem is that nobody had >> an especially good >>>>> definition of what "on-hold" meant. Some >> suggested that all media >>>>> streams being inactive implied that you are >> "held", but >>> this doesn't >>>>> work for a service such as music-on-hold. >>>>> >>>>> I believe that folks actually want a slightly >> different >>> concept--that >>>>> the semantics we want instead are already >> described in the >>>>> call control >>>>> framework: >>>>> >>>>>> Participants may also be active or passive. >> Active >>> participants are >>>>>> expected to be intelligent enough to leave a >> conversation >>>>> space when >>>>>> they no longer desire to participate. (An >> attentive human >>>>> participant >>>>>> is obviously active.) Some robotic >> participants (such as a voice >>>>>> messaging system, an instant messaging agent, >> or a voice dialog >>>>>> system) may be active participants if they can >> leave the >>>>> conversation >>>>>> space when there is no human interaction. >> Other robots >>> (for example >>>>>> our tone generating robot from the previous >> example) are passive >>>>>> participants. A human participant "on-hold" is >> passive. >>>>> >>>>> I think we should add a new attribute to the >> dialog package that >>>>> expresses this property. My proposal is to >> express this >>> property only >>>>> for the local side of each dialog by adding an >> attribute >>> to the state >>>>> tag in the dialog-info notification body. The >> example below >>>>> includes a >>>>> proposed (optional) participation attribute in >> the state tag. >>>>> >>>>> >>>>> > xmlns="urn:ietf:params:xml:ns:dialog-info" >>>>> version="3" >>>>> state="partial" >>>>> entity="sip:caller@bar.com"> >> > === message truncated === > > > __________________________________ > Do you Yahoo!? > Yahoo! Calendar - Free online calendar with sync to Outlook(TM). > http://calendar.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 mailnull@www1.ietf.org Wed Jun 11 17:40:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04400 for ; Wed, 11 Jun 2003 17:40:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5BLeWt08457 for sipping-archive@odin.ietf.org; Wed, 11 Jun 2003 17:40:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BLeWm08454 for ; Wed, 11 Jun 2003 17:40: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 RAA04387 for ; Wed, 11 Jun 2003 17:40:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QDIW-0004Dz-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 17:38:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QDIW-0004Dw-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 17:38:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BLcwm08331; Wed, 11 Jun 2003 17:38:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BLWFm07152 for ; Wed, 11 Jun 2003 17:32: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 RAA04123 for ; Wed, 11 Jun 2003 17:32:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QDAV-0004Aj-00 for sipping@ietf.org; Wed, 11 Jun 2003 17:30:07 -0400 Received: from pmesmtp01.wcom.com ([199.249.20.1]) by ietf-mx with esmtp (Exim 4.12) id 19QDAV-0004AZ-00 for sipping@ietf.org; Wed, 11 Jun 2003 17:30:07 -0400 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HGC00IEV6BP6V@firewall.wcom.com> for sipping@ietf.org; Wed, 11 Jun 2003 21:28:37 +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 <0HGC00L016BP7E@pmismtp02.wcomnet.com>; Wed, 11 Jun 2003 21:28:37 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.97.129]) by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HGC00JKS6BNWV@pmismtp02.wcomnet.com>; Wed, 11 Jun 2003 21:28:37 +0000 (GMT) Date: Wed, 11 Jun 2003 16:28:34 -0500 From: Alan Johnston Subject: RE: [Sipping] refer and pstn In-reply-to: <16102.54630.772069.225765@harjus.tutpro.com> X-Sender: Alan.Johnston@pop.mcit.com To: Juha Heinanen , "Christer Holmberg (LMF)" Cc: "'Francois Audet'" , Tom-PT Taylor , "'sipping@ietf.org'" Message-id: <5.2.1.1.0.20030611162038.01d9ac10@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed References: <" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , At 10:08 AM 6/11/2003 +0300, Juha Heinanen wrote: >Christer Holmberg (LMF) writes: > > > Exactly what information do you want the protocol to provide? > >as i mentioned earlier, for example, the gw would like to know if >referred-by can be trusted and that the party doing the refer has the >right the forward a call to the refer-to number. The GW uses the same approach for a REFER that it uses to authenticate/authorize a BYE - using standard SIP means. The transferee does not need to trust the Referred-By header - it can authenticate the REFER. That is a requirement of the transfer target which receives the triggered INVITE which may contain the Referred-By header. If the transfer target is unable to verify the Referred-By header (using the cryptographic means discussed in the draft) and the target is screening calls, then the target should reject the INVITE. A PSTN gateway is just a normal SIP UA - the main difference with respect to REFER is that a PSTN gateway can not in general initiate a transfer due to the user interface limitations of phones, unless there is some mid-call DTMF string that the gateway recognizes. Thanks, Alan Johnston MCI >-- juha >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jun 11 18:43:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07827 for ; Wed, 11 Jun 2003 18:43:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5BMge114092 for sipping-archive@odin.ietf.org; Wed, 11 Jun 2003 18:42:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BMgem14089 for ; Wed, 11 Jun 2003 18:42: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 SAA07820 for ; Wed, 11 Jun 2003 18:42:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QEGe-0004tU-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 18:40:32 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QEGd-0004tR-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 18:40:31 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BMfOm13988; Wed, 11 Jun 2003 18:41:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BMdAm13690 for ; Wed, 11 Jun 2003 18:39: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 SAA07710 for ; Wed, 11 Jun 2003 18:39:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QEDG-0004qo-00 for sipping@ietf.org; Wed, 11 Jun 2003 18:37:02 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by ietf-mx with esmtp (Exim 4.12) id 19QEDG-0004qP-00 for sipping@ietf.org; Wed, 11 Jun 2003 18:37:02 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h5BMcXI2014764; Wed, 11 Jun 2003 15:38:34 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIA51006; Wed, 11 Jun 2003 15:33:34 -0700 (PDT) Date: Wed, 11 Jun 2003 15:39:32 -0700 Subject: Re: [Sipping] refer and pstn Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Chris Boulton" , "Christer Holmberg (LMF)" , "Pascal Dore" , To: Juha Heinanen From: Rohan Mahy In-Reply-To: <16101.64836.892342.884866@harjus.tutpro.com> Message-Id: <91C68E47-9C5D-11D7-A0EF-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Juha, There are really two issues here: 1) authorizing the REFER request 2) authorizing the triggered request Authorizing a REFER request is fairly complicated, but for trunking gateways my guidelines to our developers where something along these lines: - only accept REFER requests with a Refer-To scheme of SIP or tel (today I would include SIPS). - only accept REFER requests in the context of an existing dialog (i think unsolicited REFER makes sense on a phone, but not on a gateway). - authenticate that the originator of the REFER has the same credentials as the originator of the current dialog - reject REFER requests with Refer-Tos for methods that you don't want to deal with (in my experience, INVITE is usually method anyone ever considers). - ignore any non-relevant or unsupported Refer-To URI parameters (for example: ttl, transport) - reject REFER requests with Refer-Tos that contain Vias, CSeq and certain other especially dangerous headers - ignore another set of headers (like From) based on your policy - include a Referred-By header - if your policy is to send all new request through a proxy, send the REFER through the proxy Then you authorize the triggered request. However you have to consider the Referred-By header when you do so. This is especially important for say an INVITE with Replaces. hope this helps. thanks, -rohan On Tuesday, June 10, 2003, at 08:46 AM, Juha Heinanen wrote: > Chris Boulton writes: > >> Are these not security issues rather than base protocol problems. > > i don't know what they are. i was just asking, what were the makers of > pstn gws thinking when they included refer UAS capability in their > boxes. how is an operator of such a gw suppose to solve these kind of > security issues. > > -- juha > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jun 11 18:48:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08183 for ; Wed, 11 Jun 2003 18:48:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5BMm9214379 for sipping-archive@odin.ietf.org; Wed, 11 Jun 2003 18:48:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BMm9m14376 for ; Wed, 11 Jun 2003 18: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 SAA08180 for ; Wed, 11 Jun 2003 18:48:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QELx-0004y7-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 18:46:01 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QELw-0004y4-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 18:46:00 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BMl8m14330; Wed, 11 Jun 2003 18:47:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BMkQm14296 for ; Wed, 11 Jun 2003 18:46: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 SAA08113 for ; Wed, 11 Jun 2003 18:46:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QEKI-0004xJ-00 for sipping@ietf.org; Wed, 11 Jun 2003 18:44:18 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by ietf-mx with esmtp (Exim 4.12) id 19QEKH-0004wf-00 for sipping@ietf.org; Wed, 11 Jun 2003 18:44:17 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h5BMjoI2018427; Wed, 11 Jun 2003 15:45:51 -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 AIA51685; Wed, 11 Jun 2003 15:40:51 -0700 (PDT) Date: Wed, 11 Jun 2003 15:46:50 -0700 Subject: Re: [Sipping] refer and pstn Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Christer Holmberg (LMF)" , "'Francois Audet'" , Tom-PT Taylor , "'sipping@ietf.org'" To: Juha Heinanen From: Rohan Mahy In-Reply-To: <16102.55954.101362.375799@harjus.tutpro.com> Message-Id: <96DC0AD0-9C5E-11D7-A0EF-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, June 11, 2003, at 12:30 AM, Juha Heinanen wrote: > Christer Holmberg (LMF) writes: > >> That is if the gw cares. The who-is-allowed-to-call-who handling can >> also be done by a proxy ... > > exactly, so lets focus on the proxy instead. as i have asked before, > how does the proxy know if referred-by has been checked upstream or how > can it indicate to downstream if it itself has verified referred-by. > that is, what is the equivalent of remote-party-id for referred-by? I sense another "trusted network" p-header discussion looming ahead. If you want to be really sure, then you use an authentication identity body. If you are just using the transitive trust model, then your proxy would need to do a number of gross things including verify that the Referred-By header in a REFER matches the identity of the sender. Gateways and other "trusted" UAs would also need to reject any REFER requests which did not arrive through their proxy with a 305 Use Proxy. > also, lets assume that the uri in refer-to contains a telephone number. > if so, the proxy must make enum query on it. where in the request does > the proxy store the result of the enum query? the proxy retargets the Request-URI in the triggered INVITE, not the Refer-To URI thx, -r > -- juha > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Jun 11 19:24: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 TAA09168 for ; Wed, 11 Jun 2003 19:24:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5BNOVx16787 for sipping-archive@odin.ietf.org; Wed, 11 Jun 2003 19:24:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BNOVm16784 for ; Wed, 11 Jun 2003 19:24: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 TAA09162 for ; Wed, 11 Jun 2003 19:24:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QEvA-0005Dm-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 19:22:24 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QEv9-0005Di-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 19:22:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BNNDm16567; Wed, 11 Jun 2003 19:23:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BNFYm16266 for ; Wed, 11 Jun 2003 19:15: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 TAA08787 for ; Wed, 11 Jun 2003 19:15:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QEmW-00058V-00 for sipping@ietf.org; Wed, 11 Jun 2003 19:13:28 -0400 Received: from outbound04.telus.net ([199.185.220.223] helo=priv-edtnes15-hme0.telusplanet.net) by ietf-mx with esmtp (Exim 4.12) id 19QEmV-00057u-00 for sipping@ietf.org; Wed, 11 Jun 2003 19:13:27 -0400 Received: from me ([216.232.86.234]) by priv-edtnes15-hme0.telusplanet.net (InterMail vM.5.01.05.17 201-253-122-126-117-20021021) with SMTP id <20030611231457.SKWV1656.priv-edtnes15-hme0.telusplanet.net@me>; Wed, 11 Jun 2003 17:14:57 -0600 From: "Jason Arnold" To: "Rohan Mahy" , "Sean Olson" Cc: "Drage, Keith \(Keith\)" , "'Jonathan Rosenberg'" , , Subject: RE: [Sipping] proposed enhancement to dialog package Date: Wed, 11 Jun 2003 16:20:56 -0700 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) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <02277DDC-9C36-11D7-861A-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree to an extent. If the hold presents "dead air", most people will feel lost with out some indication that they are on hold. It would seem that people require the assurance that the receiving party has not terminated their call. It could be assumed that if the hold period is for an extended period of time, only presenting silence to the calling party, people may think they have been accidentally "disconnected" and terminate their call. It is important to supply a media stream (even irritating propaganda) during the hold session. Non-Conformity to current expectations of people while on hold would seem illogical. Thanks, Jason On Wednesday, June 11, 2003, at 09:40 AM, Sean Olson wrote: > This is an interesting discussion in an almost > academic sense, but it really does not address the > reality of the very simple service that is being > described here. > > "hold", "passive", whatever else you want to call it > means not sending/receiving media. I disagree. If you call someone on the average PBX or Key System, and ask them to put you on hold, you will typically still receive media (music, tones, irritating announcements). Likewise, if you call a call center or a big store, you are likely to wait "on hold" with some type of propaganda, music, or recorded message claiming that you are important. Clearly the user experience of the user-visible feature "Hold" is that hold does not typically equate to "no media". I believe that from a feature perspective the existence or presence of no media being sent/received is irrelevant. It does not affect my perception that I am on hold, nor does it affect the perception of my peer if I am on hold or not, since I can receive or not receive media and still know that I am on hold. My assertion is that what users really want to know is if the other end is actively participating. Do they care if I am still around? Is there the potential for interaction between me and my peer? With this concept, I can build useful features that users can relate to. For example, I would like "passive" participants (participants that cannot interact with me, like inane robots sending me Musak) to be automatically muted in my conference. I would like to express this property. If the name "passive" is too confusing, then feel free to suggest other terms. "interactivity" EQUAL ( "yes" / "no" ) ? thanks, -rohan > We've all > experienced this. And, yes, this can be independent of > the ability to do SIP signaling. > > I think we are focusing too much on signaling here and > not enough on the user experience that is being built. > And I certainly don't want a history lesson in ISDN > signaling ;-) > > > --- "Drage, Keith (Keith)" wrote: >> See below >> >> regards >> >> Keith >> >> Keith Drage >> Lucent Technologies >> Tel: +44 1793 776249 >> Email: drage@lucent.com >> >>> -----Original Message----- >>> From: Rohan Mahy [mailto:rohan@cisco.com] >>> Sent: 10 June 2003 16:25 >>> To: Drage, Keith (Keith) >>> Cc: 'Jonathan Rosenberg'; alan.johnston@wcom.com; >> 'sipping@ietf.org' >>> Subject: Re: [Sipping] proposed enhancement to >> dialog package >>> >>> >>> Hi Keith, >>> >>> Hold as a UI concept significantly predated the >> development of ISDN. >> >> Agreed, and my initial message identified in that >> case (analogue PSTN terminals) that Hold was >> originally to recall the register (and there was a >> manual board equivalent as well) to allow access >> resources to be used for signalling, as a result of >> that signalling, the access resources might be used >> for communication with another party, and only as a >> by product of that did it necessarily result in loss >> of communication path with the other party. >> >>> In any case, an ISDN user (Alice) who requests an >> ISDN hold >>> is still a >>> passive participant by my definition. When >> Alice's call is connected >>> to a conference server and all the active >> participants say "ok, we're >>> leaving now, good bye", Alice is not active enough >> to be able to hang >>> up. >> >> Assuming your last statement still refers to an ISDN >> user, then I can think of nothing in the above >> scenario that prevents Alice sending a DISCONNECT, >> and receiving a RELEASE back. Can you clarify. The >> DSS1 basic call state machine is totally independent >> of any subsidiary state machine relating to >> hold/retrieve. >> >> If you are referring to hanging up the conference >> bridge resources, then this is dependent on the >> concept of ownership, which varies based on the >> conference service provided, and also between public >> and private networks. >> >> As a result, I think I am now confused about what >> you actually mean by passive, can you elaborate >> further. >> >> >>> >>> I agree that whatever we do, we need to describe >> the semantics very >>> crisply. >>> >>> thanks, >>> -rohan >>> >>> >>> On Tuesday, June 10, 2003, at 04:47 AM, Drage, >> Keith (Keith) wrote: >>> >>>> I fail to see how thw property you are proposing >> correlates in some >>>> way to any concept of hold. I agree that "hold" >> has many meanings, >>>> based on which type of signalling you are using. >>>> >>>> To clarify, the prime function of hold in the >> PSTN was never to >>>> interrupt the communication, that was a side >> effect of grabbing the >>>> access resources to signal to another party. >> Thus for ISDN, hold >>>> therefore was only a removal of access resources >> (the >>> bearer) so that >>>> that bearer could be reused for another call; >> again the side effect >>>> was to interrupt the communication. The sole >> function of >>> hold for SIP >>>> is to interrupt the communication. >>>> >>>> Certainly, if an ISDN user places another user >> on hold, I >>> would regard >>>> neither user as "passive" as you seem to be >> defining here. >>>> >>>> If we are going to do this, can we make sure we >> define the >>> semantics >>>> correctly. Otherwise we will surely create >> confusion, >>> particularly if >>>> people try and equate this concept with that of >> hold, and in >>>> particular with the PSTN concept. >>>> >>>> regards >>>> >>>> Keith >>>> >>>> >>>> Keith Drage >>>> Lucent Technologies >>>> Tel: +44 1793 776249 >>>> Email: drage@lucent.com >>>> >>>>> -----Original Message----- >>>>> From: Rohan Mahy [mailto:rohan@cisco.com] >>>>> Sent: 03 June 2003 22:18 >>>>> To: 'Jonathan Rosenberg' >>>>> Cc: rohan@cisco.com; alan.johnston@wcom.com; >> 'sipping@ietf.org' >>>>> Subject: [Sipping] proposed enhancement to >> dialog package >>>>> >>>>> >>>>> Hi, >>>>> >>>>> There have been many requests for the dialog >> package to express the >>>>> concept of hold. The problem is that nobody had >> an especially good >>>>> definition of what "on-hold" meant. Some >> suggested that all media >>>>> streams being inactive implied that you are >> "held", but >>> this doesn't >>>>> work for a service such as music-on-hold. >>>>> >>>>> I believe that folks actually want a slightly >> different >>> concept--that >>>>> the semantics we want instead are already >> described in the >>>>> call control >>>>> framework: >>>>> >>>>>> Participants may also be active or passive. >> Active >>> participants are >>>>>> expected to be intelligent enough to leave a >> conversation >>>>> space when >>>>>> they no longer desire to participate. (An >> attentive human >>>>> participant >>>>>> is obviously active.) Some robotic >> participants (such as a voice >>>>>> messaging system, an instant messaging agent, >> or a voice dialog >>>>>> system) may be active participants if they can >> leave the >>>>> conversation >>>>>> space when there is no human interaction. >> Other robots >>> (for example >>>>>> our tone generating robot from the previous >> example) are passive >>>>>> participants. A human participant "on-hold" is >> passive. >>>>> >>>>> I think we should add a new attribute to the >> dialog package that >>>>> expresses this property. My proposal is to >> express this >>> property only >>>>> for the local side of each dialog by adding an >> attribute >>> to the state >>>>> tag in the dialog-info notification body. The >> example below >>>>> includes a >>>>> proposed (optional) participation attribute in >> the state tag. >>>>> >>>>> >>>>> > xmlns="urn:ietf:params:xml:ns:dialog-info" >>>>> version="3" >>>>> state="partial" >>>>> entity="sip:caller@bar.com"> >> > === message truncated === > > > __________________________________ > Do you Yahoo!? > Yahoo! Calendar - Free online calendar with sync to Outlook(TM). > http://calendar.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 mailnull@www1.ietf.org Wed Jun 11 20:18:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10281 for ; Wed, 11 Jun 2003 20:18:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5C0I2X20539 for sipping-archive@odin.ietf.org; Wed, 11 Jun 2003 20:18:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C0I2m20536 for ; Wed, 11 Jun 2003 20:18: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 UAA10274 for ; Wed, 11 Jun 2003 20:17:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QFkx-0005Wh-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 20:15:55 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QFkw-0005We-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 20:15:54 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C0GVm20501; Wed, 11 Jun 2003 20:16:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C0F4m20449 for ; Wed, 11 Jun 2003 20:15: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 UAA10230 for ; Wed, 11 Jun 2003 20:15:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QFi4-0005Ve-00 for sipping@ietf.org; Wed, 11 Jun 2003 20:12:56 -0400 Received: from web41506.mail.yahoo.com ([66.218.93.89]) by ietf-mx with smtp (Exim 4.12) id 19QFi4-0005VV-00 for sipping@ietf.org; Wed, 11 Jun 2003 20:12:56 -0400 Message-ID: <20030612001431.96893.qmail@web41506.mail.yahoo.com> Received: from [207.46.228.98] by web41506.mail.yahoo.com via HTTP; Wed, 11 Jun 2003 17:14:31 PDT Date: Wed, 11 Jun 2003 17:14:31 -0700 (PDT) From: Sean Olson Subject: RE: [Sipping] proposed enhancement to dialog package To: Jason Arnold , Rohan Mahy Cc: "Drage, Keith \(Keith\)" , "'Jonathan Rosenberg'" , alan.johnston@wcom.com, sipping@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , I don't get it. What we are talking about is an INDICATION of what is happening on a dialog. I certaingly am not proposing CONTROL of what happens on that dialog. i.e. I don't care whether you play hold music or not. The important thing is that I know one of the parties in a dialog is "on hold". From my perspective, "on hold" means that the two parties on either end of the dialog are not actively engaged in communication. This is what I mean by "no media" (no relevant media being exchanged). From this point of view, "passive" sounds perfectly reasonable to me. And it does really relate to the availability of that party to potentially take part in another dialog --- but then we start splitting hairs over the best way to reproduce the PSTN experience. --- Jason Arnold wrote: > I agree to an extent. > > If the hold presents "dead air", most people will > feel lost with out some > indication that they are on hold. It would seem > that people require the > assurance that the receiving party has not > terminated their call. It could > be assumed that if the hold period is for an > extended period of time, only > presenting silence to the calling party, people may > think they have been > accidentally "disconnected" and terminate their > call. > > It is important to supply a media stream (even > irritating propaganda) during > the hold session. Non-Conformity to current > expectations of people while on > hold would seem illogical. > > Thanks, > > Jason > > On Wednesday, June 11, 2003, at 09:40 AM, Sean Olson > wrote: > > > This is an interesting discussion in an almost > > academic sense, but it really does not address the > > reality of the very simple service that is being > > described here. > > > > "hold", "passive", whatever else you want to call > it > > means not sending/receiving media. > > I disagree. > > If you call someone on the average PBX or Key > System, and ask them to > put you on hold, you will typically still receive > media (music, tones, > irritating announcements). Likewise, if you call a > call center or a > big store, you are likely to wait "on hold" with > some type of > propaganda, music, or recorded message claiming that > you are important. > > Clearly the user experience of the user-visible > feature "Hold" is that > hold does not typically equate to "no media". > > I believe that from a feature perspective the > existence or presence of > no media being sent/received is irrelevant. It does > not affect my > perception that I am on hold, nor does it affect the > perception of my > peer if I am on hold or not, since I can receive or > not receive media > and still know that I am on hold. > > My assertion is that what users really want to know > is if the other end > is actively participating. Do they care if I am > still around? Is > there the potential for interaction between me and > my peer? > > With this concept, I can build useful features that > users can relate > to. For example, I would like "passive" > participants (participants > that cannot interact with me, like inane robots > sending me Musak) to be > automatically muted in my conference. > > I would like to express this property. If the name > "passive" is too > confusing, then feel free to suggest other terms. > "interactivity" > EQUAL ( "yes" / "no" ) ? > > thanks, > -rohan > > > > We've all > > experienced this. And, yes, this can be > independent of > > the ability to do SIP signaling. > > > > I think we are focusing too much on signaling here > and > > not enough on the user experience that is being > built. > > And I certainly don't want a history lesson in > ISDN > > signaling ;-) > > > > > > --- "Drage, Keith (Keith)" > wrote: > >> See below > >> > >> regards > >> > >> Keith > >> > >> Keith Drage > >> Lucent Technologies > >> Tel: +44 1793 776249 > >> Email: drage@lucent.com > >> > >>> -----Original Message----- > >>> From: Rohan Mahy [mailto:rohan@cisco.com] > >>> Sent: 10 June 2003 16:25 > >>> To: Drage, Keith (Keith) > >>> Cc: 'Jonathan Rosenberg'; > alan.johnston@wcom.com; > >> 'sipping@ietf.org' > >>> Subject: Re: [Sipping] proposed enhancement to > >> dialog package > >>> > >>> > >>> Hi Keith, > >>> > >>> Hold as a UI concept significantly predated the > >> development of ISDN. > >> > >> Agreed, and my initial message identified in that > >> case (analogue PSTN terminals) that Hold was > >> originally to recall the register (and there was > a > >> manual board equivalent as well) to allow access > >> resources to be used for signalling, as a result > of > >> that signalling, the access resources might be > used > >> for communication with another party, and only as > a > >> by product of that did it necessarily result in > loss > >> of communication path with the other party. > >> > >>> In any case, an ISDN user (Alice) who requests > an > >> ISDN hold > >>> is still a > >>> passive participant by my definition. When > >> Alice's call is connected > >>> to a conference server and all the active > >> participants say "ok, we're > >>> leaving now, good bye", Alice is not active > enough > >> to be able to hang > >>> up. > >> > >> Assuming your last statement still refers to an > ISDN > >> user, then I can think of nothing in the above > >> scenario that prevents Alice sending a > DISCONNECT, > >> and receiving a RELEASE back. Can you clarify. > The > >> DSS1 basic call state machine is totally > independent > >> of any subsidiary state machine relating to > >> hold/retrieve. > >> > >> If you are referring to hanging up the conference > >> bridge resources, then this is dependent on the > >> concept of ownership, which varies based on the > >> conference service provided, and also between > public > >> and private networks. > >> > >> As a result, I think I am now confused about what > >> you actually mean by passive, can you elaborate > >> further. > >> > >> > >>> > >>> I agree that whatever we do, we need to describe > >> the semantics very > >>> crisply. > >>> > >>> thanks, > >>> -rohan > >>> > >>> > >>> On Tuesday, June 10, 2003, at 04:47 AM, Drage, > >> Keith (Keith) wrote: > >>> > >>>> I fail to see how thw property you are > proposing > >> correlates in some > >>>> way to any concept of hold. I agree that "hold" > >> has many meanings, > === message truncated === __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.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 mailnull@www1.ietf.org Wed Jun 11 20:26:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10384 for ; Wed, 11 Jun 2003 20:26:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5C0QN420782 for sipping-archive@odin.ietf.org; Wed, 11 Jun 2003 20:26:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C0QNm20779 for ; Wed, 11 Jun 2003 20: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 UAA10380 for ; Wed, 11 Jun 2003 20:26:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QFt2-0005Z0-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 20:24:16 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QFt1-0005Yx-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 20:24:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C0N7m20693; Wed, 11 Jun 2003 20:23:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C0Mkm20670 for ; Wed, 11 Jun 2003 20:22: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 UAA10332 for ; Wed, 11 Jun 2003 20:22:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QFpX-0005Xv-00 for sipping@ietf.org; Wed, 11 Jun 2003 20:20:39 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19QFpX-0005Xp-00 for sipping@ietf.org; Wed, 11 Jun 2003 20:20:39 -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 h5C0M5ms011793; Wed, 11 Jun 2003 17:22:05 -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 AIA61571; Wed, 11 Jun 2003 17:17:06 -0700 (PDT) Date: Wed, 11 Jun 2003 17:23:04 -0700 Subject: Re: [Sipping] proposed enhancement to dialog package Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Jason Arnold , "Drage, Keith \(Keith\)" , "'Jonathan Rosenberg'" , alan.johnston@wcom.com, sipping@ietf.org To: Sean Olson From: Rohan Mahy In-Reply-To: <20030612001431.96893.qmail@web41506.mail.yahoo.com> Message-Id: <08BF964F-9C6C-11D7-A0EF-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, June 11, 2003, at 05:14 PM, Sean Olson wrote: > I don't get it. What we are talking about is an > INDICATION of what is happening on a dialog. What I am describing is an indication of a PROPERTY of a dialog or the associated participant. > I certaingly am not proposing CONTROL of what happens on > that dialog. i.e. I don't care whether you play hold > music or not. The important thing is that I know one > of the parties in a dialog is "on hold". From my > perspective, "on hold" means that the two parties on > either end of the dialog are not actively engaged in > communication. exactly. > This is what I mean by "no media" (no > relevant media being exchanged). well, the difference between no media and no relevant media is a completely different kettle of fish. > From this point of > view, "passive" sounds perfectly reasonable to me. And > it does really relate to the availability of that > party to potentially take part in another dialog --- > but then we start splitting hairs over the best way to > reproduce the PSTN experience. I don't think we need to reproduce the PSTN definition of hold, or the existing experience of being on a conference call listening to someone's Musak. ;-) thx, -r > > --- Jason Arnold wrote: >> I agree to an extent. >> >> If the hold presents "dead air", most people will >> feel lost with out some >> indication that they are on hold. It would seem >> that people require the >> assurance that the receiving party has not >> terminated their call. It could >> be assumed that if the hold period is for an >> extended period of time, only >> presenting silence to the calling party, people may >> think they have been >> accidentally "disconnected" and terminate their >> call. >> >> It is important to supply a media stream (even >> irritating propaganda) during >> the hold session. Non-Conformity to current >> expectations of people while on >> hold would seem illogical. >> >> Thanks, >> >> Jason >> >> On Wednesday, June 11, 2003, at 09:40 AM, Sean Olson >> wrote: >> >>> This is an interesting discussion in an almost >>> academic sense, but it really does not address the >>> reality of the very simple service that is being >>> described here. >>> >>> "hold", "passive", whatever else you want to call >> it >>> means not sending/receiving media. >> >> I disagree. >> >> If you call someone on the average PBX or Key >> System, and ask them to >> put you on hold, you will typically still receive >> media (music, tones, >> irritating announcements). Likewise, if you call a >> call center or a >> big store, you are likely to wait "on hold" with >> some type of >> propaganda, music, or recorded message claiming that >> you are important. >> >> Clearly the user experience of the user-visible >> feature "Hold" is that >> hold does not typically equate to "no media". >> >> I believe that from a feature perspective the >> existence or presence of >> no media being sent/received is irrelevant. It does >> not affect my >> perception that I am on hold, nor does it affect the >> perception of my >> peer if I am on hold or not, since I can receive or >> not receive media >> and still know that I am on hold. >> >> My assertion is that what users really want to know >> is if the other end >> is actively participating. Do they care if I am >> still around? Is >> there the potential for interaction between me and >> my peer? >> >> With this concept, I can build useful features that >> users can relate >> to. For example, I would like "passive" >> participants (participants >> that cannot interact with me, like inane robots >> sending me Musak) to be >> automatically muted in my conference. >> >> I would like to express this property. If the name >> "passive" is too >> confusing, then feel free to suggest other terms. >> "interactivity" >> EQUAL ( "yes" / "no" ) ? >> >> thanks, >> -rohan >> >> >>> We've all >>> experienced this. And, yes, this can be >> independent of >>> the ability to do SIP signaling. >>> >>> I think we are focusing too much on signaling here >> and >>> not enough on the user experience that is being >> built. >>> And I certainly don't want a history lesson in >> ISDN >>> signaling ;-) >>> >>> >>> --- "Drage, Keith (Keith)" >> wrote: >>>> See below >>>> >>>> regards >>>> >>>> Keith >>>> >>>> Keith Drage >>>> Lucent Technologies >>>> Tel: +44 1793 776249 >>>> Email: drage@lucent.com >>>> >>>>> -----Original Message----- >>>>> From: Rohan Mahy [mailto:rohan@cisco.com] >>>>> Sent: 10 June 2003 16:25 >>>>> To: Drage, Keith (Keith) >>>>> Cc: 'Jonathan Rosenberg'; >> alan.johnston@wcom.com; >>>> 'sipping@ietf.org' >>>>> Subject: Re: [Sipping] proposed enhancement to >>>> dialog package >>>>> >>>>> >>>>> Hi Keith, >>>>> >>>>> Hold as a UI concept significantly predated the >>>> development of ISDN. >>>> >>>> Agreed, and my initial message identified in that >>>> case (analogue PSTN terminals) that Hold was >>>> originally to recall the register (and there was >> a >>>> manual board equivalent as well) to allow access >>>> resources to be used for signalling, as a result >> of >>>> that signalling, the access resources might be >> used >>>> for communication with another party, and only as >> a >>>> by product of that did it necessarily result in >> loss >>>> of communication path with the other party. >>>> >>>>> In any case, an ISDN user (Alice) who requests >> an >>>> ISDN hold >>>>> is still a >>>>> passive participant by my definition. When >>>> Alice's call is connected >>>>> to a conference server and all the active >>>> participants say "ok, we're >>>>> leaving now, good bye", Alice is not active >> enough >>>> to be able to hang >>>>> up. >>>> >>>> Assuming your last statement still refers to an >> ISDN >>>> user, then I can think of nothing in the above >>>> scenario that prevents Alice sending a >> DISCONNECT, >>>> and receiving a RELEASE back. Can you clarify. >> The >>>> DSS1 basic call state machine is totally >> independent >>>> of any subsidiary state machine relating to >>>> hold/retrieve. >>>> >>>> If you are referring to hanging up the conference >>>> bridge resources, then this is dependent on the >>>> concept of ownership, which varies based on the >>>> conference service provided, and also between >> public >>>> and private networks. >>>> >>>> As a result, I think I am now confused about what >>>> you actually mean by passive, can you elaborate >>>> further. >>>> >>>> >>>>> >>>>> I agree that whatever we do, we need to describe >>>> the semantics very >>>>> crisply. >>>>> >>>>> thanks, >>>>> -rohan >>>>> >>>>> >>>>> On Tuesday, June 10, 2003, at 04:47 AM, Drage, >>>> Keith (Keith) wrote: >>>>> >>>>>> I fail to see how thw property you are >> proposing >>>> correlates in some >>>>>> way to any concept of hold. I agree that "hold" >>>> has many meanings, >> > === message truncated === > > > __________________________________ > Do you Yahoo!? > Yahoo! Calendar - Free online calendar with sync to Outlook(TM). > http://calendar.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 mailnull@www1.ietf.org Wed Jun 11 21:00:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10895 for ; Wed, 11 Jun 2003 21:00:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5C0xXK22697 for sipping-archive@odin.ietf.org; Wed, 11 Jun 2003 20:59:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C0xXm22694 for ; Wed, 11 Jun 2003 20: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 UAA10873 for ; Wed, 11 Jun 2003 20:59:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QGP7-0005hp-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 20:57:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QGP6-0005hm-00 for sipping-web-archive@ietf.org; Wed, 11 Jun 2003 20:57:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C0uXm22578; Wed, 11 Jun 2003 20:56:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C0tWm22529 for ; Wed, 11 Jun 2003 20:55: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 UAA10809 for ; Wed, 11 Jun 2003 20:55:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QGLE-0005gN-00 for sipping@ietf.org; Wed, 11 Jun 2003 20:53:25 -0400 Received: from halt-in.cisco.com ([171.70.144.185]) by ietf-mx with esmtp (Exim 4.12) id 19QGLE-0005gI-00 for sipping@ietf.org; Wed, 11 Jun 2003 20:53:24 -0400 Received: from cisco.com (171.71.177.223) by halt-in.cisco.com with ESMTP; 11 Jun 2003 17:54:44 -0800 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 RAA21259; Wed, 11 Jun 2003 17:54:58 -0700 (PDT) Message-Id: <4.3.2.7.2.20030611194202.023adf00@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 11 Jun 2003 19:55:04 -0500 To: "Jason Arnold" , "Rohan Mahy" , "Sean Olson" From: "James M. Polk" Subject: RE: [Sipping] proposed enhancement to dialog package Cc: "Drage, Keith \(Keith\)" , "'Jonathan Rosenberg'" , , In-Reply-To: References: <02277DDC-9C36-11D7-861A-0003938AF740@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , At 04:20 PM 6/11/2003 -0700, Jason Arnold wrote: >It is important to supply a media stream (even irritating propaganda) during >the hold session. Is this asking that media be mandatory when a UA is placed on hold? There are many times where there is no propaganda playing while someone is on hold (though I wish was more often the case). Creating a mechanism that must satisfy "media always streaming" will break when there isn't media (which will be during some sessions), especially when media isn't necessary or wanted (for whatever reason). Might I suggest some form of a "hold keep-alive" indicator (periodically) sent to the UA that was put on hold so that UI experience demonstrates this session wasn't disconnected in times that there is no media. >Non-Conformity to current expectations of people while on >hold would seem illogical. > >Thanks, > >Jason 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 mailnull@www1.ietf.org Thu Jun 12 01:48:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15544 for ; Thu, 12 Jun 2003 01:48:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5C5mJ608193 for sipping-archive@odin.ietf.org; Thu, 12 Jun 2003 01:48:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C5mJm08190 for ; Thu, 12 Jun 2003 01: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 BAA15541 for ; Thu, 12 Jun 2003 01:48:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QKuZ-0006kM-00 for sipping-web-archive@ietf.org; Thu, 12 Jun 2003 01:46:11 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QKuZ-0006kJ-00 for sipping-web-archive@ietf.org; Thu, 12 Jun 2003 01:46:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C5kwm08159; Thu, 12 Jun 2003 01:46:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C5jrm08112 for ; Thu, 12 Jun 2003 01: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 BAA15520 for ; Thu, 12 Jun 2003 01:45:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QKsD-0006jy-00 for sipping@ietf.org; Thu, 12 Jun 2003 01:43:45 -0400 Received: from shawidc-mo1.cg.shawcable.net ([24.71.223.10] helo=pd2mo2so.prod.shaw.ca) by ietf-mx with esmtp (Exim 4.12) id 19QKsD-0006jv-00 for sipping@ietf.org; Thu, 12 Jun 2003 01:43:45 -0400 Received: from pd3mr1so.prod.shaw.ca (pd3mr1so-ser.prod.shaw.ca [10.0.141.177]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HGC004J0TAGDG@l-daemon> for sipping@ietf.org; Wed, 11 Jun 2003 23:44:40 -0600 (MDT) Received: from pn2ml2so.prod.shaw.ca (pn2ml2so-qfe0.prod.shaw.ca [10.0.121.146]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HGC00H1FTAGO5@l-daemon> for sipping@ietf.org; Wed, 11 Jun 2003 23:44:40 -0600 (MDT) Received: from me (h24-82-30-144.vw.shawcable.net [24.82.30.144]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HGC00A12TAF8T@l-daemon> for sipping@ietf.org; Wed, 11 Jun 2003 23:44:40 -0600 (MDT) Date: Wed, 11 Jun 2003 22:50:40 -0700 From: Jason Arnold Subject: RE: [Sipping] proposed enhancement to dialog package In-reply-to: <4.3.2.7.2.20030611194202.023adf00@localhost> To: "James M. Polk" , Rohan Mahy , Sean Olson Cc: "Drage, Keith (Keith)" , "'Jonathan Rosenberg'" , alan.johnston@wcom.com, sipping@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) 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 At 04:20 PM 6/11/2003 -0700, Jason Arnold wrote: >It is important to supply a media stream (even irritating propaganda) during >the hold session. Is this asking that media be mandatory when a UA is placed on hold? Might I suggest some form of a "hold keep-alive" indicator (periodically) sent to the UA that was put on hold so that UI experience demonstrates this session wasn't disconnected in times that there is no media. < In some cases of PSTN hold, there are indicators assuring UA of continued call connection. A simple stutter sound (beep, beep) eases a typical user that they are still connected. Jason 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 mailnull@www1.ietf.org Thu Jun 12 05:58: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 FAA02028 for ; Thu, 12 Jun 2003 05:58:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5C9w8X04656 for sipping-archive@odin.ietf.org; Thu, 12 Jun 2003 05:58:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C9w8m04653 for ; Thu, 12 Jun 2003 05: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 FAA02020 for ; Thu, 12 Jun 2003 05:58:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QOoJ-0000RJ-00 for sipping-web-archive@ietf.org; Thu, 12 Jun 2003 05:55:59 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QOoI-0000RG-00 for sipping-web-archive@ietf.org; Thu, 12 Jun 2003 05:55:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C9umm04599; Thu, 12 Jun 2003 05:56:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C9tkm04559 for ; Thu, 12 Jun 2003 05:55: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 FAA02009 for ; Thu, 12 Jun 2003 05:55:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QOm2-0000R4-00 for sipping@ietf.org; Thu, 12 Jun 2003 05:53:38 -0400 Received: from [217.158.120.227] (helo=rnidmail.rnid.org.uk) by ietf-mx with esmtp (Exim 4.12) id 19QOm1-0000R1-00 for sipping@ietf.org; Thu, 12 Jun 2003 05:53:37 -0400 Received: from rnid.org.uk (unverified) by rnidmail.rnid.org.uk (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Thu, 12 Jun 2003 10:53:29 +0100 Received: from RNIDMAIL-Message_Server by rnid.org.uk with Novell_GroupWise; Thu, 12 Jun 2003 10:52:59 +0100 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Thu, 12 Jun 2003 10:52:24 +0100 From: "Guido Gybels" To: , Cc: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5C9tlm04560 Subject: [Sipping] RE: Text support in SIP phones Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Keith and all, <> The point being that one cannot dislodge the terminal considerations from the network ones, neither can you isolate them from the overal user functionality required. The famous discussions on the RTTE directive in groups like TCAM and COCOM surely have proven this point? The ability of terminals, i.e. SIP devices to support carrying or accessing interactive text services therefore has to take that into account. Even if a device does not offer a screen or a full keyboard, it might be hooked up to one. Or might need to relay text. We cannot predict what the future will bring. <> You need to differentiate between assistive devices and end user equipment. While it is certainly necessary to continue to develop assistive devices as alternatives for those users who cannot be catered for otherwise, the main focus should be on inclusive design for mainstream technology. The solution is not to design mainstream technology as minimalist as possible and then having to build assistive technology to support users with different abilities and preferences. So, I think we should state "MUST" and provide a clearly defined exception rule that could cover what you are alluding at. The rule should be to support it and provide exceptions where applicable, not the other way around IMHO. So, to recap, I believe we should state that all devices MUST support interactive texting, EXCEPT for a clearly defined domain of exceptions. <> Which is a reason for having it here as well as in other relevant places. As I said, it is not a problem that is limited to either network or terminal side. It is by definition an overall issue. <> IMO, standards, by default, are being based on voluntary agreement between stakeholders. Even if legislators and regulators can use them as a basis for legislation and regulations. <> Yes, but GTT is not exactly an example of how things should be done. It certainly is very unsuitable for most of Europe as a solution. I don't want this document to make the same mistakes. 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 ************************************************************************ 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 mailnull@www1.ietf.org Thu Jun 12 09:22:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09610 for ; Thu, 12 Jun 2003 09:22:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CDMRP20497 for sipping-archive@odin.ietf.org; Thu, 12 Jun 2003 09:22:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CDMRm20494 for ; Thu, 12 Jun 2003 09:22: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 JAA09601 for ; Thu, 12 Jun 2003 09:22:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QS02-0002Jo-00 for sipping-web-archive@ietf.org; Thu, 12 Jun 2003 09:20:18 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QS02-0002Jl-00 for sipping-web-archive@ietf.org; Thu, 12 Jun 2003 09:20:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CDHcm20183; Thu, 12 Jun 2003 09:17:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CDGDm20058 for ; Thu, 12 Jun 2003 09:16: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 JAA09495 for ; Thu, 12 Jun 2003 09:16:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QRu1-0002IG-00 for sipping@ietf.org; Thu, 12 Jun 2003 09:14:05 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19QRu0-0002I8-00 for sipping@ietf.org; Thu, 12 Jun 2003 09:14:04 -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 JAA13842; Thu, 12 Jun 2003 09:15:39 -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 JAA29590; Thu, 12 Jun 2003 09:15:39 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Jun 2003 09:15:39 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5AD9@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Jason Arnold'" , Rohan Mahy , Sean Olson Cc: "Drage, Keith (Keith)" , "'Jonathan Rosenberg'" , alan.johnston@wcom.com, sipping@ietf.org Subject: RE: [Sipping] proposed enhancement to dialog package Date: Thu, 12 Jun 2003 09:15:30 -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: , May I add some interesting observational data? We now have about a year experience with sip videophones that implement hold. When you are on hold, you see a gray screen that has text indicating the other party put you on hold. We deliver silence on the audio channel. We have lots and lots of feature requests from users. No one has ever asked for audio on hold. The visual information is sufficient. I suspect that you don't need to be entertained, or pitched. You need to know what is happening. If your UA tells you you are on hold, then audio when you are on hold may not be important. One caveat; almost everyone uses our videophone handsfree. If you are holding a handset to your ear, your desire for hold audio may be greater. Brian > -----Original Message----- > From: Jason Arnold [mailto:jason@azatel.com] > Sent: Wednesday, June 11, 2003 7:21 PM > To: Rohan Mahy; Sean Olson > Cc: Drage, Keith (Keith); 'Jonathan Rosenberg'; > alan.johnston@wcom.com; > sipping@ietf.org > Subject: RE: [Sipping] proposed enhancement to dialog package > > > I agree to an extent. > > If the hold presents "dead air", most people will feel lost > with out some > indication that they are on hold. It would seem that people > require the > assurance that the receiving party has not terminated their > call. It could > be assumed that if the hold period is for an extended period > of time, only > presenting silence to the calling party, people may think > they have been > accidentally "disconnected" and terminate their call. > > It is important to supply a media stream (even irritating > propaganda) during > the hold session. Non-Conformity to current expectations of > people while on > hold would seem illogical. > > Thanks, > > Jason > > On Wednesday, June 11, 2003, at 09:40 AM, Sean Olson wrote: > > > This is an interesting discussion in an almost > > academic sense, but it really does not address the > > reality of the very simple service that is being > > described here. > > > > "hold", "passive", whatever else you want to call it > > means not sending/receiving media. > > I disagree. > > If you call someone on the average PBX or Key System, and ask them to > put you on hold, you will typically still receive media > (music, tones, > irritating announcements). Likewise, if you call a call center or a > big store, you are likely to wait "on hold" with some type of > propaganda, music, or recorded message claiming that you are > important. > > Clearly the user experience of the user-visible feature "Hold" is that > hold does not typically equate to "no media". > > I believe that from a feature perspective the existence or presence of > no media being sent/received is irrelevant. It does not affect my > perception that I am on hold, nor does it affect the perception of my > peer if I am on hold or not, since I can receive or not receive media > and still know that I am on hold. > > My assertion is that what users really want to know is if the > other end > is actively participating. Do they care if I am still around? Is > there the potential for interaction between me and my peer? > > With this concept, I can build useful features that users can relate > to. For example, I would like "passive" participants (participants > that cannot interact with me, like inane robots sending me > Musak) to be > automatically muted in my conference. > > I would like to express this property. If the name "passive" is too > confusing, then feel free to suggest other terms. "interactivity" > EQUAL ( "yes" / "no" ) ? > > thanks, > -rohan > > > > We've all > > experienced this. And, yes, this can be independent of > > the ability to do SIP signaling. > > > > I think we are focusing too much on signaling here and > > not enough on the user experience that is being built. > > And I certainly don't want a history lesson in ISDN > > signaling ;-) > > > > > > --- "Drage, Keith (Keith)" wrote: > >> See below > >> > >> regards > >> > >> Keith > >> > >> Keith Drage > >> Lucent Technologies > >> Tel: +44 1793 776249 > >> Email: drage@lucent.com > >> > >>> -----Original Message----- > >>> From: Rohan Mahy [mailto:rohan@cisco.com] > >>> Sent: 10 June 2003 16:25 > >>> To: Drage, Keith (Keith) > >>> Cc: 'Jonathan Rosenberg'; alan.johnston@wcom.com; > >> 'sipping@ietf.org' > >>> Subject: Re: [Sipping] proposed enhancement to > >> dialog package > >>> > >>> > >>> Hi Keith, > >>> > >>> Hold as a UI concept significantly predated the > >> development of ISDN. > >> > >> Agreed, and my initial message identified in that > >> case (analogue PSTN terminals) that Hold was > >> originally to recall the register (and there was a > >> manual board equivalent as well) to allow access > >> resources to be used for signalling, as a result of > >> that signalling, the access resources might be used > >> for communication with another party, and only as a > >> by product of that did it necessarily result in loss > >> of communication path with the other party. > >> > >>> In any case, an ISDN user (Alice) who requests an > >> ISDN hold > >>> is still a > >>> passive participant by my definition. When > >> Alice's call is connected > >>> to a conference server and all the active > >> participants say "ok, we're > >>> leaving now, good bye", Alice is not active enough > >> to be able to hang > >>> up. > >> > >> Assuming your last statement still refers to an ISDN > >> user, then I can think of nothing in the above > >> scenario that prevents Alice sending a DISCONNECT, > >> and receiving a RELEASE back. Can you clarify. The > >> DSS1 basic call state machine is totally independent > >> of any subsidiary state machine relating to > >> hold/retrieve. > >> > >> If you are referring to hanging up the conference > >> bridge resources, then this is dependent on the > >> concept of ownership, which varies based on the > >> conference service provided, and also between public > >> and private networks. > >> > >> As a result, I think I am now confused about what > >> you actually mean by passive, can you elaborate > >> further. > >> > >> > >>> > >>> I agree that whatever we do, we need to describe > >> the semantics very > >>> crisply. > >>> > >>> thanks, > >>> -rohan > >>> > >>> > >>> On Tuesday, June 10, 2003, at 04:47 AM, Drage, > >> Keith (Keith) wrote: > >>> > >>>> I fail to see how thw property you are proposing > >> correlates in some > >>>> way to any concept of hold. I agree that "hold" > >> has many meanings, > >>>> based on which type of signalling you are using. > >>>> > >>>> To clarify, the prime function of hold in the > >> PSTN was never to > >>>> interrupt the communication, that was a side > >> effect of grabbing the > >>>> access resources to signal to another party. > >> Thus for ISDN, hold > >>>> therefore was only a removal of access resources > >> (the > >>> bearer) so that > >>>> that bearer could be reused for another call; > >> again the side effect > >>>> was to interrupt the communication. The sole > >> function of > >>> hold for SIP > >>>> is to interrupt the communication. > >>>> > >>>> Certainly, if an ISDN user places another user > >> on hold, I > >>> would regard > >>>> neither user as "passive" as you seem to be > >> defining here. > >>>> > >>>> If we are going to do this, can we make sure we > >> define the > >>> semantics > >>>> correctly. Otherwise we will surely create > >> confusion, > >>> particularly if > >>>> people try and equate this concept with that of > >> hold, and in > >>>> particular with the PSTN concept. > >>>> > >>>> regards > >>>> > >>>> Keith > >>>> > >>>> > >>>> Keith Drage > >>>> Lucent Technologies > >>>> Tel: +44 1793 776249 > >>>> Email: drage@lucent.com > >>>> > >>>>> -----Original Message----- > >>>>> From: Rohan Mahy [mailto:rohan@cisco.com] > >>>>> Sent: 03 June 2003 22:18 > >>>>> To: 'Jonathan Rosenberg' > >>>>> Cc: rohan@cisco.com; alan.johnston@wcom.com; > >> 'sipping@ietf.org' > >>>>> Subject: [Sipping] proposed enhancement to > >> dialog package > >>>>> > >>>>> > >>>>> Hi, > >>>>> > >>>>> There have been many requests for the dialog > >> package to express the > >>>>> concept of hold. The problem is that nobody had > >> an especially good > >>>>> definition of what "on-hold" meant. Some > >> suggested that all media > >>>>> streams being inactive implied that you are > >> "held", but > >>> this doesn't > >>>>> work for a service such as music-on-hold. > >>>>> > >>>>> I believe that folks actually want a slightly > >> different > >>> concept--that > >>>>> the semantics we want instead are already > >> described in the > >>>>> call control > >>>>> framework: > >>>>> > >>>>>> Participants may also be active or passive. > >> Active > >>> participants are > >>>>>> expected to be intelligent enough to leave a > >> conversation > >>>>> space when > >>>>>> they no longer desire to participate. (An > >> attentive human > >>>>> participant > >>>>>> is obviously active.) Some robotic > >> participants (such as a voice > >>>>>> messaging system, an instant messaging agent, > >> or a voice dialog > >>>>>> system) may be active participants if they can > >> leave the > >>>>> conversation > >>>>>> space when there is no human interaction. > >> Other robots > >>> (for example > >>>>>> our tone generating robot from the previous > >> example) are passive > >>>>>> participants. A human participant "on-hold" is > >> passive. > >>>>> > >>>>> I think we should add a new attribute to the > >> dialog package that > >>>>> expresses this property. My proposal is to > >> express this > >>> property only > >>>>> for the local side of each dialog by adding an > >> attribute > >>> to the state > >>>>> tag in the dialog-info notification body. The > >> example below > >>>>> includes a > >>>>> proposed (optional) participation attribute in > >> the state tag. > >>>>> > >>>>> > >>>>> >> xmlns="urn:ietf:params:xml:ns:dialog-info" > >>>>> version="3" > >>>>> state="partial" > >>>>> entity="sip:caller@bar.com"> > >> > > === message truncated === > > > > > > __________________________________ > > Do you Yahoo!? > > Yahoo! Calendar - Free online calendar with sync to Outlook(TM). > > http://calendar.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 > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jun 12 09:35:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09917 for ; Thu, 12 Jun 2003 09:35:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CDYxJ21115 for sipping-archive@odin.ietf.org; Thu, 12 Jun 2003 09:34:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CDYwm21112 for ; Thu, 12 Jun 2003 09:34: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 JAA09912 for ; Thu, 12 Jun 2003 09:34:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QSCA-0002O7-00 for sipping-web-archive@ietf.org; Thu, 12 Jun 2003 09:32:50 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QSC9-0002O4-00 for sipping-web-archive@ietf.org; Thu, 12 Jun 2003 09:32:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CDXFm21056; Thu, 12 Jun 2003 09:33:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CDWim21011 for ; Thu, 12 Jun 2003 09:32: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 JAA09841; Thu, 12 Jun 2003 09:32:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QS9z-0002N0-00; Thu, 12 Jun 2003 09:30:35 -0400 Received: from [202.62.83.99] (helo=gateway.blr.dlink.com) by ietf-mx with esmtp (Exim 4.12) id 19QS9x-0002Mq-00; Thu, 12 Jun 2003 09:30:34 -0400 Received: from userbvyungtdgz (localhost [127.0.0.1]) by gateway.blr.dlink.com (8.11.0/8.11.0) with SMTP id h5CDeqo23306; Thu, 12 Jun 2003 19:10:52 +0530 Message-ID: <000d01c330e7$7afc9ca0$6064a8c0@userbvyungtdgz> From: "debanjan" To: , Date: Thu, 12 Jun 2003 19:05:25 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C33115.947E1130" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: [Sipping] Message Body format for INFO method carrying DTMF Digits Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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_000A_01C33115.947E1130 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ----------------------------------------- (on the network)---------------- email-body was scanned and no virus found email-body was scanned and no virus found -----------------------------------------D-Link R & D E-Mail Traffic----------- ------=_NextPart_000_000A_01C33115.947E1130 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Anyone has any idea regarding what should be message body of SIP = Info method that carries the DTMF digits. Is there any standard RFC or = draft implementation. Any suggestions are welcome. Regards Debanjan =20 D-Link India Ltd Software and R & D Center ------=_NextPart_000_000A_01C33115.947E1130 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
    Anyone has any idea = regarding=20 what should be message body of SIP Info method that carries the DTMF = digits. Is=20 there any standard RFC or draft implementation.
    Any suggestions are=20 welcome.
 
    Regards
    = Debanjan
   
    D-Link India = Ltd
    Software and R & = D=20 Center
------=_NextPart_000_000A_01C33115.947E1130-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jun 12 10:37:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14013 for ; Thu, 12 Jun 2003 10:37:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CEavq26888 for sipping-archive@odin.ietf.org; Thu, 12 Jun 2003 10:36:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CEavm26885 for ; Thu, 12 Jun 2003 10:36: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 KAA14000 for ; Thu, 12 Jun 2003 10:36:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QTA8-00034s-00 for sipping-web-archive@ietf.org; Thu, 12 Jun 2003 10:34:48 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QTA7-00034p-00 for sipping-web-archive@ietf.org; Thu, 12 Jun 2003 10:34:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CEX7m26713; Thu, 12 Jun 2003 10:33:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CEVNm26640 for ; Thu, 12 Jun 2003 10:31: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 KAA13769 for ; Thu, 12 Jun 2003 10:31:14 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QT4e-00031s-00 for sipping@ietf.org; Thu, 12 Jun 2003 10:29:08 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19QT4a-00031p-00 for sipping@ietf.org; Thu, 12 Jun 2003 10:29:05 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5CEV1913806 for ; Thu, 12 Jun 2003 17:31:01 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 12 Jun 2003 17:31:01 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 12 Jun 2003 17:31:00 +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" Subject: RE: [Sipping] proposed enhancement to dialog package Date: Thu, 12 Jun 2003 17:30:59 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796D97@esebe019.ntc.nokia.com> Thread-Topic: [Sipping] proposed enhancement to dialog package Thread-Index: AcMw5m5SRiTwZRdqTeKrseB2uu2r8gACI19A To: , , , Cc: , , , X-OriginalArrivalTime: 12 Jun 2003 14:31:00.0484 (UTC) FILETIME=[3EC3C440:01C330EF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5CEVPm26642 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Your desire to hold audio may also be greater when you have to pay for audio packets being sent. It might be more interesting for the sender to hold the audio that for the receiver. Hisham > -----Original Message----- > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Thursday, June 12, 2003 4:16 PM > To: 'Jason Arnold'; Rohan Mahy; Sean Olson > Cc: Drage, Keith (Keith); 'Jonathan Rosenberg'; > alan.johnston@wcom.com; > sipping@ietf.org > Subject: RE: [Sipping] proposed enhancement to dialog package > > > May I add some interesting observational data? > We now have about a year experience with sip videophones that > implement hold. When you are on hold, you see a gray screen that > has text indicating the other party put you on hold. We deliver > silence on the audio channel. > > We have lots and lots of feature requests from users. No one has > ever asked for audio on hold. The visual information is sufficient. > > I suspect that you don't need to be entertained, or pitched. You need > to know what is happening. If your UA tells you you are on hold, > then audio when you are on hold may not be important. > > One caveat; almost everyone uses our videophone handsfree. If you are > holding a handset to your ear, your desire for hold audio may be > greater. > > Brian > > > -----Original Message----- > > From: Jason Arnold [mailto:jason@azatel.com] > > Sent: Wednesday, June 11, 2003 7:21 PM > > To: Rohan Mahy; Sean Olson > > Cc: Drage, Keith (Keith); 'Jonathan Rosenberg'; > > alan.johnston@wcom.com; > > sipping@ietf.org > > Subject: RE: [Sipping] proposed enhancement to dialog package > > > > > > I agree to an extent. > > > > If the hold presents "dead air", most people will feel lost > > with out some > > indication that they are on hold. It would seem that people > > require the > > assurance that the receiving party has not terminated their > > call. It could > > be assumed that if the hold period is for an extended period > > of time, only > > presenting silence to the calling party, people may think > > they have been > > accidentally "disconnected" and terminate their call. > > > > It is important to supply a media stream (even irritating > > propaganda) during > > the hold session. Non-Conformity to current expectations of > > people while on > > hold would seem illogical. > > > > Thanks, > > > > Jason > > > > On Wednesday, June 11, 2003, at 09:40 AM, Sean Olson wrote: > > > > > This is an interesting discussion in an almost > > > academic sense, but it really does not address the > > > reality of the very simple service that is being > > > described here. > > > > > > "hold", "passive", whatever else you want to call it > > > means not sending/receiving media. > > > > I disagree. > > > > If you call someone on the average PBX or Key System, and > ask them to > > put you on hold, you will typically still receive media > > (music, tones, > > irritating announcements). Likewise, if you call a call center or a > > big store, you are likely to wait "on hold" with some type of > > propaganda, music, or recorded message claiming that you are > > important. > > > > Clearly the user experience of the user-visible feature > "Hold" is that > > hold does not typically equate to "no media". > > > > I believe that from a feature perspective the existence or > presence of > > no media being sent/received is irrelevant. It does not affect my > > perception that I am on hold, nor does it affect the > perception of my > > peer if I am on hold or not, since I can receive or not > receive media > > and still know that I am on hold. > > > > My assertion is that what users really want to know is if the > > other end > > is actively participating. Do they care if I am still around? Is > > there the potential for interaction between me and my peer? > > > > With this concept, I can build useful features that users can relate > > to. For example, I would like "passive" participants (participants > > that cannot interact with me, like inane robots sending me > > Musak) to be > > automatically muted in my conference. > > > > I would like to express this property. If the name "passive" is too > > confusing, then feel free to suggest other terms. "interactivity" > > EQUAL ( "yes" / "no" ) ? > > > > thanks, > > -rohan > > > > > > > We've all > > > experienced this. And, yes, this can be independent of > > > the ability to do SIP signaling. > > > > > > I think we are focusing too much on signaling here and > > > not enough on the user experience that is being built. > > > And I certainly don't want a history lesson in ISDN > > > signaling ;-) > > > > > > > > > --- "Drage, Keith (Keith)" wrote: > > >> See below > > >> > > >> regards > > >> > > >> Keith > > >> > > >> Keith Drage > > >> Lucent Technologies > > >> Tel: +44 1793 776249 > > >> Email: drage@lucent.com > > >> > > >>> -----Original Message----- > > >>> From: Rohan Mahy [mailto:rohan@cisco.com] > > >>> Sent: 10 June 2003 16:25 > > >>> To: Drage, Keith (Keith) > > >>> Cc: 'Jonathan Rosenberg'; alan.johnston@wcom.com; > > >> 'sipping@ietf.org' > > >>> Subject: Re: [Sipping] proposed enhancement to > > >> dialog package > > >>> > > >>> > > >>> Hi Keith, > > >>> > > >>> Hold as a UI concept significantly predated the > > >> development of ISDN. > > >> > > >> Agreed, and my initial message identified in that > > >> case (analogue PSTN terminals) that Hold was > > >> originally to recall the register (and there was a > > >> manual board equivalent as well) to allow access > > >> resources to be used for signalling, as a result of > > >> that signalling, the access resources might be used > > >> for communication with another party, and only as a > > >> by product of that did it necessarily result in loss > > >> of communication path with the other party. > > >> > > >>> In any case, an ISDN user (Alice) who requests an > > >> ISDN hold > > >>> is still a > > >>> passive participant by my definition. When > > >> Alice's call is connected > > >>> to a conference server and all the active > > >> participants say "ok, we're > > >>> leaving now, good bye", Alice is not active enough > > >> to be able to hang > > >>> up. > > >> > > >> Assuming your last statement still refers to an ISDN > > >> user, then I can think of nothing in the above > > >> scenario that prevents Alice sending a DISCONNECT, > > >> and receiving a RELEASE back. Can you clarify. The > > >> DSS1 basic call state machine is totally independent > > >> of any subsidiary state machine relating to > > >> hold/retrieve. > > >> > > >> If you are referring to hanging up the conference > > >> bridge resources, then this is dependent on the > > >> concept of ownership, which varies based on the > > >> conference service provided, and also between public > > >> and private networks. > > >> > > >> As a result, I think I am now confused about what > > >> you actually mean by passive, can you elaborate > > >> further. > > >> > > >> > > >>> > > >>> I agree that whatever we do, we need to describe > > >> the semantics very > > >>> crisply. > > >>> > > >>> thanks, > > >>> -rohan > > >>> > > >>> > > >>> On Tuesday, June 10, 2003, at 04:47 AM, Drage, > > >> Keith (Keith) wrote: > > >>> > > >>>> I fail to see how thw property you are proposing > > >> correlates in some > > >>>> way to any concept of hold. I agree that "hold" > > >> has many meanings, > > >>>> based on which type of signalling you are using. > > >>>> > > >>>> To clarify, the prime function of hold in the > > >> PSTN was never to > > >>>> interrupt the communication, that was a side > > >> effect of grabbing the > > >>>> access resources to signal to another party. > > >> Thus for ISDN, hold > > >>>> therefore was only a removal of access resources > > >> (the > > >>> bearer) so that > > >>>> that bearer could be reused for another call; > > >> again the side effect > > >>>> was to interrupt the communication. The sole > > >> function of > > >>> hold for SIP > > >>>> is to interrupt the communication. > > >>>> > > >>>> Certainly, if an ISDN user places another user > > >> on hold, I > > >>> would regard > > >>>> neither user as "passive" as you seem to be > > >> defining here. > > >>>> > > >>>> If we are going to do this, can we make sure we > > >> define the > > >>> semantics > > >>>> correctly. Otherwise we will surely create > > >> confusion, > > >>> particularly if > > >>>> people try and equate this concept with that of > > >> hold, and in > > >>>> particular with the PSTN concept. > > >>>> > > >>>> regards > > >>>> > > >>>> Keith > > >>>> > > >>>> > > >>>> Keith Drage > > >>>> Lucent Technologies > > >>>> Tel: +44 1793 776249 > > >>>> Email: drage@lucent.com > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: Rohan Mahy [mailto:rohan@cisco.com] > > >>>>> Sent: 03 June 2003 22:18 > > >>>>> To: 'Jonathan Rosenberg' > > >>>>> Cc: rohan@cisco.com; alan.johnston@wcom.com; > > >> 'sipping@ietf.org' > > >>>>> Subject: [Sipping] proposed enhancement to > > >> dialog package > > >>>>> > > >>>>> > > >>>>> Hi, > > >>>>> > > >>>>> There have been many requests for the dialog > > >> package to express the > > >>>>> concept of hold. The problem is that nobody had > > >> an especially good > > >>>>> definition of what "on-hold" meant. Some > > >> suggested that all media > > >>>>> streams being inactive implied that you are > > >> "held", but > > >>> this doesn't > > >>>>> work for a service such as music-on-hold. > > >>>>> > > >>>>> I believe that folks actually want a slightly > > >> different > > >>> concept--that > > >>>>> the semantics we want instead are already > > >> described in the > > >>>>> call control > > >>>>> framework: > > >>>>> > > >>>>>> Participants may also be active or passive. > > >> Active > > >>> participants are > > >>>>>> expected to be intelligent enough to leave a > > >> conversation > > >>>>> space when > > >>>>>> they no longer desire to participate. (An > > >> attentive human > > >>>>> participant > > >>>>>> is obviously active.) Some robotic > > >> participants (such as a voice > > >>>>>> messaging system, an instant messaging agent, > > >> or a voice dialog > > >>>>>> system) may be active participants if they can > > >> leave the > > >>>>> conversation > > >>>>>> space when there is no human interaction. > > >> Other robots > > >>> (for example > > >>>>>> our tone generating robot from the previous > > >> example) are passive > > >>>>>> participants. A human participant "on-hold" is > > >> passive. > > >>>>> > > >>>>> I think we should add a new attribute to the > > >> dialog package that > > >>>>> expresses this property. My proposal is to > > >> express this > > >>> property only > > >>>>> for the local side of each dialog by adding an > > >> attribute > > >>> to the state > > >>>>> tag in the dialog-info notification body. The > > >> example below > > >>>>> includes a > > >>>>> proposed (optional) participation attribute in > > >> the state tag. > > >>>>> > > >>>>> > > >>>>> > >> xmlns="urn:ietf:params:xml:ns:dialog-info" > > >>>>> version="3" > > >>>>> state="partial" > > >>>>> entity="sip:caller@bar.com"> > > >> > > > === message truncated === > > > > > > > > > __________________________________ > > > Do you Yahoo!? > > > Yahoo! Calendar - Free online calendar with sync to Outlook(TM). > > > http://calendar.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 > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jun 12 10:56:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14411 for ; Thu, 12 Jun 2003 10:56:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CEtaa28971 for sipping-archive@odin.ietf.org; Thu, 12 Jun 2003 10:55:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CEtam28968 for ; Thu, 12 Jun 2003 10:55: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 KAA14400 for ; Thu, 12 Jun 2003 10:55:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QTS6-0003Be-00 for sipping-web-archive@ietf.org; Thu, 12 Jun 2003 10:53:22 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QTS6-0003Bb-00 for sipping-web-archive@ietf.org; Thu, 12 Jun 2003 10:53:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CErgm28838; Thu, 12 Jun 2003 10:53:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CElgm28269 for ; Thu, 12 Jun 2003 10:47: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 KAA14231 for ; Thu, 12 Jun 2003 10:47:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QTKX-00038S-00 for sipping@ietf.org; Thu, 12 Jun 2003 10:45:33 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19QTKW-000385-00 for sipping@ietf.org; Thu, 12 Jun 2003 10:45:32 -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 h5CEkxwc018616; Thu, 12 Jun 2003 07:46:59 -0700 (PDT) Received: from mhammer-w2k02.cisco.com (dhcp-hrn-64-100-229-133.cisco.com [64.100.229.133]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ADP76572; Thu, 12 Jun 2003 07:46:58 -0700 (PDT) Message-Id: <4.3.2.7.2.20030612103722.00b36aa8@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 12 Jun 2003 10:46:57 -0400 To: Sean Olson From: Michael Hammer Subject: RE: [Sipping] proposed enhancement to dialog package Cc: "Drage, Keith \(Keith\)" , "'Rohan Mahy'" , "'Jonathan Rosenberg'" , alan.johnston@wcom.com, "'sipping@ietf.org'" In-Reply-To: <20030611164040.4097.qmail@web41507.mail.yahoo.com> References: <475FF955A05DD411980D00508B6D5FB00439ED5C@en0033exch001u.uk.lucent.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_3001135==_.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: , --=====================_3001135==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Sean, At 09:40 AM 6/11/2003 -0700, Sean Olson wrote: >This is an interesting discussion in an almost >academic sense, but it really does not address the >reality of the very simple service that is being >described here. > >"hold", "passive", whatever else you want to call it >means not sending/receiving media. You mean that the active call/conference is not sending/receiving media to the party on hold, not that the held party was not receiving media. I don't understand the need for the term such as "passive". What is wrong with the term "hold"? If I am listening to a call, but not saying anything, I would consider myself passive. So can I conclude that you are after something that is not on hold, but not entirely responsive to the call? So what is the characteristic you are looking for? Ability to respond to signaling? It would appear that both parties on hold and automata could respond to such requests, i.e. a BYE. Ability to respond to media? I suppose this means a Turing machine equivalent. That could mean both human listeners and perhaps IVR systems. (Not looking for fool-proof human equivalent.) So, are you looking for a term that describes a party that is connected to the call, receiving media, but won't react to it? I think I'm missing the driving motivation here, but the above is what I am gleaning from the conversation thus far. Mike >We've all >experienced this. And, yes, this can be independent of >the ability to do SIP signaling. > >I think we are focusing too much on signaling here and >not enough on the user experience that is being built. >And I certainly don't want a history lesson in ISDN >signaling ;-) > > >--- "Drage, Keith (Keith)" wrote: > > See below > > > > regards > > > > Keith > > > > Keith Drage > > Lucent Technologies > > Tel: +44 1793 776249 > > Email: drage@lucent.com > > > > > -----Original Message----- > > > From: Rohan Mahy [mailto:rohan@cisco.com] > > > Sent: 10 June 2003 16:25 > > > To: Drage, Keith (Keith) > > > Cc: 'Jonathan Rosenberg'; alan.johnston@wcom.com; > > 'sipping@ietf.org' > > > Subject: Re: [Sipping] proposed enhancement to > > dialog package > > > > > > > > > Hi Keith, > > > > > > Hold as a UI concept significantly predated the > > development of ISDN. > > > > Agreed, and my initial message identified in that > > case (analogue PSTN terminals) that Hold was > > originally to recall the register (and there was a > > manual board equivalent as well) to allow access > > resources to be used for signalling, as a result of > > that signalling, the access resources might be used > > for communication with another party, and only as a > > by product of that did it necessarily result in loss > > of communication path with the other party. > > > > > In any case, an ISDN user (Alice) who requests an > > ISDN hold > > > is still a > > > passive participant by my definition. When > > Alice's call is connected > > > to a conference server and all the active > > participants say "ok, we're > > > leaving now, good bye", Alice is not active enough > > to be able to hang > > > up. > > > > Assuming your last statement still refers to an ISDN > > user, then I can think of nothing in the above > > scenario that prevents Alice sending a DISCONNECT, > > and receiving a RELEASE back. Can you clarify. The > > DSS1 basic call state machine is totally independent > > of any subsidiary state machine relating to > > hold/retrieve. > > > > If you are referring to hanging up the conference > > bridge resources, then this is dependent on the > > concept of ownership, which varies based on the > > conference service provided, and also between public > > and private networks. > > > > As a result, I think I am now confused about what > > you actually mean by passive, can you elaborate > > further. > > > > > > > > > > I agree that whatever we do, we need to describe > > the semantics very > > > crisply. > > > > > > thanks, > > > -rohan > > > > > > > > > On Tuesday, June 10, 2003, at 04:47 AM, Drage, > > Keith (Keith) wrote: > > > > > > > I fail to see how thw property you are proposing > > correlates in some > > > > way to any concept of hold. I agree that "hold" > > has many meanings, > > > > based on which type of signalling you are using. > > > > > > > > To clarify, the prime function of hold in the > > PSTN was never to > > > > interrupt the communication, that was a side > > effect of grabbing the > > > > access resources to signal to another party. > > Thus for ISDN, hold > > > > therefore was only a removal of access resources > > (the > > > bearer) so that > > > > that bearer could be reused for another call; > > again the side effect > > > > was to interrupt the communication. The sole > > function of > > > hold for SIP > > > > is to interrupt the communication. > > > > > > > > Certainly, if an ISDN user places another user > > on hold, I > > > would regard > > > > neither user as "passive" as you seem to be > > defining here. > > > > > > > > If we are going to do this, can we make sure we > > define the > > > semantics > > > > correctly. Otherwise we will surely create > > confusion, > > > particularly if > > > > people try and equate this concept with that of > > hold, and in > > > > particular with the PSTN concept. > > > > > > > > regards > > > > > > > > Keith > > > > > > > > > > > > Keith Drage > > > > Lucent Technologies > > > > Tel: +44 1793 776249 > > > > Email: drage@lucent.com > > > > > > > >> -----Original Message----- > > > >> From: Rohan Mahy [mailto:rohan@cisco.com] > > > >> Sent: 03 June 2003 22:18 > > > >> To: 'Jonathan Rosenberg' > > > >> Cc: rohan@cisco.com; alan.johnston@wcom.com; > > 'sipping@ietf.org' > > > >> Subject: [Sipping] proposed enhancement to > > dialog package > > > >> > > > >> > > > >> Hi, > > > >> > > > >> There have been many requests for the dialog > > package to express the > > > >> concept of hold. The problem is that nobody had > > an especially good > > > >> definition of what "on-hold" meant. Some > > suggested that all media > > > >> streams being inactive implied that you are > > "held", but > > > this doesn't > > > >> work for a service such as music-on-hold. > > > >> > > > >> I believe that folks actually want a slightly > > different > > > concept--that > > > >> the semantics we want instead are already > > described in the > > > >> call control > > > >> framework: > > > >> > > > >>> Participants may also be active or passive. > > Active > > > participants are > > > >>> expected to be intelligent enough to leave a > > conversation > > > >> space when > > > >>> they no longer desire to participate. (An > > attentive human > > > >> participant > > > >>> is obviously active.) Some robotic > > participants (such as a voice > > > >>> messaging system, an instant messaging agent, > > or a voice dialog > > > >>> system) may be active participants if they can > > leave the > > > >> conversation > > > >>> space when there is no human interaction. > > Other robots > > > (for example > > > >>> our tone generating robot from the previous > > example) are passive > > > >>> participants. A human participant "on-hold" is > > passive. > > > >> > > > >> I think we should add a new attribute to the > > dialog package that > > > >> expresses this property. My proposal is to > > express this > > > property only > > > >> for the local side of each dialog by adding an > > attribute > > > to the state > > > >> tag in the dialog-info notification body. The > > example below > > > >> includes a > > > >> proposed (optional) participation attribute in > > the state tag. > > > >> > > > >> > > > >> > xmlns="urn:ietf:params:xml:ns:dialog-info" > > > >> version="3" > > > >> state="partial" > > > >> entity="sip:caller@bar.com"> > > >=== message truncated === > > >__________________________________ >Do you Yahoo!? >Yahoo! Calendar - Free online calendar with sync to Outlook(TM). >http://calendar.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 --=====================_3001135==_.ALT Content-Type: text/html; charset="us-ascii" Sean,

At 09:40 AM 6/11/2003 -0700, Sean Olson wrote:
This is an interesting discussion in an almost
academic sense, but it really does not address the
reality of the very simple service that is being
described here.

"hold", "passive", whatever else you want to call it
means not sending/receiving media.

You mean that the active call/conference is not sending/receiving media to the party on hold, not that the held party was not receiving media.

I don't understand the need for the term such as "passive".  What is wrong with the term "hold"?  If I am listening to a call, but not saying anything, I would consider myself passive.  So can I conclude that you are after something that is not on hold, but not entirely responsive to the call?

So what is the characteristic you are looking for?

Ability to respond to signaling?  It would appear that both parties on hold and automata could respond to such requests, i.e. a BYE.

Ability to respond to media?  I suppose this means a Turing machine equivalent.  That could mean both human listeners and perhaps IVR systems.  (Not looking for fool-proof human equivalent.)

So, are you looking for a term that describes a party that is connected to the call, receiving media, but won't react to it?

I think I'm missing the driving motivation here, but the above is what I am gleaning from the conversation thus far.

Mike


We've all
experienced this. And, yes, this can be independent of
the ability to do SIP signaling.

I think we are focusing too much on signaling here and
not enough on the user experience that is being built.
And I certainly don't want a history lesson in ISDN
signaling ;-)


--- "Drage, Keith (Keith)" <drage@lucent.com> wrote:
> See below
>
> regards
>
> Keith
>
> Keith Drage
> Lucent Technologies
> Tel: +44 1793 776249
> Email: drage@lucent.com
>
> > -----Original Message-----
> > From: Rohan Mahy [mailto:rohan@cisco.com]
> > Sent: 10 June 2003 16:25
> > To: Drage, Keith (Keith)
> > Cc: 'Jonathan Rosenberg'; alan.johnston@wcom.com;
> 'sipping@ietf.org'
> > Subject: Re: [Sipping] proposed enhancement to
> dialog package
> >
> >
> > Hi Keith,
> >
> > Hold as a UI concept significantly predated the
> development of ISDN.
>
> Agreed, and my initial message identified in that
> case (analogue PSTN terminals) that Hold was
> originally to recall the register (and there was a
> manual board equivalent as well) to allow access
> resources to be used for signalling, as a result of
> that signalling, the access resources might be used
> for communication with another party, and only as a
> by product of that did it necessarily result in loss
> of communication path with the other party.
> 
> > In any case, an ISDN user (Alice) who requests an
> ISDN hold
> > is still a
> > passive participant by my definition.  When
> Alice's call is connected
> > to a conference server and all the active
> participants say "ok, we're
> > leaving now, good bye", Alice is not active enough
> to be able to hang
> > up.
>
> Assuming your last statement still refers to an ISDN
> user, then I can think of nothing in the above
> scenario that prevents Alice sending a DISCONNECT,
> and receiving a RELEASE back. Can you clarify. The
> DSS1 basic call state machine is totally independent
> of any subsidiary state machine relating to
> hold/retrieve.
>
> If you are referring to hanging up the conference
> bridge resources, then this is dependent on the
> concept of ownership, which varies based on the
> conference service provided, and also between public
> and private networks.
>
> As a result, I think I am now confused about what
> you actually mean by passive, can you elaborate
> further.
>
>
> >
> > I agree that whatever we do, we need to describe
> the semantics very
> > crisply.
> >
> > thanks,
> > -rohan
> >
> >
> > On Tuesday, June 10, 2003, at 04:47 AM, Drage,
> Keith (Keith) wrote:
> >
> > > I fail to see how thw property you are proposing
> correlates in some
> > > way to any concept of hold. I agree that "hold"
> has many meanings,
> > > based on which type of signalling you are using.
> > >
> > > To clarify, the prime function of hold in the
> PSTN was never to
> > > interrupt the communication, that was a side
> effect of grabbing the
> > > access resources to signal to another party.
> Thus for ISDN, hold
> > > therefore was only a removal of access resources
> (the
> > bearer) so that
> > > that bearer could be reused for another call;
> again the side effect
> > > was to interrupt the communication. The sole
> function of
> > hold for SIP
> > > is to interrupt the communication.
> > >
> > > Certainly, if an ISDN user places another user
> on hold, I
> > would regard
> > > neither user as "passive" as you seem to be
> defining here.
> > >
> > > If we are going to do this, can we make sure we
> define the
> > semantics
> > > correctly. Otherwise we will surely create
> confusion,
> > particularly if
> > > people try and equate this concept with that of
> hold, and in
> > > particular with the PSTN concept.
> > >
> > > regards
> > >
> > > Keith
> > >
> > >
> > > Keith Drage
> > > Lucent Technologies
> > > Tel: +44 1793 776249
> > > Email: drage@lucent.com
> > >
> > >> -----Original Message-----
> > >> From: Rohan Mahy [mailto:rohan@cisco.com]
> > >> Sent: 03 June 2003 22:18
> > >> To: 'Jonathan Rosenberg'
> > >> Cc: rohan@cisco.com; alan.johnston@wcom.com;
> 'sipping@ietf.org'
> > >> Subject: [Sipping] proposed enhancement to
> dialog package
> > >>
> > >>
> > >> Hi,
> > >>
> > >> There have been many requests for the dialog
> package to express the
> > >> concept of hold. The problem is that nobody had
> an especially good
> > >> definition of what "on-hold" meant.  Some
> suggested that all media
> > >> streams being inactive implied that you are
> "held", but
> > this doesn't
> > >> work for a service such as music-on-hold.
> > >>
> > >> I believe that folks actually want a slightly
> different
> > concept--that
> > >> the semantics we want instead are already
> described in the
> > >> call control
> > >> framework:
> > >>
> > >>> Participants may also be active or passive.
> Active
> > participants are
> > >>> expected to be intelligent enough to leave a
> conversation
> > >> space when
> > >>> they no longer desire to participate. (An
> attentive human
> > >> participant
> > >>> is obviously active.) Some robotic
> participants (such as a voice
> > >>> messaging system, an instant messaging agent,
> or a voice dialog
> > >>> system) may be active participants if they can
> leave the
> > >> conversation
> > >>> space when there is no human interaction.
> Other robots
> > (for example
> > >>> our tone generating robot from the previous
> example) are passive
> > >>> participants. A human participant "on-hold" is
> passive.
> > >>
> > >> I think we should add a new attribute to the
> dialog package that
> > >> expresses this property. My proposal is to
> express this
> > property only
> > >> for the local side of each dialog by adding an
> attribute
> > to the state
> > >> tag in the dialog-info notification body.  The
> example below
> > >> includes a
> > >> proposed (optional) participation attribute in
> the state tag.
> > >>
> > >>     <?xml version="1.0"?>
> > >>     <dialog-info
> xmlns="urn:ietf:params:xml:ns:dialog-info"
> > >>                  version="3"
> > >>                  state="partial"
> > >>                  entity="sip:caller@bar.com">
>
=== message truncated ===


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.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
--=====================_3001135==_.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 mailnull@www1.ietf.org Thu Jun 12 11:10:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15155 for ; Thu, 12 Jun 2003 11:10:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CFADl30858 for sipping-archive@odin.ietf.org; Thu, 12 Jun 2003 11:10:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CFADm30855 for ; Thu, 12 Jun 2003 11:10: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 LAA15136 for ; Thu, 12 Jun 2003 11:10:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QTgJ-0003KJ-00 for sipping-web-archive@ietf.org; Thu, 12 Jun 2003 11:08:03 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QTgI-0003KG-00 for sipping-web-archive@ietf.org; Thu, 12 Jun 2003 11:08:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CF8Nm30688; Thu, 12 Jun 2003 11:08:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CF5qm29636 for ; Thu, 12 Jun 2003 11:05: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 LAA14907 for ; Thu, 12 Jun 2003 11:05:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QTc6-0003I5-00 for sipping@ietf.org; Thu, 12 Jun 2003 11:03:42 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19QTc5-0003HS-00 for sipping@ietf.org; Thu, 12 Jun 2003 11:03:41 -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 LAA18634; Thu, 12 Jun 2003 11:05:11 -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 LAA18927; Thu, 12 Jun 2003 11:05:11 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Jun 2003 11:05:11 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5ADB@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'hisham.khartabil@nokia.com'" , jason@azatel.com, rohan@cisco.com, seancolson@yahoo.com Cc: drage@lucent.com, jdrosen@dynamicsoft.com, alan.johnston@wcom.com, sipping@ietf.org Subject: RE: [Sipping] proposed enhancement to dialog package Date: Thu, 12 Jun 2003 11:05:01 -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've always thought that "music on hold" should be local i.e. my choice of music for me to listen to, not your choice of music for me to hear. Eliminates promotional material also :) Brian > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Thursday, June 12, 2003 10:31 AM > To: Brian.Rosen@marconi.com; jason@azatel.com; rohan@cisco.com; > seancolson@yahoo.com > Cc: drage@lucent.com; jdrosen@dynamicsoft.com; alan.johnston@wcom.com; > sipping@ietf.org > Subject: RE: [Sipping] proposed enhancement to dialog package > > > Your desire to hold audio may also be greater when you have > to pay for audio packets being sent. It might be more > interesting for the sender to hold the audio that for the receiver. > > Hisham > > > -----Original Message----- > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Thursday, June 12, 2003 4:16 PM > > To: 'Jason Arnold'; Rohan Mahy; Sean Olson > > Cc: Drage, Keith (Keith); 'Jonathan Rosenberg'; > > alan.johnston@wcom.com; > > sipping@ietf.org > > Subject: RE: [Sipping] proposed enhancement to dialog package > > > > > > May I add some interesting observational data? > > We now have about a year experience with sip videophones that > > implement hold. When you are on hold, you see a gray screen that > > has text indicating the other party put you on hold. We deliver > > silence on the audio channel. > > > > We have lots and lots of feature requests from users. No one has > > ever asked for audio on hold. The visual information is sufficient. > > > > I suspect that you don't need to be entertained, or > pitched. You need > > to know what is happening. If your UA tells you you are on hold, > > then audio when you are on hold may not be important. > > > > One caveat; almost everyone uses our videophone handsfree. > If you are > > holding a handset to your ear, your desire for hold audio may be > > greater. > > > > Brian > > > > > -----Original Message----- > > > From: Jason Arnold [mailto:jason@azatel.com] > > > Sent: Wednesday, June 11, 2003 7:21 PM > > > To: Rohan Mahy; Sean Olson > > > Cc: Drage, Keith (Keith); 'Jonathan Rosenberg'; > > > alan.johnston@wcom.com; > > > sipping@ietf.org > > > Subject: RE: [Sipping] proposed enhancement to dialog package > > > > > > > > > I agree to an extent. > > > > > > If the hold presents "dead air", most people will feel lost > > > with out some > > > indication that they are on hold. It would seem that people > > > require the > > > assurance that the receiving party has not terminated their > > > call. It could > > > be assumed that if the hold period is for an extended period > > > of time, only > > > presenting silence to the calling party, people may think > > > they have been > > > accidentally "disconnected" and terminate their call. > > > > > > It is important to supply a media stream (even irritating > > > propaganda) during > > > the hold session. Non-Conformity to current expectations of > > > people while on > > > hold would seem illogical. > > > > > > Thanks, > > > > > > Jason > > > > > > On Wednesday, June 11, 2003, at 09:40 AM, Sean Olson wrote: > > > > > > > This is an interesting discussion in an almost > > > > academic sense, but it really does not address the > > > > reality of the very simple service that is being > > > > described here. > > > > > > > > "hold", "passive", whatever else you want to call it > > > > means not sending/receiving media. > > > > > > I disagree. > > > > > > If you call someone on the average PBX or Key System, and > > ask them to > > > put you on hold, you will typically still receive media > > > (music, tones, > > > irritating announcements). Likewise, if you call a call > center or a > > > big store, you are likely to wait "on hold" with some type of > > > propaganda, music, or recorded message claiming that you are > > > important. > > > > > > Clearly the user experience of the user-visible feature > > "Hold" is that > > > hold does not typically equate to "no media". > > > > > > I believe that from a feature perspective the existence or > > presence of > > > no media being sent/received is irrelevant. It does not affect my > > > perception that I am on hold, nor does it affect the > > perception of my > > > peer if I am on hold or not, since I can receive or not > > receive media > > > and still know that I am on hold. > > > > > > My assertion is that what users really want to know is if the > > > other end > > > is actively participating. Do they care if I am still around? Is > > > there the potential for interaction between me and my peer? > > > > > > With this concept, I can build useful features that users > can relate > > > to. For example, I would like "passive" participants > (participants > > > that cannot interact with me, like inane robots sending me > > > Musak) to be > > > automatically muted in my conference. > > > > > > I would like to express this property. If the name > "passive" is too > > > confusing, then feel free to suggest other terms. > "interactivity" > > > EQUAL ( "yes" / "no" ) ? > > > > > > thanks, > > > -rohan > > > > > > > > > > We've all > > > > experienced this. And, yes, this can be independent of > > > > the ability to do SIP signaling. > > > > > > > > I think we are focusing too much on signaling here and > > > > not enough on the user experience that is being built. > > > > And I certainly don't want a history lesson in ISDN > > > > signaling ;-) > > > > > > > > > > > > --- "Drage, Keith (Keith)" wrote: > > > >> See below > > > >> > > > >> regards > > > >> > > > >> Keith > > > >> > > > >> Keith Drage > > > >> Lucent Technologies > > > >> Tel: +44 1793 776249 > > > >> Email: drage@lucent.com > > > >> > > > >>> -----Original Message----- > > > >>> From: Rohan Mahy [mailto:rohan@cisco.com] > > > >>> Sent: 10 June 2003 16:25 > > > >>> To: Drage, Keith (Keith) > > > >>> Cc: 'Jonathan Rosenberg'; alan.johnston@wcom.com; > > > >> 'sipping@ietf.org' > > > >>> Subject: Re: [Sipping] proposed enhancement to > > > >> dialog package > > > >>> > > > >>> > > > >>> Hi Keith, > > > >>> > > > >>> Hold as a UI concept significantly predated the > > > >> development of ISDN. > > > >> > > > >> Agreed, and my initial message identified in that > > > >> case (analogue PSTN terminals) that Hold was > > > >> originally to recall the register (and there was a > > > >> manual board equivalent as well) to allow access > > > >> resources to be used for signalling, as a result of > > > >> that signalling, the access resources might be used > > > >> for communication with another party, and only as a > > > >> by product of that did it necessarily result in loss > > > >> of communication path with the other party. > > > >> > > > >>> In any case, an ISDN user (Alice) who requests an > > > >> ISDN hold > > > >>> is still a > > > >>> passive participant by my definition. When > > > >> Alice's call is connected > > > >>> to a conference server and all the active > > > >> participants say "ok, we're > > > >>> leaving now, good bye", Alice is not active enough > > > >> to be able to hang > > > >>> up. > > > >> > > > >> Assuming your last statement still refers to an ISDN > > > >> user, then I can think of nothing in the above > > > >> scenario that prevents Alice sending a DISCONNECT, > > > >> and receiving a RELEASE back. Can you clarify. The > > > >> DSS1 basic call state machine is totally independent > > > >> of any subsidiary state machine relating to > > > >> hold/retrieve. > > > >> > > > >> If you are referring to hanging up the conference > > > >> bridge resources, then this is dependent on the > > > >> concept of ownership, which varies based on the > > > >> conference service provided, and also between public > > > >> and private networks. > > > >> > > > >> As a result, I think I am now confused about what > > > >> you actually mean by passive, can you elaborate > > > >> further. > > > >> > > > >> > > > >>> > > > >>> I agree that whatever we do, we need to describe > > > >> the semantics very > > > >>> crisply. > > > >>> > > > >>> thanks, > > > >>> -rohan > > > >>> > > > >>> > > > >>> On Tuesday, June 10, 2003, at 04:47 AM, Drage, > > > >> Keith (Keith) wrote: > > > >>> > > > >>>> I fail to see how thw property you are proposing > > > >> correlates in some > > > >>>> way to any concept of hold. I agree that "hold" > > > >> has many meanings, > > > >>>> based on which type of signalling you are using. > > > >>>> > > > >>>> To clarify, the prime function of hold in the > > > >> PSTN was never to > > > >>>> interrupt the communication, that was a side > > > >> effect of grabbing the > > > >>>> access resources to signal to another party. > > > >> Thus for ISDN, hold > > > >>>> therefore was only a removal of access resources > > > >> (the > > > >>> bearer) so that > > > >>>> that bearer could be reused for another call; > > > >> again the side effect > > > >>>> was to interrupt the communication. The sole > > > >> function of > > > >>> hold for SIP > > > >>>> is to interrupt the communication. > > > >>>> > > > >>>> Certainly, if an ISDN user places another user > > > >> on hold, I > > > >>> would regard > > > >>>> neither user as "passive" as you seem to be > > > >> defining here. > > > >>>> > > > >>>> If we are going to do this, can we make sure we > > > >> define the > > > >>> semantics > > > >>>> correctly. Otherwise we will surely create > > > >> confusion, > > > >>> particularly if > > > >>>> people try and equate this concept with that of > > > >> hold, and in > > > >>>> particular with the PSTN concept. > > > >>>> > > > >>>> regards > > > >>>> > > > >>>> Keith > > > >>>> > > > >>>> > > > >>>> Keith Drage > > > >>>> Lucent Technologies > > > >>>> Tel: +44 1793 776249 > > > >>>> Email: drage@lucent.com > > > >>>> > > > >>>>> -----Original Message----- > > > >>>>> From: Rohan Mahy [mailto:rohan@cisco.com] > > > >>>>> Sent: 03 June 2003 22:18 > > > >>>>> To: 'Jonathan Rosenberg' > > > >>>>> Cc: rohan@cisco.com; alan.johnston@wcom.com; > > > >> 'sipping@ietf.org' > > > >>>>> Subject: [Sipping] proposed enhancement to > > > >> dialog package > > > >>>>> > > > >>>>> > > > >>>>> Hi, > > > >>>>> > > > >>>>> There have been many requests for the dialog > > > >> package to express the > > > >>>>> concept of hold. The problem is that nobody had > > > >> an especially good > > > >>>>> definition of what "on-hold" meant. Some > > > >> suggested that all media > > > >>>>> streams being inactive implied that you are > > > >> "held", but > > > >>> this doesn't > > > >>>>> work for a service such as music-on-hold. > > > >>>>> > > > >>>>> I believe that folks actually want a slightly > > > >> different > > > >>> concept--that > > > >>>>> the semantics we want instead are already > > > >> described in the > > > >>>>> call control > > > >>>>> framework: > > > >>>>> > > > >>>>>> Participants may also be active or passive. > > > >> Active > > > >>> participants are > > > >>>>>> expected to be intelligent enough to leave a > > > >> conversation > > > >>>>> space when > > > >>>>>> they no longer desire to participate. (An > > > >> attentive human > > > >>>>> participant > > > >>>>>> is obviously active.) Some robotic > > > >> participants (such as a voice > > > >>>>>> messaging system, an instant messaging agent, > > > >> or a voice dialog > > > >>>>>> system) may be active participants if they can > > > >> leave the > > > >>>>> conversation > > > >>>>>> space when there is no human interaction. > > > >> Other robots > > > >>> (for example > > > >>>>>> our tone generating robot from the previous > > > >> example) are passive > > > >>>>>> participants. A human participant "on-hold" is > > > >> passive. > > > >>>>> > > > >>>>> I think we should add a new attribute to the > > > >> dialog package that > > > >>>>> expresses this property. My proposal is to > > > >> express this > > > >>> property only > > > >>>>> for the local side of each dialog by adding an > > > >> attribute > > > >>> to the state > > > >>>>> tag in the dialog-info notification body. The > > > >> example below > > > >>>>> includes a > > > >>>>> proposed (optional) participation attribute in > > > >> the state tag. > > > >>>>> > > > >>>>> > > > >>>>> > > >> xmlns="urn:ietf:params:xml:ns:dialog-info" > > > >>>>> version="3" > > > >>>>> state="partial" > > > >>>>> entity="sip:caller@bar.com"> > > > >> > > > > === message truncated === > > > > > > > > > > > > __________________________________ > > > > Do you Yahoo!? > > > > Yahoo! Calendar - Free online calendar with sync to Outlook(TM). > > > > http://calendar.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 > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jun 12 12:30:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17682 for ; Thu, 12 Jun 2003 12:30:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CGUKX04241 for sipping-archive@odin.ietf.org; Thu, 12 Jun 2003 12:30:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CGUKm04238 for ; Thu, 12 Jun 2003 12:30: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 MAA17671 for ; Thu, 12 Jun 2003 12:30:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QUvn-0003x2-00 for sipping-web-archive@ietf.org; Thu, 12 Jun 2003 12:28:07 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QUvm-0003wz-00 for sipping-web-archive@ietf.org; Thu, 12 Jun 2003 12:28:06 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CGRwm04048; Thu, 12 Jun 2003 12:27:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CFuVm01433 for ; Thu, 12 Jun 2003 11:56: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 LAA16595 for ; Thu, 12 Jun 2003 11:56:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QUP9-0003gK-00 for sipping@ietf.org; Thu, 12 Jun 2003 11:54:23 -0400 Received: from smtp011.mail.yahoo.com ([216.136.173.31]) by ietf-mx with smtp (Exim 4.12) id 19QUP8-0003gH-00 for sipping@ietf.org; Thu, 12 Jun 2003 11:54:22 -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; 12 Jun 2003 15:56:28 -0000 Reply-To: From: "Sean Olson" To: "'Rosen, Brian'" , , , Cc: , , , Subject: RE: [Sipping] proposed enhancement to dialog package Date: Thu, 12 Jun 2003 08:56:47 -0700 Message-ID: <009101c330fb$3bd894c0$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 In-Reply-To: <313680C9A886D511A06000204840E1CF070B5ADB@whq-msgusr-02.pit.comms.marconi.com> Importance: Normal 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 For these different experiences at the UA, do you think you need different indications in the dialog package? Is "passive" enough to cover the variety of possibilities here? (My vote is yes) -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Thursday, June 12, 2003 8:05 AM To: 'hisham.khartabil@nokia.com'; jason@azatel.com; rohan@cisco.com; seancolson@yahoo.com Cc: drage@lucent.com; jdrosen@dynamicsoft.com; alan.johnston@wcom.com; sipping@ietf.org Subject: RE: [Sipping] proposed enhancement to dialog package I've always thought that "music on hold" should be local i.e. my choice of music for me to listen to, not your choice of music for me to hear. Eliminates promotional material also :) Brian > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Thursday, June 12, 2003 10:31 AM > To: Brian.Rosen@marconi.com; jason@azatel.com; rohan@cisco.com; > seancolson@yahoo.com > Cc: drage@lucent.com; jdrosen@dynamicsoft.com; alan.johnston@wcom.com; > sipping@ietf.org > Subject: RE: [Sipping] proposed enhancement to dialog package > > > Your desire to hold audio may also be greater when you have > to pay for audio packets being sent. It might be more > interesting for the sender to hold the audio that for the receiver. > > Hisham > > > -----Original Message----- > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Thursday, June 12, 2003 4:16 PM > > To: 'Jason Arnold'; Rohan Mahy; Sean Olson > > Cc: Drage, Keith (Keith); 'Jonathan Rosenberg'; > > alan.johnston@wcom.com; > > sipping@ietf.org > > Subject: RE: [Sipping] proposed enhancement to dialog package > > > > > > May I add some interesting observational data? > > We now have about a year experience with sip videophones that > > implement hold. When you are on hold, you see a gray screen that > > has text indicating the other party put you on hold. We deliver > > silence on the audio channel. > > > > We have lots and lots of feature requests from users. No one has > > ever asked for audio on hold. The visual information is sufficient. > > > > I suspect that you don't need to be entertained, or > pitched. You need > > to know what is happening. If your UA tells you you are on hold, > > then audio when you are on hold may not be important. > > > > One caveat; almost everyone uses our videophone handsfree. > If you are > > holding a handset to your ear, your desire for hold audio may be > > greater. > > > > Brian > > > > > -----Original Message----- > > > From: Jason Arnold [mailto:jason@azatel.com] > > > Sent: Wednesday, June 11, 2003 7:21 PM > > > To: Rohan Mahy; Sean Olson > > > Cc: Drage, Keith (Keith); 'Jonathan Rosenberg'; > > > alan.johnston@wcom.com; > > > sipping@ietf.org > > > Subject: RE: [Sipping] proposed enhancement to dialog package > > > > > > > > > I agree to an extent. > > > > > > If the hold presents "dead air", most people will feel lost > > > with out some > > > indication that they are on hold. It would seem that people > > > require the > > > assurance that the receiving party has not terminated their > > > call. It could > > > be assumed that if the hold period is for an extended period > > > of time, only > > > presenting silence to the calling party, people may think > > > they have been > > > accidentally "disconnected" and terminate their call. > > > > > > It is important to supply a media stream (even irritating > > > propaganda) during > > > the hold session. Non-Conformity to current expectations of > > > people while on > > > hold would seem illogical. > > > > > > Thanks, > > > > > > Jason > > > > > > On Wednesday, June 11, 2003, at 09:40 AM, Sean Olson wrote: > > > > > > > This is an interesting discussion in an almost > > > > academic sense, but it really does not address the reality of > > > > the very simple service that is being described here. > > > > > > > > "hold", "passive", whatever else you want to call it means not > > > > sending/receiving media. > > > > > > I disagree. > > > > > > If you call someone on the average PBX or Key System, and > > ask them to > > > put you on hold, you will typically still receive media > > > (music, tones, > > > irritating announcements). Likewise, if you call a call > center or a > > > big store, you are likely to wait "on hold" with some type of > > > propaganda, music, or recorded message claiming that you are > > > important. > > > > > > Clearly the user experience of the user-visible feature > > "Hold" is that > > > hold does not typically equate to "no media". > > > > > > I believe that from a feature perspective the existence or > > presence of > > > no media being sent/received is irrelevant. It does not affect my > > > perception that I am on hold, nor does it affect the > > perception of my > > > peer if I am on hold or not, since I can receive or not > > receive media > > > and still know that I am on hold. > > > > > > My assertion is that what users really want to know is if the > > > other end > > > is actively participating. Do they care if I am still around? Is > > > there the potential for interaction between me and my peer? > > > > > > With this concept, I can build useful features that users > can relate > > > to. For example, I would like "passive" participants > (participants > > > that cannot interact with me, like inane robots sending me > > > Musak) to be > > > automatically muted in my conference. > > > > > > I would like to express this property. If the name > "passive" is too > > > confusing, then feel free to suggest other terms. > "interactivity" > > > EQUAL ( "yes" / "no" ) ? > > > > > > thanks, > > > -rohan > > > > > > > > > > We've all > > > > experienced this. And, yes, this can be independent of the > > > > ability to do SIP signaling. > > > > > > > > I think we are focusing too much on signaling here and not > > > > enough on the user experience that is being built. And I > > > > certainly don't want a history lesson in ISDN signaling ;-) > > > > > > > > > > > > --- "Drage, Keith (Keith)" wrote: > > > >> See below > > > >> > > > >> regards > > > >> > > > >> Keith > > > >> > > > >> Keith Drage > > > >> Lucent Technologies > > > >> Tel: +44 1793 776249 > > > >> Email: drage@lucent.com > > > >> > > > >>> -----Original Message----- > > > >>> From: Rohan Mahy [mailto:rohan@cisco.com] > > > >>> Sent: 10 June 2003 16:25 > > > >>> To: Drage, Keith (Keith) > > > >>> Cc: 'Jonathan Rosenberg'; alan.johnston@wcom.com; > > > >> 'sipping@ietf.org' > > > >>> Subject: Re: [Sipping] proposed enhancement to > > > >> dialog package > > > >>> > > > >>> > > > >>> Hi Keith, > > > >>> > > > >>> Hold as a UI concept significantly predated the > > > >> development of ISDN. > > > >> > > > >> Agreed, and my initial message identified in that > > > >> case (analogue PSTN terminals) that Hold was originally to > > > >> recall the register (and there was a manual board equivalent as > > > >> well) to allow access resources to be used for signalling, as a > > > >> result of that signalling, the access resources might be used > > > >> for communication with another party, and only as a > > > >> by product of that did it necessarily result in loss > > > >> of communication path with the other party. > > > >> > > > >>> In any case, an ISDN user (Alice) who requests an > > > >> ISDN hold > > > >>> is still a > > > >>> passive participant by my definition. When > > > >> Alice's call is connected > > > >>> to a conference server and all the active > > > >> participants say "ok, we're > > > >>> leaving now, good bye", Alice is not active enough > > > >> to be able to hang > > > >>> up. > > > >> > > > >> Assuming your last statement still refers to an ISDN user, then > > > >> I can think of nothing in the above scenario that prevents > > > >> Alice sending a DISCONNECT, and receiving a RELEASE back. Can > > > >> you clarify. The DSS1 basic call state machine is totally > > > >> independent of any subsidiary state machine relating to > > > >> hold/retrieve. > > > >> > > > >> If you are referring to hanging up the conference bridge > > > >> resources, then this is dependent on the concept of ownership, > > > >> which varies based on the conference service provided, and also > > > >> between public and private networks. > > > >> > > > >> As a result, I think I am now confused about what > > > >> you actually mean by passive, can you elaborate further. > > > >> > > > >> > > > >>> > > > >>> I agree that whatever we do, we need to describe > > > >> the semantics very > > > >>> crisply. > > > >>> > > > >>> thanks, > > > >>> -rohan > > > >>> > > > >>> > > > >>> On Tuesday, June 10, 2003, at 04:47 AM, Drage, > > > >> Keith (Keith) wrote: > > > >>> > > > >>>> I fail to see how thw property you are proposing > > > >> correlates in some > > > >>>> way to any concept of hold. I agree that "hold" > > > >> has many meanings, > > > >>>> based on which type of signalling you are using. > > > >>>> > > > >>>> To clarify, the prime function of hold in the > > > >> PSTN was never to > > > >>>> interrupt the communication, that was a side > > > >> effect of grabbing the > > > >>>> access resources to signal to another party. > > > >> Thus for ISDN, hold > > > >>>> therefore was only a removal of access resources > > > >> (the > > > >>> bearer) so that > > > >>>> that bearer could be reused for another call; > > > >> again the side effect > > > >>>> was to interrupt the communication. The sole > > > >> function of > > > >>> hold for SIP > > > >>>> is to interrupt the communication. > > > >>>> > > > >>>> Certainly, if an ISDN user places another user > > > >> on hold, I > > > >>> would regard > > > >>>> neither user as "passive" as you seem to be > > > >> defining here. > > > >>>> > > > >>>> If we are going to do this, can we make sure we > > > >> define the > > > >>> semantics > > > >>>> correctly. Otherwise we will surely create > > > >> confusion, > > > >>> particularly if > > > >>>> people try and equate this concept with that of > > > >> hold, and in > > > >>>> particular with the PSTN concept. > > > >>>> > > > >>>> regards > > > >>>> > > > >>>> Keith > > > >>>> > > > >>>> > > > >>>> Keith Drage > > > >>>> Lucent Technologies > > > >>>> Tel: +44 1793 776249 > > > >>>> Email: drage@lucent.com > > > >>>> > > > >>>>> -----Original Message----- > > > >>>>> From: Rohan Mahy [mailto:rohan@cisco.com] > > > >>>>> Sent: 03 June 2003 22:18 > > > >>>>> To: 'Jonathan Rosenberg' > > > >>>>> Cc: rohan@cisco.com; alan.johnston@wcom.com; > > > >> 'sipping@ietf.org' > > > >>>>> Subject: [Sipping] proposed enhancement to > > > >> dialog package > > > >>>>> > > > >>>>> > > > >>>>> Hi, > > > >>>>> > > > >>>>> There have been many requests for the dialog > > > >> package to express the > > > >>>>> concept of hold. The problem is that nobody had > > > >> an especially good > > > >>>>> definition of what "on-hold" meant. Some > > > >> suggested that all media > > > >>>>> streams being inactive implied that you are > > > >> "held", but > > > >>> this doesn't > > > >>>>> work for a service such as music-on-hold. > > > >>>>> > > > >>>>> I believe that folks actually want a slightly > > > >> different > > > >>> concept--that > > > >>>>> the semantics we want instead are already > > > >> described in the > > > >>>>> call control > > > >>>>> framework: > > > >>>>> > > > >>>>>> Participants may also be active or passive. > > > >> Active > > > >>> participants are > > > >>>>>> expected to be intelligent enough to leave a > > > >> conversation > > > >>>>> space when > > > >>>>>> they no longer desire to participate. (An > > > >> attentive human > > > >>>>> participant > > > >>>>>> is obviously active.) Some robotic > > > >> participants (such as a voice > > > >>>>>> messaging system, an instant messaging agent, > > > >> or a voice dialog > > > >>>>>> system) may be active participants if they can > > > >> leave the > > > >>>>> conversation > > > >>>>>> space when there is no human interaction. > > > >> Other robots > > > >>> (for example > > > >>>>>> our tone generating robot from the previous > > > >> example) are passive > > > >>>>>> participants. A human participant "on-hold" is > > > >> passive. > > > >>>>> > > > >>>>> I think we should add a new attribute to the > > > >> dialog package that > > > >>>>> expresses this property. My proposal is to > > > >> express this > > > >>> property only > > > >>>>> for the local side of each dialog by adding an > > > >> attribute > > > >>> to the state > > > >>>>> tag in the dialog-info notification body. The > > > >> example below > > > >>>>> includes a > > > >>>>> proposed (optional) participation attribute in > > > >> the state tag. > > > >>>>> > > > >>>>> > > > >>>>> > > >> xmlns="urn:ietf:params:xml:ns:dialog-info" > > > >>>>> version="3" > > > >>>>> state="partial" > > > >>>>> entity="sip:caller@bar.com"> > > > >> > > > > === message truncated === > > > > > > > > > > > > __________________________________ > > > > Do you Yahoo!? > > > > Yahoo! Calendar - Free online calendar with sync to Outlook(TM). > > > > http://calendar.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 > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jun 12 22:19:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05456 for ; Thu, 12 Jun 2003 22:19:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5D2JMM13088 for sipping-archive@odin.ietf.org; Thu, 12 Jun 2003 22:19:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D2JMm13085 for ; Thu, 12 Jun 2003 22:19: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 WAA05446 for ; Thu, 12 Jun 2003 22:19:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qe7r-0000KT-00 for sipping-web-archive@ietf.org; Thu, 12 Jun 2003 22:17:11 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Qe7r-0000KP-00 for sipping-web-archive@ietf.org; Thu, 12 Jun 2003 22:17:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CJ73a16887; Thu, 12 Jun 2003 15:07:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CJ6Rm16779 for ; Thu, 12 Jun 2003 15:06: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 PAA23417 for ; Thu, 12 Jun 2003 15:06:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QXMv-0005Kw-00 for sipping@ietf.org; Thu, 12 Jun 2003 15:04:17 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19QXMu-0005Ks-00 for sipping@ietf.org; Thu, 12 Jun 2003 15:04:16 -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 PAA26804 for ; Thu, 12 Jun 2003 15:05:52 -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 PAA23226 for ; Thu, 12 Jun 2003 15:05:53 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Jun 2003 15:05:52 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5AE1@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'sipping@ietf.org'" Date: Thu, 12 Jun 2003 15:05:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] Call Waiting - who does the tone Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Robert If you have a UA that handles multiple calls, you don't need call waiting. Another INVITE appears, you show it in your UI (lights, LCD, whatever), and eventually the user decides to answer or ignore it. What if you are a really simple UA? A second call comes in. Who does what? It would seem that the really best answer is that the dumb UA puts the call waiting tone into the current audio. The user can then either hang up the current call and let the second call ring through, or it can press the "flash" button (if implemented), alternating between the two. It's all local. What doesn't seem to work at all is to let some "tones and announcements" server handle it - there is no way the dumb phone will create a media connection to such a server if it has an active call. That means call waiting CANNOT be implemented by any other element but the called UA. So, is this something that goes in a BCP? Even a dumb phone should handle call waiting. Brian _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Jun 12 23:13:36 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 XAA06527 for ; Thu, 12 Jun 2003 23:13:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5D3D6H16610 for sipping-archive@odin.ietf.org; Thu, 12 Jun 2003 23:13:06 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D3Ctm16601 for ; Thu, 12 Jun 2003 23:12: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 XAA06510 for ; Thu, 12 Jun 2003 23:12:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qexf-0000Ze-00 for sipping-web-archive@ietf.org; Thu, 12 Jun 2003 23:10:43 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Qexe-0000Zb-00 for sipping-web-archive@ietf.org; Thu, 12 Jun 2003 23:10:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CMv3a31960; Thu, 12 Jun 2003 18:57:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CMumm31943 for ; Thu, 12 Jun 2003 18:56: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 SAA00702 for ; Thu, 12 Jun 2003 18:56:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qaxq-0006m3-00 for sipping@ietf.org; Thu, 12 Jun 2003 18:54:38 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19Qaxp-0006m0-00 for sipping@ietf.org; Thu, 12 Jun 2003 18:54:37 -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 h5CMu9wc025589; Thu, 12 Jun 2003 15:56:10 -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 AIB73680; Thu, 12 Jun 2003 15:51:02 -0700 (PDT) Date: Thu, 12 Jun 2003 15:37:04 -0700 Subject: Re: [Sipping] Message Body format for INFO method carrying DTMF Digits Content-Type: text/plain; delsp=yes; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "debanjan" From: Rohan Mahy In-Reply-To: <000d01c330e7$7afc9ca0$6064a8c0@userbvyungtdgz> Message-Id: <6438FB47-9D26-11D7-A0EF-0003938AF740@cisco.com> X-Mailer: Apple Mail (2.552) X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5CMumm31944 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h5CMv3a31960 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5D3Ctm16601 Content-Transfer-Encoding: 8bit [just to SIPPING] Hi, A SIPPING WG design team has been working on a solution to this problem. Instead of sending digits in INFO, may I suggest you take a look at KPML and the application interaction framework. http://www.softarmor.com/sipping/drafts/draft-burger-sipping-kpml-01.txt http://www.softarmor.com/sipping/drafts/draft-jennings-sip-app-info- 00.txt http://www.softarmor.com/sipping/drafts/draft-rosenberg-sipping-app- interaction-framework-00.txt http://www.softarmor.com/sipping/drafts/draft-culpepper-sipping-app- interact-reqs-03.txt thanks, -rohan btw: please post to just one of the SIPish mailing lists. If you are in doubt, you can mail the chairs to ask which list is most relevant On Thursday, June 12, 2003, at 06:35 AM, debanjan wrote: > Hi, >     Anyone has any idea regarding what should be message body of SIP > Info method that carries the DTMF digits. Is there any standard RFC or > draft implementation. >     Any suggestions are welcome. >   >     Regards >     Debanjan >     >     D-Link India Ltd >     Software and R & D Center _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jun 13 01:23:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09396 for ; Fri, 13 Jun 2003 01:23:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5D5Mcm25790 for sipping-archive@odin.ietf.org; Fri, 13 Jun 2003 01:22:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D5Mbm25787 for ; Fri, 13 Jun 2003 01:22: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 BAA09384 for ; Fri, 13 Jun 2003 01:22:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QgzD-0001JE-00 for sipping-web-archive@ietf.org; Fri, 13 Jun 2003 01:20:27 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QgzC-0001JB-00 for sipping-web-archive@ietf.org; Fri, 13 Jun 2003 01:20:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D1L3a09074; Thu, 12 Jun 2003 21:21:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D1Kum09056 for ; Thu, 12 Jun 2003 21:20: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 VAA03750 for ; Thu, 12 Jun 2003 21:20:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QdDL-0007gG-00 for sipping@ietf.org; Thu, 12 Jun 2003 21:18:47 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19QdDK-0007ft-00 for sipping@ietf.org; Thu, 12 Jun 2003 21:18:46 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h5D1I3Dc018227; Thu, 12 Jun 2003 21:18:45 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Jun 2003 20:18:02 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A6485C@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Gonzalo Camarillo Gonzalez (LMF)'" , "'sipping@ietf.org'" Cc: "Rohan Mahy (E-mail)" , "Dean Willis (E-mail)" , "Patrick Mourot (E-mail)" , "Olivier Rousseau (E-mail)" , "Frank Derks (E-mail)" Subject: RE: [Sipping] WGLC for Q.SIP-SIP mapping draft Date: Thu, 12 Jun 2003 20:17:58 -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: , Reference [19] should point to RFC 3398 instead of the draft-... Also, the overlap discussion was split out of that document, so the references to overlap procedures need to be updated. I'll try to find time to give this document a more thorough review later next week. /a > -----Original Message----- > From: Gonzalo Camarillo Gonzalez (LMF) > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Tuesday, May 27, 2003 1:04 > To: 'sipping@ietf.org' > Cc: Rohan Mahy (E-mail); Dean Willis (E-mail); Patrick Mourot > (E-mail); > Olivier Rousseau (E-mail); Frank Derks (E-mail) > Subject: [Sipping] WGLC for Q.SIP-SIP mapping draft > > > Folks, > > we would like to WGLC the draft below: > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-01.txt > > This WGLC will end on June 20th. > > Gonzalo > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jun 13 09:41:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04871 for ; Fri, 13 Jun 2003 09:41:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DDfMS11837 for sipping-archive@odin.ietf.org; Fri, 13 Jun 2003 09:41:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DDfMm11834 for ; Fri, 13 Jun 2003 09:41: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 JAA04865 for ; Fri, 13 Jun 2003 09:41:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qolq-0005K0-00 for sipping-web-archive@ietf.org; Fri, 13 Jun 2003 09:39:10 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Qolp-0005Jx-00 for sipping-web-archive@ietf.org; Fri, 13 Jun 2003 09:39:09 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CIE2a13908; Thu, 12 Jun 2003 14:14:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AJg9B20980 for ; Tue, 10 Jun 2003 15:42: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 PAA15126 for ; Tue, 10 Jun 2003 15:42:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PoyS-0001dl-00 for sipping@ietf.org; Tue, 10 Jun 2003 15:40:04 -0400 Received: from mail3.pi.se ([195.7.64.137]) by ietf-mx with esmtp (Exim 4.12) id 19PoyR-0001di-00 for sipping@ietf.org; Tue, 10 Jun 2003 15:40:03 -0400 Received: from VAIOMHP (h32n2fls31o265.telia.com [217.208.189.32]) (authenticated) by mail3.pi.se (8.11.2/8.11.2) with ESMTP id h5AJfvx02977; Tue, 10 Jun 2003 21:41:57 +0200 (CEST) From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= To: "Henry Sinnreich" , "'Drage, Keith \(Keith\)'" , "'Sipping@Ietf. Org'" , "'Sipforum-Discussion@Lists. Su. Se'" Subject: SV: [Sipforum-discussion] RE: [Sipping] Text support in SIP phones Date: Tue, 10 Jun 2003 21:41:48 +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: <000501c32f69$93095600$ea3e573f@hsinnreich2> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.pi.se id h5AJfvx02977 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5AJg9B20981 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h5CIE2a13908 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5DDfMm11834 Content-Transfer-Encoding: 8bit I agree that this discussion starts to get balance into the specification of the real time text conversation feature. Firstly, I have discovered that I need to explain again that what we talk about is a real time, character by character transmission and display of text. You can see the thought as it is growing and being formed into text. It is a very direct way to have contact, and once you have used it, you realize that in some applications it is essential to have access to this feature. It has the same immediate flow as audio in voice telephony and video in video telephony. In fact, there is a name for the three media together, it is called Total Conversation. It is true that the force behind defining it has come from the needs of people with communication related disabilities. But I am sure that once commonly implemented, it will become a natural and popular feature that is often used during voice calls between most users. Instant messaging is also a very handy service. But it goes message by message, and therefore does not have the direct touch as the real time conversational service in voice, text and video has. We have a forerunner in the specification of media for the SIP based IP Multimedia phone in 3GPP. Maybe we can pick the same style of specification. In 3GPP TS 26.235, "Packet switched conversational multimedia applications, default codecs", it is specified among the enumeration of supported media: 6.3 Real time text 3G PS multimedia terminals offering real time text conversation should support ITU-T Recommendation T.140 [25] Text Conversation presentation coding. And in the chapter on RTP payload, it is specified: 9.2 RTP payload RTP payload formats specified by IETF shall be used for real time media streams. RTP payload format for the AMR narrowband speech codec is specified in annex B. RTP payload format for the AMR wideband speech codec is specified in annex B. RTP payload format for the ITU-T Recommendation H.263 [6] video codec is specified in IETF RFC 2429 [3]. RTP payload format for the MPEG-4 visual simple profile level 0 is specified in IETF RFC 3016 [5]. RTP payload format for the ITU-T Recommendation T.140 [25] text conversation coding is specified in IETF RFC 2793 [24]. In the annex A on specific details, the following is specified for text: A.3 Text Use of the redundancy coding variant specified in RFC 2793 [24] is recommended for error resilience. -------------------------------- When this topic was handled in 3GPP, there was opposition against mentioning the reason for introducing the text feature as being something specific for disabled people. I think that is still valid. I suggest that the following formulation is used: **************************************************************************** ************************************** SIP-zz, digital text support: SIP telephone devices SHOULD support real time text conversation. If text is supported, it MUST support RFC2793 [y], for text coding and packetization, and it MUST be possible to use text simultaneously with voice. **************************************************************************** ************************************** Gunnar ------------------------------------------- Gunnar Hellström, Omnitor, Renathvägen 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ån: sipforum-discussion-admin@lists.su.se > [mailto:sipforum-discussion-admin@lists.su.se]För Henry Sinnreich > Skickat: den 10 juni 2003 18:02 > Till: 'Drage, Keith (Keith)'; 'Henry Sinnreich'; 'Gunnar Hellström'; > 'Sipping@Ietf. Org'; 'Sipforum-Discussion@Lists. Su. Se' > Ämne: [Sipforum-discussion] RE: [Sipping] Text support in SIP phones > > > Keith, thanks for bringing balance, I believe, to this discussion. > > We could formulate soemthing like "SIP phones that have a text display > and advertised as supporting the hearing or speech disabled MUST..." > > Would this be OK? > > Henry > > > -----Original Message----- > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > On Behalf Of Drage, Keith (Keith) > > Sent: Tuesday, June 10, 2003 8:14 AM > > To: 'Henry Sinnreich'; 'Gunnar Hellström'; 'Sipping@Ietf. > > Org'; 'Sipforum-Discussion@Lists. Su. Se' > > Subject: RE: [Sipping] Text support in SIP phones > > > > > > I would suggest that treating these sort of things as MUST > > strength is best left to national regulatory requirements, > > along with other things like fitness for purpose and so on. I > > have no objection to their being mentioned. By the way, I > > understood this document was being progressed as authors > > individual submission, and was therefore not standards track. > > > > Any such MUST would surely need to be qualified anyway. If > > the purpose of the devise is such that it renders a textual > > devise irrelevant, then why require one to be fitted. Suppose > > we were designing a SIP phone for the totally blind, and this > > was designed to be worn as a headset, a text device would be > > irrelevant to such a user, and positioning such a device > > where it could be seen would require an extra box hanging out > > of the side of the product. > > > > regards > > > > Keith > > > > Keith Drage > > Lucent Technologies > > Tel: +44 1793 776249 > > Email: drage@lucent.com > > > > > -----Original Message----- > > > From: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com] > > > Sent: 27 May 2003 17:18 > > > To: 'Gunnar Hellström'; 'Sipping@Ietf. Org'; > > > 'Sipforum-Discussion@Lists. > > > Su. Se' > > > Cc: 'Henry Sinnreich' > > > Subject: RE: [Sipping] Text support in SIP phones > > > > > > > > > Gunnar, this all seems very reasonable, and I will try to insert it > > > properly. > > > > > > Henry > > > > > > > -----Original Message----- > > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > > > On Behalf Of Gunnar Hellström > > > > Sent: Thursday, May 22, 2003 6:54 PM > > > > To: 'Sipping@Ietf. Org'; Sipforum-Discussion@Lists. Su. Se > > > > Cc: Henry Sinnreich > > > > Subject: [Sipping] Text support in SIP phones > > > > > > > > > > > > Sorry, I missed out the reference to the SIP device specification. > > > > > > > > Henry and all, > > > > > > > > Some time ago, I suggested addition of support for real time > > > > text communication to the SIP device specification > > > > > > > > > http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-00.txt > > > > > > > > This was the simple part of the proposal: > > > > > > > > > SIP-zz, digital text support: SIP telephone devices MUST support > > > > > real time text conversation using RFC 2793 [y] for the > > > > text stream. > > > > > It MUST be possible to use text simultaneously with voice. > > > > > > > > > > > > > > > > > > > > --------------------------------------------- > > > > > In 4.11 Ringer Behaviour : add the section below for the > > > > purpose of > > > > > deaf, hearing impaired, deaf-blind people and people in the > > > > garden and > > > > > noisy > > > > > locations: > > > > > > > > > > SIP Telephony devices MUST provide an external interface to an > > > > > external alerting system. > > > > > > > > > > > > > > > > > > > > Add to References > > > > > ----------------- > > > > > [y] G. Hellstrom: "RTP Payload for Text Conversation.", > > RFC 2793, > > > > > IETF, May 2000. > > > > > > > > > > -------------------------------------------------------------- > > > > > > > > The reception of this proposal was very positive. > > > > Now, I would like to see the final formulation, and check > > > > that we agree on it. > > > > > > > > I regard this requirement to be very light. In the Interface > > > > section ( e.g. > > > > Int-2) , there is already mentioning of mandatory text input > > > > mechanisms, and assumptions that a display would be normal, > > > > since handling of phone books and buddy lists are mandatory. > > > > To re-use these text interface devices during the call for > > > > standardised text conversation purposes seems straightforward. > > > > > > > > It could be wise to add the T.140 text presentation protocol > > > > as a codec to the codec section. The normal SDP used together > > > > with RFC2793 for text could also be specified. Do you want > > > to do that? > > > > > > > > > > > > ----- > > > > > > > > We also need to check the ideas around the other proposed > > > > requirements: The requirement to include text telephone modem > > > > in all designs where an RJ11 phone connector exists, and the > > > > requirement to support RFC 3351. I suggest that we start with > > > > the straightforward and mainstream requirement above. Is that > > > > accepted as it is? > > > > > > > > > > > > Regards > > > > > > > > Gunnar > > > > ------------------------------------------- > > > > Gunnar Hellström, Omnitor, Renathvägen 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/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 mailnull@www1.ietf.org Fri Jun 13 09:46:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05008 for ; Fri, 13 Jun 2003 09:46:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DDkBI12137 for sipping-archive@odin.ietf.org; Fri, 13 Jun 2003 09:46:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DDkBm12134 for ; Fri, 13 Jun 2003 09:46: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 JAA04984 for ; Fri, 13 Jun 2003 09:46:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QoqW-0005La-00 for sipping-web-archive@ietf.org; Fri, 13 Jun 2003 09:44:00 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QoqV-0005LX-00 for sipping-web-archive@ietf.org; Fri, 13 Jun 2003 09:43:59 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CIE4a13918; Thu, 12 Jun 2003 14:14:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BLeAm08438 for ; Wed, 11 Jun 2003 17:40: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 RAA04376 for ; Wed, 11 Jun 2003 17:40:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QDIA-0004Dq-00 for sipping@ietf.org; Wed, 11 Jun 2003 17:38:02 -0400 Received: from mail3.pi.se ([195.7.64.137]) by ietf-mx with esmtp (Exim 4.12) id 19QDI7-0004DQ-00 for sipping@ietf.org; Wed, 11 Jun 2003 17:37:59 -0400 Received: from VAIOMHP (h32n2fls31o265.telia.com [217.208.189.32]) (authenticated) by mail3.pi.se (8.11.2/8.11.2) with ESMTP id h5BLduS18006; Wed, 11 Jun 2003 23:39:56 +0200 (CEST) From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= To: "Henry Sinnreich" , "'Sipping@Ietf. Org'" , "'Sipforum-Discussion@Lists. Su. Se'" , "'Drage, Keith \(Keith\)'" Subject: SV: [Sipforum-discussion] RE: [Sipping] Text support in SIP phones Date: Wed, 11 Jun 2003 23:39:46 +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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <001101c33000$57b615b0$1d8032a6@hsinnreich2> X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.pi.se id h5BLduS18006 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5BLeAm08440 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h5CIE4a13918 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5DDkBm12134 Content-Transfer-Encoding: 8bit OK, I think it would be fine to bring the introduction of real time text conversation up for discussion in the SIPPING group. I think that the small requirement statements we have discussed so far for the sipdev specification are sufficient for that level. But I have noticed some uncertainty from developers on what SDP to use to open the RFC2793 text channel, and about some other good implementation habits around the text channel. We need to be sure that there is good agreement on such issues, so that we get maximum harmonization and interoperability between implementations. ( real time text conversation in the PSTN has a terrible history of fragmentation and incompatibility, and it is time to make sure that is history now ) I want to have your advice if you want to see also SDP examples for the text channel in the sipdev spec, in a separate Text Conversation Best Code of Practice spec, or if there is any plan for a sipdev-technical guideline spec where it could fit. Gunnar ------------------------------------------- Gunnar Hellström, Omnitor, Renathvägen 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ån: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com] > Skickat: den 11 juni 2003 11:59 > Till: 'Gunnar Hellström'; 'Sipping@Ietf. Org'; > 'Sipforum-Discussion@Lists. Su. Se'; 'Drage, Keith (Keith)' > Ämne: RE: [Sipforum-discussion] RE: [Sipping] Text support in SIP phones > > > Gunnar, thanks for bringing this up! I believe now we can ask for > discussion time at the SIPPING WG meeting. > > Henry > > > -----Original Message----- > > From: sipforum-discussion-admin@lists.su.se > > [mailto:sipforum-discussion-admin@lists.su.se] On Behalf Of > > Gunnar Hellström > > Sent: Tuesday, June 10, 2003 2:42 PM > > To: Henry Sinnreich; 'Drage, Keith (Keith)'; 'Sipping@Ietf. > > Org'; 'Sipforum-Discussion@Lists. Su. Se' > > Subject: SV: [Sipforum-discussion] RE: [Sipping] Text support > > in SIP phones > > > > > > I agree that this discussion starts to get balance into the > > specification of the real time text conversation feature. > > > > Firstly, I have discovered that I need to explain again that > > what we talk about is a real time, character by character > > transmission and display of text. You can see the thought as > > it is growing and being formed into text. It is a very direct > > way to have contact, and once you have used it, you realize > > that in some applications it is essential to have access to > > this feature. It has the same immediate flow as audio in > > voice telephony and video in video telephony. > > > > In fact, there is a name for the three media together, it is > > called Total Conversation. > > > > It is true that the force behind defining it has come from > > the needs of people with communication related disabilities. > > But I am sure that once commonly implemented, it will become > > a natural and popular feature that is often used during voice > > calls between most users. > > > > Instant messaging is also a very handy service. But it goes > > message by message, and therefore does not have the direct > > touch as the real time conversational service in voice, text > > and video has. > > > > > > > > We have a forerunner in the specification of media for the > > SIP based IP Multimedia phone in 3GPP. Maybe we can pick the > > same style of specification. In 3GPP TS 26.235, "Packet > > switched conversational multimedia applications, default > > codecs", it is specified among the enumeration of supported media: > > > > 6.3 Real time text > > 3G PS multimedia terminals offering real time text > > conversation should support ITU-T Recommendation T.140 [25] > > Text Conversation presentation coding. > > > > And in the chapter on RTP payload, it is specified: > > > > 9.2 RTP payload > > RTP payload formats specified by IETF shall be used for real > > time media streams. RTP payload format for the AMR narrowband > > speech codec is specified in annex B. RTP payload format for > > the AMR wideband speech codec is specified in annex B. RTP > > payload format for the ITU-T Recommendation H.263 [6] video > > codec is specified in IETF RFC 2429 [3]. RTP payload format > > for the MPEG-4 visual simple profile level 0 is specified in > > IETF RFC 3016 [5]. RTP payload format for the ITU-T > > Recommendation T.140 [25] text conversation coding is > > specified in IETF RFC 2793 [24]. > > > > In the annex A on specific details, the following is > > specified for text: > > > > A.3 Text > > Use of the redundancy coding variant specified in RFC 2793 > > [24] is recommended for error resilience. > > > > -------------------------------- > > When this topic was handled in 3GPP, there was opposition > > against mentioning the reason for introducing the text > > feature as being something specific for disabled people. > > > > I think that is still valid. > > > > I suggest that the following formulation is used: > > ************************************************************** > > ************** > > ************************************** > > SIP-zz, digital text support: SIP telephone devices SHOULD > > support real time text conversation. If text is supported, it > > MUST support RFC2793 [y], for text coding and packetization, > > and it MUST be possible to use text simultaneously with voice. > > ************************************************************** > > ************** > > ************************************** > > > > > > Gunnar > > ------------------------------------------- > > Gunnar Hellström, Omnitor, Renathvägen 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ån: sipforum-discussion-admin@lists.su.se > > > [mailto:sipforum-discussion-admin@lists.su.se]För Henry Sinnreich > > > Skickat: den 10 juni 2003 18:02 > > > Till: 'Drage, Keith (Keith)'; 'Henry Sinnreich'; 'Gunnar > > Hellström'; > > > 'Sipping@Ietf. Org'; 'Sipforum-Discussion@Lists. Su. Se' > > > Ämne: [Sipforum-discussion] RE: [Sipping] Text support in SIP phones > > > > > > > > > Keith, thanks for bringing balance, I believe, to this discussion. > > > > > > We could formulate soemthing like "SIP phones that have a > > text display > > > and advertised as supporting the hearing or speech disabled MUST..." > > > > > > Would this be OK? > > > > > > Henry > > > > > > > -----Original Message----- > > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On > > > > Behalf Of Drage, Keith (Keith) > > > > Sent: Tuesday, June 10, 2003 8:14 AM > > > > To: 'Henry Sinnreich'; 'Gunnar Hellström'; 'Sipping@Ietf. Org'; > > > > 'Sipforum-Discussion@Lists. Su. Se' > > > > Subject: RE: [Sipping] Text support in SIP phones > > > > > > > > > > > > I would suggest that treating these sort of things as > > MUST strength > > > > is best left to national regulatory requirements, along > > with other > > > > things like fitness for purpose and so on. I have no objection to > > > > their being mentioned. By the way, I understood this document was > > > > being progressed as authors individual submission, and > > was therefore > > > > not standards track. > > > > > > > > Any such MUST would surely need to be qualified anyway. If the > > > > purpose of the devise is such that it renders a textual devise > > > > irrelevant, then why require one to be fitted. Suppose we were > > > > designing a SIP phone for the totally blind, and this was > > designed > > > > to be worn as a headset, a text device would be > > irrelevant to such a > > > > user, and positioning such a device where it could be seen would > > > > require an extra box hanging out of the side of the product. > > > > > > > > regards > > > > > > > > Keith > > > > > > > > Keith Drage > > > > Lucent Technologies > > > > Tel: +44 1793 776249 > > > > Email: drage@lucent.com > > > > > > > > > -----Original Message----- > > > > > From: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com] > > > > > Sent: 27 May 2003 17:18 > > > > > To: 'Gunnar Hellström'; 'Sipping@Ietf. Org'; > > > > > 'Sipforum-Discussion@Lists. Su. Se' > > > > > Cc: 'Henry Sinnreich' > > > > > Subject: RE: [Sipping] Text support in SIP phones > > > > > > > > > > > > > > > Gunnar, this all seems very reasonable, and I will try > > to insert > > > > > it properly. > > > > > > > > > > Henry > > > > > > > > > > > -----Original Message----- > > > > > > From: sipping-admin@ietf.org > > [mailto:sipping-admin@ietf.org] On > > > > > > Behalf Of Gunnar Hellström > > > > > > Sent: Thursday, May 22, 2003 6:54 PM > > > > > > To: 'Sipping@Ietf. Org'; Sipforum-Discussion@Lists. Su. Se > > > > > > Cc: Henry Sinnreich > > > > > > Subject: [Sipping] Text support in SIP phones > > > > > > > > > > > > > > > > > > Sorry, I missed out the reference to the SIP device > > > > > > specification. > > > > > > > > > > > > Henry and all, > > > > > > > > > > > > Some time ago, I suggested addition of support for real time > > > > > > text communication to the SIP device specification > > > > > > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-00.tx > > > > t > > > > > > > > > > > > This was the simple part of the proposal: > > > > > > > > > > > > > SIP-zz, digital text support: SIP telephone devices > > MUST support > > > > > > > real time text conversation using RFC 2793 [y] for the > > > > > > text stream. > > > > > > > It MUST be possible to use text simultaneously with voice. > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------- > > > > > > > In 4.11 Ringer Behaviour : add the section below for the > > > > > > purpose of > > > > > > > deaf, hearing impaired, deaf-blind people and people in the > > > > > > garden and > > > > > > > noisy > > > > > > > locations: > > > > > > > > > > > > > > SIP Telephony devices MUST provide an external > > interface to an > > > > > > > external alerting system. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Add to References > > > > > > > ----------------- > > > > > > > [y] G. Hellstrom: "RTP Payload for Text Conversation.", > > > > RFC 2793, > > > > > > > IETF, May 2000. > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > > > > > > > > The reception of this proposal was very positive. > > > > > > Now, I would like to see the final formulation, and > > check that > > > > > > we agree on it. > > > > > > > > > > > > I regard this requirement to be very light. In the Interface > > > > > > section ( e.g. > > > > > > Int-2) , there is already mentioning of mandatory text input > > > > > > mechanisms, and assumptions that a display would be normal, > > > > > > since handling of phone books and buddy lists are > > mandatory. To > > > > > > re-use these text interface devices during the call for > > > > > > standardised text conversation purposes seems straightforward. > > > > > > > > > > > > It could be wise to add the T.140 text presentation > > protocol as > > > > > > a codec to the codec section. The normal SDP used > > together with > > > > > > RFC2793 for text could also be specified. Do you want > > > > > to do that? > > > > > > > > > > > > > > > > > > ----- > > > > > > > > > > > > We also need to check the ideas around the other proposed > > > > > > requirements: The requirement to include text > > telephone modem in > > > > > > all designs where an RJ11 phone connector exists, and the > > > > > > requirement to support RFC 3351. I suggest that we start with > > > > > > the straightforward and mainstream requirement above. Is that > > > > > > accepted as it is? > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > Gunnar > > > > > > ------------------------------------------- > > > > > > Gunnar Hellström, Omnitor, Renathvägen 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/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/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 From mailnull@www1.ietf.org Fri Jun 13 10:09:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06411 for ; Fri, 13 Jun 2003 10:09:35 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DE98r14427 for sipping-archive@odin.ietf.org; Fri, 13 Jun 2003 10:09:08 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DE98m14424 for ; Fri, 13 Jun 2003 10: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 KAA06351 for ; Fri, 13 Jun 2003 10:09:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QpCi-0005aS-00 for sipping-web-archive@ietf.org; Fri, 13 Jun 2003 10:06:56 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QpCi-0005aP-00 for sipping-web-archive@ietf.org; Fri, 13 Jun 2003 10:06:56 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DAP3a28209; Fri, 13 Jun 2003 06:25:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DAO3m28166 for ; Fri, 13 Jun 2003 06:24: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 GAA27494 for ; Fri, 13 Jun 2003 06:23:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qlgu-0003S0-00 for sipping@ietf.org; Fri, 13 Jun 2003 06:21:52 -0400 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19Qlgu-0003Rb-00 for sipping@ietf.org; Fri, 13 Jun 2003 06:21:52 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h5DANRP05151 for ; Fri, 13 Jun 2003 05:23:27 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Jun 2003 11:23:26 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00439ED6B@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Rosen, Brian'" , "'sipping@ietf.org'" Subject: RE: [Sipping] Call Waiting - who does the tone Date: Fri, 13 Jun 2003 11:23:24 +0100 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: , Would this be the sort of thing that should be in Henry's sip devices spec? regards Keith -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: 12 June 2003 20:06 To: 'sipping@ietf.org' Subject: [Sipping] Call Waiting - who does the tone Robert If you have a UA that handles multiple calls, you don't need call waiting. Another INVITE appears, you show it in your UI (lights, LCD, whatever), and eventually the user decides to answer or ignore it. What if you are a really simple UA? A second call comes in. Who does what? It would seem that the really best answer is that the dumb UA puts the call waiting tone into the current audio. The user can then either hang up the current call and let the second call ring through, or it can press the "flash" button (if implemented), alternating between the two. It's all local. What doesn't seem to work at all is to let some "tones and announcements" server handle it - there is no way the dumb phone will create a media connection to such a server if it has an active call. That means call waiting CANNOT be implemented by any other element but the called UA. So, is this something that goes in a BCP? Even a dumb phone should handle call waiting. Brian _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jun 13 10:29:31 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 KAA07956 for ; Fri, 13 Jun 2003 10:29:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DET4E15473 for sipping-archive@odin.ietf.org; Fri, 13 Jun 2003 10:29:04 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DET4m15469 for ; Fri, 13 Jun 2003 10:29: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 KAA07945 for ; Fri, 13 Jun 2003 10:29:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QpW0-0005oq-00 for sipping-web-archive@ietf.org; Fri, 13 Jun 2003 10:26:52 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QpW0-0005on-00 for sipping-web-archive@ietf.org; Fri, 13 Jun 2003 10:26:52 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CIb3a14985; Thu, 12 Jun 2003 14:37:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CIaBm14879 for ; Thu, 12 Jun 2003 14:36: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 OAA22344 for ; Thu, 12 Jun 2003 14:36:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QWtd-0005Bn-00 for sipping@ietf.org; Thu, 12 Jun 2003 14:34:01 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19QWtd-0005B8-00 for sipping@ietf.org; Thu, 12 Jun 2003 14:34:01 -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 OAA25629; Thu, 12 Jun 2003 14:35:36 -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 OAA18641; Thu, 12 Jun 2003 14:35:36 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Jun 2003 14:35:32 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5ADF@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'seancolson@yahoo.com'" , hisham.khartabil@nokia.com, jason@azatel.com, rohan@cisco.com Cc: drage@lucent.com, jdrosen@dynamicsoft.com, alan.johnston@wcom.com, sipping@ietf.org Subject: RE: [Sipping] proposed enhancement to dialog package Date: Thu, 12 Jun 2003 14:35:27 -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: , Oh I think you only need a single indication. It's entirely up to the UA what it does when you are in the "passive" state. So, "yes" It does occur to me to wonder out loud over how this interacts with a passive participant in a conference. We definitely need that big time. Are they the same? I think not, primarily because a "passive" state in a call is still a call, where, most often, a passive participant in a conference call is more or less invisible. It may, however, suggest that "passive" may not be the best word choice for one or the other concepts. Brian > -----Original Message----- > From: Sean Olson [mailto:seancolson@yahoo.com] > Sent: Thursday, June 12, 2003 11:57 AM > To: 'Rosen, Brian'; hisham.khartabil@nokia.com; jason@azatel.com; > rohan@cisco.com > Cc: drage@lucent.com; jdrosen@dynamicsoft.com; alan.johnston@wcom.com; > sipping@ietf.org > Subject: RE: [Sipping] proposed enhancement to dialog package > > > For these different experiences at the UA, do you think you > need different > indications in the dialog package? > Is "passive" enough to cover the variety of possibilities > here? (My vote is > yes) > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Thursday, June 12, 2003 8:05 AM > To: 'hisham.khartabil@nokia.com'; jason@azatel.com; rohan@cisco.com; > seancolson@yahoo.com > Cc: drage@lucent.com; jdrosen@dynamicsoft.com; alan.johnston@wcom.com; > sipping@ietf.org > Subject: RE: [Sipping] proposed enhancement to dialog package > > > I've always thought that "music on hold" should be local i.e. > my choice of > music for me to listen to, not your choice of music for me to hear. > > Eliminates promotional material also :) > > Brian > > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Thursday, June 12, 2003 10:31 AM > > To: Brian.Rosen@marconi.com; jason@azatel.com; rohan@cisco.com; > > seancolson@yahoo.com > > Cc: drage@lucent.com; jdrosen@dynamicsoft.com; > alan.johnston@wcom.com; > > sipping@ietf.org > > Subject: RE: [Sipping] proposed enhancement to dialog package > > > > > > Your desire to hold audio may also be greater when you have > > to pay for audio packets being sent. It might be more > > interesting for the sender to hold the audio that for the receiver. > > > > Hisham > > > > > -----Original Message----- > > > From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: Thursday, June 12, 2003 4:16 PM > > > To: 'Jason Arnold'; Rohan Mahy; Sean Olson > > > Cc: Drage, Keith (Keith); 'Jonathan Rosenberg'; > > > alan.johnston@wcom.com; > > > sipping@ietf.org > > > Subject: RE: [Sipping] proposed enhancement to dialog package > > > > > > > > > May I add some interesting observational data? > > > We now have about a year experience with sip videophones that > > > implement hold. When you are on hold, you see a gray screen that > > > has text indicating the other party put you on hold. We deliver > > > silence on the audio channel. > > > > > > We have lots and lots of feature requests from users. No one has > > > ever asked for audio on hold. The visual information is > sufficient. > > > > > > I suspect that you don't need to be entertained, or > > pitched. You need > > > to know what is happening. If your UA tells you you are on hold, > > > then audio when you are on hold may not be important. > > > > > > One caveat; almost everyone uses our videophone handsfree. > > If you are > > > holding a handset to your ear, your desire for hold audio may be > > > greater. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Jason Arnold [mailto:jason@azatel.com] > > > > Sent: Wednesday, June 11, 2003 7:21 PM > > > > To: Rohan Mahy; Sean Olson > > > > Cc: Drage, Keith (Keith); 'Jonathan Rosenberg'; > > > > alan.johnston@wcom.com; > > > > sipping@ietf.org > > > > Subject: RE: [Sipping] proposed enhancement to dialog package > > > > > > > > > > > > I agree to an extent. > > > > > > > > If the hold presents "dead air", most people will feel lost > > > > with out some > > > > indication that they are on hold. It would seem that people > > > > require the > > > > assurance that the receiving party has not terminated their > > > > call. It could > > > > be assumed that if the hold period is for an extended period > > > > of time, only > > > > presenting silence to the calling party, people may think > > > > they have been > > > > accidentally "disconnected" and terminate their call. > > > > > > > > It is important to supply a media stream (even irritating > > > > propaganda) during > > > > the hold session. Non-Conformity to current expectations of > > > > people while on > > > > hold would seem illogical. > > > > > > > > Thanks, > > > > > > > > Jason > > > > > > > > On Wednesday, June 11, 2003, at 09:40 AM, Sean Olson wrote: > > > > > > > > > This is an interesting discussion in an almost > > > > > academic sense, but it really does not address the reality of > > > > > the very simple service that is being described here. > > > > > > > > > > "hold", "passive", whatever else you want to call it > means not > > > > > sending/receiving media. > > > > > > > > I disagree. > > > > > > > > If you call someone on the average PBX or Key System, and > > > ask them to > > > > put you on hold, you will typically still receive media > > > > (music, tones, > > > > irritating announcements). Likewise, if you call a call > > center or a > > > > big store, you are likely to wait "on hold" with some type of > > > > propaganda, music, or recorded message claiming that you are > > > > important. > > > > > > > > Clearly the user experience of the user-visible feature > > > "Hold" is that > > > > hold does not typically equate to "no media". > > > > > > > > I believe that from a feature perspective the existence or > > > presence of > > > > no media being sent/received is irrelevant. It does > not affect my > > > > perception that I am on hold, nor does it affect the > > > perception of my > > > > peer if I am on hold or not, since I can receive or not > > > receive media > > > > and still know that I am on hold. > > > > > > > > My assertion is that what users really want to know is if the > > > > other end > > > > is actively participating. Do they care if I am still > around? Is > > > > there the potential for interaction between me and my peer? > > > > > > > > With this concept, I can build useful features that users > > can relate > > > > to. For example, I would like "passive" participants > > (participants > > > > that cannot interact with me, like inane robots sending me > > > > Musak) to be > > > > automatically muted in my conference. > > > > > > > > I would like to express this property. If the name > > "passive" is too > > > > confusing, then feel free to suggest other terms. > > "interactivity" > > > > EQUAL ( "yes" / "no" ) ? > > > > > > > > thanks, > > > > -rohan > > > > > > > > > > > > > We've all > > > > > experienced this. And, yes, this can be independent of the > > > > > ability to do SIP signaling. > > > > > > > > > > I think we are focusing too much on signaling here and not > > > > > enough on the user experience that is being built. And I > > > > > certainly don't want a history lesson in ISDN signaling ;-) > > > > > > > > > > > > > > > --- "Drage, Keith (Keith)" wrote: > > > > >> See below > > > > >> > > > > >> regards > > > > >> > > > > >> Keith > > > > >> > > > > >> Keith Drage > > > > >> Lucent Technologies > > > > >> Tel: +44 1793 776249 > > > > >> Email: drage@lucent.com > > > > >> > > > > >>> -----Original Message----- > > > > >>> From: Rohan Mahy [mailto:rohan@cisco.com] > > > > >>> Sent: 10 June 2003 16:25 > > > > >>> To: Drage, Keith (Keith) > > > > >>> Cc: 'Jonathan Rosenberg'; alan.johnston@wcom.com; > > > > >> 'sipping@ietf.org' > > > > >>> Subject: Re: [Sipping] proposed enhancement to > > > > >> dialog package > > > > >>> > > > > >>> > > > > >>> Hi Keith, > > > > >>> > > > > >>> Hold as a UI concept significantly predated the > > > > >> development of ISDN. > > > > >> > > > > >> Agreed, and my initial message identified in that > > > > >> case (analogue PSTN terminals) that Hold was originally to > > > > >> recall the register (and there was a manual board > equivalent as > > > > >> well) to allow access resources to be used for > signalling, as a > > > > >> result of that signalling, the access resources might be used > > > > >> for communication with another party, and only as a > > > > >> by product of that did it necessarily result in loss > > > > >> of communication path with the other party. > > > > >> > > > > >>> In any case, an ISDN user (Alice) who requests an > > > > >> ISDN hold > > > > >>> is still a > > > > >>> passive participant by my definition. When > > > > >> Alice's call is connected > > > > >>> to a conference server and all the active > > > > >> participants say "ok, we're > > > > >>> leaving now, good bye", Alice is not active enough > > > > >> to be able to hang > > > > >>> up. > > > > >> > > > > >> Assuming your last statement still refers to an ISDN > user, then > > > > >> I can think of nothing in the above scenario that prevents > > > > >> Alice sending a DISCONNECT, and receiving a RELEASE > back. Can > > > > >> you clarify. The DSS1 basic call state machine is totally > > > > >> independent of any subsidiary state machine relating to > > > > >> hold/retrieve. > > > > >> > > > > >> If you are referring to hanging up the conference bridge > > > > >> resources, then this is dependent on the concept of > ownership, > > > > >> which varies based on the conference service > provided, and also > > > > >> between public and private networks. > > > > >> > > > > >> As a result, I think I am now confused about what > > > > >> you actually mean by passive, can you elaborate further. > > > > >> > > > > >> > > > > >>> > > > > >>> I agree that whatever we do, we need to describe > > > > >> the semantics very > > > > >>> crisply. > > > > >>> > > > > >>> thanks, > > > > >>> -rohan > > > > >>> > > > > >>> > > > > >>> On Tuesday, June 10, 2003, at 04:47 AM, Drage, > > > > >> Keith (Keith) wrote: > > > > >>> > > > > >>>> I fail to see how thw property you are proposing > > > > >> correlates in some > > > > >>>> way to any concept of hold. I agree that "hold" > > > > >> has many meanings, > > > > >>>> based on which type of signalling you are using. > > > > >>>> > > > > >>>> To clarify, the prime function of hold in the > > > > >> PSTN was never to > > > > >>>> interrupt the communication, that was a side > > > > >> effect of grabbing the > > > > >>>> access resources to signal to another party. > > > > >> Thus for ISDN, hold > > > > >>>> therefore was only a removal of access resources > > > > >> (the > > > > >>> bearer) so that > > > > >>>> that bearer could be reused for another call; > > > > >> again the side effect > > > > >>>> was to interrupt the communication. The sole > > > > >> function of > > > > >>> hold for SIP > > > > >>>> is to interrupt the communication. > > > > >>>> > > > > >>>> Certainly, if an ISDN user places another user > > > > >> on hold, I > > > > >>> would regard > > > > >>>> neither user as "passive" as you seem to be > > > > >> defining here. > > > > >>>> > > > > >>>> If we are going to do this, can we make sure we > > > > >> define the > > > > >>> semantics > > > > >>>> correctly. Otherwise we will surely create > > > > >> confusion, > > > > >>> particularly if > > > > >>>> people try and equate this concept with that of > > > > >> hold, and in > > > > >>>> particular with the PSTN concept. > > > > >>>> > > > > >>>> regards > > > > >>>> > > > > >>>> Keith > > > > >>>> > > > > >>>> > > > > >>>> Keith Drage > > > > >>>> Lucent Technologies > > > > >>>> Tel: +44 1793 776249 > > > > >>>> Email: drage@lucent.com > > > > >>>> > > > > >>>>> -----Original Message----- > > > > >>>>> From: Rohan Mahy [mailto:rohan@cisco.com] > > > > >>>>> Sent: 03 June 2003 22:18 > > > > >>>>> To: 'Jonathan Rosenberg' > > > > >>>>> Cc: rohan@cisco.com; alan.johnston@wcom.com; > > > > >> 'sipping@ietf.org' > > > > >>>>> Subject: [Sipping] proposed enhancement to > > > > >> dialog package > > > > >>>>> > > > > >>>>> > > > > >>>>> Hi, > > > > >>>>> > > > > >>>>> There have been many requests for the dialog > > > > >> package to express the > > > > >>>>> concept of hold. The problem is that nobody had > > > > >> an especially good > > > > >>>>> definition of what "on-hold" meant. Some > > > > >> suggested that all media > > > > >>>>> streams being inactive implied that you are > > > > >> "held", but > > > > >>> this doesn't > > > > >>>>> work for a service such as music-on-hold. > > > > >>>>> > > > > >>>>> I believe that folks actually want a slightly > > > > >> different > > > > >>> concept--that > > > > >>>>> the semantics we want instead are already > > > > >> described in the > > > > >>>>> call control > > > > >>>>> framework: > > > > >>>>> > > > > >>>>>> Participants may also be active or passive. > > > > >> Active > > > > >>> participants are > > > > >>>>>> expected to be intelligent enough to leave a > > > > >> conversation > > > > >>>>> space when > > > > >>>>>> they no longer desire to participate. (An > > > > >> attentive human > > > > >>>>> participant > > > > >>>>>> is obviously active.) Some robotic > > > > >> participants (such as a voice > > > > >>>>>> messaging system, an instant messaging agent, > > > > >> or a voice dialog > > > > >>>>>> system) may be active participants if they can > > > > >> leave the > > > > >>>>> conversation > > > > >>>>>> space when there is no human interaction. > > > > >> Other robots > > > > >>> (for example > > > > >>>>>> our tone generating robot from the previous > > > > >> example) are passive > > > > >>>>>> participants. A human participant "on-hold" is > > > > >> passive. > > > > >>>>> > > > > >>>>> I think we should add a new attribute to the > > > > >> dialog package that > > > > >>>>> expresses this property. My proposal is to > > > > >> express this > > > > >>> property only > > > > >>>>> for the local side of each dialog by adding an > > > > >> attribute > > > > >>> to the state > > > > >>>>> tag in the dialog-info notification body. The > > > > >> example below > > > > >>>>> includes a > > > > >>>>> proposed (optional) participation attribute in > > > > >> the state tag. > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > >> xmlns="urn:ietf:params:xml:ns:dialog-info" > > > > >>>>> version="3" > > > > >>>>> state="partial" > > > > >>>>> entity="sip:caller@bar.com"> > > > > >> > > > > > === message truncated === > > > > > > > > > > > > > > > __________________________________ > > > > > Do you Yahoo!? > > > > > Yahoo! Calendar - Free online calendar with sync to > Outlook(TM). > > > > > http://calendar.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 > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jun 13 10:53:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08709 for ; Fri, 13 Jun 2003 10:53:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DEqtr17560 for sipping-archive@odin.ietf.org; Fri, 13 Jun 2003 10:52:55 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DEqtm17557 for ; Fri, 13 Jun 2003 10:52: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 KAA08686 for ; Fri, 13 Jun 2003 10:52:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qpt5-0005y3-00 for sipping-web-archive@ietf.org; Fri, 13 Jun 2003 10:50:43 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Qpt5-0005y0-00 for sipping-web-archive@ietf.org; Fri, 13 Jun 2003 10:50:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D0c3a06445; Thu, 12 Jun 2003 20:38:03 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D0bDm05905 for ; Thu, 12 Jun 2003 20: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 UAA02894 for ; Thu, 12 Jun 2003 20:37:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QcX1-0007Oi-00 for sipping@ietf.org; Thu, 12 Jun 2003 20:35:03 -0400 Received: from web41510.mail.yahoo.com ([66.218.93.93]) by ietf-mx with smtp (Exim 4.12) id 19QcX0-0007Oe-00 for sipping@ietf.org; Thu, 12 Jun 2003 20:35:03 -0400 Message-ID: <20030613003640.52724.qmail@web41510.mail.yahoo.com> Received: from [131.107.3.84] by web41510.mail.yahoo.com via HTTP; Thu, 12 Jun 2003 17:36:40 PDT Date: Thu, 12 Jun 2003 17:36:40 -0700 (PDT) From: Sean Olson Subject: RE: [Sipping] proposed enhancement to dialog package To: "Rosen, Brian" , hisham.khartabil@nokia.com, jason@azatel.com, rohan@cisco.com Cc: drage@lucent.com, jdrosen@dynamicsoft.com, alan.johnston@wcom.com, sipping@ietf.org In-Reply-To: <313680C9A886D511A06000204840E1CF070B5ADF@whq-msgusr-02.pit.comms.marconi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Good point. Any suggestions for an alternative to "passive"? How about "disassociated"? ;-) --- "Rosen, Brian" wrote: > Oh I think you only need a single indication. It's > entirely up to > the UA what it does when you are in the "passive" > state. > > So, "yes" > > It does occur to me to wonder out loud over how this > interacts with > a passive participant in a conference. We > definitely need that big > time. Are they the same? I think not, primarily > because a "passive" > state in a call is still a call, where, most often, > a passive > participant in a conference call is more or less > invisible. > > It may, however, suggest that "passive" may not be > the best word choice > for one or the other concepts. > > Brian > > > -----Original Message----- > > From: Sean Olson [mailto:seancolson@yahoo.com] > > Sent: Thursday, June 12, 2003 11:57 AM > > To: 'Rosen, Brian'; hisham.khartabil@nokia.com; > jason@azatel.com; > > rohan@cisco.com > > Cc: drage@lucent.com; jdrosen@dynamicsoft.com; > alan.johnston@wcom.com; > > sipping@ietf.org > > Subject: RE: [Sipping] proposed enhancement to > dialog package > > > > > > For these different experiences at the UA, do you > think you > > need different > > indications in the dialog package? > > Is "passive" enough to cover the variety of > possibilities > > here? (My vote is > > yes) > > > > -----Original Message----- > > From: Rosen, Brian > [mailto:Brian.Rosen@marconi.com] > > Sent: Thursday, June 12, 2003 8:05 AM > > To: 'hisham.khartabil@nokia.com'; > jason@azatel.com; rohan@cisco.com; > > seancolson@yahoo.com > > Cc: drage@lucent.com; jdrosen@dynamicsoft.com; > alan.johnston@wcom.com; > > sipping@ietf.org > > Subject: RE: [Sipping] proposed enhancement to > dialog package > > > > > > I've always thought that "music on hold" should be > local i.e. > > my choice of > > music for me to listen to, not your choice of > music for me to hear. > > > > Eliminates promotional material also :) > > > > Brian > > > > > -----Original Message----- > > > From: hisham.khartabil@nokia.com > [mailto:hisham.khartabil@nokia.com] > > > Sent: Thursday, June 12, 2003 10:31 AM > > > To: Brian.Rosen@marconi.com; jason@azatel.com; > rohan@cisco.com; > > > seancolson@yahoo.com > > > Cc: drage@lucent.com; jdrosen@dynamicsoft.com; > > alan.johnston@wcom.com; > > > sipping@ietf.org > > > Subject: RE: [Sipping] proposed enhancement to > dialog package > > > > > > > > > Your desire to hold audio may also be greater > when you have > > > to pay for audio packets being sent. It might be > more > > > interesting for the sender to hold the audio > that for the receiver. > > > > > > Hisham > > > > > > > -----Original Message----- > > > > From: ext Rosen, Brian > [mailto:Brian.Rosen@marconi.com] > > > > Sent: Thursday, June 12, 2003 4:16 PM > > > > To: 'Jason Arnold'; Rohan Mahy; Sean Olson > > > > Cc: Drage, Keith (Keith); 'Jonathan > Rosenberg'; > > > > alan.johnston@wcom.com; > > > > sipping@ietf.org > > > > Subject: RE: [Sipping] proposed enhancement to > dialog package > > > > > > > > > > > > May I add some interesting observational data? > > > > We now have about a year experience with sip > videophones that > > > > implement hold. When you are on hold, you see > a gray screen that > > > > has text indicating the other party put you on > hold. We deliver > > > > silence on the audio channel. > > > > > > > > We have lots and lots of feature requests from > users. No one has > > > > ever asked for audio on hold. The visual > information is > > sufficient. > > > > > > > > I suspect that you don't need to be > entertained, or > > > pitched. You need > > > > to know what is happening. If your UA tells > you you are on hold, > > > > then audio when you are on hold may not be > important. > > > > > > > > One caveat; almost everyone uses our > videophone handsfree. > > > If you are > > > > holding a handset to your ear, your desire for > hold audio may be > > > > greater. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Jason Arnold [mailto:jason@azatel.com] > > > > > Sent: Wednesday, June 11, 2003 7:21 PM > > > > > To: Rohan Mahy; Sean Olson > > > > > Cc: Drage, Keith (Keith); 'Jonathan > Rosenberg'; > > > > > alan.johnston@wcom.com; > > > > > sipping@ietf.org > > > > > Subject: RE: [Sipping] proposed enhancement > to dialog package > > > > > > > > > > > > > > > I agree to an extent. > > > > > > > > > > If the hold presents "dead air", most people > will feel lost > > > > > with out some > > > > > indication that they are on hold. It would > seem that people > > > > > require the > > > > > assurance that the receiving party has not > terminated their > > > > > call. It could > > > > > be assumed that if the hold period is for an > extended period > > > > > of time, only > > > > > presenting silence to the calling party, > people may think > > > > > they have been > > > > > accidentally "disconnected" and terminate > their call. > > > > > > > > > > It is important to supply a media stream > (even irritating > > > > > propaganda) during > > > > > the hold session. Non-Conformity to current > expectations of > > > > > people while on > > > > > hold would seem illogical. > > > > > > > > > > Thanks, > > > > > > > > > > Jason > > > > > > > > > > On Wednesday, June 11, 2003, at 09:40 AM, > Sean Olson wrote: > > > > > > > > > > > This is an interesting discussion in an > almost > > > > > > academic sense, but it really does not > address the reality of > > > > > > the very simple service that is being > described here. > > > > > > > > > > > > "hold", "passive", whatever else you want > to call it > > means not > > > > > > sending/receiving media. > > > > > > > > > > I disagree. > > > > > > > > > > If you call someone on the average PBX or > Key System, and > === message truncated === __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.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 mailnull@www1.ietf.org Fri Jun 13 11:43:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10156 for ; Fri, 13 Jun 2003 11:43:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DFgZG22358 for sipping-archive@odin.ietf.org; Fri, 13 Jun 2003 11:42:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DFgZm22355 for ; Fri, 13 Jun 2003 11:42: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 LAA10148 for ; Fri, 13 Jun 2003 11:42:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QqfB-0006Ga-00 for sipping-web-archive@ietf.org; Fri, 13 Jun 2003 11:40:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QqfA-0006GX-00 for sipping-web-archive@ietf.org; Fri, 13 Jun 2003 11:40:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DBp3a01888; Fri, 13 Jun 2003 07:51:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DBojm01860 for ; Fri, 13 Jun 2003 07:50:45 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28960; Fri, 13 Jun 2003 07:50:43 -0400 (EDT) Message-Id: <200306131150.HAA28960@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, 13 Jun 2003 07:50:43 -0400 Subject: [Sipping] I-D ACTION:draft-anil-sipping-bla-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 : Implementing Bridged Line Appearances Using Session Initiation Protocol (SIP) Author(s) : A. Kumar, V. Venkataramanan Filename : draft-anil-sipping-bla-00.txt Pages : 12 Date : 2003-6-12 This document describes a proposal for implementing Bridged Line Appearance for SIP User Agents A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-anil-sipping-bla-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-anil-sipping-bla-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-anil-sipping-bla-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-12132215.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-anil-sipping-bla-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-anil-sipping-bla-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-12132215.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jun 13 12:54:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11884 for ; Fri, 13 Jun 2003 12:54:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DGsA629518 for sipping-archive@odin.ietf.org; Fri, 13 Jun 2003 12:54:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DGsAm29515 for ; Fri, 13 Jun 2003 12:54: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 MAA11810 for ; Fri, 13 Jun 2003 12:54:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QrmS-0006f9-00 for sipping-web-archive@ietf.org; Fri, 13 Jun 2003 12:52:00 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QrmR-0006f6-00 for sipping-web-archive@ietf.org; Fri, 13 Jun 2003 12:51:59 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DAl2a29976; Fri, 13 Jun 2003 06:47:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DAkOm29955 for ; Fri, 13 Jun 2003 06:46: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 GAA27890 for ; Fri, 13 Jun 2003 06:46:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qm2X-0003Yl-00 for sipping@ietf.org; Fri, 13 Jun 2003 06:44:13 -0400 Received: from smtp2.dataconnection.com ([192.91.191.8] helo=miles.dataconnection.com) by ietf-mx with esmtp (Exim 4.12) id 19Qm2X-0003Yd-00 for sipping@ietf.org; Fri, 13 Jun 2003 06:44:13 -0400 Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2656.59) id ; Fri, 13 Jun 2003 11:45:35 +0100 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F8B8E5A1@baker.datcon.co.uk> From: Nicole Johnson To: "'Rohan Mahy'" Cc: "'sipping@ietf.org'" Subject: RE: [Sipping] [Sipping]Questions on draft-ietf-sipping-connect-re use-reqs-00 Date: Fri, 13 Jun 2003 11:45:47 +0100 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: , Rohan, Thanks for these answers. A couple of comments below. Thanks, Nicole >-----Original Message----- >From: Rohan Mahy [mailto:rohan@cisco.com] >Sent: Saturday, June 07, 2003 1:48 AM >To: Nicole Johnson >Cc: 'sipping@ietf.org' >Subject: Re: [Sipping] [Sipping]Questions on >draft-ietf-sipping-connect-re use-reqs-00> > > >Hi Nicole, > > >On Thursday, May 22, 2003, at 05:12 AM, Nicole Johnson wrote: > >> Thanks for the clarification. >> >> I have two comments about the second security mechanism discussed in >> section >> 4.1 of this draft. >> >> 1. The draft states that, for a server to accept an alias, the target >> address of that alias must previously have been registered with the >> server. >> However, this mechanism is only as secure as the REGISTER itself. For >> example, if the REGISTER is not integrity-checked, a man-in-the-middle >> could >> alter the contact address in the REGISTER. > >the attack you describe is on the Registration function. The alias is >at least as secure as the registration policy of the registrar. > >> I think the draft should recommend that the REGISTER also be >> integrity-checked using S/MIME and a sipfrag bodypart containing the >> Contact. I would be happy to propose some text. Alternatively, if I >> have >> misunderstood the proposed mechanism, please let me know where I have >> gone >> wrong. > >Digest actually works fine here. Agreed, but I suggest that the second mechanism could be clarified by adding "If Digest authentication is used, integrity protection should be applied and the client should add a sipfrag bodypart containing the contact header." > >> 2. Target address fails to authenticate. >> >> If a server receives a request containing the alias parameter and the >> target >> address of the request fails authentication, how should the server >> react? > > it should not create the alias. > >> It could drop the message, respond to the target address with a "not >> authorized" response, or continue processing the request as if the >> "alias" >> parameter was not present. Is there a recommended behaviour? > > the behavior for handling the request should then do whatever normally > happens when a request without an alias parameter arrives with failed > or missing authentication. frequently this is fine and will result in > a digest authentication challenge (401 or 407). Following on from this, on receipt of the challenge response the client will send another request with an Authorization header. My concern is that even if the credentials in the Authorization header are OK the target address has still not been authenticated so the server will respond with another 401/407. In this case, wouldn't it be better for the server to respond to the original request with, for example, 403 Forbidden? Thanks, Nicole > > hope this makes sense. > > thanks, > -rohan > >> Thanks, >> Nicole >> >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jun 13 12:58:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12480 for ; Fri, 13 Jun 2003 12:58:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DGwG002509 for sipping-archive@odin.ietf.org; Fri, 13 Jun 2003 12:58:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DGwGm02506 for ; Fri, 13 Jun 2003 12:58: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 MAA12268 for ; Fri, 13 Jun 2003 12:58:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QrqP-0006l3-00 for sipping-web-archive@ietf.org; Fri, 13 Jun 2003 12:56:05 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QrqO-0006l0-00 for sipping-web-archive@ietf.org; Fri, 13 Jun 2003 12:56:04 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DES6a15438; Fri, 13 Jun 2003 10:28:06 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DERem15400 for ; Fri, 13 Jun 2003 10:27: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 KAA07892; Fri, 13 Jun 2003 10:27:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QpUf-0005o0-00; Fri, 13 Jun 2003 10:25:29 -0400 Received: from law12-f46.law12.hotmail.com ([64.4.19.46] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19QpUe-0005nl-00; Fri, 13 Jun 2003 10:25:28 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 13 Jun 2003 07:27:03 -0700 Received: from 193.220.224.9 by lw12fd.law12.hotmail.msn.com with HTTP; Fri, 13 Jun 2003 14:27:02 GMT X-Originating-IP: [193.220.224.9] X-Originating-Email: [rajarshi_chakraborty@hotmail.com] From: "Rajarshi Chakraborty" To: sip@ietf.org, sipping@ietf.org Date: Fri, 13 Jun 2003 14:27:02 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Jun 2003 14:27:03.0026 (UTC) FILETIME=[DBA44D20:01C331B7] Subject: [Sipping] Using SUBSCRIBE/NOTIFY in mobility Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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, This mail is kind of a follow-up to the earlier mail where I posted a couple of doubts regarding registration models in draft-schulzrinne-register-01. In the second design called "Outbound proxy intercept", could we not use SUBSCRIBE and NOTIFY between the mobile user agent and the outbound proxy server in the foriegn domain to indicate the former's departure from that domain into some other domain? And this would be followed by the local registrar unbinding the temporary canonical ID of the mobile host just upon receiving the NOTIFY, if it is co-located with the local proxy or the latter could send a de-register to the registrar if not co-located with it. According to this design the mobile host doesn't register with the foreign proxy/registrar. Hence I think SUBSCRIBE/NOTIFY would be of good use. The local proxy would SUBSCRIBE to the mobile user agent, and just before the latter departs it sends a NOTIFY back to the local proxy. Is this feasible? regards, Rajarshi Rajarshi Chakraborty B-196, IIT Campus, Kharagpur, West Bengal, India PIN-721302 _________________________________________________________________ Dress up your desktop! Get the best wallpapers. http://server1.msn.co.in/msnchannels/Entertainment/wallpaperhome.asp Just click here! _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jun 13 13:18:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13829 for ; Fri, 13 Jun 2003 13:18:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DHHbY19305 for sipping-archive@odin.ietf.org; Fri, 13 Jun 2003 13:17:37 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DHHbm19302 for ; Fri, 13 Jun 2003 13:17: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 NAA13707 for ; Fri, 13 Jun 2003 13:17:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qs98-00077U-00 for sipping-web-archive@ietf.org; Fri, 13 Jun 2003 13:15:26 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Qs97-00077R-00 for sipping-web-archive@ietf.org; Fri, 13 Jun 2003 13:15:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DHA6a12618; Fri, 13 Jun 2003 13:10:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DH9bm12330 for ; Fri, 13 Jun 2003 13:09: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 NAA13319; Fri, 13 Jun 2003 13:09:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qs1O-00070K-00; Fri, 13 Jun 2003 13:07:26 -0400 Received: from gateway.hns.com ([208.236.67.14]) by ietf-mx with esmtp (Exim 4.12) id 19Qs1N-00070F-00; Fri, 13 Jun 2003 13:07:25 -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 h5DH9Uaf027305; Fri, 13 Jun 2003 13:09:30 -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 h5DH9OsE024785; Fri, 13 Jun 2003 13:09:24 -0400 (EDT) To: sipping@ietf.org, sipping-admin@ietf.org Subject: Re: [Sipping] I-D ACTION:draft-anil-sipping-bla-00.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Arjun Roychowdhury" Date: Fri, 13 Jun 2003 13:09:22 -0400 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.12 |February 13, 2003) at 06/13/2003 01:07:27 PM, Serialize complete at 06/13/2003 01:07: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: , Quick comment: I would like to see a discussion on how potential race conflicts can be avoided. Since this draft proposes that endpoints essentially 'behave' themselves - ie before sending INVITE send NOTIFY, it is entirely possible that multiple INVITEs go out at the same time, each with different call-ids and other such race conditions. any thoughts on addressing the same wrt. called user experience :-) regds arjun -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301 212 7860 Internet-Drafts@ietf.org Sent by: sipping-admin@ietf.org 06/13/2003 07:50 AM Please respond to Internet-Drafts To: IETF-Announce: ; cc: sipping@ietf.org Subject: [Sipping] I-D ACTION:draft-anil-sipping-bla-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Implementing Bridged Line Appearances Using Session Initiation Protocol (SIP) Author(s) : A. Kumar, V. Venkataramanan Filename : draft-anil-sipping-bla-00.txt Pages : 12 Date : 2003-6-12 This document describes a proposal for implementing Bridged Line Appearance for SIP User Agents A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-anil-sipping-bla-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-anil-sipping-bla-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-anil-sipping-bla-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. ftp://anonymous@ftp.ietf.org/internet-drafts/draft-anil-sipping-bla-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 mailnull@www1.ietf.org Fri Jun 13 13:20:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14007 for ; Fri, 13 Jun 2003 13:20:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DHJsr17116 for sipping-archive@odin.ietf.org; Fri, 13 Jun 2003 13:19:54 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DHJsm17112 for ; Fri, 13 Jun 2003 13:19: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 NAA13931 for ; Fri, 13 Jun 2003 13:19:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QsBK-0007A5-00 for sipping-web-archive@ietf.org; Fri, 13 Jun 2003 13:17:42 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QsBK-0007A2-00 for sipping-web-archive@ietf.org; Fri, 13 Jun 2003 13:17:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DCp2a06754; Fri, 13 Jun 2003 08:51:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DCosm06738 for ; Fri, 13 Jun 2003 08:50: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 IAA00636 for ; Fri, 13 Jun 2003 08:50:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qnz2-0004Ar-00 for sipping@ietf.org; Fri, 13 Jun 2003 08:48:44 -0400 Received: from [202.62.76.42] (helo=gateway.blr.dlink.com) by ietf-mx with esmtp (Exim 4.12) id 19Qnyz-0004Ao-00 for sipping@ietf.org; Fri, 13 Jun 2003 08:48:42 -0400 Received: from userbvyungtdgz (localhost [127.0.0.1]) by gateway.blr.dlink.com (8.11.0/8.11.0) with SMTP id h5DCxMQ17126; Fri, 13 Jun 2003 18:29:22 +0530 Message-ID: <001401c331aa$d859a1e0$6064a8c0@userbvyungtdgz> From: "debanjan" To: "Umesh Sharma" , References: <20030613060118.78836.qmail@mail.com> Date: Fri, 13 Jun 2003 18:23:53 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C331D8.F1C803A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: [Sipping] Re: [Sip] Message Body format for INFO method carrying DTMF Digits Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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_0011_01C331D8.F1C803A0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ----------------------------------------- (on the network)---------------- email-body was scanned and no virus found email-body was scanned and no virus found -----------------------------------------D-Link R & D E-Mail Traffic----------- ------=_NextPart_000_0011_01C331D8.F1C803A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yeah, thanx for ur information. But actually I am working on a UAS = application which may not initiate any calls. But it can receive calls = from anywhere. So, I wanted to know what all standards( I found some = formats, but those are not widely used I guess) of message body parts = may come with the SIP INFO method. Also, if u have got a link to the = expired draft please send me ( I have checked up few links of the = drafts, but noe are working). Thanx. Regards Debanjan ----- Original Message -----=20 From: Umesh Sharma=20 To: debanjan ; sip@ietf.org ; sipping@ietf.org=20 Sent: Friday, June 13, 2003 11:31 AM Subject: Re: [Sip] Message Body format for INFO method carrying DTMF = Digits There is this draft "draft-choudhuri-sip-info-digit-00.txt" but it = seems it has expired & other one is "RFC 2833" on DTMF transmission.=20 Umesh ----- Original Message ----- From: "debanjan"=20 Date: Thu, 12 Jun 2003 19:05:25 +0530 To: ,=20 Subject: [Sip] Message Body format for INFO method carrying DTMF = Digits Hi, Anyone has any idea regarding what should be message body of SIP = Info method that carries the DTMF digits. Is there any standard RFC or = draft implementation. Any suggestions are welcome. Regards Debanjan =20 D-Link India Ltd Software and R & D Center --=20 _______________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com _______________________________________________ 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 ------=_NextPart_000_0011_01C331D8.F1C803A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Yeah, thanx for ur information. But = actually I am=20 working on a UAS application which may not initiate any calls. But it = can=20 receive calls from anywhere. So, I wanted to know what all standards( I = found=20 some formats, but those are not widely used I guess) of message body = parts may=20 come with the SIP INFO method. Also, if u have got a link to the expired = draft=20 please send me ( I have checked up few links of the drafts, but noe are=20 working).
Thanx.
 
Regards
Debanjan
----- Original Message -----
From:=20 Umesh=20 Sharma
Sent: Friday, June 13, 2003 = 11:31=20 AM
Subject: Re: [Sip] Message Body = format=20 for INFO method carrying DTMF Digits

There is this draft = "draft-choudhuri-sip-info-digit-00.txt"  but=20 it seems it has expired & other one is "RFC 2833"  on DTMF=20 transmission.

Umesh

----- Original Message -----
From: "debanjan"=20
Date: Thu, 12 Jun 2003 19:05:25 +0530
To: = ,
Subject: [Sip] Message Body = format for=20 INFO method carrying DTMF Digits

Hi,
    Anyone has any = idea regarding=20 what should be message body of SIP Info method that carries the DTMF = digits.=20 Is there any standard RFC or draft implementation.
    Any suggestions = are=20 welcome.
 
    = Regards
    = Debanjan
   
    D-Link India = Ltd
    Software and R = & D=20 Center
--=20 __________________________________= _____________=20 Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list = is for=20 NEW development of the core SIP Protocol Use = sip-implementors@cs.columbia.edu=20 for questions on current sip Use sipping@ietf.org for new developments = on the=20 application of sip ------=_NextPart_000_0011_01C331D8.F1C803A0-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jun 13 13:27:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14583 for ; Fri, 13 Jun 2003 13:27:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DHQaM13936 for sipping-archive@odin.ietf.org; Fri, 13 Jun 2003 13:26:36 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DHQam13933 for ; Fri, 13 Jun 2003 13:26: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 NAA14550 for ; Fri, 13 Jun 2003 13:26:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QsHo-0007Kc-00 for sipping-web-archive@ietf.org; Fri, 13 Jun 2003 13:24:24 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QsHo-0007KZ-00 for sipping-web-archive@ietf.org; Fri, 13 Jun 2003 13:24:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DEx2a17939; Fri, 13 Jun 2003 10:59:02 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DEwUm17910 for ; Fri, 13 Jun 2003 10:58: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 KAA08880 for ; Fri, 13 Jun 2003 10:58:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QpyU-00060l-00 for sipping@ietf.org; Fri, 13 Jun 2003 10:56:18 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19QpyT-00060i-00 for sipping@ietf.org; Fri, 13 Jun 2003 10:56:17 -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 h5DEvi3p020252; Fri, 13 Jun 2003 07:57:45 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIC26605; Fri, 13 Jun 2003 07:52:30 -0700 (PDT) Date: Fri, 13 Jun 2003 07:58:46 -0700 Subject: Re: [Sipping] proposed enhancement to dialog package Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'seancolson@yahoo.com'" , hisham.khartabil@nokia.com, jason@azatel.com, drage@lucent.com, jdrosen@dynamicsoft.com, alan.johnston@wcom.com, sipping@ietf.org To: "Rosen, Brian" From: Rohan Mahy In-Reply-To: <313680C9A886D511A06000204840E1CF070B5ADF@whq-msgusr-02.pit.comms.marconi.com> Message-Id: <88ACEC13-9DAF-11D7-A0EF-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, June 12, 2003, at 11:35 AM, Rosen, Brian wrote: > Oh I think you only need a single indication. It's entirely up to > the UA what it does when you are in the "passive" state. agreed > So, "yes" > > It does occur to me to wonder out loud over how this interacts with > a passive participant in a conference. We definitely need that big > time. Are they the same? I think not, primarily because a "passive" > state in a call is still a call, where, most often, a passive > participant in a conference call is more or less invisible. perhaps you mean a "hidden" participant? some of these hidden participants are actually active participants (conference leave/join bots or humans monitoring a conference silently) by my definition. i think the concepts are orthogonal, and both useful. thx, -r > It may, however, suggest that "passive" may not be the best word choice > for one or the other concepts. > > Brian > >> -----Original Message----- >> From: Sean Olson [mailto:seancolson@yahoo.com] >> Sent: Thursday, June 12, 2003 11:57 AM >> To: 'Rosen, Brian'; hisham.khartabil@nokia.com; jason@azatel.com; >> rohan@cisco.com >> Cc: drage@lucent.com; jdrosen@dynamicsoft.com; alan.johnston@wcom.com; >> sipping@ietf.org >> Subject: RE: [Sipping] proposed enhancement to dialog package >> >> >> For these different experiences at the UA, do you think you >> need different >> indications in the dialog package? >> Is "passive" enough to cover the variety of possibilities >> here? (My vote is >> yes) >> >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] >> Sent: Thursday, June 12, 2003 8:05 AM >> To: 'hisham.khartabil@nokia.com'; jason@azatel.com; rohan@cisco.com; >> seancolson@yahoo.com >> Cc: drage@lucent.com; jdrosen@dynamicsoft.com; alan.johnston@wcom.com; >> sipping@ietf.org >> Subject: RE: [Sipping] proposed enhancement to dialog package >> >> >> I've always thought that "music on hold" should be local i.e. >> my choice of >> music for me to listen to, not your choice of music for me to hear. >> >> Eliminates promotional material also :) >> >> Brian >> >>> -----Original Message----- >>> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>> Sent: Thursday, June 12, 2003 10:31 AM >>> To: Brian.Rosen@marconi.com; jason@azatel.com; rohan@cisco.com; >>> seancolson@yahoo.com >>> Cc: drage@lucent.com; jdrosen@dynamicsoft.com; >> alan.johnston@wcom.com; >>> sipping@ietf.org >>> Subject: RE: [Sipping] proposed enhancement to dialog package >>> >>> >>> Your desire to hold audio may also be greater when you have >>> to pay for audio packets being sent. It might be more >>> interesting for the sender to hold the audio that for the receiver. >>> >>> Hisham >>> >>>> -----Original Message----- >>>> From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] >>>> Sent: Thursday, June 12, 2003 4:16 PM >>>> To: 'Jason Arnold'; Rohan Mahy; Sean Olson >>>> Cc: Drage, Keith (Keith); 'Jonathan Rosenberg'; >>>> alan.johnston@wcom.com; >>>> sipping@ietf.org >>>> Subject: RE: [Sipping] proposed enhancement to dialog package >>>> >>>> >>>> May I add some interesting observational data? >>>> We now have about a year experience with sip videophones that >>>> implement hold. When you are on hold, you see a gray screen that >>>> has text indicating the other party put you on hold. We deliver >>>> silence on the audio channel. >>>> >>>> We have lots and lots of feature requests from users. No one has >>>> ever asked for audio on hold. The visual information is >> sufficient. >>>> >>>> I suspect that you don't need to be entertained, or >>> pitched. You need >>>> to know what is happening. If your UA tells you you are on hold, >>>> then audio when you are on hold may not be important. >>>> >>>> One caveat; almost everyone uses our videophone handsfree. >>> If you are >>>> holding a handset to your ear, your desire for hold audio may be >>>> greater. >>>> >>>> Brian >>>> >>>>> -----Original Message----- >>>>> From: Jason Arnold [mailto:jason@azatel.com] >>>>> Sent: Wednesday, June 11, 2003 7:21 PM >>>>> To: Rohan Mahy; Sean Olson >>>>> Cc: Drage, Keith (Keith); 'Jonathan Rosenberg'; >>>>> alan.johnston@wcom.com; >>>>> sipping@ietf.org >>>>> Subject: RE: [Sipping] proposed enhancement to dialog package >>>>> >>>>> >>>>> I agree to an extent. >>>>> >>>>> If the hold presents "dead air", most people will feel lost >>>>> with out some >>>>> indication that they are on hold. It would seem that people >>>>> require the >>>>> assurance that the receiving party has not terminated their >>>>> call. It could >>>>> be assumed that if the hold period is for an extended period >>>>> of time, only >>>>> presenting silence to the calling party, people may think >>>>> they have been >>>>> accidentally "disconnected" and terminate their call. >>>>> >>>>> It is important to supply a media stream (even irritating >>>>> propaganda) during >>>>> the hold session. Non-Conformity to current expectations of >>>>> people while on >>>>> hold would seem illogical. >>>>> >>>>> Thanks, >>>>> >>>>> Jason >>>>> >>>>> On Wednesday, June 11, 2003, at 09:40 AM, Sean Olson wrote: >>>>> >>>>>> This is an interesting discussion in an almost >>>>>> academic sense, but it really does not address the reality of >>>>>> the very simple service that is being described here. >>>>>> >>>>>> "hold", "passive", whatever else you want to call it >> means not >>>>>> sending/receiving media. >>>>> >>>>> I disagree. >>>>> >>>>> If you call someone on the average PBX or Key System, and >>>> ask them to >>>>> put you on hold, you will typically still receive media >>>>> (music, tones, >>>>> irritating announcements). Likewise, if you call a call >>> center or a >>>>> big store, you are likely to wait "on hold" with some type of >>>>> propaganda, music, or recorded message claiming that you are >>>>> important. >>>>> >>>>> Clearly the user experience of the user-visible feature >>>> "Hold" is that >>>>> hold does not typically equate to "no media". >>>>> >>>>> I believe that from a feature perspective the existence or >>>> presence of >>>>> no media being sent/received is irrelevant. It does >> not affect my >>>>> perception that I am on hold, nor does it affect the >>>> perception of my >>>>> peer if I am on hold or not, since I can receive or not >>>> receive media >>>>> and still know that I am on hold. >>>>> >>>>> My assertion is that what users really want to know is if the >>>>> other end >>>>> is actively participating. Do they care if I am still >> around? Is >>>>> there the potential for interaction between me and my peer? >>>>> >>>>> With this concept, I can build useful features that users >>> can relate >>>>> to. For example, I would like "passive" participants >>> (participants >>>>> that cannot interact with me, like inane robots sending me >>>>> Musak) to be >>>>> automatically muted in my conference. >>>>> >>>>> I would like to express this property. If the name >>> "passive" is too >>>>> confusing, then feel free to suggest other terms. >>> "interactivity" >>>>> EQUAL ( "yes" / "no" ) ? >>>>> >>>>> thanks, >>>>> -rohan >>>>> >>>>> >>>>>> We've all >>>>>> experienced this. And, yes, this can be independent of the >>>>>> ability to do SIP signaling. >>>>>> >>>>>> I think we are focusing too much on signaling here and not >>>>>> enough on the user experience that is being built. And I >>>>>> certainly don't want a history lesson in ISDN signaling ;-) >>>>>> >>>>>> >>>>>> --- "Drage, Keith (Keith)" wrote: >>>>>>> See below >>>>>>> >>>>>>> regards >>>>>>> >>>>>>> Keith >>>>>>> >>>>>>> Keith Drage >>>>>>> Lucent Technologies >>>>>>> Tel: +44 1793 776249 >>>>>>> Email: drage@lucent.com >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Rohan Mahy [mailto:rohan@cisco.com] >>>>>>>> Sent: 10 June 2003 16:25 >>>>>>>> To: Drage, Keith (Keith) >>>>>>>> Cc: 'Jonathan Rosenberg'; alan.johnston@wcom.com; >>>>>>> 'sipping@ietf.org' >>>>>>>> Subject: Re: [Sipping] proposed enhancement to >>>>>>> dialog package >>>>>>>> >>>>>>>> >>>>>>>> Hi Keith, >>>>>>>> >>>>>>>> Hold as a UI concept significantly predated the >>>>>>> development of ISDN. >>>>>>> >>>>>>> Agreed, and my initial message identified in that >>>>>>> case (analogue PSTN terminals) that Hold was originally to >>>>>>> recall the register (and there was a manual board >> equivalent as >>>>>>> well) to allow access resources to be used for >> signalling, as a >>>>>>> result of that signalling, the access resources might be used >>>>>>> for communication with another party, and only as a >>>>>>> by product of that did it necessarily result in loss >>>>>>> of communication path with the other party. >>>>>>> >>>>>>>> In any case, an ISDN user (Alice) who requests an >>>>>>> ISDN hold >>>>>>>> is still a >>>>>>>> passive participant by my definition. When >>>>>>> Alice's call is connected >>>>>>>> to a conference server and all the active >>>>>>> participants say "ok, we're >>>>>>>> leaving now, good bye", Alice is not active enough >>>>>>> to be able to hang >>>>>>>> up. >>>>>>> >>>>>>> Assuming your last statement still refers to an ISDN >> user, then >>>>>>> I can think of nothing in the above scenario that prevents >>>>>>> Alice sending a DISCONNECT, and receiving a RELEASE >> back. Can >>>>>>> you clarify. The DSS1 basic call state machine is totally >>>>>>> independent of any subsidiary state machine relating to >>>>>>> hold/retrieve. >>>>>>> >>>>>>> If you are referring to hanging up the conference bridge >>>>>>> resources, then this is dependent on the concept of >> ownership, >>>>>>> which varies based on the conference service >> provided, and also >>>>>>> between public and private networks. >>>>>>> >>>>>>> As a result, I think I am now confused about what >>>>>>> you actually mean by passive, can you elaborate further. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> I agree that whatever we do, we need to describe >>>>>>> the semantics very >>>>>>>> crisply. >>>>>>>> >>>>>>>> thanks, >>>>>>>> -rohan >>>>>>>> >>>>>>>> >>>>>>>> On Tuesday, June 10, 2003, at 04:47 AM, Drage, >>>>>>> Keith (Keith) wrote: >>>>>>>> >>>>>>>>> I fail to see how thw property you are proposing >>>>>>> correlates in some >>>>>>>>> way to any concept of hold. I agree that "hold" >>>>>>> has many meanings, >>>>>>>>> based on which type of signalling you are using. >>>>>>>>> >>>>>>>>> To clarify, the prime function of hold in the >>>>>>> PSTN was never to >>>>>>>>> interrupt the communication, that was a side >>>>>>> effect of grabbing the >>>>>>>>> access resources to signal to another party. >>>>>>> Thus for ISDN, hold >>>>>>>>> therefore was only a removal of access resources >>>>>>> (the >>>>>>>> bearer) so that >>>>>>>>> that bearer could be reused for another call; >>>>>>> again the side effect >>>>>>>>> was to interrupt the communication. The sole >>>>>>> function of >>>>>>>> hold for SIP >>>>>>>>> is to interrupt the communication. >>>>>>>>> >>>>>>>>> Certainly, if an ISDN user places another user >>>>>>> on hold, I >>>>>>>> would regard >>>>>>>>> neither user as "passive" as you seem to be >>>>>>> defining here. >>>>>>>>> >>>>>>>>> If we are going to do this, can we make sure we >>>>>>> define the >>>>>>>> semantics >>>>>>>>> correctly. Otherwise we will surely create >>>>>>> confusion, >>>>>>>> particularly if >>>>>>>>> people try and equate this concept with that of >>>>>>> hold, and in >>>>>>>>> particular with the PSTN concept. >>>>>>>>> >>>>>>>>> regards >>>>>>>>> >>>>>>>>> Keith >>>>>>>>> >>>>>>>>> >>>>>>>>> Keith Drage >>>>>>>>> Lucent Technologies >>>>>>>>> Tel: +44 1793 776249 >>>>>>>>> Email: drage@lucent.com >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Rohan Mahy [mailto:rohan@cisco.com] >>>>>>>>>> Sent: 03 June 2003 22:18 >>>>>>>>>> To: 'Jonathan Rosenberg' >>>>>>>>>> Cc: rohan@cisco.com; alan.johnston@wcom.com; >>>>>>> 'sipping@ietf.org' >>>>>>>>>> Subject: [Sipping] proposed enhancement to >>>>>>> dialog package >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> There have been many requests for the dialog >>>>>>> package to express the >>>>>>>>>> concept of hold. The problem is that nobody had >>>>>>> an especially good >>>>>>>>>> definition of what "on-hold" meant. Some >>>>>>> suggested that all media >>>>>>>>>> streams being inactive implied that you are >>>>>>> "held", but >>>>>>>> this doesn't >>>>>>>>>> work for a service such as music-on-hold. >>>>>>>>>> >>>>>>>>>> I believe that folks actually want a slightly >>>>>>> different >>>>>>>> concept--that >>>>>>>>>> the semantics we want instead are already >>>>>>> described in the >>>>>>>>>> call control >>>>>>>>>> framework: >>>>>>>>>> >>>>>>>>>>> Participants may also be active or passive. >>>>>>> Active >>>>>>>> participants are >>>>>>>>>>> expected to be intelligent enough to leave a >>>>>>> conversation >>>>>>>>>> space when >>>>>>>>>>> they no longer desire to participate. (An >>>>>>> attentive human >>>>>>>>>> participant >>>>>>>>>>> is obviously active.) Some robotic >>>>>>> participants (such as a voice >>>>>>>>>>> messaging system, an instant messaging agent, >>>>>>> or a voice dialog >>>>>>>>>>> system) may be active participants if they can >>>>>>> leave the >>>>>>>>>> conversation >>>>>>>>>>> space when there is no human interaction. >>>>>>> Other robots >>>>>>>> (for example >>>>>>>>>>> our tone generating robot from the previous >>>>>>> example) are passive >>>>>>>>>>> participants. A human participant "on-hold" is >>>>>>> passive. >>>>>>>>>> >>>>>>>>>> I think we should add a new attribute to the >>>>>>> dialog package that >>>>>>>>>> expresses this property. My proposal is to >>>>>>> express this >>>>>>>> property only >>>>>>>>>> for the local side of each dialog by adding an >>>>>>> attribute >>>>>>>> to the state >>>>>>>>>> tag in the dialog-info notification body. The >>>>>>> example below >>>>>>>>>> includes a >>>>>>>>>> proposed (optional) participation attribute in >>>>>>> the state tag. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> xmlns="urn:ietf:params:xml:ns:dialog-info" >>>>>>>>>> version="3" >>>>>>>>>> state="partial" >>>>>>>>>> entity="sip:caller@bar.com"> >>>>>>> >>>>>> === message truncated === >>>>>> >>>>>> >>>>>> __________________________________ >>>>>> Do you Yahoo!? >>>>>> Yahoo! Calendar - Free online calendar with sync to >> Outlook(TM). >>>>>> http://calendar.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 >>>> >>> _______________________________________________ >>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>> This list is for NEW development of the application of SIP >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sip@ietf.org for new developments of core SIP >>> >> > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Jun 13 13:27:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14643 for ; Fri, 13 Jun 2003 13:27:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DHRKE14748 for sipping-archive@odin.ietf.org; Fri, 13 Jun 2003 13:27:20 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DHRKm14745 for ; Fri, 13 Jun 2003 13: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 NAA14607 for ; Fri, 13 Jun 2003 13:27:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QsIX-0007Lu-00 for sipping-web-archive@ietf.org; Fri, 13 Jun 2003 13:25:09 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QsIW-0007Lr-00 for sipping-web-archive@ietf.org; Fri, 13 Jun 2003 13:25:08 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DEi2a17064; Fri, 13 Jun 2003 10:44:02 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DEhZm17043 for ; Fri, 13 Jun 2003 10:43: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 KAA08396 for ; Fri, 13 Jun 2003 10:43:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qpk4-0005to-00 for sipping@ietf.org; Fri, 13 Jun 2003 10:41:24 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19Qpk2-0005te-00 for sipping@ietf.org; Fri, 13 Jun 2003 10:41:23 -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 h5DEgjwe028952; Fri, 13 Jun 2003 07:42:49 -0700 (PDT) Received: from mhammer-w2k02.cisco.com (dhcp-hrn-64-100-229-133.cisco.com [64.100.229.133]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ADS80799; Fri, 13 Jun 2003 07:42:43 -0700 (PDT) Message-Id: <4.3.2.7.2.20030613104159.00b60790@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 13 Jun 2003 10:42:43 -0400 To: Sean Olson From: Michael Hammer Subject: RE: [Sipping] proposed enhancement to dialog package Cc: "Rosen, Brian" , hisham.khartabil@nokia.com, jason@azatel.com, rohan@cisco.com, drage@lucent.com, jdrosen@dynamicsoft.com, alan.johnston@wcom.com, sipping@ietf.org In-Reply-To: <20030613003640.52724.qmail@web41510.mail.yahoo.com> References: <313680C9A886D511A06000204840E1CF070B5ADF@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_4945931==_.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: , --=====================_4945931==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Or dormant? Mike At 05:36 PM 6/12/2003 -0700, Sean Olson wrote: >Good point. Any suggestions for an alternative to >"passive"? How about "disassociated"? ;-) > >--- "Rosen, Brian" wrote: > > Oh I think you only need a single indication. It's > > entirely up to > > the UA what it does when you are in the "passive" > > state. > > > > So, "yes" > > > > It does occur to me to wonder out loud over how this > > interacts with > > a passive participant in a conference. We > > definitely need that big > > time. Are they the same? I think not, primarily > > because a "passive" > > state in a call is still a call, where, most often, > > a passive > > participant in a conference call is more or less > > invisible. > > > > It may, however, suggest that "passive" may not be > > the best word choice > > for one or the other concepts. > > > > Brian > > > > > -----Original Message----- > > > From: Sean Olson [mailto:seancolson@yahoo.com] > > > Sent: Thursday, June 12, 2003 11:57 AM > > > To: 'Rosen, Brian'; hisham.khartabil@nokia.com; > > jason@azatel.com; > > > rohan@cisco.com > > > Cc: drage@lucent.com; jdrosen@dynamicsoft.com; > > alan.johnston@wcom.com; > > > sipping@ietf.org > > > Subject: RE: [Sipping] proposed enhancement to > > dialog package > > > > > > > > > For these different experiences at the UA, do you > > think you > > > need different > > > indications in the dialog package? > > > Is "passive" enough to cover the variety of > > possibilities > > > here? (My vote is > > > yes) > > > > > > -----Original Message----- > > > From: Rosen, Brian > > [mailto:Brian.Rosen@marconi.com] > > > Sent: Thursday, June 12, 2003 8:05 AM > > > To: 'hisham.khartabil@nokia.com'; > > jason@azatel.com; rohan@cisco.com; > > > seancolson@yahoo.com > > > Cc: drage@lucent.com; jdrosen@dynamicsoft.com; > > alan.johnston@wcom.com; > > > sipping@ietf.org > > > Subject: RE: [Sipping] proposed enhancement to > > dialog package > > > > > > > > > I've always thought that "music on hold" should be > > local i.e. > > > my choice of > > > music for me to listen to, not your choice of > > music for me to hear. > > > > > > Eliminates promotional material also :) > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: hisham.khartabil@nokia.com > > [mailto:hisham.khartabil@nokia.com] > > > > Sent: Thursday, June 12, 2003 10:31 AM > > > > To: Brian.Rosen@marconi.com; jason@azatel.com; > > rohan@cisco.com; > > > > seancolson@yahoo.com > > > > Cc: drage@lucent.com; jdrosen@dynamicsoft.com; > > > alan.johnston@wcom.com; > > > > sipping@ietf.org > > > > Subject: RE: [Sipping] proposed enhancement to > > dialog package > > > > > > > > > > > > Your desire to hold audio may also be greater > > when you have > > > > to pay for audio packets being sent. It might be > > more > > > > interesting for the sender to hold the audio > > that for the receiver. > > > > > > > > Hisham > > > > > > > > > -----Original Message----- > > > > > From: ext Rosen, Brian > > [mailto:Brian.Rosen@marconi.com] > > > > > Sent: Thursday, June 12, 2003 4:16 PM > > > > > To: 'Jason Arnold'; Rohan Mahy; Sean Olson > > > > > Cc: Drage, Keith (Keith); 'Jonathan > > Rosenberg'; > > > > > alan.johnston@wcom.com; > > > > > sipping@ietf.org > > > > > Subject: RE: [Sipping] proposed enhancement to > > dialog package > > > > > > > > > > > > > > > May I add some interesting observational data? > > > > > We now have about a year experience with sip > > videophones that > > > > > implement hold. When you are on hold, you see > > a gray screen that > > > > > has text indicating the other party put you on > > hold. We deliver > > > > > silence on the audio channel. > > > > > > > > > > We have lots and lots of feature requests from > > users. No one has > > > > > ever asked for audio on hold. The visual > > information is > > > sufficient. > > > > > > > > > > I suspect that you don't need to be > > entertained, or > > > > pitched. You need > > > > > to know what is happening. If your UA tells > > you you are on hold, > > > > > then audio when you are on hold may not be > > important. > > > > > > > > > > One caveat; almost everyone uses our > > videophone handsfree. > > > > If you are > > > > > holding a handset to your ear, your desire for > > hold audio may be > > > > > greater. > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Jason Arnold [mailto:jason@azatel.com] > > > > > > Sent: Wednesday, June 11, 2003 7:21 PM > > > > > > To: Rohan Mahy; Sean Olson > > > > > > Cc: Drage, Keith (Keith); 'Jonathan > > Rosenberg'; > > > > > > alan.johnston@wcom.com; > > > > > > sipping@ietf.org > > > > > > Subject: RE: [Sipping] proposed enhancement > > to dialog package > > > > > > > > > > > > > > > > > > I agree to an extent. > > > > > > > > > > > > If the hold presents "dead air", most people > > will feel lost > > > > > > with out some > > > > > > indication that they are on hold. It would > > seem that people > > > > > > require the > > > > > > assurance that the receiving party has not > > terminated their > > > > > > call. It could > > > > > > be assumed that if the hold period is for an > > extended period > > > > > > of time, only > > > > > > presenting silence to the calling party, > > people may think > > > > > > they have been > > > > > > accidentally "disconnected" and terminate > > their call. > > > > > > > > > > > > It is important to supply a media stream > > (even irritating > > > > > > propaganda) during > > > > > > the hold session. Non-Conformity to current > > expectations of > > > > > > people while on > > > > > > hold would seem illogical. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Jason > > > > > > > > > > > > On Wednesday, June 11, 2003, at 09:40 AM, > > Sean Olson wrote: > > > > > > > > > > > > > This is an interesting discussion in an > > almost > > > > > > > academic sense, but it really does not > > address the reality of > > > > > > > the very simple service that is being > > described here. > > > > > > > > > > > > > > "hold", "passive", whatever else you want > > to call it > > > means not > > > > > > > sending/receiving media. > > > > > > > > > > > > I disagree. > > > > > > > > > > > > If you call someone on the average PBX or > > Key System, and > > >=== message truncated === > > >__________________________________ >Do you Yahoo!? >Yahoo! Calendar - Free online calendar with sync to Outlook(TM). >http://calendar.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 --=====================_4945931==_.ALT Content-Type: text/html; charset="us-ascii" Or dormant?

Mike


At 05:36 PM 6/12/2003 -0700, Sean Olson wrote:
Good point. Any suggestions for an alternative to
"passive"? How about "disassociated"? ;-)

--- "Rosen, Brian" <Brian.Rosen@marconi.com> wrote:
> Oh I think you only need a single indication.  It's
> entirely up to
> the UA what it does when you are in the "passive"
> state.
>
> So, "yes"
>
> It does occur to me to wonder out loud over how this
> interacts with
> a passive participant in a conference.  We
> definitely need that big
> time.  Are they the same?  I think not, primarily
> because a "passive"
> state in a call is still a call, where, most often,
> a passive
> participant in a conference call is more or less
> invisible.
>
> It may, however, suggest that "passive" may not be
> the best word choice
> for one or the other concepts.
>
> Brian
>
> > -----Original Message-----
> > From: Sean Olson [mailto:seancolson@yahoo.com]
> > Sent: Thursday, June 12, 2003 11:57 AM
> > To: 'Rosen, Brian'; hisham.khartabil@nokia.com;
> jason@azatel.com;
> > rohan@cisco.com
> > Cc: drage@lucent.com; jdrosen@dynamicsoft.com;
> alan.johnston@wcom.com;
> > sipping@ietf.org
> > Subject: RE: [Sipping] proposed enhancement to
> dialog package
> >
> >
> > For these different experiences at the UA, do you
> think you
> > need different
> > indications in the dialog package?
> > Is "passive" enough to cover the variety of
> possibilities
> > here? (My vote is
> > yes)
> >
> > -----Original Message-----
> > From: Rosen, Brian
> [mailto:Brian.Rosen@marconi.com]
> > Sent: Thursday, June 12, 2003 8:05 AM
> > To: 'hisham.khartabil@nokia.com';
> jason@azatel.com; rohan@cisco.com;
> > seancolson@yahoo.com
> > Cc: drage@lucent.com; jdrosen@dynamicsoft.com;
> alan.johnston@wcom.com;
> > sipping@ietf.org
> > Subject: RE: [Sipping] proposed enhancement to
> dialog package
> >
> >
> > I've always thought that "music on hold" should be
> local i.e.
> > my choice of
> > music for me to listen to, not your choice of
> music for me to hear.
> >
> > Eliminates promotional material also :)
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: hisham.khartabil@nokia.com
> [mailto:hisham.khartabil@nokia.com]
> > > Sent: Thursday, June 12, 2003 10:31 AM
> > > To: Brian.Rosen@marconi.com; jason@azatel.com;
> rohan@cisco.com;
> > > seancolson@yahoo.com
> > > Cc: drage@lucent.com; jdrosen@dynamicsoft.com;
> > alan.johnston@wcom.com;
> > > sipping@ietf.org
> > > Subject: RE: [Sipping] proposed enhancement to
> dialog package
> > >
> > >
> > > Your desire to hold audio may also be greater
> when you have
> > > to pay for audio packets being sent. It might be
> more
> > > interesting for the sender to hold the audio
> that for the receiver.
> > >
> > > Hisham
> > >
> > > > -----Original Message-----
> > > > From: ext Rosen, Brian
> [mailto:Brian.Rosen@marconi.com]
> > > > Sent: Thursday, June 12, 2003 4:16 PM
> > > > To: 'Jason Arnold'; Rohan Mahy; Sean Olson
> > > > Cc: Drage, Keith (Keith); 'Jonathan
> Rosenberg';
> > > > alan.johnston@wcom.com;
> > > > sipping@ietf.org
> > > > Subject: RE: [Sipping] proposed enhancement to
> dialog package
> > > >
> > > >
> > > > May I add some interesting observational data?
> > > > We now have about a year experience with sip
> videophones that
> > > > implement hold.  When you are on hold, you see
> a gray screen that
> > > > has text indicating the other party put you on
> hold.  We deliver
> > > > silence on the audio channel.
> > > >
> > > > We have lots and lots of feature requests from
> users.  No one has
> > > > ever asked for audio on hold.  The visual
> information is
> > sufficient.
> > > >
> > > > I suspect that you don't need to be
> entertained, or
> > > pitched.  You need
> > > > to know what is happening.  If your UA tells
> you you are on hold,
> > > > then audio when you are on hold may not be
> important.
> > > >
> > > > One caveat; almost everyone uses our
> videophone handsfree.
> > > If you are
> > > > holding a handset to your ear, your desire for
> hold audio may be
> > > > greater.
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Jason Arnold [mailto:jason@azatel.com]
> > > > > Sent: Wednesday, June 11, 2003 7:21 PM
> > > > > To: Rohan Mahy; Sean Olson
> > > > > Cc: Drage, Keith (Keith); 'Jonathan
> Rosenberg';
> > > > > alan.johnston@wcom.com;
> > > > > sipping@ietf.org
> > > > > Subject: RE: [Sipping] proposed enhancement
> to dialog package
> > > > >
> > > > >
> > > > > I agree to an extent.
> > > > >
> > > > > If the hold presents "dead air", most people
> will feel lost
> > > > > with out some
> > > > > indication that they are on hold.  It would
> seem that people
> > > > > require the
> > > > > assurance that the receiving party has not
> terminated their
> > > > > call.  It could
> > > > > be assumed that if the hold period is for an
> extended period
> > > > > of time, only
> > > > > presenting silence to the calling party,
> people may think
> > > > > they have been
> > > > > accidentally "disconnected" and terminate
> their call.
> > > > >
> > > > > It is important to supply a media stream
> (even irritating
> > > > > propaganda) during
> > > > > the hold session.  Non-Conformity to current
> expectations of
> > > > > people while on
> > > > > hold would seem illogical.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Jason
> > > > >
> > > > > On Wednesday, June 11, 2003, at 09:40 AM,
> Sean Olson wrote:
> > > > >
> > > > > > This is an interesting discussion in an
> almost
> > > > > > academic sense, but it really does not
> address the reality of
> > > > > > the very simple service that is being
> described here.
> > > > > >
> > > > > > "hold", "passive", whatever else you want
> to call it
> > means not
> > > > > > sending/receiving media.
> > > > >
> > > > > I disagree.
> > > > >
> > > > > If you call someone on the average PBX or
> Key System, and
>
=== message truncated ===


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.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
--=====================_4945931==_.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 mailnull@www1.ietf.org Fri Jun 13 14:46:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18162 for ; Fri, 13 Jun 2003 14:46:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DIkFj10799 for sipping-archive@odin.ietf.org; Fri, 13 Jun 2003 14:46:15 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DIkFm10796 for ; Fri, 13 Jun 2003 14: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 OAA18121 for ; Fri, 13 Jun 2003 14:46:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QtWt-0000OX-00 for sipping-web-archive@ietf.org; Fri, 13 Jun 2003 14:44:03 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QtWs-0000OU-00 for sipping-web-archive@ietf.org; Fri, 13 Jun 2003 14:44:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DIL4a20432; Fri, 13 Jun 2003 14:21:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DIKum20387 for ; Fri, 13 Jun 2003 14:20: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 OAA16679 for ; Fri, 13 Jun 2003 14:20:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qt8P-00008b-00 for sipping@ietf.org; Fri, 13 Jun 2003 14:18:45 -0400 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by ietf-mx with esmtp (Exim 4.12) id 19Qt8O-00008P-00 for sipping@ietf.org; Fri, 13 Jun 2003 14:18:44 -0400 Received: from dgismtp06.wcomnet.com ([166.38.58.89]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HGF00C99MU08B@firewall.wcom.com> for sipping@ietf.org; Fri, 13 Jun 2003 18:18:00 +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 <0HGF00M01MTZBU@dgismtp06.wcomnet.com>; Fri, 13 Jun 2003 18:18:00 +0000 (GMT) Received: from hsinnreich2 ([166.35.136.36]) by dgismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HGF00K65MTY2H@dgismtp06.wcomnet.com>; Fri, 13 Jun 2003 18:18:00 +0000 (GMT) Date: Fri, 13 Jun 2003 13:17:57 -0500 From: Henry Sinnreich Subject: RE: [Sipforum-discussion] RE: [Sipping] Text support in SIP phones In-reply-to: To: "=?iso-8859-1?Q?'Gunnar_Hellstr=F6m'?=" , "'Henry Sinnreich'" , "'Sipping@Ietf. Org'" , "'Sipforum-Discussion@Lists. Su. Se'" , "'Drage, Keith (Keith)'" Message-id: <000101c331d8$1e98c050$248823a6@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 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5DIKvm20388 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h5DIL4a20432 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5DIkFm10796 Content-Transfer-Encoding: 8bit > I want to have your advice if you want to see also SDP > examples for the text channel in the sipdev spec, in a > separate Text Conversation Best Code of Practice spec, or if > there is any plan for a sipdev-technical guideline spec where > it could fit. I believe a short I-D with SDP examples for the text channel would very productive and could serve as reference for the SIP Telephony Device I-D and other. Thanks, Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of Gunnar Hellström > Sent: Wednesday, June 11, 2003 4:40 PM > To: Henry Sinnreich; 'Sipping@Ietf. Org'; > 'Sipforum-Discussion@Lists. Su. Se'; 'Drage, Keith (Keith)' > Subject: SV: [Sipforum-discussion] RE: [Sipping] Text support > in SIP phones > > > OK, I think it would be fine to bring the introduction of > real time text conversation up for discussion in the SIPPING group. > > I think that the small requirement statements we have > discussed so far for the sipdev specification are sufficient > for that level. > > But I have noticed some uncertainty from developers on what > SDP to use to open the RFC2793 text channel, and about some > other good implementation habits around the text channel. We > need to be sure that there is good agreement on such issues, > so that we get maximum harmonization and interoperability > between implementations. ( real time text conversation in the > PSTN has a terrible history of fragmentation and > incompatibility, and it is time to make sure that is history now ) > > I want to have your advice if you want to see also SDP > examples for the text channel in the sipdev spec, in a > separate Text Conversation Best Code of Practice spec, or if > there is any plan for a sipdev-technical guideline spec where > it could fit. > > > Gunnar > > ------------------------------------------- > Gunnar Hellström, Omnitor, Renathvägen 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ån: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com] > > Skickat: den 11 juni 2003 11:59 > > Till: 'Gunnar Hellström'; 'Sipping@Ietf. Org'; > > 'Sipforum-Discussion@Lists. Su. Se'; 'Drage, Keith (Keith)' > > Ämne: RE: [Sipforum-discussion] RE: [Sipping] Text support in SIP > > phones > > > > > > Gunnar, thanks for bringing this up! I believe now we can ask for > > discussion time at the SIPPING WG meeting. > > > > Henry > > > > > -----Original Message----- > > > From: sipforum-discussion-admin@lists.su.se > > > [mailto:sipforum-discussion-admin@lists.su.se] On Behalf > Of Gunnar > > > Hellström > > > Sent: Tuesday, June 10, 2003 2:42 PM > > > To: Henry Sinnreich; 'Drage, Keith (Keith)'; 'Sipping@Ietf. Org'; > > > 'Sipforum-Discussion@Lists. Su. Se' > > > Subject: SV: [Sipforum-discussion] RE: [Sipping] Text > support in SIP > > > phones > > > > > > > > > I agree that this discussion starts to get balance into the > > > specification of the real time text conversation feature. > > > > > > Firstly, I have discovered that I need to explain again > that what we > > > talk about is a real time, character by character > transmission and > > > display of text. You can see the thought as it is growing > and being > > > formed into text. It is a very direct way to have > contact, and once > > > you have used it, you realize that in some applications it is > > > essential to have access to this feature. It has the same > immediate > > > flow as audio in voice telephony and video in video telephony. > > > > > > In fact, there is a name for the three media together, it > is called > > > Total Conversation. > > > > > > It is true that the force behind defining it has come > from the needs > > > of people with communication related disabilities. But I am sure > > > that once commonly implemented, it will become a natural > and popular > > > feature that is often used during voice calls between most users. > > > > > > Instant messaging is also a very handy service. But it > goes message > > > by message, and therefore does not have the direct touch > as the real > > > time conversational service in voice, text and video has. > > > > > > > > > > > > We have a forerunner in the specification of media for > the SIP based > > > IP Multimedia phone in 3GPP. Maybe we can pick the same style of > > > specification. In 3GPP TS 26.235, "Packet switched conversational > > > multimedia applications, default codecs", it is specified > among the > > > enumeration of supported media: > > > > > > 6.3 Real time text > > > 3G PS multimedia terminals offering real time text conversation > > > should support ITU-T Recommendation T.140 [25] Text Conversation > > > presentation coding. > > > > > > And in the chapter on RTP payload, it is specified: > > > > > > 9.2 RTP payload > > > RTP payload formats specified by IETF shall be used for real time > > > media streams. RTP payload format for the AMR narrowband speech > > > codec is specified in annex B. RTP payload format for the AMR > > > wideband speech codec is specified in annex B. RTP payload format > > > for the ITU-T Recommendation H.263 [6] video codec is > specified in > > > IETF RFC 2429 [3]. RTP payload format for the MPEG-4 > visual simple > > > profile level 0 is specified in IETF RFC 3016 [5]. RTP payload > > > format for the ITU-T Recommendation T.140 [25] text conversation > > > coding is specified in IETF RFC 2793 [24]. > > > > > > In the annex A on specific details, the following is > specified for > > > text: > > > > > > A.3 Text > > > Use of the redundancy coding variant specified in RFC > 2793 [24] is > > > recommended for error resilience. > > > > > > -------------------------------- > > > When this topic was handled in 3GPP, there was opposition against > > > mentioning the reason for introducing the text feature as being > > > something specific for disabled people. > > > > > > I think that is still valid. > > > > > > I suggest that the following formulation is used: > > > ************************************************************** > > > ************** > > > ************************************** > > > SIP-zz, digital text support: SIP telephone devices > SHOULD support > > > real time text conversation. If text is supported, it > MUST support > > > RFC2793 [y], for text coding and packetization, and it MUST be > > > possible to use text simultaneously with voice. > > > ************************************************************** > > > ************** > > > ************************************** > > > > > > > > > Gunnar > > > ------------------------------------------- > > > Gunnar Hellström, Omnitor, Renathvägen 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ån: sipforum-discussion-admin@lists.su.se > > > > [mailto:sipforum-discussion-admin@lists.su.se]För Henry > Sinnreich > > > > Skickat: den 10 juni 2003 18:02 > > > > Till: 'Drage, Keith (Keith)'; 'Henry Sinnreich'; 'Gunnar > > > Hellström'; > > > > 'Sipping@Ietf. Org'; 'Sipforum-Discussion@Lists. Su. Se' > > > > Ämne: [Sipforum-discussion] RE: [Sipping] Text support in SIP > > > > phones > > > > > > > > > > > > Keith, thanks for bringing balance, I believe, to this > discussion. > > > > > > > > We could formulate soemthing like "SIP phones that have a > > > text display > > > > and advertised as supporting the hearing or speech disabled > > > > MUST..." > > > > > > > > Would this be OK? > > > > > > > > Henry > > > > > > > > > -----Original Message----- > > > > > From: sipping-admin@ietf.org > [mailto:sipping-admin@ietf.org] On > > > > > Behalf Of Drage, Keith (Keith) > > > > > Sent: Tuesday, June 10, 2003 8:14 AM > > > > > To: 'Henry Sinnreich'; 'Gunnar Hellström'; > 'Sipping@Ietf. Org'; > > > > > 'Sipforum-Discussion@Lists. Su. Se' > > > > > Subject: RE: [Sipping] Text support in SIP phones > > > > > > > > > > > > > > > I would suggest that treating these sort of things as > > > MUST strength > > > > > is best left to national regulatory requirements, along > > > with other > > > > > things like fitness for purpose and so on. I have no > objection > > > > > to their being mentioned. By the way, I understood > this document > > > > > was being progressed as authors individual submission, and > > > was therefore > > > > > not standards track. > > > > > > > > > > Any such MUST would surely need to be qualified > anyway. If the > > > > > purpose of the devise is such that it renders a > textual devise > > > > > irrelevant, then why require one to be fitted. > Suppose we were > > > > > designing a SIP phone for the totally blind, and this was > > > designed > > > > > to be worn as a headset, a text device would be > > > irrelevant to such a > > > > > user, and positioning such a device where it could be > seen would > > > > > require an extra box hanging out of the side of the product. > > > > > > > > > > regards > > > > > > > > > > Keith > > > > > > > > > > Keith Drage > > > > > Lucent Technologies > > > > > Tel: +44 1793 776249 > > > > > Email: drage@lucent.com > > > > > > > > > > > -----Original Message----- > > > > > > From: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com] > > > > > > Sent: 27 May 2003 17:18 > > > > > > To: 'Gunnar Hellström'; 'Sipping@Ietf. Org'; > > > > > > 'Sipforum-Discussion@Lists. Su. Se' > > > > > > Cc: 'Henry Sinnreich' > > > > > > Subject: RE: [Sipping] Text support in SIP phones > > > > > > > > > > > > > > > > > > Gunnar, this all seems very reasonable, and I will try > > > to insert > > > > > > it properly. > > > > > > > > > > > > Henry > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: sipping-admin@ietf.org > > > [mailto:sipping-admin@ietf.org] On > > > > > > > Behalf Of Gunnar Hellström > > > > > > > Sent: Thursday, May 22, 2003 6:54 PM > > > > > > > To: 'Sipping@Ietf. Org'; Sipforum-Discussion@Lists. Su. Se > > > > > > > Cc: Henry Sinnreich > > > > > > > Subject: [Sipping] Text support in SIP phones > > > > > > > > > > > > > > > > > > > > > Sorry, I missed out the reference to the SIP device > > > > > > > specification. > > > > > > > > > > > > > > Henry and all, > > > > > > > > > > > > > > Some time ago, I suggested addition of support > for real time > > > > > > > text communication to the SIP device specification > > > > > > > > > > > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-00.tx > > > > > t > > > > > > > > > > > > > > This was the simple part of the proposal: > > > > > > > > > > > > > > > SIP-zz, digital text support: SIP telephone devices > > > MUST support > > > > > > > > real time text conversation using RFC 2793 [y] for the > > > > > > > text stream. > > > > > > > > It MUST be possible to use text simultaneously with > > > > > > > > voice. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------- > > > > > > > > In 4.11 Ringer Behaviour : add the section > below for the > > > > > > > purpose of > > > > > > > > deaf, hearing impaired, deaf-blind people and people in > > > > > > > > the > > > > > > > garden and > > > > > > > > noisy > > > > > > > > locations: > > > > > > > > > > > > > > > > SIP Telephony devices MUST provide an external > > > interface to an > > > > > > > > external alerting system. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Add to References > > > > > > > > ----------------- > > > > > > > > [y] G. Hellstrom: "RTP Payload for Text Conversation.", > > > > > RFC 2793, > > > > > > > > IETF, May 2000. > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > > > > > > > > > > The reception of this proposal was very positive. Now, I > > > > > > > would like to see the final formulation, and > > > check that > > > > > > > we agree on it. > > > > > > > > > > > > > > I regard this requirement to be very light. In > the Interface > > > > > > > section ( e.g. > > > > > > > Int-2) , there is already mentioning of mandatory > text input > > > > > > > mechanisms, and assumptions that a display would > be normal, > > > > > > > since handling of phone books and buddy lists are > > > mandatory. To > > > > > > > re-use these text interface devices during the call for > > > > > > > standardised text conversation purposes seems > > > > > > > straightforward. > > > > > > > > > > > > > > It could be wise to add the T.140 text presentation > > > protocol as > > > > > > > a codec to the codec section. The normal SDP used > > > together with > > > > > > > RFC2793 for text could also be specified. Do you want > > > > > > to do that? > > > > > > > > > > > > > > > > > > > > > ----- > > > > > > > > > > > > > > We also need to check the ideas around the other proposed > > > > > > > requirements: The requirement to include text > > > telephone modem in > > > > > > > all designs where an RJ11 phone connector exists, and the > > > > > > > requirement to support RFC 3351. I suggest that we start > > > > > > > with the straightforward and mainstream > requirement above. > > > > > > > Is that accepted as it is? > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > Gunnar > > > > > > > ------------------------------------------- > > > > > > > Gunnar Hellström, Omnitor, Renathvägen 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/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/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 From mailnull@www1.ietf.org Sat Jun 14 02:13:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18983 for ; Sat, 14 Jun 2003 02:13:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5E6DGe05776 for sipping-archive@odin.ietf.org; Sat, 14 Jun 2003 02:13:16 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E6DFm05767 for ; Sat, 14 Jun 2003 02:13:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18935 for ; Sat, 14 Jun 2003 02:13:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19R4Fi-0004a5-00 for sipping-web-archive@ietf.org; Sat, 14 Jun 2003 02:11:02 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19R4Fh-0004a1-00 for sipping-web-archive@ietf.org; Sat, 14 Jun 2003 02:11:01 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DJN2a01667; Fri, 13 Jun 2003 15:23:02 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DJMCm01395 for ; Fri, 13 Jun 2003 15: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 PAA20518 for ; Fri, 13 Jun 2003 15:22:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qu5h-0000et-00 for sipping@ietf.org; Fri, 13 Jun 2003 15:20:01 -0400 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by ietf-mx with esmtp (Exim 4.12) id 19Qu5h-0000ea-00 for sipping@ietf.org; Fri, 13 Jun 2003 15:20:01 -0400 Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HGF00NBMPOJ1L@firewall.wcom.com> for sipping@ietf.org; Fri, 13 Jun 2003 19:19:31 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HGF00E01PL6YG@dgismtp03.wcomnet.com>; Fri, 13 Jun 2003 19:19:31 +0000 (GMT) Received: from hsinnreich2 ([166.35.136.36]) by dgismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HGF00D8ZPNMYW@dgismtp03.wcomnet.com>; Fri, 13 Jun 2003 19:19:01 +0000 (GMT) Date: Fri, 13 Jun 2003 14:18:58 -0500 From: Henry Sinnreich Subject: RE: [Sipforum-discussion] RE: [Sipping] Text support in SIP phones In-reply-to: To: "=?iso-8859-1?Q?'Gunnar_Hellstr=F6m'?=" , "'Henry Sinnreich'" , "'Drage, Keith (Keith)'" , "'Sipping@Ietf. Org'" , "'Sipforum-Discussion@Lists. Su. Se'" Message-id: <000901c331e0$a527cc30$248823a6@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 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5DJMCm01399 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h5DJN2a01667 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5E6DFm05767 Content-Transfer-Encoding: 8bit > 6.3 Real time text > 3G PS multimedia terminals offering real time text > conversation should support ITU-T Recommendation T.140 [25] > Text Conversation presentation coding. This is a very usefyl reference! It does not say "ALL" or "MUST", but "terminals offering real time text conversation should support ITU-T Recommendation T.140". I guess in IETF language the "should" would be "SHOULD". Thanks, Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of Gunnar Hellström > Sent: Tuesday, June 10, 2003 2:42 PM > To: Henry Sinnreich; 'Drage, Keith (Keith)'; 'Sipping@Ietf. > Org'; 'Sipforum-Discussion@Lists. Su. Se' > Subject: SV: [Sipforum-discussion] RE: [Sipping] Text support > in SIP phones > > > I agree that this discussion starts to get balance into the > specification of the real time text conversation feature. > > Firstly, I have discovered that I need to explain again that > what we talk about is a real time, character by character > transmission and display of text. You can see the thought as > it is growing and being formed into text. It is a very direct > way to have contact, and once you have used it, you realize > that in some applications it is essential to have access to > this feature. It has the same immediate flow as audio in > voice telephony and video in video telephony. > > In fact, there is a name for the three media together, it is > called Total Conversation. > > It is true that the force behind defining it has come from > the needs of people with communication related disabilities. > But I am sure that once commonly implemented, it will become > a natural and popular feature that is often used during voice > calls between most users. > > Instant messaging is also a very handy service. But it goes > message by message, and therefore does not have the direct > touch as the real time conversational service in voice, text > and video has. > > > > We have a forerunner in the specification of media for the > SIP based IP Multimedia phone in 3GPP. Maybe we can pick the > same style of specification. In 3GPP TS 26.235, "Packet > switched conversational multimedia applications, default > codecs", it is specified among the enumeration of supported media: > > 6.3 Real time text > 3G PS multimedia terminals offering real time text > conversation should support ITU-T Recommendation T.140 [25] > Text Conversation presentation coding. > > And in the chapter on RTP payload, it is specified: > > 9.2 RTP payload > RTP payload formats specified by IETF shall be used for real > time media streams. RTP payload format for the AMR narrowband > speech codec is specified in annex B. RTP payload format for > the AMR wideband speech codec is specified in annex B. RTP > payload format for the ITU-T Recommendation H.263 [6] video > codec is specified in IETF RFC 2429 [3]. RTP payload format > for the MPEG-4 visual simple profile level 0 is specified in > IETF RFC 3016 [5]. RTP payload format for the ITU-T > Recommendation T.140 [25] text conversation coding is > specified in IETF RFC 2793 [24]. > > In the annex A on specific details, the following is > specified for text: > > A.3 Text > Use of the redundancy coding variant specified in RFC 2793 > [24] is recommended for error resilience. > > -------------------------------- > When this topic was handled in 3GPP, there was opposition > against mentioning the reason for introducing the text > feature as being something specific for disabled people. > > I think that is still valid. > > I suggest that the following formulation is used: > ************************************************************** > ************** > ************************************** > SIP-zz, digital text support: SIP telephone devices SHOULD > support real time text conversation. If text is supported, it > MUST support RFC2793 [y], for text coding and packetization, > and it MUST be possible to use text simultaneously with voice. > ************************************************************** > ************** > ************************************** > > > Gunnar > ------------------------------------------- > Gunnar Hellström, Omnitor, Renathvägen 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ån: sipforum-discussion-admin@lists.su.se > > [mailto:sipforum-discussion-admin@lists.su.se]För Henry Sinnreich > > Skickat: den 10 juni 2003 18:02 > > Till: 'Drage, Keith (Keith)'; 'Henry Sinnreich'; 'Gunnar > Hellström'; > > 'Sipping@Ietf. Org'; 'Sipforum-Discussion@Lists. Su. Se' > > Ämne: [Sipforum-discussion] RE: [Sipping] Text support in SIP phones > > > > > > Keith, thanks for bringing balance, I believe, to this discussion. > > > > We could formulate soemthing like "SIP phones that have a > text display > > and advertised as supporting the hearing or speech disabled MUST..." > > > > Would this be OK? > > > > Henry > > > > > -----Original Message----- > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On > > > Behalf Of Drage, Keith (Keith) > > > Sent: Tuesday, June 10, 2003 8:14 AM > > > To: 'Henry Sinnreich'; 'Gunnar Hellström'; 'Sipping@Ietf. Org'; > > > 'Sipforum-Discussion@Lists. Su. Se' > > > Subject: RE: [Sipping] Text support in SIP phones > > > > > > > > > I would suggest that treating these sort of things as > MUST strength > > > is best left to national regulatory requirements, along > with other > > > things like fitness for purpose and so on. I have no objection to > > > their being mentioned. By the way, I understood this document was > > > being progressed as authors individual submission, and > was therefore > > > not standards track. > > > > > > Any such MUST would surely need to be qualified anyway. If the > > > purpose of the devise is such that it renders a textual devise > > > irrelevant, then why require one to be fitted. Suppose we were > > > designing a SIP phone for the totally blind, and this was > designed > > > to be worn as a headset, a text device would be > irrelevant to such a > > > user, and positioning such a device where it could be seen would > > > require an extra box hanging out of the side of the product. > > > > > > regards > > > > > > Keith > > > > > > Keith Drage > > > Lucent Technologies > > > Tel: +44 1793 776249 > > > Email: drage@lucent.com > > > > > > > -----Original Message----- > > > > From: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com] > > > > Sent: 27 May 2003 17:18 > > > > To: 'Gunnar Hellström'; 'Sipping@Ietf. Org'; > > > > 'Sipforum-Discussion@Lists. Su. Se' > > > > Cc: 'Henry Sinnreich' > > > > Subject: RE: [Sipping] Text support in SIP phones > > > > > > > > > > > > Gunnar, this all seems very reasonable, and I will try > to insert > > > > it properly. > > > > > > > > Henry > > > > > > > > > -----Original Message----- > > > > > From: sipping-admin@ietf.org > [mailto:sipping-admin@ietf.org] On > > > > > Behalf Of Gunnar Hellström > > > > > Sent: Thursday, May 22, 2003 6:54 PM > > > > > To: 'Sipping@Ietf. Org'; Sipforum-Discussion@Lists. Su. Se > > > > > Cc: Henry Sinnreich > > > > > Subject: [Sipping] Text support in SIP phones > > > > > > > > > > > > > > > Sorry, I missed out the reference to the SIP device > > > > > specification. > > > > > > > > > > Henry and all, > > > > > > > > > > Some time ago, I suggested addition of support for real time > > > > > text communication to the SIP device specification > > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-00.tx > > > t > > > > > > > > > > This was the simple part of the proposal: > > > > > > > > > > > SIP-zz, digital text support: SIP telephone devices > MUST support > > > > > > real time text conversation using RFC 2793 [y] for the > > > > > text stream. > > > > > > It MUST be possible to use text simultaneously with voice. > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------- > > > > > > In 4.11 Ringer Behaviour : add the section below for the > > > > > purpose of > > > > > > deaf, hearing impaired, deaf-blind people and people in the > > > > > garden and > > > > > > noisy > > > > > > locations: > > > > > > > > > > > > SIP Telephony devices MUST provide an external > interface to an > > > > > > external alerting system. > > > > > > > > > > > > > > > > > > > > > > > > Add to References > > > > > > ----------------- > > > > > > [y] G. Hellstrom: "RTP Payload for Text Conversation.", > > > RFC 2793, > > > > > > IETF, May 2000. > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > > > > > > The reception of this proposal was very positive. > > > > > Now, I would like to see the final formulation, and > check that > > > > > we agree on it. > > > > > > > > > > I regard this requirement to be very light. In the Interface > > > > > section ( e.g. > > > > > Int-2) , there is already mentioning of mandatory text input > > > > > mechanisms, and assumptions that a display would be normal, > > > > > since handling of phone books and buddy lists are > mandatory. To > > > > > re-use these text interface devices during the call for > > > > > standardised text conversation purposes seems straightforward. > > > > > > > > > > It could be wise to add the T.140 text presentation > protocol as > > > > > a codec to the codec section. The normal SDP used > together with > > > > > RFC2793 for text could also be specified. Do you want > > > > to do that? > > > > > > > > > > > > > > > ----- > > > > > > > > > > We also need to check the ideas around the other proposed > > > > > requirements: The requirement to include text > telephone modem in > > > > > all designs where an RJ11 phone connector exists, and the > > > > > requirement to support RFC 3351. I suggest that we start with > > > > > the straightforward and mainstream requirement above. Is that > > > > > accepted as it is? > > > > > > > > > > > > > > > Regards > > > > > > > > > > Gunnar > > > > > ------------------------------------------- > > > > > Gunnar Hellström, Omnitor, Renathvägen 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/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/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 From mailnull@www1.ietf.org Sat Jun 14 05:22: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 FAA22217 for ; Sat, 14 Jun 2003 05:22:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5E9MVC18791 for sipping-archive@odin.ietf.org; Sat, 14 Jun 2003 05:22:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E9MVm18788 for ; Sat, 14 Jun 2003 05:22: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 FAA22209 for ; Sat, 14 Jun 2003 05:22:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19R7Cs-0005W8-00 for sipping-web-archive@ietf.org; Sat, 14 Jun 2003 05:20:18 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19R7Cs-0005W5-00 for sipping-web-archive@ietf.org; Sat, 14 Jun 2003 05:20:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E7b4a12296; Sat, 14 Jun 2003 03:37:04 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E7aom12204 for ; Sat, 14 Jun 2003 03:36: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 DAA21105 for ; Sat, 14 Jun 2003 03:36:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19R5Yd-0005Fh-00 for sipping@ietf.org; Sat, 14 Jun 2003 03:34:39 -0400 Received: from e-eihq01.eis.ernet.in ([202.41.97.131]) by ietf-mx with esmtp (Exim 4.12) id 19R5YU-0005FQ-00 for sipping@ietf.org; Sat, 14 Jun 2003 03:34:31 -0400 Received: from uucp-relay-delhi.ernet.in by e-eihq01.eis.ernet.in (8.10.2/1.1.2.10/13Jul01-0336PM) id h5E82Sw0000022324; Sat, 14 Jun 2003 13:02:31 +0500 (GMT+0500) Received: by uucp-relay-delhi.ernet.in (8.9.3+Sun/SMI-4.1-MHS-7.0) id NAA29595; Sat, 14 Jun 2003 13:11:46 -0500 (GMT) >Received: from virgo.cdotd.ernet.in by cdotd.cdotd.ernet.in (SMI-8.6/SMI-SVR4) id MAA13921; Sat, 14 Jun 2003 12:51:16 -0500 Message-ID: <3EEACE62.A5FC9038@cdotd.ernet.in> Date: Sat, 14 Jun 2003 12:57:30 +0530 From: "Satish Bansal!" X-Mailer: Mozilla 4.73 [en] (X11; I; HP-UX B.11.00 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'sipping@ietf.org'" Subject: Re: [Sipping] Call Waiting - who does the tone References: <313680C9A886D511A06000204840E1CF070B5AE1@whq-msgusr-02.pit.comms.marconi.com> Received: from cdotd by vikram.eis.ernet.in; Sat, 14 Jun 2003 13:11 GMT Content-Type: multipart/alternative; boundary="------------52B9FF855EE2BCEE30EA2719" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --------------52B9FF855EE2BCEE30EA2719 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit There could be two options. First as you said, a dump phone should handle call waiting. It would mean that we are making end nodes intelligent. Second option is that intelligence is in the network, the inbound proxy should be call statefull and should use 3pcc for playing tone & annc. through a server to the party. rgds Satish Bansal Senior Research Engineer Intelligent Networks. "Rosen, Brian" wrote: > Robert > > If you have a UA that handles multiple calls, you don't need call waiting. > Another INVITE appears, you show it in your UI (lights, LCD, whatever), > and eventually the user decides to answer or ignore it. > > What if you are a really simple UA? A second call comes in. Who does what? > It would seem that the really best answer is that the dumb UA puts the > call waiting tone into the current audio. The user can then either > hang up the current call and let the second call ring through, or it can > press the "flash" button (if implemented), alternating between the two. > It's all local. > > What doesn't seem to work at all is to let some "tones and announcements" > server handle it - there is no way the dumb phone will create a media > connection to such a server if it has an active call. That means call > waiting CANNOT be implemented by any other element but the called UA. > > So, is this something that goes in a BCP? Even a dumb phone should handle > call waiting. > > Brian > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP Life at its best is a series of challenges. A big enough challenge will bring out strengths and abilities you never knew you had. Take on the challenges and you will bring yourself to life --------------52B9FF855EE2BCEE30EA2719 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit There could be two options. First as you said,  a dump phone should handle call waiting. It would mean that we are making  end nodes intelligent.
Second option is that intelligence is in the  network, the inbound proxy should be call statefull and should use 3pcc for playing tone & annc. through a server to  the party.

rgds
Satish Bansal
Senior Research Engineer
Intelligent Networks.

"Rosen, Brian" wrote:

Robert

If you have a UA that handles multiple calls, you don't need call waiting.
Another INVITE appears, you show it in your UI (lights, LCD, whatever),
and eventually the user decides to answer or ignore it.

What if you are a really simple UA?  A second call comes in.  Who does what?
It would seem that the really best answer is that the dumb UA puts the
call waiting tone into the current audio.  The user can then either
hang up the current call and let the second call ring through, or it can
press the "flash" button (if implemented), alternating between the two.
It's all local.

What doesn't seem to work at all is to let some "tones and announcements"
server handle it - there is no way the dumb phone will create a media
connection to such a server if it has an active call.  That means call
waiting CANNOT be implemented by any other element but the called UA.

So, is this something that goes in a BCP?  Even a dumb phone should handle
call waiting.

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

Life at its best is a series of challenges. 
A big enough challenge will bring out strengths
and abilities you never knew you had.
Take on the challenges and you will bring yourself
to life
  --------------52B9FF855EE2BCEE30EA2719-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sat Jun 14 20:13:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08185 for ; Sat, 14 Jun 2003 20:13:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5F0Ciq05126 for sipping-archive@odin.ietf.org; Sat, 14 Jun 2003 20:12:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5F0Cim05123 for ; Sat, 14 Jun 2003 20:12: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 UAA08179 for ; Sat, 14 Jun 2003 20:12:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RL6M-0000qX-00 for sipping-web-archive@ietf.org; Sat, 14 Jun 2003 20:10:30 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19RL6L-0000qU-00 for sipping-web-archive@ietf.org; Sat, 14 Jun 2003 20:10:29 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5EKT2a24172; Sat, 14 Jun 2003 16:29:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5EKSmm24157 for ; Sat, 14 Jun 2003 16:28: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 QAA03708 for ; Sat, 14 Jun 2003 16:28:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RHbf-0007lj-00 for sipping@ietf.org; Sat, 14 Jun 2003 16:26:35 -0400 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19RHbf-0007lg-00 for sipping@ietf.org; Sat, 14 Jun 2003 16:26:35 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by auemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h5EKSCg10796 for ; Sat, 14 Jun 2003 15:28:13 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Sat, 14 Jun 2003 21:28:11 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB008CB576E@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Michael Hammer , Sean Olson Cc: "Drage, Keith (Keith)" , "'Rohan Mahy'" , "'Jonathan Rosenberg'" , alan.johnston@wcom.com, "'sipping@ietf.org'" Subject: RE: [Sipping] proposed enhancement to dialog package Date: Sat, 14 Jun 2003 21:28:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , It seems to me that Michael has managed to put into the words the thoughts I was trying to express in my previous mail. The only reason we were talking about hold is that that is what Rohan used to describe it. From the further text I have seen so far, I am coming to the conclusion that what is desired has absolutely nothing whatsoever to do with hold at all, under whatever definition is being used. I am also coming to the conclusion that the state that is being represented is buried somewhere in the application above the SIP protocol entity, rather than in the SIP protocol entity itself. Which leads me to the question of whether the dialog state package (which represents SIP entity state) is the appropriate place to put it. (Or do we put everything we might want to say about the state of the end user as an extension to the dialog state package?) regards Keith Drage -----Original Message----- From: Michael Hammer [mailto:mhammer@cisco.com] Sent: 12 June 2003 15:47 To: Sean Olson Cc: Drage, Keith (Keith); 'Rohan Mahy'; 'Jonathan Rosenberg'; alan.johnston@wcom.com; 'sipping@ietf.org' Subject: RE: [Sipping] proposed enhancement to dialog package Sean, At 09:40 AM 6/11/2003 -0700, Sean Olson wrote: This is an interesting discussion in an almost academic sense, but it really does not address the reality of the very simple service that is being described here. "hold", "passive", whatever else you want to call it means not sending/receiving media. You mean that the active call/conference is not sending/receiving media to the party on hold, not that the held party was not receiving media. I don't understand the need for the term such as "passive". What is wrong with the term "hold"? If I am listening to a call, but not saying anything, I would consider myself passive. So can I conclude that you are after something that is not on hold, but not entirely responsive to the call? So what is the characteristic you are looking for? Ability to respond to signaling? It would appear that both parties on hold and automata could respond to such requests, i.e. a BYE. Ability to respond to media? I suppose this means a Turing machine equivalent. That could mean both human listeners and perhaps IVR systems. (Not looking for fool-proof human equivalent.) So, are you looking for a term that describes a party that is connected to the call, receiving media, but won't react to it? I think I'm missing the driving motivation here, but the above is what I am gleaning from the conversation thus far. Mike We've all experienced this. And, yes, this can be independent of the ability to do SIP signaling. I think we are focusing too much on signaling here and not enough on the user experience that is being built. And I certainly don't want a history lesson in ISDN signaling ;-) --- "Drage, Keith (Keith)" wrote: > See below > > regards > > Keith > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > > -----Original Message----- > > From: Rohan Mahy [mailto:rohan@cisco.com] > > Sent: 10 June 2003 16:25 > > To: Drage, Keith (Keith) > > Cc: 'Jonathan Rosenberg'; alan.johnston@wcom.com; > 'sipping@ietf.org' > > Subject: Re: [Sipping] proposed enhancement to > dialog package > > > > > > Hi Keith, > > > > Hold as a UI concept significantly predated the > development of ISDN. > > Agreed, and my initial message identified in that > case (analogue PSTN terminals) that Hold was > originally to recall the register (and there was a > manual board equivalent as well) to allow access > resources to be used for signalling, as a result of > that signalling, the access resources might be used > for communication with another party, and only as a > by product of that did it necessarily result in loss > of communication path with the other party. > > > In any case, an ISDN user (Alice) who requests an > ISDN hold > > is still a > > passive participant by my definition. When > Alice's call is connected > > to a conference server and all the active > participants say "ok, we're > > leaving now, good bye", Alice is not active enough > to be able to hang > > up. > > Assuming your last statement still refers to an ISDN > user, then I can think of nothing in the above > scenario that prevents Alice sending a DISCONNECT, > and receiving a RELEASE back. Can you clarify. The > DSS1 basic call state machine is totally independent > of any subsidiary state machine relating to > hold/retrieve. > > If you are referring to hanging up the conference > bridge resources, then this is dependent on the > concept of ownership, which varies based on the > conference service provided, and also between public > and private networks. > > As a result, I think I am now confused about what > you actually mean by passive, can you elaborate > further. > > > > > > I agree that whatever we do, we need to describe > the semantics very > > crisply. > > > > thanks, > > -rohan > > > > > > On Tuesday, June 10, 2003, at 04:47 AM, Drage, > Keith (Keith) wrote: > > > > > I fail to see how thw property you are proposing > correlates in some > > > way to any concept of hold. I agree that "hold" > has many meanings, > > > based on which type of signalling you are using. > > > > > > To clarify, the prime function of hold in the > PSTN was never to > > > interrupt the communication, that was a side > effect of grabbing the > > > access resources to signal to another party. > Thus for ISDN, hold > > > therefore was only a removal of access resources > (the > > bearer) so that > > > that bearer could be reused for another call; > again the side effect > > > was to interrupt the communication. The sole > function of > > hold for SIP > > > is to interrupt the communication. > > > > > > Certainly, if an ISDN user places another user > on hold, I > > would regard > > > neither user as "passive" as you seem to be > defining here. > > > > > > If we are going to do this, can we make sure we > define the > > semantics > > > correctly. Otherwise we will surely create > confusion, > > particularly if > > > people try and equate this concept with that of > hold, and in > > > particular with the PSTN concept. > > > > > > regards > > > > > > Keith > > > > > > > > > Keith Drage > > > Lucent Technologies > > > Tel: +44 1793 776249 > > > Email: drage@lucent.com > > > > > >> -----Original Message----- > > >> From: Rohan Mahy [mailto:rohan@cisco.com] > > >> Sent: 03 June 2003 22:18 > > >> To: 'Jonathan Rosenberg' > > >> Cc: rohan@cisco.com; alan.johnston@wcom.com; > 'sipping@ietf.org' > > >> Subject: [Sipping] proposed enhancement to > dialog package > > >> > > >> > > >> Hi, > > >> > > >> There have been many requests for the dialog > package to express the > > >> concept of hold. The problem is that nobody had > an especially good > > >> definition of what "on-hold" meant. Some > suggested that all media > > >> streams being inactive implied that you are > "held", but > > this doesn't > > >> work for a service such as music-on-hold. > > >> > > >> I believe that folks actually want a slightly > different > > concept--that > > >> the semantics we want instead are already > described in the > > >> call control > > >> framework: > > >> > > >>> Participants may also be active or passive. > Active > > participants are > > >>> expected to be intelligent enough to leave a > conversation > > >> space when > > >>> they no longer desire to participate. (An > attentive human > > >> participant > > >>> is obviously active.) Some robotic > participants (such as a voice > > >>> messaging system, an instant messaging agent, > or a voice dialog > > >>> system) may be active participants if they can > leave the > > >> conversation > > >>> space when there is no human interaction. > Other robots > > (for example > > >>> our tone generating robot from the previous > example) are passive > > >>> participants. A human participant "on-hold" is > passive. > > >> > > >> I think we should add a new attribute to the > dialog package that > > >> expresses this property. My proposal is to > express this > > property only > > >> for the local side of each dialog by adding an > attribute > > to the state > > >> tag in the dialog-info notification body. The > example below > > >> includes a > > >> proposed (optional) participation attribute in > the state tag. > > >> > > >> > > >> xmlns="urn:ietf:params:xml:ns:dialog-info" > > >> version="3" > > >> state="partial" > > >> entity="sip:caller@bar.com"> > === message truncated === __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.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 mailnull@www1.ietf.org Mon Jun 16 06:50:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07843 for ; Mon, 16 Jun 2003 06:50:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5GAoHj24022 for sipping-archive@odin.ietf.org; Mon, 16 Jun 2003 06:50:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GAoHm24019 for ; Mon, 16 Jun 2003 06:50: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 GAA07838 for ; Mon, 16 Jun 2003 06:50:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RrWp-0001Ga-00 for sipping-web-archive@ietf.org; Mon, 16 Jun 2003 06:48:00 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19RrWp-0001GW-00 for sipping-web-archive@ietf.org; Mon, 16 Jun 2003 06:47:59 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G8u2a16675; Mon, 16 Jun 2003 04:56:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G8tum16652 for ; Mon, 16 Jun 2003 04:55: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 EAA05762 for ; Mon, 16 Jun 2003 04:55:53 -0400 (EDT) From: georg.mayer@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RpkC-0000ok-00 for sipping@ietf.org; Mon, 16 Jun 2003 04:53:40 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19RpkB-0000od-00 for sipping@ietf.org; Mon, 16 Jun 2003 04:53:39 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5G8tq907092 for ; Mon, 16 Jun 2003 11:55:52 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 16 Jun 2003 11:55:52 +0300 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 16 Jun 2003 11:55:52 +0300 Received: from esebe021.NOE.Nokia.com ([172.21.138.104]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 16 Jun 2003 11:55:50 +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" Date: Mon, 16 Jun 2003 11:55:49 +0300 Message-ID: <147748D63CC6B5449BC5E49FB5F8FF510149D379@esebe021.ntc.nokia.com> Thread-Topic: Comments on draft-ietf-sipping-config-framework-00.txt - 3: Fetching of Information Thread-Index: AcMz4Y2h+Q1FKtIJSGCNeeGRqHKGCQ== To: , X-OriginalArrivalTime: 16 Jun 2003 08:55:50.0688 (UTC) FILETIME=[160B6A00:01C333E5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5G8tum16655 Subject: [Sipping] Comments on draft-ietf-sipping-config-framework-00.txt - 3: Fetching of Information Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, 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 From mailnull@www1.ietf.org Mon Jun 16 07:39:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08494 for ; Mon, 16 Jun 2003 07:39:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5GBcqC27530 for sipping-archive@odin.ietf.org; Mon, 16 Jun 2003 07:38:52 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GBcqm27527 for ; Mon, 16 Jun 2003 07:38: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 HAA08486 for ; Mon, 16 Jun 2003 07:38:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RsHs-0001RL-00 for sipping-web-archive@ietf.org; Mon, 16 Jun 2003 07:36:36 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19RsHr-0001RI-00 for sipping-web-archive@ietf.org; Mon, 16 Jun 2003 07:36:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G8u5a16687; Mon, 16 Jun 2003 04:56:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G8tvm16659 for ; Mon, 16 Jun 2003 04:55: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 EAA05767 for ; Mon, 16 Jun 2003 04:55:54 -0400 (EDT) From: georg.mayer@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RpkD-0000or-00 for sipping@ietf.org; Mon, 16 Jun 2003 04:53:41 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19RpkC-0000oh-00 for sipping@ietf.org; Mon, 16 Jun 2003 04:53:40 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5G8tra14777 for ; Mon, 16 Jun 2003 11:55:53 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 16 Jun 2003 11:55:53 +0300 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 16 Jun 2003 11:55:52 +0300 Received: from esebe021.NOE.Nokia.com ([172.21.138.104]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 16 Jun 2003 11:55:51 +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" Date: Mon, 16 Jun 2003 11:55:49 +0300 Message-ID: <147748D63CC6B5449BC5E49FB5F8FF510149D37B@esebe021.ntc.nokia.com> Thread-Topic: Comments on draft-ietf-sipping-config-framework-00.txt - 1: general scope of framework Thread-Index: AcMz4TSvJ05wsd7PSv+nEB/44tiuVg== To: , X-OriginalArrivalTime: 16 Jun 2003 08:55:51.0110 (UTC) FILETIME=[164BCE60:01C333E5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5G8tvm16660 Subject: [Sipping] Comments on draft-ietf-sipping-config-framework-00.txt - 1: general scope of 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: 8bit Content-Transfer-Encoding: 8bit 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 From mailnull@www1.ietf.org Mon Jun 16 07:46:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08636 for ; Mon, 16 Jun 2003 07:46:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5GBkU827813 for sipping-archive@odin.ietf.org; Mon, 16 Jun 2003 07:46:30 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GBkUm27810 for ; Mon, 16 Jun 2003 07:46: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 HAA08623 for ; Mon, 16 Jun 2003 07:46:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RsPG-0001TG-00 for sipping-web-archive@ietf.org; Mon, 16 Jun 2003 07:44:15 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19RsPG-0001TD-00 for sipping-web-archive@ietf.org; Mon, 16 Jun 2003 07:44:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G7Z3a10814; Mon, 16 Jun 2003 03:35:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G7YFm10767 for ; Mon, 16 Jun 2003 03:34: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 DAA04526 for ; Mon, 16 Jun 2003 03:34:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RoT9-0000Tu-00 for sipping@ietf.org; Mon, 16 Jun 2003 03:31:59 -0400 Received: from [217.158.120.227] (helo=rnidmail.rnid.org.uk) by ietf-mx with esmtp (Exim 4.12) id 19RoT8-0000TX-00 for sipping@ietf.org; Mon, 16 Jun 2003 03:31:58 -0400 Received: from rnid.org.uk (unverified) by rnidmail.rnid.org.uk (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Mon, 16 Jun 2003 08:31:55 +0100 Received: from RNIDMAIL-Message_Server by rnid.org.uk with Novell_GroupWise; Mon, 16 Jun 2003 08:31:18 +0100 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Mon, 16 Jun 2003 08:30:50 +0100 From: "Guido Gybels" To: Subject: RE: [Sipping] Text support in SIP phones Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5G7YFm10768 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Henry, <> I respectfully suggest that it is not because there exist already a number of incomplete or even bad solutions today, that we should refrain from improving. Taking 3G's GTT as an example won't get us anywhere either since that is a solution that is completely unfit for the European market. I strongly suggest we look again at my previous suggesting: make it MUST, except for well defined exceptions. That allows to harmonize interactive texting while still allowing for specific cases not to support it. It certainly is the most robust business solution and makes sense as a mainstream solution as well. 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 ************************************************************************ 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 mailnull@www1.ietf.org Mon Jun 16 08:15: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 IAA09826 for ; Mon, 16 Jun 2003 08:15:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5GCFT629902 for sipping-archive@odin.ietf.org; Mon, 16 Jun 2003 08:15:29 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GCFTm29899 for ; Mon, 16 Jun 2003 08:15: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 IAA09823 for ; Mon, 16 Jun 2003 08:15:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RsrI-0001eP-00 for sipping-web-archive@ietf.org; Mon, 16 Jun 2003 08:13:12 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19RsrI-0001eM-00 for sipping-web-archive@ietf.org; Mon, 16 Jun 2003 08:13:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G8u7a16697; Mon, 16 Jun 2003 04:56:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G8txm16663 for ; Mon, 16 Jun 2003 04:55: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 EAA05770 for ; Mon, 16 Jun 2003 04:55:56 -0400 (EDT) From: georg.mayer@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RpkF-0000ox-00 for sipping@ietf.org; Mon, 16 Jun 2003 04:53:43 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19RpkE-0000ou-00 for sipping@ietf.org; Mon, 16 Jun 2003 04:53:42 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5G8tta14801 for ; Mon, 16 Jun 2003 11:55:55 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 16 Jun 2003 11:55:53 +0300 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 16 Jun 2003 11:55:52 +0300 Received: from esebe021.NOE.Nokia.com ([172.21.138.104]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 16 Jun 2003 11:55:50 +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" Date: Mon, 16 Jun 2003 11:55:49 +0300 Message-ID: <147748D63CC6B5449BC5E49FB5F8FF510149D37A@esebe021.ntc.nokia.com> Thread-Topic: Comments on draft-ietf-sipping-config-framework-00.txt - 2: Content and format of configuration data Thread-Index: AcMz4W1nNVLZGsa4QHimEuVPf6MGLA== To: , X-OriginalArrivalTime: 16 Jun 2003 08:55:50.0907 (UTC) FILETIME=[162CD4B0:01C333E5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5G8txm16664 Subject: [Sipping] Comments on draft-ietf-sipping-config-framework-00.txt - 2: Content and format of configuration data Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit 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 From mailnull@www1.ietf.org Mon Jun 16 19:31:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08481 for ; Mon, 16 Jun 2003 19:31:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5GNVVj14723 for sipping-archive@odin.ietf.org; Mon, 16 Jun 2003 19:31:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GNVVm14720 for ; Mon, 16 Jun 2003 19:31: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 TAA08477 for ; Mon, 16 Jun 2003 19:31:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S3PW-0000Ip-00 for sipping-web-archive@ietf.org; Mon, 16 Jun 2003 19:29:14 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19S3PW-0000Im-00 for sipping-web-archive@ietf.org; Mon, 16 Jun 2003 19:29:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GFP8a11346; Mon, 16 Jun 2003 11:25:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FLSnm26938 for ; Sun, 15 Jun 2003 17:28:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11358 for ; Sun, 15 Jun 2003 17:28:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Rf1G-0005Rg-00 for sipping@ietf.org; Sun, 15 Jun 2003 17:26:34 -0400 Received: from dsl-dt-207-34-112-i195-cgy.nucleus.com ([207.34.112.195] helo=yyc.jasomi.com) by ietf-mx with esmtp (Exim 4.12) id 19Rf1F-0005Rc-00 for sipping@ietf.org; Sun, 15 Jun 2003 17:26:33 -0400 Received: from jasomi.com (aluminum.jasomi.com [192.168.16.61]) (authenticated bits=0) by yyc.jasomi.com (8.12.9/8.12.6) with ESMTP id h5FLJAiT031884 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 15 Jun 2003 15:19:11 -0600 (MDT) Date: Sun, 15 Jun 2003 15:28:44 -0600 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed From: Alan Hawrylyshen To: "'sipping@ietf.org'" Message-Id: <579B54C0-9F78-11D7-B0FA-000A956A5F38@jasomi.com> X-Mailer: Apple Mail (2.552) X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5FLSnm26939 Subject: [Sipping] Call Waiting - who does the tone Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h5GFP8a11346 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5GNVVm14720 Content-Transfer-Encoding: 8bit On Saturday, Jun 14, 2003, at 01:27 Canada/Mountain, Satish Bansal! wrote: > > There could be two options. First as you said,  a dump phone should > handle call waiting. It would mean that we are making  end nodes > intelligent. > > Second option is that intelligence is in the  network, the inbound > proxy should be call statefull and should use 3pcc for playing tone & > annc. through a server to  the party. 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 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). 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 maintain and deploy the ’core’ portion of a SIP network infrastructure. I would agree w/ Brian on this; this could be appropriate for inclusion in a BCP document. De-lurking, Alan Hawrylyshen Jasomi Networks Inc. sip:alan@jasomi.com mailto:alan@jasomi.com http://www.jasomi.com/ _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jun 16 20:03:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09362 for ; Mon, 16 Jun 2003 20:03:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5H03Mw16942 for sipping-archive@odin.ietf.org; Mon, 16 Jun 2003 20:03:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H03Mm16939 for ; Mon, 16 Jun 2003 20:03: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 UAA09340 for ; Mon, 16 Jun 2003 20:03:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S3uL-0000XK-00 for sipping-web-archive@ietf.org; Mon, 16 Jun 2003 20:01:05 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19S3uK-0000XH-00 for sipping-web-archive@ietf.org; Mon, 16 Jun 2003 20:01:04 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GFPAa11357; Mon, 16 Jun 2003 11:25:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G8tum16651 for ; Mon, 16 Jun 2003 04:55: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 EAA05763 for ; Mon, 16 Jun 2003 04:55:53 -0400 (EDT) From: georg.mayer@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RpkC-0000og-00 for sipping@ietf.org; Mon, 16 Jun 2003 04:53:40 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19RpkA-0000oc-00 for sipping@ietf.org; Mon, 16 Jun 2003 04:53:39 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5G8tq907079 for ; Mon, 16 Jun 2003 11:55:52 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 16 Jun 2003 11:55:51 +0300 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 16 Jun 2003 11:55:51 +0300 Received: from esebe021.NOE.Nokia.com ([172.21.138.104]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 16 Jun 2003 11:55:50 +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" Date: Mon, 16 Jun 2003 11:55:48 +0300 Message-ID: <147748D63CC6B5449BC5E49FB5F8FF510149D378@esebe021.ntc.nokia.com> Thread-Topic: Comments on draft-ietf-sipping-config-framework-00.txt - 4: Discovery Thread-Index: AcMz4bKoX0l5y4SdRcaBOBkCfzBkMg== To: , X-OriginalArrivalTime: 16 Jun 2003 08:55:50.0360 (UTC) FILETIME=[15D95D80:01C333E5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5G8tum16654 Subject: [Sipping] Comments on draft-ietf-sipping-config-framework-00.txt - 4: Discovery Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit And once again - this time on the discovery mechanism: The discovery procedure can be simplified by making the subscription to the service more presence-alike, i..e the user puts her own URI in the request URI: SUBSCRIBE sip:user@home1.net SIP/2.0 To: sip:user@home1.net From: sip:user@home1.net;tag=151170 Event: sip-config The request would then - same as presence or registration state - be routed to the service configuration server. The discovery mechanism as described in the current draft could therefore be one option, in the same way as the above described procedure. This would also solve the problem when a roaming wireless user subscribes to her configuration information. 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 From mailnull@www1.ietf.org Mon Jun 16 21:00:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11094 for ; Mon, 16 Jun 2003 21:00:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5H0xiA20804 for sipping-archive@odin.ietf.org; Mon, 16 Jun 2003 20:59:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H0xim20801 for ; Mon, 16 Jun 2003 20:59: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 UAA11007 for ; Mon, 16 Jun 2003 20:59:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S4ms-00011j-00 for sipping-web-archive@ietf.org; Mon, 16 Jun 2003 20:57:26 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19S4mr-00011f-00 for sipping-web-archive@ietf.org; Mon, 16 Jun 2003 20:57:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GFP3a11324; Mon, 16 Jun 2003 11:25:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D61rm28188 for ; Fri, 13 Jun 2003 02:01: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 CAA12024 for ; Fri, 13 Jun 2003 02:01:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QhbC-0001V5-00 for sipping@ietf.org; Fri, 13 Jun 2003 01:59:42 -0400 Received: from 205-158-62-158.outblaze.com ([205.158.62.158] helo=spf1.us.outblaze.com) by ietf-mx with smtp (Exim 4.12) id 19QhbB-0001UV-00 for sipping@ietf.org; Fri, 13 Jun 2003 01:59:41 -0400 Received: (qmail 29160 invoked from network); 13 Jun 2003 06:00:44 -0000 Received: from unknown (205.158.62.68) by spf1.us.outblaze.com with QMQP; 13 Jun 2003 06:00:44 -0000 Received: (qmail 7240 invoked from network); 13 Jun 2003 06:01:18 -0000 Received: from unknown (HELO ws1-9.us4.outblaze.com) (205.158.62.37) by 205-158-62-153.outblaze.com with SMTP; 13 Jun 2003 06:01:18 -0000 Received: (qmail 78837 invoked by uid 1001); 13 Jun 2003 06:01:18 -0000 Message-ID: <20030613060118.78836.qmail@mail.com> Content-Type: text/html; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [202.54.26.125] by ws1-9.us4.outblaze.com with http for umsharma@techie.com; Fri, 13 Jun 2003 01:01:18 -0500 From: "Umesh Sharma" To: "debanjan" , sip@ietf.org, sipping@ietf.org Date: Fri, 13 Jun 2003 01:01:18 -0500 X-Originating-Ip: 202.54.26.125 X-Originating-Server: ws1-9.us4.outblaze.com Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: [Sip] Message Body format for INFO method carrying DTMF Digits Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit

There is this draft "draft-choudhuri-sip-info-digit-00.txt"  but it seems it has expired & other one is "RFC 2833"  on DTMF transmission.

Umesh

----- Original Message -----
From: "debanjan"
Date: Thu, 12 Jun 2003 19:05:25 +0530
To: ,
Subject: [Sip] Message Body format for INFO method carrying DTMF Digits

Hi,
    Anyone has any idea regarding what should be message body of SIP Info method that carries the DTMF digits. Is there any standard RFC or draft implementation.
    Any suggestions are welcome.
 
    Regards
    Debanjan
   
    D-Link India Ltd
    Software and R & D Center
--

_______________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com

_______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jun 16 21:12:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11561 for ; Mon, 16 Jun 2003 21:12:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5H1CKZ22328 for sipping-archive@odin.ietf.org; Mon, 16 Jun 2003 21:12:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H1CKm22325 for ; Mon, 16 Jun 2003 21:12: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 VAA11522 for ; Mon, 16 Jun 2003 21:12:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S4z5-0001CP-00 for sipping-web-archive@ietf.org; Mon, 16 Jun 2003 21:10:03 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19S4z4-0001CM-00 for sipping-web-archive@ietf.org; Mon, 16 Jun 2003 21:10:02 -0400 Received: from www1.ietf.org (a.mx.viagraonlinenow.biz [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GJA2a28191; Mon, 16 Jun 2003 15:10:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GJ90m28151 for ; Mon, 16 Jun 2003 15:09: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 PAA26245 for ; Mon, 16 Jun 2003 15:08:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RzJT-0005Lm-00 for sipping@ietf.org; Mon, 16 Jun 2003 15:06:43 -0400 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx with esmtp (Exim 4.12) id 19RzJS-0005LT-00 for sipping@ietf.org; Mon, 16 Jun 2003 15:06:42 -0400 Received: by fox.iptel.org (Postfix, from userid 534) id 9A9171E9; Mon, 16 Jun 2003 21:08:22 +0200 (CEST) Received: from jku07.iptel.org (port-212-202-172-56.reverse.qdsl-home.de [212.202.172.56]) by fox.iptel.org (Postfix) with ESMTP id 6C8121E3; Mon, 16 Jun 2003 21:08:21 +0200 (CEST) Message-Id: <5.2.0.9.0.20030616204858.0293f920@iptel.org> X-Sender: jiri@iptel.org (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 16 Jun 2003 21:05:21 +0200 To: David Yon , sipping@ietf.org From: Jiri Kuthan In-Reply-To: <5.1.1.6.0.20030616130712.03a3d008@mail.rfdsoftware.com> References: <5.2.0.9.0.20030616182209.0293f920@iptel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-25.0 required=5.0 tests=AWL,BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.51 X-Spam-Checker-Version: SpamAssassin 2.51 (1.174.2.5-2003-03-20-exp) Subject: [Sipping] re: what happens if both SIP UAs want to be active Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , [ok, I'm diverting from mmusic to sipping and re-asking the same question again.] My today's problem is it is difficult to detect when signaling using comedia fails because of both UAs behind symmetric NATs trying to enter symmetric active mode. If entities in the signaling path (proxies, b2bua, whatsoever) know what happened, they can try other means of NAT traversal. The missing piece is that they don't know what happened -- there is no specific error code for this condition in SIP. It's thus imho very desirable to introduce such an error code. Comments? -Jiri At 07:07 PM 6/16/2003, David Yon wrote: >The SIP gurus can chime in, but seems to me it would be in the same category as not being able to come to an agreement vis-a-vis which codec to use. > >At 12:25 PM 6/16/2003, Jiri Kuthan wrote: >>[sorry, misthreaded -- I copy'n'pasted from archive since I was stripped >> off the recepient list] >> >>What does it mean SIP-wise that negotiation fails? >> >>I mean it would be great to have a special code for this error which >>allows SIP entities to recognized these conditions and act approprietly. >> >>-Jiri >> >>on Sun, 08 Jun 2003 17:31:12 -0400, David wrote: >>> If they both want to be active, the negotiation fails. >> >>>> At 12:47 PM 6/7/2003, Jiri Kuthan wrote: >>>> David, >>>> >>>> can you please explain me how SIP signaling proceeds if two UAs both >>>> with to have direction=active, since they are behind symmetric NATs? >>>> >>>> Thanks, >>>> >>>> -jiri >> >>-- >>Jiri Kuthan http://iptel.org/~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 mailnull@www1.ietf.org Mon Jun 16 22:23:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13196 for ; Mon, 16 Jun 2003 22:23:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5H2MdQ26812 for sipping-archive@odin.ietf.org; Mon, 16 Jun 2003 22:22:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H2Mdm26809 for ; Mon, 16 Jun 2003 22:22: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 WAA13163 for ; Mon, 16 Jun 2003 22:22:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S657-0001fc-00 for sipping-web-archive@ietf.org; Mon, 16 Jun 2003 22:20:21 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19S656-0001fZ-00 for sipping-web-archive@ietf.org; Mon, 16 Jun 2003 22:20:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GM23a08248; Mon, 16 Jun 2003 18:02:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GM1Ym08226 for ; Mon, 16 Jun 2003 18:01: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 SAA04743 for ; Mon, 16 Jun 2003 18:01:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S20T-0007Q5-00 for sipping@ietf.org; Mon, 16 Jun 2003 17:59:17 -0400 Received: from dsl-dt-207-34-112-i195-cgy.nucleus.com ([207.34.112.195] helo=yyc.jasomi.com) by ietf-mx with esmtp (Exim 4.12) id 19S20S-0007Q1-00 for sipping@ietf.org; Mon, 16 Jun 2003 17:59:16 -0400 Received: from jasomi.com (aluminum.jasomi.com [192.168.16.61]) (authenticated bits=0) by yyc.jasomi.com (8.12.9/8.12.6) with ESMTP id h5GLpmiT002470 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 16 Jun 2003 15:51:48 -0600 (MDT) Date: Mon, 16 Jun 2003 16:01:29 -0600 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed From: Alan Hawrylyshen To: "'sipping@ietf.org'" Message-Id: <1586D8FA-A046-11D7-A786-000A956A5F38@jasomi.com> X-Mailer: Apple Mail (2.552) X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5GM1Ym08227 Subject: [Sipping] Re: Call Waiting - who does the tone Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h5GM23a08248 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5H2Mdm26809 Content-Transfer-Encoding: 8bit On Saturday, Jun 14, 2003, at 01:27 Canada/Mountain, Satish Bansal! wrote: > > There could be two options. First as you said,  a dump phone should > handle call waiting. It would mean that we are making  end nodes > intelligent. > > Second option is that intelligence is in the  network, the inbound > proxy should be call statefull and should use 3pcc for playing tone & > annc. through a server to  the party. 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 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). 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 maintain and deploy the ’core’ portion of a SIP network infrastructure. I would agree w/ Brian on this; this could be appropriate for inclusion in a BCP document. De-lurking, Alan Hawrylyshen Jasomi Networks Inc. sip:alan@jasomi.com mailto:alan@jasomi.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jun 16 22:30:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13365 for ; Mon, 16 Jun 2003 22:30:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5H2UNM27174 for sipping-archive@odin.ietf.org; Mon, 16 Jun 2003 22:30:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H2UNm27171 for ; Mon, 16 Jun 2003 22:30: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 WAA13362 for ; Mon, 16 Jun 2003 22:30:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S6Cb-0001hX-00 for sipping-web-archive@ietf.org; Mon, 16 Jun 2003 22:28:05 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19S6Ca-0001hU-00 for sipping-web-archive@ietf.org; Mon, 16 Jun 2003 22:28:04 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GEe3a08282; Mon, 16 Jun 2003 10:40:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GEdWm08197 for ; Mon, 16 Jun 2003 10:39: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 KAA16543 for ; Mon, 16 Jun 2003 10:39:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Rv6g-00034F-00 for sipping@ietf.org; Mon, 16 Jun 2003 10:37:15 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19Rv6g-000346-00 for sipping@ietf.org; Mon, 16 Jun 2003 10:37:14 -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 KAA29449; Mon, 16 Jun 2003 10:38:57 -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 KAA02409; Mon, 16 Jun 2003 10:38:58 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Jun 2003 10:38:57 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5AEA@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Satish Bansal!'" Cc: "'sipping@ietf.org'" Subject: RE: [Sipping] Call Waiting - who does the tone Date: Mon, 16 Jun 2003 10:38:53 -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 don't think your second option works. The situation is that a call is up to the called party (the one that gets call waiting). No amount of 3PCC is going to change the state of that call such that a tone could be played. You would have to instruct the called party to put the existing call on hold, and then accept (automatically!) a call from tones/announcement generator without ringing. No way that any dumb phone is going to do that. Brian -----Original Message----- From: Satish Bansal! [mailto:sbansal@cdotd.ernet.in] Sent: Saturday, June 14, 2003 3:28 AM To: Rosen, Brian Cc: 'sipping@ietf.org' Subject: Re: [Sipping] Call Waiting - who does the tone There could be two options. First as you said, a dump phone should handle call waiting. It would mean that we are making end nodes intelligent. Second option is that intelligence is in the network, the inbound proxy should be call statefull and should use 3pcc for playing tone & annc. through a server to the party. rgds Satish Bansal Senior Research Engineer Intelligent Networks. "Rosen, Brian" wrote: Robert If you have a UA that handles multiple calls, you don't need call waiting. Another INVITE appears, you show it in your UI (lights, LCD, whatever), and eventually the user decides to answer or ignore it. What if you are a really simple UA? A second call comes in. Who does what? It would seem that the really best answer is that the dumb UA puts the call waiting tone into the current audio. The user can then either hang up the current call and let the second call ring through, or it can press the "flash" button (if implemented), alternating between the two. It's all local. What doesn't seem to work at all is to let some "tones and announcements" server handle it - there is no way the dumb phone will create a media connection to such a server if it has an active call. That means call waiting CANNOT be implemented by any other element but the called UA. So, is this something that goes in a BCP? Even a dumb phone should handle call waiting. Brian _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP Life at its best is a series of challenges. A big enough challenge will bring out strengths and abilities you never knew you had. Take on the challenges and you will bring yourself to life _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Jun 16 23:21:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14607 for ; Mon, 16 Jun 2003 23:21:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5H3KgP31064 for sipping-archive@odin.ietf.org; Mon, 16 Jun 2003 23:20:42 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H3Kam31061 for ; Mon, 16 Jun 2003 23:20: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 XAA14573 for ; Mon, 16 Jun 2003 23:20:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S6z9-00022T-00 for sipping-web-archive@ietf.org; Mon, 16 Jun 2003 23:18:15 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19S6z8-00022Q-00 for sipping-web-archive@ietf.org; Mon, 16 Jun 2003 23:18:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GFP6a11335; Mon, 16 Jun 2003 11:25:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ELUTm28337 for ; Sat, 14 Jun 2003 17: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 RAA04744 for ; Sat, 14 Jun 2003 17:30:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RIZM-0000Ho-00 for sipping@ietf.org; Sat, 14 Jun 2003 17:28:16 -0400 Received: from dsl-dt-207-34-112-i195-cgy.nucleus.com ([207.34.112.195] helo=yyc.jasomi.com) by ietf-mx with esmtp (Exim 4.12) id 19RIZL-0000Hl-00 for sipping@ietf.org; Sat, 14 Jun 2003 17:28:15 -0400 Received: from jasomi.com (aluminum.jasomi.com [192.168.16.61]) (authenticated bits=0) by yyc.jasomi.com (8.12.9/8.12.6) with ESMTP id h5ELIpiT010246 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Sat, 14 Jun 2003 15:18:51 -0600 (MDT) Date: Sat, 14 Jun 2003 15:28:20 -0600 Subject: Re: [Sipping] Call Waiting - who does the tone Content-Type: multipart/alternative; boundary=Apple-Mail-4-9489202 Mime-Version: 1.0 (Apple Message framework v552) Cc: "Rosen, Brian" , "'sipping@ietf.org'" To: "Satish Bansal!" From: Alan Hawrylyshen In-Reply-To: <3EEACE62.A5FC9038@cdotd.ernet.in> Message-Id: <1EDC4E4E-9EAF-11D7-925B-000A956A5F38@jasomi.com> X-Mailer: Apple Mail (2.552) Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --Apple-Mail-4-9489202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On Saturday, Jun 14, 2003, at 01:27 Canada/Mountain, Satish Bansal!=20 wrote: > There could be two options. First as you said,=A0 a dump phone should=20= > handle call waiting. It would mean that we are making=A0 end nodes=20 > intelligent. > Second option is that intelligence is in the=A0 network, the inbound=20= > proxy should be call statefull and should use 3pcc for playing tone &=20= > annc. through a server to=A0 the party. Certainly both solutions work, but keeping the implementation of this=20 feature in the UA would be , in my opinion, more in keeping with the=20 SIP design philosophies of keeping the core relatively free of=20 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=20 direct URL dialing while in a pre-existing session established through=20= the proxy handling your registered AOR). Although it raises the bar a little bit for the UA implementors, I=20 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. I would agree w/ Brian on this; this could be appropriate for inclusion=20= in a BCP document. De-lurking, Alan Hawrylyshen Jasomi Networks Inc. sip:alan@jasomi.com mailto:alan@jasomi.com http://www.jasomi.com/ --Apple-Mail-4-9489202 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Saturday, Jun 14, 2003, at 01:27 Canada/Mountain, Satish Bansal! wrote: 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. Second option is that intelligence is in the=A0 network, the inbound proxy should be call statefull and should use 3pcc for playing tone & annc. through a server to=A0 the party. 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 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). 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 maintain and deploy the 'core' portion of a SIP network infrastructure. I would agree w/ Brian on this; this could be appropriate for inclusion in a BCP document. De-lurking, VerdanaAlan Hawrylyshen Jasomi Networks Inc. sip:alan@jasomi.com mailto:alan@jasomi.com http://www.jasomi.com/ = --Apple-Mail-4-9489202-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jun 17 00:58:31 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 AAA16932 for ; Tue, 17 Jun 2003 00:58:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5H4w5805594 for sipping-archive@odin.ietf.org; Tue, 17 Jun 2003 00:58:05 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H4w4m05591 for ; Tue, 17 Jun 2003 00:58:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16928 for ; Tue, 17 Jun 2003 00:58:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S8VX-0002b8-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 00:55:47 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19S8VW-0002b5-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 00:55:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GHn3a21864; Mon, 16 Jun 2003 13:49:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GHmNm21825 for ; Mon, 16 Jun 2003 13:48: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 NAA22473; Mon, 16 Jun 2003 13:48:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ry3R-0004R1-00; Mon, 16 Jun 2003 13:46:05 -0400 Received: from [65.200.90.207] (helo=mailserver.sylantro.com) by ietf-mx with smtp (Exim 4.12) id 19Ry3Q-0004Qg-00; Mon, 16 Jun 2003 13:46:04 -0400 Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Mon, 16 Jun 2003 10:47:32 -0700 X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Received: by mailserver.sylantro.com with Internet Mail Service ( 5.5.2653.19) id ; Mon, 16 Jun 2003 10:47:32 -0700 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD023BCAB3@mailserver.sylantro.com> From: "Venkatesh Venkataramanan" To: "'Arjun Roychowdhury'" , sipping@ietf.org, sipping-admin@ietf.org cc: "Anil Kumar" Subject: RE: [Sipping] I-D ACTION:draft-anil-sipping-bla-00.txt Date: Mon, 16 Jun 2003 10:47:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 12F0DD3E61305-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi: Good point.... For exclusive bridging to work, the UA MUST guarantee that the NOTIFY gets generated and acknowledged before the INVITE is sent out. Hence we chose the MUST strength for the same. I didnt' quite get the part as regards "called user experience" ? Are you meaning what would happen if all the UA's sent out INVITE to the same called party without sending a NOTIFY? regards, Venkatesh -----Original Message----- From: Arjun Roychowdhury [mailto:aroychow@hns.com] Sent: Friday, June 13, 2003 10:09 AM To: sipping@ietf.org; sipping-admin@ietf.org Subject: Re: [Sipping] I-D ACTION:draft-anil-sipping-bla-00.txt Quick comment: I would like to see a discussion on how potential race conflicts can be avoided. Since this draft proposes that endpoints essentially 'behave' themselves - ie before sending INVITE send NOTIFY, it is entirely possible that multiple INVITEs go out at the same time, each with different call-ids and other such race conditions. any thoughts on addressing the same wrt. called user experience :-) regds arjun -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301 212 7860 Internet-Drafts@ietf.org Sent by: sipping-admin@ietf.org 06/13/2003 07:50 AM Please respond to Internet-Drafts To: IETF-Announce: ; cc: sipping@ietf.org Subject: [Sipping] I-D ACTION:draft-anil-sipping-bla-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Implementing Bridged Line Appearances Using Session Initiation Protocol (SIP) Author(s) : A. Kumar, V. Venkataramanan Filename : draft-anil-sipping-bla-00.txt Pages : 12 Date : 2003-6-12 This document describes a proposal for implementing Bridged Line Appearance for SIP User Agents A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-anil-sipping-bla-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-anil-sipping-bla-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-anil-sipping-bla-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. ftp://anonymous@ftp.ietf.org/internet-drafts/draft-anil-sipping-bla-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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jun 17 01:37:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17676 for ; Tue, 17 Jun 2003 01:37:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5H5ajH08253 for sipping-archive@odin.ietf.org; Tue, 17 Jun 2003 01:36:45 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H5ajm08250 for ; Tue, 17 Jun 2003 01:36: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 BAA17672 for ; Tue, 17 Jun 2003 01:36:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S96x-0002o3-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 01:34:27 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19S96x-0002o0-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 01:34:27 -0400 Received: from www1.ietf.org (a.mx.viagraonlinenow.biz [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GId2a25979; Mon, 16 Jun 2003 14:39:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GIcCm25923 for ; Mon, 16 Jun 2003 14:38: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 OAA24825; Mon, 16 Jun 2003 14:38:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Rypf-00053p-00; Mon, 16 Jun 2003 14:35:55 -0400 Received: from gateway.hns.com ([208.236.67.13]) by ietf-mx with esmtp (Exim 4.12) id 19Rypd-00053m-00; Mon, 16 Jun 2003 14:35:54 -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 h5GIc4af002059; Mon, 16 Jun 2003 14:38:05 -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 h5GIbwsE022368; Mon, 16 Jun 2003 14:37:58 -0400 (EDT) To: "Venkatesh Venkataramanan" Cc: "Anil Kumar" , sipping@ietf.org, sipping-admin@ietf.org Subject: RE: [Sipping] I-D ACTION:draft-anil-sipping-bla-00.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Arjun Roychowdhury" Date: Mon, 16 Jun 2003 14:37:56 -0400 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.12 |February 13, 2003) at 06/16/2003 02:36:01 PM, Serialize complete at 06/16/2003 02:36:01 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: , Venky: My doubt got clarified after I read the ID again. One of my concerns was whether its possible for two calls to get initiated at the same time (ie is it possible that two terminals that send NFY at the same time, get 200OK and therefore make o/b calls). You mention that the EA would send a 4xx in this case, the moment it gets one early notify regds arjun -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301 212 7860 "Venkatesh Venkataramanan" 06/16/2003 01:47 PM To: "'Arjun Roychowdhury'" , sipping@ietf.org, sipping-admin@ietf.org cc: "Anil Kumar" Subject: RE: [Sipping] I-D ACTION:draft-anil-sipping-bla-00.txt Hi: Good point.... For exclusive bridging to work, the UA MUST guarantee that the NOTIFY gets generated and acknowledged before the INVITE is sent out. Hence we chose the MUST strength for the same. I didnt' quite get the part as regards "called user experience" ? Are you meaning what would happen if all the UA's sent out INVITE to the same called party without sending a NOTIFY? regards, Venkatesh -----Original Message----- From: Arjun Roychowdhury [mailto:aroychow@hns.com] Sent: Friday, June 13, 2003 10:09 AM To: sipping@ietf.org; sipping-admin@ietf.org Subject: Re: [Sipping] I-D ACTION:draft-anil-sipping-bla-00.txt Quick comment: I would like to see a discussion on how potential race conflicts can be avoided. Since this draft proposes that endpoints essentially 'behave' themselves - ie before sending INVITE send NOTIFY, it is entirely possible that multiple INVITEs go out at the same time, each with different call-ids and other such race conditions. any thoughts on addressing the same wrt. called user experience :-) regds arjun -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301 212 7860 Internet-Drafts@ietf.org Sent by: sipping-admin@ietf.org 06/13/2003 07:50 AM Please respond to Internet-Drafts To: IETF-Announce: ; cc: sipping@ietf.org Subject: [Sipping] I-D ACTION:draft-anil-sipping-bla-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Implementing Bridged Line Appearances Using Session Initiation Protocol (SIP) Author(s) : A. Kumar, V. Venkataramanan Filename : draft-anil-sipping-bla-00.txt Pages : 12 Date : 2003-6-12 This document describes a proposal for implementing Bridged Line Appearance for SIP User Agents A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-anil-sipping-bla-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-anil-sipping-bla-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-anil-sipping-bla-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. ftp://anonymous@ftp.ietf.org/internet-drafts/draft-anil-sipping-bla-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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jun 17 02:34:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00708 for ; Tue, 17 Jun 2003 02:34:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5H6XoR25472 for sipping-archive@odin.ietf.org; Tue, 17 Jun 2003 02:33:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H6Xom25468 for ; Tue, 17 Jun 2003 02:33: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 CAA00670 for ; Tue, 17 Jun 2003 02:33:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SA0C-0003QA-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 02:31:32 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SA0B-0003Q7-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 02:31:31 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H062a17111; Mon, 16 Jun 2003 20:06:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H05Xm17060 for ; Mon, 16 Jun 2003 20:05: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 UAA09388 for ; Mon, 16 Jun 2003 20:05:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S3wS-0000Xo-00 for sipping@ietf.org; Mon, 16 Jun 2003 20:03:16 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx with esmtp (Exim 4.12) id 19S3wR-0000Xk-00 for sipping@ietf.org; Mon, 16 Jun 2003 20:03:16 -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 h5H04uC07672; Tue, 17 Jun 2003 00:04:56 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Jun 2003 20:05:27 -0400 Message-ID: <0449D80A0E9B614A83FA9031B07E8D3B257B4F@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Guido Gybels'" , sipping@ietf.org Subject: RE: [Sipping] Text support in SIP phones Date: Mon, 16 Jun 2003 20:05:25 -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'm uncomfortable with the suggestion that RFC2793 be mandatory as a payload format for SIP telephone device implementations. Mr. Drage has already articulated several of the reasons I would put forward (i.e. some telephones need not support textual communication at all). I might add that alternative methods of sending textual information in the PSTN today (like SMS or similar instant messaging systems) have enjoyed profound adoption and marketshare that has not been rivaled by T.140, in my experience anyway. The SIP community has not been particularly enthusiastic about the RFC2793 paradigm in the past - and we have considered it for some applications. UNIX talk does not dominate textual communication in the modern Internet for a number of reasons - lack of an intelligible strategy for conferencing (which IRC and its numerous descendents, including AOL, MSN, and Yahoo messengers, easily mastered) being one obvious problem. Presumably, RFC2793 has the same NAT traversal and security properties as baseline RTP (i.e. STUN and sRTP are applicable), but I'm not sure if the latter is currently required for sip devices (and note that sharing keying material for RTP is still a somewhat controversial subject). The desired immediacy of T.140 would also, I imagine, be somewhat compromised by the crude manner in which we are compelled to 'dial' letters into virtually all telephones today (in which it takes much longer to reach 's' than 'p'). If we are to mandate or even encourage any means of textual communication in telephone devices, I think it should more closely correspond to the irrefutable direction of the marketplace - the instant messaging paradigm. I would categorically oppose mandating RFC2793 to the exclusion of, say, the outcome of SIMPLE's instant messaging sessions work. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Guido Gybels [mailto:Guido.Gybels@rnid.org.uk] > Sent: Monday, June 16, 2003 12:31 AM > To: sipping@ietf.org > Subject: RE: [Sipping] Text support in SIP phones > > > Henry, > > < "MUST", but "terminals offering real time text conversation > should support ITU-T > Recommendation T.140". I guess in IETF language the "should" > would be "SHOULD".>> > > I respectfully suggest that it is not because there exist > already a number of incomplete or even bad solutions today, > that we should refrain from improving. Taking 3G's GTT as an > example won't get us anywhere either since that is a solution > that is completely unfit for the European market. > I strongly suggest we look again at my previous suggesting: > make it MUST, except for well defined exceptions. That allows > to harmonize interactive texting while still allowing for > specific cases not to support it. It certainly is the most > robust business solution and makes sense as a mainstream > solution as well. > 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 > > > > > ************************************************************** > ********** > 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 > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Jun 17 09:22:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13933 for ; Tue, 17 Jun 2003 09:22:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HDMAP27748 for sipping-archive@odin.ietf.org; Tue, 17 Jun 2003 09:22:10 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HDMAm27745 for ; Tue, 17 Jun 2003 09:22: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 JAA13896 for ; Tue, 17 Jun 2003 09:22:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SGNL-0006fb-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 09:19:51 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SGNK-0006fR-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 09:19:50 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H7a4a32170; Tue, 17 Jun 2003 03:36:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H7Zom32140 for ; Tue, 17 Jun 2003 03:35: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 DAA01956 for ; Tue, 17 Jun 2003 03:35:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SAyC-0003kD-00 for sipping@ietf.org; Tue, 17 Jun 2003 03:33:32 -0400 Received: from [217.158.120.227] (helo=rnidmail.rnid.org.uk) by ietf-mx with esmtp (Exim 4.12) id 19SAyC-0003jh-00 for sipping@ietf.org; Tue, 17 Jun 2003 03:33:32 -0400 Received: from rnid.org.uk (unverified) by rnidmail.rnid.org.uk (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Tue, 17 Jun 2003 08:33:28 +0100 Received: from RNIDMAIL-Message_Server by rnid.org.uk with Novell_GroupWise; Tue, 17 Jun 2003 08:32:50 +0100 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Tue, 17 Jun 2003 08:32:10 +0100 From: "Guido Gybels" To: , Cc: Subject: RE: [Sipping] Text support in SIP phones Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5H7Zom32141 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Jon, Thanks for your clear comments. <> I do appreciate that there might be a need to exclude certain devices or device categories from providing such text support, but surely the best way to achieve a harmonized and mainstream solution is to do it by specifying those categories that do not support it? <> I'm sorry, we're missing the point here. SMS is not a viable alternative to realtime communication for deaf and hard of hearing people. It is not the equivalent of voice for hearing people. It is an additional modality that deaf people do use, because it fits their abilities and preferences. However, to communicate interactively using text. especially with a relay service, you need a character-by-character interactive communication. We are running a pilot and experiments comparing character-by-character conversations between deaf text users and hearing people over the RNID Typetalk relay service, and it is clear that message based communications do not fulfil there needs at all. With regard to T.140, there can hardly be any market assessment since it is simply not commonly available, unlike SMS for instance. <> First of all, when hearing people are being put in front of an interactive text based system like the ones based on T.140, they love it. The feeling of interactivity is much greater than with things like IM. But if users simply have no choice, sure than there is no market... <> Good point. But surely it is up to us in the technology community to define solutions, rather than avoid dealing with them? <> The way we have dealt with it in the RNID pilot is to use a proxy server to connect both ends, so that both user agents only make outbound connections, which obviously solves the firewall traversal and NAT problem. Also, IM systems like MSN etc, are not entirely immune to FW traversal and natting issues either when you start using their extended feature set. I won't even mention netmeeting. <> We are already looking at solutions for that, like (configurable) word based buffering on mobiles for instance, so that you can use small keyboards and predictive texting. Also, heavy text users might opt to connect larger keyboards to the system and I know at least one BT foldable keyboard for use with a mobile phone. SIP deskphones can have a full-size keyboard added to them where required. <> I'm not so sure that direction is so irrefutable as you claim it to be. The truth is that IM still is hampered by the whole interconnectivity issue and that users have not really had any choice so far. Releasing applications that do offer an alternative to IM by providing more character-by-character based implementations while providing interconnectivity with existing IM systems as well as legacy TTYs (like the current RNID pilot which will go public early 2004 and might even be offered license free) might change the current picture dramatically. If I would get a penny for every time someone in technology has claimed something was never going to happen and was proven incorrect afterwards <> I don't think that is what anyone is asking for. There is no reason at all why SIMPLE and RFC2793 cannot live together simultaneously. They are simply separate issues. Remember though that, certainly in Europe, IM will *not* fulfil the legal and regulatory obligations on service providers and manufacturers and that those obligations will become even more strict with the implementation of the famous 4 EC Directives on Communication which is now taking place in all the member states and should be completed over the next couple of months. RFC2793 will comply with those requirements. It's up to the community to decide whether or not they want to be burdened by more regulation or legislation or whether they will try to fulfil those requirements through mainstream solutions that will benefit their business case. 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 ************************************************************************ 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 Tue Jun 17 14:15: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 OAA29919 for ; Tue, 17 Jun 2003 14:15:56 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HIFS712943 for sipping-archive@odin.ietf.org; Tue, 17 Jun 2003 14:15:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SKw2-0002iG-Ow for sipping-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 14:11:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29431 for ; Tue, 17 Jun 2003 14:11:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SKtm-0002Yu-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 14:09:38 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SKtl-0002Yr-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 14:09:37 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HEq3a02488; Tue, 17 Jun 2003 10:52:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HEpRm02449 for ; Tue, 17 Jun 2003 10:51: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 KAA20568 for ; Tue, 17 Jun 2003 10:51:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SHlj-0000EC-00 for sipping@ietf.org; Tue, 17 Jun 2003 10:49:07 -0400 Received: from mailgate.siemenscomms.co.uk ([194.129.217.115]) by ietf-mx with esmtp (Exim 4.12) id 19SHlj-0000Cb-00 for sipping@ietf.org; Tue, 17 Jun 2003 10:49:07 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0HGM00501RTSYX@siemenscomms.co.uk> for sipping@ietf.org; Tue, 17 Jun 2003 15:49:23 +0100 (BST) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #45905) with ESMTP id <0HGM005JHRTNSA@siemenscomms.co.uk>; Tue, 17 Jun 2003 15:49:00 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Tue, 17 Jun 2003 15:49:39 +0100 Content-return: allowed Date: Tue, 17 Jun 2003 15:49:54 +0100 From: "Elwell, John" Subject: RE: [Sipping] WGLC for Q.SIP-SIP mapping draft To: "'Adam Roach'" , "'Gonzalo Camarillo Gonzalez (LMF)'" , "'sipping@ietf.org'" Cc: "Rohan Mahy (E-mail)" , "Dean Willis (E-mail)" , "Patrick Mourot (E-mail)" , "Olivier Rousseau (E-mail)" , "Frank Derks (E-mail)" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Adam, Reference [19] is there only for the purpose of overlap - it intentionally refers to the overlap draft rather than RFC3398. My assumption is that the overlap draft will receive an RFC number shortly, and then reference [19] can be changed. John (john.elwell@siemens.com) > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: 13 June 2003 02:18 > To: 'Gonzalo Camarillo Gonzalez (LMF)'; 'sipping@ietf.org' > Cc: Rohan Mahy (E-mail); Dean Willis (E-mail); Patrick Mourot > (E-mail); > Olivier Rousseau (E-mail); Frank Derks (E-mail) > Subject: RE: [Sipping] WGLC for Q.SIP-SIP mapping draft > > > Reference [19] should point to RFC 3398 instead of the draft-... > Also, the overlap discussion was split out of that document, so > the references to overlap procedures need to be updated. > > I'll try to find time to give this document a more thorough review > later next week. > > /a > > > -----Original Message----- > > From: Gonzalo Camarillo Gonzalez (LMF) > > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: Tuesday, May 27, 2003 1:04 > > To: 'sipping@ietf.org' > > Cc: Rohan Mahy (E-mail); Dean Willis (E-mail); Patrick Mourot > > (E-mail); > > Olivier Rousseau (E-mail); Frank Derks (E-mail) > > Subject: [Sipping] WGLC for Q.SIP-SIP mapping draft > > > > > > Folks, > > > > we would like to WGLC the draft below: > > > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-01.txt > > This WGLC will end on June 20th. > > 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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 17 14:17:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00305 for ; Tue, 17 Jun 2003 14:17:07 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HIGdu13785 for sipping-archive@odin.ietf.org; Tue, 17 Jun 2003 14:16:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SKyp-00038l-JS for sipping-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 14:14: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 OAA29662 for ; Tue, 17 Jun 2003 14:14:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SKwZ-0002e3-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 14:12:31 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SKwZ-0002e0-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 14:12:31 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HE43a30438; Tue, 17 Jun 2003 10:04:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HE3vm30418 for ; Tue, 17 Jun 2003 10:03: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 KAA16520 for ; Tue, 17 Jun 2003 10:03:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SH1m-0007Nw-00 for sipping@ietf.org; Tue, 17 Jun 2003 10:01:38 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19SH1l-0007Ml-00 for sipping@ietf.org; Tue, 17 Jun 2003 10:01:37 -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 h5HE2K6r028513; Tue, 17 Jun 2003 07:02:23 -0700 (PDT) Received: from mhammer-w2k02.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 AED92349; Tue, 17 Jun 2003 07:02:19 -0700 (PDT) Message-Id: <4.3.2.7.2.20030617095346.00b4e8f8@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 17 Jun 2003 10:02:19 -0400 To: "Guido Gybels" From: Michael Hammer Subject: RE: [Sipping] Text support in SIP phones Cc: , , In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_3216044==_.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: , --=====================_3216044==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 08:32 AM 6/17/2003 +0100, Guido Gybels wrote: >First of all, when hearing people are being put in front of an interactive >text based system like the ones based on T.140, they love it. The feeling >of interactivity is much greater than with things like IM. But if users >simply have no choice, sure than there is no market... Guido, Personally speaking, and maybe I have ADD, but I would find watching someone type mildly interesting in the short run, but as boring as watching grass grow in the long run. I would more likely turn my attention to other tasks at work and come back later when they are done typing. Frankly, I don't see that this is so different from IM. Also, as a sender, I would prefer to have my thoughts laid out before me before hitting the send button. So, I'm not so sure we can draw well-founded conclusions based on some anecdotal evidence. That is not to say that we can't offer both modes. I'm sure those (on both sides) that had no choice have a strong affinity to what they are used to, but I'm not so sure which they would choose if both were available. Mike --=====================_3216044==_.ALT Content-Type: text/html; charset="us-ascii" At 08:32 AM 6/17/2003 +0100, Guido Gybels wrote:
First of all, when hearing people are being put in front of an interactive text based system like the ones based on T.140, they love it. The feeling of interactivity is much greater than with things like IM. But if users simply have no choice, sure than there is no market...

Guido,

Personally speaking, and maybe I have ADD, but I would find watching someone type mildly interesting in the short run, but as boring as watching grass grow in the long run.  I would more likely turn my attention to other tasks at work and come back later when they are done typing.  Frankly, I don't see that this is so different from IM.  Also, as a sender, I would prefer to have my thoughts laid out before me before hitting the send button.  So, I'm not so sure we can draw well-founded conclusions based on some anecdotal evidence.

That is not to say that we can't offer both modes.  I'm sure those (on both sides) that had no choice have a strong affinity to what they are used to, but I'm not so sure which they would choose if both were available.

Mike
 --=====================_3216044==_.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 Jun 17 14:17:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00310 for ; Tue, 17 Jun 2003 14:17:07 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HIGdC13819 for sipping-archive@odin.ietf.org; Tue, 17 Jun 2003 14:16:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SKz9-00039R-Eu for sipping-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 14: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 OAA29680 for ; Tue, 17 Jun 2003 14:15:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SKwt-0002eJ-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 14:12:51 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SKwt-0002eE-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 14:12:51 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HFu3a07534; Tue, 17 Jun 2003 11:56:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HFtYm07509 for ; Tue, 17 Jun 2003 11: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 LAA23878 for ; Tue, 17 Jun 2003 11:55:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SIlo-00017R-00 for sipping@ietf.org; Tue, 17 Jun 2003 11:53:16 -0400 Received: from [204.42.169.163] (helo=elmer.LEAPSTONE.COM) by ietf-mx with esmtp (Exim 4.12) id 19SIlo-00016L-00 for sipping@ietf.org; Tue, 17 Jun 2003 11:53:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] Call Waiting - who does the tone Date: Tue, 17 Jun 2003 11:55:47 -0400 Message-ID: <59A835EDCDDBEB46BC75402F4604D5520107AC73@elmer> Thread-Topic: [Sipping] Call Waiting - who does the tone Thread-Index: AcM04mObDnNJoC7YQqaac5DYz4M9pwABJUXg From: "Dusan Mudric" To: "Rosen, Brian" , "Alan Hawrylyshen" , "Satish Bansal!" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5HFtYm07510 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit There is an existing SIP busy that can be used to offer multi-party call waiting announcement service. Off-hook from terminating party would be signaled with re-INVITE. Regards, Dusan Mudric. -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Tuesday, June 17, 2003 11:07 AM To: Dusan Mudric; Alan Hawrylyshen; Satish Bansal! Cc: sipping@ietf.org Subject: RE: [Sipping] Call Waiting - who does the tone If this was desirable, which I don't personally believe it is, I don't think there exists a sip mechanism that would enable it. Are you proposing we create one? Brian -----Original Message----- From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] Sent: Tuesday, June 17, 2003 11:04 AM To: Alan Hawrylyshen; Satish Bansal! Cc: Rosen, Brian; sipping@ietf.org Subject: RE: [Sipping] Call Waiting - who does the tone Call Waiting service in the core of the network offers more flexible solution to service providers. They can chose which media server to use and type of announcement message to play to the end user waiting on the call. This would be a part of service offering (in this particular example, call waiting) to a subscriber. In addition, it is UA independent. Regards, Dusan Mudric. Senior Sw Engineer Leapstone Systems Inc. -----Original Message----- From: Alan Hawrylyshen [mailto:alan@jasomi.com] Sent: Saturday, June 14, 2003 5:28 PM To: Satish Bansal! Cc: Rosen, Brian; 'sipping@ietf.org' Subject: Re: [Sipping] Call Waiting - who does the tone On Saturday, Jun 14, 2003, at 01:27 Canada/Mountain, Satish Bansal! wrote: There could be two options. First as you said, a dump phone should handle call waiting. It would mean that we are making end nodes intelligent. Second option is that intelligence is in the network, the inbound proxy should be call statefull and should use 3pcc for playing tone & annc. through a server to the party. 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 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). 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 maintain and deploy the 'core' portion of a SIP network infrastructure. I would agree w/ Brian on this; this could be appropriate for inclusion in a BCP document. De-lurking, Alan Hawrylyshen Jasomi Networks Inc. sip:alan@jasomi.com mailto:alan@jasomi.com http://www.jasomi.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 Jun 17 14:34:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01756 for ; Tue, 17 Jun 2003 14:34:48 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HIYLo17954 for sipping-archive@odin.ietf.org; Tue, 17 Jun 2003 14:34:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SLHT-0004es-VU for sipping-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 14: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 OAA01699 for ; Tue, 17 Jun 2003 14:34:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SLFD-00032V-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 14:31:47 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SLFD-00032S-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 14:31:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HEV3a00445; Tue, 17 Jun 2003 10:31:03 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HEUxm00394 for ; Tue, 17 Jun 2003 10:30: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 KAA19489 for ; Tue, 17 Jun 2003 10:30:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SHRw-00000R-00 for sipping@ietf.org; Tue, 17 Jun 2003 10:28:40 -0400 Received: from [217.158.120.227] (helo=rnidmail.rnid.org.uk) by ietf-mx with esmtp (Exim 4.12) id 19SHRv-000006-00 for sipping@ietf.org; Tue, 17 Jun 2003 10:28:39 -0400 Received: from rnid.org.uk (unverified) by rnidmail.rnid.org.uk (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Tue, 17 Jun 2003 15:28:08 +0100 Received: from RNIDMAIL-Message_Server by rnid.org.uk with Novell_GroupWise; Tue, 17 Jun 2003 15:27:27 +0100 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Tue, 17 Jun 2003 15:26:44 +0100 From: "Guido Gybels" To: Cc: , , Subject: RE: [Sipping] Text support in SIP phones Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5HEUxm00395 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Michael, <> To be quite frank about this, I was speaking about what deaf and hard of hearing people want as a group, not necessarily what you or I want as individuals or as techies. Believe me, I have argued a lot about this and talked about IM with them etc. The point is that if it doesn't suit their requirements, we have to accept that. The technology should adapt to the user, not the other way around. Apart from that, you have however missed my most important point, namely the use of a relay service. When a deaf person wants to talk to a hearing person over the relay service, the IM model simply does not work. The operators will be speaking to the hearing party as words come through and type back to the deaf users almost simultaneously as the voice from the hearing party comes true. That is the closest deaf and hard of hearing people can get. We have done trials with our gateway and RNID Typetalk using deaf and hard of hearing people and the number 1 item was that the message style conversation didn't work for them at all in that scenario. I think we should accept that the user requirements are the predominant driving factor here, not what we would like to develop. I'll leave it to Arnoud, who is deaf, to comment on this from the user perspective, but based on our research, I'm quite sure I'm right about this. As to finding it boring: I have actually used both systems and to be honest I find IM much more frustrating than character-by-character. I accept that my individual judgement doesn't constitute relevant data, but neither does your personal assessment of it being boring. Let's accept that user requirements drive this. <> Which misses the point about using text as an equivalent to voice altogether, I'm afraid. Deaf people are not using text as an additional medium, it is their version of talking to someone over the phone. I would respectfully suggest that we therefore allow *them* to odentify what they want as users, rather than having us tell them what they want. <> Excuse me, the trials we have conducted recently and in the past, as well as the experience of 10 years of running RNID Typetalk constitute quite relevant expertise. That is quite different to individuals in here voicing their personal opinions and speaking on behalf of deaf and hard of hearing people. There is currently a research project going on under the auspices of TAG in the UK, using independent researchers to verify the current assumptions and user requirements. I'm more than happy to publish those results to IETF when they become available. I take it that you all then agree to accept the outcome of that independent research? Do I have a commitment on that?? <> You miss the point that hundreds of thousands of deaf people DO use IM. As they use other text based solutions in mainstream technology. And they say to us clearly that it doesn't meet their needs. So, I accept that the users are telling me what they need/want. Not the other way around. 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 ************************************************************************ 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 Tue Jun 17 15:02:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29918 for ; Tue, 17 Jun 2003 14:15:56 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HIFRr12924 for sipping-archive@odin.ietf.org; Tue, 17 Jun 2003 14:15:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SKv1-0002gX-H3 for sipping-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 14:10: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 OAA29327 for ; Tue, 17 Jun 2003 14:10:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SKsl-0002XM-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 14:08:35 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SKsl-0002XJ-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 14:08:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HF92a04374; Tue, 17 Jun 2003 11:09:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HF8Am04324 for ; Tue, 17 Jun 2003 11: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 LAA21403 for ; Tue, 17 Jun 2003 11:08:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SI1u-0000SI-00 for sipping@ietf.org; Tue, 17 Jun 2003 11:05:50 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19SI1t-0000S3-00 for sipping@ietf.org; Tue, 17 Jun 2003 11:05:49 -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 LAA09858; Tue, 17 Jun 2003 11:07:32 -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 LAA18726; Tue, 17 Jun 2003 11:07:32 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jun 2003 11:07:32 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5AF3@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Dusan Mudric'" , Alan Hawrylyshen , Satish Bansal! Cc: sipping@ietf.org Subject: RE: [Sipping] Call Waiting - who does the tone Date: Tue, 17 Jun 2003 11:07:23 -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: , If this was desirable, which I don't personally believe it is, I don't think there exists a sip mechanism that would enable it. Are you proposing we create one? Brian -----Original Message----- From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] Sent: Tuesday, June 17, 2003 11:04 AM To: Alan Hawrylyshen; Satish Bansal! Cc: Rosen, Brian; sipping@ietf.org Subject: RE: [Sipping] Call Waiting - who does the tone Call Waiting service in the core of the network offers more flexible solution to service providers. They can chose which media server to use and type of announcement message to play to the end user waiting on the call. This would be a part of service offering (in this particular example, call waiting) to a subscriber. In addition, it is UA independent. Regards, Dusan Mudric. Senior Sw Engineer Leapstone Systems Inc. -----Original Message----- From: Alan Hawrylyshen [mailto:alan@jasomi.com] Sent: Saturday, June 14, 2003 5:28 PM To: Satish Bansal! Cc: Rosen, Brian; 'sipping@ietf.org' Subject: Re: [Sipping] Call Waiting - who does the tone On Saturday, Jun 14, 2003, at 01:27 Canada/Mountain, Satish Bansal! wrote: There could be two options. First as you said, a dump phone should handle call waiting. It would mean that we are making end nodes intelligent. Second option is that intelligence is in the network, the inbound proxy should be call statefull and should use 3pcc for playing tone & annc. through a server to the party. 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 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). 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 maintain and deploy the 'core' portion of a SIP network infrastructure. I would agree w/ Brian on this; this could be appropriate for inclusion in a BCP document. De-lurking, Alan Hawrylyshen Jasomi Networks Inc. sip:alan@jasomi.com mailto:alan@jasomi.com http://www.jasomi.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 Jun 17 15:23:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06035 for ; Tue, 17 Jun 2003 15:23:48 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HJNJR11388 for sipping-archive@odin.ietf.org; Tue, 17 Jun 2003 15:23:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SLaZ-0006Mg-NF for sipping-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 14:53: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 OAA02692 for ; Tue, 17 Jun 2003 14:53:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SLYJ-0003GZ-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 14:51:31 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SLYI-0003GW-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 14:51:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HFC0a04533; Tue, 17 Jun 2003 11:12:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HFBem04509 for ; Tue, 17 Jun 2003 11:11:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21649 for ; Tue, 17 Jun 2003 11:11:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SI5J-0000WW-00 for sipping@ietf.org; Tue, 17 Jun 2003 11:09:21 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19SI5I-0000WM-00 for sipping@ietf.org; Tue, 17 Jun 2003 11:09:20 -0400 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5HFAmUm029062; Tue, 17 Jun 2003 08:10:49 -0700 (PDT) Received: from mhammer-w2k02.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 AEE09164; Tue, 17 Jun 2003 08:10:47 -0700 (PDT) Message-Id: <4.3.2.7.2.20030617104845.00b4ee18@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 17 Jun 2003 11:10:06 -0400 To: "Guido Gybels" From: Michael Hammer Subject: RE: [Sipping] Text support in SIP phones Cc: , , In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_7323690==_.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: , --=====================_7323690==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Guido, Please don't get so defensive. You missed the whole point of my statement, which has little to do with what deaf people prefer, and everything to do with what non-deaf people might prefer, if both parties were using text-based near-real-time communications. I was responding to your suggestion that non-deaf users would also prefer the character-by-character mode of operation. I was simply disagreeing with that assertion. I was also up front that mine was simply an individual opinion. The studies that you cite seemed to be focused on determining what the deaf experience, and your added comments concerning non-deaf experience appeared anecdotal. I was merely suggesting that the experiences of both sides of the communication should be taken into account, for both the asymmetrical (text/voice) and symmetrical (both text) types of exchanges. Your point about the nature of the experience when dealing with the situation where one party is using text and the other is using voice is a key distinguishing factor. I appreciate the education I am getting by following the discussion. But, please don't attack me for questioning what the studies are really saying based on the limited information provided thus far, or for exploring alternative experiences and opinions. Mike At 03:26 PM 6/17/2003 +0100, Guido Gybels wrote: >Michael, > ><watching someone type mildly interesting in the short run, but as boring >as watching grass grow in the long run.>> > >To be quite frank about this, I was speaking about what deaf and hard of >hearing people want as a group, not necessarily what you or I want as >individuals or as techies. Believe me, I have argued a lot about this and >talked about IM with them etc. The point is that if it doesn't suit their >requirements, we have to accept that. The technology should adapt to the >user, not the other way around. >Apart from that, you have however missed my most important point, namely >the use of a relay service. When a deaf person wants to talk to a hearing >person over the relay service, the IM model simply does not work. The >operators will be speaking to the hearing party as words come through and >type back to the deaf users almost simultaneously as the voice from the >hearing party comes true. That is the closest deaf and hard of hearing >people can get. We have done trials with our gateway and RNID Typetalk >using deaf and hard of hearing people and the number 1 item was that the >message style conversation didn't work for them at all in that scenario. I >think we should accept that the user requirements are the predominant >driving factor here, not what we would like to develop. I'll leave it to >Arnoud, who is deaf, to comment on this from the user perspective, but >based on our research, I'm quite sure I'm right about this. >As to finding it boring: I have actually used both systems and to be >honest I find IM much more frustrating than character-by-character. I >accept that my individual judgement doesn't constitute relevant data, but >neither does your personal assessment of it being boring. Let's accept >that user requirements drive this. > ><back later when they are done typing.>> > >Which misses the point about using text as an equivalent to voice >altogether, I'm afraid. Deaf people are not using text as an additional >medium, it is their version of talking to someone over the phone. I would >respectfully suggest that we therefore allow *them* to odentify what they >want as users, rather than having us tell them what they want. > ><anecdotal evidence.>> > >Excuse me, the trials we have conducted recently and in the past, as well >as the experience of 10 years of running RNID Typetalk constitute quite >relevant expertise. That is quite different to individuals in here voicing >their personal opinions and speaking on behalf of deaf and hard of hearing >people. >There is currently a research project going on under the auspices of TAG >in the UK, using independent researchers to verify the current assumptions >and user requirements. I'm more than happy to publish those results to >IETF when they become available. I take it that you all then agree to >accept the outcome of that independent research? Do I have a commitment on >that?? > ><to what they are used to, but I'm not so sure which they would choose if >both were available.>> > >You miss the point that hundreds of thousands of deaf people DO use IM. As >they use other text based solutions in mainstream technology. And they say >to us clearly that it doesn't meet their needs. So, I accept that the >users are telling me what they need/want. Not the other way around. > >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 > > > > >************************************************************************ >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 >************************************************************************ --=====================_7323690==_.ALT Content-Type: text/html; charset="us-ascii" Guido,

Please don't get so defensive. 

You missed the whole point of my statement, which has little to do with what deaf people prefer, and everything to do with what non-deaf people might prefer, if both parties were using text-based near-real-time communications.

I was responding to your suggestion that non-deaf users would also prefer the character-by-character mode of operation.  I was simply disagreeing with that assertion.  I was also up front that mine was simply an individual opinion.

The studies that you cite seemed to be focused on determining what the deaf experience, and your added comments concerning non-deaf experience appeared anecdotal.  I was merely suggesting that the experiences of both sides of the communication should be taken into account, for both the asymmetrical (text/voice) and symmetrical (both text) types of exchanges.

Your point about the nature of the experience when dealing with the situation where one party is using text and the other is using voice is a key distinguishing factor.

I appreciate the education I am getting by following the discussion.  But, please don't attack me for questioning what the studies are really saying based on the limited information provided thus far, or for exploring alternative experiences and opinions.

Mike


At 03:26 PM 6/17/2003 +0100, Guido Gybels wrote:
Michael,

<<Personally speaking, and maybe I have ADD, but I would find watching  someone type mildly interesting in the short run, but as boring as watching  grass grow in the long run.>>

To be quite frank about this, I was speaking about what deaf and hard of hearing people want as a group, not necessarily what you or I want as individuals or as techies. Believe me, I have argued a lot about this and talked about IM with them etc. The point is that if it doesn't suit their requirements, we have to accept that. The technology should adapt to the user, not the other way around.
Apart from that, you have however missed my most important point, namely the use of a relay service. When a deaf person wants to talk to a hearing person over the relay service, the IM model simply does not work. The operators will be speaking to the hearing party as words come through and type back to the deaf users almost simultaneously as the voice from the hearing party comes true. That is the closest deaf and hard of hearing people can get. We have done trials with our gateway and RNID Typetalk using deaf and hard of hearing people and the number 1 item was that the message style conversation didn't work for them at all in that scenario. I think we should accept that the user requirements are the predominant driving factor here, not what we would like to develop. I'll leave it to Arnoud, who is deaf, to comment on this from the user perspective, but based on our research, I'm quite sure I'm right about this.
As to finding it boring: I have actually used both systems and to be honest I find IM much more frustrating than character-by-character. I accept that my individual judgement doesn't constitute relevant data, but neither does your personal assessment of it being boring. Let's accept that user requirements drive this.

<<I would more likely turn my attention to other tasks at work and come back later when they are done typing.>>

Which misses the point about using text as an equivalent to voice altogether, I'm afraid. Deaf people are not using text as an additional medium, it is their version of talking to someone over the phone. I would respectfully suggest that we therefore allow *them* to odentify what they want as users, rather than having us tell them what they want.

<<So, I'm not so sure we can draw well-founded conclusions based on some anecdotal evidence.>>

Excuse me, the trials we have conducted recently and in the past, as well as the experience of 10 years of running RNID Typetalk constitute quite relevant expertise. That is quite different to individuals in here voicing their personal opinions and speaking on behalf of deaf and hard of hearing people.
There is currently a research project going on under the auspices of TAG in the UK, using independent researchers to verify the current assumptions and user requirements. I'm more than happy to publish those results to IETF when they become available. I take it that you all then agree to accept the outcome of that independent research? Do I have a commitment on that??

<<I'm sure those (on both sides) that had no choice have a strong affinity to what they are used to,  but I'm not so sure which they would choose if both were available.>>

You miss the point that hundreds of thousands of deaf people DO use IM. As they use other text based solutions in mainstream technology. And they say to us clearly that it doesn't meet their needs. So, I accept that the users are telling me what they need/want. Not the other way around.

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




************************************************************************
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
************************************************************************
--=====================_7323690==_.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 Jun 17 15:23:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06064 for ; Tue, 17 Jun 2003 15:23:49 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HJNJm11472 for sipping-archive@odin.ietf.org; Tue, 17 Jun 2003 15:23:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SLdQ-0006XH-DZ for sipping-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 14:56: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 OAA02840 for ; Tue, 17 Jun 2003 14:56:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SLbA-0003JN-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 14:54:28 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SLb9-0003JK-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 14:54:27 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HF45a03140; Tue, 17 Jun 2003 11:04:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HF3Zm03082 for ; Tue, 17 Jun 2003 11:03: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 LAA21153 for ; Tue, 17 Jun 2003 11:03:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SHxT-0000NR-00 for sipping@ietf.org; Tue, 17 Jun 2003 11:01:15 -0400 Received: from [204.42.169.163] (helo=elmer.LEAPSTONE.COM) by ietf-mx with esmtp (Exim 4.12) id 19SHxS-0000NE-00 for sipping@ietf.org; Tue, 17 Jun 2003 11:01:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C334E1.A5657704" Subject: RE: [Sipping] Call Waiting - who does the tone Date: Tue, 17 Jun 2003 11:03:44 -0400 Message-ID: <59A835EDCDDBEB46BC75402F4604D5520107AC72@elmer> Thread-Topic: [Sipping] Call Waiting - who does the tone Thread-Index: AcM0fkMOwyj8BqU6SZSkZpL5zlseTwAYd9yw From: "Dusan Mudric" To: "Alan Hawrylyshen" , "Satish Bansal!" Cc: "Rosen, Brian" , Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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_01C334E1.A5657704 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Call Waiting service in the core of the network offers more flexible = solution to service providers. They can chose which media server to use = and type of announcement message to play to the end user waiting on the = call. This would be a part of service offering (in this particular = example, call waiting) to a subscriber. In addition, it is UA = independent. =20 Regards, Dusan Mudric. Senior Sw Engineer Leapstone Systems Inc. =20 -----Original Message----- From: Alan Hawrylyshen [mailto:alan@jasomi.com] Sent: Saturday, June 14, 2003 5:28 PM To: Satish Bansal! Cc: Rosen, Brian; 'sipping@ietf.org' Subject: Re: [Sipping] Call Waiting - who does the tone =20 On Saturday, Jun 14, 2003, at 01:27 Canada/Mountain, Satish Bansal! = wrote:=20 =20 There could be two options. First as you said, a dump phone should = handle call waiting. It would mean that we are making end nodes = intelligent.=20 =20 Second option is that intelligence is in the network, the inbound proxy = should be call statefull and should use 3pcc for playing tone & annc. = through a server to the party.=20 =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 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 =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 = maintain and deploy the 'core' portion of a SIP network infrastructure.=20 =20 I would agree w/ Brian on this; this could be appropriate for inclusion = in a BCP document.=20 =20 De-lurking,=20 =20 Alan Hawrylyshen Jasomi Networks Inc.=20 sip:alan@jasomi.com mailto:alan@jasomi.com=20 http://www.jasomi.com/=20 ------_=_NextPart_001_01C334E1.A5657704 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Ca= ll Waiting service in the core of the network offers more flexible solution = to service providers. They can chose which media server to use and type of = announcement message to play to the end user waiting on the call. This would be a = part of service offering (in this particular example, call waiting) to a = subscriber. In addition, it is UA independent.

 

Regards,

Dusan Mudric.

Senior Sw = Engineer

Leapstone Systems = Inc.

<= span class=3DEmailStyle15> 

-----Original Message-----
From: Alan Hawrylyshen [mailto:alan@jasomi.com]
Sent: Saturday, June 14, = 2003 5:28 PM
To: Satish Bansal!
Cc: Rosen, Brian; 'sipping@ietf.org'
Subject: Re: [Sipping] = Call Waiting - who does the tone

 

On = Saturday, Jun 14, 2003, at 01:27 Canada/Mountain, Satish Bansal! wrote: = <= /p>

 <= /p>

There could be two options. First = as you said,  a dump phone should handle call waiting. It would mean that = we are making  end nodes intelligent. <= /p>

 <= /p>

Second option is that = intelligence is in the  network, the inbound proxy should be call statefull and should = use 3pcc for playing tone & annc. through a server to  the party. = <= /p>

 <= /p>

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 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). = <= /p>

 <= /p>

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 maintain and deploy the = 'core' portion of a SIP network infrastructure. <= /p>

 <= /p>

I = would agree w/ Brian on this; this could be appropriate for inclusion in a BCP = document. <= /p>

 <= /p>

De-lurking, <= /p>

 <= /p>

Alan Hawrylyshen Jasomi Networks Inc. <= /o:p>

sip:alan@jasom= i.com mailto:alan@jasomi.com <= /o:p>

http://www.jas= omi.com/

------_=_NextPart_001_01C334E1.A5657704-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 17 15:41:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06875 for ; Tue, 17 Jun 2003 15:41:07 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HJedQ16220 for sipping-archive@odin.ietf.org; Tue, 17 Jun 2003 15:40:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SLqz-0000Bg-Kl for sipping-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 15:10:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04515 for ; Tue, 17 Jun 2003 15:10:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SLoj-0003b2-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 15:08:29 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SLoi-0003az-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 15:08:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SKzz-0003Pj-PC; Tue, 17 Jun 2003 14:16:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus with esmtp (Exim 4.20) id 19SJt3-0003vl-1m for sipping@optimus.ietf.org; Tue, 17 Jun 2003 13:04: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 NAA26384 for ; Tue, 17 Jun 2003 13:04:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SJqo-0001lU-00 for sipping@ietf.org; Tue, 17 Jun 2003 13:02:30 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19SJqn-0001l8-00 for sipping@ietf.org; Tue, 17 Jun 2003 13:02:29 -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 NAA13639; Tue, 17 Jun 2003 13:04:14 -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 NAA04728; Tue, 17 Jun 2003 13:04:15 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jun 2003 13:04:14 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5AF4@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Dusan Mudric'" , "Rosen, Brian" , Alan Hawrylyshen , Satish Bansal! Cc: sipping@ietf.org Subject: RE: [Sipping] Call Waiting - who does the tone Date: Tue, 17 Jun 2003 13:04:09 -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: , Hmmm, please explain. I don't think there is any "busy" (which is usually a 400 class response to an INVITE) that creates a media connection. Of course, usually call waiting is overlaid (mixed) with live audio, but even as an independent media stream, you can't use 3PCC to cause the called party to put his existing call on hold. You would have to force both ends of the call to reroute to a mixer. A middle box can't do that, and it isn't likely to work smoothly at all. Brian > -----Original Message----- > From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] > Sent: Tuesday, June 17, 2003 11:56 AM > To: Rosen, Brian; Alan Hawrylyshen; Satish Bansal! > Cc: sipping@ietf.org > Subject: RE: [Sipping] Call Waiting - who does the tone > > > There is an existing SIP busy that can be used to offer > multi-party call waiting announcement service. Off-hook from > terminating party would be signaled with re-INVITE. > > Regards, > Dusan Mudric. > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Tuesday, June 17, 2003 11:07 AM > To: Dusan Mudric; Alan Hawrylyshen; Satish Bansal! > Cc: sipping@ietf.org > Subject: RE: [Sipping] Call Waiting - who does the tone > > If this was desirable, which I don't personally believe it is, > I don't think there exists a sip mechanism that would enable it. > Are you proposing we create one? > > Brian > -----Original Message----- > From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] > Sent: Tuesday, June 17, 2003 11:04 AM > To: Alan Hawrylyshen; Satish Bansal! > Cc: Rosen, Brian; sipping@ietf.org > Subject: RE: [Sipping] Call Waiting - who does the tone > > > Call Waiting service in the core of the network offers more flexible > solution to service providers. They can chose which media > server to use and > type of announcement message to play to the end user waiting > on the call. > This would be a part of service offering (in this particular > example, call > waiting) to a subscriber. In addition, it is UA independent. > > Regards, > Dusan Mudric. > Senior Sw Engineer > Leapstone Systems Inc. > > -----Original Message----- > From: Alan Hawrylyshen [mailto:alan@jasomi.com] > Sent: Saturday, June 14, 2003 5:28 PM > To: Satish Bansal! > Cc: Rosen, Brian; 'sipping@ietf.org' > Subject: Re: [Sipping] Call Waiting - who does the tone > > On Saturday, Jun 14, 2003, at 01:27 Canada/Mountain, Satish > Bansal! wrote: > > There could be two options. First as you said, a dump phone > should handle > call waiting. It would mean that we are making end nodes > intelligent. > > Second option is that intelligence is in the network, the > inbound proxy > should be call statefull and should use 3pcc for playing tone & annc. > through a server to the party. > > 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 > 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). > > 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 > maintain and > deploy the 'core' portion of a SIP network infrastructure. > > I would agree w/ Brian on this; this could be appropriate for > inclusion in a > BCP document. > > De-lurking, > > Alan Hawrylyshen Jasomi Networks Inc. > sip:alan@jasomi.com mailto:alan@jasomi.com > http://www.jasomi.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 Jun 17 15:41:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07046 for ; Tue, 17 Jun 2003 15:41:19 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HJeoB17899 for sipping-archive@odin.ietf.org; Tue, 17 Jun 2003 15:40:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SM2J-0002fx-5A for sipping-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 15:22: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 PAA05796 for ; Tue, 17 Jun 2003 15:22:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SM04-0003pS-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 15:20:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SM04-0003pP-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 15:20:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SL0v-0003bf-Cg; Tue, 17 Jun 2003 14: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 19SKwg-0002rU-1C for sipping@optimus.ietf.org; Tue, 17 Jun 2003 14:12: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 OAA29481 for ; Tue, 17 Jun 2003 14:12:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SKuQ-0002Zx-00 for sipping@ietf.org; Tue, 17 Jun 2003 14:10:18 -0400 Received: from [204.42.169.163] (helo=elmer.LEAPSTONE.COM) by ietf-mx with esmtp (Exim 4.12) id 19SKuP-0002ZE-00 for sipping@ietf.org; Tue, 17 Jun 2003 14:10:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] Call Waiting - who does the tone Date: Tue, 17 Jun 2003 14:12:45 -0400 Message-ID: <59A835EDCDDBEB46BC75402F4604D5520107AC74@elmer> Thread-Topic: [Sipping] Call Waiting - who does the tone Thread-Index: AcM08rZoX1sf36oURI+pb5IU6zkJ+gAB7VDQ From: "Dusan Mudric" To: "Rosen, Brian" , "Alan Hawrylyshen" , "Satish Bansal!" Cc: Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA07046 Media connection can be established on 486 busy. It would be very similar call flow as in draft-ietf-sipping-service-examples-04.txt, 2.7 Call Forwarding - Busy. Btw, we should add this service description in the mentioned draft. Regards, Dusan Mudric. -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Tuesday, June 17, 2003 1:04 PM To: Dusan Mudric; Rosen, Brian; Alan Hawrylyshen; Satish Bansal! Cc: sipping@ietf.org Subject: RE: [Sipping] Call Waiting - who does the tone Hmmm, please explain. I don't think there is any "busy" (which is usually a 400 class response to an INVITE) that creates a media connection. Of course, usually call waiting is overlaid (mixed) with live audio, but even as an independent media stream, you can't use 3PCC to cause the called party to put his existing call on hold. You would have to force both ends of the call to reroute to a mixer. A middle box can't do that, and it isn't likely to work smoothly at all. Brian > -----Original Message----- > From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] > Sent: Tuesday, June 17, 2003 11:56 AM > To: Rosen, Brian; Alan Hawrylyshen; Satish Bansal! > Cc: sipping@ietf.org > Subject: RE: [Sipping] Call Waiting - who does the tone > > > There is an existing SIP busy that can be used to offer > multi-party call waiting announcement service. Off-hook from > terminating party would be signaled with re-INVITE. > > Regards, > Dusan Mudric. > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Tuesday, June 17, 2003 11:07 AM > To: Dusan Mudric; Alan Hawrylyshen; Satish Bansal! > Cc: sipping@ietf.org > Subject: RE: [Sipping] Call Waiting - who does the tone > > If this was desirable, which I don't personally believe it is, > I don't think there exists a sip mechanism that would enable it. > Are you proposing we create one? > > Brian > -----Original Message----- > From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] > Sent: Tuesday, June 17, 2003 11:04 AM > To: Alan Hawrylyshen; Satish Bansal! > Cc: Rosen, Brian; sipping@ietf.org > Subject: RE: [Sipping] Call Waiting - who does the tone > > > Call Waiting service in the core of the network offers more flexible > solution to service providers. They can chose which media > server to use and > type of announcement message to play to the end user waiting > on the call. > This would be a part of service offering (in this particular > example, call > waiting) to a subscriber. In addition, it is UA independent. > > Regards, > Dusan Mudric. > Senior Sw Engineer > Leapstone Systems Inc. > > -----Original Message----- > From: Alan Hawrylyshen [mailto:alan@jasomi.com] > Sent: Saturday, June 14, 2003 5:28 PM > To: Satish Bansal! > Cc: Rosen, Brian; 'sipping@ietf.org' > Subject: Re: [Sipping] Call Waiting - who does the tone > > On Saturday, Jun 14, 2003, at 01:27 Canada/Mountain, Satish > Bansal! wrote: > > There could be two options. First as you said, a dump phone > should handle > call waiting. It would mean that we are making end nodes > intelligent. > > Second option is that intelligence is in the network, the > inbound proxy > should be call statefull and should use 3pcc for playing tone & annc. > through a server to the party. > > 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 > 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). > > 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 > maintain and > deploy the 'core' portion of a SIP network infrastructure. > > I would agree w/ Brian on this; this could be appropriate for > inclusion in a > BCP document. > > De-lurking, > > Alan Hawrylyshen Jasomi Networks Inc. > sip:alan@jasomi.com mailto:alan@jasomi.com > http://www.jasomi.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 Jun 17 16:05:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08386 for ; Tue, 17 Jun 2003 16:05:50 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HK5Ln26245 for sipping-archive@odin.ietf.org; Tue, 17 Jun 2003 16:05:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SMUm-0006Q4-Pa for sipping-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 15:51: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 PAA07943 for ; Tue, 17 Jun 2003 15:51:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SMSX-0004Gx-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 15:49:37 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SMSX-0004Gu-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 15:49:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SMQ3-00064I-Lw; Tue, 17 Jun 2003 15: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 19SMIS-00045i-6a for sipping@optimus.ietf.org; Tue, 17 Jun 2003 15:39: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 PAA06715 for ; Tue, 17 Jun 2003 15:39:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SMGD-00040a-00 for sipping@ietf.org; Tue, 17 Jun 2003 15:36:53 -0400 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by ietf-mx with esmtp (Exim 4.12) id 19SMGD-00040D-00 for sipping@ietf.org; Tue, 17 Jun 2003 15:36:53 -0400 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HGN00I2Y50UNZ@firewall.wcom.com> for sipping@ietf.org; Tue, 17 Jun 2003 19:34:06 +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 <0HGN005014S35K@pmismtp02.wcomnet.com>; Tue, 17 Jun 2003 19:34:06 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.128.155]) by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HGN005H05062W@pmismtp02.wcomnet.com>; Tue, 17 Jun 2003 19:33:45 +0000 (GMT) Date: Tue, 17 Jun 2003 14:33:41 -0500 From: Alan Johnston Subject: RE: [Sipping] Call Waiting - who does the tone In-reply-to: <59A835EDCDDBEB46BC75402F4604D5520107AC74@elmer> X-Sender: Alan.Johnston@pop.mcit.com To: Dusan Mudric , "Rosen, Brian" , Alan Hawrylyshen , Satish Bansal! Cc: sipping@ietf.org Message-id: <5.2.1.1.0.20030617143005.022eed68@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 Dusan, See my comments below. Thanks, Alan Johnston MCI At 02:12 PM 6/17/2003 -0400, Dusan Mudric wrote: >Media connection can be established on 486 busy. It would be very similar >call flow as in draft-ietf-sipping-service-examples-04.txt, 2.7 Call >Forwarding - Busy. But the media connection is established with a different UA - there is no way this flow can be made into a call waiting flow without invoking some sort of non-SIP 3rd party control which is not part of the Service Examples. I agree with Brian that call waiting is a trivial end-point service. >Btw, we should add this service description in the mentioned draft. > >Regards, >Dusan Mudric. > > -----Original Message----- >From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] >Sent: Tuesday, June 17, 2003 1:04 PM >To: Dusan Mudric; Rosen, Brian; Alan Hawrylyshen; Satish Bansal! >Cc: sipping@ietf.org >Subject: RE: [Sipping] Call Waiting - who does the tone > >Hmmm, please explain. > >I don't think there is any "busy" (which is usually a 400 class >response to an INVITE) that creates a media connection. >Of course, usually call waiting is overlaid (mixed) with live audio, >but even as an independent media stream, you can't use 3PCC to cause >the called party to put his existing call on hold. You would have to >force both ends of the call to reroute to a mixer. A middle box >can't do that, and it isn't likely to work smoothly at all. > >Brian > > > > > -----Original Message----- > > From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] > > Sent: Tuesday, June 17, 2003 11:56 AM > > To: Rosen, Brian; Alan Hawrylyshen; Satish Bansal! > > Cc: sipping@ietf.org > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > > > There is an existing SIP busy that can be used to offer > > multi-party call waiting announcement service. Off-hook from > > terminating party would be signaled with re-INVITE. > > > > Regards, > > Dusan Mudric. > > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Tuesday, June 17, 2003 11:07 AM > > To: Dusan Mudric; Alan Hawrylyshen; Satish Bansal! > > Cc: sipping@ietf.org > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > If this was desirable, which I don't personally believe it is, > > I don't think there exists a sip mechanism that would enable it. > > Are you proposing we create one? > > > > Brian > > -----Original Message----- > > From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] > > Sent: Tuesday, June 17, 2003 11:04 AM > > To: Alan Hawrylyshen; Satish Bansal! > > Cc: Rosen, Brian; sipping@ietf.org > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > > > Call Waiting service in the core of the network offers more flexible > > solution to service providers. They can chose which media > > server to use and > > type of announcement message to play to the end user waiting > > on the call. > > This would be a part of service offering (in this particular > > example, call > > waiting) to a subscriber. In addition, it is UA independent. > > > > Regards, > > Dusan Mudric. > > Senior Sw Engineer > > Leapstone Systems Inc. > > > > -----Original Message----- > > From: Alan Hawrylyshen [mailto:alan@jasomi.com] > > Sent: Saturday, June 14, 2003 5:28 PM > > To: Satish Bansal! > > Cc: Rosen, Brian; 'sipping@ietf.org' > > Subject: Re: [Sipping] Call Waiting - who does the tone > > > > On Saturday, Jun 14, 2003, at 01:27 Canada/Mountain, Satish > > Bansal! wrote: > > > > There could be two options. First as you said, a dump phone > > should handle > > call waiting. It would mean that we are making end nodes > > intelligent. > > > > Second option is that intelligence is in the network, the > > inbound proxy > > should be call statefull and should use 3pcc for playing tone & annc. > > through a server to the party. > > > > 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 > > 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). > > > > 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 > > maintain and > > deploy the 'core' portion of a SIP network infrastructure. > > > > I would agree w/ Brian on this; this could be appropriate for > > inclusion in a > > BCP document. > > > > De-lurking, > > > > Alan Hawrylyshen Jasomi Networks Inc. > > sip:alan@jasomi.com mailto:alan@jasomi.com > > http://www.jasomi.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 Jun 17 16:45:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10526 for ; Tue, 17 Jun 2003 16:45:51 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HKjNp04436 for sipping-archive@odin.ietf.org; Tue, 17 Jun 2003 16:45:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SNKV-00019T-9Q for sipping-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 16:45: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 QAA10456 for ; Tue, 17 Jun 2003 16:45:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SNIG-0004qS-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 16:43:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SNIF-0004qP-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 16:43:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SN4f-0008Qr-MR; Tue, 17 Jun 2003 16: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 19SMY5-0006Y8-UU for sipping@optimus.ietf.org; Tue, 17 Jun 2003 15:55: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 PAA08009 for ; Tue, 17 Jun 2003 15:55:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SMVr-0004ID-00 for sipping@ietf.org; Tue, 17 Jun 2003 15:53:03 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19SMVq-0004Hp-00 for sipping@ietf.org; Tue, 17 Jun 2003 15:53:02 -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 PAA19812; Tue, 17 Jun 2003 15:54:47 -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 PAA00112; Tue, 17 Jun 2003 15:54:48 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jun 2003 15:54:47 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5AF5@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Dusan Mudric'" Cc: sipping@ietf.org Subject: RE: [Sipping] Call Waiting - who does the tone Date: Tue, 17 Jun 2003 15: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: , Please look again. You don't get media for the 486. The transaction completes, and a new transaction starts with INVITE. The media flow occurs as a result of the INVITE. You will also note that you see 180 Ringing. What would you expect the user experience to be? Using this example, you would experience a call, two way audio, then the call would have to be cut off without warning, your phone would ring, and when you answered, you would hear a tone or announcement. I suppose that if you hung up from that "call", you could get another call, which would be your original call, resumed, which you could then hang up, and get yet another call which would be the waiting call. Also, for that to work at all, the original call, as well as the waiting call, have to arrive at your phone via 3PCC. One of the underlying assumptions about 3PCC is that the controller is the "other" participant for both end-participants. There are no systems I'm familiar with that do this. Dusan, I don't think there are any systems out there, or even contemplated, that would support call waiting implemented this way. I also don't think it's a good idea. I think we probably should keep call waiting a local function and not a network function. Brian > -----Original Message----- > From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] > Sent: Tuesday, June 17, 2003 2:13 PM > To: Rosen, Brian; Alan Hawrylyshen; Satish Bansal! > Cc: sipping@ietf.org > Subject: RE: [Sipping] Call Waiting - who does the tone > > > Media connection can be established on 486 busy. It would be > very similar call flow as in > draft-ietf-sipping-service-examples-04.txt, 2.7 Call > Forwarding - Busy. > > Btw, we should add this service description in the mentioned draft. > > Regards, > Dusan Mudric. > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Tuesday, June 17, 2003 1:04 PM > To: Dusan Mudric; Rosen, Brian; Alan Hawrylyshen; Satish Bansal! > Cc: sipping@ietf.org > Subject: RE: [Sipping] Call Waiting - who does the tone > > Hmmm, please explain. > > I don't think there is any "busy" (which is usually a 400 class > response to an INVITE) that creates a media connection. > Of course, usually call waiting is overlaid (mixed) with live audio, > but even as an independent media stream, you can't use 3PCC to cause > the called party to put his existing call on hold. You would have to > force both ends of the call to reroute to a mixer. A middle box > can't do that, and it isn't likely to work smoothly at all. > > Brian > > > > > -----Original Message----- > > From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] > > Sent: Tuesday, June 17, 2003 11:56 AM > > To: Rosen, Brian; Alan Hawrylyshen; Satish Bansal! > > Cc: sipping@ietf.org > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > > > There is an existing SIP busy that can be used to offer > > multi-party call waiting announcement service. Off-hook from > > terminating party would be signaled with re-INVITE. > > > > Regards, > > Dusan Mudric. > > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Tuesday, June 17, 2003 11:07 AM > > To: Dusan Mudric; Alan Hawrylyshen; Satish Bansal! > > Cc: sipping@ietf.org > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > If this was desirable, which I don't personally believe it is, > > I don't think there exists a sip mechanism that would enable it. > > Are you proposing we create one? > > > > Brian > > -----Original Message----- > > From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] > > Sent: Tuesday, June 17, 2003 11:04 AM > > To: Alan Hawrylyshen; Satish Bansal! > > Cc: Rosen, Brian; sipping@ietf.org > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > > > Call Waiting service in the core of the network offers more flexible > > solution to service providers. They can chose which media > > server to use and > > type of announcement message to play to the end user waiting > > on the call. > > This would be a part of service offering (in this particular > > example, call > > waiting) to a subscriber. In addition, it is UA independent. > > > > Regards, > > Dusan Mudric. > > Senior Sw Engineer > > Leapstone Systems Inc. > > > > -----Original Message----- > > From: Alan Hawrylyshen [mailto:alan@jasomi.com] > > Sent: Saturday, June 14, 2003 5:28 PM > > To: Satish Bansal! > > Cc: Rosen, Brian; 'sipping@ietf.org' > > Subject: Re: [Sipping] Call Waiting - who does the tone > > > > On Saturday, Jun 14, 2003, at 01:27 Canada/Mountain, Satish > > Bansal! wrote: > > > > There could be two options. First as you said, a dump phone > > should handle > > call waiting. It would mean that we are making end nodes > > intelligent. > > > > Second option is that intelligence is in the network, the > > inbound proxy > > should be call statefull and should use 3pcc for playing > tone & annc. > > through a server to the party. > > > > 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 > > 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). > > > > 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 > > maintain and > > deploy the 'core' portion of a SIP network infrastructure. > > > > I would agree w/ Brian on this; this could be appropriate for > > inclusion in a > > BCP document. > > > > De-lurking, > > > > Alan Hawrylyshen Jasomi Networks Inc. > > sip:alan@jasomi.com mailto:alan@jasomi.com > > http://www.jasomi.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 Jun 17 16:50:31 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 QAA10895 for ; Tue, 17 Jun 2003 16:50:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HKo3Z05208 for sipping-archive@odin.ietf.org; Tue, 17 Jun 2003 16:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SNP1-0001Lv-6X for sipping-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 16:50: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 QAA10888 for ; Tue, 17 Jun 2003 16:50:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SNMm-0004xb-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 16:47:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SNMl-0004xY-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 16:47:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SNOz-0001Kz-Ti; Tue, 17 Jun 2003 16: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 19SNOe-0001KU-Py for sipping@optimus.ietf.org; Tue, 17 Jun 2003 16:49: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 QAA10868 for ; Tue, 17 Jun 2003 16:49:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SNMP-0004x6-00 for sipping@ietf.org; Tue, 17 Jun 2003 16:47:21 -0400 Received: from [204.42.169.163] (helo=elmer.LEAPSTONE.COM) by ietf-mx with esmtp (Exim 4.12) id 19SNMP-0004ws-00 for sipping@ietf.org; Tue, 17 Jun 2003 16:47:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] Call Waiting - who does the tone Date: Tue, 17 Jun 2003 16:49:52 -0400 Message-ID: <59A835EDCDDBEB46BC75402F4604D5520107AC76@elmer> Thread-Topic: [Sipping] Call Waiting - who does the tone Thread-Index: AcM1CnzaMF04E/2VRmCtlid+8x1vQQABWm7Q From: "Dusan Mudric" To: "Rosen, Brian" Cc: Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA10895 Call flow is very close. Originating UA-C can experience smoother events: ringing and than media stream with announcement. Terminating party UA-B can get a signal from media server for the call from UA-C waiting for UA-B. When terminating party UA-B is ready to accept the call (hung up with UA-A), proxy sends INVITE for the second session to the terminating UA-B, UA-B sends 200 OK, and proxy issues re-INVITE to originating party UA-C (assumption is UA-C is still waiting). Media stream is cutoff and original session with calling party is reestablished. Regards, Dusan Mudric. -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Tuesday, June 17, 2003 3:55 PM To: Dusan Mudric Cc: sipping@ietf.org Subject: RE: [Sipping] Call Waiting - who does the tone Please look again. You don't get media for the 486. The transaction completes, and a new transaction starts with INVITE. The media flow occurs as a result of the INVITE. You will also note that you see 180 Ringing. What would you expect the user experience to be? Using this example, you would experience a call, two way audio, then the call would have to be cut off without warning, your phone would ring, and when you answered, you would hear a tone or announcement. I suppose that if you hung up from that "call", you could get another call, which would be your original call, resumed, which you could then hang up, and get yet another call which would be the waiting call. Also, for that to work at all, the original call, as well as the waiting call, have to arrive at your phone via 3PCC. One of the underlying assumptions about 3PCC is that the controller is the "other" participant for both end-participants. There are no systems I'm familiar with that do this. Dusan, I don't think there are any systems out there, or even contemplated, that would support call waiting implemented this way. I also don't think it's a good idea. I think we probably should keep call waiting a local function and not a network function. Brian > -----Original Message----- > From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] > Sent: Tuesday, June 17, 2003 2:13 PM > To: Rosen, Brian; Alan Hawrylyshen; Satish Bansal! > Cc: sipping@ietf.org > Subject: RE: [Sipping] Call Waiting - who does the tone > > > Media connection can be established on 486 busy. It would be > very similar call flow as in > draft-ietf-sipping-service-examples-04.txt, 2.7 Call > Forwarding - Busy. > > Btw, we should add this service description in the mentioned draft. > > Regards, > Dusan Mudric. > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Tuesday, June 17, 2003 1:04 PM > To: Dusan Mudric; Rosen, Brian; Alan Hawrylyshen; Satish Bansal! > Cc: sipping@ietf.org > Subject: RE: [Sipping] Call Waiting - who does the tone > > Hmmm, please explain. > > I don't think there is any "busy" (which is usually a 400 class > response to an INVITE) that creates a media connection. > Of course, usually call waiting is overlaid (mixed) with live audio, > but even as an independent media stream, you can't use 3PCC to cause > the called party to put his existing call on hold. You would have to > force both ends of the call to reroute to a mixer. A middle box > can't do that, and it isn't likely to work smoothly at all. > > Brian > > > > > -----Original Message----- > > From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] > > Sent: Tuesday, June 17, 2003 11:56 AM > > To: Rosen, Brian; Alan Hawrylyshen; Satish Bansal! > > Cc: sipping@ietf.org > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > > > There is an existing SIP busy that can be used to offer > > multi-party call waiting announcement service. Off-hook from > > terminating party would be signaled with re-INVITE. > > > > Regards, > > Dusan Mudric. > > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Tuesday, June 17, 2003 11:07 AM > > To: Dusan Mudric; Alan Hawrylyshen; Satish Bansal! > > Cc: sipping@ietf.org > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > If this was desirable, which I don't personally believe it is, > > I don't think there exists a sip mechanism that would enable it. > > Are you proposing we create one? > > > > Brian > > -----Original Message----- > > From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] > > Sent: Tuesday, June 17, 2003 11:04 AM > > To: Alan Hawrylyshen; Satish Bansal! > > Cc: Rosen, Brian; sipping@ietf.org > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > > > Call Waiting service in the core of the network offers more flexible > > solution to service providers. They can chose which media > > server to use and > > type of announcement message to play to the end user waiting > > on the call. > > This would be a part of service offering (in this particular > > example, call > > waiting) to a subscriber. In addition, it is UA independent. > > > > Regards, > > Dusan Mudric. > > Senior Sw Engineer > > Leapstone Systems Inc. > > > > -----Original Message----- > > From: Alan Hawrylyshen [mailto:alan@jasomi.com] > > Sent: Saturday, June 14, 2003 5:28 PM > > To: Satish Bansal! > > Cc: Rosen, Brian; 'sipping@ietf.org' > > Subject: Re: [Sipping] Call Waiting - who does the tone > > > > On Saturday, Jun 14, 2003, at 01:27 Canada/Mountain, Satish > > Bansal! wrote: > > > > There could be two options. First as you said, a dump phone > > should handle > > call waiting. It would mean that we are making end nodes > > intelligent. > > > > Second option is that intelligence is in the network, the > > inbound proxy > > should be call statefull and should use 3pcc for playing > tone & annc. > > through a server to the party. > > > > 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 > > 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). > > > > 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 > > maintain and > > deploy the 'core' portion of a SIP network infrastructure. > > > > I would agree w/ Brian on this; this could be appropriate for > > inclusion in a > > BCP document. > > > > De-lurking, > > > > Alan Hawrylyshen Jasomi Networks Inc. > > sip:alan@jasomi.com mailto:alan@jasomi.com > > http://www.jasomi.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 Jun 17 16:59:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11219 for ; Tue, 17 Jun 2003 16:59:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HKx2v07237 for sipping-archive@odin.ietf.org; Tue, 17 Jun 2003 16:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SNXi-0001se-OV for sipping-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 16:59: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 QAA11203 for ; Tue, 17 Jun 2003 16:58:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SNVT-00053s-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 16:56:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SNVT-00053p-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 16:56:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SNXh-0001re-Lg; Tue, 17 Jun 2003 16: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 19SNWl-0001qY-Vt for sipping@optimus.ietf.org; Tue, 17 Jun 2003 16:58: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 QAA11187 for ; Tue, 17 Jun 2003 16:58:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SNUW-00053O-00 for sipping@ietf.org; Tue, 17 Jun 2003 16:55:45 -0400 Received: from pmesmtp02.wcom.com ([199.249.20.2]) by ietf-mx with esmtp (Exim 4.12) id 19SNUW-00053E-00 for sipping@ietf.org; Tue, 17 Jun 2003 16:55:44 -0400 Received: from pmismtp06.wcomnet.com ([166.38.62.54]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HGN00AJT8QSNI@firewall.wcom.com> for sipping@ietf.org; Tue, 17 Jun 2003 20:54:29 +0000 (GMT) Received: from pmismtp06.wcomnet.com by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HGN002018FDMZ@pmismtp06.wcomnet.com>; Tue, 17 Jun 2003 20:54:28 +0000 (GMT) Received: from hsinnreich2 ([166.35.136.36]) by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HGN003A98PK7F@pmismtp06.wcomnet.com>; Tue, 17 Jun 2003 20:53:53 +0000 (GMT) Date: Tue, 17 Jun 2003 15:53:45 -0500 From: Henry Sinnreich Subject: RE: [Sipping] Re: Call Waiting - who does the tone In-reply-to: <1586D8FA-A046-11D7-A786-000A956A5F38@jasomi.com> To: "'Alan Hawrylyshen'" , sipping@ietf.org Message-id: <000301c33512$9014edc0$248823a6@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 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: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA11219 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. 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 Alan Hawrylyshen > Sent: Monday, June 16, 2003 5:01 PM > To: 'sipping@ietf.org' > Subject: [Sipping] Re: Call Waiting - who does the tone > > > On Saturday, Jun 14, 2003, at 01:27 Canada/Mountain, Satish Bansal! > wrote: > > > > There could be two options. First as you said,  a dump phone should > > handle call waiting. It would mean that we are making  end nodes > > intelligent. > > > > Second option is that intelligence is in the  network, the inbound > > proxy should be call statefull and should use 3pcc for > playing tone & > > annc. through a server to  the party. > > 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 > 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). > > 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 > maintain and deploy the ’core’ portion of a SIP network > infrastructure. > > I would agree w/ Brian on this; this could be appropriate for > inclusion > in a BCP document. > > De-lurking, > > Alan Hawrylyshen Jasomi Networks Inc. > sip:alan@jasomi.com mailto:alan@jasomi.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 Jun 17 17:56: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 RAA12888 for ; Tue, 17 Jun 2003 17:56:33 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HLu6r15290 for sipping-archive@odin.ietf.org; Tue, 17 Jun 2003 17:56:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SOQw-0003yX-Di for sipping-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 17:56: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 RAA12876 for ; Tue, 17 Jun 2003 17:56:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SOOg-0005Sa-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 17:53:46 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SOOg-0005SX-00 for sipping-web-archive@ietf.org; Tue, 17 Jun 2003 17:53:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SOQs-0003xV-As; Tue, 17 Jun 2003 17: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 19SOQY-0003x1-O1 for sipping@optimus.ietf.org; Tue, 17 Jun 2003 17:55: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 RAA12864 for ; Tue, 17 Jun 2003 17:55:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SOOJ-0005SJ-00 for sipping@ietf.org; Tue, 17 Jun 2003 17:53:23 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19SOOI-0005S9-00 for sipping@ietf.org; Tue, 17 Jun 2003 17:53:22 -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 RAA22620; Tue, 17 Jun 2003 17:55:08 -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 RAA13582; Tue, 17 Jun 2003 17:55:09 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jun 2003 17:55:08 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5AF6@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Dusan Mudric'" Cc: sipping@ietf.org Subject: RE: [Sipping] Call Waiting - who does the tone Date: Tue, 17 Jun 2003 17:55:06 -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: , Call waiting announcements traditionally are played to the called party (call waiting tone). The calling party experiences ringing, and then either answer or forwarding-no answer behavior. How does called party B know that C is waiting? That is the call waiting problem I first started this thread on. It's not a problem for call forward-no answer to allow a retry, with announcements, if that's what you want, but it doesn't have much to do with call waiting. Brian > -----Original Message----- > From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] > Sent: Tuesday, June 17, 2003 4:50 PM > To: Rosen, Brian > Cc: sipping@ietf.org > Subject: RE: [Sipping] Call Waiting - who does the tone > > > Call flow is very close. Originating UA-C can experience > smoother events: ringing and than media stream with > announcement. Terminating party UA-B can get a signal from > media server for the call from UA-C waiting for UA-B. When > terminating party UA-B is ready to accept the call (hung up > with UA-A), proxy sends INVITE for the second session to the > terminating UA-B, UA-B sends 200 OK, and proxy issues > re-INVITE to originating party UA-C (assumption is UA-C is > still waiting). Media stream is cutoff and original session > with calling party is reestablished. > Regards, > Dusan Mudric. > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Tuesday, June 17, 2003 3:55 PM > To: Dusan Mudric > Cc: sipping@ietf.org > Subject: RE: [Sipping] Call Waiting - who does the tone > > Please look again. You don't get media for the 486. > The transaction completes, and a new transaction starts > with INVITE. The media flow occurs as a result of the > INVITE. You will also note that you see 180 Ringing. > > What would you expect the user experience to be? > Using this example, you would experience a call, > two way audio, then the call would have to be cut off > without warning, your phone would ring, and when you > answered, you would hear a tone or announcement. > I suppose that if you hung up from that "call", you > could get another call, which would be your original > call, resumed, which you could then hang up, and > get yet another call which would be the waiting call. > > Also, for that to work at all, the original call, > as well as the waiting call, have to arrive at your > phone via 3PCC. One of the underlying assumptions > about 3PCC is that the controller is the "other" > participant for both end-participants. There are no > systems I'm familiar with that do this. > > Dusan, I don't think there are any systems out there, or > even contemplated, that would support call waiting implemented > this way. I also don't think it's a good idea. > > I think we probably should keep call waiting a local > function and not a network function. > > Brian > > > -----Original Message----- > > From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] > > Sent: Tuesday, June 17, 2003 2:13 PM > > To: Rosen, Brian; Alan Hawrylyshen; Satish Bansal! > > Cc: sipping@ietf.org > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > > > Media connection can be established on 486 busy. It would be > > very similar call flow as in > > draft-ietf-sipping-service-examples-04.txt, 2.7 Call > > Forwarding - Busy. > > > > Btw, we should add this service description in the mentioned draft. > > > > Regards, > > Dusan Mudric. > > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Tuesday, June 17, 2003 1:04 PM > > To: Dusan Mudric; Rosen, Brian; Alan Hawrylyshen; Satish Bansal! > > Cc: sipping@ietf.org > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > Hmmm, please explain. > > > > I don't think there is any "busy" (which is usually a 400 class > > response to an INVITE) that creates a media connection. > > Of course, usually call waiting is overlaid (mixed) with live audio, > > but even as an independent media stream, you can't use 3PCC to cause > > the called party to put his existing call on hold. You > would have to > > force both ends of the call to reroute to a mixer. A middle box > > can't do that, and it isn't likely to work smoothly at all. > > > > Brian > > > > > > > > > -----Original Message----- > > > From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] > > > Sent: Tuesday, June 17, 2003 11:56 AM > > > To: Rosen, Brian; Alan Hawrylyshen; Satish Bansal! > > > Cc: sipping@ietf.org > > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > > > > > > There is an existing SIP busy that can be used to offer > > > multi-party call waiting announcement service. Off-hook from > > > terminating party would be signaled with re-INVITE. > > > > > > Regards, > > > Dusan Mudric. > > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: Tuesday, June 17, 2003 11:07 AM > > > To: Dusan Mudric; Alan Hawrylyshen; Satish Bansal! > > > Cc: sipping@ietf.org > > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > > > If this was desirable, which I don't personally believe it is, > > > I don't think there exists a sip mechanism that would enable it. > > > Are you proposing we create one? > > > > > > Brian > > > -----Original Message----- > > > From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] > > > Sent: Tuesday, June 17, 2003 11:04 AM > > > To: Alan Hawrylyshen; Satish Bansal! > > > Cc: Rosen, Brian; sipping@ietf.org > > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > > > > > > Call Waiting service in the core of the network offers > more flexible > > > solution to service providers. They can chose which media > > > server to use and > > > type of announcement message to play to the end user waiting > > > on the call. > > > This would be a part of service offering (in this particular > > > example, call > > > waiting) to a subscriber. In addition, it is UA independent. > > > > > > Regards, > > > Dusan Mudric. > > > Senior Sw Engineer > > > Leapstone Systems Inc. > > > > > > -----Original Message----- > > > From: Alan Hawrylyshen [mailto:alan@jasomi.com] > > > Sent: Saturday, June 14, 2003 5:28 PM > > > To: Satish Bansal! > > > Cc: Rosen, Brian; 'sipping@ietf.org' > > > Subject: Re: [Sipping] Call Waiting - who does the tone > > > > > > On Saturday, Jun 14, 2003, at 01:27 Canada/Mountain, Satish > > > Bansal! wrote: > > > > > > There could be two options. First as you said, a dump phone > > > should handle > > > call waiting. It would mean that we are making end nodes > > > intelligent. > > > > > > Second option is that intelligence is in the network, the > > > inbound proxy > > > should be call statefull and should use 3pcc for playing > > tone & annc. > > > through a server to the party. > > > > > > 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 > > > 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). > > > > > > 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 > > > maintain and > > > deploy the 'core' portion of a SIP network infrastructure. > > > > > > I would agree w/ Brian on this; this could be appropriate for > > > inclusion in a > > > BCP document. > > > > > > De-lurking, > > > > > > Alan Hawrylyshen Jasomi Networks Inc. > > > sip:alan@jasomi.com mailto:alan@jasomi.com > > > http://www.jasomi.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 Jun 18 07:52:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28016 for ; Wed, 18 Jun 2003 07:52:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IBq5b17879 for sipping-archive@odin.ietf.org; Wed, 18 Jun 2003 07:52:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SbTx-0004eI-Rt for sipping-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 07:52:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27924 for ; Wed, 18 Jun 2003 07:52:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SbRi-0002Jz-00 for sipping-web-archive@ietf.org; Wed, 18 Jun 2003 07:49:46 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SbRh-0002Jw-00 for sipping-web-archive@ietf.org; Wed, 18 Jun 2003 07:49:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SbTt-0004dC-Ve; Wed, 18 Jun 2003 07: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 19SbTq-0004Zr-5D for sipping@optimus.ietf.org; Wed, 18 Jun 2003 07:51:58 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27894; Wed, 18 Jun 2003 07:51:56 -0400 (EDT) Message-Id: <200306181151.HAA27894@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, 18 Jun 2003 07:51:56 -0400 Subject: [Sipping] I-D ACTION:draft-elmalki-v6ops-3gpp-translator-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 : IPv6-IPv4 Translators in 3GPP Networks Author(s) : K. El Malki et al. Filename : draft-elmalki-v6ops-3gpp-translator-00.txt Pages : 16 Date : 2003-6-17 There have been discussions on the v6ops mailing list and at IETF meetings regarding the suitability of translators (e.g. NAT-PT) as mechanisms for IPv4 to IPv6 transition. It has often been stated that NAT-PT is not a mechanism to be recommended in general to solve the IPv6-IPv4 transition problem and some modifications to NAT-PT have been proposed. However there have also been discussions regarding special scenarios where some form of translators could be deployed if their use is documented appropriately. The aim of this draft is to document the rationale for using translators in 3GPP networks, in particular for IPv6-only IMS (IP Multimedia Subsystem) and to describe possible solutions to the problem and the interactions with SIP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-elmalki-v6ops-3gpp-translator-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-elmalki-v6ops-3gpp-translator-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-elmalki-v6ops-3gpp-translator-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-17144253.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-elmalki-v6ops-3gpp-translator-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-elmalki-v6ops-3gpp-translator-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-17144253.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 Jun 18 10:33:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09935 for ; Wed, 18 Jun 2003 10:33:57 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IEXUO15080 for sipping-archive@odin.ietf.org; Wed, 18 Jun 2003 10:33:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SdYJ-0002O9-Fw for sipping-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 10:04: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 KAA07864 for ; Wed, 18 Jun 2003 10:04:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SdW2-0004z5-00 for sipping-web-archive@ietf.org; Wed, 18 Jun 2003 10:02:22 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SdW2-0004z1-00 for sipping-web-archive@ietf.org; Wed, 18 Jun 2003 10:02:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SdBO-0001Jp-3W; Wed, 18 Jun 2003 09: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 19Sd3B-0000m7-FE for sipping@optimus.ietf.org; Wed, 18 Jun 2003 09:32: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 JAA06206 for ; Wed, 18 Jun 2003 09:32:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sd0u-0004e3-00 for sipping@ietf.org; Wed, 18 Jun 2003 09:30:12 -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 19Sd0u-0004e0-00 for sipping@ietf.org; Wed, 18 Jun 2003 09:30:12 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.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 h5IDWQw2026108; Wed, 18 Jun 2003 15:32:26 +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 LYGLRCMC; Wed, 18 Jun 2003 15:32:21 +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 h5IDW9SZ004501; Wed, 18 Jun 2003 16:32:09 +0300 (EET DST) Message-ID: <3EF069D9.441CA13@lmf.ericsson.se> Date: Wed, 18 Jun 2003 16:32:09 +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: sipping CC: Rohan Mahy , Dean Willis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Agenda requests Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk 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 can start sending us your agenda requests for Vienna. We will keep track of them at: http://www.softarmor.com/sipping/meets/ietf57/requests.html We will try to acknowledge your emails as we get them, but, in any event, please make sure that your request shows up in the web site above. Don't forget to send us your estimation for the length of time slot(s) you request. Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Jun 18 11:24: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 LAA12402 for ; Wed, 18 Jun 2003 11:24:27 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IFNw526904 for sipping-archive@odin.ietf.org; Wed, 18 Jun 2003 11:23:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Se6C-0004ZT-NH for sipping-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 10:39: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 KAA10120 for ; Wed, 18 Jun 2003 10:39:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Se3v-0005EZ-00 for sipping-web-archive@ietf.org; Wed, 18 Jun 2003 10:37:23 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Se3u-0005EW-00 for sipping-web-archive@ietf.org; Wed, 18 Jun 2003 10:37:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SdeR-00035S-9k; Wed, 18 Jun 2003 10: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 19SdGO-0001Rx-Cy for sipping@optimus.ietf.org; Wed, 18 Jun 2003 09:46: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 JAA06780 for ; Wed, 18 Jun 2003 09:46:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SdE7-0004li-00 for sipping@ietf.org; Wed, 18 Jun 2003 09:43:51 -0400 Received: from ns.ivd.nl ([193.67.37.226]) by ietf-mx with esmtp (Exim 4.12) id 19SdE6-0004lf-00 for sipping@ietf.org; Wed, 18 Jun 2003 09:43:50 -0400 Received: (from root@localhost) by ns.ivd.nl (8.9.3c/8.6.12) id PAA38550 for ; Wed, 18 Jun 2003 15:47:04 +0200 (CEST) Received: by ns.ivd.nl (TUNIX txp2/smap) for id sma038320; Wed, 18 Jun 03 15:45:25 +0200 Received: from IVD-Message_Server by mailserver.viataal.nl with Novell_GroupWise; Wed, 18 Jun 2003 15:46:22 +0200 Message-Id: X-Mailer: Novell GroupWise 5.5.5 Date: Wed, 18 Jun 2003 15:46:09 +0200 From: "A vWijk" To: , Cc: , Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Subject: [Sipping] Perspective of a deaf person. Was: Text support in SIP phones Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA12402 Jon, Michael and others. Let me bring in my experience as a deaf person. And I am then speaking for millions and millions of hearing impaired users all over the world! <> Well, as Guido said, we are looking for what the most users want. Text communication is for us hearing impaired people almost the ONLY way to use the telephone! We, the hearing impaired, want to see the other user type. Why? We will immediately know that a person is indeed answering, we can see what kind of answer the other person is formulating..and we can even interrupt and type an answer or comment. It is then a dialog, real time interaction. IM is a very nice invetion, but as a daily user of IM. I really dislike the waiting before the other person is ready with typing. Or the other user might have missed the message. Or as sometimes desired, thinking about how to formulate a reply. That is not interactive. Compare it in this way: Imagine that voice telephony works like IM. How well can you place a call? It would be like a radio communication with Mars, where there is a 20 seconds delay. So only one side can talk and then wait a while before getting a reply. Is that what you want for all the hearing impaired users? <> Exactly, we love IM and other text messaging systems since it is the ONLY way for us right now. But as soon we have a way for real-time text conversation.. I guarantee that all the hearing impaired users will immediately switch over to T.140/RTP. Now the funny thing is that IM and T.140/RTP can be used side by side in harmony. I think that it would be a very good idea if the SIMPLE WG really take a close look at T.140/RTP (RFC 2793). Jon? What do you say? The special thing about my IETF participation is that I bring in the experience, views and wishes/needs of the hearing impaired community. I KNOW what I am talking about and I want to help everybody here to get a better understanding how not to be able to hear. Everyday things which are normal for you, become a burden when you cannot hear. This insight should be considered when designing anything. Making it mainstream and default in designs is the ONLY way to prevent the protocol and technology mess in the past (think for example of the different non interworking text telephone protocols OR how the designers of the cellular telephony never ever considered to allow for text telephony over their systems). We are talking about functionality that almost all users will like and use. While it is essential for the hearing and speech impaired to have text communication, hearing users will also benefit from this. Thus allowing for many new and exiting services for all users. The text support that we as internet community design and implement is for EVERYBODY. And not for just a few users with specific needs. Sincerely, Arnoud 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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 18 11:24:36 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 LAA12438 for ; Wed, 18 Jun 2003 11:24:36 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IFO7627159 for sipping-archive@odin.ietf.org; Wed, 18 Jun 2003 11:24:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SeHF-0005IO-9H for sipping-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 10:51: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 KAA10757 for ; Wed, 18 Jun 2003 10:51:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SeEx-0005N6-00 for sipping-web-archive@ietf.org; Wed, 18 Jun 2003 10:48:47 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SeEx-0005N3-00 for sipping-web-archive@ietf.org; Wed, 18 Jun 2003 10:48:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SdeV-000370-Nm; Wed, 18 Jun 2003 10:11:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SdSB-00022E-OQ for sipping@optimus.ietf.org; Wed, 18 Jun 2003 09: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 JAA07314 for ; Wed, 18 Jun 2003 09:58:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SdPu-0004t1-00 for sipping@ietf.org; Wed, 18 Jun 2003 09:56:02 -0400 Received: from ns.ivd.nl ([193.67.37.226]) by ietf-mx with esmtp (Exim 4.12) id 19SdPs-0004sy-00 for sipping@ietf.org; Wed, 18 Jun 2003 09:56:01 -0400 Received: (from root@localhost) by ns.ivd.nl (8.9.3c/8.6.12) id PAA40957 for ; Wed, 18 Jun 2003 15:59:10 +0200 (CEST) Received: by ns.ivd.nl (TUNIX txp2/smap) for id sma040471; Wed, 18 Jun 03 15:58:05 +0200 Received: from IVD-Message_Server by mailserver.viataal.nl with Novell_GroupWise; Wed, 18 Jun 2003 15:59:02 +0200 Message-Id: X-Mailer: Novell GroupWise 5.5.5 Date: Wed, 18 Jun 2003 15:58:49 +0200 From: "A vWijk" To: , Cc: , Subject: RE: [Sipping] Text support in SIP phones Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA12438 Michael, And my point is that the real-time text conversation is for ALL users. Hearing users DO like to know if the other person is actually typing or not. Very often IM messages cross each other. Becuase the other user was taking so much more time to reply, that the original sender is already adding additional stuff or even questions. That happens very very often between hearing IM users (or hearing /deaf etc etc). Yahoo messenger and some other IM clients now have an indicator when the other user is typing. Also some IM clients offer a chat mode in IRC style. Which allows for quicker and more interactive conversation. But it still goes line by line with the mixups. The above shows that most users will like the ability to communicate in real-time using text. And those are hearing users! Hence, I URGE all IM designers/programmers to include real-time streaming text. And use RFC 2793 so that any client can interwork with any other client. greetz Arnoud PS. I am so strong about this because I see how important this real-time streaming text is. So any comments are not directed to the persons personally. Everybody is free to have his or her own opinions. You are free to hate streaming text, but realise that there is a huge user base who dearly want streaming text. 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 >>> Michael Hammer 06/17/03 05:10pm >>> Guido, Please don't get so defensive. You missed the whole point of my statement, which has little to do with what deaf people prefer, and everything to do with what non-deaf people might prefer, if both parties were using text-based near-real-time communications. I was responding to your suggestion that non-deaf users would also prefer the character-by-character mode of operation. I was simply disagreeing with that assertion. I was also up front that mine was simply an individual opinion. The studies that you cite seemed to be focused on determining what the deaf experience, and your added comments concerning non-deaf experience appeared anecdotal. I was merely suggesting that the experiences of both sides of the communication should be taken into account, for both the asymmetrical (text/voice) and symmetrical (both text) types of exchanges. Your point about the nature of the experience when dealing with the situation where one party is using text and the other is using voice is a key distinguishing factor. I appreciate the education I am getting by following the discussion. But, please don't attack me for questioning what the studies are really saying based on the limited information provided thus far, or for exploring alternative experiences and opinions. Mike At 03:26 PM 6/17/2003 +0100, Guido Gybels wrote: >Michael, > ><watching someone type mildly interesting in the short run, but as boring >as watching grass grow in the long run.>> > >To be quite frank about this, I was speaking about what deaf and hard of >hearing people want as a group, not necessarily what you or I want as >individuals or as techies. Believe me, I have argued a lot about this and >talked about IM with them etc. The point is that if it doesn't suit their >requirements, we have to accept that. The technology should adapt to the >user, not the other way around. >Apart from that, you have however missed my most important point, namely >the use of a relay service. When a deaf person wants to talk to a hearing >person over the relay service, the IM model simply does not work. The >operators will be speaking to the hearing party as words come through and >type back to the deaf users almost simultaneously as the voice from the >hearing party comes true. That is the closest deaf and hard of hearing >people can get. We have done trials with our gateway and RNID Typetalk >using deaf and hard of hearing people and the number 1 item was that the >message style conversation didn't work for them at all in that scenario. I >think we should accept that the user requirements are the predominant >driving factor here, not what we would like to develop. I'll leave it to >Arnoud, who is deaf, to comment on this from the user perspective, but >based on our research, I'm quite sure I'm right about this. >As to finding it boring: I have actually used both systems and to be >honest I find IM much more frustrating than character-by-character. I >accept that my individual judgement doesn't constitute relevant data, but >neither does your personal assessment of it being boring. Let's accept >that user requirements drive this. > ><back later when they are done typing.>> > >Which misses the point about using text as an equivalent to voice >altogether, I'm afraid. Deaf people are not using text as an additional >medium, it is their version of talking to someone over the phone. I would >respectfully suggest that we therefore allow *them* to odentify what they >want as users, rather than having us tell them what they want. > ><anecdotal evidence.>> > >Excuse me, the trials we have conducted recently and in the past, as well >as the experience of 10 years of running RNID Typetalk constitute quite >relevant expertise. That is quite different to individuals in here voicing >their personal opinions and speaking on behalf of deaf and hard of hearing >people. >There is currently a research project going on under the auspices of TAG >in the UK, using independent researchers to verify the current assumptions >and user requirements. I'm more than happy to publish those results to >IETF when they become available. I take it that you all then agree to >accept the outcome of that independent research? Do I have a commitment on >that?? > ><to what they are used to, but I'm not so sure which they would choose if >both were available.>> > >You miss the point that hundreds of thousands of deaf people DO use IM. As >they use other text based solutions in mainstream technology. And they say >to us clearly that it doesn't meet their needs. So, I accept that the >users are telling me what they need/want. Not the other way around. > >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 > > > > >************************************************************************ >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 Wed Jun 18 12:29:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15230 for ; Wed, 18 Jun 2003 12:29:26 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IGSxD06883 for sipping-archive@odin.ietf.org; Wed, 18 Jun 2003 12:28:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SfHv-00004y-KJ for sipping-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 11:55: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 LAA14152 for ; Wed, 18 Jun 2003 11:55:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SfFf-0006Cq-00 for sipping-web-archive@ietf.org; Wed, 18 Jun 2003 11:53:35 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SfFe-0006Cn-00 for sipping-web-archive@ietf.org; Wed, 18 Jun 2003 11:53:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sen3-00072G-UE; Wed, 18 Jun 2003 11: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 19Se6c-0004aw-0K for sipping@optimus.ietf.org; Wed, 18 Jun 2003 10:40: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 KAA10133 for ; Wed, 18 Jun 2003 10:40:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Se4K-0005Ew-00 for sipping@ietf.org; Wed, 18 Jun 2003 10:37:48 -0400 Received: from [204.42.169.163] (helo=elmer.LEAPSTONE.COM) by ietf-mx with esmtp (Exim 4.12) id 19Se4J-0005ES-00 for sipping@ietf.org; Wed, 18 Jun 2003 10:37:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] Call Waiting - who does the tone Date: Wed, 18 Jun 2003 10:40:19 -0400 Message-ID: <59A835EDCDDBEB46BC75402F4604D5520107AC79@elmer> Thread-Topic: [Sipping] Call Waiting - who does the tone Thread-Index: AcM1G0xPxHJef9zlQQOaTCzTe5KTGgAixy7w From: "Dusan Mudric" To: "Rosen, Brian" Cc: Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA15230 As mentioned "Terminating party UA-B can get a signal from media server for the call from UA-C waiting for UA-B." Terminating party UA-B can get call waiting signal from media on behalf on UA-C (proxy connects media to UA-B) while session with UA-A is in progress. Calling party UA-C might experience a ringing or even more advanced services, like announcement, music, ..., while it is waiting for UA-B to finish the call. Regards, Dusan Mudric. -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Tuesday, June 17, 2003 5:55 PM To: Dusan Mudric Cc: sipping@ietf.org Subject: RE: [Sipping] Call Waiting - who does the tone Call waiting announcements traditionally are played to the called party (call waiting tone). The calling party experiences ringing, and then either answer or forwarding-no answer behavior. How does called party B know that C is waiting? That is the call waiting problem I first started this thread on. It's not a problem for call forward-no answer to allow a retry, with announcements, if that's what you want, but it doesn't have much to do with call waiting. Brian > -----Original Message----- > From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] > Sent: Tuesday, June 17, 2003 4:50 PM > To: Rosen, Brian > Cc: sipping@ietf.org > Subject: RE: [Sipping] Call Waiting - who does the tone > > > Call flow is very close. Originating UA-C can experience > smoother events: ringing and than media stream with > announcement. Terminating party UA-B can get a signal from > media server for the call from UA-C waiting for UA-B. When > terminating party UA-B is ready to accept the call (hung up > with UA-A), proxy sends INVITE for the second session to the > terminating UA-B, UA-B sends 200 OK, and proxy issues > re-INVITE to originating party UA-C (assumption is UA-C is > still waiting). Media stream is cutoff and original session > with calling party is reestablished. > Regards, > Dusan Mudric. > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Tuesday, June 17, 2003 3:55 PM > To: Dusan Mudric > Cc: sipping@ietf.org > Subject: RE: [Sipping] Call Waiting - who does the tone > > Please look again. You don't get media for the 486. > The transaction completes, and a new transaction starts > with INVITE. The media flow occurs as a result of the > INVITE. You will also note that you see 180 Ringing. > > What would you expect the user experience to be? > Using this example, you would experience a call, > two way audio, then the call would have to be cut off > without warning, your phone would ring, and when you > answered, you would hear a tone or announcement. > I suppose that if you hung up from that "call", you > could get another call, which would be your original > call, resumed, which you could then hang up, and > get yet another call which would be the waiting call. > > Also, for that to work at all, the original call, > as well as the waiting call, have to arrive at your > phone via 3PCC. One of the underlying assumptions > about 3PCC is that the controller is the "other" > participant for both end-participants. There are no > systems I'm familiar with that do this. > > Dusan, I don't think there are any systems out there, or > even contemplated, that would support call waiting implemented > this way. I also don't think it's a good idea. > > I think we probably should keep call waiting a local > function and not a network function. > > Brian > > > -----Original Message----- > > From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] > > Sent: Tuesday, June 17, 2003 2:13 PM > > To: Rosen, Brian; Alan Hawrylyshen; Satish Bansal! > > Cc: sipping@ietf.org > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > > > Media connection can be established on 486 busy. It would be > > very similar call flow as in > > draft-ietf-sipping-service-examples-04.txt, 2.7 Call > > Forwarding - Busy. > > > > Btw, we should add this service description in the mentioned draft. > > > > Regards, > > Dusan Mudric. > > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Tuesday, June 17, 2003 1:04 PM > > To: Dusan Mudric; Rosen, Brian; Alan Hawrylyshen; Satish Bansal! > > Cc: sipping@ietf.org > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > Hmmm, please explain. > > > > I don't think there is any "busy" (which is usually a 400 class > > response to an INVITE) that creates a media connection. > > Of course, usually call waiting is overlaid (mixed) with live audio, > > but even as an independent media stream, you can't use 3PCC to cause > > the called party to put his existing call on hold. You > would have to > > force both ends of the call to reroute to a mixer. A middle box > > can't do that, and it isn't likely to work smoothly at all. > > > > Brian > > > > > > > > > -----Original Message----- > > > From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] > > > Sent: Tuesday, June 17, 2003 11:56 AM > > > To: Rosen, Brian; Alan Hawrylyshen; Satish Bansal! > > > Cc: sipping@ietf.org > > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > > > > > > There is an existing SIP busy that can be used to offer > > > multi-party call waiting announcement service. Off-hook from > > > terminating party would be signaled with re-INVITE. > > > > > > Regards, > > > Dusan Mudric. > > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: Tuesday, June 17, 2003 11:07 AM > > > To: Dusan Mudric; Alan Hawrylyshen; Satish Bansal! > > > Cc: sipping@ietf.org > > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > > > If this was desirable, which I don't personally believe it is, > > > I don't think there exists a sip mechanism that would enable it. > > > Are you proposing we create one? > > > > > > Brian > > > -----Original Message----- > > > From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] > > > Sent: Tuesday, June 17, 2003 11:04 AM > > > To: Alan Hawrylyshen; Satish Bansal! > > > Cc: Rosen, Brian; sipping@ietf.org > > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > > > > > > Call Waiting service in the core of the network offers > more flexible > > > solution to service providers. They can chose which media > > > server to use and > > > type of announcement message to play to the end user waiting > > > on the call. > > > This would be a part of service offering (in this particular > > > example, call > > > waiting) to a subscriber. In addition, it is UA independent. > > > > > > Regards, > > > Dusan Mudric. > > > Senior Sw Engineer > > > Leapstone Systems Inc. > > > > > > -----Original Message----- > > > From: Alan Hawrylyshen [mailto:alan@jasomi.com] > > > Sent: Saturday, June 14, 2003 5:28 PM > > > To: Satish Bansal! > > > Cc: Rosen, Brian; 'sipping@ietf.org' > > > Subject: Re: [Sipping] Call Waiting - who does the tone > > > > > > On Saturday, Jun 14, 2003, at 01:27 Canada/Mountain, Satish > > > Bansal! wrote: > > > > > > There could be two options. First as you said, a dump phone > > > should handle > > > call waiting. It would mean that we are making end nodes > > > intelligent. > > > > > > Second option is that intelligence is in the network, the > > > inbound proxy > > > should be call statefull and should use 3pcc for playing > > tone & annc. > > > through a server to the party. > > > > > > 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 > > > 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). > > > > > > 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 > > > maintain and > > > deploy the 'core' portion of a SIP network infrastructure. > > > > > > I would agree w/ Brian on this; this could be appropriate for > > > inclusion in a > > > BCP document. > > > > > > De-lurking, > > > > > > Alan Hawrylyshen Jasomi Networks Inc. > > > sip:alan@jasomi.com mailto:alan@jasomi.com > > > http://www.jasomi.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 Jun 18 13:08:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16524 for ; Wed, 18 Jun 2003 13:08:05 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IH7cR12655 for sipping-archive@odin.ietf.org; Wed, 18 Jun 2003 13:07:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SfbM-0001A3-H8 for sipping-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 12:16: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 MAA14792 for ; Wed, 18 Jun 2003 12:15:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SfZ6-0006M6-00 for sipping-web-archive@ietf.org; Wed, 18 Jun 2003 12:13:40 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SfZ5-0006M3-00 for sipping-web-archive@ietf.org; Wed, 18 Jun 2003 12:13:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Seup-0007RF-1b; Wed, 18 Jun 2003 11:32:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SeSH-0005vm-OT for sipping@optimus.ietf.org; Wed, 18 Jun 2003 11:02: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 LAA11163 for ; Wed, 18 Jun 2003 11:02:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SeQ0-0005Tg-00 for sipping@ietf.org; Wed, 18 Jun 2003 11:00:12 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19SePz-0005Td-00 for sipping@ietf.org; Wed, 18 Jun 2003 11:00:11 -0400 Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h5IF2QkN014711 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 18 Jun 2003 11:02:26 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by bart.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h5IF2Fpr003021; Wed, 18 Jun 2003 11:02:20 -0400 (EDT) Message-ID: <3EF07E53.1050905@cs.columbia.edu> Date: Wed, 18 Jun 2003 10:59:31 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030603 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: A vWijk CC: mhammer@cisco.com, Guido.Gybels@rnid.org.uk, sipping@ietf.org, jon.peterson@neustar.biz Subject: Re: [Sipping] Text support in SIP phones 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 Two quick remarks: - There is a draft, draft-schulzrinne-simple-iscomposing-00.txt, that describes a mechanism for indicating that one party is composing a message. (Composing could include creating a video or audio message.) This is a generalization of the 'is typing' status indication commonly found on commercial IM systems. - Even with one-character-at-a-time transmission, a user interface at the receiver could render the text in more semantically meaningful units (and minus the usual backspace-over-typos annoyance), e.g., on word or CR boundaries. This does impose the burden on the sender to indicate such semantic units. Some senders may prefer to compose their thoughts before sending them or are bad typists, so this one-unit-at-a-time should also be possible for senders. I have no data to back this up, but I suspect that familiarity of the two parties and text communications may influence the preference for message or character mode. If you do this a lot, you either become very good at typing or you don't care if things look a bit jumbled. If I were to send text messages to my Provost, I would want to make sure they are typo-free and correct in grammar. I probably would find a more spontaneous mode more appropriate if 'talking' to my son. I'm also somewhat confused as to why this is an either-or proposition. 2793 is pretty light-weight, so this is hardly an undue burden to implement. (I would find it useful just as a test tool for verifying NAT operation for RTP :-)) A vWijk wrote: > Michael, > > And my point is that the real-time text conversation is for ALL > users. Hearing users DO like to know if the other person is actually > typing or not. Very often IM messages cross each other. Becuase the > other user was taking so much more time to reply, that the original > sender is already adding additional stuff or even questions. That > happens very very often between hearing IM users (or hearing /deaf > etc etc). Yahoo messenger and some other IM clients now have an > indicator when the other user is typing. Also some IM clients offer a > chat mode in IRC style. Which allows for quicker and more interactive > conversation. But it still goes line by line with the mixups. > > The above shows that most users will like the ability to communicate > in real-time using text. And those are hearing users! > > Hence, I URGE all IM designers/programmers to include real-time > streaming text. And use RFC 2793 so that any client can interwork > with any other client. > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 18 14:18:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19586 for ; Wed, 18 Jun 2003 14:18:06 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IIHcJ25614 for sipping-archive@odin.ietf.org; Wed, 18 Jun 2003 14: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 19Sgwy-0004zp-RP for sipping-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 13:42: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 NAA17818 for ; Wed, 18 Jun 2003 13:42:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sguh-00078X-00 for sipping-web-archive@ietf.org; Wed, 18 Jun 2003 13:40:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Sgug-00078U-00 for sipping-web-archive@ietf.org; Wed, 18 Jun 2003 13:40:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SgUX-0003a3-G5; Wed, 18 Jun 2003 13:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sfh9-0001Nr-NB for sipping@optimus.ietf.org; Wed, 18 Jun 2003 12:21: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 MAA14993 for ; Wed, 18 Jun 2003 12:21:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sfet-0006P8-00 for sipping@ietf.org; Wed, 18 Jun 2003 12:19:39 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by ietf-mx with esmtp (Exim 4.12) id 19Sfes-0006Oz-00 for sipping@ietf.org; Wed, 18 Jun 2003 12:19:38 -0400 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h5IGLHTt001784; Wed, 18 Jun 2003 09:21:20 -0700 (PDT) Received: from mhammer-w2k02.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 AEH37365; Wed, 18 Jun 2003 09:21:16 -0700 (PDT) Message-Id: <4.3.2.7.2.20030618114037.049fb810@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 18 Jun 2003 12:21:16 -0400 To: "A vWijk" From: Michael Hammer Cc: , , In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_10409508==_.ALT" Subject: [Sipping] Re: Perspective of a deaf person. Was: Text support in SIP phones Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --=====================_10409508==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed See below. At 03:46 PM 6/18/2003 +0200, A vWijk wrote: >Jon, Michael and others. >Let me bring in my experience as a deaf person. And I am then speaking for >millions and millions of hearing impaired users all over the world! > ><watching someone type mildly interesting in the short run, but as boring >as watching grass grow in the long run.>> > >Well, as Guido said, we are looking for what the most users want. Text >communication is for us hearing impaired people almost the ONLY way to use >the telephone! We, the hearing impaired, want to see the other user type. >Why? We will immediately know that a person is indeed answering, I hope your IM system gives an indication that the other person is responding. >we can see what kind of answer the other person is formulating..and we can >even interrupt There may be a cultural aspect here, as there are some folks who seem to talk over each other. (Although I find that rather rude, especially on TV news shows.) But lurking in there is a requirement for more expressive presence information than simply the fact that I am responding. >and type an answer or comment. >It is then a dialog, real time interaction. IM is a very nice invetion, >but as a daily user of IM. I really dislike the waiting before the other >person is ready with typing. Or the other user might have missed the >message. Or as sometimes desired, thinking about how to formulate a reply. >That is not interactive. But, I do understand the desire to be more immediate. >Compare it in this way: Imagine that voice telephony works like IM. >How well can you place a call? >It would be like a radio communication with Mars, where there is a 20 >seconds delay. So only one side can talk and then wait a while before >getting a reply. >Is that what you want for all the hearing impaired users? I'm wondering if my view of IM is colored by the use of a very good system. A 20 second delay seems extremely slow. Imagine if someone told you email was simply not fast enough because he needed to get responses in less than 24 hours and that was not happening. Should IM get a different level of QoS treatment? I know I get frustrated when my on-line banking transactions take more than a couple seconds, yet this too is best effort. ><to what they are used to, but I'm not so sure which they would choose if >both were available.>> > >As they use other text based solutions in mainstream technology. And they >say to us clearly that it doesn't meet their needs. So, I accept that the >users are telling me what they need/want. Not the other way around.> > >Exactly, we love IM and other text messaging systems since it is the ONLY >way for us right now. But as soon we have a way for real-time text >conversation.. I guarantee that all the hearing impaired users will >immediately switch over to T.140/RTP. > >Now the funny thing is that IM and T.140/RTP can be used side by side in >harmony. Agree that both methods are needed. But, the nature of IM messaging and character by character transmission by be sufficiently different that I'm not sure what you are asking next. >I think that it would be a very good idea if the SIMPLE WG really take a >close look at T.140/RTP (RFC 2793). >Jon? What do you say? > >The special thing about my IETF participation is that I bring in the >experience, views and wishes/needs of the hearing impaired community. >I KNOW what I am talking about and I want to help everybody here to get a >better understanding how not to be able to hear. Everyday things which are >normal for you, become a burden when you cannot hear. This insight should >be considered when designing anything. >Making it mainstream and default in designs is the ONLY way to prevent the >protocol and technology mess in the past (think for example of the >different non interworking text telephone protocols OR how the designers >of the cellular telephony never ever considered to allow for text >telephony over their systems). > >We are talking about functionality that almost all users will like and use. This is where my opinion diverged, then got stomped on. While I do think there is a need to have a non-voice means of interacting, I would like more evidence that hearing users would prefer this over IM. I appreciate the ability to hear. I think the crux is that if I really needed to get the interactivity that you speak of, I would make a phone call. The mobile phone carriers were simply meeting the needs of the majority of users of their system, which by its nature was solely hearing oriented to begin with. That being said, I applaud their expansion into mutliple media realms, which includes IM, video, and yes it should include interactive text too. I agree with the idea that this should be mainstream, not special equipment. However, I do believe in modularity of design and packaging. You wouldn't force everyone to buy an 8-person van if all they needed was a bicycle would you? Hopefully, this feature could be downloaded, plugged-in, and used as needed. I am curious to see the statistics on its use in the coming years. Mike >While it is essential for the hearing and speech impaired to have text >communication, hearing users will also benefit from this. Thus allowing >for many new and exiting services for all users. > >The text support that we as internet community design and implement is for >EVERYBODY. And not for just a few users with specific needs. > >Sincerely, > >Arnoud > > > > > >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 --=====================_10409508==_.ALT Content-Type: text/html; charset="us-ascii" See below.

At 03:46 PM 6/18/2003 +0200, A vWijk wrote:
Jon, Michael and others.
Let me bring in my experience as a deaf person. And I am then speaking for millions and millions of hearing impaired users all over the world!

<<Personally speaking, and maybe I have ADD, but I would find watching  someone type mildly interesting in the short run, but as boring as watching  grass grow in the long run.>>

Well, as Guido said, we are looking for what the most users want. Text communication is for us hearing impaired people almost the ONLY way to use the telephone! We, the hearing impaired, want to see the other user type. Why? We will immediately know that a person is indeed answering,

I hope your IM system gives an indication that the other person is responding.

we can see what kind of answer the other person is formulating..and we can even interrupt

There may be a cultural aspect here, as there are some folks who seem to talk over each other. (Although I find that rather rude, especially on TV news shows.)

But lurking in there is a requirement for more expressive presence information than simply the fact that I am responding.

and type an answer or comment.
It is then a dialog, real time interaction. IM is a very nice invetion, but as a daily user of IM. I really dislike the waiting before the other person is ready with typing. Or the other user might have missed the message. Or as sometimes desired, thinking about how to formulate a reply.
That is not interactive.

But, I do understand the desire to be more immediate.

Compare it in this way: Imagine that voice telephony works like IM.
How well can you place a call?
It would be like a radio communication with Mars, where there is a 20 seconds delay. So only one side can talk and then wait a while before getting a reply.
Is that what you want for all the hearing impaired users?

I'm wondering if my view of IM is colored by the use of a very good system.  A 20 second delay seems extremely slow.  Imagine if someone told you email was simply not fast enough because he needed to get responses in less than 24 hours and that was not happening.

Should IM get a different level of QoS treatment?  I know I get frustrated when my on-line banking transactions take more than a couple seconds, yet this too is best effort.


<<I'm sure those (on both sides) that had no choice have a strong affinity to what they are used to,  but I'm not so sure which they would choose if both were available.>>

<You miss the point that hundreds of thousands of deaf people DO use IM. As they use other text based solutions in mainstream technology. And they say to us clearly that it doesn't meet their needs. So, I accept that the users are telling me what they need/want. Not the other way around.>

Exactly, we love IM and other text messaging systems since it is the ONLY way for us right now. But as soon we have a way for real-time text conversation.. I guarantee that all the hearing impaired users will immediately switch over to T.140/RTP.

Now the funny thing is that IM and T.140/RTP can be used side by side in harmony.

Agree that both methods are needed.  But, the nature of IM messaging and character by character transmission by be sufficiently different that I'm not sure what you are asking next.

I think that it would be a very good idea if the SIMPLE WG really take a close look at T.140/RTP (RFC 2793).
Jon? What do you say?

The special thing about my IETF participation is that I bring in the experience, views and wishes/needs of the hearing impaired community.
I KNOW what I am talking about and I want to help everybody here to get a better understanding how not to be able to hear. Everyday things which are normal for you, become a burden when you cannot hear. This insight should be considered when designing anything.
Making it mainstream and default in designs is the ONLY way to prevent the protocol and technology mess in the past (think for example of the different non interworking text telephone protocols OR how the designers of the cellular telephony never ever considered to allow for text telephony over their systems).

We are talking about functionality that almost all users will like and use.

This is where my opinion diverged, then got stomped on.  While I do think there is a need to have a non-voice means of interacting, I would like more evidence that hearing users would prefer this over IM.  I appreciate the ability to hear.  I think the crux is that if I really needed to get the interactivity that you speak of, I would make a phone call. 

The mobile phone carriers were simply meeting the needs of the majority of users of their system, which by its nature was solely hearing oriented to begin with.  That being said, I applaud their expansion into mutliple media realms, which includes IM, video, and yes it should include interactive text too.

I agree with the idea that this should be mainstream, not special equipment.  However, I do believe in modularity of design and packaging.  You wouldn't force everyone to buy an 8-person van if all they needed was a bicycle would you?  Hopefully, this feature could be downloaded, plugged-in, and used as needed.

I am curious to see the statistics on its use in the coming years.

Mike

While it is essential for the hearing  and speech impaired to have text communication, hearing users will also benefit from this. Thus allowing for many new and exiting services for all users.

The text support that we as internet community design and implement is for EVERYBODY. And not for just a few users with specific needs.

Sincerely,

Arnoud





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
--=====================_10409508==_.ALT-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Jun 18 14:19:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19646 for ; Wed, 18 Jun 2003 14:19:09 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IIIf225892 for sipping-archive@odin.ietf.org; Wed, 18 Jun 2003 14:18:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sgzm-0005EV-4n for sipping-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 13:45: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 NAA17935 for ; Wed, 18 Jun 2003 13:45:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SgxV-0007AW-00 for sipping-web-archive@ietf.org; Wed, 18 Jun 2003 13:42:57 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SgxU-0007AT-00 for sipping-web-archive@ietf.org; Wed, 18 Jun 2003 13:42:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SgWT-0003h6-Id; Wed, 18 Jun 2003 13: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 19Sfob-0001oE-3m for sipping@optimus.ietf.org; Wed, 18 Jun 2003 12:29: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 MAA15255 for ; Wed, 18 Jun 2003 12:29:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SfmK-0006TU-00 for sipping@ietf.org; Wed, 18 Jun 2003 12:27:20 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19SfmJ-0006TO-00 for sipping@ietf.org; Wed, 18 Jun 2003 12:27:19 -0400 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 h5IGSopa029446; Wed, 18 Jun 2003 09:28:51 -0700 (PDT) Received: from mhammer-w2k02.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 AEH39178; Wed, 18 Jun 2003 09:28:49 -0700 (PDT) Message-Id: <4.3.2.7.2.20030618122256.049fa600@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 18 Jun 2003 12:28:49 -0400 To: "A vWijk" From: Michael Hammer Subject: RE: [Sipping] Text support in SIP phones Cc: , , In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_10862529==_.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: , --=====================_10862529==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Arnoud, Are you saying that two users' characters can not cross on the wire with interactive text systems? Also, I never said I hated it. Please don't put words in my mouth. I simply said that I preferred having a chance to edit my thoughts on screen before sending. I also wanted to know the basis of your generalization from the preferences of one group to another group of people. Even without that, I support doing interactive text because there is a need. Mike At 03:58 PM 6/18/2003 +0200, A vWijk wrote: >Michael, > >And my point is that the real-time text conversation is for ALL users. >Hearing users DO like to know if the other person is actually typing or >not. Very often IM messages cross each other. Becuase the other user was >taking so much more time to reply, that the original sender is already >adding additional stuff or even questions. >That happens very very often between hearing IM users (or hearing /deaf >etc etc). >Yahoo messenger and some other IM clients now have an indicator when the >other user is typing. >Also some IM clients offer a chat mode in IRC style. Which allows for >quicker and more interactive conversation. But it still goes line by line >with the mixups. > >The above shows that most users will like the ability to communicate in >real-time using text. And those are hearing users! > >Hence, I URGE all IM designers/programmers to include real-time streaming >text. And use RFC 2793 so that any client can interwork with any other client. > >greetz > >Arnoud > >PS. I am so strong about this because I see how important this real-time >streaming text is. So any comments are not directed to the persons >personally. Everybody is free to have his or her own opinions. You are >free to hate streaming text, but realise that there is a huge user base >who dearly want streaming text. > >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 > > >>> Michael Hammer 06/17/03 05:10pm >>> >Guido, > >Please don't get so defensive. > >You missed the whole point of my statement, which has little to do with >what deaf people prefer, and everything to do with what non-deaf people >might prefer, if both parties were using text-based near-real-time >communications. > >I was responding to your suggestion that non-deaf users would also prefer >the character-by-character mode of operation. I was simply disagreeing >with that assertion. I was also up front that mine was simply an >individual opinion. > >The studies that you cite seemed to be focused on determining what the deaf >experience, and your added comments concerning non-deaf experience appeared >anecdotal. I was merely suggesting that the experiences of both sides of >the communication should be taken into account, for both the asymmetrical >(text/voice) and symmetrical (both text) types of exchanges. > >Your point about the nature of the experience when dealing with the >situation where one party is using text and the other is using voice is a >key distinguishing factor. > >I appreciate the education I am getting by following the discussion. But, >please don't attack me for questioning what the studies are really saying >based on the limited information provided thus far, or for exploring >alternative experiences and opinions. > >Mike > > >At 03:26 PM 6/17/2003 +0100, Guido Gybels wrote: > >Michael, > > > >< >watching someone type mildly interesting in the short run, but as boring > >as watching grass grow in the long run.>> > > > >To be quite frank about this, I was speaking about what deaf and hard of > >hearing people want as a group, not necessarily what you or I want as > >individuals or as techies. Believe me, I have argued a lot about this and > >talked about IM with them etc. The point is that if it doesn't suit their > >requirements, we have to accept that. The technology should adapt to the > >user, not the other way around. > >Apart from that, you have however missed my most important point, namely > >the use of a relay service. When a deaf person wants to talk to a hearing > >person over the relay service, the IM model simply does not work. The > >operators will be speaking to the hearing party as words come through and > >type back to the deaf users almost simultaneously as the voice from the > >hearing party comes true. That is the closest deaf and hard of hearing > >people can get. We have done trials with our gateway and RNID Typetalk > >using deaf and hard of hearing people and the number 1 item was that the > >message style conversation didn't work for them at all in that scenario. I > >think we should accept that the user requirements are the predominant > >driving factor here, not what we would like to develop. I'll leave it to > >Arnoud, who is deaf, to comment on this from the user perspective, but > >based on our research, I'm quite sure I'm right about this. > >As to finding it boring: I have actually used both systems and to be > >honest I find IM much more frustrating than character-by-character. I > >accept that my individual judgement doesn't constitute relevant data, but > >neither does your personal assessment of it being boring. Let's accept > >that user requirements drive this. > > > >< >back later when they are done typing.>> > > > >Which misses the point about using text as an equivalent to voice > >altogether, I'm afraid. Deaf people are not using text as an additional > >medium, it is their version of talking to someone over the phone. I would > >respectfully suggest that we therefore allow *them* to odentify what they > >want as users, rather than having us tell them what they want. > > > >< >anecdotal evidence.>> > > > >Excuse me, the trials we have conducted recently and in the past, as well > >as the experience of 10 years of running RNID Typetalk constitute quite > >relevant expertise. That is quite different to individuals in here voicing > >their personal opinions and speaking on behalf of deaf and hard of hearing > >people. > >There is currently a research project going on under the auspices of TAG > >in the UK, using independent researchers to verify the current assumptions > >and user requirements. I'm more than happy to publish those results to > >IETF when they become available. I take it that you all then agree to > >accept the outcome of that independent research? Do I have a commitment on > >that?? > > > >< >to what they are used to, but I'm not so sure which they would choose if > >both were available.>> > > > >You miss the point that hundreds of thousands of deaf people DO use IM. As > >they use other text based solutions in mainstream technology. And they say > >to us clearly that it doesn't meet their needs. So, I accept that the > >users are telling me what they need/want. Not the other way around. > > > >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 > > > > > > > > > >************************************************************************ > >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 > >************************************************************************ --=====================_10862529==_.ALT Content-Type: text/html; charset="us-ascii" Arnoud,

Are you saying that two users' characters can not cross on the wire with interactive text systems?

Also, I never said I hated it.  Please don't put words in my mouth.  I simply said that I preferred having a chance to edit my thoughts on screen before sending.  I also wanted to know the basis of your generalization from the preferences of one group to another group of people.

Even without that, I support doing interactive text because there is a need.

Mike


At 03:58 PM 6/18/2003 +0200, A vWijk wrote:
Michael,

And my point is that the real-time text conversation is for ALL users.
Hearing users DO like to know if the other person is actually typing or not. Very often IM messages cross each other. Becuase the other user was taking so much more time to reply, that the original sender is already adding additional stuff or even questions.
That happens very very often between hearing IM users (or hearing /deaf etc etc).
Yahoo messenger and some other IM clients now have an indicator when the other user is typing.
Also some IM clients offer a chat mode in IRC style. Which allows for quicker and more interactive conversation. But it still goes line by line with the mixups.

The above shows that most users will like the ability to communicate in real-time using text. And those are hearing users!

Hence, I URGE all IM designers/programmers to include real-time streaming text. And use RFC 2793 so that any client can interwork with any other client.

greetz

Arnoud

PS. I am so strong about this because I see how important this real-time streaming text is. So any comments are not directed to the persons personally. Everybody is free to have his or her own opinions. You are free to hate streaming text, but realise that there is a huge user base who dearly want streaming text.

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

>>> Michael Hammer <mhammer@cisco.com> 06/17/03 05:10pm >>>
Guido,

Please don't get so defensive.

You missed the whole point of my statement, which has little to do with
what deaf people prefer, and everything to do with what non-deaf people
might prefer, if both parties were using text-based near-real-time
communications.

I was responding to your suggestion that non-deaf users would also prefer
the character-by-character mode of operation.  I was simply disagreeing
with that assertion.  I was also up front that mine was simply an
individual opinion.

The studies that you cite seemed to be focused on determining what the deaf
experience, and your added comments concerning non-deaf experience appeared
anecdotal.  I was merely suggesting that the experiences of both sides of
the communication should be taken into account, for both the asymmetrical
(text/voice) and symmetrical (both text) types of exchanges.

Your point about the nature of the experience when dealing with the
situation where one party is using text and the other is using voice is a
key distinguishing factor.

I appreciate the education I am getting by following the discussion.  But,
please don't attack me for questioning what the studies are really saying
based on the limited information provided thus far, or for exploring
alternative experiences and opinions.

Mike


At 03:26 PM 6/17/2003 +0100, Guido Gybels wrote:
>Michael,
>
><<Personally speaking, and maybe I have ADD, but I would find
>watching  someone type mildly interesting in the short run, but as boring
>as watching  grass grow in the long run.>>
>
>To be quite frank about this, I was speaking about what deaf and hard of
>hearing people want as a group, not necessarily what you or I want as
>individuals or as techies. Believe me, I have argued a lot about this and
>talked about IM with them etc. The point is that if it doesn't suit their
>requirements, we have to accept that. The technology should adapt to the
>user, not the other way around.
>Apart from that, you have however missed my most important point, namely
>the use of a relay service. When a deaf person wants to talk to a hearing
>person over the relay service, the IM model simply does not work. The
>operators will be speaking to the hearing party as words come through and
>type back to the deaf users almost simultaneously as the voice from the
>hearing party comes true. That is the closest deaf and hard of hearing
>people can get. We have done trials with our gateway and RNID Typetalk
>using deaf and hard of hearing people and the number 1 item was that the
>message style conversation didn't work for them at all in that scenario. I
>think we should accept that the user requirements are the predominant
>driving factor here, not what we would like to develop. I'll leave it to
>Arnoud, who is deaf, to comment on this from the user perspective, but
>based on our research, I'm quite sure I'm right about this.
>As to finding it boring: I have actually used both systems and to be
>honest I find IM much more frustrating than character-by-character. I
>accept that my individual judgement doesn't constitute relevant data, but
>neither does your personal assessment of it being boring. Let's accept
>that user requirements drive this.
>
><<I would more likely turn my attention to other tasks at work and come
>back later when they are done typing.>>
>
>Which misses the point about using text as an equivalent to voice
>altogether, I'm afraid. Deaf people are not using text as an additional
>medium, it is their version of talking to someone over the phone. I would
>respectfully suggest that we therefore allow *them* to odentify what they
>want as users, rather than having us tell them what they want.
>
><<So, I'm not so sure we can draw well-founded conclusions based on some
>anecdotal evidence.>>
>
>Excuse me, the trials we have conducted recently and in the past, as well
>as the experience of 10 years of running RNID Typetalk constitute quite
>relevant expertise. That is quite different to individuals in here voicing
>their personal opinions and speaking on behalf of deaf and hard of hearing
>people.
>There is currently a research project going on under the auspices of TAG
>in the UK, using independent researchers to verify the current assumptions
>and user requirements. I'm more than happy to publish those results to
>IETF when they become available. I take it that you all then agree to
>accept the outcome of that independent research? Do I have a commitment on
>that??
>
><<I'm sure those (on both sides) that had no choice have a strong affinity
>to what they are used to,  but I'm not so sure which they would choose if
>both were available.>>
>
>You miss the point that hundreds of thousands of deaf people DO use IM. As
>they use other text based solutions in mainstream technology. And they say
>to us clearly that it doesn't meet their needs. So, I accept that the
>users are telling me what they need/want. Not the other way around.
>
>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
>
>
>
>
>************************************************************************
>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
>************************************************************************
--=====================_10862529==_.ALT-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Wed Jun 18 15:31:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24719 for ; Wed, 18 Jun 2003 15:31:39 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IJVAX07112 for sipping-archive@odin.ietf.org; Wed, 18 Jun 2003 15:31:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SiWN-0001dP-Bh for sipping-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 15: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 PAA24074 for ; Wed, 18 Jun 2003 15:23:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SiU7-0000dz-00 for sipping-web-archive@ietf.org; Wed, 18 Jun 2003 15:20:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SiU6-0000dw-00 for sipping-web-archive@ietf.org; Wed, 18 Jun 2003 15:20:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SiHq-00017C-UC; Wed, 18 Jun 2003 15: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 19Si8w-0000G1-4H for sipping@optimus.ietf.org; Wed, 18 Jun 2003 14:58: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 OAA21797 for ; Wed, 18 Jun 2003 14:58:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Si6e-0000LM-00 for sipping@ietf.org; Wed, 18 Jun 2003 14:56:28 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19Si6d-0000Kt-00 for sipping@ietf.org; Wed, 18 Jun 2003 14:56:27 -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 h5IIvhwH013372; Wed, 18 Jun 2003 14:57:44 -0400 (EDT) Received: from cisco.com ([161.44.79.70]) by cannon.cisco.com (Mirapoint) with ESMTP id ABL29174; Wed, 18 Jun 2003 15:06:39 -0400 (EDT) Message-ID: <3EF0B626.1020500@cisco.com> Date: Wed, 18 Jun 2003 14:57:42 -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: seancolson@yahoo.com CC: "'Rosen, Brian'" , hisham.khartabil@nokia.com, jason@azatel.com, rohan@cisco.com, drage@lucent.com, jdrosen@dynamicsoft.com, alan.johnston@wcom.com, sipping@ietf.org Subject: Re: [Sipping] proposed enhancement to dialog package References: <009101c330fb$3bd894c0$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 Sean Olson wrote: > For these different experiences at the UA, do you think you need different > indications in the dialog package? > Is "passive" enough to cover the variety of possibilities here? (My vote is > yes) There are different possibilities that ought to be reflected uniquely. Consider a call from A to B: - A may be attending to the media from B, and visa versa. - A is ignoring the media stream from B, and either sending nothing, sending MoH, progaganda, etc. Meanwhile B is attending to the media stream from A, waiting for A to begin attending again. Typically B is transmitting media, for no particular reason. - A is ignoring the media stream from B and visa versa. Each may or may not be sending junk to the other. - there are a bunch of other permutations, not commonly used. From A's perspective these correspond to a=sendrecv, a=sendonly, a=inactive in the SDP it has provided to B. The 2nd and 3rd both correspond in some sense to HOLD. We don't have great terminology for this. If A pushes the HOLD button on his phone, then he will say he as put the call on hold and B will say he has been put on hold. You put someone on hold when you want to cease attending to the call. If you are put on hold you generally have a social obligation to continue attending, awaiting the return of the other party. My first thought was simply to use the sendrecv/sendonly/recvonly/inactive indications for this purpose. The advantage is that they are coupled to signaling and so are easily accessible. But they lack something, because they don't directly say whether a received stream is being attended to. Unfortunately that requires information from the application above the signaling, and possibly from the actual user. Paul > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Thursday, June 12, 2003 8:05 AM > To: 'hisham.khartabil@nokia.com'; jason@azatel.com; rohan@cisco.com; > seancolson@yahoo.com > Cc: drage@lucent.com; jdrosen@dynamicsoft.com; alan.johnston@wcom.com; > sipping@ietf.org > Subject: RE: [Sipping] proposed enhancement to dialog package > > > I've always thought that "music on hold" should be local i.e. my choice of > music for me to listen to, not your choice of music for me to hear. > > Eliminates promotional material also :) > > Brian > > >>-----Original Message----- >>From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>Sent: Thursday, June 12, 2003 10:31 AM >>To: Brian.Rosen@marconi.com; jason@azatel.com; rohan@cisco.com; >>seancolson@yahoo.com >>Cc: drage@lucent.com; jdrosen@dynamicsoft.com; alan.johnston@wcom.com; >>sipping@ietf.org >>Subject: RE: [Sipping] proposed enhancement to dialog package >> >> >>Your desire to hold audio may also be greater when you have >>to pay for audio packets being sent. It might be more >>interesting for the sender to hold the audio that for the receiver. >> >>Hisham >> >> >>>-----Original Message----- >>>From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] >>>Sent: Thursday, June 12, 2003 4:16 PM >>>To: 'Jason Arnold'; Rohan Mahy; Sean Olson >>>Cc: Drage, Keith (Keith); 'Jonathan Rosenberg'; >>>alan.johnston@wcom.com; >>>sipping@ietf.org >>>Subject: RE: [Sipping] proposed enhancement to dialog package >>> >>> >>>May I add some interesting observational data? >>>We now have about a year experience with sip videophones that >>>implement hold. When you are on hold, you see a gray screen that >>>has text indicating the other party put you on hold. We deliver >>>silence on the audio channel. >>> >>>We have lots and lots of feature requests from users. No one has >>>ever asked for audio on hold. The visual information is sufficient. >>> >>>I suspect that you don't need to be entertained, or >> >>pitched. You need >> >>>to know what is happening. If your UA tells you you are on hold, >>>then audio when you are on hold may not be important. >>> >>>One caveat; almost everyone uses our videophone handsfree. >> >>If you are >> >>>holding a handset to your ear, your desire for hold audio may be >>>greater. >>> >>>Brian >>> >>> >>>>-----Original Message----- >>>>From: Jason Arnold [mailto:jason@azatel.com] >>>>Sent: Wednesday, June 11, 2003 7:21 PM >>>>To: Rohan Mahy; Sean Olson >>>>Cc: Drage, Keith (Keith); 'Jonathan Rosenberg'; >>>>alan.johnston@wcom.com; >>>>sipping@ietf.org >>>>Subject: RE: [Sipping] proposed enhancement to dialog package >>>> >>>> >>>>I agree to an extent. >>>> >>>>If the hold presents "dead air", most people will feel lost >>>>with out some >>>>indication that they are on hold. It would seem that people >>>>require the >>>>assurance that the receiving party has not terminated their >>>>call. It could >>>>be assumed that if the hold period is for an extended period >>>>of time, only >>>>presenting silence to the calling party, people may think >>>>they have been >>>>accidentally "disconnected" and terminate their call. >>>> >>>>It is important to supply a media stream (even irritating >>>>propaganda) during >>>>the hold session. Non-Conformity to current expectations of >>>>people while on >>>>hold would seem illogical. >>>> >>>>Thanks, >>>> >>>>Jason >>>> >>>>On Wednesday, June 11, 2003, at 09:40 AM, Sean Olson wrote: >>>> >>>> >>>>>This is an interesting discussion in an almost >>>>>academic sense, but it really does not address the reality of >>>>>the very simple service that is being described here. >>>>> >>>>>"hold", "passive", whatever else you want to call it means not >>>>>sending/receiving media. >>>> >>>>I disagree. >>>> >>>>If you call someone on the average PBX or Key System, and >>> >>>ask them to >>> >>>>put you on hold, you will typically still receive media >>>>(music, tones, >>>>irritating announcements). Likewise, if you call a call >>> >>center or a >> >>>>big store, you are likely to wait "on hold" with some type of >>>>propaganda, music, or recorded message claiming that you are >>>>important. >>>> >>>>Clearly the user experience of the user-visible feature >>> >>>"Hold" is that >>> >>>>hold does not typically equate to "no media". >>>> >>>>I believe that from a feature perspective the existence or >>> >>>presence of >>> >>>>no media being sent/received is irrelevant. It does not affect my >>>>perception that I am on hold, nor does it affect the >>> >>>perception of my >>> >>>>peer if I am on hold or not, since I can receive or not >>> >>>receive media >>> >>>>and still know that I am on hold. >>>> >>>>My assertion is that what users really want to know is if the >>>>other end >>>>is actively participating. Do they care if I am still around? Is >>>>there the potential for interaction between me and my peer? >>>> >>>>With this concept, I can build useful features that users >>> >>can relate >> >>>>to. For example, I would like "passive" participants >>> >>(participants >> >>>>that cannot interact with me, like inane robots sending me >>>>Musak) to be >>>>automatically muted in my conference. >>>> >>>>I would like to express this property. If the name >>> >>"passive" is too >> >>>>confusing, then feel free to suggest other terms. >>> >>"interactivity" >> >>>>EQUAL ( "yes" / "no" ) ? >>>> >>>>thanks, >>>>-rohan >>>> >>>> >>>> >>>>>We've all >>>>>experienced this. And, yes, this can be independent of the >>>>>ability to do SIP signaling. >>>>> >>>>>I think we are focusing too much on signaling here and not >>>>>enough on the user experience that is being built. And I >>>>>certainly don't want a history lesson in ISDN signaling ;-) >>>>> >>>>> >>>>>--- "Drage, Keith (Keith)" wrote: >>>>> >>>>>>See below >>>>>> >>>>>>regards >>>>>> >>>>>>Keith >>>>>> >>>>>>Keith Drage >>>>>>Lucent Technologies >>>>>>Tel: +44 1793 776249 >>>>>>Email: drage@lucent.com >>>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: Rohan Mahy [mailto:rohan@cisco.com] >>>>>>>Sent: 10 June 2003 16:25 >>>>>>>To: Drage, Keith (Keith) >>>>>>>Cc: 'Jonathan Rosenberg'; alan.johnston@wcom.com; >>>>>> >>>>>>'sipping@ietf.org' >>>>>> >>>>>>>Subject: Re: [Sipping] proposed enhancement to >>>>>> >>>>>>dialog package >>>>>> >>>>>>> >>>>>>>Hi Keith, >>>>>>> >>>>>>>Hold as a UI concept significantly predated the >>>>>> >>>>>>development of ISDN. >>>>>> >>>>>>Agreed, and my initial message identified in that >>>>>>case (analogue PSTN terminals) that Hold was originally to >>>>>>recall the register (and there was a manual board equivalent as >>>>>>well) to allow access resources to be used for signalling, as a >>>>>>result of that signalling, the access resources might be used >>>>>>for communication with another party, and only as a >>>>>>by product of that did it necessarily result in loss >>>>>>of communication path with the other party. >>>>>> >>>>>> >>>>>>>In any case, an ISDN user (Alice) who requests an >>>>>> >>>>>>ISDN hold >>>>>> >>>>>>>is still a >>>>>>>passive participant by my definition. When >>>>>> >>>>>>Alice's call is connected >>>>>> >>>>>>>to a conference server and all the active >>>>>> >>>>>>participants say "ok, we're >>>>>> >>>>>>>leaving now, good bye", Alice is not active enough >>>>>> >>>>>>to be able to hang >>>>>> >>>>>>>up. >>>>>> >>>>>>Assuming your last statement still refers to an ISDN user, then >>>>>>I can think of nothing in the above scenario that prevents >>>>>>Alice sending a DISCONNECT, and receiving a RELEASE back. Can >>>>>>you clarify. The DSS1 basic call state machine is totally >>>>>>independent of any subsidiary state machine relating to >>>>>>hold/retrieve. >>>>>> >>>>>>If you are referring to hanging up the conference bridge >>>>>>resources, then this is dependent on the concept of ownership, >>>>>>which varies based on the conference service provided, and also >>>>>>between public and private networks. >>>>>> >>>>>>As a result, I think I am now confused about what >>>>>>you actually mean by passive, can you elaborate further. >>>>>> >>>>>> >>>>>> >>>>>>>I agree that whatever we do, we need to describe >>>>>> >>>>>>the semantics very >>>>>> >>>>>>>crisply. >>>>>>> >>>>>>>thanks, >>>>>>>-rohan >>>>>>> >>>>>>> >>>>>>>On Tuesday, June 10, 2003, at 04:47 AM, Drage, >>>>>> >>>>>>Keith (Keith) wrote: >>>>>> >>>>>>>>I fail to see how thw property you are proposing >>>>>>> >>>>>>correlates in some >>>>>> >>>>>>>>way to any concept of hold. I agree that "hold" >>>>>>> >>>>>>has many meanings, >>>>>> >>>>>>>>based on which type of signalling you are using. >>>>>>>> >>>>>>>>To clarify, the prime function of hold in the >>>>>>> >>>>>>PSTN was never to >>>>>> >>>>>>>>interrupt the communication, that was a side >>>>>>> >>>>>>effect of grabbing the >>>>>> >>>>>>>>access resources to signal to another party. >>>>>>> >>>>>>Thus for ISDN, hold >>>>>> >>>>>>>>therefore was only a removal of access resources >>>>>>> >>>>>>(the >>>>>> >>>>>>>bearer) so that >>>>>>> >>>>>>>>that bearer could be reused for another call; >>>>>>> >>>>>>again the side effect >>>>>> >>>>>>>>was to interrupt the communication. The sole >>>>>>> >>>>>>function of >>>>>> >>>>>>>hold for SIP >>>>>>> >>>>>>>>is to interrupt the communication. >>>>>>>> >>>>>>>>Certainly, if an ISDN user places another user >>>>>>> >>>>>>on hold, I >>>>>> >>>>>>>would regard >>>>>>> >>>>>>>>neither user as "passive" as you seem to be >>>>>>> >>>>>>defining here. >>>>>> >>>>>>>>If we are going to do this, can we make sure we >>>>>>> >>>>>>define the >>>>>> >>>>>>>semantics >>>>>>> >>>>>>>>correctly. Otherwise we will surely create >>>>>>> >>>>>>confusion, >>>>>> >>>>>>>particularly if >>>>>>> >>>>>>>>people try and equate this concept with that of >>>>>>> >>>>>>hold, and in >>>>>> >>>>>>>>particular with the PSTN concept. >>>>>>>> >>>>>>>>regards >>>>>>>> >>>>>>>>Keith >>>>>>>> >>>>>>>> >>>>>>>>Keith Drage >>>>>>>>Lucent Technologies >>>>>>>>Tel: +44 1793 776249 >>>>>>>>Email: drage@lucent.com >>>>>>>> >>>>>>>> >>>>>>>>>-----Original Message----- >>>>>>>>>From: Rohan Mahy [mailto:rohan@cisco.com] >>>>>>>>>Sent: 03 June 2003 22:18 >>>>>>>>>To: 'Jonathan Rosenberg' >>>>>>>>>Cc: rohan@cisco.com; alan.johnston@wcom.com; >>>>>>>> >>>>>>'sipping@ietf.org' >>>>>> >>>>>>>>>Subject: [Sipping] proposed enhancement to >>>>>>>> >>>>>>dialog package >>>>>> >>>>>>>>> >>>>>>>>>Hi, >>>>>>>>> >>>>>>>>>There have been many requests for the dialog >>>>>>>> >>>>>>package to express the >>>>>> >>>>>>>>>concept of hold. The problem is that nobody had >>>>>>>> >>>>>>an especially good >>>>>> >>>>>>>>>definition of what "on-hold" meant. Some >>>>>>>> >>>>>>suggested that all media >>>>>> >>>>>>>>>streams being inactive implied that you are >>>>>>>> >>>>>>"held", but >>>>>> >>>>>>>this doesn't >>>>>>> >>>>>>>>>work for a service such as music-on-hold. >>>>>>>>> >>>>>>>>>I believe that folks actually want a slightly >>>>>>>> >>>>>>different >>>>>> >>>>>>>concept--that >>>>>>> >>>>>>>>>the semantics we want instead are already >>>>>>>> >>>>>>described in the >>>>>> >>>>>>>>>call control >>>>>>>>>framework: >>>>>>>>> >>>>>>>>> >>>>>>>>>>Participants may also be active or passive. >>>>>>>>> >>>>>>Active >>>>>> >>>>>>>participants are >>>>>>> >>>>>>>>>>expected to be intelligent enough to leave a >>>>>>>>> >>>>>>conversation >>>>>> >>>>>>>>>space when >>>>>>>>> >>>>>>>>>>they no longer desire to participate. (An >>>>>>>>> >>>>>>attentive human >>>>>> >>>>>>>>>participant >>>>>>>>> >>>>>>>>>>is obviously active.) Some robotic >>>>>>>>> >>>>>>participants (such as a voice >>>>>> >>>>>>>>>>messaging system, an instant messaging agent, >>>>>>>>> >>>>>>or a voice dialog >>>>>> >>>>>>>>>>system) may be active participants if they can >>>>>>>>> >>>>>>leave the >>>>>> >>>>>>>>>conversation >>>>>>>>> >>>>>>>>>>space when there is no human interaction. >>>>>>>>> >>>>>>Other robots >>>>>> >>>>>>>(for example >>>>>>> >>>>>>>>>>our tone generating robot from the previous >>>>>>>>> >>>>>>example) are passive >>>>>> >>>>>>>>>>participants. A human participant "on-hold" is >>>>>>>>> >>>>>>passive. >>>>>> >>>>>>>>>I think we should add a new attribute to the >>>>>>>> >>>>>>dialog package that >>>>>> >>>>>>>>>expresses this property. My proposal is to >>>>>>>> >>>>>>express this >>>>>> >>>>>>>property only >>>>>>> >>>>>>>>>for the local side of each dialog by adding an >>>>>>>> >>>>>>attribute >>>>>> >>>>>>>to the state >>>>>>> >>>>>>>>>tag in the dialog-info notification body. The >>>>>>>> >>>>>>example below >>>>>> >>>>>>>>>includes a >>>>>>>>>proposed (optional) participation attribute in >>>>>>>> >>>>>>the state tag. >>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>xmlns="urn:ietf:params:xml:ns:dialog-info" >>>>>> >>>>>>>>> version="3" >>>>>>>>> state="partial" >>>>>>>>> entity="sip:caller@bar.com"> >>>>>>>> >>>>>=== message truncated === >>>>> >>>>> >>>>>__________________________________ >>>>>Do you Yahoo!? >>>>>Yahoo! Calendar - Free online calendar with sync to Outlook(TM). >>>>>http://calendar.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 >>> >> >>_______________________________________________ >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>This list is for NEW development of the application of SIP >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sip@ietf.org for new developments of core SIP >> > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 18 22:17:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11741 for ; Wed, 18 Jun 2003 22:17:52 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5J2HPc03247 for sipping-archive@odin.ietf.org; Wed, 18 Jun 2003 22:17:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sotw-0000XB-Ii for sipping-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 22: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 WAA11550 for ; Wed, 18 Jun 2003 22:11:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sore-0005Gl-00 for sipping-web-archive@ietf.org; Wed, 18 Jun 2003 22:09:26 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Sore-0005Gi-00 for sipping-web-archive@ietf.org; Wed, 18 Jun 2003 22:09:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sogb-0008My-DJ; Wed, 18 Jun 2003 21: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 19Sobb-0008GI-Gq for sipping@optimus.ietf.org; Wed, 18 Jun 2003 21:52: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 VAA10962 for ; Wed, 18 Jun 2003 21:52:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SoZJ-00055O-00 for sipping@ietf.org; Wed, 18 Jun 2003 21:50:29 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx with esmtp (Exim 4.12) id 19SoZJ-00055J-00 for sipping@ietf.org; Wed, 18 Jun 2003 21:50:29 -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 h5J1q6C15645; Thu, 19 Jun 2003 01:52:06 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Jun 2003 21:52:40 -0400 Message-ID: <0449D80A0E9B614A83FA9031B07E8D3B257B7A@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'A vWijk'" , mhammer@cisco.com, Guido.Gybels@rnid.org.uk Cc: sipping@ietf.org Date: Wed, 18 Jun 2003 21:52:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] RE: Perspective of a deaf person. Was: Text support in SIP phones Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , > Now the funny thing is that IM and T.140/RTP can be used side by side in harmony. > I think that it would be a very good idea if the SIMPLE WG > really take a close look at T.140/RTP (RFC 2793). > Jon? What do you say? Certainly, Arnould, I don't want to eliminate RFC2793, or suggest that it is inappropriate for use with SIP. But this thread originated with the supposition that RFC2793 MUST be implemented by all SIP telephone devices. I am uncomfortable with that mandate, especially if this requirement leads to a plurality of standards for textual communication. Given the current dominance (right or wrong) of the instant messaging paradigm, both on personal computers and existing cellular telephones (i.e. SMS), by mandating RFC2793 we would be encouraging a split market. By mandating both RFC2793 and, say, SIMPLE instant messaging sessions, we would be requiring that telephone vendors implement two varieties of textual communication on their devices. As you know, mobile phone vendors are especially concerned with minimizing their baseline functionality, given the memory and interface constraints of their devices. Frankly, I find it likely that many vendors would elect to implement only one or the other means of textual communications. This could lead to failures of interoperability - and the prevention of such failures is our most important charge as a standards body. > The special thing about my IETF participation is that I bring > in the experience, views and wishes/needs of the hearing > impaired community. I hope you understand that we value your contribution to the standards process here greatly. [snip] > We are talking about functionality that almost all users will > like and use. While it is essential for the hearing and > speech impaired to have text communication, hearing users > will also benefit from this. Thus allowing for many new and > exiting services for all users. This aesthetic matter is, I think, the hardest thing for the working group to swallow. Many readers probably haven't had much experience with real-time text channels, and at least some users who have (myself included) found it less accessible and useful than the instant messaging model. Ultimately, this may come down to advocating chocolate or vanilla - we can argue about why one or the other is better, but really it's just a matter of taste. I imagine that some hearing-impaired users in the world might prefer instant messaging, and some hearing users might prefer text channels, and so on. The only real beacon of guidance we have is the existing market. And (right or wrong) that market has favored the instant messaging model. Were the market to be seeded with RFC2793 applications, perhaps we would see a shift. But I'm not sure it is our prerogative to mandate that market. Jon Peterson NeuStar, Inc. > The text support that we as internet community design and > implement is for EVERYBODY. And not for just a few users with > specific needs. > > Sincerely, > > Arnoud > > > > > > 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 > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 19 04:02:36 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 EAA04113 for ; Thu, 19 Jun 2003 04:02:36 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5J828K00825 for sipping-archive@odin.ietf.org; Thu, 19 Jun 2003 04: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 19SuAv-0008Jk-DV for sipping-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 03:49: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 DAA03726 for ; Thu, 19 Jun 2003 03:49:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Su8d-0000V4-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 03:47:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Su8d-0000Uy-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 03:47:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Stxi-0007al-Dd; Thu, 19 Jun 2003 03: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 19StrY-0007NS-6A for sipping@optimus.ietf.org; Thu, 19 Jun 2003 03:29: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 DAA03302 for ; Thu, 19 Jun 2003 03:29:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19StpG-0000QE-00 for sipping@ietf.org; Thu, 19 Jun 2003 03:27:18 -0400 Received: from [217.158.120.227] (helo=rnidmail.rnid.org.uk) by ietf-mx with esmtp (Exim 4.12) id 19StpG-0000QA-00 for sipping@ietf.org; Thu, 19 Jun 2003 03:27:18 -0400 Received: from rnid.org.uk (unverified) by rnidmail.rnid.org.uk (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Thu, 19 Jun 2003 08:27:22 +0100 Received: from RNIDMAIL-Message_Server by rnid.org.uk with Novell_GroupWise; Thu, 19 Jun 2003 08:26:38 +0100 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Thu, 19 Jun 2003 08:26:29 +0100 From: "Guido Gybels" To: Cc: , , Subject: RE: [Sipping] Text support in SIP phones Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA04113 Michael, <> It's not a matter of getting defensive. What's happening is that we've voiced a specific requirement for character-by-character interactive text. The case for deaf people is clear, even if it seems that some of us are still trying to lecture deaf people about what they want rather than accepting that the users define their requirements. I've also argued that such a requirement should be brought into mainstream technology because that is the only way you're going to be able to move away from the current position where text telephony is cumbersome, lack interconnectivity and availability and is done using crude and overly expensive devices. What would you hearing people say if you could only phone to someone on the same network, provided they had the same or a similar phone terminal on their desk and that thing would cost 400 quid? I've also stated that I believe that asking for such mainstream support for interactive texting makes sense as a business case too. While it is true that muy organisation has focussed its research on deaf and hard of hearing people, and therefore our findings will reflect the needs of this group, it is untrue that these findings would not have any correlation with mainstream users. The group of deaf and hard of hearing people is a very substantial one. In the UK 1 in 7, 9 million, individuals are affected by deafness and hearing loss. These are not all profoundly deaf people, but they are, as a group, as varied as society itself. What I do know is that the only relevant research as to what user requirements are in terms of buffered versus character-by-character comes from deaf and hard of hearing organisations. If research is lacking with regard to the whole of society, I respectfully suggest that is because you, the industry, have simply not bothered researching it. It's a shambles that my organisation, as a charity, with limited charitable resources, would have to provide relevant data for a group that does not belong to our constituancy in the first place, while the industry does not care about relevant data, except to dismiss well-founded claims from an organisation like RNID, while having failed for 20 years in collecting relevant data to back up their own claims. In the mean time, the politics here seem to matter more than the exclusion of a big group of people who are already being severly disadvantaged in a society where the ability to communicate freely is absolutely essential in order for them to fully participate in that Information Society. I hope you won't mind me pointing to you all as being responsible for some of the barriers deaf and hard of hearing people will face in the next decade if we would fail to do this properly? I have no multi-million pound budgets, nor do I have big marketing departments and strings of lawyers to my disposal to fight you all on this. I can only ask that you open your eyes for the reality with which I have to deal on a daily basis. The requirement we are asking for is extremely lightweight, as Henning acknowledges. It makes perfectly sense to make it a provision that is as basic as SMS on mobile phones, i.e. by default supported, unless there is a good case not to. Surely, as a group of skillled and knowledgeable people, we are able to define clearly which device categories do not require this extremely lightweight provision to be build in? If you maintain that you know better what that deaf and hard of hearing people want, and that these people are all wrong or have all been doing the wrong thing over the last decade, than I invite you and the others who doubt what I am stating, to attend the TAG seminar on text telephony that will take place in the Autumn in London. It will be chaired by deaf people and deaf people will speak about what they want and what they need. I therefore repeat my question that has remained unanswered so far: is this group prepared to accept the requirements of deaf people or not? 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 ************************************************************************ 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 Thu Jun 19 04:32:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05147 for ; Thu, 19 Jun 2003 04:32:14 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5J8VkQ07293 for sipping-archive@odin.ietf.org; Thu, 19 Jun 2003 04:31:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sugr-0001Og-O6 for sipping-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 04:22: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 EAA04805 for ; Thu, 19 Jun 2003 04:22:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Suea-0000nR-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 04:20:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SueZ-0000nO-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 04:20:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SuNq-0000JR-3E; Thu, 19 Jun 2003 04: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 19Su8E-0008Ct-G1 for sipping@optimus.ietf.org; Thu, 19 Jun 2003 03: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 DAA03629 for ; Thu, 19 Jun 2003 03:46:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Su5x-0000UO-00 for sipping@ietf.org; Thu, 19 Jun 2003 03:44:33 -0400 Received: from [217.158.120.227] (helo=rnidmail.rnid.org.uk) by ietf-mx with esmtp (Exim 4.12) id 19Su5w-0000U9-00 for sipping@ietf.org; Thu, 19 Jun 2003 03:44:32 -0400 Received: from rnid.org.uk (unverified) by rnidmail.rnid.org.uk (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Thu, 19 Jun 2003 08:39:41 +0100 Received: from RNIDMAIL-Message_Server by rnid.org.uk with Novell_GroupWise; Thu, 19 Jun 2003 08:38:56 +0100 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Thu, 19 Jun 2003 08:38:28 +0100 From: "Guido Gybels" To: , Cc: , , Subject: Re: [Sipping] Text support in SIP phones Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA05147 Henning, Thanks for the comments! <> Indeed, my IM system does provide that. But interactivity does not end with being able to see that the user is typing. That is only 1 aspect of it. What people keep missing here is the point that deaf people use text as an equivalent to voice, with all the characteristics that this brings with it, including realtime flow of the conversation and the option to interrupt or barge in. IM simply does not offer that. <> The point being that if you're deaf you don't have a choice! The request to be able to communicate using text as en *equivalent* to voice (and not as an additional modality as it is for hearing people) is crucial. It is also required for relay services. <> Voice conversations are spontaneous when compared to written, more formal communications. In using text as a substitute for voice, the interactive and spontaneous nature of the conversation is critical in order to get the equivalent experience. <> Well, it is certainly nor an either-or option in my view. I have stated clearly that I have absolutely no problems with IM. On the contrary, I personally use it a lot. I'm just stating that providing an interactive text provision as a *basic* and *standardised* feature is crucial if we want to move deaf and hard of hearing people into mainstream technology. <<2793 is pretty light-weight, so this is hardly an undue burden to implement.>> Which was exactly the point I have been making for a while now and I'm very happy that someone of your reputation supports that assessment. I must say that I'm puzzled as to why others are so scared of it, since it is that light-weight and easy to implement anyhow. You would think that the industry would be happy that they can deliver inclusion at such negligible cost. All the best, 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 ************************************************************************ 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 Thu Jun 19 04:56:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05574 for ; Thu, 19 Jun 2003 04:56:18 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5J8to112421 for sipping-archive@odin.ietf.org; Thu, 19 Jun 2003 04:55:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sv4X-0002fC-B2 for sipping-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 04:47:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05347 for ; Thu, 19 Jun 2003 04:47:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sv2F-0000wA-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 04:44:47 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Sv2E-0000w7-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 04:44:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sum2-0001fX-5m; Thu, 19 Jun 2003 04: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 19SuTD-0000sw-NS for sipping@optimus.ietf.org; Thu, 19 Jun 2003 04: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 EAA04264 for ; Thu, 19 Jun 2003 04:08:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SuQw-0000d4-00 for sipping@ietf.org; Thu, 19 Jun 2003 04:06:14 -0400 Received: from [217.158.120.227] (helo=rnidmail.rnid.org.uk) by ietf-mx with esmtp (Exim 4.12) id 19SuQv-0000ck-00 for sipping@ietf.org; Thu, 19 Jun 2003 04:06:13 -0400 Received: from rnid.org.uk (unverified) by rnidmail.rnid.org.uk (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Thu, 19 Jun 2003 09:06:24 +0100 Received: from RNIDMAIL-Message_Server by rnid.org.uk with Novell_GroupWise; Thu, 19 Jun 2003 09:05:41 +0100 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Thu, 19 Jun 2003 09:05:16 +0100 From: "Guido Gybels" To: , Cc: , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Subject: [Sipping] Re: Perspective of a deaf person. Was: Text support in SIPphones Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA05574 Michael, <> Even if it does, that hardly makes it the equivalent of voice. I know it is difficult for hearing people to understand, but consider all the characteristics of voice conversation and try to transpose voice to text. Maybe that makes it more clear. And then remember that text is not an *additional* modality to deaf and hard of hearing people. <> Are you saying that you have never been in casual phone calls where someone interrupts you in the midst of a sentence? Only seeing that someone is typing does not solve the problem there: interrupting or discussing with someone implies that you have been following the conversation and barge in at the appropriate moment or when a keyword appears. In text, that is only possible if you can see what is actually being said at that moment, not at a later stage. <> You've missed the point! It is NOT about presence. It is about CONTENT and the ability to interact with that content as it is being generated. That is the nature of voice conversations. And if you have to use text rather than voice because you are deaf, you will want the equivalent experience. Presence will not solve it. <> You've missed the point again: email is NOT interactive. It is store and forward. People use email as one of the modalities they have to their disposal. As they use IM. The kind of buffered experience of IM is simply not able to replace the immediate and interactive nature of voice conversations and therefore IM cannot be the text equivalent of spoken conversations for deaf and hard of hearing people. And I hope I do not have to repeat the problem of relay services? Oh, BTW, I received an email from a person (hearing!) yesterday as part of a different discussion, but he mentioned IM. I quote: "I believe that you should think that it is reasonable to design text communication systems that allow character-at-a-time transmission. ICQ works that way and it's a nice feature. It improves the overall efficiency of real-time textual exchange. Most instant messaging systems today are "slow", as the users have to sit and wait for a message to be fully entered and transmitted. They're a bit awkward, as compared to having a chat window that allows users to type simultaneously and to see text coming in real-time. By using RFC 2793, we can get what I'm describing. In my opinion, it makes for a better product." I know of lots of other hearing people who share that opinion. So, it seems to me unlikely that deaf and hard of hearing people are so substantially different that what works for them would be foreign to hearing people. After all: "Deaf people can do anything except hear" (King Jordan) <> Oh come on, if anything got stomped on it was our genuine demand for making interactive texting a default part of mainstream technology. Let's not fudge the issue here: for political reasons, some people in here don't want to support that, probably in order to further other agendas. What annoys me is that the result of that political discussion will be that the exclusion of deaf and hard of hearing people in our Information Society increases and the barriers they face become bigger. Cynically, the hearing people that will be responsible for it will not be the ones that suffer as result of that. Let's not obfuscate things here: we all know very well that unless you have the "MUST" in that document, we will not meet the objective of having mainstream support for this and we will go back to the present situation of non-available, expensive and non-interoperable "special" needs equipment. <> That's kind of a rude thing to say to someone who is DEAF and who cannot use voice. And while you are free to state your own preferences, I can cite a hearing person with the opposite opinion that they would welcome interactive texting as an alternative to voice. Let's face it: relevant data is not the sum of anecdotal evidence. <> So, you are in effect stating that they were right in ignoring the needs of deaf and hard of hearing people, who after all had been able to use textphones for quite a long time before mobile went mainstream?? And that we should continue to do so? Let me point out again that because the ability to communicate while on the move has become such an essential tool in employment, social life and entertainment, deaf and hard of hearing people are now in many respects worse off than before the GSM revolution. Thank you so much, technology! We spent billions on them, yet they are unable to provide something as simple as a text equivalent to the millions of deaf and hard of hearing people! <> The comparison is preposterous. We are not asking for a van where a bike would do, I find something inherently insulting in this comparison. What we ask for is a very small, light-weight provision. It can hardly get any simpler. Maybe all we ask for is that every bike is fitted with a head light. And we argue that will benefit all drivers. <> It is not just a terminal issue. To be able to do the above, the network will have to support it to begin with. And unless it is a mainstream solution that is part of the standard provisions, there is no chance that would happen with the level of interconnectivity that is required. <> Well, it doesn't take a genius to figure out that if it is not going to be mainstream, the usage will suffer. 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 ************************************************************************ 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 Thu Jun 19 04:56:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05589 for ; Thu, 19 Jun 2003 04:56:45 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5J8uIP12527 for sipping-archive@odin.ietf.org; Thu, 19 Jun 2003 04:56:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sv8y-00034b-9g for sipping-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 04:51: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 EAA05488 for ; Thu, 19 Jun 2003 04:51:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sv6g-0000yv-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 04:49:22 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Sv6f-0000ys-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 04:49:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Supt-0001zf-VM; Thu, 19 Jun 2003 04: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 19Sua4-0001CD-5D for sipping@optimus.ietf.org; Thu, 19 Jun 2003 04: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 EAA04477 for ; Thu, 19 Jun 2003 04:15:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SuXm-0000hc-00 for sipping@ietf.org; Thu, 19 Jun 2003 04:13:18 -0400 Received: from pine.neustar.com ([209.173.57.70]) by ietf-mx with esmtp (Exim 4.12) id 19SuXl-0000hT-00 for sipping@ietf.org; Thu, 19 Jun 2003 04:13:17 -0400 Received: from chiimc01.npac.com ([10.32.90.4]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id h5J8F6N17711; Thu, 19 Jun 2003 08:15:06 GMT Received: by CHIIMC01 with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Jun 2003 03:17:48 -0500 Message-ID: <0449D80A0E9B614A83FA9031B07E8D3B257B8D@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Guido Gybels'" , sipping@ietf.org Cc: A.vWijk@viataal.nl Subject: RE: [Sipping] Text support in SIP phones Date: Thu, 19 Jun 2003 03:15:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , > I'm sorry, we're missing the point here. SMS is not a viable > alternative to realtime communication for deaf and hard of > hearing people. It is not the equivalent of voice for hearing > people. It is an additional modality that deaf people do use, > because it fits their abilities and preferences. I think it is important to distinguish between abilities and preferences. It is not my preference, for example, to use G.711 for audio communications - its fidelity is pretty poor. My preference would be to use a wideband codec, like L16. For that matter, I have a hard time understanding why I still need to communicate via telephones at all - I would prefer a fully immersive virtual reality rig. Nokia folks, where is that on your release calendar? But to return to my more modest ambition, why am I stuck with G.711 rather than L16 in the PSTN? Because G.711 is ubiquitous and entrenched, and it is sufficient for audio communications. Similarly, SMS is ubiquitous and entrenched, and it is sufficient for textual communication. I don't think it will be easy to persuade this group that any alternative to RFC2793 is not 'viable'. Instant messaging is obviously and eminently viable, even if it isn't ideal from an aesthetic perspective. > However, to > communicate interactively using text. especially with a relay > service, you need a character-by-character interactive > communication. We are running a pilot and experiments > comparing character-by-character conversations between deaf > text users and hearing people over the RNID Typetalk relay > service, and it is clear that message based communications do > not fulfil there needs at all. The relay service is an interesting case, and one that I think highlights some of the difficulties with these arguments for text channels. In order for a (human or robotic) operator at a relay service to vocalize textual communications, they need more than a single character - I don't think these operators can plausibly sound out words on a character-by-character basis. Some minimal number of phonemes need to be acquired by the relay before it can vocalize - and in Indo-European languages, to provide correct inflection to speech, several words worth of context are probably necessary. Instant messaging users often parcel complex utterances into multiple messages to avoid the IM equivalent of an awkward silence. ok wait a minute if you think this is too long we can divvy it up into little parts it'll be easier to understand that way Users could also elect to concatenate those fragments into a single message, of course, but the point is that instant messaging admits of levels of granularity chosen by the sender. > With regard to T.140, there can hardly be any market > assessment since it is simply not commonly available, unlike > SMS for instance. > Character-by-character network transmission is, from my persepective, not a new idea entering the market - it is an idea that was briefly the de facto standard for UNIX-to-UNIX communication before the rollout of EFnet and the golden age of IRC. talk(1) had its chance at market dominance, and I believe there are clear reasons why it was obsoleted by modern IM systems (one issue I mentioned before, conferencing, I won't explore in further detail here). For one thing, managing typos in these systems is always problematic. I would often watch someone type out most of a sentence and then change their mind and backspace over the whole thing (if backspace worked in that terminal type - more often than not it led to patches ^H^H^H^H across the screen). People like myself who compulsively rework what they are typing make frustrating conversationalists in that medium. I also found that two-way character-by-character transmission led to a lot of simultaneous typing, balking, waiting for the other person to continue with their thought or to defer to you - the social mechanics seemed quite awkward. Issues with typos would be compounded, I would think, by any kind of relay service that vocalized on a character-by-character basis. What sound would an automaton produce in response to a backspace? Is there an audio equivalent of ^H? > < about the RFC2793 paradigm in the past - and we have > considered it for some applications.>> > > First of all, when hearing people are being put in front of > an interactive text based system like the ones based on > T.140, they love it. The feeling of interactivity is much > greater than with things like IM. But if users simply have no > choice, sure than there is no market... > The lack of supply might be credibly attributed to a lack of demand. *NIX is far more prevalent and available to common users today than it was in the early nineties (gratis to Mr. Torvalds & co). 'talk' has no doubt been grandfathered into any number of modern operating systems. Somehow it doesn't seem to have provided a real challenge to the ten of millions of users boasted by any of the large commercial instant messaging systems. Given the sheer diversity of start-ups targeting the instant messaging space, if emulation of UNIX 'talk' were a positive differentiating factor, surely someone would have offered it by now? [snip] > (in which it takes much longer to reach 's' than 'p').>> > > We are already looking at solutions for that, like > (configurable) word based buffering on mobiles for instance, > so that you can use small keyboards and predictive texting. > Also, heavy text users might opt to connect larger keyboards > to the system and I know at least one BT foldable keyboard > for use with a mobile phone. SIP deskphones can have a > full-size keyboard added to them where required. > I agree that once the device is no longer strictly a telephone (and is effectively a personal computer with a keyboard etc), there are good arguments for encouraging and even mandating all sorts of supported media types. But this does not entail that RFC2793 should be mandatory for vanilla telephone devices. > < communication in telephone devices, I think it should more > closely correspond to the irrefutable direction of the > marketplace - the instant messaging paradigm.>> > > I'm not so sure that direction is so irrefutable as you claim > it to be. The truth is that IM still is hampered by the whole > interconnectivity issue and that users have not really had > any choice so far. Releasing applications that do offer an > alternative to IM by providing more character-by-character > based implementations while providing interconnectivity with > existing IM systems as well as legacy TTYs (like the current > RNID pilot which will go public early 2004 and might even be > offered license free) might change the current picture dramatically. > If I would get a penny for every time someone in technology > has claimed something was never going to happen and was > proven incorrect afterwards > The suggestion above that RNID, at some future time, might not be offered 'license free' rings a few additional alarm bells with me. I am even less comfortable mandating something for all SIP telephones that will require royalty payments. > < exclusion of, say, the outcome of SIMPLE's instant messaging > sessions work.>> > > I don't think that is what anyone is asking for. There is no > reason at all why SIMPLE and RFC2793 cannot live together > simultaneously. They are simply separate issues. Remember > though that, certainly in Europe, IM will *not* fulfil the > legal and regulatory obligations on service providers and > manufacturers and that those obligations will become even > more strict with the implementation of the famous 4 EC > Directives on Communication which is now taking place in all > the member states and should be completed over the next > couple of months. RFC2793 will comply with those > requirements. It's up to the community to decide whether or > not they want to be burdened by more regulation or > legislation or whether they will try to fulfil those > requirements through mainstream solutions that will benefit > their business case. I would note that it is not the philosophy of the IETF to cater to regulations that contradict market direction and our WGs' technical judgment. > 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 Thu Jun 19 05:35:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06057 for ; Thu, 19 Jun 2003 05:35:03 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5J9YaS19112 for sipping-archive@odin.ietf.org; Thu, 19 Jun 2003 05: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 19SvcT-0004Wx-O4 for sipping-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 05:22: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 FAA05854 for ; Thu, 19 Jun 2003 05:22:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SvaB-00014o-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 05:19:51 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SvaB-00014l-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 05:19:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SvHx-0003SN-DB; Thu, 19 Jun 2003 05: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 19Sv9z-0003AW-Dq for sipping@optimus.ietf.org; Thu, 19 Jun 2003 04:52: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 EAA05521 for ; Thu, 19 Jun 2003 04:52:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sv7h-0000zU-00 for sipping@ietf.org; Thu, 19 Jun 2003 04:50:25 -0400 Received: from comsrv.com.dtu.dk ([192.38.77.2]) by ietf-mx with esmtp (Exim 4.12) id 19Sv7g-0000zR-00 for sipping@ietf.org; Thu, 19 Jun 2003 04:50:25 -0400 Received: by comsrv.com.dtu.dk with Internet Mail Service (5.5.2650.21) id ; Thu, 19 Jun 2003 10:52:43 +0200 Message-ID: <0FAFFBDC8353D211B00A00104B0CDCBF01C9F7BF@comsrv.com.dtu.dk> From: =?iso-8859-1?Q?Jos=E9_Soler_Lucas?= To: "'sipping@ietf.org'" Date: Thu, 19 Jun 2003 10:52:43 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] How to Register multiple users with a single REGISTER 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA06057 Hi, Lets see if you can help me with the following issue: Suposse there is a need to register a series of n users, with SIP URI of the form SIP:(whatever)@hostname, so that (whatever) contains [common pattern] for all the usser adresses to be registered. Furthermore, all the users will have the same REGISTER´s Contact header. Is it possible to use regular expressions in a SIP URI? This would allow for this case to specify a SIP URI in the TO Header field of the REGISTER, using regular expressions, that apply to an adress like: SIP:*[common patern]*@hostname? In such a way, if a registrar can handle this kind of REGISTER messages, the registration would be single and it wouldn´t need to be updated for every new user with the [common pattern] to be added. Well, thanks a lot in advance. Best regards, josé -------------------------------------------- José Soler Lucas, M.Sc.Telecom.E. PhD Student Networks Competence Area Research Center COM (Communications, Optics and Materials) Technical University of Denmark Building 343, DK 2800 Kgs. Lyngby, Denmark. Phone: +45 45 25 38 08 (direct) Fax: +45 45 93 65 81 E-mail: jsoler@com.dtu.dk Web: http://www.com.dtu.dk/staff/jso/ ---- Cellular: +45 22 27 48 22 -------------------------------------------- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 19 05:41: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 FAA06228 for ; Thu, 19 Jun 2003 05:41:33 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5J9f6A21304 for sipping-archive@odin.ietf.org; Thu, 19 Jun 2003 05:41:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SveM-0004hD-MG for sipping-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 05: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 FAA05884 for ; Thu, 19 Jun 2003 05:24:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Svc3-00015c-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 05:21:47 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Svc3-00015Z-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 05:21:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SvLq-0003bu-0z; Thu, 19 Jun 2003 05:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SvC7-0003CB-AT for sipping@optimus.ietf.org; Thu, 19 Jun 2003 04:54: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 EAA05559 for ; Thu, 19 Jun 2003 04:54:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sv9p-000107-00 for sipping@ietf.org; Thu, 19 Jun 2003 04:52:37 -0400 Received: from [217.158.120.227] (helo=rnidmail.rnid.org.uk) by ietf-mx with esmtp (Exim 4.12) id 19Sv9o-000104-00 for sipping@ietf.org; Thu, 19 Jun 2003 04:52:36 -0400 Received: from rnid.org.uk (unverified) by rnidmail.rnid.org.uk (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Thu, 19 Jun 2003 09:52:44 +0100 Received: from RNIDMAIL-Message_Server by rnid.org.uk with Novell_GroupWise; Thu, 19 Jun 2003 09:52:02 +0100 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Thu, 19 Jun 2003 09:51:39 +0100 From: "Guido Gybels" To: , , Cc: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Subject: [Sipping] RE: Perspective of a deaf person. Was: Text support in SIP phones Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA06228 Jon, <> But not for the reasons you state, but because unless you mandate it, it will not be able to use it to bring services for deaf and hard of hearing people into the mainstream. I'm also annoyed by the fact that you seem to ignore what I have suggested on multiple occasions now: make it mandatory, except for well-defined cases. Failure to do so will mean giving up on the idea of mainstream support for this important requirement. If that is what people want, for whatever political motives, I suggest they are clear and unambiguous about that. <> and <> I can't believe this. The IM market is already heavily split internally. Interactive text requirements are an alternative modality, not a competing one. Many posters have acknowledged already it is not an either-or option. <> Yes, and most mobile manufacturers will find something light-weigt as RFC2793 quite attractive, especially if that will fulfil their legal and regulatory obligations in Europe where IM will not do so. <> There is no point in heaving an interoperable system that can't fulfil the requirements. IM will not be able to provide deaf and hard of hearing people with what they need, including access to relay services. If you then don't have something like RFC2793 in mainstream, we'll be back where we are now: a plethora of proprietary solutions that don't interwork, are not widely accessible and relay on special terminals. <> I hope we will do more than expressing our sympathies to deaf and hard of hearing people. As I have said in another post: we are on a point where we can either do it right, or do it wrong. We, as hearing people, won't suffer the consequences of doing it wrong, but I hope that doesn't decrease or motivation to do the right thing. <> It's hardly up to hearing people to say what deaf people want. And, as so many others, you have missed the crucial point: that deaf people use text not as an *additional* or *alternative* modality, but as a substitute for voice. IM cannot deliver that and neither can it deliver relay access. You are hereby also invited to attend the TAG seminar in the qutumn in London. You can hear from deaf people what they want then and maybe you could spend a couple of days with them as well, that might shed a new light on things. <> Oh, no, it isn't! It is no question of taste, it is a question of abilities. Deaf people have no choice but to use text rather than voice. It is not about aesthetics. Maybe if you would have been in my job, you would start to appreciate that point a bit more, I don't know, but what I see is that many people here still fail to understand what is going on and what the requirement is. That scares me, because it will lead to the wrong decisions that will impact extremely heavily on deaf and hard of hearing people. <> I'm sorry, hearing impaired users that rely on text as a substitute to voice do not have a choice. They cannot use IM for that, and that includes the inability to use relay services in a meaningful way. <> Yes, and that market has steadily increased the disadvantage for deaf and hard of hearing people in a society that is ever more dependent on access to telecommunications. You might not see it, but I am faced daily with the consequences of that. Please leave it to deaf and hard of hearing people to decide what they need and what they want. The market certainbly hasn't served them well. So I guess that means the question to you is: do you want to maintain the current discriminating situation or are you prepared to do something about it? <> Ah, so it is our prerogative to mess up deaf and hard of hearing people instead? Is that our mandate?? 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 ************************************************************************ 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 Thu Jun 19 06:24:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07486 for ; Thu, 19 Jun 2003 06:24:17 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JANph28390 for sipping-archive@odin.ietf.org; Thu, 19 Jun 2003 06:23:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SwOR-00072J-7Z for sipping-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 06:11: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 GAA07149 for ; Thu, 19 Jun 2003 06:11:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SwM7-0001Ma-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 06:09:23 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SwM7-0001MX-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 06:09:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SvzV-0005o2-KL; Thu, 19 Jun 2003 05:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Svs1-0005Or-Fu for sipping@optimus.ietf.org; Thu, 19 Jun 2003 05:38: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 FAA06148 for ; Thu, 19 Jun 2003 05:38:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Svpj-00019R-00 for sipping@ietf.org; Thu, 19 Jun 2003 05:35:55 -0400 Received: from [217.158.120.227] (helo=rnidmail.rnid.org.uk) by ietf-mx with esmtp (Exim 4.12) id 19Svpi-00019A-00 for sipping@ietf.org; Thu, 19 Jun 2003 05:35:54 -0400 Received: from rnid.org.uk (unverified) by rnidmail.rnid.org.uk (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Thu, 19 Jun 2003 10:36:04 +0100 Received: from RNIDMAIL-Message_Server by rnid.org.uk with Novell_GroupWise; Thu, 19 Jun 2003 10:35:21 +0100 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Thu, 19 Jun 2003 10:35:01 +0100 From: "Guido Gybels" To: , Cc: Subject: RE: [Sipping] Text support in SIP phones Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA07486 Jon, <> Indeed. <> I find that one of the most arrogant and insulting statements to deaf people that I have seen in quite a while. Deaf people cannot use SMS as a substitute to text conversation. Your implicitly saying that they shouldn't expect any better, even if it doesn't meet their requirements. SMS is an available service. Hearing people use it. So do deaf people. But that has absolutely nothing to do with their requirements to use text as an equivalent to voice. <> I find it offensive, even as a hearing person (albeit one that works with deaf people all day) to decide on behalf of deaf people about what they want or need. I suggest strongly that you leave it to them to decide what their requirements are and I believe you are mnistaken if you think the majority of this group would support the view that it is up to hearing people to decide what deaf people need. Deaf people have already established that IM is not able to meet their needs, not in the least because of the requirement to use relay services to communicate with hearing people. If you want to discuss on mainstream markets, fine, but please refrain from patronising deaf and hard of hearing people or dictating to them what they need. >>The relay service is an interesting case, and one that I think highlights some of the difficulties with these arguments for text channels. In order for a (human or robotic) operator at a relay service to vocalize textual communications, they need more than a single character - I don't think these operators can plausibly sound out words on a character-by-character basis.>> The operator will certainly type almost in RT what is being said, character by character and not word by word. The other way around is difficult enough to achieve in a transparent way with character-by-character, let alone on a sentence base. For practical reasons, it will have to be utterance based, or word or part-of-word based, depending on context. It certainly requires training. But maybe you should visit some relay operators and deaf people and use it on a daily basis for some months before making assumptions on what works and what doesn't. I'll repeat that we have experience from the gateway pilot and that the clear and ambiguous feedback is that buffered messaging just doesn't work for relay services. I suggest it is left to deaf people and to organisations like RNID to formulate what this group wants. <> I speak 6 Indo-European languages and I have seen relay working in most of them and they certainly don't require several words to vocalise. Relay services are certainly not perfect, but it is as close as it can get to seamless communication between text and voice. Let me suggest that you leave it to relay operators like RNID Typetalk, operating 24/24, 7/7, every day of the year. There is constant research and development done here for at least a decade now and there is also constant discussion going on with the users through user panels and research. <<-snip- of orthogonal discussion>> <> LOL! Tell that to the deaf community. Seldom have I seen such a display of ignorance about how deaf people communicate and what their needs are than in the above. I'm not trying to be offending, but I simply have no better way of describing it. <> It does if you accept that the ability to use text as an equivalent to voice is essential for deaf people to participate fully in our information society. If you don't care about that, it probably doesn't need to be mandatory. <> ??? I have no idea what you are talking about, I was merely stating that RNID is willing to offer the result of their research and developments to the PUBLIC (in which after all charitable money is being invested) for FREE. There is no talk about royalty payments whatsoever, I don't know what you read in my words, but you could not be further of the mark. RNID is not a commercial organisation, we are a CHARITY for Christ' sake! I am not aware of RFC2793 requiring any royalties at all. It is typical that people would read something in there that was not present in what I said, neither explicitly nor implicitly. <> There is nothing contradictory to the market direction. That is rubbish. We are talking plainly and simply about making sure a big user group is not being further excluded and disadvantaged in society. I'm amazed by the hostility that you have aired in this message towards such a goal of inclusion. I would have thought everybody would have benefitted from being able to bring these users in the mainstream market. How that can be perceived as being opposite to the market direction I don't know, but that is probably because I'm incompetent. 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 ************************************************************************ 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 Thu Jun 19 07:30:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09200 for ; Thu, 19 Jun 2003 07:30:50 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JBULQ06529 for sipping-archive@odin.ietf.org; Thu, 19 Jun 2003 07:30:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SxU6-0001NF-Jr for sipping-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 07:21: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 HAA08802 for ; Thu, 19 Jun 2003 07:21:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SxRp-0001mR-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 07:19:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SxRo-0001mO-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 07:19:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SxHo-0000ri-Pk; Thu, 19 Jun 2003 07: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 19Sx6i-0000J3-FG for sipping@optimus.ietf.org; Thu, 19 Jun 2003 06:57: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 GAA08325 for ; Thu, 19 Jun 2003 06:57:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sx4P-0001fN-00 for sipping@ietf.org; Thu, 19 Jun 2003 06:55:09 -0400 Received: from mta05.btfusion.com ([62.172.195.14]) by ietf-mx with esmtp (Exim 4.12) id 19Sx4O-0001ee-00 for sipping@ietf.org; Thu, 19 Jun 2003 06:55:08 -0400 Received: from [217.34.231.189] (helo=ictgateway.ictrnid.org.uk) by mta05.btfusion.com with smtp (Exim 4.10) id 19Sx65-0001GJ-00; Thu, 19 Jun 2003 10:56:53 +0000 Received: from 192.168.1.33 ([192.168.1.33]) by ictgateway.ictrnid.org.uk (WinRoute Pro 4.1.29) with SMTP; Thu, 19 Jun 2003 11:56:46 +0100 From: "James Hamlin" To: "\"Jon Peterson\"" Cc: , , , Subject: RE: [Sipping] RE: Perspective of a deaf person. Was: Text support in SIP phones Date: Thu, 19 Jun 2003 11:56:46 +0100 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.6604 (9.0.2911.0) Importance: Normal 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 Jon <> I think the aesthetics aren't as problematic as one might at first think. Sending data character-by-character (RFC2793/T.140) does not imply that the user interface needs to look like a conventional textphone screen. The presentation to the user can look like an IM session. The only difference is that as you type, the characters appear to the person at the other end. The history of the conversation can still be presented in a line-by-line way just as it is in existing IM clients. I don't think that users of existing IM will be frightened off when their conversation becomes character-by-character. Indeed I believe they will embrace it when they realise that it speeds up their communication. <> I would say that SMS is used much more like email than IM at present. As I said in the previous paragraph, I don't think IM users will notice a great change when character-by-character transport is used. It is possible to put "packagers" in the network so that networks that take the sensible - in our view - step of using character-by-character systems can still provide compatibility with others that are message based. This does mean that networks can provide character-by-character without risking incompatibility with those that fail to do so. << The only real beacon of guidance we have is the existing market. And (right or wrong) that market has favored the instant messaging model. Were the market to be seeded with RFC2793 applications, perhaps we would see a shift. But I'm not sure it is our prerogative to mandate that market. >> Already in the UK there is a legal requirement for the telecommunications industry to provide a PSTN relay service (that uses human operators to translate between voice and text). It is most likely that such provision will become mandatory across all networks. While running a pilot system that bridges between Instant Messaging and the PSTN, we have discovered that IM introduces a delay which many users describe as unacceptable. My conclusion is that there will be a legal mandate for character-by-character messaging. RFC2793 need not be a hindrance to IM users, fragmentation of standards can be mitigated and there will be legal motivation that overrides the free market. Regards James ----------------------------- Message: 2 From: "Peterson, Jon" To: "'A vWijk'" , mhammer@cisco.com, Guido.Gybels@rnid.org.uk Cc: sipping@ietf.org Date: Wed, 18 Jun 2003 21:52:33 -0400 Subject: [Sipping] RE: Perspective of a deaf person. Was: Text support in SIP phones > Now the funny thing is that IM and T.140/RTP can be used side by side in harmony. > I think that it would be a very good idea if the SIMPLE WG > really take a close look at T.140/RTP (RFC 2793). > Jon? What do you say? Certainly, Arnould, I don't want to eliminate RFC2793, or suggest that it is inappropriate for use with SIP. But this thread originated with the supposition that RFC2793 MUST be implemented by all SIP telephone devices. I am uncomfortable with that mandate, especially if this requirement leads to a plurality of standards for textual communication. Given the current dominance (right or wrong) of the instant messaging paradigm, both on personal computers and existing cellular telephones (i.e. SMS), by mandating RFC2793 we would be encouraging a split market. By mandating both RFC2793 and, say, SIMPLE instant messaging sessions, we would be requiring that telephone vendors implement two varieties of textual communication on their devices. As you know, mobile phone vendors are especially concerned with minimizing their baseline functionality, given the memory and interface constraints of their devices. Frankly, I find it likely that many vendors would elect to implement only one or the other means of textual communications. This could lead to failures of interoperability - and the prevention of such failures is our most important charge as a standards body. > The special thing about my IETF participation is that I bring > in the experience, views and wishes/needs of the hearing > impaired community. I hope you understand that we value your contribution to the standards process here greatly. [snip] > We are talking about functionality that almost all users will > like and use. While it is essential for the hearing and > speech impaired to have text communication, hearing users > will also benefit from this. Thus allowing for many new and > exiting services for all users. This aesthetic matter is, I think, the hardest thing for the working group to swallow. Many readers probably haven't had much experience with real-time text channels, and at least some users who have (myself included) found it less accessible and useful than the instant messaging model. Ultimately, this may come down to advocating chocolate or vanilla - we can argue about why one or the other is better, but really it's just a matter of taste. I imagine that some hearing-impaired users in the world might prefer instant messaging, and some hearing users might prefer text channels, and so on. The only real beacon of guidance we have is the existing market. And (right or wrong) that market has favored the instant messaging model. Were the market to be seeded with RFC2793 applications, perhaps we would see a shift. But I'm not sure it is our prerogative to mandate that market. 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 Thu Jun 19 09:24:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17071 for ; Thu, 19 Jun 2003 09:24:09 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JDNgL31410 for sipping-archive@odin.ietf.org; Thu, 19 Jun 2003 09:23:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sz4c-0006hT-5p for sipping-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 09:03:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16185 for ; Thu, 19 Jun 2003 09:03:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sz2J-0003s9-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 09:01:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Sz2J-0003s6-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 09:01:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sygw-0005Yj-Rx; Thu, 19 Jun 2003 08:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sy3h-0003Af-NE for sipping@optimus.ietf.org; Thu, 19 Jun 2003 07: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 HAA10857 for ; Thu, 19 Jun 2003 07:58:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sy1P-00028P-00 for sipping@ietf.org; Thu, 19 Jun 2003 07:56:07 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19Sy1P-00028M-00 for sipping@ietf.org; Thu, 19 Jun 2003 07:56:07 -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, 19 Jun 2003 13:01:10 +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" Subject: RE: [Sipping] Text support in SIP phones Date: Thu, 19 Jun 2003 12:58:27 +0100 Message-ID: <45730E094814E44488F789C1CDED27AE01E22BDB@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Sipping] Text support in SIP phones Thread-Index: AcM2SzFkm+4gCogNRCWFTjfldLPxFwADoCTg From: "Chris Boulton" To: "Guido Gybels" , , Cc: Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA17071 Guido, Maybe it would be an idea for your research to be made available to the group - thus allowing a range of information for members with less experience in this area and to provide a balanced opinion. Chris. >-----Original Message----- >From: Guido Gybels [mailto:Guido.Gybels@rnid.org.uk] >Sent: 19 June 2003 10:35 >To: sipping@ietf.org; jon.peterson@neustar.biz >Cc: A.vWijk@viataal.nl >Subject: RE: [Sipping] Text support in SIP phones > >Jon, > ><preferences.>> > >Indeed. > ><textual communication.>> > >I find that one of the most arrogant and insulting statements to deaf >people that I have seen in quite a while. Deaf people cannot use SMS as a >substitute to text conversation. Your implicitly saying that they shouldn't >expect any better, even if it doesn't meet their requirements. SMS is an >available service. Hearing people use it. So do deaf people. But that has >absolutely nothing to do with their requirements to use text as an >equivalent to voice. > ><to RFC2793 is not 'viable'. Instant messaging is obviously and eminently >viable, even if it isn't ideal from an aesthetic perspective.>> > >I find it offensive, even as a hearing person (albeit one that works with >deaf people all day) to decide on behalf of deaf people about what they >want or need. I suggest strongly that you leave it to them to decide what >their requirements are and I believe you are mnistaken if you think the >majority of this group would support the view that it is up to hearing >people to decide what deaf people need. Deaf people have already >established that IM is not able to meet their needs, not in the least >because of the requirement to use relay services to communicate with >hearing people. If you want to discuss on mainstream markets, fine, but >please refrain from patronising deaf and hard of hearing people or >dictating to them what they need. > >>>The relay service is an interesting case, and one that I think highlights >some of the difficulties with these arguments for text channels. In order >for a (human or robotic) operator at a relay service to vocalize textual >communications, they need more than a single character - I don't think >these operators can plausibly sound out words on a character-by-character >basis.>> > >The operator will certainly type almost in RT what is being said, character >by character and not word by word. The other way around is difficult enough >to achieve in a transparent way with character-by-character, let alone on a >sentence base. For practical reasons, it will have to be utterance based, >or word or part-of-word based, depending on context. It certainly requires >training. But maybe you should visit some relay operators and deaf people >and use it on a daily basis for some months before making assumptions on >what works and what doesn't. > >I'll repeat that we have experience from the gateway pilot and that the >clear and ambiguous feedback is that buffered messaging just doesn't work >for relay services. > >I suggest it is left to deaf people and to organisations like RNID to >formulate what this group wants. > ><it can vocalize - and in Indo-European languages, to provide correct >inflection to speech, several words worth of context are probably >necessary.>> > >I speak 6 Indo-European languages and I have seen relay working in most of >them and they certainly don't require several words to vocalise. Relay >services are certainly not perfect, but it is as close as it can get to >seamless communication between text and voice. Let me suggest that you >leave it to relay operators like RNID Typetalk, operating 24/24, 7/7, every >day of the year. There is constant research and development done here for >at least a decade now and there is also constant discussion going on with >the users through user panels and research. > ><<-snip- of orthogonal discussion>> ><> > >LOL! Tell that to the deaf community. Seldom have I seen such a display of >ignorance about how deaf people communicate and what their needs are than >in the above. I'm not trying to be offending, but I simply have no better >way of describing it. > ><telephone devices.>> > >It does if you accept that the ability to use text as an equivalent to >voice is essential for deaf people to participate fully in our information >society. If you don't care about that, it probably doesn't need to be >mandatory. > ><'license free' rings a few additional alarm bells with me. I am even less >comfortable mandating something for all SIP telephones that will require >royalty payments.>> > >??? I have no idea what you are talking about, I was merely stating that >RNID is willing to offer the result of their research and developments to >the PUBLIC (in which after all charitable money is being invested) for >FREE. There is no talk about royalty payments whatsoever, I don't know what >you read in my words, but you could not be further of the mark. RNID is not >a commercial organisation, we are a CHARITY for Christ' sake! I am not >aware of RFC2793 requiring any royalties at all. It is typical that people >would read something in there that was not present in what I said, neither >explicitly nor implicitly. > ><regulations that contradict market direction and our WGs' technical >judgment.>> > >There is nothing contradictory to the market direction. That is rubbish. We >are talking plainly and simply about making sure a big user group is not >being further excluded and disadvantaged in society. I'm amazed by the >hostility that you have aired in this message towards such a goal of >inclusion. I would have thought everybody would have benefitted from being >able to bring these users in the mainstream market. How that can be >perceived as being opposite to the market direction I don't know, but that >is probably because I'm incompetent. > >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 > > > >*********************************************************************** * >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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 19 09:24:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17086 for ; Thu, 19 Jun 2003 09:24:10 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JDNhb31454 for sipping-archive@odin.ietf.org; Thu, 19 Jun 2003 09:23:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sz5O-0006qJ-GI for sipping-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 09:04: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 JAA16221 for ; Thu, 19 Jun 2003 09:04:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sz36-0003tH-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 09:01:56 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Sz35-0003tE-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 09:01:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sygx-0005Yz-TU; Thu, 19 Jun 2003 08: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 19SyEH-0003q3-HZ for sipping@optimus.ietf.org; Thu, 19 Jun 2003 08:09: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 IAA11289 for ; Thu, 19 Jun 2003 08:09:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SyBz-0002F4-00 for sipping@ietf.org; Thu, 19 Jun 2003 08:07:03 -0400 Received: from [217.158.120.227] (helo=rnidmail.rnid.org.uk) by ietf-mx with esmtp (Exim 4.12) id 19SyBx-0002Eq-00 for sipping@ietf.org; Thu, 19 Jun 2003 08:07:02 -0400 Received: from rnid.org.uk (unverified) by rnidmail.rnid.org.uk (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Thu, 19 Jun 2003 13:07:11 +0100 Received: from RNIDMAIL-Message_Server by rnid.org.uk with Novell_GroupWise; Thu, 19 Jun 2003 13:06:25 +0100 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Thu, 19 Jun 2003 13:06:07 +0100 From: "Guido Gybels" To: , , Cc: Subject: RE: [Sipping] Text support in SIP phones Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA17086 Chris, <> We have scheduled the writing and publishing of a number of White Papers on the issue. As we are a charity with limited resources and so many things to do, it is unlikely that will happen before Q1 or even Q2 next year. 2004 will also see the publishing of the TAG (and BT funded) research on text telephony. Apart from that. we have done a survey, sponsored by Nokia, in 2001-2002 across well over 15.000 subjects. Processing of that data is still ongoing, and as that is a massive amount of work, I don't expect publication before the end of this year either. We simply have no resources to put dozens of people on that. Apart from that, publication of our research to the wider public has always been our intention. Apart from formal publication as and when the studies are ready, I cannot do much more at the time than share our expertise and knowledge, as a charity that operates in the field of deafness and hearing loss since 1911, including referral to feedback from user trials on some of our relevant pilots. 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 ************************************************************************ 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 Thu Jun 19 09:52:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18059 for ; Thu, 19 Jun 2003 09:52:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JDq4m06256 for sipping-archive@odin.ietf.org; Thu, 19 Jun 2003 09:52:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Szpc-0001cp-PT for sipping-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 09:52: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 JAA18028 for ; Thu, 19 Jun 2003 09:52:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SznK-0004NP-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 09:49:42 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SznJ-0004NM-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 09:49:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Szpa-0001bt-8V; Thu, 19 Jun 2003 09: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 19Szp9-0001SX-9M for sipping@optimus.ietf.org; Thu, 19 Jun 2003 09:51: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 JAA18010 for ; Thu, 19 Jun 2003 09:51:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Szmq-0004Mw-00 for sipping@ietf.org; Thu, 19 Jun 2003 09:49:12 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19Szmp-0004Mt-00 for sipping@ietf.org; Thu, 19 Jun 2003 09:49:11 -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, 19 Jun 2003 14:54:14 +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" Subject: RE: [Sipping] Text support in SIP phones Date: Thu, 19 Jun 2003 14:51:31 +0100 Message-ID: <45730E094814E44488F789C1CDED27AE0219AFFA@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Sipping] Text support in SIP phones Thread-Index: AcM2Y0s10knOwIetRnytARx+j5Q6FQABadfw From: "Chris Boulton" To: "Guido Gybels" , , Cc: Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA18059 Guido, I fully understand your frustration and passion to include such technology as mainstream due to the results of your research BUT in Jon's defense, until organizations like yours are able to publish the results of such research, he will always be inclined to build a model that 'best fits' current practice/demand. It is up to you to deviate this opinion with hard facts that illustrate desire for change, rather than accusations. Chris. >-----Original Message----- >From: Guido Gybels [mailto:Guido.Gybels@rnid.org.uk] >Sent: 19 June 2003 13:06 >To: sipping@ietf.org; jon.peterson@neustar.biz; Chris Boulton >Cc: A.vWijk@viataal.nl >Subject: RE: [Sipping] Text support in SIP phones > >Chris, > ><group - thus allowing a range of information for members with >less experience in this area and to provide a balanced opinion.>> > >We have scheduled the writing and publishing of a number of White Papers on >the issue. As we are a charity with limited resources and so many things to >do, it is unlikely that will happen before Q1 or even Q2 next year. 2004 >will also see the publishing of the TAG (and BT funded) research on text >telephony. Apart from that. we have done a survey, sponsored by Nokia, in >2001-2002 across well over 15.000 subjects. Processing of that data is >still ongoing, and as that is a massive amount of work, I don't expect >publication before the end of this year either. We simply have no resources >to put dozens of people on that. >Apart from that, publication of our research to the wider public has always >been our intention. Apart from formal publication as and when the studies >are ready, I cannot do much more at the time than share our expertise and >knowledge, as a charity that operates in the field of deafness and hearing >loss since 1911, including referral to feedback from user trials on some of >our relevant pilots. > >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 > > > > >*********************************************************************** * >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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 19 10:00:31 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 KAA18611 for ; Thu, 19 Jun 2003 10:00:31 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JE04d07941 for sipping-archive@odin.ietf.org; Thu, 19 Jun 2003 10:00:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SzxM-000240-DF for sipping-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 10:00: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 KAA18560 for ; Thu, 19 Jun 2003 10:00:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Szv3-0004TJ-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 09:57:41 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Szv2-0004TG-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 09:57:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SzxK-00023L-2s; Thu, 19 Jun 2003 10: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 19Szx9-000202-SY for sipping@optimus.ietf.org; Thu, 19 Jun 2003 09:59: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 JAA18520 for ; Thu, 19 Jun 2003 09:59:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Szur-0004Su-00 for sipping@ietf.org; Thu, 19 Jun 2003 09:57:29 -0400 Received: from [217.158.120.227] (helo=rnidmail.rnid.org.uk) by ietf-mx with esmtp (Exim 4.12) id 19Szuq-0004Sl-00 for sipping@ietf.org; Thu, 19 Jun 2003 09:57:28 -0400 Received: from rnid.org.uk (unverified) by rnidmail.rnid.org.uk (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Thu, 19 Jun 2003 14:57:38 +0100 Received: from RNIDMAIL-Message_Server by rnid.org.uk with Novell_GroupWise; Thu, 19 Jun 2003 14:56:52 +0100 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Thu, 19 Jun 2003 14:56:37 +0100 From: "Guido Gybels" To: , , Cc: Subject: RE: [Sipping] Text support in SIP phones Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA18611 Chris, <> The fatal flaw in the reasoning here being that while the industry is expecting *charities* like ourselves to come up with "hard facts", they have so far been unable to provide hard evidence to support the contrary either. It's all assumption or, even worse, hearing people trying to tell deaf people what they need. And I'd like to point out that we do HAVE the well-expressed desire from change, from within the deaf community, a FACT that you seem to ignore. It seems however, that the industry is unwilling to accept that. If they don't accept that, why don't they ask deaf people directly, rather than dismiss what is being said. I also note that Arnoud, being deaf, is happily ignored as a voice of the deaf community. Thus, it all boils down to this: does the industry accept that organisations like RNID, who represent the interests of deaf and hard of hearing people AND do have the daily expertise in this field, as being able to voice the needs and requirements of deaf and hard of hearing people?? With "accusations" this has little to do. Do I take it you're willing to say publicly, for instance on the BBC, that you don't care about the express desires of the deaf community then? 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 ************************************************************************ 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 Thu Jun 19 10:16:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20378 for ; Thu, 19 Jun 2003 10:16:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JEG8911795 for sipping-archive@odin.ietf.org; Thu, 19 Jun 2003 10:16:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T0Cu-00034A-Cr for sipping-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 10:16: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 KAA20314 for ; Thu, 19 Jun 2003 10:16:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T0Ab-0004dr-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 10:13:45 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19T0Aa-0004dn-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 10:13:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T0Co-000338-SM; Thu, 19 Jun 2003 10:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T0Ck-00032H-NB for sipping@optimus.ietf.org; Thu, 19 Jun 2003 10:15: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 KAA20294 for ; Thu, 19 Jun 2003 10:15:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T0AR-0004dc-00 for sipping@ietf.org; Thu, 19 Jun 2003 10:13:35 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19T0AQ-0004dU-00 for sipping@ietf.org; Thu, 19 Jun 2003 10:13:35 -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 KAA04363; Thu, 19 Jun 2003 10:15:23 -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 KAA00439; Thu, 19 Jun 2003 10:15:24 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Jun 2003 10:15:23 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5B02@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Michael Hammer'" , Paul Kyzivat Cc: seancolson@yahoo.com, hisham.khartabil@nokia.com, jason@azatel.com, rohan@cisco.com, drage@lucent.com, jdrosen@dynamicsoft.com, alan.johnston@wcom.com, sipping@ietf.org Subject: RE: [Sipping] proposed enhancement to dialog package Date: Thu, 19 Jun 2003 10:15:22 -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: , Please also make sure that we don't conflate "hold" with "mute". They are different. To make it more interesting, we discovered that users insisted that video mute be two way (you can't see me if I can't see you). The difference between hold and two way mute is that hold really does make the call inactive, while mute does not. Users expectations for what they can do, and what is presented to them, are quite different. Brian -----Original Message----- From: Michael Hammer [mailto:mhammer@cisco.com] Sent: Thursday, June 19, 2003 10:03 AM To: Paul Kyzivat Cc: seancolson@yahoo.com; 'Rosen, Brian'; hisham.khartabil@nokia.com; jason@azatel.com; rohan@cisco.com; drage@lucent.com; jdrosen@dynamicsoft.com; alan.johnston@wcom.com; sipping@ietf.org Subject: Re: [Sipping] proposed enhancement to dialog package Paul, One subtle modification. Extend the hold situation to a conference. When a user hits the hold button, does he put the conference (all the other parties) on hold? Not really. They may still talk to each other. He is really putting himself on hold. Shouldn't the actions that one party takes be a reflection on himself only? E.g., I put myself on hold from the call/conference. I am indicating that I am not attending to media, etc. Mike At 02:57 PM 6/18/2003 -0400, Paul Kyzivat wrote: Sean Olson wrote: For these different experiences at the UA, do you think you need different indications in the dialog package? Is "passive" enough to cover the variety of possibilities here? (My vote is yes) There are different possibilities that ought to be reflected uniquely. Consider a call from A to B: - A may be attending to the media from B, and visa versa. - A is ignoring the media stream from B, and either sending nothing, sending MoH, progaganda, etc. Meanwhile B is attending to the media stream from A, waiting for A to begin attending again. Typically B is transmitting media, for no particular reason. - A is ignoring the media stream from B and visa versa. Each may or may not be sending junk to the other. - there are a bunch of other permutations, not commonly used. From A's perspective these correspond to a=sendrecv, a=sendonly, a=inactive in the SDP it has provided to B. The 2nd and 3rd both correspond in some sense to HOLD. We don't have great terminology for this. If A pushes the HOLD button on his phone, then he will say he as put the call on hold and B will say he has been put on hold. You put someone on hold when you want to cease attending to the call. If you are put on hold you generally have a social obligation to continue attending, awaiting the return of the other party. My first thought was simply to use the sendrecv/sendonly/recvonly/inactive indications for this purpose. The advantage is that they are coupled to signaling and so are easily accessible. But they lack something, because they don't directly say whether a received stream is being attended to. Unfortunately that requires information from the application above the signaling, and possibly from the actual user. Paul -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Thursday, June 12, 2003 8:05 AM To: 'hisham.khartabil@nokia.com'; jason@azatel.com; rohan@cisco.com; seancolson@yahoo.com Cc: drage@lucent.com; jdrosen@dynamicsoft.com; alan.johnston@wcom.com; sipping@ietf.org Subject: RE: [Sipping] proposed enhancement to dialog package I've always thought that "music on hold" should be local i.e. my choice of music for me to listen to, not your choice of music for me to hear. Eliminates promotional material also :) Brian -----Original Message----- From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] Sent: Thursday, June 12, 2003 10:31 AM To: Brian.Rosen@marconi.com; jason@azatel.com; rohan@cisco.com; seancolson@yahoo.com Cc: drage@lucent.com; jdrosen@dynamicsoft.com; alan.johnston@wcom.com; sipping@ietf.org Subject: RE: [Sipping] proposed enhancement to dialog package Your desire to hold audio may also be greater when you have to pay for audio packets being sent. It might be more interesting for the sender to hold the audio that for the receiver. Hisham -----Original Message----- From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Thursday, June 12, 2003 4:16 PM To: 'Jason Arnold'; Rohan Mahy; Sean Olson Cc: Drage, Keith (Keith); 'Jonathan Rosenberg'; alan.johnston@wcom.com; sipping@ietf.org Subject: RE: [Sipping] proposed enhancement to dialog package May I add some interesting observational data? We now have about a year experience with sip videophones that implement hold. When you are on hold, you see a gray screen that has text indicating the other party put you on hold. We deliver silence on the audio channel. We have lots and lots of feature requests from users. No one has ever asked for audio on hold. The visual information is sufficient. I suspect that you don't need to be entertained, or pitched. You need to know what is happening. If your UA tells you you are on hold, then audio when you are on hold may not be important. One caveat; almost everyone uses our videophone handsfree. If you are holding a handset to your ear, your desire for hold audio may be greater. Brian -----Original Message----- From: Jason Arnold [mailto:jason@azatel.com] Sent: Wednesday, June 11, 2003 7:21 PM To: Rohan Mahy; Sean Olson Cc: Drage, Keith (Keith); 'Jonathan Rosenberg'; alan.johnston@wcom.com; sipping@ietf.org Subject: RE: [Sipping] proposed enhancement to dialog package I agree to an extent. If the hold presents "dead air", most people will feel lost with out some indication that they are on hold. It would seem that people require the assurance that the receiving party has not terminated their call. It could be assumed that if the hold period is for an extended period of time, only presenting silence to the calling party, people may think they have been accidentally "disconnected" and terminate their call. It is important to supply a media stream (even irritating propaganda) during the hold session. Non-Conformity to current expectations of people while on hold would seem illogical. Thanks, Jason On Wednesday, June 11, 2003, at 09:40 AM, Sean Olson wrote: This is an interesting discussion in an almost academic sense, but it really does not address the reality of the very simple service that is being described here. "hold", "passive", whatever else you want to call it means not sending/receiving media. I disagree. If you call someone on the average PBX or Key System, and ask them to put you on hold, you will typically still receive media (music, tones, irritating announcements). Likewise, if you call a call center or a big store, you are likely to wait "on hold" with some type of propaganda, music, or recorded message claiming that you are important. Clearly the user experience of the user-visible feature "Hold" is that hold does not typically equate to "no media". I believe that from a feature perspective the existence or presence of no media being sent/received is irrelevant. It does not affect my perception that I am on hold, nor does it affect the perception of my peer if I am on hold or not, since I can receive or not receive media and still know that I am on hold. My assertion is that what users really want to know is if the other end is actively participating. Do they care if I am still around? Is there the potential for interaction between me and my peer? With this concept, I can build useful features that users can relate to. For example, I would like "passive" participants (participants that cannot interact with me, like inane robots sending me Musak) to be automatically muted in my conference. I would like to express this property. If the name "passive" is too confusing, then feel free to suggest other terms. "interactivity" EQUAL ( "yes" / "no" ) ? thanks, -rohan We've all experienced this. And, yes, this can be independent of the ability to do SIP signaling. I think we are focusing too much on signaling here and not enough on the user experience that is being built. And I certainly don't want a history lesson in ISDN signaling ;-) --- "Drage, Keith (Keith)" wrote: See below regards Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com] Sent: 10 June 2003 16:25 To: Drage, Keith (Keith) Cc: 'Jonathan Rosenberg'; alan.johnston@wcom.com; 'sipping@ietf.org' Subject: Re: [Sipping] proposed enhancement to dialog package Hi Keith, Hold as a UI concept significantly predated the development of ISDN. Agreed, and my initial message identified in that case (analogue PSTN terminals) that Hold was originally to recall the register (and there was a manual board equivalent as well) to allow access resources to be used for signalling, as a result of that signalling, the access resources might be used for communication with another party, and only as a by product of that did it necessarily result in loss of communication path with the other party. In any case, an ISDN user (Alice) who requests an ISDN hold is still a passive participant by my definition. When Alice's call is connected to a conference server and all the active participants say "ok, we're leaving now, good bye", Alice is not active enough to be able to hang up. Assuming your last statement still refers to an ISDN user, then I can think of nothing in the above scenario that prevents Alice sending a DISCONNECT, and receiving a RELEASE back. Can you clarify. The DSS1 basic call state machine is totally independent of any subsidiary state machine relating to hold/retrieve. If you are referring to hanging up the conference bridge resources, then this is dependent on the concept of ownership, which varies based on the conference service provided, and also between public and private networks. As a result, I think I am now confused about what you actually mean by passive, can you elaborate further. I agree that whatever we do, we need to describe the semantics very crisply. thanks, -rohan On Tuesday, June 10, 2003, at 04:47 AM, Drage, Keith (Keith) wrote: I fail to see how thw property you are proposing correlates in some way to any concept of hold. I agree that "hold" has many meanings, based on which type of signalling you are using. To clarify, the prime function of hold in the PSTN was never to interrupt the communication, that was a side effect of grabbing the access resources to signal to another party. Thus for ISDN, hold therefore was only a removal of access resources (the bearer) so that that bearer could be reused for another call; again the side effect was to interrupt the communication. The sole function of hold for SIP is to interrupt the communication. Certainly, if an ISDN user places another user on hold, I would regard neither user as "passive" as you seem to be defining here. If we are going to do this, can we make sure we define the semantics correctly. Otherwise we will surely create confusion, particularly if people try and equate this concept with that of hold, and in particular with the PSTN concept. regards Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com] Sent: 03 June 2003 22:18 To: 'Jonathan Rosenberg' Cc: rohan@cisco.com; alan.johnston@wcom.com; 'sipping@ietf.org' Subject: [Sipping] proposed enhancement to dialog package Hi, There have been many requests for the dialog package to express the concept of hold. The problem is that nobody had an especially good definition of what "on-hold" meant. Some suggested that all media streams being inactive implied that you are "held", but this doesn't work for a service such as music-on-hold. I believe that folks actually want a slightly different concept--that the semantics we want instead are already described in the call control framework: Participants may also be active or passive. Active participants are expected to be intelligent enough to leave a conversation space when they no longer desire to participate. (An attentive human participant is obviously active.) Some robotic participants (such as a voice messaging system, an instant messaging agent, or a voice dialog system) may be active participants if they can leave the conversation space when there is no human interaction. Other robots (for example our tone generating robot from the previous example) are passive participants. A human participant "on-hold" is passive. I think we should add a new attribute to the dialog package that expresses this property. My proposal is to express this property only for the local side of each dialog by adding an attribute to the state tag in the dialog-info notification body. The example below includes a proposed (optional) participation attribute in the state tag. === message truncated === __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 19 10:40:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22190 for ; Thu, 19 Jun 2003 10:40:00 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JEdXw17687 for sipping-archive@odin.ietf.org; Thu, 19 Jun 2003 10:39:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T0ZZ-0004bC-J1 for sipping-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 10:39: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 KAA22097 for ; Thu, 19 Jun 2003 10:39: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 19T0Z3-0004SM-PJ; Thu, 19 Jun 2003 10:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T0Yg-0004S8-3T for sipping@optimus.ietf.org; Thu, 19 Jun 2003 10:38: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 KAA22007 for ; Thu, 19 Jun 2003 10:38:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T0WM-0004xW-00 for sipping@ietf.org; Thu, 19 Jun 2003 10:36:14 -0400 Received: from law12-f87.law12.hotmail.com ([64.4.19.87] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19T0WM-0004xE-00 for sipping@ietf.org; Thu, 19 Jun 2003 10:36:14 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 19 Jun 2003 07:37:59 -0700 Received: from 193.220.224.9 by lw12fd.law12.hotmail.msn.com with HTTP; Thu, 19 Jun 2003 14:37:58 GMT X-Originating-IP: [193.220.224.9] X-Originating-Email: [rajarshi_chakraborty@hotmail.com] From: "Rajarshi Chakraborty" To: jsoler@com.dtu.dk, sipping@ietf.org Subject: Re: [Sipping] How to Register multiple users with a single REGISTER message Date: Thu, 19 Jun 2003 14:37:58 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Jun 2003 14:37:59.0155 (UTC) FILETIME=[61342430:01C33670] X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA22008 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA22190 This is very interesting Jose. But the first thing that comes to my mind is the security concern. What if some illegitimate user (someone who has not subscribed to the SIP services offered) creates a user name for itself that matches that "common pattern"? There may be few other issues. regards, Rajarshi Rajarshi Chakraborty B-196, IIT Campus, Kharagpur, West Bengal, India PIN-721302 ----Original Message Follows---- From: José Soler Lucas To: "'sipping@ietf.org'" Subject: [Sipping] How to Register multiple users with a single REGISTER message Date: Thu, 19 Jun 2003 10:52:43 +0200 Hi, Lets see if you can help me with the following issue: Suposse there is a need to register a series of n users, with SIP URI of the form SIP:(whatever)@hostname, so that (whatever) contains [common pattern] for all the usser adresses to be registered. Furthermore, all the users will have the same REGISTER´s Contact header. Is it possible to use regular expressions in a SIP URI? This would allow for this case to specify a SIP URI in the TO Header field of the REGISTER, using regular expressions, that apply to an adress like: SIP:*[common patern]*@hostname? In such a way, if a registrar can handle this kind of REGISTER messages, the registration would be single and it wouldn´t need to be updated for every new user with the [common pattern] to be added. Well, thanks a lot in advance. Best regards, josé -------------------------------------------- José Soler Lucas, M.Sc.Telecom.E. PhD Student Networks Competence Area Research Center COM (Communications, Optics and Materials) Technical University of Denmark Building 343, DK 2800 Kgs. Lyngby, Denmark. Phone: +45 45 25 38 08 (direct) Fax: +45 45 93 65 81 E-mail: jsoler@com.dtu.dk Web: http://www.com.dtu.dk/staff/jso/ ---- Cellular: +45 22 27 48 22 -------------------------------------------- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _________________________________________________________________ Wedding blues? Need help? http://www.msn.co.in/Matrimony/ _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 19 10:59: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 KAA22964 for ; Thu, 19 Jun 2003 10:59:34 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JEx6j21155 for sipping-archive@odin.ietf.org; Thu, 19 Jun 2003 10:59:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T0sU-0005V8-Gg for sipping-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 10:59: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 KAA22898 for ; Thu, 19 Jun 2003 10:59:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T0qB-00058s-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 10:56:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19T0qA-00058p-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 10:56:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T0sQ-0005Tu-2x; Thu, 19 Jun 2003 10:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T0sI-0005Sf-TT for sipping@optimus.ietf.org; Thu, 19 Jun 2003 10:58: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 KAA22890 for ; Thu, 19 Jun 2003 10:58:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T0pz-00058Z-00 for sipping@ietf.org; Thu, 19 Jun 2003 10:56:31 -0400 Received: from comsrv.com.dtu.dk ([192.38.77.2]) by ietf-mx with esmtp (Exim 4.12) id 19T0py-00058W-00 for sipping@ietf.org; Thu, 19 Jun 2003 10:56:31 -0400 Received: by comsrv.com.dtu.dk with Internet Mail Service (5.5.2650.21) id ; Thu, 19 Jun 2003 16:58:50 +0200 Message-ID: <0FAFFBDC8353D211B00A00104B0CDCBF01C9F7C9@comsrv.com.dtu.dk> From: =?iso-8859-1?Q?Jos=E9_Soler_Lucas?= To: "'Rajarshi Chakraborty'" , sipping@ietf.org Subject: RE: [Sipping] How to Register multiple users with a single REGIST ER message Date: Thu, 19 Jun 2003 16:58:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA22964 Hi Rajarshi, Thanks a lot for the response. You are right: it represents a security problem for certain services. Anyway it will be the service itself the one registering such numbers...what about publicly available services that need no subscription? Just to consider some applicable case as an example: consider a sip application server (AS) that offers a weather information service through a SIP proxy that proxies INVITE messages to the (AS) arriving to it with the following To SIP URI name_of_town_weather@domain.com If the application server has to register each town´s info address into the proxy it can be really unpractical. In the other hand, if it is allowed to register something like $\w.[_weather]@domain.com and the proxy ´s registrars recognises it as a request for registration of whatever contains the common pattern [_weather] then the service is much simpler from the communication point of view (ammount of messages). To mention the real case I am dealing with, the application I am concerned is with a "SIP poll colector" application that handles different polls with a number of different options to be voted for in each poll. So to make a registration from the application for each vote option and for each poll is really unpractical. That´s why I needed to now wheter it is possible to include wildcards in SIP URIS and / or is any work done on the issue. Again thanks a lot, jose -------------------------------------------- Jose Soler Lucas, M.Sc.Telecom.E. PhD Student Networks Competence Area Research Center COM (Communications, Optics and Materials) Technical University of Denmark Building 343, DK 2800 Kgs. Lyngby, Denmark. Phone: +45 45 25 38 08 (direct) Fax: +45 45 93 65 81 E-mail: jsoler@com.dtu.dk Web: http://www.com.dtu.dk/staff/jso/ ---- Cellular: +45 22 27 48 22 -------------------------------------------- -----Original Message----- From: Rajarshi Chakraborty [mailto:rajarshi_chakraborty@hotmail.com] Sent: 19. juni 2003 16:38 To: jsoler@com.dtu.dk; sipping@ietf.org Subject: Re: [Sipping] How to Register multiple users with a single REGISTER message This is very interesting Jose. But the first thing that comes to my mind is the security concern. What if some illegitimate user (someone who has not subscribed to the SIP services offered) creates a user name for itself that matches that "common pattern"? There may be few other issues. regards, Rajarshi Rajarshi Chakraborty B-196, IIT Campus, Kharagpur, West Bengal, India PIN-721302 ----Original Message Follows---- From: José Soler Lucas To: "'sipping@ietf.org'" Subject: [Sipping] How to Register multiple users with a single REGISTER message Date: Thu, 19 Jun 2003 10:52:43 +0200 Hi, Lets see if you can help me with the following issue: Suposse there is a need to register a series of n users, with SIP URI of the form SIP:(whatever)@hostname, so that (whatever) contains [common pattern] for all the usser adresses to be registered. Furthermore, all the users will have the same REGISTER´s Contact header. Is it possible to use regular expressions in a SIP URI? This would allow for this case to specify a SIP URI in the TO Header field of the REGISTER, using regular expressions, that apply to an adress like: SIP:*[common patern]*@hostname? In such a way, if a registrar can handle this kind of REGISTER messages, the registration would be single and it wouldn´t need to be updated for every new user with the [common pattern] to be added. Well, thanks a lot in advance. Best regards, josé -------------------------------------------- José Soler Lucas, M.Sc.Telecom.E. PhD Student Networks Competence Area Research Center COM (Communications, Optics and Materials) Technical University of Denmark Building 343, DK 2800 Kgs. Lyngby, Denmark. Phone: +45 45 25 38 08 (direct) Fax: +45 45 93 65 81 E-mail: jsoler@com.dtu.dk Web: http://www.com.dtu.dk/staff/jso/ ---- Cellular: +45 22 27 48 22 -------------------------------------------- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _________________________________________________________________ Wedding blues? Need help? http://www.msn.co.in/Matrimony/ _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 19 11:12:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24194 for ; Thu, 19 Jun 2003 11:12:29 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JFC0o26231 for sipping-archive@odin.ietf.org; Thu, 19 Jun 2003 11: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 19T14y-0006p0-Q9 for sipping-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 11:12: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 LAA24165 for ; Thu, 19 Jun 2003 11:11:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T12h-0005VT-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 11:09:39 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19T12g-0005VQ-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 11:09:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T14x-0006o3-7h; Thu, 19 Jun 2003 11:11:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T14F-0006i3-9A for sipping@optimus.ietf.org; Thu, 19 Jun 2003 11:11: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 LAA24147 for ; Thu, 19 Jun 2003 11:11:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T11v-0005V3-00 for sipping@ietf.org; Thu, 19 Jun 2003 11:08:51 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19T11u-0005Uh-00 for sipping@ietf.org; Thu, 19 Jun 2003 11:08:51 -0400 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 h5JFAcwm028193; Thu, 19 Jun 2003 08:10:38 -0700 (PDT) Received: from mhammer-w2k02.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 AEK29685; Thu, 19 Jun 2003 08:10:37 -0700 (PDT) Message-Id: <4.3.2.7.2.20030619102056.00b2cf40@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 19 Jun 2003 11:10:36 -0400 To: "Guido Gybels" From: Michael Hammer Subject: Re: [Sipping] Re: Perspective of a deaf person. Was: Text support in SIPphones Cc: , , In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_5488892==_.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: , --=====================_5488892==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Guido, There is an expression that someone can hear, but doesn't listen. Please understand what I have said: 1) Interactive text capability in the network is a requirement. As you've pointed out, it is needed for enabling voice to text interactivity and vice versa, and may be desirable for text-text communications by some parties. 2) Terminal characteristics should be suited to the users needs and desires, and that may be market driven. Would you mandate that a blind person with no hands be required to buy a terminal with a screen and keyboard for 400 quid? In many situations, hands-free and vision-free mobile communications is a requirement. Terminals should not be burdened with unnecessary requirements and cost in those situations. 3) I respect your preferences in modes of communications, please respect mine. Demanding that chocolate be an option is fine, demanding that vanilla be prohibited is not. More below. At 09:05 AM 6/19/2003 +0100, Guido Gybels wrote: >Michael, > >[snip] > ><presence information than simply the fact that I am responding.>> > >You've missed the point! It is NOT about presence. It is about CONTENT and >the ability to interact with that content as it is being generated. That >is the nature of voice conversations. And if you have to use text rather >than voice because you are deaf, you will want the equivalent experience. >Presence will not solve it. There are multiple modes of expressing oneself, including "body language". Presence is another means of expression. So it is "content" too. The advancement of this mode should not be construed as a detriment to the one mode that has your attention most. ><good system. A 20 second delay seems extremely slow. Imagine if someone >told you email was simply not fast enough because he needed to get >responses in less than 24 hours and that was not happening.>> > >You've missed the point again: email is NOT interactive. It is store and >forward. People use email as one of the modalities they have to their >disposal. As they use IM. The kind of buffered experience of IM is simply >not able to replace the immediate and interactive nature of voice >conversations and therefore IM cannot be the text equivalent of spoken >conversations for deaf and hard of hearing people. And I hope I do not >have to repeat the problem of relay services? You are missing my point. The analogy was judging the capabilities of a system based on a poorly performing system. I have found IM to be highly interactive, less than a second. But, I accept that you prefer another means, and have no problem supporting your desires so long as it does not mean altering mine. [snip] ><> > >Oh come on, if anything got stomped on it was our genuine demand for >making interactive texting a default part of mainstream technology. Let's >not fudge the issue here: for political reasons, some people in here don't >want to support that, probably in order to further other agendas. How can you say this when I am supporting making the mode of communication you are asking for in the network a mainstream requirement? >What annoys me is that the result of that political discussion will be >that the exclusion of deaf and hard of hearing people in our Information >Society increases and the barriers they face become bigger. Cynically, the >hearing people that will be responsible for it will not be the ones that >suffer as result of that. Let's not obfuscate things here: we all know >very well that unless you have the "MUST" in that document, we will not >meet the objective of having mainstream support for this and we will go >back to the present situation of non-available, expensive and >non-interoperable "special" needs equipment. I also support your desired capability in terminals where it is appropriate. But, I think having a blanket MUST should be considered very carefully. I'm optimistic that a series of requirements that allocates the MUSTs, SHOULDs, and MAYs appropriately to devices types could be found. ><interacting, I would like more evidence that hearing users would prefer >this over IM. I appreciate the ability to hear. I think the crux is that >if I really needed to get the interactivity that you speak of, I would >make a phone call.>> > >That's kind of a rude thing to say to someone who is DEAF and who cannot >use voice. Why? If I use voice and you use text and there is a relay between the two, how would you know and why would you care what means to communicate I choose to use? Re-read the sentence. I did not demand that you use a particular mode of communication that didn't suit you. If it is rude to do so, then what does that say about what you are requesting here? [snip] ><of users of their system, which by its nature was solely hearing oriented >to begin with.>> > >So, you are in effect stating that they were right in ignoring the needs >of deaf and hard of hearing people, who after all had been able to use >textphones for quite a long time before mobile went mainstream?? And that >we should continue to do so? The first sentence was pointing out the fact that voice+mobility was the killer application that drove the development of the mobile networks to begin with. You conveniently left off my second sentence in which I answered your above questions to the negative, meaning that the needs of the deaf and hard of hearing should not be ignored. [snip] ><asneeded.>> > >It is not just a terminal issue. To be able to do the above, the network >will have to support it to begin with. Here, is where we agree. It is a network issue for sure. But, I still think as a general rule that terminals should be adaptable to the needs of the user that buys the terminal. Mike >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 > > > >************************************************************************ >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 --=====================_5488892==_.ALT Content-Type: text/html; charset="us-ascii" Guido,

There is an expression that someone can hear, but doesn't listen.  Please understand what I have said:

1) Interactive text capability in the network is a requirement.  As you've pointed out, it is needed for enabling voice to text interactivity and vice versa, and may be desirable for text-text communications by some parties.

2) Terminal characteristics should be suited to the users needs and desires, and that may be market driven.  Would you mandate that a blind person with no hands be required to buy a terminal with a screen and keyboard for 400 quid?  In many situations, hands-free and vision-free mobile communications is a requirement.  Terminals should not be burdened with unnecessary requirements and cost in those situations.

3) I respect your preferences in modes of communications, please respect mine.  Demanding that chocolate be an option is fine, demanding that vanilla be prohibited is not.

More below.

At 09:05 AM 6/19/2003 +0100, Guido Gybels wrote:
Michael,

[snip]

<<But lurking in there is a requirement for more expressive presence  information than simply the fact that I am responding.>>

You've missed the point! It is NOT about presence. It is about CONTENT and the ability to interact with that content as it is being generated. That is the nature of voice conversations. And if you have to use text rather than voice because you are deaf, you will want the equivalent experience. Presence will not solve it.

There are multiple modes of expressing oneself, including "body language".  Presence is another means of expression.  So it is "content" too.  The advancement of this mode should not be construed as a detriment to the one mode that has your attention most.


<<I'm wondering if my view of IM is colored by the use of a very good  system.  A 20 second delay seems extremely slow.  Imagine if someone told  you email was simply not fast enough because he needed to get responses in less than 24 hours and that was not happening.>>

You've missed the point again: email is NOT interactive. It is store and forward. People use email as one of the modalities they have to their disposal. As they use IM. The kind of buffered experience of IM is simply not able to replace the immediate and interactive nature of voice conversations and therefore IM cannot be the text equivalent of spoken conversations for deaf and hard of hearing people. And I hope I do not have to repeat the problem of relay services?

You are missing my point.  The analogy was judging the capabilities of a system based on a poorly performing system.  I have found IM to be highly interactive, less than a second.  But, I accept that you prefer another means, and have no problem supporting your desires so long as it does not mean altering mine.

[snip]

<<This is where my opinion diverged, then got stomped on.>>

Oh come on, if anything got stomped on it was our genuine demand for making interactive texting a default part of mainstream technology. Let's not fudge the issue here: for political reasons, some people in here don't want to support that, probably in order to further other agendas.

How can you say this when I am supporting making the mode of communication you are asking for in the network a mainstream requirement?

What annoys me is that the result of that political discussion will be that the exclusion of deaf and hard of hearing people in our Information Society increases and the barriers they face become bigger. Cynically, the hearing people that will be responsible for it will not be the ones that suffer as result of that. Let's not obfuscate things here: we all know very well that unless you have the "MUST" in that document, we will not meet the objective of having mainstream support for this and we will go back to the present situation of non-available, expensive and non-interoperable "special" needs equipment.

I also support your desired capability in terminals where it is appropriate.  But, I think having a blanket MUST should be considered very carefully.  I'm optimistic that a series of requirements that allocates the MUSTs, SHOULDs, and MAYs appropriately to devices types could be found.


<<While I do think there is a need to have a non-voice means of interacting, I would like more evidence that hearing users would prefer this over IM.  I appreciate the ability to hear.  I think the crux is that if I really needed to get the interactivity that you speak of, I would make a phone call.>>

That's kind of a rude thing to say to someone who is DEAF and who cannot use voice.

Why?  If I use voice and you use text and there is a relay between the two, how would you know and why would you care what means to communicate I choose to use?  Re-read the sentence.  I did not demand that you use a particular mode of communication that didn't suit you.  If it is rude to do so, then what does that say about what you are requesting here?

[snip]

<<The mobile phone carriers were simply meeting the needs of the majority of users of their system, which by its nature was solely hearing oriented to begin with.>>

So, you are in effect stating that they were right in ignoring the needs of deaf and hard of hearing people, who after all had been able to use textphones for quite a long time before mobile went mainstream?? And that we should continue to do so?

The first sentence was pointing out the fact that voice+mobility was the killer application that drove the development of the mobile networks to begin with.  You conveniently left off my second sentence in which I answered your above questions to the negative, meaning that the needs of the deaf and hard of hearing should not be ignored.

[snip]

<<Hopefully, this feature could be downloaded, plugged-in, and used asneeded.>>

It is not just a terminal issue. To be able to do the above, the network will have to support it to begin with.

Here, is where we agree.  It is a network issue for sure.  But, I still think as a general rule that terminals should be adaptable to the needs of the user that buys the terminal.

Mike


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



************************************************************************
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
--=====================_5488892==_.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 Jun 19 12:58:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00991 for ; Thu, 19 Jun 2003 12:58:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JGw3222220 for sipping-archive@odin.ietf.org; Thu, 19 Jun 2003 12: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 19T2jb-0005mJ-AP for sipping-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 12:58: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 MAA00981 for ; Thu, 19 Jun 2003 12:57:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T2hI-00079T-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 12:55:40 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19T2hI-00079Q-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 12:55:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T2jZ-0005lQ-39; Thu, 19 Jun 2003 12: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 19T2jA-0005l7-Kj for sipping@optimus.ietf.org; Thu, 19 Jun 2003 12:57: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 MAA00966 for ; Thu, 19 Jun 2003 12:57:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T2gs-000794-00 for sipping@ietf.org; Thu, 19 Jun 2003 12:55:14 -0400 Received: from [217.158.120.227] (helo=rnidmail.rnid.org.uk) by ietf-mx with esmtp (Exim 4.12) id 19T2gr-00078d-00 for sipping@ietf.org; Thu, 19 Jun 2003 12:55:13 -0400 Received: from rnid.org.uk (unverified) by rnidmail.rnid.org.uk (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Thu, 19 Jun 2003 17:55:23 +0100 Received: from RNIDMAIL-Message_Server by rnid.org.uk with Novell_GroupWise; Thu, 19 Jun 2003 17:54:39 +0100 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Thu, 19 Jun 2003 17:54:08 +0100 From: "Guido Gybels" To: Cc: , , Subject: Re: [Sipping] Re: Perspective of a deaf person. Was: Textsupport in SIPphones Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA00991 Michael, <> Strange, I was thinking of saying something similar! Actually, in Dutch I would probably make it: "Wat baten kaars en bril als den uil niet zien en wil". Nevertheless, I don't think this kind of back and forward name calling is going to get us anywhere. I do think that in your haste to comment on what I say, you have ignored the things I have said: <<1) Interactive text capability in the network is a requirement. As you've pointed out, it is needed for enabling voice to text interactivity and vice versa, and may be desirable for text-text communications by some parties.>> So, that's agreed then. <<2) Terminal characteristics should be suited to the users needs and desires, and that may be market driven. Would you mandate that a blind person with no hands be required to buy a terminal with a screen and keyboard for 400 quid? In many situations, hands-free and vision-free mobile communications is a requirement. Terminals should not be burdened with unnecessary requirements and cost in those situations.>> You are twisting my words, I don't know if it is deliberately or not, but it is quite frustrating. Unless you can quote me stating the above, I suggest you refrain from putting words in my mouth that I haven't said. I have now stated on numerous occasions that I'm willing to provide for well defined categories of devices. Nevertheless, just like an average mobile phones these days comes with a small screen and display and with SMS as a standard built-in, and just like that is the consequence of both the design of the GSM standard (in which SMS is key), I think interactive text should be the default, not the exception. That has nothing to do with the device costing 400 quid. Your suggestion that what we are asking for in terms of basic requirements, i.e. built-in support for RFC2793, at least for every phone that has a display and a screen or that is intended to have one connected to it, woulkd imply building expensive handsets is intellectually dishonest. You should know probably better than anyone else that is a travesty of the truth. In reality we are asking for something so light-weight that you won't even notice. And yes, we are asking that that be the rule, not the exception. I think that is a reasonable request. Maybe this is a good illustration that *you* have not been listening very carefully to what I have been saying. <<3) I respect your preferences in modes of communications, please respect mine. Demanding that chocolate be an option is fine, demanding that vanilla be prohibited is not.>> Another exmaple. I have never stated that different people might not have different preferences. Please quote me to prove the contrary or stop putting things in my mouth that I didn't say. Furthermore, it's slanderous to suggest I asked for something to be prohibited. I have only stated that to fulfil the requirement for interactive texting, IM is not the acceptable solution for deaf and hard of hearing people. Never have I said that therefore IM should be prohibited. <> I don't see hos this disables the argument that you cannot substitute content by presence. Redundancy of information through different channels, including facial expressions is a fact of life that I can't recall having denied. The assumption however that presence will substitute for interactive content is one that I do not support and for which I have seen no scientific evidence to support such assumption. <> Are you? I'm saying that you cannot make it mainstream unless it is a basic provision supported broadly in the network and the terminals. Saying on one hand that you support this as "mainstream" while on the other hand refusing to make it the rule rather than the exception is, IMHO, a contradictio in terminis. <> I have already agreed to that and I have repeatedly suggested that we can formulate a solid and robust description to qualify the must. I'm open to suggestions for wording and I'm sure we can find a decent compromise. I guess therefore the proposal is to make it a well qualified MUST. I believe that if you support the concept of mainstreaming the support for this, you will see the vailidty of my reasoning. And I'd like to respectfully point out that the current situation on the market supports my point that you cannot achieve mainstream unless the wording in the document is of MUST caliber. Let's be open about this Michael, you know very well that there is a world of difference between a qualified MUST and a MAY or even a SHOULD. <> <> <> Deaf staff here immediately took offense after reading your statement. I guess they see it as you saying to them: I have the choice to revert to voice to get that level of interactivity. Remember please that they have no such choice, therefore if you prevent them from using interactive text instead because it is lifted out of the mainstream and therefore not available as voice would be, they have in effect been discriminated against. <> But the point is that what you said was certainly perceived as telling deaf people they should use a mode that didn't suit them. And they took offense. I am not saying you meant to cause offense, but I certainly say that was the result. <> That is certainly correct. As it was correct when I said that text had become a major driving force as well, even with all the limitations it has in its current form. Is it therefore unreasonable to assume that when those limitations get removed and the user experience gets better, it has the potential to become even bigger, in mainstream?? <> Depends to what extend. I certainly don't want to see deaf and hard of hearing people condemned again to buying expensive and non-standard extensions to equipment in order for them to use it. Emails have been robust, and the debate has been heated so far. But now it is time to look at the facts, including the seriously disadvantaging current situation. And I call to all of you to commit yourselves to actually doing something about it. If you do this right, you'll bring dramatic change to the lives of millions of people. Let's please take this chance. Even if it requires thinking out of the box. 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 ************************************************************************ 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 Thu Jun 19 13:25:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02481 for ; Thu, 19 Jun 2003 13:25:34 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JHP8u28906 for sipping-archive@odin.ietf.org; Thu, 19 Jun 2003 13:25:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T39o-0007W9-HC for sipping-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 13:25:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02436 for ; Thu, 19 Jun 2003 13:25:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T37V-0007Vr-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 13:22:45 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19T37U-0007Vo-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 13:22:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T39i-0007VG-3W; Thu, 19 Jun 2003 13:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T38j-0007UE-U4 for sipping@optimus.ietf.org; Thu, 19 Jun 2003 13:24: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 NAA02422 for ; Thu, 19 Jun 2003 13:23:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T36R-0007VW-00 for sipping@ietf.org; Thu, 19 Jun 2003 13:21:39 -0400 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by ietf-mx with esmtp (Exim 4.12) id 19T36Q-0007VN-00 for sipping@ietf.org; Thu, 19 Jun 2003 13:21:38 -0400 Received: from dgismtp05.wcomnet.com ([166.38.58.88]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HGQ0004BO7K5W@firewall.wcom.com> for sipping@ietf.org; Thu, 19 Jun 2003 17:21:20 +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 <0HGQ00C01O7KVC@dgismtp05.wcomnet.com>; Thu, 19 Jun 2003 17:21:20 +0000 (GMT) Received: from hsinnreich2 ([166.50.104.25]) by dgismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HGQ00C1GO7IQ1@dgismtp05.wcomnet.com>; Thu, 19 Jun 2003 17:21:20 +0000 (GMT) Date: Thu, 19 Jun 2003 12:21:17 -0500 From: Henry Sinnreich Subject: RE: [Sipping] Re: Perspective of a deaf person. Was: Textsupport in SIPphones In-reply-to: To: "'Guido Gybels'" , mhammer@cisco.com Cc: sipping@ietf.org, jon.peterson@neustar.biz, A.vWijk@viataal.nl Message-id: <000001c33687$327f3c30$196832a6@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 May I suggest we take this discussion off the main list? This thread has now very little to do with engineering the interactive text and voice protocols and data to work across the Internet. (Please keep me however in the loop in this discussion) It also appears this topic, besides being emotionally charged, needs some technical clarifications, as what is really meant by "interactive text". Unless it is support for RFC 2793, and RFC 2793 is already included in the draft -01 on SIP Telephony Devices just submitted to the IETF. Thanks, Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of Guido Gybels > Sent: Thursday, June 19, 2003 11:54 AM > To: mhammer@cisco.com > Cc: sipping@ietf.org; jon.peterson@neustar.biz; A.vWijk@viataal.nl > Subject: Re: [Sipping] Re: Perspective of a deaf person. Was: > Textsupport in SIPphones > > > Michael, > > < listen. Please understand what I have said:>> > > Strange, I was thinking of saying something similar! > Actually, in Dutch I would probably make it: "Wat baten kaars > en bril als den uil niet zien en wil". Nevertheless, I don't > think this kind of back and forward name calling is going to > get us anywhere. I do think that in your haste to comment on > what I say, you have ignored the things I have said: > > <<1) Interactive text capability in the network is a > requirement. As you've pointed out, it is needed for > enabling voice to text interactivity and vice > versa, and may be desirable for text-text communications by > some parties.>> > > So, that's agreed then. > > <<2) Terminal characteristics should be suited to the users > needs and desires, and that may be market driven. Would you > mandate that a blind > person with no hands be required to buy a terminal with a > screen and keyboard for 400 quid? In many situations, > hands-free and vision-free > mobile communications is a requirement. Terminals should not > be burdened with unnecessary requirements and cost in those > situations.>> > > You are twisting my words, I don't know if it is deliberately > or not, but it is quite frustrating. Unless you can quote me > stating the above, I suggest you refrain from putting words > in my mouth that I haven't said. I have now stated on > numerous occasions that I'm willing to provide for well > defined categories of devices. Nevertheless, just like an > average mobile phones these days comes with a small screen > and display and with SMS as a standard built-in, and just > like that is the consequence of both the design of the GSM > standard (in which SMS is key), I think interactive text > should be the default, not the exception. That has nothing to > do with the device costing 400 quid. Your suggestion that > what we are asking for in terms of basic requirements, i.e. > built-in support for RFC2793, at least for every phone that > has a display and a screen or that is intended to have one > connected to it, woulkd imply building expensive handsets is > intellectually dishonest. You should know probably better > than anyone else that is a travesty of the truth. In reality > we are asking for something so light-weight that you won't > even notice. And yes, we are asking that that be the rule, > not the exception. I think that is a reasonable request. > Maybe this is a good illustration that *you* have not been > listening very carefully to what I have been saying. > > <<3) I respect your preferences in modes of communications, > please respect mine. Demanding that chocolate be an option > is fine, demanding that vanilla be prohibited is not.>> > > Another exmaple. I have never stated that different people > might not have different preferences. Please quote me to > prove the contrary or stop putting things in my mouth that I > didn't say. Furthermore, it's slanderous to suggest I asked > for something to be prohibited. I have only stated that to > fulfil the requirement for interactive texting, IM is not the > acceptable solution for deaf and hard of hearing people. > Never have I said that therefore IM should be prohibited. > > < "body language". Presence is another means of expression. > So it is "content" > too. The advancement of this mode should not be construed as > a detriment to the one mode that has your attention most.>> > > I don't see hos this disables the argument that you cannot > substitute content by presence. Redundancy of information > through different channels, including facial expressions is a > fact of life that I can't recall having denied. The > assumption however that presence will substitute for > interactive content is one that I do not support and for > which I have seen no scientific evidence to support such assumption. > > < of communication you are asking for in the network a > mainstream requirement?>> > > Are you? I'm saying that you cannot make it mainstream unless > it is a basic provision supported broadly in the network and > the terminals. Saying on one hand that you support this as > "mainstream" while on the other hand refusing to make it the > rule rather than the exception is, IMHO, a contradictio in terminis. > > < it is appropriate. But, I think having a blanket MUST should > be considered very > carefully.>> > > I have already agreed to that and I have repeatedly suggested > that we can formulate a solid and robust description to > qualify the must. I'm open to suggestions for wording and I'm > sure we can find a decent compromise. I guess therefore the > proposal is to make it a well qualified MUST. I believe that > if you support the concept of mainstreaming the support for > this, you will see the vailidty of my reasoning. And I'd like > to respectfully point out that the current situation on the > market supports my point that you cannot achieve mainstream > unless the wording in the document is of MUST caliber. Let's > be open about this Michael, you know very well that there is > a world of difference between a qualified MUST and a MAY or > even a SHOULD. > > < crux is that if I really needed to get the interactivity that > you speak of, I would make a phone call.>> > > < DEAF and who cannot use voice.>> > > <> > > Deaf staff here immediately took offense after reading your > statement. I guess they see it as you saying to them: I have > the choice to revert to voice to get that level of > interactivity. Remember please that they have no such choice, > therefore if you prevent them from using interactive text > instead because it is lifted out of the mainstream and > therefore not available as voice would be, they have in > effect been discriminated against. > > < particular mode of communication that didn't suit you.>> > > But the point is that what you said was certainly perceived > as telling deaf people they should use a mode that didn't > suit them. And they took offense. I am not saying you meant > to cause offense, but I certainly say that was the result. > > < voice+mobility was the killer application that drove the > development of the mobile networks to > begin with.>> > > That is certainly correct. As it was correct when I said that > text had become a major driving force as well, even with all > the limitations it has in its current form. Is it therefore > unreasonable to assume that when those limitations get > removed and the user experience gets better, it has the > potential to become even bigger, in mainstream?? > > < But, I still think as a general rule that terminals should > be adaptable to the needs oft he user that buys the terminal.>> > > Depends to what extend. I certainly don't want to see deaf > and hard of hearing people condemned again to buying > expensive and non-standard extensions to equipment in order > for them to use it. > > Emails have been robust, and the debate has been heated so > far. But now it is time to look at the facts, including the > seriously disadvantaging current situation. And I call to all > of you to commit yourselves to actually doing something about > it. If you do this right, you'll bring dramatic change to the > lives of millions of people. Let's please take this chance. > Even if it requires thinking out of the box. > > 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 > > > > ************************************************************** > ********** > 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 > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 19 13:28:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02742 for ; Thu, 19 Jun 2003 13:28:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JHS3230203 for sipping-archive@odin.ietf.org; Thu, 19 Jun 2003 13: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 19T3Cd-0007r4-SR for sipping-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 13:28: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 NAA02698 for ; Thu, 19 Jun 2003 13:27:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T3AK-0007aL-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 13:25:40 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19T3AJ-0007aI-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 13:25:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3Cb-0007o4-SN; Thu, 19 Jun 2003 13:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3Bg-0007nS-L3 for sipping@optimus.ietf.org; Thu, 19 Jun 2003 13:27:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02645 for ; Thu, 19 Jun 2003 13:27:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T39N-0007Zk-00 for sipping@ietf.org; Thu, 19 Jun 2003 13:24:41 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19T39N-0007YH-00 for sipping@ietf.org; Thu, 19 Jun 2003 13:24:41 -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 h5JHQMFh010268; Thu, 19 Jun 2003 10:26:22 -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 AIH49306; Thu, 19 Jun 2003 10:20:13 -0700 (PDT) Date: Thu, 19 Jun 2003 10:27:34 -0700 Subject: Re: [Sipping] Call Waiting - who does the tone Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Rosen, Brian" , "Alan Hawrylyshen" , "Satish Bansal!" , To: "Dusan Mudric" From: Rohan Mahy In-Reply-To: <59A835EDCDDBEB46BC75402F4604D5520107AC73@elmer> Message-Id: <50AF53BB-A27B-11D7-8E0D-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 Dusan, Every SIP phone that I am aware of offers call waiting natively. It requires no cooperation on the part of any service provider, and no additional cost by either the end-user nor by any service provider. - Nobody has provided any compelling benefit to the end-user to do call waiting in the network - Nobody has provided any compelling benefit to the service provider to do call waiting in the network - Nobody has demonstrated that any SIP phones implement any of the additional weirdo mechanism that would be required to make network call waiting work as well as locally-implemented call waiting, Nor that there is any compelling economic reason for them to do so. thanks, -rohan On Tuesday, June 17, 2003, at 08:55 AM, Dusan Mudric wrote: > There is an existing SIP busy that can be used to offer multi-party > call waiting announcement service. Off-hook from terminating party > would be signaled with re-INVITE. > > Regards, > Dusan Mudric. > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Tuesday, June 17, 2003 11:07 AM > To: Dusan Mudric; Alan Hawrylyshen; Satish Bansal! > Cc: sipping@ietf.org > Subject: RE: [Sipping] Call Waiting - who does the tone > > If this was desirable, which I don't personally believe it is, > I don't think there exists a sip mechanism that would enable it. > Are you proposing we create one? > > Brian > -----Original Message----- > From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] > Sent: Tuesday, June 17, 2003 11:04 AM > To: Alan Hawrylyshen; Satish Bansal! > Cc: Rosen, Brian; sipping@ietf.org > Subject: RE: [Sipping] Call Waiting - who does the tone > > > Call Waiting service in the core of the network offers more flexible > solution to service providers. They can chose which media server to > use and > type of announcement message to play to the end user waiting on the > call. > This would be a part of service offering (in this particular example, > call > waiting) to a subscriber. In addition, it is UA independent. > > Regards, > Dusan Mudric. > Senior Sw Engineer > Leapstone Systems Inc. > > -----Original Message----- > From: Alan Hawrylyshen [mailto:alan@jasomi.com] > Sent: Saturday, June 14, 2003 5:28 PM > To: Satish Bansal! > Cc: Rosen, Brian; 'sipping@ietf.org' > Subject: Re: [Sipping] Call Waiting - who does the tone > > On Saturday, Jun 14, 2003, at 01:27 Canada/Mountain, Satish Bansal! > wrote: > > There could be two options. First as you said, a dump phone should > handle > call waiting. It would mean that we are making end nodes intelligent. > > Second option is that intelligence is in the network, the inbound > proxy > should be call statefull and should use 3pcc for playing tone & annc. > through a server to the party. > > 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 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). > > 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 maintain > and > deploy the 'core' portion of a SIP network infrastructure. > > I would agree w/ Brian on this; this could be appropriate for > inclusion in a > BCP document. > > De-lurking, > > Alan Hawrylyshen Jasomi Networks Inc. > sip:alan@jasomi.com mailto:alan@jasomi.com > http://www.jasomi.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 Jun 19 13:35:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03484 for ; Thu, 19 Jun 2003 13:35:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JHZ3832132 for sipping-archive@odin.ietf.org; Thu, 19 Jun 2003 13:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3JP-0008L5-Pv for sipping-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 13:35: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 NAA03414 for ; Thu, 19 Jun 2003 13:35:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T3H6-0007lu-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 13:32:40 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19T3H5-0007lp-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 13:32:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3JN-0008Je-M0; Thu, 19 Jun 2003 13:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3Iy-0008JH-DW for sipping@optimus.ietf.org; Thu, 19 Jun 2003 13:34: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 NAA03313 for ; Thu, 19 Jun 2003 13:34:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T3Gf-0007kG-00 for sipping@ietf.org; Thu, 19 Jun 2003 13:32:13 -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 19T3Ge-0007iC-00 for sipping@ietf.org; Thu, 19 Jun 2003 13:32:12 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 19 Jun 2003 10:32:02 -0800 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 h5JHY1IX001338; Thu, 19 Jun 2003 10:34:01 -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 AIH50355; Thu, 19 Jun 2003 10:27:52 -0700 (PDT) Date: Thu, 19 Jun 2003 10:35:13 -0700 Subject: Re: [Sipping] Call Waiting - who does the tone Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Rosen, Brian" , To: "Dusan Mudric" From: Rohan Mahy In-Reply-To: <59A835EDCDDBEB46BC75402F4604D5520107AC79@elmer> Message-Id: <623652B5-A27C-11D7-8E0D-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 Dusan, We have spent valuable list energy on this discussion. If you think your idea is superior to locally-initiated call waiting, please write an Internet-Draft rigorously describing the behavior you expect, the motivations and requirements, and an example flow with detailed example messages. Until then, let's please stop this discussion. thanks, -rohan mahy co-chair SIP and SIPPING On Wednesday, June 18, 2003, at 07:40 AM, Dusan Mudric wrote: > As mentioned "Terminating party UA-B can get a signal from media > server for the call from UA-C waiting for UA-B." Terminating party > UA-B can get call waiting signal from media on behalf on UA-C (proxy > connects media to UA-B) while session with UA-A is in progress. > > Calling party UA-C might experience a ringing or even more advanced > services, like announcement, music, ..., while it is waiting for UA-B > to finish the call. > > Regards, > Dusan Mudric. > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Tuesday, June 17, 2003 5:55 PM > To: Dusan Mudric > Cc: sipping@ietf.org > Subject: RE: [Sipping] Call Waiting - who does the tone > > Call waiting announcements traditionally are played to the called party > (call waiting tone). > > The calling party experiences ringing, and then either answer or > forwarding-no answer behavior. > > How does called party B know that C is waiting? That is the call > waiting > problem I first started this thread on. > > It's not a problem for call forward-no answer to allow a retry, with > announcements, if that's what you want, but it doesn't have much > to do with call waiting. > > Brian > >> -----Original Message----- >> From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] >> Sent: Tuesday, June 17, 2003 4:50 PM >> To: Rosen, Brian >> Cc: sipping@ietf.org >> Subject: RE: [Sipping] Call Waiting - who does the tone >> >> >> Call flow is very close. Originating UA-C can experience >> smoother events: ringing and than media stream with >> announcement. Terminating party UA-B can get a signal from >> media server for the call from UA-C waiting for UA-B. When >> terminating party UA-B is ready to accept the call (hung up >> with UA-A), proxy sends INVITE for the second session to the >> terminating UA-B, UA-B sends 200 OK, and proxy issues >> re-INVITE to originating party UA-C (assumption is UA-C is >> still waiting). Media stream is cutoff and original session >> with calling party is reestablished. >> Regards, >> Dusan Mudric. >> >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] >> Sent: Tuesday, June 17, 2003 3:55 PM >> To: Dusan Mudric >> Cc: sipping@ietf.org >> Subject: RE: [Sipping] Call Waiting - who does the tone >> >> Please look again. You don't get media for the 486. >> The transaction completes, and a new transaction starts >> with INVITE. The media flow occurs as a result of the >> INVITE. You will also note that you see 180 Ringing. >> >> What would you expect the user experience to be? >> Using this example, you would experience a call, >> two way audio, then the call would have to be cut off >> without warning, your phone would ring, and when you >> answered, you would hear a tone or announcement. >> I suppose that if you hung up from that "call", you >> could get another call, which would be your original >> call, resumed, which you could then hang up, and >> get yet another call which would be the waiting call. >> >> Also, for that to work at all, the original call, >> as well as the waiting call, have to arrive at your >> phone via 3PCC. One of the underlying assumptions >> about 3PCC is that the controller is the "other" >> participant for both end-participants. There are no >> systems I'm familiar with that do this. >> >> Dusan, I don't think there are any systems out there, or >> even contemplated, that would support call waiting implemented >> this way. I also don't think it's a good idea. >> >> I think we probably should keep call waiting a local >> function and not a network function. >> >> Brian >> >>> -----Original Message----- >>> From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] >>> Sent: Tuesday, June 17, 2003 2:13 PM >>> To: Rosen, Brian; Alan Hawrylyshen; Satish Bansal! >>> Cc: sipping@ietf.org >>> Subject: RE: [Sipping] Call Waiting - who does the tone >>> >>> >>> Media connection can be established on 486 busy. It would be >>> very similar call flow as in >>> draft-ietf-sipping-service-examples-04.txt, 2.7 Call >>> Forwarding - Busy. >>> >>> Btw, we should add this service description in the mentioned draft. >>> >>> Regards, >>> Dusan Mudric. >>> >>> -----Original Message----- >>> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] >>> Sent: Tuesday, June 17, 2003 1:04 PM >>> To: Dusan Mudric; Rosen, Brian; Alan Hawrylyshen; Satish Bansal! >>> Cc: sipping@ietf.org >>> Subject: RE: [Sipping] Call Waiting - who does the tone >>> >>> Hmmm, please explain. >>> >>> I don't think there is any "busy" (which is usually a 400 class >>> response to an INVITE) that creates a media connection. >>> Of course, usually call waiting is overlaid (mixed) with live audio, >>> but even as an independent media stream, you can't use 3PCC to cause >>> the called party to put his existing call on hold. You >> would have to >>> force both ends of the call to reroute to a mixer. A middle box >>> can't do that, and it isn't likely to work smoothly at all. >>> >>> Brian >>> >>> >>> >>>> -----Original Message----- >>>> From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] >>>> Sent: Tuesday, June 17, 2003 11:56 AM >>>> To: Rosen, Brian; Alan Hawrylyshen; Satish Bansal! >>>> Cc: sipping@ietf.org >>>> Subject: RE: [Sipping] Call Waiting - who does the tone >>>> >>>> >>>> There is an existing SIP busy that can be used to offer >>>> multi-party call waiting announcement service. Off-hook from >>>> terminating party would be signaled with re-INVITE. >>>> >>>> Regards, >>>> Dusan Mudric. >>>> >>>> -----Original Message----- >>>> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] >>>> Sent: Tuesday, June 17, 2003 11:07 AM >>>> To: Dusan Mudric; Alan Hawrylyshen; Satish Bansal! >>>> Cc: sipping@ietf.org >>>> Subject: RE: [Sipping] Call Waiting - who does the tone >>>> >>>> If this was desirable, which I don't personally believe it is, >>>> I don't think there exists a sip mechanism that would enable it. >>>> Are you proposing we create one? >>>> >>>> Brian >>>> -----Original Message----- >>>> From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] >>>> Sent: Tuesday, June 17, 2003 11:04 AM >>>> To: Alan Hawrylyshen; Satish Bansal! >>>> Cc: Rosen, Brian; sipping@ietf.org >>>> Subject: RE: [Sipping] Call Waiting - who does the tone >>>> >>>> >>>> Call Waiting service in the core of the network offers >> more flexible >>>> solution to service providers. They can chose which media >>>> server to use and >>>> type of announcement message to play to the end user waiting >>>> on the call. >>>> This would be a part of service offering (in this particular >>>> example, call >>>> waiting) to a subscriber. In addition, it is UA independent. >>>> >>>> Regards, >>>> Dusan Mudric. >>>> Senior Sw Engineer >>>> Leapstone Systems Inc. >>>> >>>> -----Original Message----- >>>> From: Alan Hawrylyshen [mailto:alan@jasomi.com] >>>> Sent: Saturday, June 14, 2003 5:28 PM >>>> To: Satish Bansal! >>>> Cc: Rosen, Brian; 'sipping@ietf.org' >>>> Subject: Re: [Sipping] Call Waiting - who does the tone >>>> >>>> On Saturday, Jun 14, 2003, at 01:27 Canada/Mountain, Satish >>>> Bansal! wrote: >>>> >>>> There could be two options. First as you said, a dump phone >>>> should handle >>>> call waiting. It would mean that we are making end nodes >>>> intelligent. >>>> >>>> Second option is that intelligence is in the network, the >>>> inbound proxy >>>> should be call statefull and should use 3pcc for playing >>> tone & annc. >>>> through a server to the party. >>>> >>>> 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 >>>> 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). >>>> >>>> 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 >>>> maintain and >>>> deploy the 'core' portion of a SIP network infrastructure. >>>> >>>> I would agree w/ Brian on this; this could be appropriate for >>>> inclusion in a >>>> BCP document. >>>> >>>> De-lurking, >>>> >>>> Alan Hawrylyshen Jasomi Networks Inc. >>>> sip:alan@jasomi.com mailto:alan@jasomi.com >>>> http://www.jasomi.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 Jun 19 13:48:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04374 for ; Thu, 19 Jun 2003 13:48:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JHm4d04657 for sipping-archive@odin.ietf.org; Thu, 19 Jun 2003 13:48:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3W0-0001Cq-Db for sipping-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 13:48: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 NAA04334 for ; Thu, 19 Jun 2003 13:48:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T3Th-0000CJ-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 13:45:41 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19T3Tg-0000CG-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 13:45:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3Vx-0001AS-EN; Thu, 19 Jun 2003 13: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 19T3VC-00016S-04 for sipping@optimus.ietf.org; Thu, 19 Jun 2003 13:47: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 NAA04317 for ; Thu, 19 Jun 2003 13:47:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T3St-0000Bw-00 for sipping@ietf.org; Thu, 19 Jun 2003 13:44:51 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19T3Sr-0000Bl-00 for sipping@ietf.org; Thu, 19 Jun 2003 13:44:50 -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 h5JHkYFh025125; Thu, 19 Jun 2003 10:46:34 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIH52128; Thu, 19 Jun 2003 10:40:25 -0700 (PDT) Date: Thu, 19 Jun 2003 10:47:46 -0700 Subject: Re: [Sipping] How to Register multiple users with a single REGIST ER message Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'Rajarshi Chakraborty'" , sipping@ietf.org To: =?ISO-8859-1?Q?Jos=E9_Soler_Lucas?= From: Rohan Mahy In-Reply-To: <0FAFFBDC8353D211B00A00104B0CDCBF01C9F7C9@comsrv.com.dtu.dk> Message-Id: <22BBA112-A27E-11D7-8E0D-0003938AF740@cisco.com> X-Mailer: Apple Mail (2.552) Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA04374 Hi Jose, What you are describing is a service which needs to be configured. You want _weather@domain.com to go to your application, so you configure your proxy to do this (possibly using regular expressions, CGI scripts, or the like). Many commercial proxies allow this. However I don't think you need to dynamically register this service, support user mobility of this service, or support multiple simultaneous contacts for the service. Those are the properties of an AOR that needs to be registered. Also, I'd like to point out that you could also name your service: sip:@weather.domain.com and add an entry in DNS which points weather.domain.com to your application server. then you don't even need the proxy to cooperate. thanks, -rohan On Thursday, June 19, 2003, at 07:58 AM, José Soler Lucas wrote: > Hi Rajarshi, > Thanks a lot for the response. > You are right: it represents a security problem for certain services. > Anyway > it will be the service itself the one registering such numbers...what > about > publicly available services that need no subscription? > > Just to consider some applicable case as an example: consider a sip > application server (AS) that offers a weather information service > through a > SIP proxy that proxies INVITE messages to the (AS) arriving to it with > the > following To SIP URI > > name_of_town_weather@domain.com > > If the application server has to register each town´s info address > into the > proxy it can be really unpractical. In the other hand, if it is > allowed to > register something like $\w.[_weather]@domain.com and the proxy ´s > registrars recognises it as a request for registration of whatever > contains > the common pattern [_weather] then the service is much simpler from the > communication point of view (ammount of messages). > > To mention the real case I am dealing with, the application I am > concerned > is with a "SIP poll colector" application that handles different polls > with > a number of different options to be voted for in each poll. So to make > a > registration from the application for each vote option and for each > poll is > really unpractical. That´s why I needed to now wheter it is possible to > include wildcards in SIP URIS and / or is any work done on the issue. > > Again thanks a lot, > > jose > -------------------------------------------- > Jose Soler Lucas, M.Sc.Telecom.E. > PhD Student > Networks Competence Area > Research Center COM (Communications, Optics and Materials) > Technical University of Denmark > Building 343, DK 2800 Kgs. Lyngby, Denmark. > Phone: +45 45 25 38 08 (direct) > Fax: +45 45 93 65 81 > E-mail: jsoler@com.dtu.dk > Web: http://www.com.dtu.dk/staff/jso/ > ---- > Cellular: +45 22 27 48 22 > -------------------------------------------- > > > > -----Original Message----- > From: Rajarshi Chakraborty [mailto:rajarshi_chakraborty@hotmail.com] > Sent: 19. juni 2003 16:38 > To: jsoler@com.dtu.dk; sipping@ietf.org > Subject: Re: [Sipping] How to Register multiple users with a single > REGISTER message > > > This is very interesting Jose. But the first thing that comes to my > mind is > the security concern. What if some illegitimate user (someone who has > not > subscribed to the SIP services offered) creates a user name for itself > that > matches that "common pattern"? There may be few other issues. > > regards, > Rajarshi > > Rajarshi Chakraborty > B-196, IIT Campus, > Kharagpur, > West Bengal, India > PIN-721302 > > > > > > ----Original Message Follows---- > From: José Soler Lucas > To: "'sipping@ietf.org'" > Subject: [Sipping] How to Register multiple users with a single > REGISTER > message > Date: Thu, 19 Jun 2003 10:52:43 +0200 > > > Hi, > > Lets see if you can help me with the following issue: > > Suposse there is a need to register a series of n users, with SIP URI > of the > form SIP:(whatever)@hostname, so that (whatever) contains [common > pattern] > for all the usser adresses to be registered. Furthermore, all the > users will > have the same REGISTER´s Contact header. > > Is it possible to use regular expressions in a SIP URI? This would > allow for > this case to specify a SIP URI in the TO Header field of the REGISTER, > using > regular expressions, that apply to an adress like: SIP:*[common > patern]*@hostname? > > In such a way, if a registrar can handle this kind of REGISTER > messages, the > registration would be single and it wouldn´t need to be updated for > every > new user with the [common pattern] to be added. > > Well, thanks a lot in advance. > Best regards, > > josé > -------------------------------------------- > José Soler Lucas, M.Sc.Telecom.E. > PhD Student > Networks Competence Area > Research Center COM (Communications, Optics and Materials) > Technical University of Denmark > Building 343, DK 2800 Kgs. Lyngby, Denmark. > Phone: +45 45 25 38 08 (direct) > Fax: +45 45 93 65 81 > E-mail: jsoler@com.dtu.dk > Web: http://www.com.dtu.dk/staff/jso/ > ---- > Cellular: +45 22 27 48 22 > -------------------------------------------- > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > > _________________________________________________________________ > Wedding blues? Need help? http://www.msn.co.in/Matrimony/ > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 19 14:14: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 OAA06655 for ; Thu, 19 Jun 2003 14:14:33 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JIE5612968 for sipping-archive@odin.ietf.org; Thu, 19 Jun 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 19T3vB-0003N4-He for sipping-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 14:14: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 OAA06549 for ; Thu, 19 Jun 2003 14:14:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T3ss-0000lG-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 14:11:42 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19T3sr-0000lD-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 14:11:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3v7-0003Lt-2F; Thu, 19 Jun 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 19T3uD-0003Jv-B7 for sipping@optimus.ietf.org; Thu, 19 Jun 2003 14:13: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 OAA06505 for ; Thu, 19 Jun 2003 14:13:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T3ru-0000kI-00 for sipping@ietf.org; Thu, 19 Jun 2003 14:10:42 -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 19T3rt-0000jy-00 for sipping@ietf.org; Thu, 19 Jun 2003 14:10:41 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 19 Jun 2003 11:10:27 -0800 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 h5JICLIX003566; Thu, 19 Jun 2003 11:12:21 -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 AIH55827; Thu, 19 Jun 2003 11:06:12 -0700 (PDT) Date: Thu, 19 Jun 2003 11:13:33 -0700 Subject: PLEASE STOP: Re: [Sipping] Re: Perspective of a deaf person. Was: Textsupport in SIPphones Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: , , , To: "Guido Gybels" From: Rohan Mahy In-Reply-To: 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 Guido, Mike, Jon, I am declaring this thread out of scope. Henry is working on a document with recommendations for building off-the-shelf SIP telephones, and implementation experience from the industry AS A NON-WG ITEM. His recommendations already include "requirements" such as support for the iLBC codec, and support for SIMPLE. He was asked by Guido and others to include T140 as well. Addition of T140 to the existing laundry list in this NON-WG DRAFT is certainly not a hardship to someone who would implement to it, and actually promotes more choice than less choice for the user. Henry has asked to have an adhoc meeting on the phone requirements document itself (did I mention yet that this is a NON WORKING GROUP draft), and I will announce the location of the adhoc at the beginning of the first SIPPING meeting in Vienna. If you have any questions, issues, or discussions about this topic, please take them off list immediately so that we can discuss Working Group issues. On a personal note, I am actually shocked and mildly offended that a hearing person would try to convince a deaf person that IM is better than character-by-character chat. Sometimes it is and sometimes it isn't. Each to his own. thanks, -rohan co-chair SIP and SIPPING On Thursday, June 19, 2003, at 09:54 AM, Guido Gybels wrote: > Michael, > > < Please understand what I have said:>> > > Strange, I was thinking of saying something similar! Actually, in > Dutch I would probably make it: "Wat baten kaars en bril als den uil > niet zien en wil". Nevertheless, I don't think this kind of back and > forward name calling is going to get us anywhere. I do think that in > your haste to comment on what I say, you have ignored the things I > have said: > > <<1) Interactive text capability in the network is a requirement. As > you've pointed out, it is needed for enabling voice to text > interactivity and vice > versa, and may be desirable for text-text communications by some > parties.>> > > So, that's agreed then. > > <<2) Terminal characteristics should be suited to the users needs and > desires, and that may be market driven. Would you mandate that a > blind > person with no hands be required to buy a terminal with a screen and > keyboard for 400 quid? In many situations, hands-free and vision-free > mobile communications is a requirement. Terminals should not be > burdened with unnecessary requirements and cost in those situations.>> > > You are twisting my words, I don't know if it is deliberately or not, > but it is quite frustrating. Unless you can quote me stating the > above, I suggest you refrain from putting words in my mouth that I > haven't said. I have now stated on numerous occasions that I'm willing > to provide for well defined categories of devices. Nevertheless, just > like an average mobile phones these days comes with a small screen and > display and with SMS as a standard built-in, and just like that is the > consequence of both the design of the GSM standard (in which SMS is > key), I think interactive text should be the default, not the > exception. That has nothing to do with the device costing 400 quid. > Your suggestion that what we are asking for in terms of basic > requirements, i.e. built-in support for RFC2793, at least for every > phone that has a display and a screen or that is intended to have one > connected to it, woulkd imply building expensive handsets is > intellectually dishonest. You should know probably better than anyone > else that is a travesty of the truth. In reality we are asking for > something so light-weight that you won't even notice. And yes, we are > asking that that be the rule, not the exception. I think that is a > reasonable request. Maybe this is a good illustration that *you* have > not been listening very carefully to what I have been saying. > > <<3) I respect your preferences in modes of communications, please > respect mine. Demanding that chocolate be an option is fine, > demanding that vanilla be prohibited is not.>> > > Another exmaple. I have never stated that different people might not > have different preferences. Please quote me to prove the contrary or > stop putting things in my mouth that I didn't say. Furthermore, it's > slanderous to suggest I asked for something to be prohibited. I have > only stated that to fulfil the requirement for interactive texting, IM > is not the acceptable solution for deaf and hard of hearing people. > Never have I said that therefore IM should be prohibited. > > < language". Presence is another means of expression. So it is > "content" > too. The advancement of this mode should not be construed as a > detriment to the one mode that has your attention most.>> > > I don't see hos this disables the argument that you cannot substitute > content by presence. Redundancy of information through different > channels, including facial expressions is a fact of life that I can't > recall having denied. The assumption however that presence will > substitute for interactive content is one that I do not support and > for which I have seen no scientific evidence to support such > assumption. > > < communication you are asking for in the network a mainstream > requirement?>> > > Are you? I'm saying that you cannot make it mainstream unless it is a > basic provision supported broadly in the network and the terminals. > Saying on one hand that you support this as "mainstream" while on the > other hand refusing to make it the rule rather than the exception is, > IMHO, a contradictio in terminis. > > < appropriate. But, I think having a blanket MUST should be considered > very > carefully.>> > > I have already agreed to that and I have repeatedly suggested that we > can formulate a solid and robust description to qualify the must. I'm > open to suggestions for wording and I'm sure we can find a decent > compromise. I guess therefore the proposal is to make it a well > qualified MUST. I believe that if you support the concept of > mainstreaming the support for this, you will see the vailidty of my > reasoning. And I'd like to respectfully point out that the current > situation on the market supports my point that you cannot achieve > mainstream unless the wording in the document is of MUST caliber. > Let's be open about this Michael, you know very well that there is a > world of difference between a qualified MUST and a MAY or even a > SHOULD. > > < if I really needed to get the interactivity that you speak of, I would > make a phone call.>> > > < who cannot use voice.>> > > <> > > Deaf staff here immediately took offense after reading your statement. > I guess they see it as you saying to them: I have the choice to revert > to voice to get that level of interactivity. Remember please that they > have no such choice, therefore if you prevent them from using > interactive text instead because it is lifted out of the mainstream > and therefore not available as voice would be, they have in effect > been discriminated against. > > < mode of communication that didn't suit you.>> > > But the point is that what you said was certainly perceived as telling > deaf people they should use a mode that didn't suit them. And they > took offense. I am not saying you meant to cause offense, but I > certainly say that was the result. > > < the killer application that drove the development of the mobile > networks to > begin with.>> > > That is certainly correct. As it was correct when I said that text had > become a major driving force as well, even with all the limitations it > has in its current form. Is it therefore unreasonable to assume that > when those limitations get removed and the user experience gets > better, it has the potential to become even bigger, in mainstream?? > > < still think as a general rule that terminals should be adaptable to > the needs oft > he user that buys the terminal.>> > > Depends to what extend. I certainly don't want to see deaf and hard of > hearing people condemned again to buying expensive and non-standard > extensions to equipment in order for them to use it. > > Emails have been robust, and the debate has been heated so far. But > now it is time to look at the facts, including the seriously > disadvantaging current situation. And I call to all of you to commit > yourselves to actually doing something about it. If you do this right, > you'll bring dramatic change to the lives of millions of people. Let's > please take this chance. Even if it requires thinking out of the box. > > 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 > > > > *********************************************************************** > * > 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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 19 14:29:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08235 for ; Thu, 19 Jun 2003 14:29:03 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JISZE19718 for sipping-archive@odin.ietf.org; Thu, 19 Jun 2003 14:28:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T49D-00057s-FU for sipping-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 14:28: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 OAA08210 for ; Thu, 19 Jun 2003 14:28:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T48g-0004rQ-2O; Thu, 19 Jun 2003 14: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 19T48D-0004r8-Tl for sipping@optimus.ietf.org; Thu, 19 Jun 2003 14:27: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 OAA08158 for ; Thu, 19 Jun 2003 14:27:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T45u-0001AP-00 for sipping@ietf.org; Thu, 19 Jun 2003 14:25:10 -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 19T45t-0001A4-00 for sipping@ietf.org; Thu, 19 Jun 2003 14:25:10 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 19 Jun 2003 11:28:51 -0800 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 h5JIQwIX016655; Thu, 19 Jun 2003 11:26:59 -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 AIH57920; Thu, 19 Jun 2003 11:20:49 -0700 (PDT) Date: Thu, 19 Jun 2003 11:28:09 -0700 Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'sipping@ietf.org'" To: "Rajarshi Chakraborty" From: Rohan Mahy In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: [Sip] Using SUBSCRIBE/NOTIFY in mobility Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk 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, First of all, please do not cross post to more than one sip* list. I have trimmed this reply to SIPPING only. Second, I cannot find the draft you are referring to. It is unusual to ask questions about an expired draft unless it has been discussed recently on the list. Perhaps you are referring to the following? If so, it is truly ancient and you should avert your eyes, lest you turn into a pillar of salt. Seriously, the draft below was incorporated into RFC2543 which was later replaced by RFC3261. http://www.softarmor.com/sipwg/drafts/morgue/draft-schulzrinne-sip- register-00.txt Finally, from your questions, you may be interested in the registration package which was approved by the IESG and is awaiting editing to become an RFC: http://www.ietf.org/internet-drafts/draft-ietf-sipping-reg-event-00.txt thanks, -rohan On Friday, June 13, 2003, at 07:27 AM, Rajarshi Chakraborty wrote: > Hi, > > This mail is kind of a follow-up to the earlier mail where I posted a > couple of doubts regarding registration models in > draft-schulzrinne-register-01. In the second design called "Outbound > proxy intercept", could we not use SUBSCRIBE and NOTIFY between the > mobile user agent and the outbound proxy server in the foriegn domain > to indicate the former's departure from that domain into some other > domain? And this would be followed by the local registrar unbinding > the temporary canonical ID of the mobile host just upon receiving the > NOTIFY, if it is co-located with the local proxy or the latter could > send a de-register to the registrar if not co-located with it. > According to this design the mobile host doesn't register with the > foreign proxy/registrar. Hence I think SUBSCRIBE/NOTIFY would be of > good use. The local proxy would SUBSCRIBE to the mobile user agent, > and just before the latter departs it sends a NOTIFY back to the local > proxy. Is this feasible? > > regards, > Rajarshi > > > > Rajarshi Chakraborty > B-196, IIT Campus, > Kharagpur, > West Bengal, India > PIN-721302 > > _________________________________________________________________ > Dress up your desktop! Get the best wallpapers. > http://server1.msn.co.in/msnchannels/Entertainment/wallpaperhome.asp > Just click here! > > _______________________________________________ > 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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 19 18:26:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23550 for ; Thu, 19 Jun 2003 18:26:33 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JMQ7j23288 for sipping-archive@odin.ietf.org; Thu, 19 Jun 2003 18:26:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T7r5-00063X-CD for sipping-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 18:26: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 SAA23520 for ; Thu, 19 Jun 2003 18:26:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T7ol-0004HU-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 18:23:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19T7ok-0004HR-00 for sipping-web-archive@ietf.org; Thu, 19 Jun 2003 18:23:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T7r0-00062K-6u; Thu, 19 Jun 2003 18:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T7qE-00061d-1G for sipping@optimus.ietf.org; Thu, 19 Jun 2003 18:25: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 SAA23477 for ; Thu, 19 Jun 2003 18:25:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T7nu-0004Gz-00 for sipping@ietf.org; Thu, 19 Jun 2003 18:22:50 -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 19T7nt-0004Gw-00 for sipping@ietf.org; Thu, 19 Jun 2003 18:22:49 -0400 Received: from localhost (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h5JMP8VU003951; Thu, 19 Jun 2003 17:25:08 -0500 Subject: RE: [Sipping] Text support in SIP phones From: Dean Willis To: Guido Gybels Cc: sipping@ietf.org, jon.peterson@neustar.biz, cboulton@ubiquity.net, A.vWijk@viataal.nl In-Reply-To: References: Content-Type: text/plain Message-Id: <1056061507.3521.20.camel@bdsl.greycouncil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 19 Jun 2003 17:25:08 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'm willing to accept a user requirement for real-time texting on display phones. Of course, we should also have a neural input pad capable of I/O for quadraplegics and people with their hands full (can you imagine a real-time-text interface via a sip-and-puff controller? Ouch! People would hyperventilate saying "hello"!) but that's probably a little further off ;-(. Maybe ten more years . . . In the meantime. . . Question: Have we analyzed the problems of the loss-characteristics of RFC2793 vs. the overhead of near-real-time character by character IMs? One of my first projects studying computer enabled human communication was a text conference package. The first incarnation of it used UDP transmission without a reliability layer (a really lightweight cousin of RTP). On two machines on the same segment, it worked pretty well. But across campus, with a halfdozen or so routers that were always running at full capacity in between, it really sucked. Instead of looking "like this does" it was more like "ie thdos" due to packet losses. We switched to TCP with disabled Nagle algorithm (allowing multiple outstanding small packets) and found it much more satisfying to use. The slight loss of timing acuity was handily made up for by the increased alphabetic acuity. Given that the "3G" phone I'm using has comparable loss characteristics to that old campus net, I can't imagine RTP text (even with redundant coding) giving satisfactory performance. Consequently, I'm thinking that we might be better off defining a model of instant messaging (perhaps with MSRP) that preserves as much temporal acuity as possible, while still having the realibility and network-problem-tolerance of IM. The nifty thing is that such a model could have the advantage of interworking directly with conventiional IMs applications -- it would simply be a user-settable option. One could then trade off between smooth real-time and reduced network overhead as appropriate for a given conversation, or even dynamically within a conversation. Of course, that woul make this a SIMPLEproblem. not a SIPPING problem, but we have to start somewhere. --Dean _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Jun 20 00:37: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 AAA03932 for ; Fri, 20 Jun 2003 00:37:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5K4b6M14125 for sipping-archive@odin.ietf.org; Fri, 20 Jun 2003 00:37:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TDe6-0003fk-79 for sipping-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 00:37: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 AAA03910 for ; Fri, 20 Jun 2003 00:37:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TDbm-0006mV-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 00:34:42 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TDbl-0006mR-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 00:34:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TDe1-0003eV-SX; Fri, 20 Jun 2003 00: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 19TDdQ-0003Se-9s for sipping@optimus.ietf.org; Fri, 20 Jun 2003 00:36: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 AAA03887 for ; Fri, 20 Jun 2003 00:36:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TDb6-0006ly-00 for sipping@ietf.org; Fri, 20 Jun 2003 00:34:00 -0400 Received: from law12-f20.law12.hotmail.com ([64.4.19.20] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19TDb6-0006ll-00 for sipping@ietf.org; Fri, 20 Jun 2003 00:34:00 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 19 Jun 2003 21:35:51 -0700 Received: from 193.220.224.9 by lw12fd.law12.hotmail.msn.com with HTTP; Fri, 20 Jun 2003 04:35:51 GMT X-Originating-IP: [193.220.224.9] X-Originating-Email: [rajarshi_chakraborty@hotmail.com] From: "Rajarshi Chakraborty" To: rohan@cisco.com Cc: sipping@ietf.org Subject: Re: [Sipping] Re: [Sip] Using SUBSCRIBE/NOTIFY in mobility Date: Fri, 20 Jun 2003 04:35:51 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Jun 2003 04:35:51.0697 (UTC) FILETIME=[6DF94810:01C336E5] Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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, Yes its draft-schulzrinne-sip-register-01 that I was talking about. My bad, I gave the incorrect name. But I understand that due to the draft being outdated and rather having been incorporated into a couple of RFCs no more question from it would be entertained. And thanks a lot for the pointer to the other draft. Rajarshi Chakraborty B-196, IIT Campus, Kharagpur, West Bengal, India PIN-721302 ----Original Message Follows---- From: Rohan Mahy To: "Rajarshi Chakraborty" CC: "'sipping@ietf.org'" Subject: [Sipping] Re: [Sip] Using SUBSCRIBE/NOTIFY in mobility Date: Thu, 19 Jun 2003 11:28:09 -0700 Hi, First of all, please do not cross post to more than one sip* list. I have trimmed this reply to SIPPING only. Second, I cannot find the draft you are referring to. It is unusual to ask questions about an expired draft unless it has been discussed recently on the list. Perhaps you are referring to the following? If so, it is truly ancient and you should avert your eyes, lest you turn into a pillar of salt. Seriously, the draft below was incorporated into RFC2543 which was later replaced by RFC3261. http://www.softarmor.com/sipwg/drafts/morgue/draft-schulzrinne-sip- register-00.txt Finally, from your questions, you may be interested in the registration package which was approved by the IESG and is awaiting editing to become an RFC: http://www.ietf.org/internet-drafts/draft-ietf-sipping-reg-event-00.txt thanks, -rohan On Friday, June 13, 2003, at 07:27 AM, Rajarshi Chakraborty wrote: >Hi, > >This mail is kind of a follow-up to the earlier mail where I posted a >couple of doubts regarding registration models in >draft-schulzrinne-register-01. In the second design called "Outbound proxy >intercept", could we not use SUBSCRIBE and NOTIFY between the mobile user >agent and the outbound proxy server in the foriegn domain to indicate the >former's departure from that domain into some other domain? And this would >be followed by the local registrar unbinding the temporary canonical ID of >the mobile host just upon receiving the NOTIFY, if it is co-located with >the local proxy or the latter could send a de-register to the registrar if >not co-located with it. According to this design the mobile host doesn't >register with the foreign proxy/registrar. Hence I think SUBSCRIBE/NOTIFY >would be of good use. The local proxy would SUBSCRIBE to the mobile user >agent, and just before the latter departs it sends a NOTIFY back to the >local proxy. Is this feasible? > >regards, >Rajarshi > > > >Rajarshi Chakraborty >B-196, IIT Campus, >Kharagpur, >West Bengal, India >PIN-721302 > >_________________________________________________________________ >Dress up your desktop! Get the best wallpapers. >http://server1.msn.co.in/msnchannels/Entertainment/wallpaperhome.asp Just >click here! > >_______________________________________________ >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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _________________________________________________________________ Food fit for Kings! Now available online. http://server1.msn.co.in/features/general/itc/index.asp _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 20 04:24:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21229 for ; Fri, 20 Jun 2003 04:24:34 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5K8O6t07330 for sipping-archive@odin.ietf.org; Fri, 20 Jun 2003 04:24:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19THBm-0001u9-Lv for sipping-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 04:24:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21214 for ; Fri, 20 Jun 2003 04:24:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TH9T-0000a8-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 04:21:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TH9S-0000a5-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 04:21:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19THBh-0001tE-U0; Fri, 20 Jun 2003 04: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 19THBZ-0001sm-74 for sipping@optimus.ietf.org; Fri, 20 Jun 2003 04:23: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 EAA21210 for ; Fri, 20 Jun 2003 04:23:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TH9F-0000a2-00 for sipping@ietf.org; Fri, 20 Jun 2003 04:21:29 -0400 Received: from [210.21.224.29] (helo=szsmtp.utstar.com.cn) by ietf-mx with esmtp (Exim 4.12) id 19TH9D-0000Zk-00 for sipping@ietf.org; Fri, 20 Jun 2003 04:21:27 -0400 Received: from sznsszqweng ([172.19.16.43]) by szsmtp.utstar.com.cn (8.11.1/8.11.1) with SMTP id h5K7rE128401; Fri, 20 Jun 2003 15:53:34 +0800 Message-ID: <013101c33701$0e944980$2b1013ac@cn.utstar.com> From: "weng zhiqiang" To: "Dusan Mudric" , "Rosen, Brian" Cc: References: <59A835EDCDDBEB46BC75402F4604D5520107AC79@elmer> Subject: Re: [Sipping] Call Waiting - who does the tone Date: Fri, 20 Jun 2003 15:52:56 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id EAA21229 hi : what do you suppose the call wait signal to be ? a pure sip message or an announcement from media server ? if it is an announcment , have we had to hold UA-A cause UA-B may not support audio mix ? BR JohnyWeng ----- Original Message ----- From: "Dusan Mudric" To: "Rosen, Brian" Cc: Sent: Wednesday, June 18, 2003 10:40 PM Subject: RE: [Sipping] Call Waiting - who does the tone > As mentioned "Terminating party UA-B can get a signal from media server for the call from UA-C waiting for UA-B." Terminating party UA-B can get call waiting signal from media on behalf on UA-C (proxy connects media to UA-B) while session with UA-A is in progress. > > Calling party UA-C might experience a ringing or even more advanced services, like announcement, music, ..., while it is waiting for UA-B to finish the call. > > Regards, > Dusan Mudric. > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Tuesday, June 17, 2003 5:55 PM > To: Dusan Mudric > Cc: sipping@ietf.org > Subject: RE: [Sipping] Call Waiting - who does the tone > > Call waiting announcements traditionally are played to the called party > (call waiting tone). > > The calling party experiences ringing, and then either answer or > forwarding-no answer behavior. > > How does called party B know that C is waiting? That is the call waiting > problem I first started this thread on. > > It's not a problem for call forward-no answer to allow a retry, with > announcements, if that's what you want, but it doesn't have much > to do with call waiting. > > Brian > > > -----Original Message----- > > From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] > > Sent: Tuesday, June 17, 2003 4:50 PM > > To: Rosen, Brian > > Cc: sipping@ietf.org > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > > > Call flow is very close. Originating UA-C can experience > > smoother events: ringing and than media stream with > > announcement. Terminating party UA-B can get a signal from > > media server for the call from UA-C waiting for UA-B. When > > terminating party UA-B is ready to accept the call (hung up > > with UA-A), proxy sends INVITE for the second session to the > > terminating UA-B, UA-B sends 200 OK, and proxy issues > > re-INVITE to originating party UA-C (assumption is UA-C is > > still waiting). Media stream is cutoff and original session > > with calling party is reestablished. > > Regards, > > Dusan Mudric. > > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Tuesday, June 17, 2003 3:55 PM > > To: Dusan Mudric > > Cc: sipping@ietf.org > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > Please look again. You don't get media for the 486. > > The transaction completes, and a new transaction starts > > with INVITE. The media flow occurs as a result of the > > INVITE. You will also note that you see 180 Ringing. > > > > What would you expect the user experience to be? > > Using this example, you would experience a call, > > two way audio, then the call would have to be cut off > > without warning, your phone would ring, and when you > > answered, you would hear a tone or announcement. > > I suppose that if you hung up from that "call", you > > could get another call, which would be your original > > call, resumed, which you could then hang up, and > > get yet another call which would be the waiting call. > > > > Also, for that to work at all, the original call, > > as well as the waiting call, have to arrive at your > > phone via 3PCC. One of the underlying assumptions > > about 3PCC is that the controller is the "other" > > participant for both end-participants. There are no > > systems I'm familiar with that do this. > > > > Dusan, I don't think there are any systems out there, or > > even contemplated, that would support call waiting implemented > > this way. I also don't think it's a good idea. > > > > I think we probably should keep call waiting a local > > function and not a network function. > > > > Brian > > > > > -----Original Message----- > > > From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] > > > Sent: Tuesday, June 17, 2003 2:13 PM > > > To: Rosen, Brian; Alan Hawrylyshen; Satish Bansal! > > > Cc: sipping@ietf.org > > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > > > > > > Media connection can be established on 486 busy. It would be > > > very similar call flow as in > > > draft-ietf-sipping-service-examples-04.txt, 2.7 Call > > > Forwarding - Busy. > > > > > > Btw, we should add this service description in the mentioned draft. > > > > > > Regards, > > > Dusan Mudric. > > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: Tuesday, June 17, 2003 1:04 PM > > > To: Dusan Mudric; Rosen, Brian; Alan Hawrylyshen; Satish Bansal! > > > Cc: sipping@ietf.org > > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > > > Hmmm, please explain. > > > > > > I don't think there is any "busy" (which is usually a 400 class > > > response to an INVITE) that creates a media connection. > > > Of course, usually call waiting is overlaid (mixed) with live audio, > > > but even as an independent media stream, you can't use 3PCC to cause > > > the called party to put his existing call on hold. You > > would have to > > > force both ends of the call to reroute to a mixer. A middle box > > > can't do that, and it isn't likely to work smoothly at all. > > > > > > Brian > > > > > > > > > > > > > -----Original Message----- > > > > From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] > > > > Sent: Tuesday, June 17, 2003 11:56 AM > > > > To: Rosen, Brian; Alan Hawrylyshen; Satish Bansal! > > > > Cc: sipping@ietf.org > > > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > > > > > > > > > There is an existing SIP busy that can be used to offer > > > > multi-party call waiting announcement service. Off-hook from > > > > terminating party would be signaled with re-INVITE. > > > > > > > > Regards, > > > > Dusan Mudric. > > > > > > > > -----Original Message----- > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > Sent: Tuesday, June 17, 2003 11:07 AM > > > > To: Dusan Mudric; Alan Hawrylyshen; Satish Bansal! > > > > Cc: sipping@ietf.org > > > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > > > > > If this was desirable, which I don't personally believe it is, > > > > I don't think there exists a sip mechanism that would enable it. > > > > Are you proposing we create one? > > > > > > > > Brian > > > > -----Original Message----- > > > > From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] > > > > Sent: Tuesday, June 17, 2003 11:04 AM > > > > To: Alan Hawrylyshen; Satish Bansal! > > > > Cc: Rosen, Brian; sipping@ietf.org > > > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > > > > > > > > > Call Waiting service in the core of the network offers > > more flexible > > > > solution to service providers. They can chose which media > > > > server to use and > > > > type of announcement message to play to the end user waiting > > > > on the call. > > > > This would be a part of service offering (in this particular > > > > example, call > > > > waiting) to a subscriber. In addition, it is UA independent. > > > > > > > > Regards, > > > > Dusan Mudric. > > > > Senior Sw Engineer > > > > Leapstone Systems Inc. > > > > > > > > -----Original Message----- > > > > From: Alan Hawrylyshen [mailto:alan@jasomi.com] > > > > Sent: Saturday, June 14, 2003 5:28 PM > > > > To: Satish Bansal! > > > > Cc: Rosen, Brian; 'sipping@ietf.org' > > > > Subject: Re: [Sipping] Call Waiting - who does the tone > > > > > > > > On Saturday, Jun 14, 2003, at 01:27 Canada/Mountain, Satish > > > > Bansal! wrote: > > > > > > > > There could be two options. First as you said, a dump phone > > > > should handle > > > > call waiting. It would mean that we are making end nodes > > > > intelligent. > > > > > > > > Second option is that intelligence is in the network, the > > > > inbound proxy > > > > should be call statefull and should use 3pcc for playing > > > tone & annc. > > > > through a server to the party. > > > > > > > > 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 > > > > 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). > > > > > > > > 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 > > > > maintain and > > > > deploy the 'core' portion of a SIP network infrastructure. > > > > > > > > I would agree w/ Brian on this; this could be appropriate for > > > > inclusion in a > > > > BCP document. > > > > > > > > De-lurking, > > > > > > > > Alan Hawrylyshen Jasomi Networks Inc. > > > > sip:alan@jasomi.com mailto:alan@jasomi.com > > > > http://www.jasomi.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 ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÒŠšbž šŠX§‚X¬¶m¦Ïÿÿ 0×øžµÿè®æj)fjåŠËbú?²*iŠx†+%ŠËb±ú+4Ez÷¥¢™žžÚ¶š¦™bq«b¢zHƒÔ±ë"§ø¦¦W¦z{h®Ïܳ÷(–雉¯Þvç讫ž²Ø¨žÊ'rêëz{lŠ•,zÈ©þ'­ú+ú+ìz÷¥¢™žžÛ(}Ê+y" From exim@www1.ietf.org Fri Jun 20 07:35:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26408 for ; Fri, 20 Jun 2003 07:35:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KBZ6318317 for sipping-archive@odin.ietf.org; Fri, 20 Jun 2003 07:35:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TKAc-0004lM-AA for sipping-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 07:35: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 HAA26296 for ; Fri, 20 Jun 2003 07:35:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TK8G-0001gT-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 07:32:40 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TK8G-0001gQ-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 07:32:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TKAY-0004jB-Hc; Fri, 20 Jun 2003 07: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 19TKAL-0004iQ-4Q for sipping@optimus.ietf.org; Fri, 20 Jun 2003 07:34:49 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26234; Fri, 20 Jun 2003 07:34:47 -0400 (EDT) Message-Id: <200306201134.HAA26234@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sipping@ietf.org, mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 20 Jun 2003 07:34:47 -0400 Subject: [Sipping] I-D ACTION:draft-camarillo-mmusic-alt-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 : The Alternative Semantics for the Session Description Protocol Grouping Framework Author(s) : G. Camarillo, J. Rosenberg Filename : draft-camarillo-mmusic-alt-01.txt Pages : 10 Date : 2003-6-19 This document defines the alternative (ALT) semantics for the SDP grouping framework. The ALT semantics allow offering alternative transport addresses to establish a particular media stream. This is useful in scenarios that involve IPv4 and IPv6 and/or network address translators. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-camarillo-mmusic-alt-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-camarillo-mmusic-alt-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-camarillo-mmusic-alt-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-6-19154258.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-camarillo-mmusic-alt-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-camarillo-mmusic-alt-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-19154258.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 Fri Jun 20 08:49:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04379 for ; Fri, 20 Jun 2003 08:49:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KCn7f08477 for sipping-archive@odin.ietf.org; Fri, 20 Jun 2003 08:49:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TLKF-0002Ce-2U for sipping-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 08:49: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 IAA04342 for ; Fri, 20 Jun 2003 08:49:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TLHt-0003gT-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 08:46:41 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TLHs-0003gQ-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 08:46:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TLK9-0002B2-64; Fri, 20 Jun 2003 08: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 19TLJi-0002AZ-5D for sipping@optimus.ietf.org; Fri, 20 Jun 2003 08:48: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 IAA04302 for ; Fri, 20 Jun 2003 08:48:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TLHM-0003fp-00 for sipping@ietf.org; Fri, 20 Jun 2003 08:46:08 -0400 Received: from [204.42.169.163] (helo=elmer.LEAPSTONE.COM) by ietf-mx with esmtp (Exim 4.12) id 19TLHL-0003fX-00 for sipping@ietf.org; Fri, 20 Jun 2003 08:46:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] Call Waiting - who does the tone Date: Fri, 20 Jun 2003 08:48:40 -0400 Message-ID: <59A835EDCDDBEB46BC75402F4604D5520107AC8C@elmer> Thread-Topic: [Sipping] Call Waiting - who does the tone Thread-Index: AcM3ATgZslIVk906Rn2WdnPKc6Ns1AAKIj7A From: "Dusan Mudric" To: "weng zhiqiang" , "Rosen, Brian" Cc: Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA04379 Call waiting signal would be an announcement from a media server. Some UA's support audio mix. If not, proxy can put UA-A on hold while letting a media server play a short message to UA-B. Regards, Dusan Mudric. -----Original Message----- From: weng zhiqiang [mailto:zqweng@utstar.com] Sent: Friday, June 20, 2003 3:53 AM To: Dusan Mudric; Rosen, Brian Cc: sipping@ietf.org Subject: Re: [Sipping] Call Waiting - who does the tone hi : what do you suppose the call wait signal to be ? a pure sip message or an announcement from media server ? if it is an announcment , have we had to hold UA-A cause UA-B may not support audio mix ? BR JohnyWeng ----- Original Message ----- From: "Dusan Mudric" To: "Rosen, Brian" Cc: Sent: Wednesday, June 18, 2003 10:40 PM Subject: RE: [Sipping] Call Waiting - who does the tone > As mentioned "Terminating party UA-B can get a signal from media server for the call from UA-C waiting for UA-B." Terminating party UA-B can get call waiting signal from media on behalf on UA-C (proxy connects media to UA-B) while session with UA-A is in progress. > > Calling party UA-C might experience a ringing or even more advanced services, like announcement, music, ..., while it is waiting for UA-B to finish the call. > > Regards, > Dusan Mudric. > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Tuesday, June 17, 2003 5:55 PM > To: Dusan Mudric > Cc: sipping@ietf.org > Subject: RE: [Sipping] Call Waiting - who does the tone > > Call waiting announcements traditionally are played to the called party > (call waiting tone). > > The calling party experiences ringing, and then either answer or > forwarding-no answer behavior. > > How does called party B know that C is waiting? That is the call waiting > problem I first started this thread on. > > It's not a problem for call forward-no answer to allow a retry, with > announcements, if that's what you want, but it doesn't have much > to do with call waiting. > > Brian > > > -----Original Message----- > > From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] > > Sent: Tuesday, June 17, 2003 4:50 PM > > To: Rosen, Brian > > Cc: sipping@ietf.org > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > > > Call flow is very close. Originating UA-C can experience > > smoother events: ringing and than media stream with > > announcement. Terminating party UA-B can get a signal from > > media server for the call from UA-C waiting for UA-B. When > > terminating party UA-B is ready to accept the call (hung up > > with UA-A), proxy sends INVITE for the second session to the > > terminating UA-B, UA-B sends 200 OK, and proxy issues > > re-INVITE to originating party UA-C (assumption is UA-C is > > still waiting). Media stream is cutoff and original session > > with calling party is reestablished. > > Regards, > > Dusan Mudric. > > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Tuesday, June 17, 2003 3:55 PM > > To: Dusan Mudric > > Cc: sipping@ietf.org > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > Please look again. You don't get media for the 486. > > The transaction completes, and a new transaction starts > > with INVITE. The media flow occurs as a result of the > > INVITE. You will also note that you see 180 Ringing. > > > > What would you expect the user experience to be? > > Using this example, you would experience a call, > > two way audio, then the call would have to be cut off > > without warning, your phone would ring, and when you > > answered, you would hear a tone or announcement. > > I suppose that if you hung up from that "call", you > > could get another call, which would be your original > > call, resumed, which you could then hang up, and > > get yet another call which would be the waiting call. > > > > Also, for that to work at all, the original call, > > as well as the waiting call, have to arrive at your > > phone via 3PCC. One of the underlying assumptions > > about 3PCC is that the controller is the "other" > > participant for both end-participants. There are no > > systems I'm familiar with that do this. > > > > Dusan, I don't think there are any systems out there, or > > even contemplated, that would support call waiting implemented > > this way. I also don't think it's a good idea. > > > > I think we probably should keep call waiting a local > > function and not a network function. > > > > Brian > > > > > -----Original Message----- > > > From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] > > > Sent: Tuesday, June 17, 2003 2:13 PM > > > To: Rosen, Brian; Alan Hawrylyshen; Satish Bansal! > > > Cc: sipping@ietf.org > > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > > > > > > Media connection can be established on 486 busy. It would be > > > very similar call flow as in > > > draft-ietf-sipping-service-examples-04.txt, 2.7 Call > > > Forwarding - Busy. > > > > > > Btw, we should add this service description in the mentioned draft. > > > > > > Regards, > > > Dusan Mudric. > > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: Tuesday, June 17, 2003 1:04 PM > > > To: Dusan Mudric; Rosen, Brian; Alan Hawrylyshen; Satish Bansal! > > > Cc: sipping@ietf.org > > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > > > Hmmm, please explain. > > > > > > I don't think there is any "busy" (which is usually a 400 class > > > response to an INVITE) that creates a media connection. > > > Of course, usually call waiting is overlaid (mixed) with live audio, > > > but even as an independent media stream, you can't use 3PCC to cause > > > the called party to put his existing call on hold. You > > would have to > > > force both ends of the call to reroute to a mixer. A middle box > > > can't do that, and it isn't likely to work smoothly at all. > > > > > > Brian > > > > > > > > > > > > > -----Original Message----- > > > > From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] > > > > Sent: Tuesday, June 17, 2003 11:56 AM > > > > To: Rosen, Brian; Alan Hawrylyshen; Satish Bansal! > > > > Cc: sipping@ietf.org > > > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > > > > > > > > > There is an existing SIP busy that can be used to offer > > > > multi-party call waiting announcement service. Off-hook from > > > > terminating party would be signaled with re-INVITE. > > > > > > > > Regards, > > > > Dusan Mudric. > > > > > > > > -----Original Message----- > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > Sent: Tuesday, June 17, 2003 11:07 AM > > > > To: Dusan Mudric; Alan Hawrylyshen; Satish Bansal! > > > > Cc: sipping@ietf.org > > > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > > > > > If this was desirable, which I don't personally believe it is, > > > > I don't think there exists a sip mechanism that would enable it. > > > > Are you proposing we create one? > > > > > > > > Brian > > > > -----Original Message----- > > > > From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] > > > > Sent: Tuesday, June 17, 2003 11:04 AM > > > > To: Alan Hawrylyshen; Satish Bansal! > > > > Cc: Rosen, Brian; sipping@ietf.org > > > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > > > > > > > > > Call Waiting service in the core of the network offers > > more flexible > > > > solution to service providers. They can chose which media > > > > server to use and > > > > type of announcement message to play to the end user waiting > > > > on the call. > > > > This would be a part of service offering (in this particular > > > > example, call > > > > waiting) to a subscriber. In addition, it is UA independent. > > > > > > > > Regards, > > > > Dusan Mudric. > > > > Senior Sw Engineer > > > > Leapstone Systems Inc. > > > > > > > > -----Original Message----- > > > > From: Alan Hawrylyshen [mailto:alan@jasomi.com] > > > > Sent: Saturday, June 14, 2003 5:28 PM > > > > To: Satish Bansal! > > > > Cc: Rosen, Brian; 'sipping@ietf.org' > > > > Subject: Re: [Sipping] Call Waiting - who does the tone > > > > > > > > On Saturday, Jun 14, 2003, at 01:27 Canada/Mountain, Satish > > > > Bansal! wrote: > > > > > > > > There could be two options. First as you said, a dump phone > > > > should handle > > > > call waiting. It would mean that we are making end nodes > > > > intelligent. > > > > > > > > Second option is that intelligence is in the network, the > > > > inbound proxy > > > > should be call statefull and should use 3pcc for playing > > > tone & annc. > > > > through a server to the party. > > > > > > > > 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 > > > > 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). > > > > > > > > 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 > > > > maintain and > > > > deploy the 'core' portion of a SIP network infrastructure. > > > > > > > > I would agree w/ Brian on this; this could be appropriate for > > > > inclusion in a > > > > BCP document. > > > > > > > > De-lurking, > > > > > > > > Alan Hawrylyshen Jasomi Networks Inc. > > > > sip:alan@jasomi.com mailto:alan@jasomi.com > > > > http://www.jasomi.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 Jun 20 09:47: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 JAA06088 for ; Fri, 20 Jun 2003 09:47:33 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KDl6t22950 for sipping-archive@odin.ietf.org; Fri, 20 Jun 2003 09:47:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TMEM-0005y3-4S for sipping-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 09:47:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06062 for ; Fri, 20 Jun 2003 09:47:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TMEK-00043k-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 09:47:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TMEJ-00043h-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 09: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 19TMEI-0005ww-9u; Fri, 20 Jun 2003 09: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 19TME9-0005w7-Ed for sipping@optimus.ietf.org; Fri, 20 Jun 2003 09:46: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 JAA06050 for ; Fri, 20 Jun 2003 09:46:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TME7-00043M-00 for sipping@ietf.org; Fri, 20 Jun 2003 09:46:51 -0400 Received: from pmesmtp01.wcom.com ([199.249.20.1]) by ietf-mx with esmtp (Exim 4.12) id 19TME7-000435-00 for sipping@ietf.org; Fri, 20 Jun 2003 09:46:51 -0400 Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HGS00JJG8QCJD@firewall.wcom.com> for sipping@ietf.org; Fri, 20 Jun 2003 13:42:12 +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 <0HGS00K018QBNH@dgismtp01.wcomnet.com>; Fri, 20 Jun 2003 13:42:12 +0000 (GMT) Received: from hsinnreich2 ([166.50.104.69]) by dgismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HGS00K2F8Q8EX@dgismtp01.wcomnet.com>; Fri, 20 Jun 2003 13:42:11 +0000 (GMT) Date: Fri, 20 Jun 2003 08:42:08 -0500 From: Henry Sinnreich Subject: RE: [Sipping] Call Waiting - who does the tone In-reply-to: <59A835EDCDDBEB46BC75402F4604D5520107AC8C@elmer> To: "'Dusan Mudric'" , "'weng zhiqiang'" , "'Rosen, Brian'" Cc: sipping@ietf.org Message-id: <000001c33731$bf460c70$6a01a8c0@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 Dusan, I have followed your mail on this with some astonishment, and now the latest: > Call waiting signal would be an announcement from a media > server. Some UA's support audio mix. If not, proxy can put > UA-A on hold while letting a media server play a short > message to UA-B. Can't the phone just generate a local beep? Or do you propose a $M project to generate the beep from a media server in the network? :-) Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of Dusan Mudric > Sent: Friday, June 20, 2003 7:49 AM > To: weng zhiqiang; Rosen, Brian > Cc: sipping@ietf.org > Subject: RE: [Sipping] Call Waiting - who does the tone > > > Call waiting signal would be an announcement from a media > server. Some UA's support audio mix. If not, proxy can put > UA-A on hold while letting a media server play a short > message to UA-B. > > Regards, > Dusan Mudric. > > -----Original Message----- > From: weng zhiqiang [mailto:zqweng@utstar.com] > Sent: Friday, June 20, 2003 3:53 AM > To: Dusan Mudric; Rosen, Brian > Cc: sipping@ietf.org > Subject: Re: [Sipping] Call Waiting - who does the tone > > hi : > what do you suppose the call wait signal to be ? > a pure sip message or an announcement from media server ? > if it is an announcment , have we had to hold UA-A cause > UA-B may not support audio mix ? > > BR > JohnyWeng > > ----- Original Message ----- > From: "Dusan Mudric" > To: "Rosen, Brian" > Cc: > Sent: Wednesday, June 18, 2003 10:40 PM > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > As mentioned "Terminating party UA-B can get a signal from media > > server for the call from UA-C waiting for UA-B." Terminating party > > UA-B can get call waiting signal from media on behalf on > UA-C (proxy > > connects media to UA-B) while session with UA-A is in progress. > > > > Calling party UA-C might experience a ringing or even more advanced > > services, like announcement, music, ..., while it is > waiting for UA-B > > to finish the call. > > > > Regards, > > Dusan Mudric. > > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Tuesday, June 17, 2003 5:55 PM > > To: Dusan Mudric > > Cc: sipping@ietf.org > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > Call waiting announcements traditionally are played to the called > > party (call waiting tone). > > > > The calling party experiences ringing, and then either answer or > > forwarding-no answer behavior. > > > > How does called party B know that C is waiting? That is the call > > waiting problem I first started this thread on. > > > > It's not a problem for call forward-no answer to allow a > retry, with > > announcements, if that's what you want, but it doesn't have > much to do > > with call waiting. > > > > Brian > > > > > -----Original Message----- > > > From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] > > > Sent: Tuesday, June 17, 2003 4:50 PM > > > To: Rosen, Brian > > > Cc: sipping@ietf.org > > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > > > > > > Call flow is very close. Originating UA-C can experience > > > smoother events: ringing and than media stream with > > > announcement. Terminating party UA-B can get a signal from > > > media server for the call from UA-C waiting for UA-B. When > > > terminating party UA-B is ready to accept the call (hung up > > > with UA-A), proxy sends INVITE for the second session to the > > > terminating UA-B, UA-B sends 200 OK, and proxy issues > > > re-INVITE to originating party UA-C (assumption is UA-C is > > > still waiting). Media stream is cutoff and original session > > > with calling party is reestablished. > > > Regards, > > > Dusan Mudric. > > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: Tuesday, June 17, 2003 3:55 PM > > > To: Dusan Mudric > > > Cc: sipping@ietf.org > > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > > > Please look again. You don't get media for the 486. > > > The transaction completes, and a new transaction starts > with INVITE. > > > The media flow occurs as a result of the INVITE. You > will also note > > > that you see 180 Ringing. > > > > > > What would you expect the user experience to be? > > > Using this example, you would experience a call, > > > two way audio, then the call would have to be cut off > > > without warning, your phone would ring, and when you > > > answered, you would hear a tone or announcement. > > > I suppose that if you hung up from that "call", you > > > could get another call, which would be your original > > > call, resumed, which you could then hang up, and > > > get yet another call which would be the waiting call. > > > > > > Also, for that to work at all, the original call, > > > as well as the waiting call, have to arrive at your > > > phone via 3PCC. One of the underlying assumptions > > > about 3PCC is that the controller is the "other" participant for > > > both end-participants. There are no systems I'm familiar > with that > > > do this. > > > > > > Dusan, I don't think there are any systems out there, or even > > > contemplated, that would support call waiting implemented > this way. > > > I also don't think it's a good idea. > > > > > > I think we probably should keep call waiting a local function and > > > not a network function. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] > > > > Sent: Tuesday, June 17, 2003 2:13 PM > > > > To: Rosen, Brian; Alan Hawrylyshen; Satish Bansal! > > > > Cc: sipping@ietf.org > > > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > > > > > > > > > Media connection can be established on 486 busy. It would be > > > > very similar call flow as in > > > > draft-ietf-sipping-service-examples-04.txt, 2.7 Call > > > > Forwarding - Busy. > > > > > > > > Btw, we should add this service description in the mentioned > > > > draft. > > > > > > > > Regards, > > > > Dusan Mudric. > > > > > > > > -----Original Message----- > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > Sent: Tuesday, June 17, 2003 1:04 PM > > > > To: Dusan Mudric; Rosen, Brian; Alan Hawrylyshen; Satish Bansal! > > > > Cc: sipping@ietf.org > > > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > > > > > Hmmm, please explain. > > > > > > > > I don't think there is any "busy" (which is usually a 400 class > > > > response to an INVITE) that creates a media connection. > Of course, > > > > usually call waiting is overlaid (mixed) with live > audio, but even > > > > as an independent media stream, you can't use 3PCC to cause the > > > > called party to put his existing call on hold. You > > > would have to > > > > force both ends of the call to reroute to a mixer. A > middle box > > > > can't do that, and it isn't likely to work smoothly at all. > > > > > > > > Brian > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] > > > > > Sent: Tuesday, June 17, 2003 11:56 AM > > > > > To: Rosen, Brian; Alan Hawrylyshen; Satish Bansal! > > > > > Cc: sipping@ietf.org > > > > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > > > > > > > > > > > > There is an existing SIP busy that can be used to offer > > > > > multi-party call waiting announcement service. Off-hook from > > > > > terminating party would be signaled with re-INVITE. > > > > > > > > > > Regards, > > > > > Dusan Mudric. > > > > > > > > > > -----Original Message----- > > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > > Sent: Tuesday, June 17, 2003 11:07 AM > > > > > To: Dusan Mudric; Alan Hawrylyshen; Satish Bansal! > > > > > Cc: sipping@ietf.org > > > > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > > > > > > > If this was desirable, which I don't personally believe it is, > > > > > I don't think there exists a sip mechanism that would > enable it. > > > > > Are you proposing we create one? > > > > > > > > > > Brian > > > > > -----Original Message----- > > > > > From: Dusan Mudric [mailto:dmudric@LEAPSTONE.com] > > > > > Sent: Tuesday, June 17, 2003 11:04 AM > > > > > To: Alan Hawrylyshen; Satish Bansal! > > > > > Cc: Rosen, Brian; sipping@ietf.org > > > > > Subject: RE: [Sipping] Call Waiting - who does the tone > > > > > > > > > > > > > > > Call Waiting service in the core of the network offers > > > more flexible > > > > > solution to service providers. They can chose which media > > > > > server to use and > > > > > type of announcement message to play to the end user waiting > > > > > on the call. > > > > > This would be a part of service offering (in this particular > > > > > example, call > > > > > waiting) to a subscriber. In addition, it is UA independent. > > > > > > > > > > Regards, > > > > > Dusan Mudric. > > > > > Senior Sw Engineer > > > > > Leapstone Systems Inc. > > > > > > > > > > -----Original Message----- > > > > > From: Alan Hawrylyshen [mailto:alan@jasomi.com] > > > > > Sent: Saturday, June 14, 2003 5:28 PM > > > > > To: Satish Bansal! > > > > > Cc: Rosen, Brian; 'sipping@ietf.org' > > > > > Subject: Re: [Sipping] Call Waiting - who does the tone > > > > > > > > > > On Saturday, Jun 14, 2003, at 01:27 Canada/Mountain, Satish > > > > > Bansal! wrote: > > > > > > > > > > There could be two options. First as you said, a dump phone > > > > > should handle > > > > > call waiting. It would mean that we are making end nodes > > > > > intelligent. > > > > > > > > > > Second option is that intelligence is in the network, the > > > > > inbound proxy > > > > > should be call statefull and should use 3pcc for playing > > > > tone & annc. > > > > > through a server to the party. > > > > > > > > > > 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 > > > > > 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). > > > > > > > > > > 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 > > > > > maintain and > > > > > deploy the 'core' portion of a SIP network infrastructure. > > > > > > > > > > I would agree w/ Brian on this; this could be appropriate for > > > > > inclusion in a > > > > > BCP document. > > > > > > > > > > De-lurking, > > > > > > > > > > Alan Hawrylyshen Jasomi Networks Inc. > > > > > sip:alan@jasomi.com mailto:alan@jasomi.com > > > > > http://www.jasomi.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 Fri Jun 20 10:15: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 KAA07942 for ; Fri, 20 Jun 2003 10:15:33 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KEF6u31142 for sipping-archive@odin.ietf.org; Fri, 20 Jun 2003 10:15:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TMfS-00086D-IC for sipping-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 10:15: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 KAA07887 for ; Fri, 20 Jun 2003 10:15:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TMfQ-0004FE-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 10:15:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TMfP-0004F7-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 10:15:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TMfO-000859-3i; Fri, 20 Jun 2003 10:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TMeM-00084Y-Dp for sipping@optimus.ietf.org; Fri, 20 Jun 2003 10:14: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 KAA07756 for ; Fri, 20 Jun 2003 10:13:55 -0400 (EDT) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TMeK-0004Eu-00 for sipping@ietf.org; Fri, 20 Jun 2003 10:13:56 -0400 Received: from imo-r02.mx.aol.com ([152.163.225.98]) by ietf-mx with esmtp (Exim 4.12) id 19TMeJ-0004Ei-00 for sipping@ietf.org; Fri, 20 Jun 2003 10:13:55 -0400 Received: from Mpierce1@aol.com by imo-r02.mx.aol.com (mail_out_v36.3.) id c.18e.1c177f42 (4196); Fri, 20 Jun 2003 10:12:46 -0400 (EDT) Message-ID: <18e.1c177f42.2c24705e@aol.com> Date: Fri, 20 Jun 2003 10:12:46 EDT Subject: Re: [Sipping] Call Waiting - who does the tone (round 2) To: rohan@cisco.com, dmudric@leapstone.com CC: Brian.Rosen@marconi.com, alan@jasomi.com, sbansal@cdotd.ernet.in, sipping@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_18e.1c177f42.2c24705e_boundary" X-Mailer: 6.0 for Windows XP sub 10501 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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_18e.1c177f42.2c24705e_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 6/19/2003 1:28:51 PM Eastern Standard Time, rohan@cisco.com writes: > Dusan, > > Every SIP phone that I am aware of offers call waiting natively. It > requires no cooperation on the part of any service provider, and no > additional cost by either the end-user nor by any service provider. > > - Nobody has provided any compelling benefit to the end-user to do call > waiting in the network > - Nobody has provided any compelling benefit to the service provider to > do call waiting in the network > - Nobody has demonstrated that any SIP phones implement any of the > additional weirdo mechanism that would be required to make network call > waiting work as well as locally-implemented call waiting, Nor that > there is any compelling economic reason for them to do so. > > thanks, > -rohan > Rohan, I've been watching this discussion hoping to see a good answer to the beginning question: "Who does the tone?" since this same question about the source of tones comes up in many other areas, such as the Assured Service that we require. Maybe I missed something, but I don't think I've heard an answer - just lots of conjecture and possibilities of how it might be done. As for the question above - what is the benefit to the service provider to doing call waiting in the network?- I'll try to address that one. It's not a question of "where" it's done, but of who controls it. In the case I am interested in, the network provider/service provider/end users (really all the same large bunch of people) want a system which offers a number of services, including Call Waiting and Assured Service. Part of the requirement is to provide certain operational interactions between those services. That is, there is an expectation of which service takes precedence when multiple services may apply at the same time. If Call Waiting is done completely in the UA, and Call Forwarding is done in a proxy, and the decision to preempt a call for Assured Service is done someplace else, there is no way that I can imagine that the service provider would have any control whatsoever over the precedence of these actions or other interactions between them. So the requirement for this network is going to be that all services applying to a terminating call must be controlled by a single device, I guess it would be a SIP proxy serving the called user. The service provider requires standardized ways to do all of the required services, controlled by a proxy. Without that, it can not use SIP. Mike Pierce --part1_18e.1c177f42.2c24705e_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 6/19/2= 003 1:28:51 PM Eastern Standard Time, rohan@cisco.com writes:


Dusan,

Every SIP phone that I am aware of offers call waiting natively. It=20
requires no cooperation on the part of any service provider, and no=20
additional cost by either the end-user nor by any service provider.

- Nobody has provided any compelling benefit to the end-user to do call=20
waiting in the network
- Nobody has provided any compelling benefit to the service provider to=20
do call waiting in the network
- Nobody has demonstrated that any SIP phones implement any of the=20
additional weirdo mechanism that would be required to make network call=20
waiting work as well as locally-implemented call waiting, Nor that=20
there is any compelling economic reason for them to do so.

thanks,
-rohan




Rohan,

I've been watching this discussion hoping to see a good answer to the be= ginning question: "Who does the tone?" since this same question about the so= urce of tones comes up in many other areas, such as the Assured Service that= we require. Maybe I missed something, but I don't think I've heard an answe= r - just lots of conjecture and possibilities of how it might be done.

As for the question above - what is the benefit to the service provider=20= to doing call waiting in the network?- I'll try to address that one.

It's not a question of "where" it's done, but of who controls it. In the= case I am interested in, the network provider/service provider/end users (r= eally all the same large bunch of people) want a system which offers a numbe= r of services, including Call Waiting and Assured Service. Part of the requi= rement is to provide certain operational interactions between those services= . That is, there is an expectation of which service takes precedence when mu= ltiple services may apply at the same time. If Call Waiting is done complete= ly in the UA, and Call Forwarding is done in a proxy, and the decision to pr= eempt a call for Assured Service is done someplace else, there is no way tha= t I can imagine that the service provider would have any control whatsoever=20= over the precedence of these actions or other interactions between them. So=20= the requirement for this network is going to be that all services applying t= o a terminating call must be controlled by a single device, I guess it would= be a SIP proxy serving the called user. The service provider requires stand= ardized ways to do all of the required services, controlled by a proxy. With= out that, it can not use SIP.


Mike Pierce
--part1_18e.1c177f42.2c24705e_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 Fri Jun 20 10:27:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08371 for ; Fri, 20 Jun 2003 10:27:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KER3l01103 for sipping-archive@odin.ietf.org; Fri, 20 Jun 2003 10: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 19TMr1-0000Hi-GB for sipping-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 10:27:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08352 for ; Fri, 20 Jun 2003 10:26:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TMqy-0004J8-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 10:27:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TMqy-0004J5-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 10:27:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TMqz-0000Gn-Ah; Fri, 20 Jun 2003 10: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 19TMqZ-0000GH-1Y for sipping@optimus.ietf.org; Fri, 20 Jun 2003 10:26: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 KAA08346 for ; Fri, 20 Jun 2003 10:26:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TMqW-0004J2-00 for sipping@ietf.org; Fri, 20 Jun 2003 10:26:32 -0400 Received: from [204.42.169.163] (helo=elmer.LEAPSTONE.COM) by ietf-mx with esmtp (Exim 4.12) id 19TMqT-0004It-00 for sipping@ietf.org; Fri, 20 Jun 2003 10:26:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33737.F619AAC8" Subject: RE: [Sipping] Call Waiting - who does the tone (round 2) Date: Fri, 20 Jun 2003 10:26:38 -0400 Message-ID: <59A835EDCDDBEB46BC75402F4604D5520107AC91@elmer> Thread-Topic: [Sipping] Call Waiting - who does the tone (round 2) Thread-Index: AcM3Ni8gnU/8ueDZQGCVAthHY4XyvAAAR7Zg From: "Dusan Mudric" To: , Cc: , , , Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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_01C33737.F619AAC8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Exactly.=20 =20 That was basic assumption. I was just trying to show that it is possible = to make it controllable by service provider. I didn't want to stream = discussion into this direction assuming concept of service control is = well understood. =20 Regards, Dusan Mudric. =20 -----Original Message----- From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: Friday, June 20, 2003 10:13 AM To: rohan@cisco.com; Dusan Mudric Cc: Brian.Rosen@marconi.com; alan@jasomi.com; sbansal@cdotd.ernet.in; = sipping@ietf.org Subject: Re: [Sipping] Call Waiting - who does the tone (round 2) =20 In a message dated 6/19/2003 1:28:51 PM Eastern Standard Time, = rohan@cisco.com writes:=20 Dusan,=20 Every SIP phone that I am aware of offers call waiting natively. It=20 requires no cooperation on the part of any service provider, and no=20 additional cost by either the end-user nor by any service provider.=20 - Nobody has provided any compelling benefit to the end-user to do call=20 waiting in the network=20 - Nobody has provided any compelling benefit to the service provider to=20 do call waiting in the network=20 - Nobody has demonstrated that any SIP phones implement any of the=20 additional weirdo mechanism that would be required to make network call=20 waiting work as well as locally-implemented call waiting, Nor that=20 there is any compelling economic reason for them to do so.=20 thanks,=20 -rohan=20 Rohan,=20 I've been watching this discussion hoping to see a good answer to the = beginning question: "Who does the tone?" since this same question about = the source of tones comes up in many other areas, such as the Assured = Service that we require. Maybe I missed something, but I don't think = I've heard an answer - just lots of conjecture and possibilities of how = it might be done.=20 As for the question above - what is the benefit to the service provider = to doing call waiting in the network?- I'll try to address that one.=20 It's not a question of "where" it's done, but of who controls it. In the = case I am interested in, the network provider/service provider/end users = (really all the same large bunch of people) want a system which offers a = number of services, including Call Waiting and Assured Service. Part of = the requirement is to provide certain operational interactions between = those services. That is, there is an expectation of which service takes = precedence when multiple services may apply at the same time. If Call = Waiting is done completely in the UA, and Call Forwarding is done in a = proxy, and the decision to preempt a call for Assured Service is done = someplace else, there is no way that I can imagine that the service = provider would have any control whatsoever over the precedence of these = actions or other interactions between them. So the requirement for this = network is going to be that all services applying to a terminating call = must be controlled by a single device, I guess it would be a SIP proxy = serving the called user. The service provider requires standardized ways = to do all of the required services, controlled by a proxy. Without that, = it can not use SIP.=20 Mike Pierce=20 ------_=_NextPart_001_01C33737.F619AAC8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Ex= actly.

 

Th= at was basic assumption. I was just trying to show that it is possible to make = it controllable by service provider. I didn’t want to stream = discussion into this direction assuming concept of service control is well = understood.

 

Regards,

Dusan Mudric.

<= span class=3DEmailStyle15> 

-----Original Message-----
From: Mpierce1@aol.com [mailto:Mpierce1@aol.com]
Sent: Friday, June 20, = 2003 10:13 AM
To: rohan@cisco.com; = Dusan Mudric
Cc: = Brian.Rosen@marconi.com; alan@jasomi.com; sbansal@cdotd.ernet.in; sipping@ietf.org
Subject: Re: [Sipping] = Call Waiting - who does the tone (round 2)

 

In a message dated 6/19/2003 1:28:51 PM Eastern Standard Time, = rohan@cisco.com writes:



Dusan,

Every SIP phone that I am aware of offers call waiting natively. It
requires no cooperation on the part of any service provider, and no
additional cost by either the end-user nor by any service provider.

- Nobody has provided any compelling benefit to the end-user to do call =
waiting in the network
- Nobody has provided any compelling benefit to the service provider to =
do call waiting in the network
- Nobody has demonstrated that any SIP phones implement any of the
additional weirdo mechanism that would be required to make network call =
waiting work as well as locally-implemented call waiting, Nor that
there is any compelling economic reason for them to do so.

thanks,
-rohan





Rohan,

I've been watching this discussion hoping to see a good answer to the = beginning question: "Who does the tone?" since this same question about = the source of tones comes up in many other areas, such as the Assured = Service that we require. Maybe I missed something, but I don't think I've heard an = answer - just lots of conjecture and possibilities of how it might be done.

As for the question above - what is the benefit to the service provider = to doing call waiting in the network?- I'll try to address that one.

It's not a question of "where" it's done, but of who controls = it. In the case I am interested in, the network provider/service provider/end = users (really all the same large bunch of people) want a system which offers a = number of services, including Call Waiting and Assured Service. Part of the requirement is to provide certain operational interactions between those services. That is, there is an expectation of which service takes = precedence when multiple services may apply at the same time. If Call Waiting is = done completely in the UA, and Call Forwarding is done in a proxy, and the = decision to preempt a call for Assured Service is done someplace else, there is = no way that I can imagine that the service provider would have any control = whatsoever over the precedence of these actions or other interactions between them. = So the requirement for this network is going to be that all services applying = to a terminating call must be controlled by a single device, I guess it would = be a SIP proxy serving the called user. The service provider requires = standardized ways to do all of the required services, controlled by a proxy. Without = that, it can not use SIP.


Mike Pierce

------_=_NextPart_001_01C33737.F619AAC8-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 20 10:44: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 KAA08938 for ; Fri, 20 Jun 2003 10:44:33 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KEi6J06427 for sipping-archive@odin.ietf.org; Fri, 20 Jun 2003 10:44:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TN7W-0001fa-8m for sipping-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 10:44: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 KAA08911 for ; Fri, 20 Jun 2003 10:44:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TN7T-0004R8-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 10:44:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TN7T-0004R5-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 10: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 19TN7R-0001ea-98; Fri, 20 Jun 2003 10: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 19TN6i-0001b6-Qw for sipping@optimus.ietf.org; Fri, 20 Jun 2003 10:43: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 KAA08878 for ; Fri, 20 Jun 2003 10:43:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TN6g-0004Qh-00 for sipping@ietf.org; Fri, 20 Jun 2003 10:43:14 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19TN6f-0004QK-00 for sipping@ietf.org; Fri, 20 Jun 2003 10:43:13 -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 KAA04551; Fri, 20 Jun 2003 10:42:40 -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 KAA06108; Fri, 20 Jun 2003 10:42:42 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Jun 2003 10:42:41 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5B12@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Mpierce1@aol.com'" , rohan@cisco.com, dmudric@leapstone.com Cc: alan@jasomi.com, sbansal@cdotd.ernet.in, sipping@ietf.org Subject: RE: [Sipping] Call Waiting - who does the tone (round 2) Date: Fri, 20 Jun 2003 10:42:39 -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: , Mike Most SIP Phones handle multiple call appearances. Some don't. For the ones that do, "Call Waiting" isn't a useful service; it's clearly handled in the phone. At the moment, I don't even think there is way for a system to even know if a phone can actually handle multiple call appearances. With that reality, I think that the requirement is that the phone do something reasonable when it gets an INVITE from another UA while it has an existing session. It might light a light, ring the ringer, play a tone, or shake, but it does something that alerts the user that another call is available. The call assurance service would have to work with phones that handle multiple call appearances. Whatever you decide to do with them would apply equally to a phone that only handles one call, but plays a tone when another INVITE arrives. There are no significant differences. Brian -----Original Message----- From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: Friday, June 20, 2003 10:13 AM To: rohan@cisco.com; dmudric@leapstone.com Cc: Brian.Rosen@marconi.com; alan@jasomi.com; sbansal@cdotd.ernet.in; sipping@ietf.org Subject: Re: [Sipping] Call Waiting - who does the tone (round 2) In a message dated 6/19/2003 1:28:51 PM Eastern Standard Time, rohan@cisco.com writes: Dusan, Every SIP phone that I am aware of offers call waiting natively. It requires no cooperation on the part of any service provider, and no additional cost by either the end-user nor by any service provider. - Nobody has provided any compelling benefit to the end-user to do call waiting in the network - Nobody has provided any compelling benefit to the service provider to do call waiting in the network - Nobody has demonstrated that any SIP phones implement any of the additional weirdo mechanism that would be required to make network call waiting work as well as locally-implemented call waiting, Nor that there is any compelling economic reason for them to do so. thanks, -rohan Rohan, I've been watching this discussion hoping to see a good answer to the beginning question: "Who does the tone?" since this same question about the source of tones comes up in many other areas, such as the Assured Service that we require. Maybe I missed something, but I don't think I've heard an answer - just lots of conjecture and possibilities of how it might be done. As for the question above - what is the benefit to the service provider to doing call waiting in the network?- I'll try to address that one. It's not a question of "where" it's done, but of who controls it. In the case I am interested in, the network provider/service provider/end users (really all the same large bunch of people) want a system which offers a number of services, including Call Waiting and Assured Service. Part of the requirement is to provide certain operational interactions between those services. That is, there is an expectation of which service takes precedence when multiple services may apply at the same time. If Call Waiting is done completely in the UA, and Call Forwarding is done in a proxy, and the decision to preempt a call for Assured Service is done someplace else, there is no way that I can imagine that the service provider would have any control whatsoever over the precedence of these actions or other interactions between them. So the requirement for this network is going to be that all services applying to a terminating call must be controlled by a single device, I guess it would be a SIP proxy serving the called user. The service provider requires standardized ways to do all of the required services, controlled by a proxy. Without that, it can not use SIP. Mike Pierce _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 20 13:06: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 NAA17662 for ; Fri, 20 Jun 2003 13:06:33 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KH66r16143 for sipping-archive@odin.ietf.org; Fri, 20 Jun 2003 13:06:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TPKw-0004CI-Qq for sipping-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 13:06: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 NAA17644 for ; Fri, 20 Jun 2003 13:06:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TPKv-0006j8-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 13:06:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TPKu-0006j5-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 13: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 19TPKs-0004BF-Hh; Fri, 20 Jun 2003 13: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 19TPKm-0004Aw-Sy for sipping@optimus.ietf.org; Fri, 20 Jun 2003 13:06: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 NAA17638 for ; Fri, 20 Jun 2003 13:05:53 -0400 (EDT) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TPKl-0006iu-00 for sipping@ietf.org; Fri, 20 Jun 2003 13:05:55 -0400 Received: from imo-m01.mx.aol.com ([64.12.136.4]) by ietf-mx with esmtp (Exim 4.12) id 19TPKk-0006ik-00 for sipping@ietf.org; Fri, 20 Jun 2003 13:05:54 -0400 Received: from Mpierce1@aol.com by imo-m01.mx.aol.com (mail_out_v36.3.) id z.178.1c762b31 (4184); Fri, 20 Jun 2003 13:05:03 -0400 (EDT) Message-ID: <178.1c762b31.2c2498be@aol.com> Date: Fri, 20 Jun 2003 13:05:02 EDT Subject: Re: [Sipping] Call Waiting - who does the tone To: Henry.Sinnreich@mci.com, dmudric@LEAPSTONE.com, zqweng@utstar.com, Brian.Rosen@marconi.com CC: sipping@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_178.1c762b31.2c2498be_boundary" X-Mailer: 6.0 for Windows XP sub 10501 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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_178.1c762b31.2c2498be_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 6/20/2003 9:47:56 AM Eastern Standard Time, Henry.Sinnreich@mci.com writes: > Can't the phone just generate a local beep? Or do you propose a $M > project to generate the beep from a media server in the network? :-) > I can certainly foresee a service provider that wants to provide a Call Waiting announcement like "You have a call waiting from John Doe." rather than a beep. And there are many other cases of the need to provide announcements in the middle of a call. I think Dusan's comments should be thought of in the general case, not just Call Waiting. While I don't know if his idea is a good one or possible, we still need a general solution for this. Mike Pierce --part1_178.1c762b31.2c2498be_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 6/20/2= 003 9:47:56 AM Eastern Standard Time, Henry.Sinnreich@mci.com writes:


Can't the phone just genera= te a local beep? Or do you propose a $M
project to generate the beep from a media server in the network?  := -)


I can certainly foresee a service provider that wants to provide a Call=20= Waiting announcement like "You have a call waiting from John Doe." rather th= an a beep. And there are many other cases of the need to provide announcemen= ts in the middle of a call. I think Dusan's comments should be thought of in= the general case, not just Call Waiting. While I don't know if his idea is=20= a good one or possible, we still need a general solution for this.

Mike Pierce
--part1_178.1c762b31.2c2498be_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 Fri Jun 20 13:25:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18236 for ; Fri, 20 Jun 2003 13:25:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KHP4X20584 for sipping-archive@odin.ietf.org; Fri, 20 Jun 2003 13:25:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TPdI-0005Lv-7h for sipping-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 13:25:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18205 for ; Fri, 20 Jun 2003 13:25:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TPdG-0006qd-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 13:25:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TPdF-0006qa-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 13:25:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TPdF-0005L1-Fh; Fri, 20 Jun 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 19TPcQ-0005I9-7e for sipping@optimus.ietf.org; Fri, 20 Jun 2003 13: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 NAA18189 for ; Fri, 20 Jun 2003 13:24:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TPcO-0006qH-00 for sipping@ietf.org; Fri, 20 Jun 2003 13:24:08 -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 19TPcM-0006q9-00 for sipping@ietf.org; Fri, 20 Jun 2003 13:24:07 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-1.cisco.com with ESMTP; 20 Jun 2003 10:25:25 -0800 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 h5KHNXEP014007; Fri, 20 Jun 2003 10:23: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.3-GR) with ESMTP id AII59694; Fri, 20 Jun 2003 10:17:15 -0700 (PDT) Date: Fri, 20 Jun 2003 10:24:45 -0700 Subject: Re: [Sipping] Call Waiting - who does the tone (round 2) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: dmudric@leapstone.com, Brian.Rosen@marconi.com, alan@jasomi.com, sbansal@cdotd.ernet.in, sipping@ietf.org To: Mpierce1@aol.com From: Rohan Mahy In-Reply-To: <18e.1c177f42.2c24705e@aol.com> Message-Id: <1641FA4A-A344-11D7-8E0D-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Friday, June 20, 2003, at 07:12 AM, Mpierce1@aol.com wrote: > In a message dated 6/19/2003 1:28:51 PM Eastern Standard Time, > rohan@cisco.com writes: > > > Dusan, > > Every SIP phone that I am aware of offers call waiting natively. It > requires no cooperation on the part of any service provider, and no > additional cost by either the end-user nor by any service provider. > > - Nobody has provided any compelling benefit to the end-user to do call > waiting in the network > - Nobody has provided any compelling benefit to the service provider to > do call waiting in the network > - Nobody has demonstrated that any SIP phones implement any of the > additional weirdo mechanism that would be required to make network call > waiting work as well as locally-implemented call waiting, Nor that > there is any compelling economic reason for them to do so. > > thanks, > -rohan > > > > > > Rohan, > > I've been watching this discussion hoping to see a good answer to the > beginning question: "Who does the tone?" since this same question > about the source of tones comes up in many other areas, such as the > Assured Service that we require. Maybe I missed something, but I don't > think I've heard an answer - just lots of conjecture and possibilities > of how it might be done. > > As for the question above - what is the benefit to the service > provider to doing call waiting in the network?- I'll try to address > that one. > > It's not a question of "where" it's done, but of who controls it. In > the case I am interested in, the network provider/service provider/end > users (really all the same large bunch of people) want a system which > offers a number of services, including Call Waiting and Assured > Service. Part of the requirement is to provide certain operational > interactions between those services. That is, there is an expectation > of which service takes precedence when multiple services may apply at > the same time. If Call Waiting is done completely in the UA, and Call > Forwarding is done in a proxy, and the decision to preempt a call for > Assured Service is done someplace else, there is no way that I can > imagine that the service provider would have any control whatsoever > over the precedence of these actions or other interactions between > them. So the requirement for this network is going to be that all > services applying to a terminating call must be controlled by a single > device, I guess it would be a SIP proxy serving the called user. The > service provider requires standardized ways to do all of the required > services, controlled by a proxy. Without that, it can not use SIP. This is a good question, the answer to which should probably be explained more explicitly in the resource-priority draft. If you want to offer a service which duplicates the current MLPP experience, then I suggest that you do everything in the UA except for call forwarding unavailable, which obviously you cannot do in the UA if it is not there. If you email me the behavior you want, I am happy to sit down with you for 30 minutes in Vienna, and show you a cohesive one way to implement that behavior on a set of UAs including the appropriate security and management. In this case, the real service that the service provider is offering is a provisioning and authorization service rather than a call process service in the traditional sense. For an ETS-like service, I believe you have more of a gateway prioritization and QoS coordination service. The only coordination you would need with the proxies is to get to the appropriate set of gateways (which could even be the same gateways). Hope this helps. thanks, -rohan > > Mike Pierce _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 20 13:33: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 NAA19441 for ; Fri, 20 Jun 2003 13:33:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KHX4h22051 for sipping-archive@odin.ietf.org; Fri, 20 Jun 2003 13:33:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TPl2-0005jV-Gy for sipping-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 13: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 NAA19364 for ; Fri, 20 Jun 2003 13:33:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TPl0-00074L-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 13:33:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TPkz-00074H-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 13:33:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TPkz-0005gu-KU; Fri, 20 Jun 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 19TPk6-0005fJ-TA for sipping@optimus.ietf.org; Fri, 20 Jun 2003 13:32:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19259 for ; Fri, 20 Jun 2003 13:32:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TPk4-00073M-00 for sipping@ietf.org; Fri, 20 Jun 2003 13:32:05 -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 19TPk4-00072g-00 for sipping@ietf.org; Fri, 20 Jun 2003 13:32:04 -0400 Received: from cisco.com (171.68.223.138) by sj-iport-1.cisco.com with ESMTP; 20 Jun 2003 10:33:24 -0800 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 h5KHVV9b006457; Fri, 20 Jun 2003 10:31: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.3-GR) with ESMTP id AII60790; Fri, 20 Jun 2003 10:25:14 -0700 (PDT) Date: Fri, 20 Jun 2003 10:32:45 -0700 Subject: Re: [Sipping] Call Waiting - who does the tone Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Henry.Sinnreich@mci.com, dmudric@LEAPSTONE.com, zqweng@utstar.com, Brian.Rosen@marconi.com, sipping@ietf.org To: Mpierce1@aol.com From: Rohan Mahy In-Reply-To: <178.1c762b31.2c2498be@aol.com> Message-Id: <345D7DF2-A345-11D7-8E0D-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Friday, June 20, 2003, at 10:05 AM, Mpierce1@aol.com wrote: > I can certainly foresee a service provider that wants to provide a > Call Waiting announcement like "You have a call waiting from John > Doe." rather than a beep. And there are many other cases of the need > to provide announcements in the middle of a call. I think Dusan's > comments should be thought of in the general case, not just Call > Waiting. While I don't know if his idea is a good one or possible, we > still need a general solution for this. I agree that we want to solve the problem of tones in general. What we badly need is a set of requirements, or at least some scenarios. If we use scenarios, I don't think the scenarios should assume who is generating messages or tones. Lets focus on the experience we want the user to have, and then we can talk about the best way to provide that experience. 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 Jun 20 13:53:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20446 for ; Fri, 20 Jun 2003 13:53:36 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KHr8j29187 for sipping-archive@odin.ietf.org; Fri, 20 Jun 2003 13:53:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TQ4S-0007ag-Rx for sipping-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 13: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 NAA20420 for ; Fri, 20 Jun 2003 13:53:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TQ4Q-0007K6-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 13:53:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TQ4Q-0007K3-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 13:53:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TQ4L-0007ZP-Ku; Fri, 20 Jun 2003 13:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TQ3e-0007YP-Pa for sipping@optimus.ietf.org; Fri, 20 Jun 2003 13:52: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 NAA20394 for ; Fri, 20 Jun 2003 13:52:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TQ3c-0007JV-00 for sipping@ietf.org; Fri, 20 Jun 2003 13:52:16 -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 19TQ3b-0007JN-00 for sipping@ietf.org; Fri, 20 Jun 2003 13:52:16 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 20 Jun 2003 10:53:34 -0800 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 h5KHpgUe004406; Fri, 20 Jun 2003 10:51:42 -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 KAA28358; Fri, 20 Jun 2003 10:51:41 -0700 (PDT) Message-Id: <4.3.2.7.2.20030620124802.01e6aa90@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 20 Jun 2003 12:51:41 -0500 To: Mpierce1@aol.com, rohan@cisco.com, dmudric@leapstone.com From: "James M. Polk" Subject: Re: [Sipping] Call Waiting - who does the tone (round 2) Cc: Brian.Rosen@marconi.com, alan@jasomi.com, sbansal@cdotd.ernet.in, sipping@ietf.org In-Reply-To: <18e.1c177f42.2c24705e@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , At 10:12 AM 6/20/2003 -0400, Mpierce1@aol.com wrote: >In a message dated 6/19/2003 1:28:51 PM Eastern Standard Time, >rohan@cisco.com writes: > That is, there is an expectation of which service takes precedence when > multiple services may apply at the same time. If Call Waiting is done > completely in the UA, and Call Forwarding is done in a proxy, and the > decision to preempt a call for Assured Service is done someplace else, > there is no way that I can imagine that the service provider would have > any control whatsoever over the precedence of these actions or other > interactions between them. So the requirement for this network is going > to be that all services applying to a terminating call must be controlled > by a single device, I guess it would be a SIP proxy serving the called > user. The service provider requires standardized ways to do all of the > required services, controlled by a proxy. Without that, it can not use SIP. Mike Are you suggesting that SIP become a (Proxy) Server controlled Protocol (of UAs) before you'll use it? I hope I misunderstood the last bit of your paragraph above >Mike Pierce 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 Fri Jun 20 13:57:31 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 NAA20696 for ; Fri, 20 Jun 2003 13:57:31 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KHv3Y30176 for sipping-archive@odin.ietf.org; Fri, 20 Jun 2003 13:57:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TQ8F-0007qd-Kz for sipping-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 13:57:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20647 for ; Fri, 20 Jun 2003 13:57:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TQ8D-0007NA-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 13:57:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TQ8C-0007N3-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 13:57:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TQ8D-0007nV-HM; Fri, 20 Jun 2003 13: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 19TQ7v-0007li-KC for sipping@optimus.ietf.org; Fri, 20 Jun 2003 13:56: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 NAA20590 for ; Fri, 20 Jun 2003 13:56:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TQ7t-0007MR-00 for sipping@ietf.org; Fri, 20 Jun 2003 13:56:41 -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 19TQ7s-0007M0-00 for sipping@ietf.org; Fri, 20 Jun 2003 13:56:41 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 20 Jun 2003 10:57:59 -0800 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 h5KHu7Ue008653; Fri, 20 Jun 2003 10:56:08 -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 KAA05989; Fri, 20 Jun 2003 10:56:06 -0700 (PDT) Message-Id: <4.3.2.7.2.20030620125358.022b6ee8@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 20 Jun 2003 12:56:07 -0500 To: Rohan Mahy , Mpierce1@aol.com From: "James M. Polk" Subject: Re: [Sipping] Call Waiting - who does the tone (round 2) (R-P?) Cc: sipping@ietf.org In-Reply-To: <1641FA4A-A344-11D7-8E0D-0003938AF740@cisco.com> References: <18e.1c177f42.2c24705e@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , How did the R-P draft get drug into this thread about Call Waiting and tones? At 10:24 AM 6/20/2003 -0700, Rohan Mahy wrote: >On Friday, June 20, 2003, at 07:12 AM, Mpierce1@aol.com wrote: > >>In a message dated 6/19/2003 1:28:51 PM Eastern Standard Time, >>rohan@cisco.com writes: >> >> >>Dusan, >> >>Every SIP phone that I am aware of offers call waiting natively. It >>requires no cooperation on the part of any service provider, and no >>additional cost by either the end-user nor by any service provider. >> >>- Nobody has provided any compelling benefit to the end-user to do call >>waiting in the network >>- Nobody has provided any compelling benefit to the service provider to >>do call waiting in the network >>- Nobody has demonstrated that any SIP phones implement any of the >>additional weirdo mechanism that would be required to make network call >>waiting work as well as locally-implemented call waiting, Nor that >>there is any compelling economic reason for them to do so. >> >>thanks, >>-rohan >> >> >> >> >> >>Rohan, >> >>I've been watching this discussion hoping to see a good answer to the >>beginning question: "Who does the tone?" since this same question about >>the source of tones comes up in many other areas, such as the Assured >>Service that we require. Maybe I missed something, but I don't think I've >>heard an answer - just lots of conjecture and possibilities of how it >>might be done. >> >>As for the question above - what is the benefit to the service provider >>to doing call waiting in the network?- I'll try to address that one. >> >>It's not a question of "where" it's done, but of who controls it. In the >>case I am interested in, the network provider/service provider/end users >>(really all the same large bunch of people) want a system which offers a >>number of services, including Call Waiting and Assured Service. Part of >>the requirement is to provide certain operational interactions between >>those services. That is, there is an expectation of which service takes >>precedence when multiple services may apply at the same time. If Call >>Waiting is done completely in the UA, and Call Forwarding is done in a >>proxy, and the decision to preempt a call for Assured Service is done >>someplace else, there is no way that I can imagine that the service >>provider would have any control whatsoever over the precedence of these >>actions or other interactions between them. So the requirement for this >>network is going to be that all services applying to a terminating call >>must be controlled by a single device, I guess it would be a SIP proxy >>serving the called user. The service provider requires standardized ways >>to do all of the required services, controlled by a proxy. Without that, >>it can not use SIP. > >This is a good question, the answer to which should probably be explained >more explicitly in the resource-priority draft. If you want to offer a >service which duplicates the current MLPP experience, then I suggest that >you do everything in the UA except for call forwarding unavailable, which >obviously you cannot do in the UA if it is not there. If you email me the >behavior you want, I am happy to sit down with you for 30 minutes in >Vienna, and show you a cohesive one way to implement that behavior on a >set of UAs including the appropriate security and management. In this >case, the real service that the service provider is offering is a >provisioning and authorization service rather than a call process service >in the traditional sense. > >For an ETS-like service, I believe you have more of a gateway >prioritization and QoS coordination service. The only coordination you >would need with the proxies is to get to the appropriate set of gateways >(which could even be the same gateways). > >Hope this helps. >thanks, >-rohan > >> >>Mike Pierce > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP 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 Fri Jun 20 14:22: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 NAA19440 for ; Fri, 20 Jun 2003 13:33:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KHX4122049 for sipping-archive@odin.ietf.org; Fri, 20 Jun 2003 13:33:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TPl2-0005jU-Fo for sipping-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 13: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 NAA19361 for ; Fri, 20 Jun 2003 13:33:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TPl0-00074O-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 13:33:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TPkz-00074I-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 13:33:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TPl0-0005hU-NP; Fri, 20 Jun 2003 13:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TPky-0005gh-G1 for sipping@optimus.ietf.org; Fri, 20 Jun 2003 13:33: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 NAA19354 for ; Fri, 20 Jun 2003 13:32:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TPkw-000748-00 for sipping@ietf.org; Fri, 20 Jun 2003 13:32:58 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19TPkv-00073i-00 for sipping@ietf.org; Fri, 20 Jun 2003 13:32:57 -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 NAA09072; Fri, 20 Jun 2003 13:32:25 -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 NAA25087; Fri, 20 Jun 2003 13:32:27 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Jun 2003 13:32:26 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5B18@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Mpierce1@aol.com'" , Henry.Sinnreich@mci.com, dmudric@LEAPSTONE.com, zqweng@utstar.com Cc: sipping@ietf.org Subject: RE: [Sipping] Call Waiting - who does the tone Date: Fri, 20 Jun 2003 13:32:25 -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: , There is nothing even close to providing what would seem to be needed to achieve this goal - the ability of a server in the network to inject a media stream into an existing stream, or, worse, interrupt the existing stream and play an announcement. It would take a pretty significant change to SIP to do this, something like a special INVITE that was explicitly automatically answered, with no ringing, that pre-empted or mixed with the existing call. The security implications alone are daunting. It would be something that would have to have mandatory-to-implement characteristics in order to deploy the service. I'm not interested in such a change. In most of the cases where networks presently provide announcements, the current SIP mechanisms suffice. Call waiting tone for one line phones may not be implemented well yet, shame on us, but most functions do work. You might want to cite some more instances where a network announcement in the middle of a session is needed. I think MLPP is probably a UA function also, as Rohan pointed out in his reply to your prior post, so that's probably not a good example either. Brian -----Original Message----- From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: Friday, June 20, 2003 1:05 PM To: Henry.Sinnreich@mci.com; dmudric@LEAPSTONE.com; zqweng@utstar.com; Brian.Rosen@marconi.com Cc: sipping@ietf.org Subject: Re: [Sipping] Call Waiting - who does the tone In a message dated 6/20/2003 9:47:56 AM Eastern Standard Time, Henry.Sinnreich@mci.com writes: Can't the phone just generate a local beep? Or do you propose a $M project to generate the beep from a media server in the network? :-) I can certainly foresee a service provider that wants to provide a Call Waiting announcement like "You have a call waiting from John Doe." rather than a beep. And there are many other cases of the need to provide announcements in the middle of a call. I think Dusan's comments should be thought of in the general case, not just Call Waiting. While I don't know if his idea is a good one or possible, we still need a general solution for this. Mike Pierce _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 20 14:53:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27270 for ; Fri, 20 Jun 2003 14:53:18 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KIqp414498 for sipping-archive@odin.ietf.org; Fri, 20 Jun 2003 14:52:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TR0F-0003ll-J6 for sipping-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 14:52:51 -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 OAA27196 for ; Fri, 20 Jun 2003 14: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 19TQzQ-0003kC-Jr; Fri, 20 Jun 2003 14: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 19TQyX-0003eh-A7 for sipping@optimus.ietf.org; Fri, 20 Jun 2003 14:51:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26942 for ; Fri, 20 Jun 2003 14:51:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TQyU-0000aA-00 for sipping@ietf.org; Fri, 20 Jun 2003 14:51:02 -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 19TQyR-0000Z1-00 for sipping@ietf.org; Fri, 20 Jun 2003 14:51:01 -0400 content-class: urn:content-classes:message Subject: RE: [Sipping] re: what happens if both SIP UAs want to be active MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Date: Fri, 20 Jun 2003 11:50:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: Thread-Topic: temp Thread-Index: AcM3VkG0g+gsAawTSKS1qmE8ddO+NgAAAclg From: "Yutaka Takeda" To: Cc: Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Jiri, I have been working on similar issue. Following I-D I posted might interest you with regard to symmetric NAT traversal at both ends using STUN. It provides other aspects of applicability of STUN. [1] http://www.ietf.org/internet-drafts/draft-takeda-symmetric-nat-traversal-00.txt I agree that it is desirable to be able to tell what is happening in such cases. My I-D[1] does not address any specific protocol, however, it proposes to exchange port allocation rule of NATs, which will tell the other if it is a symmetric NAT or a cone NAT, between clients behind NATs so that both clients know what to do and if it is the case where both ends are behind symmetric NATs, the clients can try another NAT solution, such as TURN, or try out the port prediction as mentioned in [2]. The latter one, however, may fall into the same situation (no sound). The existing proposal that I know of to solve this connectivity issue is ICE (If am correct). [2] http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-ice-00.txt I am still in process of reading it... Yutaka >Jiri Kuthan wrote: > My today's problem is it is difficult to detect when > signaling using comedia > fails because of both UAs behind symmetric NATs trying to > enter symmetric active > mode. If entities in the signaling path (proxies, b2bua, > whatsoever) know > what happened, they can try other means of NAT traversal. The > missing piece > is that they don't know what happened -- there is no specific > error code for > this condition in SIP. > > It's thus imho very desirable to introduce such an error code. > > Comments? > > -Jiri > > At 07:07 PM 6/16/2003, David Yon wrote: > >The SIP gurus can chime in, but seems to me it would be in > the same category as not being able to come to an agreement > vis-a-vis which codec to use. > > > >At 12:25 PM 6/16/2003, Jiri Kuthan wrote: > >>[sorry, misthreaded -- I copy'n'pasted from archive since I > was stripped > >> off the recepient list] > >> > >>What does it mean SIP-wise that negotiation fails? > >> > >>I mean it would be great to have a special code for this error which > >>allows SIP entities to recognized these conditions and act > approprietly. > >> > >>-Jiri > >> > >>on Sun, 08 Jun 2003 17:31:12 -0400, David wrote: > >>> If they both want to be active, the negotiation fails. > >> > >>>> At 12:47 PM 6/7/2003, Jiri Kuthan wrote: > >>>> David, > >>>> > >>>> can you please explain me how SIP signaling proceeds if > two UAs both > >>>> with to have direction=active, since they are behind > symmetric NATs? > >>>> > >>>> Thanks, > >>>> > >>>> -jiri > >> > >>-- > >>Jiri Kuthan http://iptel.org/~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 Fri Jun 20 17:18:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09307 for ; Fri, 20 Jun 2003 17:18:37 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KLI9l12515 for sipping-archive@odin.ietf.org; Fri, 20 Jun 2003 17:18:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TTGr-0003Fl-Py for sipping-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 17:18: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 RAA09231 for ; Fri, 20 Jun 2003 17:18:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TTGp-0003QA-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 17:18:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TTGo-0003Q6-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 17:18:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TTGj-0003A8-Gt; Fri, 20 Jun 2003 17:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TTFk-00038u-P5 for sipping@optimus.ietf.org; Fri, 20 Jun 2003 17:17: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 RAA09191 for ; Fri, 20 Jun 2003 17:16:57 -0400 (EDT) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TTFi-0003P1-00 for sipping@ietf.org; Fri, 20 Jun 2003 17:16:58 -0400 Received: from imo-m07.mx.aol.com ([64.12.136.162]) by ietf-mx with esmtp (Exim 4.12) id 19TTFi-0003Ot-00 for sipping@ietf.org; Fri, 20 Jun 2003 17:16:58 -0400 Received: from Mpierce1@aol.com by imo-m07.mx.aol.com (mail_out_v36.3.) id c.ea.3a395691 (3940); Fri, 20 Jun 2003 17:16:09 -0400 (EDT) Message-ID: Date: Fri, 20 Jun 2003 17:16:09 EDT Subject: Re: [Sipping] Call Waiting - who does the tone (round 2) To: jmpolk@cisco.com CC: sipping@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_ea.3a395691.2c24d399_boundary" X-Mailer: 6.0 for Windows XP sub 10501 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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_ea.3a395691.2c24d399_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 6/20/2003 1:52:17 PM Eastern Standard Time, jmpolk@cisco.com writes: > Are you suggesting that SIP become a (Proxy) Server controlled Protocol (of > UAs) before you'll use it? > > I hope I misunderstood the last bit of your paragraph above > No, I think you understood what I said perfectly. I am saying, as others already have, that the only way in which SIP can be used in a "carrier" environment such as the one I represent is with SIP proxies, controlled by the service provider, in charge of providing and controlling end-user services. Please read draft-pierce-ieprep-assured-service-arch-00. Please understand though, I am not saying that "SIP become a (proxy) server controlled protocol." I am saying that it must be used in that way in the network I'm talking about. I have never argued that the alternative (without SIP proxies) can not be used in some networks to provide a full range of services (although I'm waiting to see it). Mike Pierce --part1_ea.3a395691.2c24d399_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 6/20/2= 003 1:52:17 PM Eastern Standard Time, jmpolk@cisco.com writes:


Are you suggesting that SIP= become a (Proxy) Server controlled Protocol (of=20
UAs) before you'll use it?

I hope I misunderstood the last bit of your paragraph above



No, I think you understood what I said perfectly. I am saying, as others= already have, that the only way in which SIP can be used in a "carrier" env= ironment such as the one I represent is with SIP proxies, controlled by the=20= service provider, in charge of providing and controlling end-user services.=20= Please read draft-pierce-ieprep-assured-service-arch-00.

Please understand though, I am not saying that "SIP become a (proxy) ser= ver controlled protocol." I am saying that it must be used in that way in th= e network I'm talking about. I have never argued that the alternative (witho= ut SIP proxies) can not be used in some networks to provide a full range of=20= services (although I'm waiting to see it).

Mike Pierce
--part1_ea.3a395691.2c24d399_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 Fri Jun 20 17:34:31 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 RAA09717 for ; Fri, 20 Jun 2003 17:34:31 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KLY4q15839 for sipping-archive@odin.ietf.org; Fri, 20 Jun 2003 17:34:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TTWG-00047O-7j for sipping-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 17:34:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09679 for ; Fri, 20 Jun 2003 17:34:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TTWE-0003Wi-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 17:34:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TTWD-0003Wf-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 17:34:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TTWE-00046V-EA; Fri, 20 Jun 2003 17: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 19TTVs-00043K-0l for sipping@optimus.ietf.org; Fri, 20 Jun 2003 17: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 RAA09675 for ; Fri, 20 Jun 2003 17:33:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TTVp-0003WW-00 for sipping@ietf.org; Fri, 20 Jun 2003 17:33:37 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19TTVn-0003Vx-00 for sipping@ietf.org; Fri, 20 Jun 2003 17:33:36 -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 h5KLWfO1005324; Fri, 20 Jun 2003 17:32:42 -0400 (EDT) Received: from cisco.com ([161.44.79.70]) by cannon.cisco.com (Mirapoint) with ESMTP id ABL47614; Fri, 20 Jun 2003 17:41:37 -0400 (EDT) Message-ID: <3EF37D78.3000908@cisco.com> Date: Fri, 20 Jun 2003 17:32:40 -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: Mpierce1@aol.com CC: rohan@cisco.com, dmudric@leapstone.com, Brian.Rosen@marconi.com, alan@jasomi.com, sbansal@cdotd.ernet.in, sipping@ietf.org Subject: Re: [Sipping] Call Waiting - who does the tone (round 2) References: <1d7.bf32160.2c24d398@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 In principle, by design, what you desire can't in general be provided without the cooperation of the endpoint. (Suppose the phone is currently involved in a call where the media stream is secured end:end.) For phones that are capable this ought to be implemented in the phone. If someone wants this service on a phone that isn't capable of providing it, then you probably need to put a B2BUA in front of the phone for all calls. That B2BUA can then assume the responsibilities that the phone is incapable of. The same answer may apply to all mid-call features & tones. Paul Mpierce1@aol.com wrote: > In a message dated 6/20/2003 1:24:06 PM Eastern Standard Time, > rohan@cisco.com writes: > > >> If you want >> to offer a service which duplicates the current MLPP experience, then I >> suggest that you do everything in the UA except for call forwarding >> unavailable, which obviously you cannot do in the UA if it is not >> there. > > > > > The problem with that is similar to what I think started this discussion > on Call Waiting. For Assured Service (MLPP), the "network" needs to be > able to preempt a call at a UA and play a preemption tone to the human > involved in that call, but there is no quarantee that the particular UA > that person is using would understand what a "preemption tone" is or how > to generate it. It needs to come from someplace else, just like some > have suggested for the Call Waiting tone. I tossed this reference about > Assured Service into the discussion since it is one of many service > examples that need the same thing: a tone (or announcement) stuck into > an existing "connection". > > After all the time spent on this, I would hope that you could point me > (and others) to a clear explanation in an existing document on how to do > it. > > Mike Pierce _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 20 18:03:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09308 for ; Fri, 20 Jun 2003 17:18:37 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KLI9G12529 for sipping-archive@odin.ietf.org; Fri, 20 Jun 2003 17:18:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TTGr-0003Fm-RE for sipping-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 17:18: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 RAA09233 for ; Fri, 20 Jun 2003 17:18:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TTGp-0003QD-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 17:18:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TTGp-0003Q7-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 17:18:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TTGk-0003AQ-Ae; Fri, 20 Jun 2003 17:18:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TTFx-000398-2x for sipping@optimus.ietf.org; Fri, 20 Jun 2003 17:17: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 RAA09199 for ; Fri, 20 Jun 2003 17:17:09 -0400 (EDT) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TTFv-0003PC-00 for sipping@ietf.org; Fri, 20 Jun 2003 17:17:11 -0400 Received: from imo-m05.mx.aol.com ([64.12.136.8]) by ietf-mx with esmtp (Exim 4.12) id 19TTFu-0003Ou-00 for sipping@ietf.org; Fri, 20 Jun 2003 17:17:10 -0400 Received: from Mpierce1@aol.com by imo-m05.mx.aol.com (mail_out_v36.3.) id c.1d7.bf32160 (3940); Fri, 20 Jun 2003 17:16:08 -0400 (EDT) Message-ID: <1d7.bf32160.2c24d398@aol.com> Date: Fri, 20 Jun 2003 17:16:08 EDT Subject: Re: [Sipping] Call Waiting - who does the tone (round 2) To: rohan@cisco.com CC: dmudric@leapstone.com, Brian.Rosen@marconi.com, alan@jasomi.com, sbansal@cdotd.ernet.in, sipping@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_1d7.bf32160.2c24d398_boundary" X-Mailer: 6.0 for Windows XP sub 10501 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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_1d7.bf32160.2c24d398_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 6/20/2003 1:24:06 PM Eastern Standard Time, rohan@cisco.com writes: > If you want > to offer a service which duplicates the current MLPP experience, then I > suggest that you do everything in the UA except for call forwarding > unavailable, which obviously you cannot do in the UA if it is not > there. The problem with that is similar to what I think started this discussion on Call Waiting. For Assured Service (MLPP), the "network" needs to be able to preempt a call at a UA and play a preemption tone to the human involved in that call, but there is no quarantee that the particular UA that person is using would understand what a "preemption tone" is or how to generate it. It needs to come from someplace else, just like some have suggested for the Call Waiting tone. I tossed this reference about Assured Service into the discussion since it is one of many service examples that need the same thing: a tone (or announcement) stuck into an existing "connection". After all the time spent on this, I would hope that you could point me (and others) to a clear explanation in an existing document on how to do it. Mike Pierce --part1_1d7.bf32160.2c24d398_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 6/20/2= 003 1:24:06 PM Eastern Standard Time, rohan@cisco.com writes:


If you want=20
to offer a service which duplicates the current MLPP experience, then I=20
suggest that you do everything in the UA except for call forwarding=20
unavailable, which obviously you cannot do in the UA if it is not=20
there.

The problem with that is similar to what I think started this discussion= on Call Waiting. For Assured Service (MLPP), the "network" needs to be able= to preempt a call at a UA and play a preemption tone to the human involved=20= in that call, but there is no quarantee that the particular UA that person i= s using would understand what a "preemption tone" is or how to generate it.=20= It needs to come from someplace else, just like some have suggested for the=20= Call Waiting tone. I tossed this reference about Assured Service into the di= scussion since it is one of many service examples that need the same thing:=20= a tone (or announcement) stuck into an existing "connection".

After all the time spent on this, I would hope that you could point me (= and others) to a clear explanation in an existing document on how to do it.

Mike Pierce
--part1_1d7.bf32160.2c24d398_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 Fri Jun 20 19:10:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14042 for ; Fri, 20 Jun 2003 19:10:31 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KNA6103798 for sipping-archive@odin.ietf.org; Fri, 20 Jun 2003 19:10:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TV1C-0000zB-6e for sipping-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 19:10:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14035 for ; Fri, 20 Jun 2003 19:10:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TV19-0004EZ-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 19:10:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TV18-0004EW-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 19:10:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TV17-0000yE-Tt; Fri, 20 Jun 2003 19:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TV0S-0000xm-VG for sipping@optimus.ietf.org; Fri, 20 Jun 2003 19:09: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 TAA14029 for ; Fri, 20 Jun 2003 19:09:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TV0P-0004EM-00 for sipping@ietf.org; Fri, 20 Jun 2003 19:09:17 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 19TV0P-0004EJ-00 for sipping@ietf.org; Fri, 20 Jun 2003 19:09:17 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5KN8jP11479 for ; Fri, 20 Jun 2003 19:08:45 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ND94CSW7; Fri, 20 Jun 2003 19:08:45 -0400 Received: from nortelnetworks.com (acart1b1.ca.nortel.com [47.129.129.11]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NDJAJ2SN; Fri, 20 Jun 2003 19:08:45 -0400 Message-ID: <3EF393FB.6010907@nortelnetworks.com> Date: Fri, 20 Jun 2003 19:08:43 -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: sipping@ietf.org Subject: Re: [Sipping] Call Waiting - who does the tone (round 2) References: <1d7.bf32160.2c24d398@aol.com> <3EF37D78.3000908@cisco.com> In-Reply-To: <3EF37D78.3000908@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 There's a fairly simple answer to tone/announcement injection by the service provider, but it contradicts the e2e premise. The service provider routes the media streams through a media proxy. This also implies a B2BUA to manipulate the SDP. I'm just demonstrating feasibility, not expecting that the WG wants to spell out the call flows involved. One example of a familiar scenario that might use this is a tone indication or announcement that the money prepaid for the call is running out and more must be provided. Of course, that happens on payphones in the legacy network, and the SIP equivalent would probably handle call timing itself (with the help of the appropriate AAA protocol exchanges to tell it how to rate the call). (Yeah, yeah, I know payphones are old-fashioned, but you still need public terminals of some sort for the minority of us who don't carry cell phones.) Paul Kyzivat wrote: > In principle, by design, what you desire can't in general be provided > without the cooperation of the endpoint. > > (Suppose the phone is currently involved in a call where the media > stream is secured end:end.) > > For phones that are capable this ought to be implemented in the phone. > If someone wants this service on a phone that isn't capable of providing > it, then you probably need to put a B2BUA in front of the phone for all > calls. That B2BUA can then assume the responsibilities that the phone is > incapable of. > > The same answer may apply to all mid-call features & tones. > > Paul > > Mpierce1@aol.com wrote: > >> In a message dated 6/20/2003 1:24:06 PM Eastern Standard Time, >> rohan@cisco.com writes: >> >> >>> If you want >>> to offer a service which duplicates the current MLPP experience, then I >>> suggest that you do everything in the UA except for call forwarding >>> unavailable, which obviously you cannot do in the UA if it is not >>> there. >> >> >> >> >> >> The problem with that is similar to what I think started this >> discussion on Call Waiting. For Assured Service (MLPP), the "network" >> needs to be able to preempt a call at a UA and play a preemption tone >> to the human involved in that call, but there is no quarantee that the >> particular UA that person is using would understand what a "preemption >> tone" is or how to generate it. It needs to come from someplace else, >> just like some have suggested for the Call Waiting tone. I tossed this >> reference about Assured Service into the discussion since it is one of >> many service examples that need the same thing: a tone (or >> announcement) stuck into an existing "connection". >> >> After all the time spent on this, I would hope that you could point me >> (and others) to a clear explanation in an existing document on how to >> do it. >> >> Mike Pierce > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 20 21:13: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 VAA16083 for ; Fri, 20 Jun 2003 21:13:33 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5L1D6e19908 for sipping-archive@odin.ietf.org; Fri, 20 Jun 2003 21:13:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TWwE-0005B1-03 for sipping-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 21:13:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16067 for ; Fri, 20 Jun 2003 21:13:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TWwB-0004jK-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 21:13:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TWwA-0004jH-00 for sipping-web-archive@ietf.org; Fri, 20 Jun 2003 21:13:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TWw9-0005A3-Pa; Fri, 20 Jun 2003 21: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 19TWv8-00059c-NY for sipping@optimus.ietf.org; Fri, 20 Jun 2003 21: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 VAA16037 for ; Fri, 20 Jun 2003 21:11:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TWv6-0004il-00 for sipping@ietf.org; Fri, 20 Jun 2003 21:11:56 -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 19TWv5-0004ii-00 for sipping@ietf.org; Fri, 20 Jun 2003 21:11:55 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-1.cisco.com with ESMTP; 20 Jun 2003 18:13:15 -0800 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 h5L1BFQx011698; Fri, 20 Jun 2003 18:11:15 -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 AIJ09631; Fri, 20 Jun 2003 18:04:55 -0700 (PDT) Date: Fri, 20 Jun 2003 18:12:28 -0700 Subject: Re: [Sipping] Call Waiting - who does the tone (round 2) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: dmudric@leapstone.com, Brian.Rosen@marconi.com, alan@jasomi.com, sbansal@cdotd.ernet.in, sipping@ietf.org To: Mpierce1@aol.com From: Rohan Mahy In-Reply-To: <1d7.bf32160.2c24d398@aol.com> Message-Id: <6CC2599A-A385-11D7-8E0D-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Mike, On Friday, June 20, 2003, at 02:16 PM, Mpierce1@aol.com wrote: > In a message dated 6/20/2003 1:24:06 PM Eastern Standard Time, > rohan@cisco.com writes: > >> If you want >> to offer a service which duplicates the current MLPP experience, then >> I >> suggest that you do everything in the UA except for call forwarding >> unavailable, which obviously you cannot do in the UA if it is not >> there. > > The problem with that is similar to what I think started this > discussion on Call Waiting. For Assured Service (MLPP), the "network" > needs to be able to preempt a call at a UA and play a preemption tone > to the human involved in that call, as far as i've heard, there is no requirement that the "network" do this, merely that the system when taken as a whole allows authorized calls to preempt lower priority calls and play the appropriate tones during preemption. perhaps I am missing a requirement, but I believe this is actually very easy to implement in the user agents. > but there is no quarantee that the particular UA that person is using > would understand what a "preemption tone" is or how to generate it. It > needs to come from someplace else, just like some have suggested for > the Call Waiting tone. I tossed this reference about Assured Service > into the discussion since it is one of many service examples that need > the same thing: a tone (or announcement) stuck into an existing > "connection". > > After all the time spent on this, I would hope that you could point me > (and others) to a clear explanation in an existing document on how to > do it. I wish I could point you at such a document. If there is sufficient interest though we might get one either just before Monday or after Vienna. thanks, -rohan > Mike Pierce _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 22 21:01:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23247 for ; Sun, 22 Jun 2003 21:01:45 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5N11Hg02244 for sipping-archive@odin.ietf.org; Sun, 22 Jun 2003 21:01:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UFht-0000a7-F5 for sipping-web-archive@optimus.ietf.org; Sun, 22 Jun 2003 21:01: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 VAA23241 for ; Sun, 22 Jun 2003 21:01:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UFhq-0006Jw-00 for sipping-web-archive@ietf.org; Sun, 22 Jun 2003 21:01:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UFhl-0006Js-00 for sipping-web-archive@ietf.org; Sun, 22 Jun 2003 21:01:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UFhd-0000Xh-PW; Sun, 22 Jun 2003 21: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 19UFgE-0000Wg-Oq for sipping@optimus.ietf.org; Sun, 22 Jun 2003 21:00: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 UAA23184 for ; Sun, 22 Jun 2003 20:59:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UFg7-0006J5-00 for sipping@ietf.org; Sun, 22 Jun 2003 20:59:27 -0400 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx with esmtp (Exim 4.12) id 19UFfw-0006IM-00 for sipping@ietf.org; Sun, 22 Jun 2003 20:59:16 -0400 Received: by fox.iptel.org (Postfix, from userid 103) id B3023684; Mon, 23 Jun 2003 02:55:55 +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 20F69683; Mon, 23 Jun 2003 02:55:55 +0200 (CEST) Message-Id: <5.2.0.9.0.20030623024635.032ad790@fox.iptel.org> X-Sender: jiri@fox.iptel.org (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 23 Jun 2003 02:53:19 +0200 To: sipping@ietf.org From: Jiri Kuthan Cc: cs@snom.de, henry.sinnreich@mci.com, steven.lass@mci.com, ibutcher@pingtel.com, dpetrie@pingtel.com 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] comments on device 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: , My apologies for commenting with a delay, better now than never: in general I think it is a very useful document, which every SIP phone vendor should read well every morning. There are some items I would prefer to be enhanced, dropped or changed in recommendation strength. -Jiri - NAT traversal capabilities should be complete, that's a very important one. in particular rport and comedia support is missing - DNS/SRV fail-over -- I would suggest you explicitely mention, that SIP phones must be able to use backup server referred to by DNS/SRV servers if they detect unresponsive primary for delivery of any requests - I don't think MWI is a MUST; I get my voicemail messages delivered by e-mail and like that much better - I'm not sure that SIP-17, obeying multiple 18x, should be mandated. I'm not even sure what a proper behaviour would be. Sometimes so many 18x are received that switching between them is quite confusing for caller. - SIP_20, fax support -- I don't buy it as a requirement; I like fax2email better; visit www.efax.com - I would not mandate SIP-22, _per-line_ DnD, either -- that's a matter of taste, I like single-button global DnD better - other thing I would like to have is a "deny" button for incoming calls -- every cell phone has it and very few SIP phones do (I don't really wish john.doe's call to ring to long if I am not interested in a conversation) - sipsec-1 -- I would mention "including qop" which is frequently broken in some implementations - 3.17 "available behaviour" -- I don't think this set of requirement is to be put on phones; phones can go off-line, or their administrative interface can be unreachable -- I think these services are better placed in network -- 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 Jun 23 01:21:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27049 for ; Mon, 23 Jun 2003 01:21:47 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5N5LI624545 for sipping-archive@odin.ietf.org; Mon, 23 Jun 2003 01:21:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UJlW-0006No-Si for sipping-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 01:21: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 BAA27031 for ; Mon, 23 Jun 2003 01:21:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UJlT-0007DW-00 for sipping-web-archive@ietf.org; Mon, 23 Jun 2003 01:21:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UJlO-0007DR-00 for sipping-web-archive@ietf.org; Mon, 23 Jun 2003 01:21:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UJlF-0006MI-EM; Mon, 23 Jun 2003 01: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 19UJl7-0006M2-UB for sipping@optimus.ietf.org; Mon, 23 Jun 2003 01:20: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 BAA27027 for ; Mon, 23 Jun 2003 01:20:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UJl4-0007DN-00 for sipping@ietf.org; Mon, 23 Jun 2003 01:20:51 -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 19UJku-0007DJ-00 for sipping@ietf.org; Mon, 23 Jun 2003 01:20:40 -0400 Received: from txdwillis (12-239-241-155.client.attbi.com [12.239.241.155]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h5N5KDVU001063 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 23 Jun 2003 00:20:14 -0500 From: "Dean Willis" To: Subject: Barge-in (wasRE: [Sipping] Call Waiting - who does the tone (round 2) Date: Mon, 23 Jun 2003 00:20:04 -0500 Message-ID: <001d01c33947$1b534890$b37ba8c0@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 In-Reply-To: <6CC2599A-A385-11D7-8E0D-0003938AF740@cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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'm thinking that the requirement that I'm hearing in this whole = discussion is essentially analogous to the operator service of "barge in." For = those of you unfamiliar with this service, it allows operators with special privileges to intercept the media flow of an existing call and reconnect = it elsewhere. Given that SIP nodes are what they are, it is in general impossible to implement this sort of function without the cooperation of the endpoints involved. To do otherwise would be a violation of the OPES principles, = and probably UNSAF as well. The good news is that this doesn't have any impact on the protocol specification. Such a service can be readily implemented with today's = SIP. It also isn't required in every SIP node -- just in nodes operating in = the sort of regulated environment that "phone people" envision. Or in call centers, or similar operations. There are many possible implementations. For example, the "public = network certified" terminal might be configured to automatically accept = invitations signed by a designated key, and preempt any other session in progress. = The trick, of course, is in the secrity aspects. I don't know whether 3GPP has as-yet addressed this task, but it would = be worth asking people knowledgable about their current work. Can we reframe this conversation from the perspective of requirements = and responsibilities? Service providers (especially providers in regulated environments) may require certain behaviors in network nodes receiving service from those providers.=20 Exactly what are these requirements, and who should specify them? Is = that in the scope of SIPPING? Is it in the scope of the device reuirements individual draft that is under discussion? Do we need to do a formal existence proof or discussion document? Or should it be left to organizations that actually have the regulations to deal with? -- 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 Jun 23 01:39:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27382 for ; Mon, 23 Jun 2003 01:39:21 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5N5crU28853 for sipping-archive@odin.ietf.org; Mon, 23 Jun 2003 01:38:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UK2X-0007VI-By for sipping-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 01:38: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 BAA27360 for ; Mon, 23 Jun 2003 01:38:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UK1l-0007Hd-00 for sipping-web-archive@ietf.org; Mon, 23 Jun 2003 01:38:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UK1f-0007Ha-00 for sipping-web-archive@ietf.org; Mon, 23 Jun 2003 01:37:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UK1h-0007EJ-Pk; Mon, 23 Jun 2003 01: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 19T00S-0002N9-4a for sipping@optimus.ietf.org; Thu, 19 Jun 2003 10:03: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 KAA18834 for ; Thu, 19 Jun 2003 10:03:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Szy9-0004Xf-00 for sipping@ietf.org; Thu, 19 Jun 2003 10:00: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 19Szy7-0004XA-00 for sipping@ietf.org; Thu, 19 Jun 2003 10:00:51 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 19 Jun 2003 07:04:32 -0800 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 h5JE2cIX005323; Thu, 19 Jun 2003 07:02:38 -0700 (PDT) Received: from mhammer-w2k02.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 AEK12754; Thu, 19 Jun 2003 07:02:37 -0700 (PDT) Message-Id: <4.3.2.7.2.20030619095945.00b2cd10@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 19 Jun 2003 10:02:37 -0400 To: Paul Kyzivat From: Michael Hammer Subject: Re: [Sipping] proposed enhancement to dialog package Cc: seancolson@yahoo.com, "'Rosen, Brian'" , hisham.khartabil@nokia.com, jason@azatel.com, rohan@cisco.com, drage@lucent.com, jdrosen@dynamicsoft.com, alan.johnston@wcom.com, sipping@ietf.org In-Reply-To: <3EF0B626.1020500@cisco.com> References: <009101c330fb$3bd894c0$6801a8c0@cranberry> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1409286==_.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: , --=====================_1409286==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Paul, One subtle modification. Extend the hold situation to a conference. When a user hits the hold button, does he put the conference (all the other parties) on hold? Not really. They may still talk to each other. He is really putting himself on hold. Shouldn't the actions that one party takes be a reflection on himself only? E.g., I put myself on hold from the call/conference. I am indicating that I am not attending to media, etc. Mike At 02:57 PM 6/18/2003 -0400, Paul Kyzivat wrote: >Sean Olson wrote: >>For these different experiences at the UA, do you think you need different >>indications in the dialog package? >>Is "passive" enough to cover the variety of possibilities here? (My vote is >>yes) > >There are different possibilities that ought to be reflected uniquely. >Consider a call from A to B: > >- A may be attending to the media from B, and visa versa. >- A is ignoring the media stream from B, and either > sending nothing, sending MoH, progaganda, etc. > Meanwhile B is attending to the media stream from A, > waiting for A to begin attending again. Typically B > is transmitting media, for no particular reason. >- A is ignoring the media stream from B and visa versa. > Each may or may not be sending junk to the other. >- there are a bunch of other permutations, not commonly used. > > From A's perspective these correspond to a=sendrecv, a=sendonly, > a=inactive in the SDP it has provided to B. The 2nd and 3rd both > correspond in some sense to HOLD. > >We don't have great terminology for this. If A pushes the HOLD button on >his phone, then he will say he as put the call on hold and B will say he >has been put on hold. You put someone on hold when you want to cease >attending to the call. If you are put on hold you generally have a social >obligation to continue attending, awaiting the return of the other party. > >My first thought was simply to use the sendrecv/sendonly/recvonly/inactive >indications for this purpose. The advantage is that they are coupled to >signaling and so are easily accessible. But they lack something, because >they don't directly say whether a received stream is being attended to. >Unfortunately that requires information from the application above the >signaling, and possibly from the actual user. > > Paul > > >>-----Original Message----- >>From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Thursday, June >>12, 2003 8:05 AM >>To: 'hisham.khartabil@nokia.com'; jason@azatel.com; rohan@cisco.com; >>seancolson@yahoo.com >>Cc: drage@lucent.com; jdrosen@dynamicsoft.com; alan.johnston@wcom.com; >>sipping@ietf.org >>Subject: RE: [Sipping] proposed enhancement to dialog package >> >>I've always thought that "music on hold" should be local i.e. my choice of >>music for me to listen to, not your choice of music for me to hear. >>Eliminates promotional material also :) >>Brian >> >>>-----Original Message----- >>>From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>>Sent: Thursday, June 12, 2003 10:31 AM >>>To: Brian.Rosen@marconi.com; jason@azatel.com; rohan@cisco.com; >>>seancolson@yahoo.com >>>Cc: drage@lucent.com; jdrosen@dynamicsoft.com; alan.johnston@wcom.com; >>>sipping@ietf.org >>>Subject: RE: [Sipping] proposed enhancement to dialog package >>> >>> >>>Your desire to hold audio may also be greater when you have >>>to pay for audio packets being sent. It might be more interesting for >>>the sender to hold the audio that for the receiver. >>> >>>Hisham >>> >>> >>>>-----Original Message----- >>>>From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] >>>>Sent: Thursday, June 12, 2003 4:16 PM >>>>To: 'Jason Arnold'; Rohan Mahy; Sean Olson >>>>Cc: Drage, Keith (Keith); 'Jonathan Rosenberg'; >>>>alan.johnston@wcom.com; >>>>sipping@ietf.org >>>>Subject: RE: [Sipping] proposed enhancement to dialog package >>>> >>>> >>>>May I add some interesting observational data? >>>>We now have about a year experience with sip videophones that implement >>>>hold. When you are on hold, you see a gray screen that has text >>>>indicating the other party put you on hold. We deliver silence on the >>>>audio channel. >>>> >>>>We have lots and lots of feature requests from users. No one has ever >>>>asked for audio on hold. The visual information is sufficient. >>>> >>>>I suspect that you don't need to be entertained, or >>> >>>pitched. You need >>> >>>>to know what is happening. If your UA tells you you are on hold, then >>>>audio when you are on hold may not be important. >>>> >>>>One caveat; almost everyone uses our videophone handsfree. >>> >>>If you are >>> >>>>holding a handset to your ear, your desire for hold audio may be greater. >>>> >>>>Brian >>>> >>>> >>>>>-----Original Message----- >>>>>From: Jason Arnold [mailto:jason@azatel.com] >>>>>Sent: Wednesday, June 11, 2003 7:21 PM >>>>>To: Rohan Mahy; Sean Olson >>>>>Cc: Drage, Keith (Keith); 'Jonathan Rosenberg'; >>>>>alan.johnston@wcom.com; >>>>>sipping@ietf.org >>>>>Subject: RE: [Sipping] proposed enhancement to dialog package >>>>> >>>>> >>>>>I agree to an extent. >>>>> >>>>>If the hold presents "dead air", most people will feel lost >>>>>with out some >>>>>indication that they are on hold. It would seem that people require the >>>>>assurance that the receiving party has not terminated their call. It >>>>>could >>>>>be assumed that if the hold period is for an extended period of time, only >>>>>presenting silence to the calling party, people may think they have been >>>>>accidentally "disconnected" and terminate their call. >>>>> >>>>>It is important to supply a media stream (even irritating >>>>>propaganda) during >>>>>the hold session. Non-Conformity to current expectations of people >>>>>while on >>>>>hold would seem illogical. >>>>> >>>>>Thanks, >>>>> >>>>>Jason >>>>> >>>>>On Wednesday, June 11, 2003, at 09:40 AM, Sean Olson wrote: >>>>> >>>>> >>>>>>This is an interesting discussion in an almost >>>>>>academic sense, but it really does not address the reality of the >>>>>>very simple service that is being described here. >>>>>> >>>>>>"hold", "passive", whatever else you want to call it means not >>>>>>sending/receiving media. >>>>> >>>>>I disagree. >>>>> >>>>>If you call someone on the average PBX or Key System, and >>>> >>>>ask them to >>>> >>>>>put you on hold, you will typically still receive media >>>>>(music, tones, >>>>>irritating announcements). Likewise, if you call a call >>>center or a >>> >>>>>big store, you are likely to wait "on hold" with some type of >>>>>propaganda, music, or recorded message claiming that you are important. >>>>> >>>>>Clearly the user experience of the user-visible feature >>>> >>>>"Hold" is that >>>> >>>>>hold does not typically equate to "no media". >>>>> >>>>>I believe that from a feature perspective the existence or >>>> >>>>presence of >>>> >>>>>no media being sent/received is irrelevant. It does not affect my >>>>>perception that I am on hold, nor does it affect the >>>> >>>>perception of my >>>> >>>>>peer if I am on hold or not, since I can receive or not >>>> >>>>receive media >>>> >>>>>and still know that I am on hold. >>>>> >>>>>My assertion is that what users really want to know is if the >>>>>other end >>>>>is actively participating. Do they care if I am still around? Is >>>>>there the potential for interaction between me and my peer? >>>>> >>>>>With this concept, I can build useful features that users >>>can relate >>> >>>>>to. For example, I would like "passive" participants >>>(participants >>> >>>>>that cannot interact with me, like inane robots sending me >>>>>Musak) to be >>>>>automatically muted in my conference. >>>>> >>>>>I would like to express this property. If the name >>>"passive" is too >>> >>>>>confusing, then feel free to suggest other terms. >>>"interactivity" >>> >>>>>EQUAL ( "yes" / "no" ) ? >>>>> >>>>>thanks, >>>>>-rohan >>>>> >>>>> >>>>> >>>>>>We've all >>>>>>experienced this. And, yes, this can be independent of the ability to >>>>>>do SIP signaling. >>>>>> >>>>>>I think we are focusing too much on signaling here and not enough on >>>>>>the user experience that is being built. And I certainly don't want a >>>>>>history lesson in ISDN signaling ;-) >>>>>> >>>>>> >>>>>>--- "Drage, Keith (Keith)" wrote: >>>>>> >>>>>>>See below >>>>>>> >>>>>>>regards >>>>>>> >>>>>>>Keith >>>>>>> >>>>>>>Keith Drage >>>>>>>Lucent Technologies >>>>>>>Tel: +44 1793 776249 >>>>>>>Email: drage@lucent.com >>>>>>> >>>>>>> >>>>>>>>-----Original Message----- >>>>>>>>From: Rohan Mahy [mailto:rohan@cisco.com] >>>>>>>>Sent: 10 June 2003 16:25 >>>>>>>>To: Drage, Keith (Keith) >>>>>>>>Cc: 'Jonathan Rosenberg'; alan.johnston@wcom.com; >>>>>>> >>>>>>>'sipping@ietf.org' >>>>>>> >>>>>>>>Subject: Re: [Sipping] proposed enhancement to >>>>>>> >>>>>>>dialog package >>>>>>> >>>>>>>> >>>>>>>>Hi Keith, >>>>>>>> >>>>>>>>Hold as a UI concept significantly predated the >>>>>>> >>>>>>>development of ISDN. >>>>>>> >>>>>>>Agreed, and my initial message identified in that >>>>>>>case (analogue PSTN terminals) that Hold was originally to recall >>>>>>>the register (and there was a manual board equivalent as well) to >>>>>>>allow access resources to be used for signalling, as a result of >>>>>>>that signalling, the access resources might be used >>>>>>>for communication with another party, and only as a >>>>>>>by product of that did it necessarily result in loss >>>>>>>of communication path with the other party. >>>>>>> >>>>>>> >>>>>>>>In any case, an ISDN user (Alice) who requests an >>>>>>> >>>>>>>ISDN hold >>>>>>> >>>>>>>>is still a >>>>>>>>passive participant by my definition. When >>>>>>> >>>>>>>Alice's call is connected >>>>>>> >>>>>>>>to a conference server and all the active >>>>>>> >>>>>>>participants say "ok, we're >>>>>>> >>>>>>>>leaving now, good bye", Alice is not active enough >>>>>>> >>>>>>>to be able to hang >>>>>>> >>>>>>>>up. >>>>>>> >>>>>>>Assuming your last statement still refers to an ISDN user, then I >>>>>>>can think of nothing in the above scenario that prevents Alice >>>>>>>sending a DISCONNECT, and receiving a RELEASE back. Can you clarify. >>>>>>>The DSS1 basic call state machine is totally independent of any >>>>>>>subsidiary state machine relating to >>>>>>>hold/retrieve. >>>>>>> >>>>>>>If you are referring to hanging up the conference bridge resources, >>>>>>>then this is dependent on the concept of ownership, which varies >>>>>>>based on the conference service provided, and also between public >>>>>>>and private networks. >>>>>>> >>>>>>>As a result, I think I am now confused about what >>>>>>>you actually mean by passive, can you elaborate further. >>>>>>> >>>>>>> >>>>>>> >>>>>>>>I agree that whatever we do, we need to describe >>>>>>> >>>>>>>the semantics very >>>>>>> >>>>>>>>crisply. >>>>>>>> >>>>>>>>thanks, >>>>>>>>-rohan >>>>>>>> >>>>>>>> >>>>>>>>On Tuesday, June 10, 2003, at 04:47 AM, Drage, >>>>>>> >>>>>>>Keith (Keith) wrote: >>>>>>> >>>>>>>>>I fail to see how thw property you are proposing >>>>>>>correlates in some >>>>>>> >>>>>>>>>way to any concept of hold. I agree that "hold" >>>>>>>has many meanings, >>>>>>> >>>>>>>>>based on which type of signalling you are using. >>>>>>>>> >>>>>>>>>To clarify, the prime function of hold in the >>>>>>>PSTN was never to >>>>>>> >>>>>>>>>interrupt the communication, that was a side >>>>>>>effect of grabbing the >>>>>>> >>>>>>>>>access resources to signal to another party. >>>>>>>Thus for ISDN, hold >>>>>>> >>>>>>>>>therefore was only a removal of access resources >>>>>>>(the >>>>>>> >>>>>>>>bearer) so that >>>>>>>> >>>>>>>>>that bearer could be reused for another call; >>>>>>>again the side effect >>>>>>> >>>>>>>>>was to interrupt the communication. The sole >>>>>>>function of >>>>>>> >>>>>>>>hold for SIP >>>>>>>> >>>>>>>>>is to interrupt the communication. >>>>>>>>> >>>>>>>>>Certainly, if an ISDN user places another user >>>>>>>on hold, I >>>>>>> >>>>>>>>would regard >>>>>>>> >>>>>>>>>neither user as "passive" as you seem to be >>>>>>>defining here. >>>>>>> >>>>>>>>>If we are going to do this, can we make sure we >>>>>>>define the >>>>>>> >>>>>>>>semantics >>>>>>>> >>>>>>>>>correctly. Otherwise we will surely create >>>>>>>confusion, >>>>>>> >>>>>>>>particularly if >>>>>>>> >>>>>>>>>people try and equate this concept with that of >>>>>>>hold, and in >>>>>>> >>>>>>>>>particular with the PSTN concept. >>>>>>>>> >>>>>>>>>regards >>>>>>>>> >>>>>>>>>Keith >>>>>>>>> >>>>>>>>> >>>>>>>>>Keith Drage >>>>>>>>>Lucent Technologies >>>>>>>>>Tel: +44 1793 776249 >>>>>>>>>Email: drage@lucent.com >>>>>>>>> >>>>>>>>> >>>>>>>>>>-----Original Message----- >>>>>>>>>>From: Rohan Mahy [mailto:rohan@cisco.com] >>>>>>>>>>Sent: 03 June 2003 22:18 >>>>>>>>>>To: 'Jonathan Rosenberg' >>>>>>>>>>Cc: rohan@cisco.com; alan.johnston@wcom.com; >>>>>>>'sipping@ietf.org' >>>>>>> >>>>>>>>>>Subject: [Sipping] proposed enhancement to >>>>>>>dialog package >>>>>>> >>>>>>>>>> >>>>>>>>>>Hi, >>>>>>>>>> >>>>>>>>>>There have been many requests for the dialog >>>>>>>package to express the >>>>>>> >>>>>>>>>>concept of hold. The problem is that nobody had >>>>>>>an especially good >>>>>>> >>>>>>>>>>definition of what "on-hold" meant. Some >>>>>>>suggested that all media >>>>>>> >>>>>>>>>>streams being inactive implied that you are >>>>>>>"held", but >>>>>>> >>>>>>>>this doesn't >>>>>>>> >>>>>>>>>>work for a service such as music-on-hold. >>>>>>>>>> >>>>>>>>>>I believe that folks actually want a slightly >>>>>>>different >>>>>>> >>>>>>>>concept--that >>>>>>>> >>>>>>>>>>the semantics we want instead are already >>>>>>>described in the >>>>>>> >>>>>>>>>>call control >>>>>>>>>>framework: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>Participants may also be active or passive. >>>>>>>Active >>>>>>> >>>>>>>>participants are >>>>>>>> >>>>>>>>>>>expected to be intelligent enough to leave a >>>>>>>conversation >>>>>>> >>>>>>>>>>space when >>>>>>>>>> >>>>>>>>>>>they no longer desire to participate. (An >>>>>>>attentive human >>>>>>> >>>>>>>>>>participant >>>>>>>>>> >>>>>>>>>>>is obviously active.) Some robotic >>>>>>>participants (such as a voice >>>>>>> >>>>>>>>>>>messaging system, an instant messaging agent, >>>>>>>or a voice dialog >>>>>>> >>>>>>>>>>>system) may be active participants if they can >>>>>>>leave the >>>>>>> >>>>>>>>>>conversation >>>>>>>>>> >>>>>>>>>>>space when there is no human interaction. >>>>>>>Other robots >>>>>>> >>>>>>>>(for example >>>>>>>> >>>>>>>>>>>our tone generating robot from the previous >>>>>>>example) are passive >>>>>>> >>>>>>>>>>>participants. A human participant "on-hold" is >>>>>>>passive. >>>>>>> >>>>>>>>>>I think we should add a new attribute to the >>>>>>>dialog package that >>>>>>> >>>>>>>>>>expresses this property. My proposal is to >>>>>>>express this >>>>>>> >>>>>>>>property only >>>>>>>> >>>>>>>>>>for the local side of each dialog by adding an >>>>>>>attribute >>>>>>> >>>>>>>>to the state >>>>>>>> >>>>>>>>>>tag in the dialog-info notification body. The >>>>>>>example below >>>>>>> >>>>>>>>>>includes a >>>>>>>>>>proposed (optional) participation attribute in >>>>>>>the state tag. >>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>xmlns="urn:ietf:params:xml:ns:dialog-info" >>>>>>> >>>>>>>>>> version="3" >>>>>>>>>> state="partial" >>>>>>>>>> entity="sip:caller@bar.com"> >>>>>>=== message truncated === >>>>>> >>>>>> >>>>>>__________________________________ >>>>>>Do you Yahoo!? >>>>>>Yahoo! Calendar - Free online calendar with sync to Outlook(TM). >>>>>>http://calendar.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 >>> >>>_______________________________________________ >>>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>>This list is for NEW development of the application of SIP >>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>Use sip@ietf.org for new developments of core SIP >> >>_______________________________________________ >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>This list is for NEW development of the application of SIP >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sip@ietf.org for new developments of core SIP > > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP --=====================_1409286==_.ALT Content-Type: text/html; charset="us-ascii" Paul,

One subtle modification.  Extend the hold situation to a conference.  When a user hits the hold button, does he put the conference (all the other parties) on hold?  Not really.  They may still talk to each other.  He is really putting himself on hold.  Shouldn't the actions that one party takes be a reflection on himself only?  E.g., I put myself on hold from the call/conference.  I am indicating that I am not attending to media, etc.

Mike


At 02:57 PM 6/18/2003 -0400, Paul Kyzivat wrote:
Sean Olson wrote:
For these different experiences at the UA, do you think you need different
indications in the dialog package?
Is "passive" enough to cover the variety of possibilities here? (My vote is
yes)

There are different possibilities that ought to be reflected uniquely. Consider a call from A to B:

- A may be attending to the media from B, and visa versa.
- A is ignoring the media stream from B, and either
  sending nothing, sending MoH, progaganda, etc.
  Meanwhile B is attending to the media stream from A,
  waiting for A to begin attending again. Typically B
  is transmitting media, for no particular reason.
- A is ignoring the media stream from B and visa versa.
  Each may or may not be sending junk to the other.
- there are a bunch of other permutations, not commonly used.

From A's perspective these correspond to a=sendrecv, a=sendonly, a=inactive in the SDP it has provided to B. The 2nd and 3rd both correspond in some sense to HOLD.

We don't have great terminology for this. If A pushes the HOLD button on his phone, then he will say he as put the call on hold and B will say he has been put on hold. You put someone on hold when you want to cease attending to the call. If you are put on hold you generally have a social obligation to continue attending, awaiting the return of the other party.

My first thought was simply to use the sendrecv/sendonly/recvonly/inactive indications for this purpose. The advantage is that they are coupled to signaling and so are easily accessible. But they lack something, because they don't directly say whether a received stream is being attended to. Unfortunately that requires information from the application above the signaling, and possibly from the actual user.

        Paul


-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Thursday, June 12, 2003 8:05 AM
To: 'hisham.khartabil@nokia.com'; jason@azatel.com; rohan@cisco.com;
seancolson@yahoo.com
Cc: drage@lucent.com; jdrosen@dynamicsoft.com; alan.johnston@wcom.com;
sipping@ietf.org
Subject: RE: [Sipping] proposed enhancement to dialog package

I've always thought that "music on hold" should be local i.e. my choice of
music for me to listen to, not your choice of music for me to hear.
Eliminates promotional material also :)
Brian

-----Original Message-----
From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
Sent: Thursday, June 12, 2003 10:31 AM
To: Brian.Rosen@marconi.com; jason@azatel.com; rohan@cisco.com; seancolson@yahoo.com
Cc: drage@lucent.com; jdrosen@dynamicsoft.com; alan.johnston@wcom.com; sipping@ietf.org
Subject: RE: [Sipping] proposed enhancement to dialog package


Your desire to hold audio may also be greater when you have
to pay for audio packets being sent. It might be more interesting for the sender to hold the audio that for the receiver.

Hisham


-----Original Message-----
From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Thursday, June 12, 2003 4:16 PM
To: 'Jason Arnold'; Rohan Mahy; Sean Olson
Cc: Drage, Keith (Keith); 'Jonathan Rosenberg';
alan.johnston@wcom.com;
sipping@ietf.org
Subject: RE: [Sipping] proposed enhancement to dialog package


May I add some interesting observational data?
We now have about a year experience with sip videophones that implement hold.  When you are on hold, you see a gray screen that has text indicating the other party put you on hold.  We deliver silence on the audio channel.

We have lots and lots of feature requests from users.  No one has ever asked for audio on hold.  The visual information is sufficient.

I suspect that you don't need to be entertained, or

pitched.  You need

to know what is happening.  If your UA tells you you are on hold, then audio when you are on hold may not be important.

One caveat; almost everyone uses our videophone handsfree.

If you are

holding a handset to your ear, your desire for hold audio may be greater.

Brian


-----Original Message-----
From: Jason Arnold [mailto:jason@azatel.com]
Sent: Wednesday, June 11, 2003 7:21 PM
To: Rohan Mahy; Sean Olson
Cc: Drage, Keith (Keith); 'Jonathan Rosenberg';
alan.johnston@wcom.com;
sipping@ietf.org
Subject: RE: [Sipping] proposed enhancement to dialog package


I agree to an extent.

If the hold presents "dead air", most people will feel lost
with out some
indication that they are on hold.  It would seem that people require the
assurance that the receiving party has not terminated their call.  It could
be assumed that if the hold period is for an extended period of time, only
presenting silence to the calling party, people may think they have been
accidentally "disconnected" and terminate their call.

It is important to supply a media stream (even irritating
propaganda) during
the hold session.  Non-Conformity to current expectations of people while on
hold would seem illogical.

Thanks,

Jason

On Wednesday, June 11, 2003, at 09:40 AM, Sean Olson wrote:


This is an interesting discussion in an almost
academic sense, but it really does not address the reality of the very simple service that is being described here.

"hold", "passive", whatever else you want to call it means not sending/receiving media.

I disagree.

If you call someone on the average PBX or Key System, and

ask them to

put you on hold, you will typically still receive media
(music, tones,
irritating announcements).  Likewise, if you call a call
center or a

big store, you are likely to wait "on hold" with some type of propaganda, music, or recorded message claiming that you are important.

Clearly the user experience of the user-visible feature

"Hold" is that

hold does not typically equate to "no media".

I believe that from a feature perspective the existence or

presence of

no media being sent/received is irrelevant.  It does not affect my perception that I am on hold, nor does it affect the

perception of my

peer if I am on hold or not, since I can receive or not

receive media

and still know that I am on hold.

My assertion is that what users really want to know is if the
other end
is actively participating.  Do they care if I am still around?  Is
there the potential for interaction between me and my peer?

With this concept, I can build useful features that users
can relate

to.  For example,  I would like "passive" participants
(participants

that cannot interact with me, like inane robots sending me
Musak) to be
automatically muted in my conference.

I would like to express this property. If the name
"passive" is too

confusing, then feel free to suggest other terms.  
"interactivity"

EQUAL ( "yes" / "no" ) ?

thanks,
-rohan



We've all
experienced this. And, yes, this can be independent of the ability to do SIP signaling.

I think we are focusing too much on signaling here and not enough on the user experience that is being built. And I certainly don't want a history lesson in ISDN signaling ;-)


--- "Drage, Keith (Keith)" <drage@lucent.com> wrote:

See below

regards

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: drage@lucent.com


-----Original Message-----
From: Rohan Mahy [mailto:rohan@cisco.com]
Sent: 10 June 2003 16:25
To: Drage, Keith (Keith)
Cc: 'Jonathan Rosenberg'; alan.johnston@wcom.com;

'sipping@ietf.org'

Subject: Re: [Sipping] proposed enhancement to

dialog package


Hi Keith,

Hold as a UI concept significantly predated the

development of ISDN.

Agreed, and my initial message identified in that
case (analogue PSTN terminals) that Hold was originally to recall the register (and there was a manual board equivalent as well) to allow access resources to be used for signalling, as a result of that signalling, the access resources might be used
for communication with another party, and only as a
by product of that did it necessarily result in loss
of communication path with the other party.


In any case, an ISDN user (Alice) who requests an

ISDN hold

is still a
passive participant by my definition.  When

Alice's call is connected

to a conference server and all the active

participants say "ok, we're

leaving now, good bye", Alice is not active enough

to be able to hang

up.

Assuming your last statement still refers to an ISDN user, then I can think of nothing in the above scenario that prevents Alice sending a DISCONNECT, and receiving a RELEASE back. Can you clarify. The DSS1 basic call state machine is totally independent of any subsidiary state machine relating to
hold/retrieve.

If you are referring to hanging up the conference bridge resources, then this is dependent on the concept of ownership, which varies based on the conference service provided, and also between public and private networks.

As a result, I think I am now confused about what
you actually mean by passive, can you elaborate further.



I agree that whatever we do, we need to describe

the semantics very

crisply.

thanks,
-rohan


On Tuesday, June 10, 2003, at 04:47 AM, Drage,

Keith (Keith) wrote:

I fail to see how thw property you are proposing
correlates in some

way to any concept of hold. I agree that "hold"
has many meanings,

based on which type of signalling you are using.

To clarify, the prime function of hold in the
PSTN was never to

interrupt the communication, that was a side
effect of grabbing the

access resources to signal to another party.
Thus for ISDN, hold

therefore was only a removal of access resources
(the

bearer) so that

that bearer could be reused for another call;
again the side effect

was to interrupt the communication. The sole
function of

hold for SIP

is to interrupt the communication.

Certainly, if an ISDN user places another user
on hold, I

would regard

neither user as "passive" as you seem to be
defining here.

If we are going to do this, can we make sure we
define the

semantics

correctly. Otherwise we will surely create
confusion,

particularly if

people try and equate this concept with that of
hold, and in

particular with the PSTN concept.

regards

Keith


Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: drage@lucent.com


-----Original Message-----
From: Rohan Mahy [mailto:rohan@cisco.com]
Sent: 03 June 2003 22:18
To: 'Jonathan Rosenberg'
Cc: rohan@cisco.com; alan.johnston@wcom.com;
'sipping@ietf.org'

Subject: [Sipping] proposed enhancement to
dialog package


Hi,

There have been many requests for the dialog
package to express the

concept of hold. The problem is that nobody had
an especially good

definition of what "on-hold" meant.  Some
suggested that all media

streams being inactive implied that you are
"held", but

this doesn't

work for a service such as music-on-hold.

I believe that folks actually want a slightly
different

concept--that

the semantics we want instead are already
described in the

call control
framework:


Participants may also be active or passive.
Active

participants are

expected to be intelligent enough to leave a
conversation

space when

they no longer desire to participate. (An
attentive human

participant

is obviously active.) Some robotic
participants (such as a voice

messaging system, an instant messaging agent,
or a voice dialog

system) may be active participants if they can
leave the

conversation

space when there is no human interaction.
Other robots

(for example

our tone generating robot from the previous
example) are passive

participants. A human participant "on-hold" is
passive.

I think we should add a new attribute to the
dialog package that

expresses this property. My proposal is to
express this

property only

for the local side of each dialog by adding an
attribute

to the state

tag in the dialog-info notification body.  The
example below

includes a
proposed (optional) participation attribute in
the state tag.

   <?xml version="1.0"?>
   <dialog-info
xmlns="urn:ietf:params:xml:ns:dialog-info"

                version="3"
                state="partial"
                entity="sip:caller@bar.com">
=== message truncated ===


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.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

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

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


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP
--=====================_1409286==_.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 Jun 23 01:39:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27388 for ; Mon, 23 Jun 2003 01:39:22 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5N5csX28870 for sipping-archive@odin.ietf.org; Mon, 23 Jun 2003 01:38:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UK2X-0007VZ-VW for sipping-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 01:38: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 BAA27363 for ; Mon, 23 Jun 2003 01:38:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UK1l-0007Hh-00 for sipping-web-archive@ietf.org; Mon, 23 Jun 2003 01:38:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UK1g-0007He-00 for sipping-web-archive@ietf.org; Mon, 23 Jun 2003 01:38:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UK1i-0007FI-Kp; Mon, 23 Jun 2003 01:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T0tw-0005mC-6z for sipping@optimus.ietf.org; Thu, 19 Jun 2003 11:00: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 LAA23137 for ; Thu, 19 Jun 2003 11:00:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T0rc-0005CR-00 for sipping@ietf.org; Thu, 19 Jun 2003 10:58:12 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19T0rb-0005B9-00 for sipping@ietf.org; Thu, 19 Jun 2003 10:58:11 -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 h5JExkO1006047; Thu, 19 Jun 2003 10:59:47 -0400 (EDT) Received: from cisco.com ([161.44.79.70]) by cannon.cisco.com (Mirapoint) with ESMTP id ABL35299; Thu, 19 Jun 2003 11:08:43 -0400 (EDT) Message-ID: <3EF1CFE1.1020105@cisco.com> Date: Thu, 19 Jun 2003 10:59:45 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Hammer CC: seancolson@yahoo.com, "'Rosen, Brian'" , hisham.khartabil@nokia.com, jason@azatel.com, rohan@cisco.com, drage@lucent.com, jdrosen@dynamicsoft.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> 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 Michael Hammer wrote: > Paul, > > One subtle modification. Extend the hold situation to a conference. > When a user hits the hold button, does he put the conference (all the > other parties) on hold? Not really. They may still talk to each > other. He is really putting himself on hold. Shouldn't the actions > that one party takes be a reflection on himself only? E.g., I put > myself on hold from the call/conference. I am indicating that I am not > attending to media, etc. I don't think anything I said is inconsistent with the point you are making. I suppose the following is the part you are concerned with: >> If A pushes the HOLD button >> on his phone, then he will say he as put the call on hold and B will >> say he has been put on hold. Perhaps that should be elaborated to say: ... and B will say he has been put on hold by A. ^^^^ This is something that is done by A. B *is* affected, but it doesn't prevent B from doing other things. 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. The two choices seem to be to report this property on a per-media-stream basis, or else to leave it to the UA to figure out on a per-dialog basis. (One possibility would be to consider the UA to be participating if at least one of its media streams is attended.) Paul >> You put someone on hold when you want to >> cease attending to the call. If you are put on hold you generally have >> a social obligation to continue attending, awaiting the return of the >> other party. > > Mike > > > At 02:57 PM 6/18/2003 -0400, Paul Kyzivat wrote: > >> Sean Olson wrote: >> >>> For these different experiences at the UA, do you think you need >>> different >>> indications in the dialog package? >>> Is "passive" enough to cover the variety of possibilities here? (My >>> vote is >>> yes) >> >> >> There are different possibilities that ought to be reflected uniquely. >> Consider a call from A to B: >> >> - A may be attending to the media from B, and visa versa. >> - A is ignoring the media stream from B, and either >> sending nothing, sending MoH, progaganda, etc. >> Meanwhile B is attending to the media stream from A, >> waiting for A to begin attending again. Typically B >> is transmitting media, for no particular reason. >> - A is ignoring the media stream from B and visa versa. >> Each may or may not be sending junk to the other. >> - there are a bunch of other permutations, not commonly used. >> >> From A's perspective these correspond to a=sendrecv, a=sendonly, >> a=inactive in the SDP it has provided to B. The 2nd and 3rd both >> correspond in some sense to HOLD. >> >> We don't have great terminology for this. If A pushes the HOLD button >> on his phone, then he will say he as put the call on hold and B will >> say he has been put on hold. You put someone on hold when you want to >> cease attending to the call. If you are put on hold you generally have >> a social obligation to continue attending, awaiting the return of the >> other party. >> >> My first thought was simply to use the >> sendrecv/sendonly/recvonly/inactive indications for this purpose. The >> advantage is that they are coupled to signaling and so are easily >> accessible. But they lack something, because they don't directly say >> whether a received stream is being attended to. Unfortunately that >> requires information from the application above the signaling, and >> possibly from the actual user. >> >> Paul >> >> >>> -----Original Message----- >>> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Thursday, >>> June 12, 2003 8:05 AM >>> To: 'hisham.khartabil@nokia.com'; jason@azatel.com; rohan@cisco.com; >>> seancolson@yahoo.com >>> Cc: drage@lucent.com; jdrosen@dynamicsoft.com; alan.johnston@wcom.com; >>> sipping@ietf.org >>> Subject: RE: [Sipping] proposed enhancement to dialog package >>> >>> I've always thought that "music on hold" should be local i.e. my >>> choice of >>> music for me to listen to, not your choice of music for me to hear. >>> Eliminates promotional material also :) >>> Brian >>> >>>> -----Original Message----- >>>> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>>> Sent: Thursday, June 12, 2003 10:31 AM >>>> To: Brian.Rosen@marconi.com; jason@azatel.com; rohan@cisco.com; >>>> seancolson@yahoo.com >>>> Cc: drage@lucent.com; jdrosen@dynamicsoft.com; >>>> alan.johnston@wcom.com; sipping@ietf.org >>>> Subject: RE: [Sipping] proposed enhancement to dialog package >>>> >>>> >>>> Your desire to hold audio may also be greater when you have >>>> to pay for audio packets being sent. It might be more interesting >>>> for the sender to hold the audio that for the receiver. >>>> >>>> Hisham >>>> >>>> >>>>> -----Original Message----- >>>>> From: ext Rosen, Brian [mailto:Brian.Rosen@marconi.com] >>>>> Sent: Thursday, June 12, 2003 4:16 PM >>>>> To: 'Jason Arnold'; Rohan Mahy; Sean Olson >>>>> Cc: Drage, Keith (Keith); 'Jonathan Rosenberg'; >>>>> alan.johnston@wcom.com; >>>>> sipping@ietf.org >>>>> Subject: RE: [Sipping] proposed enhancement to dialog package >>>>> >>>>> >>>>> May I add some interesting observational data? >>>>> We now have about a year experience with sip videophones that >>>>> implement hold. When you are on hold, you see a gray screen that >>>>> has text indicating the other party put you on hold. We deliver >>>>> silence on the audio channel. >>>>> >>>>> We have lots and lots of feature requests from users. No one has >>>>> ever asked for audio on hold. The visual information is sufficient. >>>>> >>>>> I suspect that you don't need to be entertained, or >>>> >>>> >>>> pitched. You need >>>> >>>>> to know what is happening. If your UA tells you you are on hold, >>>>> then audio when you are on hold may not be important. >>>>> >>>>> One caveat; almost everyone uses our videophone handsfree. >>>> >>>> >>>> If you are >>>> >>>>> holding a handset to your ear, your desire for hold audio may be >>>>> greater. >>>>> >>>>> Brian >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Jason Arnold [mailto:jason@azatel.com] >>>>>> Sent: Wednesday, June 11, 2003 7:21 PM >>>>>> To: Rohan Mahy; Sean Olson >>>>>> Cc: Drage, Keith (Keith); 'Jonathan Rosenberg'; >>>>>> alan.johnston@wcom.com; >>>>>> sipping@ietf.org >>>>>> Subject: RE: [Sipping] proposed enhancement to dialog package >>>>>> >>>>>> >>>>>> I agree to an extent. >>>>>> >>>>>> If the hold presents "dead air", most people will feel lost >>>>>> with out some >>>>>> indication that they are on hold. It would seem that people >>>>>> require the >>>>>> assurance that the receiving party has not terminated their call. >>>>>> It could >>>>>> be assumed that if the hold period is for an extended period of >>>>>> time, only >>>>>> presenting silence to the calling party, people may think they >>>>>> have been >>>>>> accidentally "disconnected" and terminate their call. >>>>>> >>>>>> It is important to supply a media stream (even irritating >>>>>> propaganda) during >>>>>> the hold session. Non-Conformity to current expectations of >>>>>> people while on >>>>>> hold would seem illogical. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jason >>>>>> >>>>>> On Wednesday, June 11, 2003, at 09:40 AM, Sean Olson wrote: >>>>>> >>>>>> >>>>>>> This is an interesting discussion in an almost >>>>>>> academic sense, but it really does not address the reality of the >>>>>>> very simple service that is being described here. >>>>>>> >>>>>>> "hold", "passive", whatever else you want to call it means not >>>>>>> sending/receiving media. >>>>>> >>>>>> >>>>>> I disagree. >>>>>> >>>>>> If you call someone on the average PBX or Key System, and >>>>> >>>>> >>>>> ask them to >>>>> >>>>>> put you on hold, you will typically still receive media >>>>>> (music, tones, >>>>>> irritating announcements). Likewise, if you call a call >>>>> >>>> center or a >>>> >>>>>> big store, you are likely to wait "on hold" with some type of >>>>>> propaganda, music, or recorded message claiming that you are >>>>>> important. >>>>>> >>>>>> Clearly the user experience of the user-visible feature >>>>> >>>>> >>>>> "Hold" is that >>>>> >>>>>> hold does not typically equate to "no media". >>>>>> >>>>>> I believe that from a feature perspective the existence or >>>>> >>>>> >>>>> presence of >>>>> >>>>>> no media being sent/received is irrelevant. It does not affect my >>>>>> perception that I am on hold, nor does it affect the >>>>> >>>>> >>>>> perception of my >>>>> >>>>>> peer if I am on hold or not, since I can receive or not >>>>> >>>>> >>>>> receive media >>>>> >>>>>> and still know that I am on hold. >>>>>> >>>>>> My assertion is that what users really want to know is if the >>>>>> other end >>>>>> is actively participating. Do they care if I am still around? Is >>>>>> there the potential for interaction between me and my peer? >>>>>> >>>>>> With this concept, I can build useful features that users >>>>> >>>> can relate >>>> >>>>>> to. For example, I would like "passive" participants >>>>> >>>> (participants >>>> >>>>>> that cannot interact with me, like inane robots sending me >>>>>> Musak) to be >>>>>> automatically muted in my conference. >>>>>> >>>>>> I would like to express this property. If the name >>>>> >>>> "passive" is too >>>> >>>>>> confusing, then feel free to suggest other terms. >>>>> >>>> "interactivity" >>>> >>>>>> EQUAL ( "yes" / "no" ) ? >>>>>> >>>>>> thanks, >>>>>> -rohan >>>>>> >>>>>> >>>>>> >>>>>>> We've all >>>>>>> experienced this. And, yes, this can be independent of the >>>>>>> ability to do SIP signaling. >>>>>>> >>>>>>> I think we are focusing too much on signaling here and not enough >>>>>>> on the user experience that is being built. And I certainly don't >>>>>>> want a history lesson in ISDN signaling ;-) >>>>>>> >>>>>>> >>>>>>> --- "Drage, Keith (Keith)" wrote: >>>>>>> >>>>>>>> See below >>>>>>>> >>>>>>>> regards >>>>>>>> >>>>>>>> Keith >>>>>>>> >>>>>>>> Keith Drage >>>>>>>> Lucent Technologies >>>>>>>> Tel: +44 1793 776249 >>>>>>>> Email: drage@lucent.com >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Rohan Mahy [mailto:rohan@cisco.com] >>>>>>>>> Sent: 10 June 2003 16:25 >>>>>>>>> To: Drage, Keith (Keith) >>>>>>>>> Cc: 'Jonathan Rosenberg'; alan.johnston@wcom.com; >>>>>>>> >>>>>>>> >>>>>>>> 'sipping@ietf.org' >>>>>>>> >>>>>>>>> Subject: Re: [Sipping] proposed enhancement to >>>>>>>> >>>>>>>> >>>>>>>> dialog package >>>>>>>> >>>>>>>>> >>>>>>>>> Hi Keith, >>>>>>>>> >>>>>>>>> Hold as a UI concept significantly predated the >>>>>>>> >>>>>>>> >>>>>>>> development of ISDN. >>>>>>>> >>>>>>>> Agreed, and my initial message identified in that >>>>>>>> case (analogue PSTN terminals) that Hold was originally to >>>>>>>> recall the register (and there was a manual board equivalent as >>>>>>>> well) to allow access resources to be used for signalling, as a >>>>>>>> result of that signalling, the access resources might be used >>>>>>>> for communication with another party, and only as a >>>>>>>> by product of that did it necessarily result in loss >>>>>>>> of communication path with the other party. >>>>>>>> >>>>>>>> >>>>>>>>> In any case, an ISDN user (Alice) who requests an >>>>>>>> >>>>>>>> >>>>>>>> ISDN hold >>>>>>>> >>>>>>>>> is still a >>>>>>>>> passive participant by my definition. When >>>>>>>> >>>>>>>> >>>>>>>> Alice's call is connected >>>>>>>> >>>>>>>>> to a conference server and all the active >>>>>>>> >>>>>>>> >>>>>>>> participants say "ok, we're >>>>>>>> >>>>>>>>> leaving now, good bye", Alice is not active enough >>>>>>>> >>>>>>>> >>>>>>>> to be able to hang >>>>>>>> >>>>>>>>> up. >>>>>>>> >>>>>>>> >>>>>>>> Assuming your last statement still refers to an ISDN user, then >>>>>>>> I can think of nothing in the above scenario that prevents Alice >>>>>>>> sending a DISCONNECT, and receiving a RELEASE back. Can you >>>>>>>> clarify. The DSS1 basic call state machine is totally >>>>>>>> independent of any subsidiary state machine relating to >>>>>>>> hold/retrieve. >>>>>>>> >>>>>>>> If you are referring to hanging up the conference bridge >>>>>>>> resources, then this is dependent on the concept of ownership, >>>>>>>> which varies based on the conference service provided, and also >>>>>>>> between public and private networks. >>>>>>>> >>>>>>>> As a result, I think I am now confused about what >>>>>>>> you actually mean by passive, can you elaborate further. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> I agree that whatever we do, we need to describe >>>>>>>> >>>>>>>> >>>>>>>> the semantics very >>>>>>>> >>>>>>>>> crisply. >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> -rohan >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tuesday, June 10, 2003, at 04:47 AM, Drage, >>>>>>>> >>>>>>>> >>>>>>>> Keith (Keith) wrote: >>>>>>>> >>>>>>>>>> I fail to see how thw property you are proposing >>>>>>>>> >>>>>>>> correlates in some >>>>>>>> >>>>>>>>>> way to any concept of hold. I agree that "hold" >>>>>>>>> >>>>>>>> has many meanings, >>>>>>>> >>>>>>>>>> based on which type of signalling you are using. >>>>>>>>>> >>>>>>>>>> To clarify, the prime function of hold in the >>>>>>>>> >>>>>>>> PSTN was never to >>>>>>>> >>>>>>>>>> interrupt the communication, that was a side >>>>>>>>> >>>>>>>> effect of grabbing the >>>>>>>> >>>>>>>>>> access resources to signal to another party. >>>>>>>>> >>>>>>>> Thus for ISDN, hold >>>>>>>> >>>>>>>>>> therefore was only a removal of access resources >>>>>>>>> >>>>>>>> (the >>>>>>>> >>>>>>>>> bearer) so that >>>>>>>>> >>>>>>>>>> that bearer could be reused for another call; >>>>>>>>> >>>>>>>> again the side effect >>>>>>>> >>>>>>>>>> was to interrupt the communication. The sole >>>>>>>>> >>>>>>>> function of >>>>>>>> >>>>>>>>> hold for SIP >>>>>>>>> >>>>>>>>>> is to interrupt the communication. >>>>>>>>>> >>>>>>>>>> Certainly, if an ISDN user places another user >>>>>>>>> >>>>>>>> on hold, I >>>>>>>> >>>>>>>>> would regard >>>>>>>>> >>>>>>>>>> neither user as "passive" as you seem to be >>>>>>>>> >>>>>>>> defining here. >>>>>>>> >>>>>>>>>> If we are going to do this, can we make sure we >>>>>>>>> >>>>>>>> define the >>>>>>>> >>>>>>>>> semantics >>>>>>>>> >>>>>>>>>> correctly. Otherwise we will surely create >>>>>>>>> >>>>>>>> confusion, >>>>>>>> >>>>>>>>> particularly if >>>>>>>>> >>>>>>>>>> people try and equate this concept with that of >>>>>>>>> >>>>>>>> hold, and in >>>>>>>> >>>>>>>>>> particular with the PSTN concept. >>>>>>>>>> >>>>>>>>>> regards >>>>>>>>>> >>>>>>>>>> Keith >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Keith Drage >>>>>>>>>> Lucent Technologies >>>>>>>>>> Tel: +44 1793 776249 >>>>>>>>>> Email: drage@lucent.com >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Rohan Mahy [mailto:rohan@cisco.com] >>>>>>>>>>> Sent: 03 June 2003 22:18 >>>>>>>>>>> To: 'Jonathan Rosenberg' >>>>>>>>>>> Cc: rohan@cisco.com; alan.johnston@wcom.com; >>>>>>>>>> >>>>>>>> 'sipping@ietf.org' >>>>>>>> >>>>>>>>>>> Subject: [Sipping] proposed enhancement to >>>>>>>>>> >>>>>>>> dialog package >>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> There have been many requests for the dialog >>>>>>>>>> >>>>>>>> package to express the >>>>>>>> >>>>>>>>>>> concept of hold. The problem is that nobody had >>>>>>>>>> >>>>>>>> an especially good >>>>>>>> >>>>>>>>>>> definition of what "on-hold" meant. Some >>>>>>>>>> >>>>>>>> suggested that all media >>>>>>>> >>>>>>>>>>> streams being inactive implied that you are >>>>>>>>>> >>>>>>>> "held", but >>>>>>>> >>>>>>>>> this doesn't >>>>>>>>> >>>>>>>>>>> work for a service such as music-on-hold. >>>>>>>>>>> >>>>>>>>>>> I believe that folks actually want a slightly >>>>>>>>>> >>>>>>>> different >>>>>>>> >>>>>>>>> concept--that >>>>>>>>> >>>>>>>>>>> the semantics we want instead are already >>>>>>>>>> >>>>>>>> described in the >>>>>>>> >>>>>>>>>>> call control >>>>>>>>>>> framework: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Participants may also be active or passive. >>>>>>>>>>> >>>>>>>> Active >>>>>>>> >>>>>>>>> participants are >>>>>>>>> >>>>>>>>>>>> expected to be intelligent enough to leave a >>>>>>>>>>> >>>>>>>> conversation >>>>>>>> >>>>>>>>>>> space when >>>>>>>>>>> >>>>>>>>>>>> they no longer desire to participate. (An >>>>>>>>>>> >>>>>>>> attentive human >>>>>>>> >>>>>>>>>>> participant >>>>>>>>>>> >>>>>>>>>>>> is obviously active.) Some robotic >>>>>>>>>>> >>>>>>>> participants (such as a voice >>>>>>>> >>>>>>>>>>>> messaging system, an instant messaging agent, >>>>>>>>>>> >>>>>>>> or a voice dialog >>>>>>>> >>>>>>>>>>>> system) may be active participants if they can >>>>>>>>>>> >>>>>>>> leave the >>>>>>>> >>>>>>>>>>> conversation >>>>>>>>>>> >>>>>>>>>>>> space when there is no human interaction. >>>>>>>>>>> >>>>>>>> Other robots >>>>>>>> >>>>>>>>> (for example >>>>>>>>> >>>>>>>>>>>> our tone generating robot from the previous >>>>>>>>>>> >>>>>>>> example) are passive >>>>>>>> >>>>>>>>>>>> participants. A human participant "on-hold" is >>>>>>>>>>> >>>>>>>> passive. >>>>>>>> >>>>>>>>>>> I think we should add a new attribute to the >>>>>>>>>> >>>>>>>> dialog package that >>>>>>>> >>>>>>>>>>> expresses this property. My proposal is to >>>>>>>>>> >>>>>>>> express this >>>>>>>> >>>>>>>>> property only >>>>>>>>> >>>>>>>>>>> for the local side of each dialog by adding an >>>>>>>>>> >>>>>>>> attribute >>>>>>>> >>>>>>>>> to the state >>>>>>>>> >>>>>>>>>>> tag in the dialog-info notification body. The >>>>>>>>>> >>>>>>>> example below >>>>>>>> >>>>>>>>>>> includes a >>>>>>>>>>> proposed (optional) participation attribute in >>>>>>>>>> >>>>>>>> the state tag. >>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>> xmlns="urn:ietf:params:xml:ns:dialog-info" >>>>>>>> >>>>>>>>>>> version="3" >>>>>>>>>>> state="partial" >>>>>>>>>>> entity="sip:caller@bar.com"> >>>>>>>>>> >>>>>>> === message truncated === >>>>>>> >>>>>>> >>>>>>> __________________________________ >>>>>>> Do you Yahoo!? >>>>>>> Yahoo! Calendar - Free online calendar with sync to Outlook(TM). >>>>>>> http://calendar.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 >>>> >>>> >>>> _______________________________________________ >>>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>>> This list is for NEW development of the application of SIP >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sip@ietf.org for new developments of core SIP >>> >>> >>> _______________________________________________ >>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>> This list is for NEW development of the application of SIP >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sip@ietf.org for new developments of core SIP >> >> >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 23 01:50:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27716 for ; Mon, 23 Jun 2003 01:50:37 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5N5o9331183 for sipping-archive@odin.ietf.org; Mon, 23 Jun 2003 01:50:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UKDR-00086s-9D for sipping-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 01:50: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 BAA27691 for ; Mon, 23 Jun 2003 01:50:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UKDO-0007Mp-00 for sipping-web-archive@ietf.org; Mon, 23 Jun 2003 01:50:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UKDI-0007Mm-00 for sipping-web-archive@ietf.org; Mon, 23 Jun 2003 01:50:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UKDJ-00080q-R7; Mon, 23 Jun 2003 01: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 19UKCd-0007yI-5r for sipping@optimus.ietf.org; Mon, 23 Jun 2003 01:49: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 BAA27665 for ; Mon, 23 Jun 2003 01:49:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UKCZ-0007MD-00 for sipping@ietf.org; Mon, 23 Jun 2003 01:49:16 -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 19UKCP-0007Lx-00 for sipping@ietf.org; Mon, 23 Jun 2003 01:49:05 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 22 Jun 2003 22:51:34 -0800 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 h5N5mTgE029522 for ; Sun, 22 Jun 2003 22:48: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.3-GR) with ESMTP id AIK00887; Sun, 22 Jun 2003 22:41:49 -0700 (PDT) Date: Sun, 22 Jun 2003 22:49:47 -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: <7F9D6ACC-A53E-11D7-8E0D-0003938AF740@cisco.com> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Sipping] New Tones draft (was: "who plays the tone" or something like that) Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I 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 From exim@www1.ietf.org Mon Jun 23 03:59:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12173 for ; Mon, 23 Jun 2003 03:59:39 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5N7xAB24624 for sipping-archive@odin.ietf.org; Mon, 23 Jun 2003 03:59:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UMEI-0006P5-Kp for sipping-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 03:59: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 DAA12156 for ; Mon, 23 Jun 2003 03:59:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UMEG-0000QH-00 for sipping-web-archive@ietf.org; Mon, 23 Jun 2003 03:59:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UMEA-0000QE-00 for sipping-web-archive@ietf.org; Mon, 23 Jun 2003 03:59:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UMEA-0006M5-L3; Mon, 23 Jun 2003 03:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UMDg-0006Ln-5z for sipping@optimus.ietf.org; Mon, 23 Jun 2003 03:58: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 DAA12142 for ; Mon, 23 Jun 2003 03:58:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UMDd-0000Po-00 for sipping@ietf.org; Mon, 23 Jun 2003 03:58:29 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19UMDS-0000PG-00 for sipping@ietf.org; Mon, 23 Jun 2003 03:58:18 -0400 Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5N7vXcv004387; Mon, 23 Jun 2003 09:57:33 +0200 Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYQ860Z; Mon, 23 Jun 2003 09:58:21 +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 h5N7uKSZ005960; Mon, 23 Jun 2003 10:56:20 +0300 (EET DST) Message-ID: <3EF6B2B4.8628DF94@lmf.ericsson.se> Date: Mon, 23 Jun 2003 10:56:36 +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: sipping CC: Rohan Mahy , Dean Willis References: <3EF069D9.441CA13@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Agenda requests - making my life easier Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk 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, when you send me an agenda request, if instead of saying: "I will be presenting a couple of drafts that I submitted some days ago" you say: "I will be needing a 5 minute time slot to talk about the draft below", and you provide a link to the draft, my life will be much easier ;o) Please, state the *time* you think you need and provide *links* to the material you want people to read. Thanks, Gonzalo Gonzalo Camarillo wrote: > > Folks, > > you can start sending us your agenda requests for Vienna. We will keep > track of them at: > > http://www.softarmor.com/sipping/meets/ietf57/requests.html > > We will try to acknowledge your emails as we get them, but, in any > event, please make sure that your request shows up in the web site > above. > > Don't forget to send us your estimation for the length of time slot(s) > you request. > > 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 Mon Jun 23 05:03:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13348 for ; Mon, 23 Jun 2003 05:03:17 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5N92oT32173 for sipping-archive@odin.ietf.org; Mon, 23 Jun 2003 05:02:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UNDu-0008Mq-1C for sipping-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 05: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 FAA13333 for ; Mon, 23 Jun 2003 05:02:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UNDq-0000i5-00 for sipping-web-archive@ietf.org; Mon, 23 Jun 2003 05:02:46 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UNDl-0000i2-00 for sipping-web-archive@ietf.org; Mon, 23 Jun 2003 05:02:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UND7-0008EY-61; Mon, 23 Jun 2003 05: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 19UNBB-0008BY-D3 for sipping@optimus.ietf.org; Mon, 23 Jun 2003 05:01: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 EAA13284 for ; Mon, 23 Jun 2003 04:59:58 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UNB8-0000hB-00 for sipping@ietf.org; Mon, 23 Jun 2003 04:59:58 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19UNAx-0000h0-00 for sipping@ietf.org; Mon, 23 Jun 2003 04:59:47 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5N8wQ912634 for ; Mon, 23 Jun 2003 11:58:27 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 23 Jun 2003 11:58:26 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 23 Jun 2003 11:58:26 +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] Call Waiting - who does the tone (round 2) Date: Mon, 23 Jun 2003 11:58:25 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701796E14@esebe019.ntc.nokia.com> Thread-Topic: [Sipping] Call Waiting - who does the tone (round 2) Thread-Index: AcM3Nm5/5VpoqfJFR16mN8qqDNa1IQCLqrCA To: , , Cc: , , , X-OriginalArrivalTime: 23 Jun 2003 08:58:26.0073 (UTC) FILETIME=[9B8D8890:01C33965] 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 A call stateful proxy can decide to forward or not to forward an INVITE = to a UA that is already in another call. The decision can be based on = anything including charging ( a user has payed for call forwarding). If = the proxy decides to forward the INVITE, it is the UA that plays the = tone when it receives the INVITE. Network controls the service, UA DOES the tone. Did I miss anything? /Hisham -----Original Message----- From: ext Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: Friday, June 20, 2003 5:13 PM To: rohan@cisco.com; dmudric@leapstone.com Cc: Brian.Rosen@marconi.com; alan@jasomi.com; sbansal@cdotd.ernet.in; = sipping@ietf.org Subject: Re: [Sipping] Call Waiting - who does the tone (round 2) In a message dated 6/19/2003 1:28:51 PM Eastern Standard Time, = rohan@cisco.com writes:=20 Dusan,=20 Every SIP phone that I am aware of offers call waiting natively. It=20 requires no cooperation on the part of any service provider, and no=20 additional cost by either the end-user nor by any service provider.=20 - Nobody has provided any compelling benefit to the end-user to do call=20 waiting in the network=20 - Nobody has provided any compelling benefit to the service provider to=20 do call waiting in the network=20 - Nobody has demonstrated that any SIP phones implement any of the=20 additional weirdo mechanism that would be required to make network call=20 waiting work as well as locally-implemented call waiting, Nor that=20 there is any compelling economic reason for them to do so.=20 thanks,=20 -rohan=20 Rohan,=20 I've been watching this discussion hoping to see a good answer to the = beginning question: "Who does the tone?" since this same question about = the source of tones comes up in many other areas, such as the Assured = Service that we require. Maybe I missed something, but I don't think = I've heard an answer - just lots of conjecture and possibilities of how = it might be done.=20 As for the question above - what is the benefit to the service provider = to doing call waiting in the network?- I'll try to address that one.=20 It's not a question of "where" it's done, but of who controls it. In the = case I am interested in, the network provider/service provider/end users = (really all the same large bunch of people) want a system which offers a = number of services, including Call Waiting and Assured Service. Part of = the requirement is to provide certain operational interactions between = those services. That is, there is an expectation of which service takes = precedence when multiple services may apply at the same time. If Call = Waiting is done completely in the UA, and Call Forwarding is done in a = proxy, and the decision to preempt a call for Assured Service is done = someplace else, there is no way that I can imagine that the service = provider would have any control whatsoever over the precedence of these = actions or other interactions between them. So the requirement for this = network is going to be that all services applying to a terminating call = must be controlled by a single device, I guess it would be a SIP proxy = serving the called user. The service provider requires standardized ways = to do all of the required services, controlled by a proxy. Without that, = it can not use SIP.=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 Jun 23 07:25:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16503 for ; Mon, 23 Jun 2003 07:25:21 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NBOqD17925 for sipping-archive@odin.ietf.org; Mon, 23 Jun 2003 07:24:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UPRM-0004f2-NG for sipping-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 07:24: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 HAA16478 for ; Mon, 23 Jun 2003 07:24:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UPRM-0001U3-00 for sipping-web-archive@ietf.org; Mon, 23 Jun 2003 07:24:52 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UPRG-0001U0-00 for sipping-web-archive@ietf.org; Mon, 23 Jun 2003 07:24:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UPQX-0004WU-T2; Mon, 23 Jun 2003 07: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 19UPPS-0004VS-Qo for sipping@optimus.ietf.org; Mon, 23 Jun 2003 07:23: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 HAA16442 for ; Mon, 23 Jun 2003 07:22:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UPPD-0001Sq-00 for sipping@ietf.org; Mon, 23 Jun 2003 07:22:39 -0400 Received: from ns.ivd.nl ([193.67.37.226]) by ietf-mx with esmtp (Exim 4.12) id 19UPP1-0001SQ-00 for sipping@ietf.org; Mon, 23 Jun 2003 07:22:28 -0400 Received: (from root@localhost) by ns.ivd.nl (8.9.3c/8.6.12) id NAA33950 for ; Mon, 23 Jun 2003 13:22:51 +0200 (CEST) Received: by ns.ivd.nl (TUNIX txp2/smap) for id sma033055; Mon, 23 Jun 03 13:21:38 +0200 Received: from IVD-Message_Server by mailserver.viataal.nl with Novell_GroupWise; Mon, 23 Jun 2003 13:22:37 +0200 Message-Id: X-Mailer: Novell GroupWise 5.5.5 Date: Mon, 23 Jun 2003 13:22:30 +0200 From: "A vWijk" To: , , Subject: RE: [Sipping] Text support in SIP phones 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 Hello Jon, <>= Real-time text telephony is NOT a luxery. It is a basic need for the = hearing and speech impaired! IM is now used, but is a very limited = system.=20 Because that is equivalent to having a telephone where you wait a while = before getting a voice reply. E.g. Hi with Jon.........................................................<.= hi! nice to hear from you Jon>.............................................= ..........how are you?.....................................................= ......................= .....................................yeah, this is Voice IM................= .............................................................= .....................Yes, this is the only way to experience how a = telephony conversation will be if we simply ignore the needs for the = hearing impaired.........................................= ....................................................= ..................... This is exactly what you are trying to tell me that is acceptable???? And, what about telephony functions like forwarding a call, or redirecting = a call or even putting on hold? Not possible with IM. For the hearing impaired users like me, text telephony is the ONLY way to = have a good conversation. I know it from first hand and I am also a very experienced IM user.=20 <> SMS is not a good alternative, we deaf are stuck to it since there is = nothing better. And by making RFC2793 mandatory for VoIP and other SIP Telephony devices = does not mean we throw away IM!=20 Just 2 ways for text, IM for short messages and short exchange of info = that are NOT time urgent. And real-time text conversatoon T.140 for = telephone conversations. <> You know what? I as a deaf person simply HATE regulations. They suck = bigtime. Regulations always result to fixing things to make it work and = never really do that well! They just basically work. Costing a lot of = money and time. Let's just be smart and implement at protocol and design level the needs = for the hearing , speech and other impairments at a neglicable cost or no = cost at all! And then we never need those regulations at all! And this work does NOT contradict market direction. I know what I am talking about, and so does Guido Gybels. Arnoud 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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 23 07:50:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17140 for ; Mon, 23 Jun 2003 07:50:18 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NBnnP21533 for sipping-archive@odin.ietf.org; Mon, 23 Jun 2003 07:49:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UPpU-0005bE-Pb for sipping-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 07:49: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 HAA17120 for ; Mon, 23 Jun 2003 07:49:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UPpT-0001cR-00 for sipping-web-archive@ietf.org; Mon, 23 Jun 2003 07:49:47 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UPpO-0001cO-00 for sipping-web-archive@ietf.org; Mon, 23 Jun 2003 07:49:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UPoj-0005Sn-JC; Mon, 23 Jun 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 19UPoi-0005Sa-As for sipping@optimus.ietf.org; Mon, 23 Jun 2003 07:49: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 HAA17108 for ; Mon, 23 Jun 2003 07:48:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UPoS-0001c0-00 for sipping@ietf.org; Mon, 23 Jun 2003 07:48:44 -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 19UPoH-0001bx-00 for sipping@ietf.org; Mon, 23 Jun 2003 07:48:33 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.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 h5NBmRw2024325 for ; Mon, 23 Jun 2003 13:48:27 +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 LYGMDYKZ; Mon, 23 Jun 2003 13:48:27 +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 h5NBmASZ020180 for ; Mon, 23 Jun 2003 14:48:10 +0300 (EET DST) Message-ID: <3EF6E90A.AD637CB9@lmf.ericsson.se> Date: Mon, 23 Jun 2003 14:48:26 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sipping@ietf.org Subject: Re: [Sipping] I-D ACTION:draft-elmalki-v6ops-3gpp-translator-00.txt References: <200306181151.HAA27894@ietf.org> 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 Folks, we would like to draw your attention to the draft below. It will be discused in v6ops, but it contains SIP stuff as well. In particular, it describes how 3GPP terminals could use ICE, STUN and ALT to communicate with IPv4-only UAs on the Internet. The authors would appreciate your comments. Gonzalo Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : IPv6-IPv4 Translators in 3GPP Networks > Author(s) : K. El Malki et al. > Filename : draft-elmalki-v6ops-3gpp-translator-00.txt > Pages : 16 > Date : 2003-6-17 > > There have been discussions on the v6ops mailing list and at IETF > meetings regarding the suitability of translators (e.g. NAT-PT) as > mechanisms for IPv4 to IPv6 transition. It has often been stated that > NAT-PT is not a mechanism to be recommended in general to solve the > IPv6-IPv4 transition problem and some modifications to NAT-PT have > been proposed. However there have also been discussions regarding > special scenarios where some form of translators could be deployed if > their use is documented appropriately. The aim of this draft is to > document the rationale for using translators in 3GPP networks, in > particular for IPv6-only IMS (IP Multimedia Subsystem) and to > describe possible solutions to the problem and the interactions with > SIP. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-elmalki-v6ops-3gpp-translator-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-elmalki-v6ops-3gpp-translator-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-elmalki-v6ops-3gpp-translator-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ------------------------------------------------------------------------ _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Jun 23 09:14:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19337 for ; Mon, 23 Jun 2003 09:14:20 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NDDq300440 for sipping-archive@odin.ietf.org; Mon, 23 Jun 2003 09:13:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UR8q-000071-Lv for sipping-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 09:13: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 JAA19327 for ; Mon, 23 Jun 2003 09:13:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UR8p-00024P-00 for sipping-web-archive@ietf.org; Mon, 23 Jun 2003 09:13:51 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UR8j-00024M-00 for sipping-web-archive@ietf.org; Mon, 23 Jun 2003 09:13:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UR81-0008NQ-UT; Mon, 23 Jun 2003 09: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 19UR6Y-0008JY-GS for sipping@optimus.ietf.org; Mon, 23 Jun 2003 09:12: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 JAA19231 for ; Mon, 23 Jun 2003 09:11:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UR6W-00022x-00 for sipping@ietf.org; Mon, 23 Jun 2003 09:11:28 -0400 Received: from ns.ivd.nl ([193.67.37.226]) by ietf-mx with esmtp (Exim 4.12) id 19UR6M-00022M-00 for sipping@ietf.org; Mon, 23 Jun 2003 09:11:18 -0400 Received: (from root@localhost) by ns.ivd.nl (8.9.3c/8.6.12) id PAA64734 for ; Mon, 23 Jun 2003 15:11:38 +0200 (CEST) Received: by ns.ivd.nl (TUNIX txp2/smap) for id sma064468; Mon, 23 Jun 03 15:10:30 +0200 Received: from IVD-Message_Server by mailserver.viataal.nl with Novell_GroupWise; Mon, 23 Jun 2003 15:11:30 +0200 Message-Id: X-Mailer: Novell GroupWise 5.5.5 Date: Mon, 23 Jun 2003 15:11:12 +0200 From: "A vWijk" To: , Cc: , , Subject: RE: [Sipping] Text support in SIP phones 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 Hello Dean, The price of original comments goes to you. :-) Huffing and puffing communication. (and the likely implementation will be input via eye movements instead = using your breath.) I have already used and seen implemenations of T140 as described in = RFC2793 which was transferred over the common ordinary overloaded = internet. Gunnar Hellstrom has a lot of info about this. But I still maintain that T140/RFC2793 has to exist besides IM.=20 Because IM, even if they go near real-time character by character (how = will that be done???). The interoperability remains a big issue. Zillions = of IM standards. Creating a new real-time streaming text protocol for IM is a bit useless. RFC 2793 uses ITU and 3GPP approved text T140 protocol. So, the implementat= ion will be easy and it should just as reliable as any other multimedia = message over RTP. Or do you feel that using RTP to send text looks like an overkill Dean? = You could then define T.140 over TCP/IP and T.140 as in RFC2793 But T.140 over TCP/IP might only be useful for GPRS. UMTS and fixed lines = will hardly notice the text bandwidth usage at all. Ofcourse I am open to comments from others. greetz Arnoud 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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 23 09:48:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20340 for ; Mon, 23 Jun 2003 09:48:16 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NDlmx05936 for sipping-archive@odin.ietf.org; Mon, 23 Jun 2003 09:47:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19URfg-0001Xf-OD for sipping-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 09:47: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 JAA20317 for ; Mon, 23 Jun 2003 09:47:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19URfe-0002Kw-00 for sipping-web-archive@ietf.org; Mon, 23 Jun 2003 09:47:46 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19URfZ-0002Kt-00 for sipping-web-archive@ietf.org; Mon, 23 Jun 2003 09:47:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19URev-0001Om-NT; Mon, 23 Jun 2003 09: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 19UReZ-0001OG-R9 for sipping@optimus.ietf.org; Mon, 23 Jun 2003 09:46: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 JAA20297 for ; Mon, 23 Jun 2003 09:46:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UReX-0002KA-00 for sipping@ietf.org; Mon, 23 Jun 2003 09:46:37 -0400 Received: from mail5.telekom.de ([62.225.183.202] helo=mail1.telekom.de) by ietf-mx with esmtp (Exim 4.12) id 19UReN-0002Jk-00 for sipping@ietf.org; Mon, 23 Jun 2003 09:46:27 -0400 Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP for sipping@ietf.org; Mon, 23 Jun 2003 15:45:25 +0200 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Jun 2003 15:45:24 +0200 Message-Id: From: "Beck01, Wolfgang" To: sipping@ietf.org Subject: RE: [Sipping] Text support in SIP phones Date: Mon, 23 Jun 2003 15:45:20 +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: , some thoughts: - UA implementors will ask how long it will take to do rfc2793. Is T.140 encoding complicated? Are the redundancy schemes difficult to implement? How much will it take to change the user interface of the client? Who will pay for this? real-time text telephony needs a better name. How many managers know the term "instant messaging" and how many know about T.140? Compare boring "half-duplex communication" with the buzz word "Push To Talk". Arnoud wrote: > Real-time text telephony is NOT a luxery. It is a basic need > for the hearing and speech impaired! IM is now used, but is a > very limited system. The question of a UA manufacturer is: "How many more UAs will we sell if we implement this feature?" If real-time text telephony does not sell outside the hearing and speech impaired community, most managers will regard it as luxury. - RfC 2793 puts far less load on SIP proxies than SIP MESSAGEs if people are having longer text conversations. -- 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 Mon Jun 23 11:22:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24215 for ; Mon, 23 Jun 2003 11:22:18 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NFLpJ20209 for sipping-archive@odin.ietf.org; Mon, 23 Jun 2003 11:21:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UT8g-0005Fs-Ug for sipping-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 11:21: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 LAA24190 for ; Mon, 23 Jun 2003 11:21:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UT8f-0002ui-00 for sipping-web-archive@ietf.org; Mon, 23 Jun 2003 11:21:49 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UT8Z-0002ti-00 for sipping-web-archive@ietf.org; Mon, 23 Jun 2003 11:21:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UT5x-0004wa-Cq; Mon, 23 Jun 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 19UT5K-0004wB-QT for sipping@optimus.ietf.org; Mon, 23 Jun 2003 11:18: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 LAA24109 for ; Mon, 23 Jun 2003 11:18:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UT5J-0002tO-00 for sipping@ietf.org; Mon, 23 Jun 2003 11:18:21 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19UT59-0002sq-00 for sipping@ietf.org; Mon, 23 Jun 2003 11:18:11 -0400 Received: from VPALAWATW2K2 (dhcp-10-86-165-2.cisco.com [10.86.165.2]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5NFH9ai024662; Mon, 23 Jun 2003 11:17:09 -0400 (EDT) Reply-To: From: "Vipin Palawat" To: "'Rohan Mahy'" , Subject: RE: [Sipping] New Tones draft (was: "who plays the tone" or something like that) Date: Mon, 23 Jun 2003 11:17:07 -0400 Message-ID: <008601c3399a$82e68c80$02a5560a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <7F9D6ACC-A53E-11D7-8E0D-0003938AF740@cisco.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 Hi rohan, Some initial comments: 1. Repeat in the schema is boolean. I would like to know how I can specify a Repeat interval for tones like "Hold". 2. Is there a way we could indicate a UA (sort of preference) to either play the early media tone or play the tone specified by "audio/tone-info+xml" ? Or a UA SHOULD always play the early media when available and stop the xml tone . There are some scenarios where it is desired to not have early media but just the tones specified by "audio/tone-info+xml" . Thanks, Vipin -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of Rohan Mahy Sent: Monday, June 23, 2003 1:50 AM To: 'sipping@ietf.org' Subject: [Sipping] New Tones draft (was: "who plays the tone" or something like that) 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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 23 12:11:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26683 for ; Mon, 23 Jun 2003 12:11:01 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NGAYP29915 for sipping-archive@odin.ietf.org; Mon, 23 Jun 2003 12:10:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UTtq-0007mQ-1z for sipping-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 12:10: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 MAA26672 for ; Mon, 23 Jun 2003 12:10: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 19UTtJ-0007c5-D2; Mon, 23 Jun 2003 12:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UTsU-0007bJ-FD for sipping@optimus.ietf.org; Mon, 23 Jun 2003 12:09:10 -0400 Received: from imo-m05.mx.aol.com (imo-m05.mx.aol.com [64.12.136.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26604 for ; Mon, 23 Jun 2003 12:09:07 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-m05.mx.aol.com (mail_out_v36.3.) id p.166.2236ce16 (4552); Mon, 23 Jun 2003 12:02:38 -0400 (EDT) Message-ID: <166.2236ce16.2c287e9e@aol.com> Date: Mon, 23 Jun 2003 12:02:38 EDT Subject: Re: [Sipping] Call Waiting - who does the tone (round 2) To: hisham.khartabil@nokia.com CC: sipping@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_166.2236ce16.2c287e9e_boundary" X-Mailer: 6.0 for Windows XP sub 10501 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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_166.2236ce16.2c287e9e_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 6/23/2003 4:59:41 AM Eastern Standard Time, hisham.khartabil@nokia.com writes: > A call stateful proxy can decide to forward or not to forward an INVITE to > a UA that is already in another call. The decision can be based on anything > including charging ( a user has payed for call forwarding). If the proxy > decides to forward the INVITE, it is the UA that plays the tone when it receives > the INVITE. > > Network controls the service, UA DOES the tone. > > Did I miss anything? > I believe you have it correct. But the question always comes down to, if the UA itself generates the tone (under control of the network), what if the network wants to introduce a new service or feature which requires a new tone. Can it be assured that every existing UA can generate that new tone? Conversely, if the UA controls the services, it would certainly be the case that old UAs could not handle a new service. Mike Pierce --part1_166.2236ce16.2c287e9e_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 6/23/2= 003 4:59:41 AM Eastern Standard Time, hisham.khartabil@nokia.com writes:


A call stateful proxy can d= ecide to forward or not to forward an INVITE to a UA that is already in anot= her call. The decision can be based on anything including charging ( a user=20= has payed for call forwarding). If the proxy decides to forward the INVITE,=20= it is the UA that plays the tone when it receives the INVITE.

Network controls the service, UA DOES the tone.

Did I miss anything?


I believe you have it correct. But the question always comes down to, if= the UA itself generates the tone (under control of the network), what if th= e network wants to introduce a new service or feature which requires a new t= one. Can it be assured that every existing UA can generate that new tone? Co= nversely, if the UA controls the services, it would certainly be the case th= at old UAs could not handle a new service.

Mike Pierce
--part1_166.2236ce16.2c287e9e_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 Jun 23 12:16:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26993 for ; Mon, 23 Jun 2003 12:16:01 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NGFY732103 for sipping-archive@odin.ietf.org; Mon, 23 Jun 2003 12:15:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UTyg-0008Li-GN for sipping-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 12:15: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 MAA26917 for ; Mon, 23 Jun 2003 12:15: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 19UTyA-00082d-PC; Mon, 23 Jun 2003 12:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UTxx-00081D-AL for sipping@optimus.ietf.org; Mon, 23 Jun 2003 12:14: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 MAA26858 for ; Mon, 23 Jun 2003 12:14:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UTxv-0003QX-00 for sipping@ietf.org; Mon, 23 Jun 2003 12:14: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 19UTxl-0003PZ-00 for sipping@ietf.org; Mon, 23 Jun 2003 12:14:37 -0400 Received: from cisco.com (171.68.223.138) by sj-iport-1.cisco.com with ESMTP; 23 Jun 2003 09:15:03 -0800 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 h5NGD8RJ011623; Mon, 23 Jun 2003 09:13:13 -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 AIK31899; Mon, 23 Jun 2003 09:06:24 -0700 (PDT) Date: Mon, 23 Jun 2003 09:14:25 -0700 Subject: Re: [Sipping] New Tones draft (was: "who plays the tone" or something like that) Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: From: Rohan Mahy In-Reply-To: <008601c3399a$82e68c80$02a5560a@amer.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 Hi Vipin, Some very short comments, because I am very sleepy. On Monday, June 23, 2003, at 08:17 AM, Vipin Palawat wrote: > Hi rohan, > > Some initial comments: > > 1. Repeat in the schema is boolean. I would like to know how I can > specify a Repeat interval for tones like "Hold". i think this should do the trick (first tone) (silence) > 2. Is there a way we could indicate a UA (sort of preference) to either > play the early media tone or play the tone specified by > "audio/tone-info+xml" ? Or a UA SHOULD always play the early media when > available and stop the xml tone . IMO, you SHOULD avoid sending early media like the plague, but if you receive it it should take precedence over whatever ringback tones you were receiving. > There are some scenarios where it is desired to not have early media > but > just the tones specified by "audio/tone-info+xml" . yes. that was the idea. next rev, i'll try to make that more clear. thx, -r > > Thanks, > Vipin > > > > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf > Of Rohan Mahy > Sent: Monday, June 23, 2003 1:50 AM > To: 'sipping@ietf.org' > Subject: [Sipping] New Tones draft (was: "who plays the tone" or > something like that) > > > 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 > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 23 13:07:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29047 for ; Mon, 23 Jun 2003 13:07:02 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NH6am10458 for sipping-archive@odin.ietf.org; Mon, 23 Jun 2003 13:06:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UUm4-0002ib-Ck for sipping-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 13:06: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 NAA29040 for ; Mon, 23 Jun 2003 13:06: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 19UUlW-0002YY-Gt; Mon, 23 Jun 2003 13: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 19UUl8-0002Y0-VE for sipping@optimus.ietf.org; Mon, 23 Jun 2003 13:05: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 NAA29025 for ; Mon, 23 Jun 2003 13:05:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UUl7-0003uB-00 for sipping@ietf.org; Mon, 23 Jun 2003 13:05:37 -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 19UUkw-0003tx-00 for sipping@ietf.org; Mon, 23 Jun 2003 13:05:26 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-1.cisco.com with ESMTP; 23 Jun 2003 10:06:39 -0800 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 h5NH4mQx014905; Mon, 23 Jun 2003 10:04:49 -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 AIK37499; Mon, 23 Jun 2003 09:58:04 -0700 (PDT) Date: Mon, 23 Jun 2003 10:06:04 -0700 Subject: Re: [Sipping] New Tones draft (was: "who plays the tone" or something like that) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: , To: "Hearty, John" From: Rohan Mahy In-Reply-To: <3DB099919328BA41905F651A6EF83976B4DD9B@idc1exc0004.corp.global.level3.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 Hi John, On Monday, June 23, 2003, at 09:41 AM, Hearty, John wrote: > Re: >>> 2. Is there a way we could indicate a UA (sort of preference) to >>> either >>> play the early media tone or play the tone specified by >>> "audio/tone-info+xml" ? Or a UA SHOULD always play the early media >>> when >>> available and stop the xml tone . >> >> IMO, you SHOULD avoid sending early media like the plague, but if you >> receive it it should take precedence over whatever ringback tones you >> were receiving. > > I see the long, drawn out early media thread starting here again. I > think the concepts of the draft are fine provided you know for sure > some > specific tone must be rendered. However, one thing I keep coming back > to is that frequently for IP to PSTN calls, we don't know if the > content > of the pre-answer media from the PSTN is tones, or other media such as > announcements. I guess the real question is if PSTN gateways know they are playing ringback often enough to justify implementing a tone mechanism. Everyone acknowledges that during MF interworking that you don't know if the content is ringback or announcements. I suspect that enough calls have signal transparency to make this worthwhile for ringback. If anyone has any data to support or refute this hunch I think that would be a valuable addition to this discussion. thanks, -rohan > 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 Mon Jun 23 13:28:36 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 NAA29973 for ; Mon, 23 Jun 2003 13:28:36 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NHSAw14422 for sipping-archive@odin.ietf.org; Mon, 23 Jun 2003 13:28:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UV6w-0003kX-B5 for sipping-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 13:28: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 NAA29966 for ; Mon, 23 Jun 2003 13:28:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UV6u-00047A-00 for sipping-web-archive@ietf.org; Mon, 23 Jun 2003 13:28:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UV6o-000477-00 for sipping-web-archive@ietf.org; Mon, 23 Jun 2003 13:28:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UV6n-0003jY-LN; Mon, 23 Jun 2003 13:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UV68-0003jE-GW for sipping@optimus.ietf.org; Mon, 23 Jun 2003 13: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 NAA29952 for ; Mon, 23 Jun 2003 13:27:16 -0400 (EDT) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UV66-00046h-00 for sipping@ietf.org; Mon, 23 Jun 2003 13:27:18 -0400 Received: from imo-m02.mx.aol.com ([64.12.136.5]) by ietf-mx with esmtp (Exim 4.12) id 19UV5q-000466-00 for sipping@ietf.org; Mon, 23 Jun 2003 13:27:02 -0400 Received: from Mpierce1@aol.com by imo-m02.mx.aol.com (mail_out_v36.3.) id c.25.3ab7d163 (2168); Mon, 23 Jun 2003 13:25:09 -0400 (EDT) Message-ID: <25.3ab7d163.2c2891f5@aol.com> Date: Mon, 23 Jun 2003 13:25:09 EDT Subject: Re: [Sipping] New Tones draft (was: "who plays the tone" or something like th... To: rohan@cisco.com, sipping@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_25.3ab7d163.2c2891f5_boundary" X-Mailer: 6.0 for Windows XP sub 10501 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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_25.3ab7d163.2c2891f5_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 6/23/2003 2:02:12 AM Eastern Standard Time, rohan@cisco.com writes: > 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. > Rohan, 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. 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: 1. send the tone only to the user of that UA (e.g., Call Waiting) 2. send the tone only to the other end (e.g., Audible Ringing) 3. send the tone to both (e.g., Recorder Warning) 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"). This proposal would work, if every UA were required to support it. Mike Pierce --part1_25.3ab7d163.2c2891f5_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 6/23/2= 003 2:02:12 AM Eastern Standard Time, rohan@cisco.com writes:


wrote the following draft=20= 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.




Rohan,

This seems to handle the general case of instructing a UA to generate a=20= tone based on a specific set of characteristics (frequencies, levels, durati= on, decay, modulation, etc.) One of the immediate questions is what is the f= ull set of possibilites required and what happens when someone wants a tone=20= 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, n= o one has used a tone that varies in frequency over time.

I didn't see anything in your write-up or in RFC 2833 about specifying w= hich direction the UA should send the tone. There can be cases which the UA=20= needs to be told:

1. send the tone only to the user of that UA (e.g., Call Waiting)
2. send the tone only to the other end (e.g., Audible Ringing)
3. send the tone to both (e.g., Recorder Warning)

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 fun= ction should be done in a different way, since the UA is presumed to have ot= her alerting mechanisms (like ringing when already "off-hook").

This proposal would work, if every UA were required to support it.

Mike Pierce
--part1_25.3ab7d163.2c2891f5_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 Jun 23 14:46:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03712 for ; Mon, 23 Jun 2003 14:46:39 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NIkCM27542 for sipping-archive@odin.ietf.org; Mon, 23 Jun 2003 14:46:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UWKS-0007A8-2F for sipping-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 14:46: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 OAA03705 for ; Mon, 23 Jun 2003 14:46:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UWKP-0004kn-00 for sipping-web-archive@ietf.org; Mon, 23 Jun 2003 14:46:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UWKJ-0004kk-00 for sipping-web-archive@ietf.org; Mon, 23 Jun 2003 14:46:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UWKI-00078l-PY; Mon, 23 Jun 2003 14: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 19UWK1-00078C-Tz for sipping@optimus.ietf.org; Mon, 23 Jun 2003 14: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 OAA03677 for ; Mon, 23 Jun 2003 14:45:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UWJz-0004kS-00 for sipping@ietf.org; Mon, 23 Jun 2003 14:45:43 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19UWJn-0004jz-00 for sipping@ietf.org; Mon, 23 Jun 2003 14:45:32 -0400 Received: from VPALAWATW2K2 (dhcp-10-86-165-2.cisco.com [10.86.165.2]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5NIiTai007604; Mon, 23 Jun 2003 14:44:30 -0400 (EDT) Reply-To: From: "Vipin Palawat" To: "'Rohan Mahy'" Cc: Subject: RE: [Sipping] New Tones draft (was: "who plays the tone" or something like that) Date: Mon, 23 Jun 2003 14:44:29 -0400 Message-ID: <00b801c339b7$7b183bd0$02a5560a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of Rohan Mahy Sent: Monday, June 23, 2003 12:14 PM To: vpalawat@cisco.com Cc: sipping@ietf.org Subject: Re: [Sipping] New Tones draft (was: "who plays the tone" or something like that) Hi Vipin, Some very short comments, because I am very sleepy. On Monday, June 23, 2003, at 08:17 AM, Vipin Palawat wrote: > Hi rohan, > > Some initial comments: > > 1. Repeat in the schema is boolean. I would like to know how I can > specify a Repeat interval for tones like "Hold". i think this should do the trick (first tone) (silence) [Vipin] I am unable to understand this completely. How do I specify the duration of silence ? Can you give me a complete example ? > 2. Is there a way we could indicate a UA (sort of preference) to > either play the early media tone or play the tone specified by > "audio/tone-info+xml" ? Or a UA SHOULD always play the early media > when available and stop the xml tone . IMO, you SHOULD avoid sending early media like the plague, but if you receive it it should take precedence over whatever ringback tones you were receiving. [Vipin] Media over early media sessions may not be desired in some cases and suppose I want to indicate that tones via "audio/tone-info+xml" takes precedence over media. Is there a way I can specify this ? Few more comments: * How do I indicate a UA to stop playing a particular or all tone ? This is also required for interworking with H225 Info message. > There are some scenarios where it is desired to not have early media > but > just the tones specified by "audio/tone-info+xml" . yes. that was the idea. next rev, i'll try to make that more clear. thx, -r > > Thanks, > Vipin > > > > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf > Of Rohan Mahy > Sent: Monday, June 23, 2003 1:50 AM > To: 'sipping@ietf.org' > Subject: [Sipping] New Tones draft (was: "who plays the tone" or > something like that) > > > 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 > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 23 15:25:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06757 for ; Mon, 23 Jun 2003 15:25:41 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NJPD102489 for sipping-archive@odin.ietf.org; Mon, 23 Jun 2003 15:25:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UWwC-0000e4-VQ for sipping-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 15:25:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06713 for ; Mon, 23 Jun 2003 15:25:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UWwB-00055H-00 for sipping-web-archive@ietf.org; Mon, 23 Jun 2003 15:25:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UWw6-00055E-00 for sipping-web-archive@ietf.org; Mon, 23 Jun 2003 15:25:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UWw1-0000co-VU; Mon, 23 Jun 2003 15: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 19UWvw-0000cE-QN for sipping@optimus.ietf.org; Mon, 23 Jun 2003 15:24: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 PAA06677 for ; Mon, 23 Jun 2003 15:24:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UWvv-00054y-00 for sipping@ietf.org; Mon, 23 Jun 2003 15:24:55 -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 19UWvk-00054H-00 for sipping@ietf.org; Mon, 23 Jun 2003 15:24:44 -0400 Received: from cisco.com (171.68.223.138) by sj-iport-1.cisco.com with ESMTP; 23 Jun 2003 12:25:57 -0800 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 h5NJO6RJ011098; Mon, 23 Jun 2003 12:24:06 -0700 (PDT) Received: from mhammer-w2k02.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 AEQ44581; Mon, 23 Jun 2003 12:24:05 -0700 (PDT) Message-Id: <4.3.2.7.2.20030623151723.00b24458@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 23 Jun 2003 15:24:04 -0400 To: Mpierce1@aol.com From: Michael Hammer Subject: Re: [Sipping] Call Waiting - who does the tone (round 2) Cc: hisham.khartabil@nokia.com, sipping@ietf.org In-Reply-To: <166.2236ce16.2c287e9e@aol.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1071771==_.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: , --=====================_1071771==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Assuming that .wav files or such can be forwarded to the phone, no reason why a UA could not play the new tone. Similarly, if you want to upgrade the phone with new services. The unstated element of MLPP that might get lost is the ability to force the UA to do something if its user programs it to refuse new tones, services, or requests. But, I would expect that if the General's call didn't preempt the lower ranking person's call due to some "local" programming, organizational remedies would take place. Mike H. At 12:02 PM 6/23/2003 -0400, Mpierce1@aol.com wrote: >In a message dated 6/23/2003 4:59:41 AM Eastern Standard Time, >hisham.khartabil@nokia.com writes: > > >>A call stateful proxy can decide to forward or not to forward an INVITE >>to a UA that is already in another call. The decision can be based on >>anything including charging ( a user has payed for call forwarding). If >>the proxy decides to forward the INVITE, it is the UA that plays the tone >>when it receives the INVITE. >> >>Network controls the service, UA DOES the tone. >> >>Did I miss anything? > > >I believe you have it correct. But the question always comes down to, if >the UA itself generates the tone (under control of the network), what if >the network wants to introduce a new service or feature which requires a >new tone. Can it be assured that every existing UA can generate that new >tone? Conversely, if the UA controls the services, it would certainly be >the case that old UAs could not handle a new service. > >Mike Pierce --=====================_1071771==_.ALT Content-Type: text/html; charset="us-ascii" Assuming that .wav files or such can be forwarded to the phone, no reason why a UA could not play the new tone.

Similarly, if you want to upgrade the phone with new services.

The unstated element of MLPP that might get lost is the ability to force the UA to do something if its user programs it to refuse new tones, services, or requests.  But, I would expect that if the General's call didn't preempt the lower ranking person's call due to some "local" programming, organizational remedies would take place.

Mike H.


At 12:02 PM 6/23/2003 -0400, Mpierce1@aol.com wrote:
In a message dated 6/23/2003 4:59:41 AM Eastern Standard Time, hisham.khartabil@nokia.com writes:


A call stateful proxy can decide to forward or not to forward an INVITE to a UA that is already in another call. The decision can be based on anything including charging ( a user has payed for call forwarding). If the proxy decides to forward the INVITE, it is the UA that plays the tone when it receives the INVITE.

Network controls the service, UA DOES the tone.

Did I miss anything?


I believe you have it correct. But the question always comes down to, if the UA itself generates the tone (under control of the network), what if the network wants to introduce a new service or feature which requires a new tone. Can it be assured that every existing UA can generate that new tone? Conversely, if the UA controls the services, it would certainly be the case that old UAs could not handle a new service.

Mike Pierce
--=====================_1071771==_.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 Jun 23 15:58:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08035 for ; Mon, 23 Jun 2003 15:58:37 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NJw9r07438 for sipping-archive@odin.ietf.org; Mon, 23 Jun 2003 15: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 19UXS5-0001vt-Ia for sipping-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 15:58: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 PAA08032 for ; Mon, 23 Jun 2003 15:58:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UXS4-0005Kc-00 for sipping-web-archive@ietf.org; Mon, 23 Jun 2003 15:58:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UXRy-0005KZ-00 for sipping-web-archive@ietf.org; Mon, 23 Jun 2003 15:58:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UXRx-0001ug-00; Mon, 23 Jun 2003 15: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 19UXR4-0001uG-L5 for sipping@optimus.ietf.org; Mon, 23 Jun 2003 15:57: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 PAA08008 for ; Mon, 23 Jun 2003 15:57:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UXR3-0005KJ-00 for sipping@ietf.org; Mon, 23 Jun 2003 15:57:05 -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 19UXQs-0005Ju-00 for sipping@ietf.org; Mon, 23 Jun 2003 15:56:54 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 23 Jun 2003 12:58:57 -0800 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 h5NJtmGe013610; Mon, 23 Jun 2003 12:55:49 -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 AIK59248; Mon, 23 Jun 2003 12:49:03 -0700 (PDT) Date: Mon, 23 Jun 2003 12:57:03 -0700 Subject: Re: [Sipping] New Tones draft (was: "who plays the tone" or something like that) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: From: Rohan Mahy In-Reply-To: <00b801c339b7$7b183bd0$02a5560a@amer.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 Monday, June 23, 2003, at 11:44 AM, Vipin Palawat wrote: > > > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf > Of Rohan Mahy > Sent: Monday, June 23, 2003 12:14 PM > To: vpalawat@cisco.com > Cc: sipping@ietf.org > Subject: Re: [Sipping] New Tones draft (was: "who plays the tone" or > something like that) > > > Hi Vipin, > > Some very short comments, because I am very sleepy. > > On Monday, June 23, 2003, at 08:17 AM, Vipin Palawat wrote: > >> Hi rohan, >> >> Some initial comments: >> >> 1. Repeat in the schema is boolean. I would like to know how I can >> specify a Repeat interval for tones like "Hold". > > i think this should do the trick > > > (first tone) > (silence) > > > [Vipin] I am unable to understand this completely. How do I specify the > duration of silence ? Can you give me a complete example ? the example in the draft: > 2. Is there a way we could indicate a UA (sort of preference) to >> either play the early media tone or play the tone specified by >> "audio/tone-info+xml" ? Or a UA SHOULD always play the early media >> when available and stop the xml tone . > > IMO, you SHOULD avoid sending early media like the plague, but if you > receive it it should take precedence over whatever ringback tones you > were receiving. > > [Vipin] Media over early media sessions may not be desired in some > cases > > and suppose I want to indicate that tones via "audio/tone-info+xml" > takes > precedence over media. Is there a way I can specify this ? my comment was only about early media. for connected media, I imagine, if you send a tone you want to play during the connected state that the tone will take precedence over any other media. (ex: barge-in tones). > Few more comments: > * How do I indicate a UA to stop playing a particular or all tone ? > This > is also > required for interworking with H225 Info message. send another message (18x, UPDATE, whatever) that has no tone? thx, -r > >> There are some scenarios where it is desired to not have early media >> but >> just the tones specified by "audio/tone-info+xml" . > > yes. that was the idea. next rev, i'll try to make that more clear. > > > > > thx, > -r > >> >> Thanks, >> Vipin >> >> >> >> -----Original Message----- >> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf > >> Of Rohan Mahy >> Sent: Monday, June 23, 2003 1:50 AM >> To: 'sipping@ietf.org' >> Subject: [Sipping] New Tones draft (was: "who plays the tone" or >> something like that) >> >> >> 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 >> > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip Use > sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 23 21:44:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17720 for ; Mon, 23 Jun 2003 21:44:46 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5O1iJm15030 for sipping-archive@odin.ietf.org; Mon, 23 Jun 2003 21: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 19Ucr5-0003uL-6j for sipping-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 21: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 VAA17714 for ; Mon, 23 Jun 2003 21:44:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ucr2-0007DC-00 for sipping-web-archive@ietf.org; Mon, 23 Jun 2003 21:44:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ucqw-0007D5-00 for sipping-web-archive@ietf.org; Mon, 23 Jun 2003 21:44:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ucqn-0003t5-R7; Mon, 23 Jun 2003 21: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 19Ucq5-0003sD-IH for sipping@optimus.ietf.org; Mon, 23 Jun 2003 21:43: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 VAA17660 for ; Mon, 23 Jun 2003 21:42:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ucpn-0007CG-00 for sipping@ietf.org; Mon, 23 Jun 2003 21:42:59 -0400 Received: from [210.21.224.29] (helo=szsmtp.utstar.com.cn) by ietf-mx with esmtp (Exim 4.12) id 19Ucpc-0007C7-00 for sipping@ietf.org; Mon, 23 Jun 2003 21:42:48 -0400 Received: from sznsszqweng ([172.19.16.43]) by szsmtp.utstar.com.cn (8.11.1/8.11.1) with SMTP id h5O1euI26275; Tue, 24 Jun 2003 09:40:58 +0800 Message-ID: <025801c339f1$a6db0920$2b1013ac@cn.utstar.com> From: "weng zhiqiang" To: , Cc: References: <166.2236ce16.2c287e9e@aol.com> Subject: Re: [Sipping] Call Waiting - who does the tone (round 2) Date: Tue, 24 Jun 2003 09:40:51 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0255_01C33A34.B353F480" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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_0255_01C33A34.B353F480 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 aGkgOg0KIEkgdGhpbmsgIG1heWh5J3MgbmV3IGRyYWZ0IGh0dHA6Ly93d3cuc29mdGFybW9yLmNv bS9zaXBwaW5nL2RyYWZ0cy9kcmFmdC1tYWh5LXNpcHBpbmctdG9uZXMtMDAudHh0ICwgZ2l2ZSBh IGdvb2Qgc29sdXRpb24gdG8gdGhpcyBwcm9ibGVtLiBpdCB1c2UgYW4gZXh0ZW5kZWQgTUlNRSB0 eXBlIHRvIGNhcnJ5IHRvbmUgZGVzY3JpcHRpb24gaW4gWE1MIHRvIG5vdGlmeSBzaXAgdGVybWlu YWwgb2YgdG9uZSdzIHR5cGUuIA0KICBidXQgaXQgbmVlZCBzaXAgdGVybWluYWwgbWFrZSBhIGNo YW5nZSB0byBzdXBwb3J0IGl0Lg0KDQpKb2hueSBXZW5nDQogIC0tLS0tIE9yaWdpbmFsIE1lc3Nh Z2UgLS0tLS0gDQogIEZyb206IE1waWVyY2UxQGFvbC5jb20gDQogIFRvOiBoaXNoYW0ua2hhcnRh YmlsQG5va2lhLmNvbSANCiAgQ2M6IHNpcHBpbmdAaWV0Zi5vcmcgDQogIFNlbnQ6IFR1ZXNkYXks IEp1bmUgMjQsIDIwMDMgMTI6MDIgQU0NCiAgU3ViamVjdDogUmU6IFtTaXBwaW5nXSBDYWxsIFdh aXRpbmcgLSB3aG8gZG9lcyB0aGUgdG9uZSAocm91bmQgMikNCg0KDQogIEluIGEgbWVzc2FnZSBk YXRlZCA2LzIzLzIwMDMgNDo1OTo0MSBBTSBFYXN0ZXJuIFN0YW5kYXJkIFRpbWUsIGhpc2hhbS5r aGFydGFiaWxAbm9raWEuY29tIHdyaXRlczogDQoNCg0KDQogICAgQSBjYWxsIHN0YXRlZnVsIHBy b3h5IGNhbiBkZWNpZGUgdG8gZm9yd2FyZCBvciBub3QgdG8gZm9yd2FyZCBhbiBJTlZJVEUgdG8g YSBVQSB0aGF0IGlzIGFscmVhZHkgaW4gYW5vdGhlciBjYWxsLiBUaGUgZGVjaXNpb24gY2FuIGJl IGJhc2VkIG9uIGFueXRoaW5nIGluY2x1ZGluZyBjaGFyZ2luZyAoIGEgdXNlciBoYXMgcGF5ZWQg Zm9yIGNhbGwgZm9yd2FyZGluZykuIElmIHRoZSBwcm94eSBkZWNpZGVzIHRvIGZvcndhcmQgdGhl IElOVklURSwgaXQgaXMgdGhlIFVBIHRoYXQgcGxheXMgdGhlIHRvbmUgd2hlbiBpdCByZWNlaXZl cyB0aGUgSU5WSVRFLiANCg0KICAgIE5ldHdvcmsgY29udHJvbHMgdGhlIHNlcnZpY2UsIFVBIERP RVMgdGhlIHRvbmUuIA0KDQogICAgRGlkIEkgbWlzcyBhbnl0aGluZz8gDQoNCg0KDQogIEkgYmVs aWV2ZSB5b3UgaGF2ZSBpdCBjb3JyZWN0LiBCdXQgdGhlIHF1ZXN0aW9uIGFsd2F5cyBjb21lcyBk b3duIHRvLCBpZiB0aGUgVUEgaXRzZWxmIGdlbmVyYXRlcyB0aGUgdG9uZSAodW5kZXIgY29udHJv bCBvZiB0aGUgbmV0d29yayksIHdoYXQgaWYgdGhlIG5ldHdvcmsgd2FudHMgdG8gaW50cm9kdWNl IGEgbmV3IHNlcnZpY2Ugb3IgZmVhdHVyZSB3aGljaCByZXF1aXJlcyBhIG5ldyB0b25lLiBDYW4g aXQgYmUgYXNzdXJlZCB0aGF0IGV2ZXJ5IGV4aXN0aW5nIFVBIGNhbiBnZW5lcmF0ZSB0aGF0IG5l dyB0b25lPyBDb252ZXJzZWx5LCBpZiB0aGUgVUEgY29udHJvbHMgdGhlIHNlcnZpY2VzLCBpdCB3 b3VsZCBjZXJ0YWlubHkgYmUgdGhlIGNhc2UgdGhhdCBvbGQgVUFzIGNvdWxkIG5vdCBoYW5kbGUg YSBuZXcgc2VydmljZS4gDQoNCiAgTWlrZSBQaWVyY2UgDQoNCg== ------=_NextPart_000_0255_01C33A34.B353F480 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDUuMDAuMjkyMC4wIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFEPg0K PEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsg c2l6ZT0yPmhpIDo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3 OyBzaXplPTI+Jm5ic3A7SSB0aGluayZuYnNwOyBtYXloeSdzIG5ldyBkcmFmdCA8QSANCmhyZWY9 Imh0dHA6Ly93d3cuc29mdGFybW9yLmNvbS9zaXBwaW5nL2RyYWZ0cy9kcmFmdC1tYWh5LXNpcHBp bmctdG9uZXMtMDAudHh0Ij5odHRwOi8vd3d3LnNvZnRhcm1vci5jb20vc2lwcGluZy9kcmFmdHMv ZHJhZnQtbWFoeS1zaXBwaW5nLXRvbmVzLTAwLnR4dDwvQT4gDQosIGdpdmUgYSBnb29kIHNvbHV0 aW9uIHRvIHRoaXMgcHJvYmxlbS4gaXQgdXNlIGFuIGV4dGVuZGVkIE1JTUUgdHlwZSB0byBjYXJy eSANCnRvbmUgZGVzY3JpcHRpb24gaW4gWE1MIHRvIG5vdGlmeSBzaXAgdGVybWluYWwgb2YgdG9u ZSdzIHR5cGUuIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7 IHNpemU9Mj4mbmJzcDsgYnV0IGl0IG5lZWQgc2lwIHRlcm1pbmFsIG1ha2UgYSZuYnNwO2NoYW5n ZSB0byANCnN1cHBvcnQgaXQuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj5Kb2hueSBXZW5nPC9GT05UPjwvRElW Pg0KPEJMT0NLUVVPVEUgDQpzdHlsZT0iQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBN QVJHSU4tTEVGVDogNXB4OyBNQVJHSU4tUklHSFQ6IDBweDsgUEFERElORy1MRUZUOiA1cHg7IFBB RERJTkctUklHSFQ6IDBweCI+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAz MDc7Ij4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KICA8RElWIHN0eWxlPSJC QUNLR1JPVU5EOiAjZTRlNGU0OyBGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OzsgZm9udC1jb2xv cjogYmxhY2siPjxCPkZyb206PC9CPiANCiAgPEEgaHJlZj0ibWFpbHRvOk1waWVyY2UxQGFvbC5j b20iIHRpdGxlPU1waWVyY2UxQGFvbC5jb20+TXBpZXJjZTFAYW9sLmNvbTwvQT4gDQogIDwvRElW Pg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+VG86PC9CPiA8 QSANCiAgaHJlZj0ibWFpbHRvOmhpc2hhbS5raGFydGFiaWxAbm9raWEuY29tIiANCiAgdGl0bGU9 aGlzaGFtLmtoYXJ0YWJpbEBub2tpYS5jb20+aGlzaGFtLmtoYXJ0YWJpbEBub2tpYS5jb208L0E+ IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+Q2M6 PC9CPiA8QSBocmVmPSJtYWlsdG86c2lwcGluZ0BpZXRmLm9yZyIgDQogIHRpdGxlPXNpcHBpbmdA aWV0Zi5vcmc+c2lwcGluZ0BpZXRmLm9yZzwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6 IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5TZW50OjwvQj4gVHVlc2RheSwgSnVuZSAyNCwgMjAw MyAxMjowMiBBTTwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3 OyI+PEI+U3ViamVjdDo8L0I+IFJlOiBbU2lwcGluZ10gQ2FsbCBXYWl0aW5nIC0gd2hvIA0KICBk b2VzIHRoZSB0b25lIChyb3VuZCAyKTwvRElWPg0KICA8RElWPjxCUj48L0RJVj48Rk9OVCBmYWNl PWFyaWFsLGhlbHZldGljYT48Rk9OVCBzaXplPTI+SW4gYSBtZXNzYWdlIGRhdGVkIA0KICA2LzIz LzIwMDMgNDo1OTo0MSBBTSBFYXN0ZXJuIFN0YW5kYXJkIFRpbWUsIDxBIA0KICBocmVmPSJtYWls dG86aGlzaGFtLmtoYXJ0YWJpbEBub2tpYS5jb20iPmhpc2hhbS5raGFydGFiaWxAbm9raWEuY29t PC9BPiANCiAgd3JpdGVzOiA8QlI+PEJSPjxCUj4NCiAgPEJMT0NLUVVPVEUgDQogIHN0eWxlPSJC T1JERVItTEVGVDogIzAwMDBmZiAycHggc29saWQ7IE1BUkdJTi1MRUZUOiA1cHg7IE1BUkdJTi1S SUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVweCIgDQogIFRZUEU9IkNJVEUiPkEgY2FsbCBzdGF0 ZWZ1bCBwcm94eSBjYW4gZGVjaWRlIHRvIGZvcndhcmQgb3Igbm90IHRvIGZvcndhcmQgYW4gDQog ICAgSU5WSVRFIHRvIGEgVUEgdGhhdCBpcyBhbHJlYWR5IGluIGFub3RoZXIgY2FsbC4gVGhlIGRl Y2lzaW9uIGNhbiBiZSBiYXNlZCBvbiANCiAgICBhbnl0aGluZyBpbmNsdWRpbmcgY2hhcmdpbmcg KCBhIHVzZXIgaGFzIHBheWVkIGZvciBjYWxsIGZvcndhcmRpbmcpLiBJZiB0aGUgDQogICAgcHJv eHkgZGVjaWRlcyB0byBmb3J3YXJkIHRoZSBJTlZJVEUsIGl0IGlzIHRoZSBVQSB0aGF0IHBsYXlz IHRoZSB0b25lIHdoZW4gDQogICAgaXQgcmVjZWl2ZXMgdGhlIElOVklURS4gPEJSPjxCUj5OZXR3 b3JrIGNvbnRyb2xzIHRoZSBzZXJ2aWNlLCBVQSBET0VTIHRoZSANCiAgICB0b25lLiA8QlI+PEJS PkRpZCBJIG1pc3MgYW55dGhpbmc/IDxCUj48L0ZPTlQ+PEZPTlQgY29sb3I9IzAwMDAwMCBmYWNl PUFyaWFsIA0KICAgIGxhbmc9MCBzaXplPTMgRkFNSUxZPSJTQU5TU0VSSUYiPjwvQkxPQ0tRVU9U RT48QlI+PC9GT05UPjxGT05UIGNvbG9yPSMwMDAwMDAgDQogIGZhY2U9QXJpYWwgbGFuZz0wIHNp emU9MiBGQU1JTFk9IlNBTlNTRVJJRiI+PEJSPkkgYmVsaWV2ZSB5b3UgaGF2ZSBpdCBjb3JyZWN0 LiANCiAgQnV0IHRoZSBxdWVzdGlvbiBhbHdheXMgY29tZXMgZG93biB0bywgaWYgdGhlIFVBIGl0 c2VsZiBnZW5lcmF0ZXMgdGhlIHRvbmUgDQogICh1bmRlciBjb250cm9sIG9mIHRoZSBuZXR3b3Jr KSwgd2hhdCBpZiB0aGUgbmV0d29yayB3YW50cyB0byBpbnRyb2R1Y2UgYSBuZXcgDQogIHNlcnZp Y2Ugb3IgZmVhdHVyZSB3aGljaCByZXF1aXJlcyBhIG5ldyB0b25lLiBDYW4gaXQgYmUgYXNzdXJl ZCB0aGF0IGV2ZXJ5IA0KICBleGlzdGluZyBVQSBjYW4gZ2VuZXJhdGUgdGhhdCBuZXcgdG9uZT8g Q29udmVyc2VseSwgaWYgdGhlIFVBIGNvbnRyb2xzIHRoZSANCiAgc2VydmljZXMsIGl0IHdvdWxk IGNlcnRhaW5seSBiZSB0aGUgY2FzZSB0aGF0IG9sZCBVQXMgY291bGQgbm90IGhhbmRsZSBhIG5l dyANCiAgc2VydmljZS4gPEJSPjxCUj5NaWtlIFBpZXJjZSA8QlI+PC9CTE9DS1FVT1RFPjwvRk9O VD48L0ZPTlQ+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0255_01C33A34.B353F480-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 24 03:06:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05845 for ; Tue, 24 Jun 2003 03:06:38 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5O76B625255 for sipping-archive@odin.ietf.org; Tue, 24 Jun 2003 03:06:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UhsZ-0006ZG-MF for sipping-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 03:06: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 DAA05822 for ; Tue, 24 Jun 2003 03:06:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UhsV-000165-00 for sipping-web-archive@ietf.org; Tue, 24 Jun 2003 03:06:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UhsQ-000162-00 for sipping-web-archive@ietf.org; Tue, 24 Jun 2003 03:06:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UhsP-0006VR-Lo; Tue, 24 Jun 2003 03: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 19Uhri-0006T2-Ar for sipping@optimus.ietf.org; Tue, 24 Jun 2003 03:05: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 DAA05787 for ; Tue, 24 Jun 2003 03:05:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uhre-00015T-00 for sipping@ietf.org; Tue, 24 Jun 2003 03:05:14 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19UhrT-00015P-00 for sipping@ietf.org; Tue, 24 Jun 2003 03:05:03 -0400 Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5O75Ycv024273; Tue, 24 Jun 2003 09:05:34 +0200 Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYR1QNQ; Tue, 24 Jun 2003 09:06:23 +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 h5O74ISZ014814; Tue, 24 Jun 2003 10:04:18 +0300 (EET DST) Message-ID: <3EF7F803.13F09411@lmf.ericsson.se> Date: Tue, 24 Jun 2003 10:04:35 +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: sipping CC: "Vesa Torvinen (LMF)" , Jari Arkko , Dean Willis , Rohan Mahy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] AKAv2 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk 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 would like to bring your attention to the draft below: http://www.ietf.org/internet-drafts/draft-torvinen-http-digest-aka-v2-00.txt It defines a new version for the HTTP digest AKA algorithm. The authors would appreciate comments on it from the SIP community. 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 From exim@www1.ietf.org Tue Jun 24 06:37:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10129 for ; Tue, 24 Jun 2003 06:37:42 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OAbGG18075 for sipping-archive@odin.ietf.org; Tue, 24 Jun 2003 06:37:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UlAq-0004hK-5o for sipping-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 06:37: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 GAA10121 for ; Tue, 24 Jun 2003 06:37:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UlAm-0001zl-00 for sipping-web-archive@ietf.org; Tue, 24 Jun 2003 06:37:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UlAg-0001zi-00 for sipping-web-archive@ietf.org; Tue, 24 Jun 2003 06:37:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UlAb-0004VP-As; Tue, 24 Jun 2003 06: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 19UlA6-0004T1-F7 for sipping@optimus.ietf.org; Tue, 24 Jun 2003 06:36:30 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09970; Tue, 24 Jun 2003 06:36:25 -0400 (EDT) Message-Id: <200306241036.GAA09970@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 24 Jun 2003 06:36:25 -0400 Subject: [Sipping] I-D ACTION:draft-olson-sipping-refer-extensions-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 : Extensions to the REFER mechanism for Third Party Call Control Author(s) : S. Olson Filename : draft-olson-sipping-refer-extensions-00.txt Pages : 29 Date : 2003-6-23 This document proposes a number of extensions to the REFER method used by the Session Initiation Protocol (SIP) for the purpose of third party call control. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-olson-sipping-refer-extensions-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-olson-sipping-refer-extensions-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-olson-sipping-refer-extensions-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-23142049.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-olson-sipping-refer-extensions-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-olson-sipping-refer-extensions-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-23142049.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 Tue Jun 24 06:57:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11053 for ; Tue, 24 Jun 2003 06:57:37 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OAvBg20728 for sipping-archive@odin.ietf.org; Tue, 24 Jun 2003 06:57:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UlU7-0005OF-6r for sipping-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 06:57: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 GAA11018 for ; Tue, 24 Jun 2003 06:57:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UlU3-00025v-00 for sipping-web-archive@ietf.org; Tue, 24 Jun 2003 06:57:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UlTx-00025s-00 for sipping-web-archive@ietf.org; Tue, 24 Jun 2003 06: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 19UlTy-0005L3-4J; Tue, 24 Jun 2003 06: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 19UlTu-0005Ka-Rt for sipping@optimus.ietf.org; Tue, 24 Jun 2003 06:56:58 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10959; Tue, 24 Jun 2003 06:56:53 -0400 (EDT) Message-Id: <200306241056.GAA10959@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 24 Jun 2003 06:56:53 -0400 Subject: [Sipping] I-D ACTION:draft-sharath-sipb-requirements-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 : 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-requirements-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. --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-23142408.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-sharath-sipb-requirements-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-sharath-sipb-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-23142408.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 Tue Jun 24 07:28:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12169 for ; Tue, 24 Jun 2003 07:28:47 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OBS9O26513 for sipping-archive@odin.ietf.org; Tue, 24 Jun 2003 07: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 19Uly5-0006tY-SF for sipping-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 07: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 HAA12137 for ; Tue, 24 Jun 2003 07:28:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uly5-0002Go-00 for sipping-web-archive@ietf.org; Tue, 24 Jun 2003 07:28:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ulxz-0002Gl-00 for sipping-web-archive@ietf.org; Tue, 24 Jun 2003 07:28:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ulxx-0006se-O9; Tue, 24 Jun 2003 07: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 19Ulxo-0006s5-Bu for sipping@optimus.ietf.org; Tue, 24 Jun 2003 07:27: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 HAA12119 for ; Tue, 24 Jun 2003 07:27:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UlxY-0002GM-00 for sipping@ietf.org; Tue, 24 Jun 2003 07:27:36 -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 19UlxN-0002G9-00 for sipping@ietf.org; Tue, 24 Jun 2003 07:27:25 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5OBPbw2010961 for ; Tue, 24 Jun 2003 13:25:37 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 24 Jun 2003 13:27:51 +0200 Message-ID: From: "Christer Holmberg (LMF)" To: "'sipping@ietf.org'" Subject: RE: [Sipping] I-D ACTION:draft-sharath-sipb-requirements-00.txt Date: Tue, 24 Jun 2003 13:25:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, A comment on DS-3. I really wonder if using the topmost Via for implementing a "last call = return" feature is going to work... But, assuming it DOES work, my question is: since the Via only contains = (in URI terms) a host part, where do you take the user part from? If = you send a request with only a host in the Request-URI, even if allowed = by the protocol, how can you be sure it will reach the same user that = tried to call you? Regards, Christer Holmberg Ericsson Finland -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: 24. kes=E4kuuta 2003 13:57 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=20 Implementing Business Telephony Features on = SIP=20 Endpoints Author(s) : V. Venkataramanan, S. Rajasekar Filename : draft-sharath-sipb-requirements-00.txt Pages : 16 Date : 2003-6-23 =09 This informational internet draft describes the requirements for a=20 standard business telephone based on the Session Initiation Protocol=20 (SIP). The objective of this document is to provide a minimum set of=20 requirements for implementing business features on SIP endpoints. =20 This draft is intended to serve as a requirements document for=20 vendors implementing business features on SIP based=20 devices/entities. Details of how each capability or feature is best=20 implemented in SIP, is beyond the scope of this document and may be=20 tracked through the working group draft submissions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sharath-sipb-requirements-00.t= xt To remove yourself from the IETF Announcement list, send a message to=20 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=20 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". =09 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. =09 =09 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 Tue Jun 24 09:02:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14528 for ; Tue, 24 Jun 2003 09:02:41 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OD2D003900 for sipping-archive@odin.ietf.org; Tue, 24 Jun 2003 09:02:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UnR7-00010p-24 for sipping-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 09:02: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 JAA14515 for ; Tue, 24 Jun 2003 09:02:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UnR5-0002ks-00 for sipping-web-archive@ietf.org; Tue, 24 Jun 2003 09:02:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UnQz-0002kp-00 for sipping-web-archive@ietf.org; Tue, 24 Jun 2003 09: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 19UnQv-0000zh-2o; Tue, 24 Jun 2003 09: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 19UnQh-0000zU-5Q for sipping@optimus.ietf.org; Tue, 24 Jun 2003 09:01: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 JAA14511 for ; Tue, 24 Jun 2003 09:01:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UnQf-0002kh-00 for sipping@ietf.org; Tue, 24 Jun 2003 09:01:45 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19UnQU-0002k0-00 for sipping@ietf.org; Tue, 24 Jun 2003 09:01:34 -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 JAA23153 for ; Tue, 24 Jun 2003 09:00:42 -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 JAA07511 for ; Tue, 24 Jun 2003 09:00:42 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jun 2003 09:00:42 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5B26@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: sipping@ietf.org Subject: RE: [Sipping] I-D ACTION:draft-sharath-sipb-requirements-00.txt Date: Tue, 24 Jun 2003 09:00:36 -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: , 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 From exim@www1.ietf.org Tue Jun 24 10:26:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18195 for ; Tue, 24 Jun 2003 10:26:05 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OEPcg17591 for sipping-archive@odin.ietf.org; Tue, 24 Jun 2003 10:25:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uojq-0004Ze-Hh for sipping-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 10:25:38 -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 KAA18175 for ; Tue, 24 Jun 2003 10:25:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UojF-0004Ul-PM; Tue, 24 Jun 2003 10: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 19UojA-0004U1-TE for sipping@optimus.ietf.org; Tue, 24 Jun 2003 10:24: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 KAA18163 for ; Tue, 24 Jun 2003 10:24:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uoit-0003GI-00 for sipping@ietf.org; Tue, 24 Jun 2003 10:24:39 -0400 Received: from [203.254.224.25] (helo=mailout2.samsung.com) by ietf-mx with esmtp (Exim 4.12) id 19Uoih-0003Fh-00 for sipping@ietf.org; Tue, 24 Jun 2003 10:24:28 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HGZ00301P7I22@mailout2.samsung.com> for sipping@ietf.org; Tue, 24 Jun 2003 23:21:18 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HGZ001YAP7I86@mailout2.samsung.com> for sipping@ietf.org; Tue, 24 Jun 2003 23:21:18 +0900 (KST) Received: from RANJITKUMAR ([107.108.7.233]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTPA id <0HGZ00CJSP7GP0@mmp1.samsung.com> for sipping@ietf.org; Tue, 24 Jun 2003 23:21:18 +0900 (KST) Date: Tue, 24 Jun 2003 19:46:19 +0530 From: Ranjit Avasarala Subject: RE: [Sipping] I-D ACTION:draft-sharath-sipb-requirements-00.txt In-reply-to: <313680C9A886D511A06000204840E1CF070B5B26@whq-msgusr-02.pit.comms.marconi.com> To: "'Rosen, Brian'" , sipping@ietf.org Reply-to: ranjitk@samsung.com Message-id: <000001c33a5b$2f2eb150$e9076c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 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 Hi I think 488 Not Acceptable Here with Retry-After: would be more appropriate response for a DnD feature rather than a 486 busy here Ranjit -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of Rosen, Brian Sent: Tuesday, June 24, 2003 6:31 PM 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 From exim@www1.ietf.org Tue Jun 24 11:08:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19585 for ; Tue, 24 Jun 2003 11:08:40 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OF8EO25080 for sipping-archive@odin.ietf.org; Tue, 24 Jun 2003 11: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 19UpP4-0006WR-Bj for sipping-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 11: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 LAA19573 for ; Tue, 24 Jun 2003 11:08:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UpP1-0003Xc-00 for sipping-web-archive@ietf.org; Tue, 24 Jun 2003 11:08:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UpOv-0003XZ-00 for sipping-web-archive@ietf.org; Tue, 24 Jun 2003 11: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 19UpOr-0006TS-Ij; Tue, 24 Jun 2003 11:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UpOH-0006PO-FS for sipping@optimus.ietf.org; Tue, 24 Jun 2003 11:07: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 LAA19557 for ; Tue, 24 Jun 2003 11:07:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UpOE-0003X8-00 for sipping@ietf.org; Tue, 24 Jun 2003 11:07:22 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19UpO2-0003X1-00 for sipping@ietf.org; Tue, 24 Jun 2003 11:07:11 -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; Tue, 24 Jun 2003 16:09:47 +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] I-D ACTION:draft-sharath-sipb-requirements-00.txt Date: Tue, 24 Jun 2003 16:06:48 +0100 Message-ID: <45730E094814E44488F789C1CDED27AE01E22BF3@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Sipping] I-D ACTION:draft-sharath-sipb-requirements-00.txt Thread-Index: AcM6XHB5N26uiS02Qz2snWhbDQ2RvgABYazA From: "Chris Boulton" To: , "Rosen, Brian" , Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Why is this a better response code? Isn't 488 usually associated with content negotiation (offer) problems. Chris. =20 >-----Original Message----- >From: Ranjit Avasarala [mailto:ranjitk@samsung.com] >Sent: 24 June 2003 15:16 >To: 'Rosen, Brian'; sipping@ietf.org >Subject: RE: [Sipping] I-D ACTION:draft-sharath-sipb-requirements-00.txt > >Hi > I think 488 Not Acceptable Here with Retry-After: would be more >appropriate response for a DnD feature rather than a 486 busy here > >Ranjit > >-----Original Message----- >From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf >Of Rosen, Brian >Sent: Tuesday, June 24, 2003 6:31 PM >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/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 24 15:09:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04076 for ; Tue, 24 Jun 2003 15:09:37 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OJ9A304952 for sipping-archive@odin.ietf.org; Tue, 24 Jun 2003 15: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 19UtAE-0001Hn-KN for sipping-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 15: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 PAA03992 for ; Tue, 24 Jun 2003 15:09:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UtAB-000668-00 for sipping-web-archive@ietf.org; Tue, 24 Jun 2003 15:09:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UtA6-000665-00 for sipping-web-archive@ietf.org; Tue, 24 Jun 2003 15: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 19UtA5-0001Eq-UZ; Tue, 24 Jun 2003 15: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 19Ut9x-0001EB-UE for sipping@optimus.ietf.org; Tue, 24 Jun 2003 15:08: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 PAA03887 for ; Tue, 24 Jun 2003 15:08:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ut9g-00065r-00 for sipping@ietf.org; Tue, 24 Jun 2003 15:08:36 -0400 Received: from [65.200.90.207] (helo=mailserver.sylantro.com) by ietf-mx with smtp (Exim 4.12) id 19Ut9V-000659-00 for sipping@ietf.org; Tue, 24 Jun 2003 15:08:25 -0400 Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Tue, 24 Jun 2003 12:06:54 -0700 X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Received: by mailserver.sylantro.com with Internet Mail Service ( 5.5.2653.19) id ; Tue, 24 Jun 2003 12:06:54 -0700 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD023BCAEE@mailserver.sylantro.com> From: "Venkatesh Venkataramanan" To: "'Christer Holmberg (LMF)'" , "'sipping@ietf.org'" cc: "Sharath Rajasekar" Subject: RE: [Sipping] I-D ACTION:draft-sharath-sipb-requirements-00.txt Date: Tue, 24 Jun 2003 12:06:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 12E67EC458103-01-01 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 You are correct about the Via header. That was an error !! We had a = couple of ideas we had in mind and this was something we had thought about = earlier on but had decided against it. We will fix this. Thanks for pointing it = out. regards, Venkatesh -----Original Message----- From: Christer Holmberg (LMF) = [mailto:Christer.Holmberg@lmf.ericsson.se] Sent: Tuesday, June 24, 2003 4:25 AM To: 'sipping@ietf.org' Subject: RE: [Sipping] I-D = ACTION:draft-sharath-sipb-requirements-00.txt Hi, A comment on DS-3. I really wonder if using the topmost Via for implementing a "last call return" feature is going to work... But, assuming it DOES work, my question is: since the Via only contains = (in URI terms) a host part, where do you take the user part from? If you = send a request with only a host in the Request-URI, even if allowed by the protocol, how can you be sure it will reach the same user that tried to = call you? Regards, Christer Holmberg Ericsson Finland -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: 24. kes=E4kuuta 2003 13:57 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=20 Implementing Business Telephony Features on = SIP=20 Endpoints Author(s) : V. Venkataramanan, S. Rajasekar Filename : draft-sharath-sipb-requirements-00.txt Pages : 16 Date : 2003-6-23 =09 This informational internet draft describes the requirements for a=20 standard business telephone based on the Session Initiation Protocol=20 (SIP). The objective of this document is to provide a minimum set of=20 requirements for implementing business features on SIP endpoints. =20 This draft is intended to serve as a requirements document for=20 vendors implementing business features on SIP based=20 devices/entities. Details of how each capability or feature is best=20 implemented in SIP, is beyond the scope of this document and may be=20 tracked through the working group draft submissions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sharath-sipb-requirements-00.t= xt To remove yourself from the IETF Announcement list, send a message to=20 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=20 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". =09 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. =09 =09 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 From exim@www1.ietf.org Tue Jun 24 15:18:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05403 for ; Tue, 24 Jun 2003 15:18:42 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OJIEO07157 for sipping-archive@odin.ietf.org; Tue, 24 Jun 2003 15:18:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UtJ0-0001rM-4m for sipping-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 15:18: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 PAA05310 for ; Tue, 24 Jun 2003 15:18:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UtIy-0006Cp-00 for sipping-web-archive@ietf.org; Tue, 24 Jun 2003 15:18:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UtIs-0006Cm-00 for sipping-web-archive@ietf.org; Tue, 24 Jun 2003 15:18:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UtIo-0001eg-02; Tue, 24 Jun 2003 15: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 19UtIS-0001dj-83 for sipping@optimus.ietf.org; Tue, 24 Jun 2003 15:17: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 PAA05142 for ; Tue, 24 Jun 2003 15:17:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UtIC-0006Bp-00 for sipping@ietf.org; Tue, 24 Jun 2003 15:17:24 -0400 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by ietf-mx with esmtp (Exim 4.12) id 19UtI1-0006BA-00 for sipping@ietf.org; Tue, 24 Jun 2003 15:17:13 -0400 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HH0009BO2UYCN@firewall.wcom.com> for sipping@ietf.org; Tue, 24 Jun 2003 19:16:10 +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 <0HH000B012UV9X@pmismtp01.wcomnet.com>; Tue, 24 Jun 2003 19:16:10 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.122.248]) by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HH00093P2UUNV@pmismtp01.wcomnet.com>; Tue, 24 Jun 2003 19:16:08 +0000 (GMT) Date: Tue, 24 Jun 2003 14:16:03 -0500 From: Alan Johnston X-Sender: Alan.Johnston@pop.mcit.com To: sipping@ietf.org Cc: Adam Roach Message-id: <5.2.1.1.0.20030624141219.023d2e68@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] Centralized Conferencing (xcon) BOF Announcement Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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. Centralized Conferencing BOF (xcon) Tuesday, July 15 at 1700-1800 ============================== CHAIRS: Alan Johnston (alan.johnston@mci.com) Adam Roach (adam@dynamicsoft.com) AGENDA: - Intro and Agenda Bashing (5 min) - Problem Statement and Overview of Scope (10 min) - Charter Discussion (15 min) - Open Discussion (30 min) Description of Proposed Working Group The focus of this working group is to develop a standardized suite of protocols for tightly-coupled multimedia conferences, where strong security and authorization requirements are integral to the solution. Tightly-coupled conferences have a central point of control and authorization so they can enforce specific media and membership relationships, and provide an accurate roster of participants. The media mixing or combining function of a tightly-coupled conference need not be performed centrally, however. Unlike previous attempts at standardizing conferencing-related activities, the scope of this effort is intentionally very narrow, and is intended to enable interoperability in a commercial environment which already has a number of implementations. Privacy, security, and authorization mechanisms are integral to the solution generated by the working group. This includes allowing participants to be completely invisible or to be visible but participate anonymously with respect to some or all of the other participants. Authorization rules allow for participants and non-participants to have roles (ex: speaker, moderator, owner), and to be otherwise authorized to perform membership and media manipulation for or on behalf of other participants. In order to preserve these properties, the protocols used will require implementation of channel security and authentication services. Initially this combination of protocols will be specified with respect to session setup with SIP, but most of the specific components would be applicable to conferences setup using other protocols. [None of the protocols defined by this group will be SIP or require SIP extensions.] The group will use the high-level requirements and framework already described by documents published by the SIPPING WG. The deliverables for the group will be: - A mechanism for membership and authorization control - A mechanism to manipulate and describe media "layout" or "topology" for multiple media types (audio, video, text) - A mechanism for notification of conference related events/changes (for example a roster) - A basic floor control protocol - Peer-to-peer cascading of conferences (one conference is a participant in another and vice versa) The following items are specifically out-of-scope: - Voting - Multicast media (due to security concerns) - Fully distributed conferences - Loosely-coupled conferences (no central point of control) - Far-end device control - Protocol used between the conference controller and the mixer(s) - Capabilities negotiation of the mixer(s) - Master-slave cascaded conferences The working group will coordinate closely with the SIPPING and MMUSIC working groups. In addition the working group will cooperate with other groups as needed, including SIP, AVT, and the W3C SMIL working groups. In addition, the working group will consider a number of existing drafts (a non-exhaustive list is included below) as input to the working group. Related documents in other working groups: - draft-ietf-sipping-conferencing-requirements-00.txt - draft-ietf-sipping-conferencing-framework-00.txt - draft-ietf-sipping-cc-conferencing-00.txt - draft-ietf-sipping-cc-framework-02.txt - draft-ietf-sipping-conference-package-00.txt Partial list of input documents: (All documents available at http://ee.wustl.edu/~alan/xcon/ until they appear in the IETF archives.) - draft-even-xcon-conference-scenarios-00.txt - draft-koskelainen-xcon-cpcp-reqs-00.txt - draft-even-xcon-media-policy-requirements-00.txt - draft-koskelainen-xcon-floor-control-req-00.txt - draft-koskelainen-xcon-xcap-cpcp-usage-00.txt - draft-levin-xcon-cpcp-00.txt - draft-mahy-xcon-media-policy-control-00.txt Comments on the above drafts are welcome on the xcon mailing list: 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 Tue Jun 24 15:19:36 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 PAA05537 for ; Tue, 24 Jun 2003 15:19:36 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OJJ8908070 for sipping-archive@odin.ietf.org; Tue, 24 Jun 2003 15:19:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UtJr-000265-U5 for sipping-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 15: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 PAA05485 for ; Tue, 24 Jun 2003 15:19:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UtJq-0006EG-00 for sipping-web-archive@ietf.org; Tue, 24 Jun 2003 15:19:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UtJl-0006ED-00 for sipping-web-archive@ietf.org; Tue, 24 Jun 2003 15:19:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UtJl-0001zr-9B; Tue, 24 Jun 2003 15: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 19UtJO-0001xJ-Cf for sipping@optimus.ietf.org; Tue, 24 Jun 2003 15:18: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 PAA05370 for ; Tue, 24 Jun 2003 15:18:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UtJN-0006D6-00 for sipping@ietf.org; Tue, 24 Jun 2003 15:18:37 -0400 Received: from [65.200.90.207] (helo=mailserver.sylantro.com) by ietf-mx with smtp (Exim 4.12) id 19UtJA-0006C6-00 for sipping@ietf.org; Tue, 24 Jun 2003 15:18:25 -0400 Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Tue, 24 Jun 2003 12:17:14 -0700 X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Received: by mailserver.sylantro.com with Internet Mail Service ( 5.5.2653.19) id ; Tue, 24 Jun 2003 12:17:14 -0700 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD023BCAEF@mailserver.sylantro.com> From: "Venkatesh Venkataramanan" To: "'Rosen, Brian'" , sipping@ietf.org cc: "Sharath Rajasekar" Subject: RE: [Sipping] I-D ACTION:draft-sharath-sipb-requirements-00.txt Date: Tue, 24 Jun 2003 12:17:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 12E67C3058335-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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 From exim@www1.ietf.org Tue Jun 24 16:14:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08319 for ; Tue, 24 Jun 2003 16:14:38 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OKEAR16680 for sipping-archive@odin.ietf.org; Tue, 24 Jun 2003 16:14:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UuB8-0004Kx-H8 for sipping-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 16: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 QAA08303 for ; Tue, 24 Jun 2003 16:14:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UuB6-0006mJ-00 for sipping-web-archive@ietf.org; Tue, 24 Jun 2003 16:14:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UuB1-0006mG-00 for sipping-web-archive@ietf.org; Tue, 24 Jun 2003 16:14:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UuAz-0004K1-37; Tue, 24 Jun 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 19UuA2-0004J4-8T for sipping@optimus.ietf.org; Tue, 24 Jun 2003 16:13: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 QAA08159 for ; Tue, 24 Jun 2003 16:12:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uu9l-0006lF-00 for sipping@ietf.org; Tue, 24 Jun 2003 16:12:45 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19Uu9a-0006ko-00 for sipping@ietf.org; Tue, 24 Jun 2003 16:12:34 -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 QAA10334; Tue, 24 Jun 2003 16:11:41 -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 QAA08795; Tue, 24 Jun 2003 16:11:42 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jun 2003 16:11:42 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5B31@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Venkatesh Venkataramanan'" , sipping@ietf.org Cc: Sharath Rajasekar Subject: RE: [Sipping] I-D ACTION:draft-sharath-sipb-requirements-00.txt Date: Tue, 24 Jun 2003 16:11:40 -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: , My problem is that if an RFC resulting from this work requires your definition of DND, and my phone implements my definition of DND, then I am not compliant to the RFC. I think my definition is a "better" definition of what phones ought to do; yours i _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 24 16:56:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10771 for ; Tue, 24 Jun 2003 16:56:37 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OKtDS22155 for sipping-archive@odin.ietf.org; Tue, 24 Jun 2003 16:55:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uuoq-0005lG-To for sipping-web-archive@optimus.ietf.org; Tue, 24 Jun 2003 16:55: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 QAA10734 for ; Tue, 24 Jun 2003 16:55:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uuoo-0007EX-00 for sipping-web-archive@ietf.org; Tue, 24 Jun 2003 16:55:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Uuoj-0007EU-00 for sipping-web-archive@ietf.org; Tue, 24 Jun 2003 16:55:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uuof-0005kL-Uo; Tue, 24 Jun 2003 16: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 19UuoQ-0005jy-Sn for sipping@optimus.ietf.org; Tue, 24 Jun 2003 16:54: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 QAA10717 for ; Tue, 24 Jun 2003 16:54:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UuoO-0007EA-00 for sipping@ietf.org; Tue, 24 Jun 2003 16:54:44 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19UuoD-0007E1-00 for sipping@ietf.org; Tue, 24 Jun 2003 16:54: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 QAA11557; Tue, 24 Jun 2003 16:53:55 -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 QAA13637; Tue, 24 Jun 2003 16:53:57 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jun 2003 16:53:56 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5B35@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Venkatesh Venkataramanan'" , sipping@ietf.org Cc: Sharath Rajasekar Subject: RE: [Sipping] I-D ACTION:draft-sharath-sipb-requirements-00.txt Date: Tue, 24 Jun 2003 16:53:51 -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 below reply somehow got mangled. About 2/3 of it got deleted. I'm guessing it was operator error, since my "sent items" folder is also mangled. The full reply was supposed to be something like: My problem is that if an RFC resulting from this work requires your definition of DND, and my phone implements my definition of DND, then I am not compliant to the RFC. I think my definition is a "better" definition of what phones ought to do; yours simply copies what phones have done for 20 years or more. When creating a "best current practice", we get to ask the question of whether doing what we have done for that long really is the best way, or whether something more capable is the best way. I understand the problem - if we say that presence based DND is the best practice, than even inexpensive business phones have to implement it. I also understand that current low end phones do have a DND implementation such as you propose. Similarly, DND that is "phone state" is what most phones do. In this case, I think it's pretty easy to compromise on the issue, because we can write the document in such a way that it says that DND is user state, but that it is acceptable to have a default user that is registered automatically. However, before we get into all of that, we have to start with "are we doing this at all" and "what basis to we start with". Need more discussion on that before we argue DND. Brian > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Tuesday, June 24, 2003 4:12 PM > To: 'Venkatesh Venkataramanan'; sipping@ietf.org > Cc: Sharath Rajasekar > Subject: RE: [Sipping] I-D > ACTION:draft-sharath-sipb-requirements-00.txt > > > My problem is that if an RFC resulting from this work > requires your definition of DND, and my phone implements my > definition of DND, then I am not compliant to the RFC. > I think my definition is a "better" definition of what > phones ought to do; yours i > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 25 11:06:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14049 for ; Wed, 25 Jun 2003 11:06:09 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PF5hb26374 for sipping-archive@odin.ietf.org; Wed, 25 Jun 2003 11:05:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBqB-0006rJ-Co for sipping-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11:05: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 LAA13991 for ; Wed, 25 Jun 2003 11: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 19VBpW-0006ha-8S; Wed, 25 Jun 2003 11:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBpA-0006YL-Ow for sipping@optimus.ietf.org; Wed, 25 Jun 2003 11:04: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 KAA12572; Wed, 25 Jun 2003 10:51:23 -0400 (EDT) Message-Id: <200306251451.KAA12572@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, 25 Jun 2003 10:51:23 -0400 Subject: [Sipping] I-D ACTION:draft-olson-sipping-dialog-package-extensions-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 : Extensions to the Dialog event package for Third Party Call Control Author(s) : S. Olson Filename : draft-olson-sipping-dialog-package-extensions-00.txt Pages : 19 Date : 2003-6-24 This document defines extensions to the dialog event package and corresponding application/dialog-info+xml MIME type for the purpose of third-party call control. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-olson-sipping-dialog-package-extensions-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-olson-sipping-dialog-package-extensions-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-olson-sipping-dialog-package-extensions-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-25103001.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-olson-sipping-dialog-package-extensions-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-olson-sipping-dialog-package-extensions-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-25103001.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 Jun 25 11:07:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14187 for ; Wed, 25 Jun 2003 11:07:01 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PF6ZI27165 for sipping-archive@odin.ietf.org; Wed, 25 Jun 2003 11:06:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBr1-000744-6l for sipping-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11:06: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 LAA14136 for ; Wed, 25 Jun 2003 11:06: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 19VBqU-0006tF-7t; Wed, 25 Jun 2003 11: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 19VBpB-0006YL-Rm for sipping@optimus.ietf.org; Wed, 25 Jun 2003 11:04:41 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12462; Wed, 25 Jun 2003 10:50:56 -0400 (EDT) Message-Id: <200306251450.KAA12462@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, 25 Jun 2003 10:50:56 -0400 Subject: [Sipping] I-D ACTION:draft-barnes-sipping-sec-inserted-info-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 : A Mechanism to Secure SIP Identity headers inserted by Intermediaries Author(s) : M. Barnes Filename : draft-barnes-sipping-sec-inserted-info-00.txt Pages : 9 Date : 2003-6-24 This draft defines a standard mechanism for securing SIP headers that are inserted into requests and responses. The fundamental requirements, for securing the headers inserted by an intermediary routing or retargeting a request or response, are summarized. The solution is directed towards headers that contain identity related information, such as Record-Route, Via, and History-Info. The proposed solution defines an Authenticated Inserted Identity Header Body based on S/MIME to secure the headers. This mechanism is optional, however, the use of it enhances the overall security of SIP by ensuring the integrity of the inserted headers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-barnes-sipping-sec-inserted-info-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-barnes-sipping-sec-inserted-info-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-barnes-sipping-sec-inserted-info-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-25102904.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-barnes-sipping-sec-inserted-info-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-barnes-sipping-sec-inserted-info-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-25102904.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 Jun 25 11:10:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14472 for ; Wed, 25 Jun 2003 11:10:02 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PF9al29669 for sipping-archive@odin.ietf.org; Wed, 25 Jun 2003 11:09:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBtw-0007iE-8Z for sipping-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11:09: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 LAA14399 for ; Wed, 25 Jun 2003 11: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 19VBtO-0007Y1-TV; Wed, 25 Jun 2003 11: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 19VBpB-0006YL-AN for sipping@optimus.ietf.org; Wed, 25 Jun 2003 11:04:41 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12545; Wed, 25 Jun 2003 10:51:18 -0400 (EDT) Message-Id: <200306251451.KAA12545@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, 25 Jun 2003 10:51:18 -0400 Subject: [Sipping] I-D ACTION:draft-mahy-sipping-tones-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 : Conveying Tones in the Session Initiation Protocol (SIP) Author(s) : R. Mahy Filename : draft-mahy-sipping-tones-00.txt Pages : 14 Date : 2003-6-24 One of the major applications of the Session Initiation Protocol (SIP) is in Internet telephony. In this context it is often useful or convenient for a SIP entity to request another SIP User Agent generate some type of tone, without generating this tone as part of a session. This document describes how SIP can be used without modification to carry such tones and explores issues relating to their use. Finally this document defines a new MIME type which is useful for conveying computer generated tones. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mahy-sipping-tones-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-mahy-sipping-tones-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-mahy-sipping-tones-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-25102952.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mahy-sipping-tones-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mahy-sipping-tones-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-25102952.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 Jun 25 11:35:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15944 for ; Wed, 25 Jun 2003 11:35:49 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFZM305451 for sipping-archive@odin.ietf.org; Wed, 25 Jun 2003 11:35:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCIq-0001Mm-JI for sipping-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11: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 LAA15602 for ; Wed, 25 Jun 2003 11:35:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VCIp-0004dd-00 for sipping-web-archive@ietf.org; Wed, 25 Jun 2003 11:35:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VCIi-0004cf-00 for sipping-web-archive@ietf.org; Wed, 25 Jun 2003 11:35:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCIa-0000vh-Tw; Wed, 25 Jun 2003 11:35:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBpi-0006YL-1c for sipping@optimus.ietf.org; Wed, 25 Jun 2003 11:05: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 KAA11078 for ; Wed, 25 Jun 2003 10:12:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VB0W-00041Q-00 for sipping@ietf.org; Wed, 25 Jun 2003 10:12:20 -0400 Received: from web41506.mail.yahoo.com ([66.218.93.89]) by ietf-mx with smtp (Exim 4.12) id 19VB0L-00041H-00 for sipping@ietf.org; Wed, 25 Jun 2003 10:12:09 -0400 Message-ID: <20030625141118.66103.qmail@web41506.mail.yahoo.com> Received: from [131.107.3.92] by web41506.mail.yahoo.com via HTTP; Wed, 25 Jun 2003 07:11:18 PDT Date: Wed, 25 Jun 2003 07:11:18 -0700 (PDT) From: Sean Olson To: sipping@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Sipping] Dialog event package and conferences Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 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 From exim@www1.ietf.org Wed Jun 25 11:36:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16161 for ; Wed, 25 Jun 2003 11:36:13 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFZkb06755 for sipping-archive@odin.ietf.org; Wed, 25 Jun 2003 11:35:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCJG-0001ks-CI for sipping-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11:35: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 LAA15843 for ; Wed, 25 Jun 2003 11:35:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VCJD-0004gk-00 for sipping-web-archive@ietf.org; Wed, 25 Jun 2003 11:35:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VCJ6-0004dS-00 for sipping-web-archive@ietf.org; Wed, 25 Jun 2003 11:35:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCIh-00015Q-Ok; Wed, 25 Jun 2003 11:35:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBpC-0006YL-Cx for sipping@optimus.ietf.org; Wed, 25 Jun 2003 11:04:42 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13278; Wed, 25 Jun 2003 10:54:49 -0400 (EDT) Message-Id: <200306251454.KAA13278@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, 25 Jun 2003 10:54:49 -0400 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-req-history-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 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA13279 Content-Transfer-Encoding: quoted-printable A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Session Initiation Proposal Investigatio= n Working Group of the IETF. Title : SIP Generic Request History Capability =FB Requirements Author(s) : M. Barnes et al. Filename : draft-ietf-sipping-req-history-04.txt Pages : 11 Date : 2003-6-24 =09 Many services that SIP is anticipated to support require the ability=20 to determine why and how the call arrived at a specific application. =20 Examples of such services include (but are not limited to) sessions=20 initiated to call centers via 'click to talk' SIP URLs on a web page,=20 'call history/logging' style services within intelligent 'call=20 management' software for SIP UAs and calls to voicemail servers and=20 call centers. While SIP implicitly provides the redirect/retarget=20 capabilities that enable calls to be routed to chosen applications,=20 there is currently no standard mechanism within SIP for communicating=20 the history of such a request. This 'request history' information=20 allows the receiving application to determine hints about how and why=20 the call arrived at the application/user. =20 This draft discusses the motivations in support of a mechanism for=20 recording the 'request history', and proposes detailed requirements=20 for such a generic 'request history' capability. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-req-history-04.txt To remove yourself from the IETF Announcement list, send a message to=20 ietf-announce-request with the word unsubscribe in the body of the messag= e. Internet-Drafts are also available by anonymous FTP. Login with the usern= ame "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sipping-req-history-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-req-history-04.txt". =09 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. =09 =09 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-25103651.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-req-history-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-req-history-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-25103651.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 Jun 25 11:36:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16160 for ; Wed, 25 Jun 2003 11:36:10 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFZYj06409 for sipping-archive@odin.ietf.org; Wed, 25 Jun 2003 11:35:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCJ1-0001dp-EA for sipping-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11:35: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 LAA15698 for ; Wed, 25 Jun 2003 11:35:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VCJ0-0004fi-00 for sipping-web-archive@ietf.org; Wed, 25 Jun 2003 11:35:30 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VCIu-0004f5-00 for sipping-web-archive@ietf.org; Wed, 25 Jun 2003 11:35:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCIq-0001L6-2h; Wed, 25 Jun 2003 11:35:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBwv-0008AG-OB for sipping@optimus.ietf.org; Wed, 25 Jun 2003 11:12: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 GAA06205 for ; Wed, 25 Jun 2003 06:17:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19V7Kz-0003AY-00 for sipping@ietf.org; Wed, 25 Jun 2003 06:17:13 -0400 Received: from mta02.btfusion.com ([62.172.195.247]) by ietf-mx with esmtp (Exim 4.12) id 19V7Ko-0003AS-00 for sipping@ietf.org; Wed, 25 Jun 2003 06:17:02 -0400 Received: from [217.34.231.189] (helo=ictgateway.ictrnid.org.uk) by mta02.btfusion.com with smtp (Exim 4.10) id 19V7Jn-0000DE-00 for sipping@ietf.org; Wed, 25 Jun 2003 10:15:59 +0000 Received: from 192.168.1.33 ([192.168.1.33]) by ictgateway.ictrnid.org.uk (WinRoute Pro 4.1.29) with SMTP; Wed, 25 Jun 2003 11:15:54 +0100 From: "James Hamlin" To: Date: Wed, 25 Jun 2003 11:15:54 +0100 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.6604 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sipping] draft-sharath-sipb-requirements-00.txt -- text support Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk 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 think draft-sharath-sipb-requirements-00.txt should include requirements for real time text support. The arguments for this are similar to those that have been discussed in relation to draft-sinnreich-sipdev-req-01.txt. The two main differences, between the two, are that business telephones are not in the low cost end of the market and that businesses in many countries have a legal obligation to make reasonable adjustments for people with disabilities. There is therefore even more justification to make RFC 2793 text support mandatory. Regards James Hamlin _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 25 11:55:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18329 for ; Wed, 25 Jun 2003 11:55:04 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFsai32045 for sipping-archive@odin.ietf.org; Wed, 25 Jun 2003 11:54:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCbU-0008Km-Dw for sipping-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11:54: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 LAA18296 for ; Wed, 25 Jun 2003 11:54: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 19VCav-00089w-DJ; Wed, 25 Jun 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 19VCaG-00082W-80 for sipping@optimus.ietf.org; Wed, 25 Jun 2003 11:53: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 LAA18185 for ; Wed, 25 Jun 2003 11:53:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VCaF-0004rF-00 for sipping@ietf.org; Wed, 25 Jun 2003 11:53:19 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19VCa3-0004pw-00 for sipping@ietf.org; Wed, 25 Jun 2003 11:53:07 -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 LAA02328; Wed, 25 Jun 2003 11:49:45 -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 LAA13200; Wed, 25 Jun 2003 11:49:47 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jun 2003 11:49:46 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5B4A@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Sean Olson'" , sipping@ietf.org Subject: RE: [Sipping] Dialog event package and conferences Date: Wed, 25 Jun 2003 11:49:46 -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: , 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 From exim@www1.ietf.org Wed Jun 25 12:22:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15943 for ; Wed, 25 Jun 2003 11:35:49 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFZMa05450 for sipping-archive@odin.ietf.org; Wed, 25 Jun 2003 11:35:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCIq-0001NG-Kv for sipping-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11: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 LAA15599 for ; Wed, 25 Jun 2003 11:35:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VCIp-0004dc-00 for sipping-web-archive@ietf.org; Wed, 25 Jun 2003 11:35:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VCIi-0004cg-00 for sipping-web-archive@ietf.org; Wed, 25 Jun 2003 11:35:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCIa-0000vO-3I; Wed, 25 Jun 2003 11:35:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBpi-0006YL-Sq for sipping@optimus.ietf.org; Wed, 25 Jun 2003 11:05:14 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12794; Wed, 25 Jun 2003 10:52:26 -0400 (EDT) Message-Id: <200306251452.KAA12794@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org, sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 25 Jun 2003 10:52:25 -0400 Subject: [Sipping] I-D ACTION:draft-melanchuk-sipping-msml-00.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Media Sessions Markup Language (MSML) Author(s) : T. Melanchuk, G. Sharratt Filename : draft-melanchuk-sipping-msml-00.txt Pages : 31 Date : 2003-6-24 The Media Sessions Markup Language (MSML) is used to control and invoke many different types of services on IP media servers. Clients can use it define how media sessions interact on a media server and to apply services to individual or groups of users. MSML can be used, for example, to control media server advanced conferencing features, create sidebars, and insert media processing objects into media streams. As well, clients can use it with other languages such as the Media Objects Markup Language (MOML) or VoiceXML to interact with individual users or with groups of conference participants. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-melanchuk-sipping-msml-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-melanchuk-sipping-msml-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-melanchuk-sipping-msml-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-25103228.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-melanchuk-sipping-msml-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-melanchuk-sipping-msml-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-25103228.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 Jun 25 14:56:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25377 for ; Wed, 25 Jun 2003 14:56:39 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PIuC706925 for sipping-archive@odin.ietf.org; Wed, 25 Jun 2003 14:56:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VFRD-0001nc-WB for sipping-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 14:56: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 OAA25351 for ; Wed, 25 Jun 2003 14:56:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VFRC-0006BF-00 for sipping-web-archive@ietf.org; Wed, 25 Jun 2003 14:56:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VFR6-0006BC-00 for sipping-web-archive@ietf.org; Wed, 25 Jun 2003 14:56:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VFR3-0001mY-6L; Wed, 25 Jun 2003 14: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 19VFQ5-0001kw-IY for sipping@optimus.ietf.org; Wed, 25 Jun 2003 14:55:01 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25299; Wed, 25 Jun 2003 14:54:38 -0400 (EDT) Message-Id: <200306251854.OAA25299@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , sipping@ietf.org From: The IESG Date: Wed, 25 Jun 2003 14:54:37 -0400 Subject: [Sipping] Protocol Action: Session Initiation Protocol Basic Call Flow Examples to BCP Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , The IESG has approved the following Internet-Drafts as BCPs: o 'Session Initiation Protocol Basic Call Flow Examples' o 'Session Initiation Protocol PSTN Call Flows' These documents are the product of the Session Initiation Proposal Investigation Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary These documents have been developed to provide reviewed examples of the use of call flows in Session Initiation Protocol (SIP) networks. These documents are designed to be used by SIP implementers, designers, and protocol researchers to help further the goal of a standard implementation of SIP. These flows represent carefully checked and working group reviewed scenarios of the most basic examples as a companion to the specifications. The "Basic Call Flow Examples" document gives examples of basic SIP call flows. Elements in these call flows include SIP User Agents and Clients, SIP Proxy and Redirect Servers. Scenarios include SIP Registration and SIP session establishment. The "PSTN Call Flows" document provides examples of SIP interworking with the PSTN through gateways. Elements in these call flows include SIP User Agents, SIP Proxy Servers, and PSTN Gateways. Scenarios include SIP to PSTN, PSTN to SIP, and PSTN to PSTN via SIP. PSTN telephony protocols are illustrated using ISDN (Integrated Services Digital Network), ISUP (ISDN User Part), and FGB (Feature Group B) circuit associated signaling. PSTN calls are illustrated using global telephone numbers from the PSTN and private extensions served on by a PBX (Private Branch Exchange). Call flow diagrams and message details are shown in both documents. Working Group Summary The working group supported the publication of these documents as BCPs, and provided a large amount of review and care. Protocol Quality These documents were reviewed for the IESG by Allison Mankin. RFC Editor Note: In the Abstract of both documents, in the first sentence, delete the word "informational". _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 25 18:50:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09077 for ; Wed, 25 Jun 2003 18:50:39 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PMoEg28431 for sipping-archive@odin.ietf.org; Wed, 25 Jun 2003 18:50:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VJ5i-0007OU-7f for sipping-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 18: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 SAA09018 for ; Wed, 25 Jun 2003 18:50:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VJ5b-0001fg-00 for sipping-web-archive@ietf.org; Wed, 25 Jun 2003 18:50:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VJ5W-0001fd-00 for sipping-web-archive@ietf.org; Wed, 25 Jun 2003 18:50:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VJ5V-0007M2-G6; Wed, 25 Jun 2003 18: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 19VJ4i-0007J2-Ah for sipping@optimus.ietf.org; Wed, 25 Jun 2003 18:49: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 SAA08964 for ; Wed, 25 Jun 2003 18:49:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VJ4f-0001eg-00 for sipping@ietf.org; Wed, 25 Jun 2003 18:49:09 -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 19VJ4U-0001di-00 for sipping@ietf.org; Wed, 25 Jun 2003 18:48:58 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 25 Jun 2003 15:49:35 -0800 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 h5PMlgMO019422; Wed, 25 Jun 2003 15:47:44 -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 AIN06453; Wed, 25 Jun 2003 15:40:38 -0700 (PDT) Date: Wed, 25 Jun 2003 15:49:03 -0700 Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Venkatesh Venkataramanan , Rohan Mahy To: "'sipping@ietf.org'" From: Rohan Mahy Content-Transfer-Encoding: 7bit Message-Id: <37FD0D32-A75F-11D7-BD84-0003938AF740@cisco.com> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Sipping] Proposed Addition to Replaces 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: 7bit Content-Transfer-Encoding: 7bit Hi, I am now making a few small edits to Replaces in response to AD review (mostly security clarifications). In an earlier thread, Venkatesh described a race condition with using Replaces for Call Pickup. We have a few options for dealing with the issue he raised: 1) provide a "state" parameter in the Replaces header which has a list or states that are acceptable for the dialog to "match". for example: Replaces: xyz;to-tag=123;from-tag=456;state="early,confirmed" 2) provide an "early-only" parameter in the Replaces header which only matches for early dialogs. 3) live with the race condition as is Replaces is only defined for early and confirmed dialogs. We have a number of cases where the UAC doesn't care which of these target dialog is in (state="early,confirmed"). Venkatesh gave an example where we only want to match for early dialogs (state="early"), but I could not come up with any application where the UAC only wanted to match is the dialog is confirmed (since the dialog will never transition from confirmed to early, there is no race condition). Based in this I am recommending we go with option #2. Unless I hear any strong objections I will make appropriate changes and submit a version with this approach on Friday. many thanks, -rohan > Per section 2.16 of the > http://www.ietf.org/internet-drafts/draft-ietf-sipping-service- > examples-04.t > xt draft, call pick up is acheived by using a INVITE with Replaces > header. > An INVITE with Replaces header is also used for consultative > transfers. A UA > that receives the a INVITE with Replaces header attempts to match an > existing dialog with details provided in the replaces header and if > found > accept the same, it then proceeds to tear down the existing dialog. > However, > the call flow for pick up presented in 2.16 is prone to race > conditions > which could produce undesirable end user behavior. > > Per the example in 2.16: > > 1. Alice calls Bob. Bob's phone is ringing. > 2. Carol decides to pick the call. > 3. Carol sends a SUBSCRIBE to Bob's dialog state. Bob's UA sends out a > NOTIFY providing the dialog details. > 4. Carol initiates a INVITE with Replaces header. > > However, between step 3 and step 4, it could so happen that Bob > decided to > pickup his phone to answer the call. The call is established and the > two > start talking..... Now the INVITE with Replaces (step 4) comes along. > Alice's UA accepts this request, tears down the session with Bob and > the > call gets established with Carol. This produces undesirable results > from a > end user perspective. > > Would it be a good idea to extend the Replaces header to contain the > dialog > state based on the dialog state draft as well so that the recipient can > compare the dialog identifiers AND the dialog state to decide whether > to > allow the same or not? > > regards, > Venkatesh _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 25 21:18:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17052 for ; Wed, 25 Jun 2003 21:18:39 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5Q1ICI26757 for sipping-archive@odin.ietf.org; Wed, 25 Jun 2003 21:18:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VLOu-0006xU-Nv for sipping-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 21:18: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 VAA17033 for ; Wed, 25 Jun 2003 21:18:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VLOq-0003be-00 for sipping-web-archive@ietf.org; Wed, 25 Jun 2003 21:18:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VLOk-0003bb-00 for sipping-web-archive@ietf.org; Wed, 25 Jun 2003 21:18:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VLOj-0006ve-3a; Wed, 25 Jun 2003 21:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VLO9-0006uz-99 for sipping@optimus.ietf.org; Wed, 25 Jun 2003 21:17: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 VAA16934 for ; Wed, 25 Jun 2003 21:17:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VLNr-0003at-00 for sipping@ietf.org; Wed, 25 Jun 2003 21:17:07 -0400 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by ietf-mx with esmtp (Exim 4.12) id 19VLNg-0003Zg-00 for sipping@ietf.org; Wed, 25 Jun 2003 21:16:56 -0400 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HH2002DNDVOOU@firewall.wcom.com> for sipping@ietf.org; Thu, 26 Jun 2003 01:09:24 +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 <0HH200B01DVO17@pmismtp02.wcomnet.com>; Thu, 26 Jun 2003 01:09:24 +0000 (GMT) Received: from hsinnreich2 ([166.50.112.150]) by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HH20097WDVMMQ@pmismtp02.wcomnet.com>; Thu, 26 Jun 2003 01:09:24 +0000 (GMT) Date: Wed, 25 Jun 2003 20:09:22 -0500 From: Henry Sinnreich Subject: RE: [Sipping] I-D ACTION:draft-sharath-sipb-requirements-00.txt In-reply-to: <79FEAA5FABA7D411BF580001023D1BBD023BCAEF@mailserver.sylantro.com> To: "'Venkatesh Venkataramanan'" , "'Rosen, Brian'" , sipping@ietf.org Cc: "'Sharath Rajasekar'" Message-id: <002601c33b7f$943284d0$967032a6@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 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/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 25 23:23:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23911 for ; Wed, 25 Jun 2003 23:23:41 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5Q3NDP27943 for sipping-archive@odin.ietf.org; Wed, 25 Jun 2003 23: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 19VNLt-0007Gc-Te for sipping-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 23: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 XAA23890 for ; Wed, 25 Jun 2003 23:23:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VNLr-00056H-00 for sipping-web-archive@ietf.org; Wed, 25 Jun 2003 23:23:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VNLm-00056E-00 for sipping-web-archive@ietf.org; Wed, 25 Jun 2003 23:23:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VNLh-0007CG-04; Wed, 25 Jun 2003 23: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 19VNKw-0007Bv-Os for sipping@optimus.ietf.org; Wed, 25 Jun 2003 23: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 XAA23855 for ; Wed, 25 Jun 2003 23:22:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VNKu-00055V-00 for sipping@ietf.org; Wed, 25 Jun 2003 23:22:12 -0400 Received: from smtp011.mail.yahoo.com ([216.136.173.31]) by ietf-mx with smtp (Exim 4.12) id 19VNKj-00055S-00 for sipping@ietf.org; Wed, 25 Jun 2003 23:22:02 -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; 26 Jun 2003 03:21:26 -0000 Reply-To: From: "Sean Olson" To: "'Rosen, Brian'" , Subject: RE: [Sipping] Dialog event package and conferences Date: Wed, 25 Jun 2003 20:21:40 -0700 Message-ID: <016e01c33b92$0fd272a0$6801a8c0@cranberry> 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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <313680C9A886D511A06000204840E1CF070B5B4A@whq-msgusr-02.pit.comms.marconi.com> Content-Transfer-Encoding: quoted-printable Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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]=20 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=20 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 >=20 >=20 > I was wondering how do you tell that a dialog reported through a=20 > dialog event NOTIFY is actually just one leg of a larger conference?=20 > Or to flip it around another way, is there a way to determine which > conferences a user is currently in? >=20 >=20 >=20 > __________________________________ > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sip@ietf.org for new developments of core SIP >=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Thu Jun 26 00:03:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24719 for ; Thu, 26 Jun 2003 00:03:36 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5Q43Al06057 for sipping-archive@odin.ietf.org; Thu, 26 Jun 2003 00:03:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VNyY-0001Zc-AY for sipping-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 00:03:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24701 for ; Thu, 26 Jun 2003 00:03:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VNyV-0005Fy-00 for sipping-web-archive@ietf.org; Thu, 26 Jun 2003 00:03:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VNyQ-0005Fv-00 for sipping-web-archive@ietf.org; Thu, 26 Jun 2003 00: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 19VNyQ-0001YY-1j; Thu, 26 Jun 2003 00: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 19VNxc-0001Y7-7S for sipping@optimus.ietf.org; Thu, 26 Jun 2003 00:02: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 AAA24673 for ; Thu, 26 Jun 2003 00:02:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VNxZ-0005FO-00 for sipping@ietf.org; Thu, 26 Jun 2003 00:02:09 -0400 Received: from [65.200.90.207] (helo=mailserver.sylantro.com) by ietf-mx with smtp (Exim 4.12) id 19VNxP-0005FD-00 for sipping@ietf.org; Thu, 26 Jun 2003 00:01:59 -0400 Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Wed, 25 Jun 2003 21:00:47 -0700 X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Received: by mailserver.sylantro.com with Internet Mail Service ( 5.5.2653.19) id ; Wed, 25 Jun 2003 21:00:46 -0700 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD020D5AE0@mailserver.sylantro.com> From: "Sharath Rajasekar" To: "'sipping@ietf.org'" , "'Henry.Sinnreich@mci.com'" cc: "Venkatesh Venkataramanan" Subject: [Sipping] I-D ACTION:draft-sharath-sipb-requirements-00.txt Date: Wed, 25 Jun 2003 21:00:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 12E4B06496696-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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/listinfo/sipping -- This list is for NEW development of the application of SIP -- Use sip-implementors@cs.columbia.edu for questions on current sip -- Use sip@ietf.org for new developments of core SIP -- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 26 08:04:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16746 for ; Thu, 26 Jun 2003 08:04:40 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QC4Cb30919 for sipping-archive@odin.ietf.org; Thu, 26 Jun 2003 08:04:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VVU4-00082c-4V for sipping-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 08:04: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 IAA16619 for ; Thu, 26 Jun 2003 08:04:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VVU3-0007hy-00 for sipping-web-archive@ietf.org; Thu, 26 Jun 2003 08:04:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VVTx-0007hv-00 for sipping-web-archive@ietf.org; Thu, 26 Jun 2003 08:04:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VVTu-0007qu-Ir; Thu, 26 Jun 2003 08:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VVTH-0007q8-2Z for sipping@optimus.ietf.org; Thu, 26 Jun 2003 08:03:23 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16414; Thu, 26 Jun 2003 08:03:20 -0400 (EDT) Message-Id: <200306261203.IAA16414@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org, sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 26 Jun 2003 08:03:20 -0400 Subject: [Sipping] I-D ACTION:draft-mahy-sip-connect-reuse-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 : Connection Reuse in the Session Initiation Protocol (SIP) Author(s) : R. Mahy Filename : draft-mahy-sip-connect-reuse-00.txt Pages : 12 Date : 2003-6-25 When SIP entities use a connection oriented protocol to send a request, they typically originate their connections from an ephemeral port. The SIP protocol includes mechanisms which insure that responses to a request, and new requests sent in the original direction reuse an existing connection. However, new requests sent in the opposite direction are unlikely to reuse the existing connection. This frequently causes a pair of SIP entities to use one connection for requests sent in each direction, and can result in potential scaling and performance problems. This document proposes requirements and a mechanism which address this deficiency. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mahy-sip-connect-reuse-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-mahy-sip-connect-reuse-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-mahy-sip-connect-reuse-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-26080228.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mahy-sip-connect-reuse-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mahy-sip-connect-reuse-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-26080228.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 Jun 26 09:46:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24649 for ; Thu, 26 Jun 2003 09:46:37 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QDkAh30665 for sipping-archive@odin.ietf.org; Thu, 26 Jun 2003 09:46:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VX4k-0007yW-GJ for sipping-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 09:46:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24638 for ; Thu, 26 Jun 2003 09:46:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VX4i-0001dD-00 for sipping-web-archive@ietf.org; Thu, 26 Jun 2003 09:46:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VX4d-0001dA-00 for sipping-web-archive@ietf.org; Thu, 26 Jun 2003 09:46:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VX4b-0007tF-2Y; Thu, 26 Jun 2003 09:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VX3w-0007pb-FA for sipping@optimus.ietf.org; Thu, 26 Jun 2003 09:45: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 JAA24597 for ; Thu, 26 Jun 2003 09:45:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VX3f-0001cn-00 for sipping@ietf.org; Thu, 26 Jun 2003 09:45:03 -0400 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 19VX3U-0001cL-00 for sipping@ietf.org; Thu, 26 Jun 2003 09:44:52 -0400 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 12451; Thu, 26 Jun 2003 09:44:54 -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: Thu, 26 Jun 2003 09:43:59 -0400 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F64B9@zoe.office.snowshore.com> Thread-Topic: conf=comments on draft-burger-sipping-netann-05 Thread-Index: AcMmMM7oeL2cKVzGQm+8ZcJRL2AlUQVVMVMg From: "Eric Burger" To: "Orit Levin" Cc: "Sipping (E-mail)" Content-Transfer-Encoding: quoted-printable Subject: [Sipping] RE: conf=comments on draft-burger-sipping-netann-05 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 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 items 1&2: you are correct; I think this is really a BCP or standard = track item. Items 3&4: that was a victim of the change to conf=3Dconf-id parameter = (see Item 5, next). Item 5: After 4 drafts, I was persuaded to move the conf-id from the = user part to a parameter. Thanks to the work of David Rio at Alcatel, = that was clearly an incorrect move. Shame on me for giving in! netann-06 will appear shortly, making these corrections, as well as = referencing the conferencing framework document. > -----Original Message----- > From: Orit Levin [mailto:orit@radvision.com] > Sent: Thu, May 29, 2003 6:20 PM > To: Eric Burger > Cc: Sipping (E-mail) > Subject: conf=3Dcomments on draft-burger-sipping-netann-05 >=20 >=20 > Hi Eric! > I have a number of questions/comments on the draft: >=20 > 1. I understand that the draft purpose is to become an=20 > informational RFC. > What stage of the process are we at? > 2. The draft uses MUST, SHOULD, MAY, etc. Is it the right=20 > language for an > informational RFC? (Also, please, take a look at the section=20 > 5.1 which says > "This section is informative" :-) > 3. Section 2. "Mechanism" discusses the need for=20 > instantiation of a service > and the corresponding syntax as "the concatenation of the=20 > service name and > an optional service instance identifier, separated by an=20 > equal sign". It > also brings up "multiple, separate conference sessions" as an=20 > example for a > service instantiation. > I endorse this direction and find it completely compatible=20 > and fitting the > more general approach of the draft-sipping-cc-conferencing. > 4. That said, in section 5 "Conference Service" a different syntax is > defined!!! It introduces a single "conf-id" parameter to be=20 > inserted as a > global SIP URI parameter - not in the USER portion of the=20 > URI... I find this > approach dangerous (even as informational) because it doesn't add any > functionality (to specifying a "service instance" in the USER=20 > part of the > URI) and will lead to interoperability problems (because it=20 > is different > from the approach taken by both the conferencing-framework and the > cc-conferencing WG documents). >=20 > Any thoughts? >=20 > Thanks, > Orit Levin > Chief Architect > RADVISION > Phone: +1.201.6896330 >=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 Thu Jun 26 10:46:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28677 for ; Thu, 26 Jun 2003 10:46:07 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QEjeC23141 for sipping-archive@odin.ietf.org; Thu, 26 Jun 2003 10:45:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VY0K-00061A-Oe for sipping-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 10:45:40 -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 KAA28652 for ; Thu, 26 Jun 2003 10:45: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 19VXzi-0005vo-30; Thu, 26 Jun 2003 10: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 19VXzP-0005tv-QN for sipping@optimus.ietf.org; Thu, 26 Jun 2003 10:44: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 KAA28563 for ; Thu, 26 Jun 2003 10:44:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VXzN-00028j-00 for sipping@ietf.org; Thu, 26 Jun 2003 10:44: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 19VXzC-00028S-00 for sipping@ietf.org; Thu, 26 Jun 2003 10:44:30 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 26 Jun 2003 07:46:56 -0800 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 h5QEhaMO025410; Thu, 26 Jun 2003 07:43:37 -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 AIN64537; Thu, 26 Jun 2003 07:36:25 -0700 (PDT) Date: Thu, 26 Jun 2003 07:44:56 -0700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'sipping@ietf.org'" , "Mark Watson" To: "Francois Audet" From: Rohan Mahy In-Reply-To: <2F1FC1DEA077D5119FAD00508BCFD6D2094128BE@zsc3c030.us.nortel.com> Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: quoted-printable Subject: [Sipping] Re: I-D ACTION:draft-mahy-sipping-tones-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: quoted-printable Content-Transfer-Encoding: quoted-printable On Wednesday, June 25, 2003, at 06:25 PM, Francois Audet wrote: > Rohan, > > What would be the expected behavior under this draft of a UA receing a=20= > 180 with > the audio/telephone-event or audio/tone-info+html with null data/no=20 > content, or even > a description of a "silent" tone? no content might be interpreted differently. > Would it mean that NO locally-generated tones shall be played to the=20= > user in conjunction > with the 180? ;^) for a small silent tone i would expect so. perhaps even this would be sufficient: SIP/2.0 180 Ringing ... Content-Type: audio/tone-info+xml Content-Length: 10 hope this helps. thanks, -rohan > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Wednesday, June 25, 2003 07:51 > > Cc: sipping@ietf.org > > Subject: I-D ACTION:draft-mahy-sipping-tones-00.txt > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > > > > =A0=A0=A0=A0=A0 Title=A0=A0 =A0=A0=A0=A0=A0=A0=A0 : Conveying Tones = in the Session > > Initiation Protocol > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 (SIP) > > =A0=A0=A0=A0=A0 Author(s)=A0=A0=A0=A0=A0=A0 : R. Mahy > > =A0=A0=A0=A0=A0 Filename=A0=A0=A0=A0=A0=A0=A0 : = draft-mahy-sipping-tones-00.txt > > =A0=A0=A0=A0=A0 Pages=A0=A0 =A0=A0=A0=A0=A0=A0=A0 : 14 > > =A0=A0=A0=A0=A0 Date=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 : 2003-6-24 > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 26 11:10:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00493 for ; Thu, 26 Jun 2003 11:10:07 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QF9fK32045 for sipping-archive@odin.ietf.org; Thu, 26 Jun 2003 11:09:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYNZ-0008Km-Ce for sipping-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 11:09: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 LAA00306 for ; Thu, 26 Jun 2003 11: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 19VYMu-0008BT-GB; Thu, 26 Jun 2003 11: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 19VYMl-0008BF-DJ for sipping@optimus.ietf.org; Thu, 26 Jun 2003 11:08:51 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00102; Thu, 26 Jun 2003 11:08:46 -0400 (EDT) Message-Id: <200306261508.LAA00102@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, 26 Jun 2003 11:08:46 -0400 Subject: [Sipping] I-D ACTION:draft-ono-sipping-end2middle-security-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 : End-to-middle security in the Session Initiation Protocol(SIP) Author(s) : K. Ono, S. Tachimoto Filename : draft-ono-sipping-end2middle-security-00.txt Pages : 23 Date : 2003-6-26 End-to-end encryption for confidentiality services can conflict with some of the features provided by intermediaries. For example, if a SIP UA encrypts the message body by using S/MIME for end-to-end security, it cannot use features that the proxy employs to inspect the message body contained in the request. This situation requires securing information passed between the UA and an intermediary proxy, also called 'end-to-middle security', which can work with end-to-end security. This document 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. It describes how to apply S/MIME CMS EnvelopedData body for use in end-to-middle security. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ono-sipping-end2middle-security-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-ono-sipping-end2middle-security-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-ono-sipping-end2middle-security-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-26100505.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ono-sipping-end2middle-security-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ono-sipping-end2middle-security-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-26100505.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 Jun 26 11:40:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04598 for ; Thu, 26 Jun 2003 11:40:12 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QFdjW11121 for sipping-archive@odin.ietf.org; Thu, 26 Jun 2003 11:39:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYqf-0002tI-C0 for sipping-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 11:39:45 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04453 for ; Thu, 26 Jun 2003 11:39: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 19VYpy-0002pc-Rv; Thu, 26 Jun 2003 11:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYpG-0002nh-48 for sipping@optimus.ietf.org; Thu, 26 Jun 2003 11:38:18 -0400 Received: from radvpost.radvision.com (radvmail.radvision.com [12.44.63.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04256 for ; Thu, 26 Jun 2003 11:38:12 -0400 (EDT) Received: from radvpost.radvision.com [192.168.216.29] by radvpost.radvision.com with XWall v3.26 ; Thu, 26 Jun 2003 11:36:31 -0400 Received: by radvpost.RADVISION.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jun 2003 11:36:31 -0400 Message-ID: From: Orit Levin To: "'Eric Burger'" Cc: "Sipping (E-mail)" Date: Thu, 26 Jun 2003 11:36:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Sipping] RE: conf=comments on draft-burger-sipping-netann-05 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , It seems that we are in synch here :-) I look forward to reading the new version! Orit. > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: Thursday, June 26, 2003 9:44 AM > To: Orit Levin > Cc: Sipping (E-mail) > Subject: RE: conf=comments on draft-burger-sipping-netann-05 > > On items 1&2: you are correct; I think this is really a BCP or standard > track item. > > Items 3&4: that was a victim of the change to conf=conf-id parameter (see > Item 5, next). > > Item 5: After 4 drafts, I was persuaded to move the conf-id from the user > part to a parameter. Thanks to the work of David Rio at Alcatel, that was > clearly an incorrect move. Shame on me for giving in! > > > netann-06 will appear shortly, making these corrections, as well as > referencing the conferencing framework document. > > > -----Original Message----- > > From: Orit Levin [mailto:orit@radvision.com] > > Sent: Thu, May 29, 2003 6:20 PM > > To: Eric Burger > > Cc: Sipping (E-mail) > > Subject: conf=comments on draft-burger-sipping-netann-05 > > > > > > Hi Eric! > > I have a number of questions/comments on the draft: > > > > 1. I understand that the draft purpose is to become an > > informational RFC. > > What stage of the process are we at? > > 2. The draft uses MUST, SHOULD, MAY, etc. Is it the right > > language for an > > informational RFC? (Also, please, take a look at the section > > 5.1 which says > > "This section is informative" :-) > > 3. Section 2. "Mechanism" discusses the need for > > instantiation of a service > > and the corresponding syntax as "the concatenation of the > > service name and > > an optional service instance identifier, separated by an > > equal sign". It > > also brings up "multiple, separate conference sessions" as an > > example for a > > service instantiation. > > I endorse this direction and find it completely compatible > > and fitting the > > more general approach of the draft-sipping-cc-conferencing. > > 4. That said, in section 5 "Conference Service" a different syntax is > > defined!!! It introduces a single "conf-id" parameter to be > > inserted as a > > global SIP URI parameter - not in the USER portion of the > > URI... I find this > > approach dangerous (even as informational) because it doesn't add any > > functionality (to specifying a "service instance" in the USER > > part of the > > URI) and will lead to interoperability problems (because it > > is different > > from the approach taken by both the conferencing-framework and the > > cc-conferencing WG documents). > > > > Any thoughts? > > > > Thanks, > > Orit Levin > > Chief Architect > > RADVISION > > Phone: +1.201.6896330 > > > > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 26 11:59:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06091 for ; Thu, 26 Jun 2003 11:59:05 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QFwcD14091 for sipping-archive@odin.ietf.org; Thu, 26 Jun 2003 11:58:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VZ8w-0003fC-DS for sipping-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 11:58:38 -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 LAA05998 for ; Thu, 26 Jun 2003 11: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 19VZ8M-0003W5-Nw; Thu, 26 Jun 2003 11: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 19VZ7W-0003NS-1Z for sipping@optimus.ietf.org; Thu, 26 Jun 2003 11:57: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 LAA05632 for ; Thu, 26 Jun 2003 11:56:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VYwW-00031C-00 for sipping@ietf.org; Thu, 26 Jun 2003 11:45:48 -0400 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by ietf-mx with esmtp (Exim 4.12) id 19VYwL-0002zC-00 for sipping@ietf.org; Thu, 26 Jun 2003 11:45:37 -0400 Received: from pmismtp05.wcomnet.com ([166.38.62.53]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HH300253I6SDV@firewall.wcom.com> for sipping@ietf.org; Thu, 26 Jun 2003 15:40:04 +0000 (GMT) Received: from pmismtp05.wcomnet.com by pmismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HH300501I2ZZG@pmismtp05.wcomnet.com>; Thu, 26 Jun 2003 15:40:04 +0000 (GMT) Received: from hsinnreich2 ([166.35.136.36]) by pmismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HH30046XHG4IL@pmismtp05.wcomnet.com>; Thu, 26 Jun 2003 15:39:45 +0000 (GMT) Date: Thu, 26 Jun 2003 10:24:03 -0500 From: Henry Sinnreich Subject: RE: [Sipping] I-D ACTION:draft-sharath-sipb-requirements-00.txt In-reply-to: <79FEAA5FABA7D411BF580001023D1BBD020D5ADC@mailserver.sylantro.com> To: "'Sharath Rajasekar'" , sipping@ietf.org Cc: "'Venkatesh Venkataramanan'" Message-id: <003801c33bf9$2ab5d140$248823a6@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 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 From exim@www1.ietf.org Thu Jun 26 13:13:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09845 for ; Thu, 26 Jun 2003 13:13:02 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QHCaB00697 for sipping-archive@odin.ietf.org; Thu, 26 Jun 2003 13:12:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VaIW-0000BA-5P for sipping-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 13:12: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 NAA09801 for ; Thu, 26 Jun 2003 13:12:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VaIF-0003zE-00 for sipping-web-archive@ietf.org; Thu, 26 Jun 2003 13:12:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VaI9-0003zA-00 for sipping-web-archive@ietf.org; Thu, 26 Jun 2003 13: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 19VaHx-0008Tg-GQ; Thu, 26 Jun 2003 13: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 19Va6O-0007VL-0X for sipping@optimus.ietf.org; Thu, 26 Jun 2003 13:00: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 MAA09254 for ; Thu, 26 Jun 2003 12:59:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Va67-0003tZ-00 for sipping@ietf.org; Thu, 26 Jun 2003 12:59:47 -0400 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 19Va5w-0003sm-00 for sipping@ietf.org; Thu, 26 Jun 2003 12:59:36 -0400 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5QGwXa14780; Thu, 26 Jun 2003 09:58:33 -0700 (PDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jun 2003 09:58:34 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D20947760A@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Rohan Mahy'" Cc: "'sipping@ietf.org'" , "Mark Watson" Date: Thu, 26 Jun 2003 09:58:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33C04.2C717B5A" Subject: [Sipping] RE: I-D ACTION:draft-mahy-sipping-tones-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. ------_=_NextPart_001_01C33C04.2C717B5A Content-Type: text/plain > On Wednesday, June 25, 2003, at 06:25 PM, Francois Audet wrote: > > > Rohan, > > > > What would be the expected behavior under this draft of a > UA receing a > > 180 with > > the audio/telephone-event or audio/tone-info+html with null data/no > > content, or even > > a description of a "silent" tone? > > no content might be interpreted differently. I would suggest we define how it should be interpreted (I don't really care what the interpretation should be, just that it is clear so that people don't use the empty content in different incompatible ways). I wouldn't mind either if we just say "don't send it and ignore it on receipt". > > Would it mean that NO locally-generated tones shall be played to the > > user in conjunction > > with the 180? ;^) > > for a small silent tone i would expect so. > > perhaps even this would be sufficient: > > SIP/2.0 180 Ringing > ... > Content-Type: audio/tone-info+xml > Content-Length: 10 > > > > hope this helps. thanks, It does. It also seems to be pretty close to the "Alerting, don't play local tone because in-band might be coming" indicator that some people were looking for... ------_=_NextPart_001_01C33C04.2C717B5A Content-Type: text/html RE: I-D ACTION:draft-mahy-sipping-tones-00.txt

> On Wednesday, June 25, 2003, at 06:25 PM, Francois Audet wrote:
>
> > Rohan,
> >
> > What would be the expected behavior under this draft of a
> UA receing a
> > 180 with
> > the audio/telephone-event or audio/tone-info+html with null data/no
> > content, or even
> > a description of a "silent" tone?
>
> no content might be interpreted differently.

I would suggest we define how it should be interpreted (I don't really
care what the interpretation should be, just that it is clear so
that people don't use the empty content in different incompatible ways).
I wouldn't mind either if we just say "don't send it and ignore it on
receipt".

> > Would it mean that NO locally-generated tones shall be played to the
> > user in conjunction
> > with the 180? ;^)
>
> for a small silent tone i would expect so.
>
> perhaps even this would be sufficient:
>
>     SIP/2.0 180 Ringing
>     ...
>     Content-Type: audio/tone-info+xml
>     Content-Length: 10
>
>     <tones/>
>
> hope this helps.  thanks,

It does. It also seems to be pretty close to the "Alerting, don't play local
tone because in-band might be coming" indicator that some people were looking
for...

------_=_NextPart_001_01C33C04.2C717B5A-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 26 14:32:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13692 for ; Thu, 26 Jun 2003 14:32:02 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFZVb06328 for sipping-archive@odin.ietf.org; Wed, 25 Jun 2003 11:35:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCJ1-0001dl-Da for sipping-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 11:35: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 LAA15692 for ; Wed, 25 Jun 2003 11:35:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VCIy-0004fP-00 for sipping-web-archive@ietf.org; Wed, 25 Jun 2003 11:35:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VCIt-0004er-00 for sipping-web-archive@ietf.org; Wed, 25 Jun 2003 11:35:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCIo-0001J0-0a; Wed, 25 Jun 2003 11:35:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBpi-0006YL-Mw for sipping@optimus.ietf.org; Wed, 25 Jun 2003 11:05:14 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12778; Wed, 25 Jun 2003 10:52:21 -0400 (EDT) Message-Id: <200306251452.KAA12778@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org, sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 25 Jun 2003 10:52:21 -0400 Subject: [Sipping] I-D ACTION:draft-melanchuk-sipping-moml-00.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Media Objects Markup Language (MOML) Author(s) : T. Melanchuk, G. Sharratt Filename : draft-melanchuk-sipping-moml-00.txt Pages : 42 Date : 2003-6-24 The Media Objects Markup Language (MOML) is used to define media processing objects which execute on media servers. It defines a set of primitive media objects (called primitives) and provides tools to group primitives together and specify how they interact with each other. Clients use MOML to create precisely tailored media processing objects which may be used as parts of application interactions with users or conferences or to transform media flowing internal to a media server. IVR is an example of an application interaction with a user. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-melanchuk-sipping-moml-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-melanchuk-sipping-moml-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-melanchuk-sipping-moml-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-25103219.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-melanchuk-sipping-moml-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-melanchuk-sipping-moml-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-25103219.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 Jun 26 14:48:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14502 for ; Thu, 26 Jun 2003 14:48:51 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5Q1icl03062 for sipping-archive@odin.ietf.org; Wed, 25 Jun 2003 21:44:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VLoU-0000nJ-1J for sipping-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 21:44: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 VAA19405 for ; Wed, 25 Jun 2003 21:44:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VLo0-00046A-00 for sipping-web-archive@ietf.org; Wed, 25 Jun 2003 21:44:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VLnu-000467-00 for sipping-web-archive@ietf.org; Wed, 25 Jun 2003 21:44:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VLnt-0000cL-F1; Wed, 25 Jun 2003 21: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 19VLmx-0000Rk-9z for sipping@optimus.ietf.org; Wed, 25 Jun 2003 21:43: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 VAA19067 for ; Wed, 25 Jun 2003 21:39:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VLjT-0003zk-00 for sipping@ietf.org; Wed, 25 Jun 2003 21:39:27 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19VLjI-0003xX-00 for sipping@ietf.org; Wed, 25 Jun 2003 21:39:16 -0400 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5Q1PXc17879; Wed, 25 Jun 2003 20:25:33 -0500 (CDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jun 2003 18:25:34 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D2094128BE@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'sipping@ietf.org'" , "'rohan@cisco.com'" Cc: "Mark Watson" Date: Wed, 25 Jun 2003 18:25:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33B81.D62E4584" Subject: [Sipping] RE: I-D ACTION:draft-mahy-sipping-tones-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. ------_=_NextPart_001_01C33B81.D62E4584 Content-Type: text/plain Rohan, What would be the expected behavior under this draft of a UA receing a 180 with the audio/telephone-event or audio/tone-info+html with null data/no content, or even a description of a "silent" tone? Would it mean that NO locally-generated tones shall be played to the user in conjunction with the 180? ;^) > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Wednesday, June 25, 2003 07:51 > Cc: sipping@ietf.org > Subject: I-D ACTION:draft-mahy-sipping-tones-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Conveying Tones in the Session > Initiation Protocol > (SIP) > Author(s) : R. Mahy > Filename : draft-mahy-sipping-tones-00.txt > Pages : 14 > Date : 2003-6-24 ------_=_NextPart_001_01C33B81.D62E4584 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-mahy-sipping-tones-00.txt

Rohan,

What would be the expected behavior under this draft = of a UA receing a 180 with
the audio/telephone-event or audio/tone-info+html = with null data/no content, or even
a description of a "silent" tone?

Would it mean that NO locally-generated tones shall = be played to the user in conjunction
with the 180? ;^)

> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org= ]
> Sent: Wednesday, June 25, 2003 07:51
> Cc: sipping@ietf.org
> Subject: I-D = ACTION:draft-mahy-sipping-tones-00.txt
>
>
> A New Internet-Draft is available from the = on-line
> Internet-Drafts directories.
>
>
>       = Title           : = Conveying Tones in the Session
> Initiation Protocol
>          = ;            = ;     (SIP)
>       = Author(s)       : R. Mahy
>       = Filename        : = draft-mahy-sipping-tones-00.txt
>       = Pages           : = 14
>       = Date            : = 2003-6-24

------_=_NextPart_001_01C33B81.D62E4584-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 26 14:53:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14812 for ; Thu, 26 Jun 2003 14:53:24 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5Q1hPo01988 for sipping-archive@odin.ietf.org; Wed, 25 Jun 2003 21:43:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VLnJ-0000Vz-ST for sipping-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 21:43: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 VAA19338 for ; Wed, 25 Jun 2003 21:43:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VLn1-00044j-00 for sipping-web-archive@ietf.org; Wed, 25 Jun 2003 21:43:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VLmv-00044g-00 for sipping-web-archive@ietf.org; Wed, 25 Jun 2003 21:43:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VLmw-0000RQ-1R; Wed, 25 Jun 2003 21: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 19VLls-0000GS-0R for sipping@optimus.ietf.org; Wed, 25 Jun 2003 21:42: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 VAA19200 for ; Wed, 25 Jun 2003 21:41:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VLlp-00042A-00 for sipping@ietf.org; Wed, 25 Jun 2003 21:41:53 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19VLle-00041P-00 for sipping@ietf.org; Wed, 25 Jun 2003 21:41:42 -0400 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5Q1f6c18671 for ; Wed, 25 Jun 2003 20:41:06 -0500 (CDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jun 2003 18:41:07 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D2094128EC@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'sipping@ietf.org'" Date: Wed, 25 Jun 2003 18:41:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33B84.01A17F0E" Subject: [Sipping] FW: I-D ACTION:draft-audet-sipping-add-realm-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. ------_=_NextPart_001_01C33B84.01A17F0E Content-Type: text/plain I would like to bring attention to the group to this draft which relates to ICE. > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, June 24, 2003 03:37 > Subject: I-D ACTION:draft-audet-sipping-add-realm-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Identifying intra-realm calls with > explicit addressing > realm identifier attribute > Author(s) : F. Audet > Filename : draft-audet-sipping-add-realm-00.txt > Pages : 10 > Date : 2003-6-23 > > This draft describes the use of an explicit addressing identifier > SDP attribute to assist in the process of choosing which addresses > shall be used by SIP User Agents (UAs) when multiple IP addresses > are known (STUN-derived, local, etc.). This draft complements the > Interactive Connectivity Establishment (ICE) draft. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-audet-sipping-add-realm-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-audet-sipping-add-realm-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-audet-sipping-add-realm-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_001_01C33B84.01A17F0E Content-Type: text/html Content-Transfer-Encoding: quoted-printable FW: I-D ACTION:draft-audet-sipping-add-realm-00.txt

I would like to bring attention to the group to this = draft which
relates to ICE.

> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org= ]
> Sent: Tuesday, June 24, 2003 03:37
> Subject: I-D = ACTION:draft-audet-sipping-add-realm-00.txt
>
>
> A New Internet-Draft is available from the = on-line
> Internet-Drafts directories.
>
>
>       = Title           : = Identifying intra-realm calls with
> explicit addressing
>          = ;            = ;     realm identifier attribute
>       = Author(s)       : F. Audet
>       = Filename        : = draft-audet-sipping-add-realm-00.txt
>       = Pages           : = 10
>       = Date            : = 2003-6-23
>      
> This draft describes the use of an explicit = addressing identifier
> SDP attribute to assist in the process of = choosing which addresses
> shall be used by SIP User Agents (UAs) when = multiple IP addresses
> are known (STUN-derived, local, etc.). This = draft complements the
> Interactive Connectivity Establishment (ICE) = draft.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-audet-sippin= g-add-realm-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-audet-sipping-add-realm-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-audet-sipping-add-realm-00.txt".
       =20
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.
        =        =20
        =        =20
Below is the data which will enable a MIME compliant = mail reader implementation to automatically retrieve the ASCII version = of the Internet-Draft.

------_=_NextPart_001_01C33B84.01A17F0E-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 26 20:47:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29184 for ; Thu, 26 Jun 2003 20:47:45 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5R0lIV19699 for sipping-archive@odin.ietf.org; Thu, 26 Jun 2003 20:47:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VhOY-00057e-2Z for sipping-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 20:47: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 UAA29168 for ; Thu, 26 Jun 2003 20:47:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VhOV-0007an-00 for sipping-web-archive@ietf.org; Thu, 26 Jun 2003 20:47:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VhOQ-0007ak-00 for sipping-web-archive@ietf.org; Thu, 26 Jun 2003 20:47:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VhOH-00051a-E3; Thu, 26 Jun 2003 20: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 19VhNm-000512-8P for sipping@optimus.ietf.org; Thu, 26 Jun 2003 20:46: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 UAA29156 for ; Thu, 26 Jun 2003 20:46:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VhNU-0007aF-00 for sipping@ietf.org; Thu, 26 Jun 2003 20:46:13 -0400 Received: from mailo.vtcif.telstra.com.au ([202.12.144.17]) by ietf-mx with esmtp (Exim 4.12) id 19VhN9-0007YD-00 for sipping@ietf.org; Thu, 26 Jun 2003 20:45:52 -0400 Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id KAA16365 for ; Fri, 27 Jun 2003 10:41:22 +1000 (EST) Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpd0zeMZm; Fri Jun 27 10:41:03 2003 Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id KAA24952 for ; Fri, 27 Jun 2003 10:41:03 +1000 (EST) Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpd0XSh.j; Fri Jun 27 10:40:31 2003 Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA09458 for ; Fri, 27 Jun 2003 10:40:25 +1000 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 27 Jun 2003 10:40:04 +1000 Message-ID: Thread-Topic: CLIP/CLIR support on redirecting number Thread-Index: AcM8RK8s+/9G5fpER3Wmnw7zLmRmYg== From: "Aders, David I" To: Content-Transfer-Encoding: quoted-printable Subject: [Sipping] CLIP/CLIR support on redirecting number Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 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 support for CLI restriction/presentation indication for the = redirecting number in a diverting call case, the case being PSTN -> SIP = (the redirecting number) diverting back out to the PSTN? Regards, David Aders Technology Specialist Voice Signalling, Interconnect and Routing Voice Platforms Technology and Deployment Voice Switching, Voice and Mobility Telstra __________________________________ Phone * + 61 3 9634 9007 Fax 7 + 61 3 9632 8658 Postal * 19/242 Exhibition Street, Melb VIC 3000 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 26 22:10:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01099 for ; Thu, 26 Jun 2003 22:10:40 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5R2ADt23308 for sipping-archive@odin.ietf.org; Thu, 26 Jun 2003 22:10:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vign-00063r-Jz for sipping-web-archive@optimus.ietf.org; Thu, 26 Jun 2003 22:10: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 WAA01081 for ; Thu, 26 Jun 2003 22:10:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Vigk-0000G2-00 for sipping-web-archive@ietf.org; Thu, 26 Jun 2003 22:10:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Vige-0000Fz-00 for sipping-web-archive@ietf.org; Thu, 26 Jun 2003 22:10:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vigb-0005tC-Dy; Thu, 26 Jun 2003 22:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vifg-0005sK-Ma for sipping@optimus.ietf.org; Thu, 26 Jun 2003 22:09: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 WAA01008; Thu, 26 Jun 2003 22:07:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Viea-0000F6-00; Thu, 26 Jun 2003 22:07:57 -0400 Received: from gateway.hns.com ([208.236.67.14]) by ietf-mx with esmtp (Exim 4.12) id 19VieQ-0000F3-00; Thu, 26 Jun 2003 22:07: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 h5R27Daf003261; Thu, 26 Jun 2003 22:07:14 -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 h5R277nU005889; Thu, 26 Jun 2003 22:07:07 -0400 (EDT) To: sipping@ietf.org, sipping-admin@ietf.org Subject: RE: [Sipping] I-D ACTION:draft-sharath-sipb-requirements-00.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Arjun Roychowdhury" Date: Thu, 26 Jun 2003 22:07:00 -0400 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.12 |February 13, 2003) at 06/26/2003 10:05:10 PM, Serialize complete at 06/26/2003 10:05:10 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: , My 'nit' contribution: I personally do not believe the existence of this draft either inhibits or improves innovation. All it is attempting to do is to specify a profile. It is important in that it is attempting to create a standard profile for a 'type of phone'. I personally disagree that it is anywhere close to outdated. But that is a matter of opinion (either way). If a particular 'communication device' does not fit into this profile, well, just dont try and fit it in ! If there is a contention with naming it a 'business phone' well, maybe the authors can consider renaming it so it does not offend any particular community. For example, I agree with Henry, that if this is called a 'business phone' then a Tablet may get disqualified to be called a 'business phone'. Which is valid. Therefore, would a name change be appropriate ? This draft otherwise is , in my opinion, very valuable within its premise. For those who are building these type of phones (very large market) this drafts is a great step forward. regds arjun -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301 212 7860 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 27 14:51:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12972 for ; Fri, 27 Jun 2003 14:51:05 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RIoZQ27584 for sipping-archive@odin.ietf.org; Fri, 27 Jun 2003 14:50:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VyIt-0007Ap-PF for sipping-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 14:50: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 OAA12929 for ; Fri, 27 Jun 2003 14:50: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 19VyIL-00071i-QP; Fri, 27 Jun 2003 14: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 19VyHj-0006zh-9D for sipping@optimus.ietf.org; Fri, 27 Jun 2003 14:49:23 -0400 Received: from tomts12-srv.bellnexxia.net (tomts12.bellnexxia.net [209.226.175.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12847 for ; Fri, 27 Jun 2003 14:49:07 -0400 (EDT) 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 <20030627184637.CYOJ27314.tomts12-srv.bellnexxia.net@Shulin> for ; Fri, 27 Jun 2003 14:46:37 -0400 From: "Shu-Lin CHen" To: Date: Fri, 27 Jun 2003 14:46:39 -0400 Message-ID: <000501c33cdc$71a227f0$390aa8c0@blueslicemtl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C33CBA.EA9087F0" 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] TLS vs IPSec Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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_0006_01C33CBA.EA9087F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi: Is there any history reason that TLS is selected for SIP security instead of IPSec? Just curious as a new comer in SIP area. Thanks. shu-lin ------=_NextPart_000_0006_01C33CBA.EA9087F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi:
 
Is there any=20 history reason that TLS is selected for SIP security instead of=20 IPSec?
Just curious as a=20 new comer in SIP area.
 
Thanks.
 
shu-lin
------=_NextPart_000_0006_01C33CBA.EA9087F0-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 27 15:04:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13787 for ; Fri, 27 Jun 2003 15:04:05 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RJ3ZU00725 for sipping-archive@odin.ietf.org; Fri, 27 Jun 2003 15:03:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VyVT-0000Bc-Kb for sipping-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 15:03: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 PAA13711 for ; Fri, 27 Jun 2003 15:03: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 19VyUv-0008VS-QO; Fri, 27 Jun 2003 15: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 19VyU8-0008Su-Bz for sipping@optimus.ietf.org; Fri, 27 Jun 2003 15:02: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 PAA13607 for ; Fri, 27 Jun 2003 15:01:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VyTs-0005Nd-00 for sipping@ietf.org; Fri, 27 Jun 2003 15:01:56 -0400 Received: from pmesmtp02.wcom.com ([199.249.20.2]) by ietf-mx with esmtp (Exim 4.12) id 19VyTi-0005Mb-00 for sipping@ietf.org; Fri, 27 Jun 2003 15:01:46 -0400 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HH500EI5L5FG0@firewall.wcom.com> for sipping@ietf.org; Fri, 27 Jun 2003 18:39:15 +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 <0HH500I01KY8ZA@pmismtp01.wcomnet.com> for sipping@ietf.org; Fri, 27 Jun 2003 18:39:15 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.136.167]) by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HH500IFJL4CNY@pmismtp01.wcomnet.com> for sipping@ietf.org; Fri, 27 Jun 2003 18:38:37 +0000 (GMT) Date: Fri, 27 Jun 2003 13:38:24 -0500 From: Alan Johnston X-Sender: Alan.Johnston@pop.mcit.com To: sipping@ietf.org Message-id: <5.2.1.1.0.20030627133549.01cfa020@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] FWD:I-D ACTION:draft-johnston-sipping-rtcp-summary-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: , 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 This document discusses the motivation and requirements for the delivery of RTCP extended reports and other summary reports to non-participants in the session. Several solution mechanisms are also discussed and compared. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-johnston-sipping-rtcp-summary-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-johnston-sipping-rtcp-summary-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-johnston-sipping-rtcp-summary-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Fri Jun 27 19:32:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26162 for ; Fri, 27 Jun 2003 19:32:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RNW6X26476 for sipping-archive@odin.ietf.org; Fri, 27 Jun 2003 19:32:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W2hK-0006si-Jm for sipping-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 19:32:06 -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 TAA26098 for ; Fri, 27 Jun 2003 19:32: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 19W2gI-0006TH-2K; Fri, 27 Jun 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 19W2fm-0006OF-2r for sipping@optimus.ietf.org; Fri, 27 Jun 2003 19: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 TAA25848 for ; Fri, 27 Jun 2003 19:29:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19W2O8-000791-00 for sipping@ietf.org; Fri, 27 Jun 2003 19:12:16 -0400 Received: from mta02-svc.ntlworld.com ([62.253.162.42]) by ietf-mx with esmtp (Exim 4.12) id 19W2Nx-000785-00 for sipping@ietf.org; Fri, 27 Jun 2003 19:12:06 -0400 Received: from winxp ([80.3.228.180]) by mta02-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with SMTP id <20030627231004.WZJM4771.mta02-svc.ntlworld.com@winxp>; Sat, 28 Jun 2003 00:10:04 +0100 Message-ID: <002801c33d01$40e3abf0$b4e40350@winxp> From: "James Undery" To: "Shu-Lin CHen" , References: <000501c33cdc$71a227f0$390aa8c0@blueslicemtl> Subject: Re: [Sipping] TLS vs IPSec Date: Sat, 28 Jun 2003 00:10:08 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01C33D09.A2789F80" 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 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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_0025_01C33D09.A2789F80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MessageHi, The main problem with IPSec is that it's a touch difficult to know when = it's being used (and how) at the application level, TLS is more obvious = to applications. That said it's a bit of a religious argument on most other points, and = some SIP architectures use IPSec (3GPP IIRC) at certain points of the = network. James ----- Original Message -----=20 From: Shu-Lin CHen=20 To: sipping@ietf.org=20 Sent: Friday, June 27, 2003 7:46 PM Subject: [Sipping] TLS vs IPSec Hi: Is there any history reason that TLS is selected for SIP security = instead of IPSec? Just curious as a new comer in SIP area. Thanks. shu-lin ------=_NextPart_000_0025_01C33D09.A2789F80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi,
 
The main problem with IPSec is that = it's a touch=20 difficult to know when it's being used (and how) at the application = level, TLS=20 is more obvious to applications.
 
That said it's a bit of a religious = argument on=20 most other points, and some SIP architectures use IPSec (3GPP IIRC) at = certain=20 points of the network.
 
James
----- Original Message -----
From:=20 Shu-Lin=20 CHen
Sent: Friday, June 27, 2003 = 7:46 PM
Subject: [Sipping] TLS vs = IPSec

Hi:
 
Is there any=20 history reason that TLS is selected for SIP security instead of=20 IPSec?
Just curious as=20 a new comer in SIP area.
 
Thanks.
 
shu-lin
------=_NextPart_000_0025_01C33D09.A2789F80-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 28 03:44:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17941 for ; Sat, 28 Jun 2003 03:44:08 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5S7hbX21393 for sipping-archive@odin.ietf.org; Sat, 28 Jun 2003 03:43:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WAMz-0005Yl-GI for sipping-web-archive@optimus.ietf.org; Sat, 28 Jun 2003 03:43: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 DAA17934 for ; Sat, 28 Jun 2003 03:43:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WAMh-00021n-00 for sipping-web-archive@ietf.org; Sat, 28 Jun 2003 03:43:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19WAMa-00021U-00 for sipping-web-archive@ietf.org; Sat, 28 Jun 2003 03:43:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WAMT-0005Tu-JA; Sat, 28 Jun 2003 03:43:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W1eN-0006v7-SS for sipping@optimus.ietf.org; Fri, 27 Jun 2003 18:24: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 SAA23126 for ; Fri, 27 Jun 2003 18:24:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19W1eK-0006jP-00 for sipping@ietf.org; Fri, 27 Jun 2003 18:24:56 -0400 Received: from [65.200.90.207] (helo=mailserver.sylantro.com) by ietf-mx with smtp (Exim 4.12) id 19W1eA-0006j2-00 for sipping@ietf.org; Fri, 27 Jun 2003 18:24:46 -0400 Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Fri, 27 Jun 2003 15:22:09 -0700 X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Received: by mailserver.sylantro.com with Internet Mail Service ( 5.5.2653.19) id ; Fri, 27 Jun 2003 15:22:09 -0700 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD68AF65@mailserver.sylantro.com> From: "Mike Chack" To: "'sipping@ietf.org'" Subject: RE: [Sipping] I-D ACTION:draft-sharath-sipb-requirements-00.txt Date: Fri, 27 Jun 2003 15:22:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 12E21C1B163813-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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 From exim@www1.ietf.org Sat Jun 28 03:47:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18088 for ; Sat, 28 Jun 2003 03:47:41 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5S7lBj24312 for sipping-archive@odin.ietf.org; Sat, 28 Jun 2003 03:47:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WAQR-0006K3-BL for sipping-web-archive@optimus.ietf.org; Sat, 28 Jun 2003 03:47:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17922 for ; Sat, 28 Jun 2003 03:43:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WAMg-00021b-00 for sipping-web-archive@ietf.org; Sat, 28 Jun 2003 03:43:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19WAMa-00021O-00 for sipping-web-archive@ietf.org; Sat, 28 Jun 2003 03:43:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WAMP-0005SI-Ou; Sat, 28 Jun 2003 03: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 19UUcQ-0002AY-6y for sipping@optimus.ietf.org; Mon, 23 Jun 2003 12: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 MAA28691 for ; Mon, 23 Jun 2003 12:56:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UUc9-0003qE-00 for sipping@ietf.org; Mon, 23 Jun 2003 12:56:21 -0400 Received: from mail3.pi.se ([195.7.64.137]) by ietf-mx with esmtp (Exim 4.12) id 19UUby-0003q4-00 for sipping@ietf.org; Mon, 23 Jun 2003 12:56:10 -0400 Received: from VAIOMHP (130.240.13.217.in-addr.dgcsystems.net [217.13.240.130]) (authenticated) by mail3.pi.se (8.11.2/8.11.2) with ESMTP id h5NGti732611; Mon, 23 Jun 2003 18:55:44 +0200 (CEST) From: =?us-ascii?Q?Gunnar_Hellstrom?= To: "'Sipping@Ietf. Org'" , , "'Mike Spanner'" , "'James Hamlin'" , , , , , "'Guido Gybels'" , , "'Judy Harkins'" , "'Trefor Davies'" , "Henry Sinnreich" Cc: , , , Subject: [Sipping] Sipdev, incoming call alert (ring signal equivalents) Date: Mon, 23 Jun 2003 18:55:34 +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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <000501c3398d$79bae7d0$d86932a6@hsinnreich2> Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In 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 From exim@www1.ietf.org Sat Jun 28 03:47:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18103 for ; Sat, 28 Jun 2003 03:47:41 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5S7lCh24329 for sipping-archive@odin.ietf.org; Sat, 28 Jun 2003 03:47:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WAQS-0006KK-JP for sipping-web-archive@optimus.ietf.org; Sat, 28 Jun 2003 03:47: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 DAA17925 for ; Sat, 28 Jun 2003 03:43:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WAMh-00021g-00 for sipping-web-archive@ietf.org; Sat, 28 Jun 2003 03:43:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19WAMa-00021N-00 for sipping-web-archive@ietf.org; Sat, 28 Jun 2003 03:43:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WAMQ-0005Sh-UI; Sat, 28 Jun 2003 03: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 19UX2X-0000wY-VB for sipping@optimus.ietf.org; Mon, 23 Jun 2003 15:32: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 PAA07032 for ; Mon, 23 Jun 2003 15:31:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UX2H-00058k-00 for sipping@ietf.org; Mon, 23 Jun 2003 15:31:29 -0400 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by ietf-mx with esmtp (Exim 4.12) id 19UX26-00057d-00 for sipping@ietf.org; Mon, 23 Jun 2003 15:31:18 -0400 Received: from dgismtp06.wcomnet.com ([166.38.58.89]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HGY006E48R7LS@firewall.wcom.com> for sipping@ietf.org; Mon, 23 Jun 2003 19:28:19 +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 <0HGY002018R5FK@dgismtp06.wcomnet.com>; Mon, 23 Jun 2003 19:28:18 +0000 (GMT) Received: from hsinnreich2 ([166.50.145.238]) by dgismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HGY001CY8R31Q@dgismtp06.wcomnet.com>; Mon, 23 Jun 2003 19:28:18 +0000 (GMT) Date: Mon, 23 Jun 2003 14:28:16 -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: <000901c339bd$997ca1f0$ee9132a6@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 > 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. I believe this is a good suggestion. With MAY in the general section or MUST for haering disabled. Henry > -----Original Message----- > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > 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 From exim@www1.ietf.org Sat Jun 28 04:32:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17942 for ; Sat, 28 Jun 2003 03:44:08 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5S7hbg21373 for sipping-archive@odin.ietf.org; Sat, 28 Jun 2003 03:43:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WAMz-0005YZ-BC for sipping-web-archive@optimus.ietf.org; Sat, 28 Jun 2003 03:43: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 DAA17927 for ; Sat, 28 Jun 2003 03:43:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WAMh-00021l-00 for sipping-web-archive@ietf.org; Sat, 28 Jun 2003 03:43:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19WAMa-00021P-00 for sipping-web-archive@ietf.org; Sat, 28 Jun 2003 03:43:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WAMR-0005T6-Tt; Sat, 28 Jun 2003 03:43:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VNqc-00016B-Go for sipping@optimus.ietf.org; Wed, 25 Jun 2003 23:55: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 XAA24509 for ; Wed, 25 Jun 2003 23:54:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VNqa-0005Dg-00 for sipping@ietf.org; Wed, 25 Jun 2003 23:54:56 -0400 Received: from [65.200.90.207] (helo=mailserver.sylantro.com) by ietf-mx with smtp (Exim 4.12) id 19VNqP-0005Dd-00 for sipping@ietf.org; Wed, 25 Jun 2003 23:54:45 -0400 Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Wed, 25 Jun 2003 20:53:27 -0700 X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Received: by mailserver.sylantro.com with Internet Mail Service ( 5.5.2653.19) id ; Wed, 25 Jun 2003 20:53:27 -0700 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD020D5ADC@mailserver.sylantro.com> From: "Sharath Rajasekar" To: "'Henry.Sinnreich@mci.com'" , "'sipping@ietf.org'" cc: "Venkatesh Venkataramanan" Subject: RE: [Sipping] I-D ACTION:draft-sharath-sipb-requirements-00.txt Date: Wed, 25 Jun 2003 20:53:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 12E4B1BD96592-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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/listinfo/sipping -- This list is for NEW development of the application of SIP -- Use sip-implementors@cs.columbia.edu for questions on current sip -- Use sip@ietf.org for new developments of core SIP -- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 Jun 28 04:33:36 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 DAA17943 for ; Sat, 28 Jun 2003 03:44:08 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5S7hb521367 for sipping-archive@odin.ietf.org; Sat, 28 Jun 2003 03:43:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WAMz-0005YX-9c for sipping-web-archive@optimus.ietf.org; Sat, 28 Jun 2003 03:43: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 DAA17929 for ; Sat, 28 Jun 2003 03:43:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WAMh-00021m-00 for sipping-web-archive@ietf.org; Sat, 28 Jun 2003 03:43:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19WAMa-00021S-00 for sipping-web-archive@ietf.org; Sat, 28 Jun 2003 03:43:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WAMS-0005TV-Od; Sat, 28 Jun 2003 03:43:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VuSM-0002P9-Ub for sipping@optimus.ietf.org; Fri, 27 Jun 2003 10:44: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 IAA26052 for ; Fri, 27 Jun 2003 08:42:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VsYx-0002IO-00 for sipping@ietf.org; Fri, 27 Jun 2003 08:42:47 -0400 Received: from [65.200.90.207] (helo=mailserver.sylantro.com) by ietf-mx with smtp (Exim 4.12) id 19VsYm-0002Fy-00 for sipping@ietf.org; Fri, 27 Jun 2003 08:42:36 -0400 Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Fri, 27 Jun 2003 05:40:23 -0700 X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Received: by mailserver.sylantro.com with Internet Mail Service ( 5.5.2653.19) id ; Fri, 27 Jun 2003 05:40:22 -0700 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD02AB03F5@mailserver.sylantro.com> From: "Mike Chack" To: sipping@ietf.org Subject: RE: [Sipping] I-D ACTION:draft-sharath-sipb-requirements-00.txt Date: Fri, 27 Jun 2003 05:40:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 12E2E4BC150143-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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 From exim@www1.ietf.org Mon Jun 30 00:17:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16973 for ; Mon, 30 Jun 2003 00:17:50 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5U4HM719333 for sipping-archive@odin.ietf.org; Mon, 30 Jun 2003 00:17:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wq6U-00051k-NU for sipping-web-archive@optimus.ietf.org; Mon, 30 Jun 2003 00:17: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 AAA16961 for ; Mon, 30 Jun 2003 00:17:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Wq6S-0003EI-00 for sipping-web-archive@ietf.org; Mon, 30 Jun 2003 00:17:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Wq6M-0003EE-00 for sipping-web-archive@ietf.org; Mon, 30 Jun 2003 00:17:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wq69-0004ym-DQ; Mon, 30 Jun 2003 00: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 19Wq5N-0004xu-Gr for sipping@optimus.ietf.org; Mon, 30 Jun 2003 00:16: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 AAA16931 for ; Mon, 30 Jun 2003 00:15:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Wq56-0003E0-00 for sipping@ietf.org; Mon, 30 Jun 2003 00:15:56 -0400 Received: from cerbrus.convedia.com ([216.129.93.50]) by ietf-mx with esmtp (Exim 4.12) id 19Wq4v-0003DI-00 for sipping@ietf.org; Mon, 30 Jun 2003 00:15:45 -0400 Received: from ladon.convedia.com (ladon [192.168.208.15]) by cerbrus.convedia.com (8.12.9/8.12.9) with ESMTP id h5U4C4CW017306 for ; Sun, 29 Jun 2003 21:12:04 -0700 (PDT) Received: from laptop200 (dave-is.convedia.com [192.168.208.162]) by ladon.convedia.com (8.9.3+Sun/8.9.3) with SMTP id VAA14013 for ; Sun, 29 Jun 2003 21:14:54 -0700 (PDT) From: "Garland Sharratt" To: "Sipping@Ietf. Org" Date: Sun, 29 Jun 2003 21:14:50 -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.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [Sipping] 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 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 Mon Jun 30 01:45:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19270 for ; Mon, 30 Jun 2003 01:45:20 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5U5ip200328 for sipping-archive@odin.ietf.org; Mon, 30 Jun 2003 01:44:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WrT9-00005D-ON for sipping-web-archive@optimus.ietf.org; Mon, 30 Jun 2003 01:44: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 BAA19242 for ; Mon, 30 Jun 2003 01:44:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WrT6-0003ge-00 for sipping-web-archive@ietf.org; Mon, 30 Jun 2003 01:44:48 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19WrT1-0003gb-00 for sipping-web-archive@ietf.org; Mon, 30 Jun 2003 01:44:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WrSL-0008KT-La; Mon, 30 Jun 2003 01: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 19WrRN-0008Hj-5x for sipping@optimus.ietf.org; Mon, 30 Jun 2003 01:43: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 BAA19157; Mon, 30 Jun 2003 01:42:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WrLt-0003e0-00; Mon, 30 Jun 2003 01:37:21 -0400 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 19WrLi-0003dq-00; Mon, 30 Jun 2003 01:37:10 -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 h5U5an1R019898; Mon, 30 Jun 2003 14:36:49 +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 h5U5an8E029542; Mon, 30 Jun 2003 14:36:49 +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 h5U5ameH000053; Mon, 30 Jun 2003 14:36:48 +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 OAA10209; Mon, 30 Jun 2003 14:36:48 +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 OAA21621; Mon, 30 Jun 2003 14:36:47 +0900 (JST) Message-Id: <5.1.1.9.2.20030630143131.040e8388@imj.m.ecl.ntt.co.jp> X-Sender: nm014@imj.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr3 Date: Mon, 30 Jun 2003 14:37:18 +0900 To: tsvwg@ietf.org, sipping@ietf.org From: "MORITA, Naotaka" Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Priority Promotion Scheme Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk 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 am Naotaka Morita working for NTT Laboratories. I would like to draw your attention to the following new ID. The purpose of this draft is to identify the Priority Promotion Scheme and to define a new Measurable Forwarding Per-Hop Behavior. Althouhg this is targeted to tsvwg, I would like to discuss this regarding the interaction between SIP proxies and edge routers to provide QoS guaranteed service. Naotaka Morita ============ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Framework of Priority Promotion Scheme Author(s) : N. Morita, G. Karlsson Filename : draft-morita-tsvwg-pps-00.txt Pages : 20 Date : 2003-6-25 This document describes a framework of a new scheme for traffic control to achieve end-to-end QoS for interactive multimedia services. The scheme is based on end-to-end measurement of network resources by end systems. The network is assumed to fully support the priority control scheme specified in the Diffserv architecture for QoS and SIP [1] for session control. Since the scheme relies on the behavior of the end systems, this document also touches on mechanisms for monitoring end-system behavior. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-morita-tsvwg-pps-00.txt ---------------------------------- 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 Mon Jun 30 05:47:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07296 for ; Mon, 30 Jun 2003 05:47:38 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5U9lBi19440 for sipping-archive@odin.ietf.org; Mon, 30 Jun 2003 05:47:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WvFf-00053T-8m for sipping-web-archive@optimus.ietf.org; Mon, 30 Jun 2003 05:47:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07293 for ; Mon, 30 Jun 2003 05:47:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WvFb-0005EN-00 for sipping-web-archive@ietf.org; Mon, 30 Jun 2003 05:47:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19WvFW-0005EK-00 for sipping-web-archive@ietf.org; Mon, 30 Jun 2003 05:47:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WvFW-00052Y-0y; Mon, 30 Jun 2003 05: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 19WvE7-00050Y-62 for sipping@optimus.ietf.org; Mon, 30 Jun 2003 05: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 FAA07255 for ; Mon, 30 Jun 2003 05:45:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WvE3-0005Dt-00 for sipping@ietf.org; Mon, 30 Jun 2003 05:45:31 -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 19WvDs-0005DQ-00 for sipping@ietf.org; Mon, 30 Jun 2003 05:45:20 -0400 Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5U9ipw2010945; Mon, 30 Jun 2003 11:44:51 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id NW48J1A1; Mon, 30 Jun 2003 11:46:56 +0200 Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.31.89]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h5U9ifSZ005640; Mon, 30 Jun 2003 12:44:41 +0300 (EET DST) Message-ID: <3F000692.9000109@ericsson.com> Date: Mon, 30 Jun 2003 12:44:50 +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.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: es,en MIME-Version: 1.0 To: Jonathan Rosenberg , sipping@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Comments on draft-ietf-sipping-session-policy-req-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 Jonathan: Here are some thoughts about the Session Policy requirements draft. 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". You have an open issue in REQ-SEC-4, questioning the validity of the requirement: The mechanism should allow proxies to ensure the confidentiality of the session policies, so that no one but the UAC or UAS can observe them. I think it is a valid requirement. I foresee that the administrators would not like to disclose their policies to administrators of other domains. Although I suspect this information could be acquired by some other means. The las issue I want to raise is related to the wireless scenario that you describe in the introduction: "In another application, SIP is used in a wireless network. The network provider has limited resources for media traffic. During periods of high activity, the provider would like to restrict codec usage on the network to lower rate codecs." 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. 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. Regards, Miguel -- 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 Jun 30 06:52:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09128 for ; Mon, 30 Jun 2003 06:52:41 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5UAqDx29006 for sipping-archive@odin.ietf.org; Mon, 30 Jun 2003 06:52:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WwGb-0007Xl-0P for sipping-web-archive@optimus.ietf.org; Mon, 30 Jun 2003 06:52: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 GAA09114 for ; Mon, 30 Jun 2003 06:52:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WwGW-0005fz-00 for sipping-web-archive@ietf.org; Mon, 30 Jun 2003 06:52:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19WwGR-0005fw-00 for sipping-web-archive@ietf.org; Mon, 30 Jun 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 19WwGP-0007Uu-Rq; Mon, 30 Jun 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 19WwFz-0007UO-1y for sipping@optimus.ietf.org; Mon, 30 Jun 2003 06:51: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 GAA09095 for ; Mon, 30 Jun 2003 06:51:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WwFu-0005fR-00 for sipping@ietf.org; Mon, 30 Jun 2003 06:51:30 -0400 Received: from mail5.telekom.de ([62.225.183.202] helo=mail1.telekom.de) by ietf-mx with esmtp (Exim 4.12) id 19WwFk-0005eG-00 for sipping@ietf.org; Mon, 30 Jun 2003 06:51:20 -0400 Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 30 Jun 2003 12:49:20 +0200 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jun 2003 12:49:09 +0200 Message-Id: <8730C545389BD7118BCE000347055E66334CA4@G9JNV.mgb01.telekom.de> From: "Beck01, Wolfgang" To: morita.naotaka@lab.ntt.co.jp, sipping@ietf.org Subject: RE: [Sipping] Priority Promotion Scheme Date: Mon, 30 Jun 2003 12:49:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-2022-jp" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Naotaka, first of all, I am glad to see that I am not the only one who is interested in endpoint admission control in the SIP context. However, I don't think the proxy can derive bandwidth requirements from the SDP body of a SIP message. To do so, it would have to know every codec available. SDP bodies can even be encrypted. Only the user agents know what bandwidth they are going to use. They know about the packet size (not included in SDP) and voice activity detection (not included in SDP). Maybe the SIP User Agents could use some RSVP variant to tell the edge router, like in RfC 3313 6.1? Wolfgang > > Title : Framework of Priority Promotion Scheme > Author(s) : N. Morita, G. Karlsson > Filename : draft-morita-tsvwg-pps-00.txt > Pages : 20 > Date : 2003-6-25 > > This document describes a framework of a new scheme for traffic > control to achieve end-to-end QoS for interactive multimedia > services. The scheme is based on end-to-end measurement of network > resources by end systems. The network is assumed to fully support > the priority control scheme specified in the Diffserv architecture > for QoS and SIP [1] for session control. Since the scheme relies on > the behavior of the end systems, this document also touches on > mechanisms for monitoring end-system behavior. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-morita-tsvwg-pps-00.txt -- 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 Mon Jun 30 07:38:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10995 for ; Mon, 30 Jun 2003 07:38:39 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5UBc9W04800 for sipping-archive@odin.ietf.org; Mon, 30 Jun 2003 07:38:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wwz3-0001FL-Ev for sipping-web-archive@optimus.ietf.org; Mon, 30 Jun 2003 07:38: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 HAA10870 for ; Mon, 30 Jun 2003 07:38:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Wwz2-0005yl-00 for sipping-web-archive@ietf.org; Mon, 30 Jun 2003 07:38:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Wwyx-0005yi-00 for sipping-web-archive@ietf.org; Mon, 30 Jun 2003 07: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 19Wwyu-0001Ad-VB; Mon, 30 Jun 2003 07:38:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wwy8-00011C-2c for sipping@optimus.ietf.org; Mon, 30 Jun 2003 07:37: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 HAA10707 for ; Mon, 30 Jun 2003 07:37:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Wwy7-0005y1-00 for sipping@ietf.org; Mon, 30 Jun 2003 07:37:11 -0400 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 19Wwxv-0005xT-00 for sipping@ietf.org; Mon, 30 Jun 2003 07:37:00 -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 h5UBZs1R021479; Mon, 30 Jun 2003 20:35:54 +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 h5UBZs8E024427; Mon, 30 Jun 2003 20:35:54 +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 h5UBZreH029426; Mon, 30 Jun 2003 20:35:53 +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 UAA12962; Mon, 30 Jun 2003 20:35:53 +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 UAA24160; Mon, 30 Jun 2003 20:35:52 +0900 (JST) Message-Id: <5.1.1.9.2.20030630202853.040e64a0@imj.m.ecl.ntt.co.jp> X-Sender: nm014@imj.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr3 Date: Mon, 30 Jun 2003 20:36:10 +0900 To: "Beck01, Wolfgang" , sipping@ietf.org From: "MORITA, Naotaka" Subject: RE: [Sipping] Priority Promotion Scheme In-Reply-To: <8730C545389BD7118BCE000347055E66334CA4@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, Thank you for you comment. I would like to clarify the discussion items. 1) The effectiveness of endpoint adimssion control. This is the matter whether the measurement based approach is valid or not. This issue will be discussed at the TSVWG on Friday. 2) Interaction to edge routers This is the matter of SIPPING, I believe. I would like to hear other experts opinion, because this is the common issue for all QoS guaranteed schemes. Are there any way to control edge routers by SIP proxies? Naotaka At 12:49 03/06/30 +0200, Beck01, Wolfgang wrote: >Naotaka, > >first of all, I am glad to see that I am not the only one >who is interested in endpoint admission control in the SIP >context. However, I don't think the proxy can derive bandwidth >requirements from the SDP body of a SIP message. To do so, >it would have to know every codec available. SDP bodies can >even be encrypted. Only the user agents know what bandwidth >they are going to use. They know about the packet size (not >included in SDP) and voice activity detection (not included >in SDP). > >Maybe the SIP User Agents could use some RSVP variant to >tell the edge router, like in RfC 3313 6.1? > >Wolfgang > > > > > > Title : Framework of Priority Promotion Scheme > > Author(s) : N. Morita, G. Karlsson > > Filename : draft-morita-tsvwg-pps-00.txt > > Pages : 20 > > Date : 2003-6-25 > > > > This document describes a framework of a new scheme for traffic > > control to achieve end-to-end QoS for interactive multimedia > > services. The scheme is based on end-to-end measurement of network > > resources by end systems. The network is assumed to fully support > > the priority control scheme specified in the Diffserv architecture > > for QoS and SIP [1] for session control. Since the scheme relies on > > the behavior of the end systems, this document also touches on > > mechanisms for monitoring end-system behavior. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-morita-tsvwg-pps-00.txt >-- >Wolfgang Beck >T-Systems Nova GmbH ---------------------------------- 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 Mon Jun 30 11:16: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 LAA00412 for ; Mon, 30 Jun 2003 11:16:56 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5UFGSA17912 for sipping-archive@odin.ietf.org; Mon, 30 Jun 2003 11:16:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X0OK-0004ep-Bl for sipping-web-archive@optimus.ietf.org; Mon, 30 Jun 2003 11:16: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 LAA00379 for ; Mon, 30 Jun 2003 11:16:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X0OH-0001jF-00 for sipping-web-archive@ietf.org; Mon, 30 Jun 2003 11:16:25 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19X0O6-0001jB-00 for sipping-web-archive@ietf.org; Mon, 30 Jun 2003 11:16:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X0Nv-0004bR-Im; Mon, 30 Jun 2003 11:16:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X0Nm-0004am-FV for sipping@optimus.ietf.org; Mon, 30 Jun 2003 11:15: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 LAA00351 for ; Mon, 30 Jun 2003 11:15:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X0NV-0001ip-00 for sipping@ietf.org; Mon, 30 Jun 2003 11:15:37 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19X0NG-0001i3-00 for sipping@ietf.org; Mon, 30 Jun 2003 11:15:22 -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 LAA08778 for ; Mon, 30 Jun 2003 11:14:19 -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 LAA27846 for ; Mon, 30 Jun 2003 11:14:18 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jun 2003 11:14:17 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5B72@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'sipping@ietf.org'" Date: Mon, 30 Jun 2003 11:14:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] What is a Tuple -- categorizing rows Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , One of the issues that was not resolved in the "what is a tuple" design team was a problem that Robert characterizes as: "whether a PA needs to expose the policy it used to create tuples to the watcher and whether a watcher needs to be able to request a certain policy" I am the main protagonist on this issue. I hope we can have a good discussion on the problem in Vienna, but for those of you not coming, I think it would be a good idea to at least alert you to the problem. First of all, I don't like characterizing the problem as "exposing a policy". I want the rows labeled with what they represent. We have at least three possible things a row can represent: a device a "service" a presentity There might be more. We agree that we don't have a good definition of "service", but we can come up with examples. One example is an IM service that seamlessly migrates from one physical device to another without the buddy's knowledge. Another is a "find me follow me" telephony service. Services follow the definition of a tuple given = a contact and a set of characteristics about that contact. The current proposal on the table is to represent the data the PA has as a kind of table in a database. The columns represent characteristics (RPIDS items, for example). The rows represent a "pivot" of the table, using the kinds of operations a database SQL SELECT statement might be able to accomplish. In particular, it would be some kind of rule based on columns. The result of this would be a "view" of the data. In this design, if the raw data was something akin to a device, in theory, you could define a pivot that made a "service" view, and another that made a presentity view. The majority of people on the design team believe that it is not important for the watcher to know what the rows represent. They can be anything (devices, services, presentities, or something else), and the watcher doesn't care, or more precisely, can't really do anything with any additional information about what the rows represent. My opinion is that what the rows represent is essential information for the watcher, so that it knows how to render the data, and so that for watcher that are automatons, so that the automaton can correctly process the information it is given. In response to a request for an example, I offered the following: > View presented from PA implementation 1 > > AOR contact media status geoloc > br@example.com ae22@example.com aud,vid,im open x1,y1 > br@example.com 9967@example.com aud open x1,y1 > br@example.com 4a66@example.com aud,vid,im open x1,y1 > br@example.com 5551212@cell.net aud,im open x2,y2 > br@example.com br665@pda.com im open x3,y3 > > View presented from PA implementation 2 > > AOR contact media status geoloc > br@example.com 54ea@example.com aud open x1,y1:x2,y2 > br@example.com b56c@example.com aud,vid open x1,y1 > br@example.com 32a1@example.com im open x1,y1:x3,y3 > > View presented from PA implementation 3 > > AOR contact media status geoloc > br@example.com 7a24@example.com aud,vid,im open x1,y1:x2,y2:x3,y3 > > View presented from PA implementation 4 > > AOR contact media status geoloc > br@example.com 7a24@example.com aud,im open x2,y2 > > All of these represent the same person, who happens to be in > an associate's office a building away. > > I claim that unless I very explicitly explain what each of these > PA implementations represent, a watcher can't do anything intelligent > with the data except print it out. The last two are interesting. > Implementation 3 does what I think a "pivot on AOR" means. Implementation > 4 is using information it has to make an intelligent guess as to > what is happening, to present the most likely state of the presentity. > The PA, because it knows the presentity, can decide whether to offer > IM or not. Since the presentity is in the building, IM likely will work. > If the presentity is, say, driving a car, it likely won't. It's the > PA that knows the limits of the campus to make the guess. It is a guess. I believe that while many systems will have device level data at the PA, they will not offer that information to a watcher. For privacy and called party preference reasons, they will never give you a device view. They will only give you a presentity view. Normally, this would be one row in the proposed model. It's possible that some systems will only give you a service view. This mail is getting long, so I am going to stop here, but my proposal is to have a characteristic for a view that presents what the rows represent, which is a choice from an IANA registered list, of which we will have three initial entries ('device', 'service', 'presentity') and an extension mechanism. Brian _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Jun 30 11:21:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00791 for ; Mon, 30 Jun 2003 11:21:01 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5UFKXq20423 for sipping-archive@odin.ietf.org; Mon, 30 Jun 2003 11:20:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X0SH-0005JK-C8 for sipping-web-archive@optimus.ietf.org; Mon, 30 Jun 2003 11:20: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 LAA00761 for ; Mon, 30 Jun 2003 11:20: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 19X0Rl-0005Co-F1; Mon, 30 Jun 2003 11:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X0RZ-0005C3-Ku for sipping@optimus.ietf.org; Mon, 30 Jun 2003 11:19: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 LAA00711 for ; Mon, 30 Jun 2003 11:19:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X0RW-0001m3-00 for sipping@ietf.org; Mon, 30 Jun 2003 11:19:46 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19X0RH-0001le-00 for sipping@ietf.org; Mon, 30 Jun 2003 11:19:32 -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 LAA09001 for ; Mon, 30 Jun 2003 11:18:53 -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 LAA28564 for ; Mon, 30 Jun 2003 11:18:54 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jun 2003 11:18:53 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5B74@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'sipping@ietf.org'" Date: Mon, 30 Jun 2003 11:18:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] RE: What is a Tuple -- categorizing rows Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , My apologies for addressing this message to the wrong list. If you reply to the original, PLEASE change the address for the reply to SIMPLE. Brian _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From exim@www1.ietf.org Mon Jun 30 11:27:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01096 for ; Mon, 30 Jun 2003 11:27:01 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5UFQXs21955 for sipping-archive@odin.ietf.org; Mon, 30 Jun 2003 11:26:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X0Y5-0005i2-7Y for sipping-web-archive@optimus.ietf.org; Mon, 30 Jun 2003 11:26: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 LAA01078 for ; Mon, 30 Jun 2003 11:26:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X0Xa-0005Zx-8Z; Mon, 30 Jun 2003 11:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X0XM-0005ZW-4w for sipping@optimus.ietf.org; Mon, 30 Jun 2003 11:25: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 LAA01028 for ; Mon, 30 Jun 2003 11:25:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X0X4-0001ob-00 for sipping@ietf.org; Mon, 30 Jun 2003 11:25:30 -0400 Received: from mail5.telekom.de ([62.225.183.202] helo=mail1.telekom.de) by ietf-mx with esmtp (Exim 4.12) id 19X0Wp-0001o3-00 for sipping@ietf.org; Mon, 30 Jun 2003 11:25:16 -0400 Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 30 Jun 2003 17:23:39 +0200 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jun 2003 17:23:28 +0200 Message-Id: <8730C545389BD7118BCE000347055E66334CA7@G9JNV.mgb01.telekom.de> From: "Beck01, Wolfgang" To: morita.naotaka@lab.ntt.co.jp, sipping@ietf.org Subject: RE: [Sipping] Priority Promotion Scheme Date: Mon, 30 Jun 2003 17:23:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-2022-jp" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 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? -- 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

_______________________________________________
Sign-up for your = own=20 FREE Personalized E-mail at Mail.com