From mailnull@www1.ietf.org Thu May 1 03:42: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 DAA01305 for ; Thu, 1 May 2003 03:42:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h417mc031644 for sipping-archive@odin.ietf.org; Thu, 1 May 2003 03:48: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 h417mc831641 for ; Thu, 1 May 2003 03:48: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 DAA01283 for ; Thu, 1 May 2003 03:42:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B8jv-00075E-00 for sipping-web-archive@ietf.org; Thu, 01 May 2003 03:44:23 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19B8ju-00075A-00 for sipping-web-archive@ietf.org; Thu, 01 May 2003 03:44: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 h417kF831560; Thu, 1 May 2003 03:46: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 h417gt831452 for ; Thu, 1 May 2003 03:42: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 DAA01181 for ; Thu, 1 May 2003 03:36:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B8eG-00073N-00 for sipping@ietf.org; Thu, 01 May 2003 03:38:32 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19B8e9-00072z-00 for sipping@ietf.org; Thu, 01 May 2003 03:38:26 -0400 Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h417cQdh004803 for ; Thu, 1 May 2003 03:38:27 -0400 (EDT) Message-ID: <3EB09353.6070601@dynamicsoft.com> Date: Wed, 30 Apr 2003 23:24:03 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Conferencing Framework open issue: scope of data which is manipulated by CPCP Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eric raised an issue in his comments on conf-fw, to which I replied: >> Also, w.r.t. section 5.8.2, I would really hope that CPCP is SIP: >> I'm really hesitant to have to implement all the same protocol >> actions with two different protocols "just because." Let's pick >> one and run with it. > > > See above discussion on why these are just not the same. In the case > of conference participants, you will basically learn them as the > result of a full-state update generated by a subscription to the > conference state. CPCP, being a data transaction protocol, would > also allow you to directly query for the list. Just because there is > this sliver of overlap does not mean that they are the same protocol. > My response is wrong. In the current design, you cannot use CPCP to access any of the focus state, such as the current participant list. It is strictly viewed as a protocol for manipulated the conference POLICY. This leads to the question - is this sensible? On one hand, one would expect that a protocol for accessing state of the conference should give you access to ALL of the state, not just the subset which is defined as policy. On the other hand, as Eric points out, conference policy and conference state are very different. Indeed, they may likely reside in entirely different servers in the network. One can imagine using an external DB to hold the policy, whereas focus state is in-memory soft-state. Thus, using the same protocol to access them may be complicated to support. What do people think about this issue? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu May 1 03:43: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 DAA01320 for ; Thu, 1 May 2003 03:43:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h417mtQ31672 for sipping-archive@odin.ietf.org; Thu, 1 May 2003 03:48: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 h417mt831669 for ; Thu, 1 May 2003 03:48: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 DAA01295 for ; Thu, 1 May 2003 03:42:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B8kB-00075b-00 for sipping-web-archive@ietf.org; Thu, 01 May 2003 03:44:39 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19B8kB-00075Y-00 for sipping-web-archive@ietf.org; Thu, 01 May 2003 03:44: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 h417kk831589; Thu, 1 May 2003 03:46: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 h417gt831451 for ; Thu, 1 May 2003 03:42: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 DAA01183 for ; Thu, 1 May 2003 03:36:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B8eG-00073O-00 for sipping@ietf.org; Thu, 01 May 2003 03:38:32 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19B8e9-00072y-00 for sipping@ietf.org; Thu, 01 May 2003 03:38:26 -0400 Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h417cLdh004800; Thu, 1 May 2003 03:38:22 -0400 (EDT) Message-ID: <3EB0915A.8030304@dynamicsoft.com> Date: Wed, 30 Apr 2003 23:15:38 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christer Holmberg CC: sipping Subject: Re: [Sipping] Thoughts on GRUUs, URI leasing and embedded route headers References: <3E9D03A7.1090505@dynamicsoft.com> <3E9D4E30.78848FFA@lmf.ericsson.se> <3E9F9DF9.6040504@dynamicsoft.com> <3EA3D915.DBDC44BB@lmf.ericsson.se> <3EA62CED.7070200@dynamicsoft.com> <3EA6A278.C21C0D95@lmf.ericsson.se> In-Reply-To: <3EA6A278.C21C0D95@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Christer Holmberg wrote: > Hi, > > >>>To make this work, it is assumed that requests sent in the backward >>>direction really will be directed via the proxy which issued the >>>leased URI (unless the proxy is able to "share" the information with >>>other proxies). So, won't we have the same problem with the >>>Record-Route URI that you now try to solve for the Contact URI - ie >>>we want to make sure that requests reach a specific node, and not >>>just any node within a specific user domain? >> >>No. >> >>Just because I ask a specific server for a URI that is routable in the >>domain, does not meant that requests have to go to that specific server. >> It is a requirement on the administrator of the domain to guarantee >>that the URI will route to the UA instance when used by anyone from >>anywhere. This will frequently require coordinated routing policies >>throughout the domain. Thats fine. Thats why you need to ask for the >>name - to make sure what you get is consistent with those routing policies. > > > Ok, but assume that proxy A still wants a request to be sent via it. Now, it > can do so by inserting its IP address in the Record-Route URI, but aren't the > problems them the same as if the UA would insert its IP address in the Contact? The problem GRUUs are trying to solve is that a UA wants a URI that it can be reached at *outside of the dialog* that was just set up. I do not see a pressing need for a proxy to be reached *outside of a dialog* that was just set up. > > My question basically is: should it only be possible for UAs to obtain a GRUU, > or should it also be possible for proxies? Its possible but I see no value. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu May 1 03:48: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 DAA01448 for ; Thu, 1 May 2003 03:48:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h417s8D31953 for sipping-archive@odin.ietf.org; Thu, 1 May 2003 03:54: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 h417s8831946 for ; Thu, 1 May 2003 03:54:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01417 for ; Thu, 1 May 2003 03:47:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B8pF-00077C-00 for sipping-web-archive@ietf.org; Thu, 01 May 2003 03:49:53 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19B8pE-000776-00 for sipping-web-archive@ietf.org; Thu, 01 May 2003 03:49: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 h417qu831800; Thu, 1 May 2003 03:52: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 h417h4831456 for ; Thu, 1 May 2003 03:43: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 DAA01188 for ; Thu, 1 May 2003 03:36:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B8eX-00073V-00 for sipping@ietf.org; Thu, 01 May 2003 03:38:49 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19B8eR-000731-00 for sipping@ietf.org; Thu, 01 May 2003 03:38:43 -0400 Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h417cUdh004806; Thu, 1 May 2003 03:38:31 -0400 (EDT) Message-ID: <3EB09538.8070505@dynamicsoft.com> Date: Wed, 30 Apr 2003 23:32:08 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arjun Roychowdhury CC: sipping@ietf.org Subject: Re: [Sipping] CPCP and SIP {conferencing} 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 Sorry for not responding to these questions earlier. Some answers inline: Arjun Roychowdhury wrote: > Reading > http://www.ietf.org/internet-drafts/draft-levin-sipping-conferencing-requirements-03.txt > and > http://www.ietf.org/internet-drafts/draft-koskelainen-sipping-conf-policy-req-00.txt > in conjunction, > > it seems both CPCP and SIP have similar requirements and the reqts > listed in the above two drafts to a great extent can mix with each > other. This probably is a good thing since that means SIP can meet > many of CPCP's requirements. > > But it does not clarify my confusion below: > > In addition, framework-01, for each scenario lists a SIP way and a > CPCP wa > > Even though SIP may finally land up doing a lot of what is required > by CPCP, looking at the framework-01 diagram Figure 2, the interface > between Participant and Focus is different from the interface between > Participant and Conference Policy server. > > However, when I read petri's, jonathan's and orit's drafts in > conjunction, I see these two interfaces sparring in the same ring. > > I am somewhat confused. Where does the design team consider CPCP to > stop (Participant - CPS) and SIP dialog to start (Participant to > Focus) ? Firstly, we arent defining these protocols based on the fact that they go from element A to element B. We define them based on their functional properties. In my mind, the difference between SIP and CPCP is clear. SIP is about initiating and managing sessions. CPCP is an RPC type of protocol that manipulates policies on a server. The confusion is arising because somtimes the establishment of a policy results in the creation of a session, or vice-a-versa, so that the establishment of a session is effectively creating some kind of change in policy. From the full scope of CPCP, though, its clear that it is doing many things that make no sense for SIP. For example, setting up policy about who is allowed to moderate, or setting policy about who can and can't join the conference. These things are clearly not SIP. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu May 1 03:48: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 DAA01462 for ; Thu, 1 May 2003 03:48:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h417sGd31969 for sipping-archive@odin.ietf.org; Thu, 1 May 2003 03:54: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 h417sG831966 for ; Thu, 1 May 2003 03:54: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 DAA01438 for ; Thu, 1 May 2003 03:47:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B8pM-00077R-00 for sipping-web-archive@ietf.org; Thu, 01 May 2003 03:50:00 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19B8pM-00077M-00 for sipping-web-archive@ietf.org; Thu, 01 May 2003 03:50: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 h417qw831822; Thu, 1 May 2003 03:52: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 h417gY831442 for ; Thu, 1 May 2003 03:42: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 DAA01177 for ; Thu, 1 May 2003 03:36:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B8e3-00073D-00 for sipping@ietf.org; Thu, 01 May 2003 03:38:19 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19B8dx-00072x-00 for sipping@ietf.org; Thu, 01 May 2003 03:38:13 -0400 Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h417cEdh004794; Thu, 1 May 2003 03:38:15 -0400 (EDT) Message-ID: <3EB08FD9.2050809@dynamicsoft.com> Date: Wed, 30 Apr 2003 23:09:13 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marjou Xavier CC: "'sipping@ietf.org'" Subject: Re: [Sipping] conf: comments on draft-rosenberg-sipping-conferenc ing-framework-01 References: <5B788FC2CAFBD6118BAE0030848B025C416CB4@LNN201E> In-Reply-To: <5B788FC2CAFBD6118BAE0030848B025C416CB4@LNN201E> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Marjou Xavier wrote: > Hello, > > Something is not clear to me : is CPCP really mandatory to perform > something as "simple" as calling many recipients via a focus (adhoc > conference). In an ad-hoc conference, the focus resides with one of the endpoints. Therefore, an internal interface can be used to instruct the focus to call out to additional users. So, in the case of ad-hoc, something as "simple" as mass invitation does not require CPCP. With a centralized conference server, a client can use a series of REFER requests to bring new users into the conference. This is described in the document as a SIP mecahnism for adding users. However, for a large number of invitations, this is really inefficient, and thus a real control protocol like CPCP is needed. > In my opinion, it should be as simple as sending an > e-mail to multiple recipients (Of course, having everybody in the > "To" header is not possible in SIP, but having another header for > giving the list of recipients whould be very nice). Its not as simple as that. How would you report the results of that back to the sender? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu May 1 03: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 DAA01496 for ; Thu, 1 May 2003 03:49:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h417tNt32039 for sipping-archive@odin.ietf.org; Thu, 1 May 2003 03:55: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 h417tN832036 for ; Thu, 1 May 2003 03:55: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 DAA01479 for ; Thu, 1 May 2003 03:48:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B8qD-00077n-00 for sipping-web-archive@ietf.org; Thu, 01 May 2003 03:50:53 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19B8qC-00077j-00 for sipping-web-archive@ietf.org; Thu, 01 May 2003 03:50: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 h417rG831888; Thu, 1 May 2003 03:53: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 h417ih831503 for ; Thu, 1 May 2003 03:44: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 DAA01194; Thu, 1 May 2003 03:36:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B8em-00073d-00; Thu, 01 May 2003 03:39:04 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19B8eg-00073E-00; Thu, 01 May 2003 03:38:58 -0400 Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h417cZdh004809; Thu, 1 May 2003 03:38:38 -0400 (EDT) Message-ID: <3EB097CD.7080905@dynamicsoft.com> Date: Wed, 30 Apr 2003 23:43:09 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Zon-Yin Shae CC: aroychow@hss.hns.com, shaj@cisco.com, sipping@ietf.org, sipping-admin@ietf.org Subject: Re: [Sipping] Comments on draft-rosenberg-sipping-conferencing-framework-01.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I was combing back through the SIP/SIPPING list to make sure all conferencing framework comments and issues were addressed, and I noticed that there was no response to this. The design team considered whether or not to consider conferences that were split amongst multiple focuses, where the focuses were actively communicating in order to make the whole thing appear as a single conference. This is a very hard problem, and given the scope of the work already on the table, we ruled it out of scope. You can have one focus be a member of another conference. That requires no standardization, since a focus is just a UA. That seemed to get us enough functionality for free, that the more complex case wasnt worth the cost. -Jonathan R. Zon-Yin Shae wrote: > > > > Overall the draft looks good. I wish this conference frame work can be > extended to cover the following enterprise/service conferencing scenario: > > When an application need a conference service, it only creates a conference > ID (and its associated policy). By the time the application does not know > (does not want to or can not specify) which conference service ( Focus) to > use. Moreover, it is desired for the performance and scalability that a > set of Focuses should work collaboratively to perform the distributed > conference service. For example, 20 participants in a conference, 10 in > CA and 10 in NY, it is better to have two Focuses (one in CA and one in > NY) to jointly perform the service. Protocols among Focuses are required. > > Also, most of VoIP phone does support ad-hoc conference capability and is > an useful media mixing resource. It can be useful (for the resource usage > and scalability) that the Focus can delegate some of the media mixing > function to be performed in these phones of the conference participants. > Protocols among Focus and participants are required. > > There are some components are required in the above scenario to achieve the > dynamic conference configuration. . > > 1. A conference is identified by a conference ID. A conference might be > collaboratively serviced by more than one Focuses. Since URI is used for > routing to only one UA, it would be more appropriate to carry the > conference ID (and its associated policy) in the payload with standard URI. > > 2. The default Focus for a UA can be pre-configured or discovered using > similar procedure of outbound proxy (or proxy server). > > 3. Protocols among Focuses (and conference policy server) are required. > The Subscribe and Notify SIP mechanism with extended SDP can be used among > Focuses to establish a collaboratively distributed service for a > conference. > > 4. Protocols between Focus (and conference policy server) and participants > are required. In Figure 2, the conference policy control protocol is only > one way (from participant to conference policy server), it can be two way > protocol to make use of the mixing resources in the participants (e.g., > VoIP phone). One possibility is to extend REFER mechanism using > (extended) SDP for carrying conferencing policy. > > Regards, > > zon-yin shae > IBM Watson Research Center > > > aroychow@hss.hns.com@ietf.org on 02/22/2003 10:37:44 AM > > Sent by: sipping-admin@ietf.org > > > To: > cc: sipping@ietf.org, sipping-admin@ietf.org > Subject: Re: [Sipping] Comments on > draft-rosenberg-sipping-conferencing-framework-01.txt > > > > > Inline prefixed by > > The idea of having a unique URI for each conference is a good one. However > a more scalable approach would be to have a master Focus or a group of them > that register with a standard URI. This way users use a standard URI with a > Conference ID as the payload in the Invite message. This is directed to > the master Focus that does the following > * Retrieve the Conference ID > * Check if a Focus corresponding to the conference exists > * If the Conference specific Focus does not exist create a new Focus with > a unique URI derived from the Conference ID > * Forward the call using the standard Refer mechanism to the new Focus with > the Unique URI. > > > You may also want to read > http://www.iptel.org/info/players/ietf/conferencing/draft-johnston-sipping-cc-conferencing-01.txt > . > Its provides the definition of a conference Factory URI, which could be > used to create new conferences and their Focii. > Note that when you send an INVITE to a factory URI, that entity returns the > actual Conference-URI in the Contact header. > Also, you may be using a central 'conference enabling application' > that asks you lots of questions before allowing you to create/join a new > conference. See an example of that in 4.3 of alan/orit's draft. > Note however , that when you want to use a "standard wellknown URI" that > has not been published to you by the conference server, > you are assuming that there is some agreement for that domain on conference > naming policies. > I am not sure I like your idea of a payload contaning conf-id (what use is > that ?) > Also, note that for scalability (if thats your primary concern), this > mechanism allows a way for you to start with a 'guessed URI' and from > then on communicate directly with you assigned focus without routing > everthing to what you call your 'master focus'. > > > > Instead of dealing with Conference aware UA's and Conference Unaware UA's > we could assume all participants in the Conference to be Conference Aware. > The Conference Unaware participants are routed through a Gateway (e.g. an > IVR ) that provides a primitive interface to the conference unaware > participants and a Conference aware interface to the Conference > itself. This would keep the model simpler and it can allow Conference > aware UAs a way to control the conference. > > > It is extremely important to acknowledge conference-unaware endpoints. You > cannot assume an IVR or any other application in all > conference scenarios who 'aware' on behalf of an unaware UA. Again, reading > both Jonathan and Alan/Orit's draft in conjunction may motivate > you more on the requirement of conference unaware UAs. Remeber also , that > most of the EPs deployed in SIP have zilch idea of what isFocus is > as well as will not be aware of protocols to moderate a conference for a > while. > > > > The other comment was in the area of the Conference policy control > protocol. Is this something like the SDP which is carried as a payload in > SIP or does it have specifics of it's own. Currently most of the operations > that are part of the CPCP are also possible through SIP based mechanisms. > Is there a need to define two parallel mechanisms within the same > framework. > > > I think what has been identifed here is a need for a conference policy > control protocol. It is not ascertained yet which protocol will deliver > these > requirements. Thats as far as I know. The existing SDP specs do not meet > all control requirements that come to my mind. > > Alan - would you mind reposting that link of conferencing work in > progress ? I thought I noticed some drafts attempting to address this in > more detail > > Now a question again for the authors > of draft-johnston-sipping-cc-conferencing-01.txt: > > * section 4.5 callflow - you show alice sending an invite to a conf-factory > URI but the ladder diagram shows it being received by a 'Focus'. > The definition of a focus > > > 3.1 Focus UA > > A focus, as defined in the framework, hosts a SIP conference and > maintains a SIP signaling relationship with each participant in the > conference. A focus contains a conference-aware user agent that > supports the conferencing call control conventions as defined in this > document. > > Since a 'Focus' hosts 'a specific' conference, I find it a little > disconcerting > that the call flows show messages with a factory-URI reaching a focus. I > thought > it may be clearer, if we limit a 'focus' to be the target of a specific URI > meant > for a specific conference. If a person sends an INVITE to a factory-URI or > a 'conf-app-URI' < like an IVR etc which then contacts a Factory after auth > etc> > it should not be received by a Focus, should it ? > > > > regds > Arjun > > -- > Arjun Roychowdhury @ Hughes Software Systems > 11717 Exploration Lane, Germantown MD 20876 > (O): 301 212 7860 (M): 240 997 0066{@vtext.com} > > > > "Shiva" > To: > Sent by: cc: > sipping-admin@ietf.o Subject: [Sipping] > rg Comments on > draft-rosenberg-sipping-conferencing-fram > 02/22/2003 01:57 AM ework-01.txt > Please respond to > shaj > > > > > > > Hello, > > Overall the draft looks good. Here are some of my comments on this draft > > > The advantage of doing this is that I could have multiple Conference > servers that are running that are registered their master focus. > > We can implement Load Balancing across Conference servers without the UA > realizing it as it is not connecting to a specific Focus on a specific > server. A second advantage is that if in the course of a meeting if the > focus were to go down or the server went down the participants can attempt > to rejoin the call. In such a case the Master Focus would see that the > Conference specific focus is down and recreate it allowing users to quickly > rejoin the conference. > > Of course one needs to work out the details of the communication and > keepalive between the Master Focus and the Conference focus it creates. > > The other advantage is if there are global Conference policies these can be > applied at the master and the Individual Conference focus needs to worry > about the specifics of the conference it is dealing with. > > The other comment was in the area of the Conference policy control > protocol. Is this something like the SDP which is carried as a payload in > SIP or does it have specifics of it's own. Currently most of the operations > that are part of the CPCP are also possible through SIP based mechanisms. > Is there a need to define two parallel mechanisms within the same > framework. > > > Instead of dealing with Conference aware UA's and Conference Unaware UA's > we could assume all participants in the Conference to be Conference Aware. > The Conference Unaware participants are routed through a Gateway (e.g. an > IVR ) that provides a primitive interface to the conference unaware > participants and a Conference aware interface to the Conference > itself. This would keep the model simpler and it can allow Conference > aware UAs a way to control the conference. > > Regards > Shiva > Cisco Systems > > > > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu May 1 09:39: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 JAA09549 for ; Thu, 1 May 2003 09:39:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41Djkk31766 for sipping-archive@odin.ietf.org; Thu, 1 May 2003 09:45: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 h41Djk831763 for ; Thu, 1 May 2003 09:45:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09260 for ; Thu, 1 May 2003 09:35:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BEFM-0001Dl-00 for sipping-web-archive@ietf.org; Thu, 01 May 2003 09:37:12 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BEFL-0001DX-00 for sipping-web-archive@ietf.org; Thu, 01 May 2003 09: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 h41DeH830037; Thu, 1 May 2003 09:40: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 h41Ddf829966 for ; Thu, 1 May 2003 09:39: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 JAA09144 for ; Thu, 1 May 2003 09:32:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BED2-0001BP-00 for sipping@ietf.org; Thu, 01 May 2003 09:34:48 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19BECw-00019q-00 for sipping@ietf.org; Thu, 01 May 2003 09:34:43 -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 JAA12843; Thu, 1 May 2003 09:33:12 -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 JAA16105; Thu, 1 May 2003 09:33:09 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <2BD2MF7Y>; Thu, 1 May 2003 09:33:09 -0400 Message-ID: <313680C9A886D511A06000204840E1CF030B6107@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Jonathan Rosenberg'" , sipping Subject: RE: [Sipping] Conferencing Framework open issue: scope of data wh ich is manipulated by CPCP Date: Thu, 1 May 2003 09:33:04 -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: , Generally I agree that state and policy are separate. OTOH, I think the vast majority of implementations will have them in the same implementation. I think the design should allow the possibility of the functions being split, but be optimized when they are the same entity. That means they should have nearly 100% overlap on representation of data and protocol machinery. Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, April 30, 2003 11:24 PM > To: sipping > Subject: [Sipping] Conferencing Framework open issue: scope of data > which is manipulated by CPCP > > > Eric raised an issue in his comments on conf-fw, to which I replied: > > >> Also, w.r.t. section 5.8.2, I would really hope that CPCP is SIP: > >> I'm really hesitant to have to implement all the same protocol > >> actions with two different protocols "just because." Let's pick > >> one and run with it. > > > > > > See above discussion on why these are just not the same. In the case > > of conference participants, you will basically learn them as the > > result of a full-state update generated by a subscription to the > > conference state. CPCP, being a data transaction protocol, would > > also allow you to directly query for the list. Just because there is > > this sliver of overlap does not mean that they are the same > protocol. > > > > My response is wrong. In the current design, you cannot use CPCP to > access any of the focus state, such as the current > participant list. It > is strictly viewed as a protocol for manipulated the > conference POLICY. > > This leads to the question - is this sensible? On one hand, one would > expect that a protocol for accessing state of the conference > should give > you access to ALL of the state, not just the subset which is > defined as > policy. On the other hand, as Eric points out, conference policy and > conference state are very different. Indeed, they may likely > reside in > entirely different servers in the network. One can imagine using an > external DB to hold the policy, whereas focus state is in-memory > soft-state. Thus, using the same protocol to access them may be > complicated to support. > > What do people think about this issue? > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Scientist Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu May 1 15:43: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 PAA04513 for ; Thu, 1 May 2003 15:43:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41Jntk26038 for sipping-archive@odin.ietf.org; Thu, 1 May 2003 15:49: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 h41Jnt826035 for ; Thu, 1 May 2003 15:49:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04490 for ; Thu, 1 May 2003 15:43:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BJzh-0005pD-00 for sipping-web-archive@ietf.org; Thu, 01 May 2003 15:45:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BJzg-0005p9-00 for sipping-web-archive@ietf.org; Thu, 01 May 2003 15:45: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 h41JgX823227; Thu, 1 May 2003 15:42: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 h41JWK818798 for ; Thu, 1 May 2003 15:32:20 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02698; Thu, 1 May 2003 15:25:37 -0400 (EDT) Message-Id: <200305011925.PAA02698@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, 01 May 2003 15:25:37 -0400 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-conferencing-framework-00.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : A Framework for Conferencing with the Session Initiation Protocol Author(s) : J. Rosenberg Filename : draft-ietf-sipping-conferencing-framework-00.txt Pages : 39 Date : 2003-5-1 The Session Initiation Protocol (SIP) supports the initiation, modification, and termination of media sessions between user agents. These sessions are managed by SIP dialogs, which represent a SIP relationship between a pair of user agents. Because dialogs are between pairs of user agents, SIP's usage for two-party communications (such as a phone call), is obvious. Communications sessions with multiple participants, generally known as conferencing, are more complicated. This document defines a framework for how such conferencing can occur. This framework describes the overall architecture, terminology, and protocol components needed for multi- party conferencing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-conferencing-framework-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sipping-conferencing-framework-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sipping-conferencing-framework-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-5-1153655.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-conferencing-framework-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-conferencing-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-1153655.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 May 6 06:17: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 GAA13460 for ; Tue, 6 May 2003 06:17:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46APcD07917 for sipping-archive@odin.ietf.org; Tue, 6 May 2003 06:25: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 h46APc807914 for ; Tue, 6 May 2003 06:25: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 GAA13426 for ; Tue, 6 May 2003 06:13:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CzUR-0004jZ-00 for sipping-web-archive@ietf.org; Tue, 06 May 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 19CzUQ-0004jV-00 for sipping-web-archive@ietf.org; Tue, 06 May 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 h46AKm807684; Tue, 6 May 2003 06:20: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 h46AA9807324 for ; Tue, 6 May 2003 06:10: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 GAA13157 for ; Tue, 6 May 2003 06:00:58 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CzHs-0004fu-00 for sipping@ietf.org; Tue, 06 May 2003 06:03:04 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19CzHm-0004fl-00 for sipping@ietf.org; Tue, 06 May 2003 06:02:58 -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 h46A3WD01705 for ; Tue, 6 May 2003 13:03:32 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 6 May 2003 13:03:32 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 6 May 2003 13:03:32 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 6 May 2003 13:03:31 +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: Tue, 6 May 2003 13:03:30 +0300 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD5E1@esebe013.ntc.nokia.com> Thread-Topic: Commentary on draft-niemi-sipping-event-throttle-reqs Thread-Index: AcMKzd9v5bMgoYwdTuet8J1UOvwikQI2Mdqg To: , Cc: , X-OriginalArrivalTime: 06 May 2003 10:03:31.0741 (UTC) FILETIME=[BFAF2CD0:01C313B6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h46AD8807418 Subject: [Sipping] RE: Commentary on draft-niemi-sipping-event-throttle-reqs Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 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 Dean, Thanks a lot for the comments. I'll have some answers inline, and will edit the draft to also reflect your suggestions. > -----Original Message----- > From: ext Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 25 April, 2003 04:56 > To: sipping@ietf.org; Niemi Aki (NMP/Helsinki) > Cc: jdrosen@dynamcisoft.com; David Oran > Subject: Commentary on draft-niemi-sipping-event-throttle-reqs > > > > At the last meeting, we agreed (well, actually Rohan > volunteered us) that we > would look at the event throttling requirements draft, and > that at least a > couple of us would post discussions before we considered > taking it on as a > WG effort. So here's my try at it. > > The given draft is: > > http://www.ietf.org/internet-drafts/draft-niemi-sipping-event > -throttle-reqs- > 01.txt > > > Overall, I think that developing an event throttling > mechanism is a good > idea, and that this draft is a reasonable start on the requirements. Good. > General comment: The draft seems to confuse the maximum > notification rate > "desired" or "allowed" by the subscriber with the rate > "required" by the > notifier. I'll come back to this at several points in the > discussion. There > also seems to be a bit of confusion on the difference > between average rates > and minimum interval -- they're not exactly inverses of each > other. English > is such a fun language -- too bad it doesn't work well for > specifications. Good point. That certainly wasn't the intention. Simply without the require/allowed/desired semantics, a rate is the inverse of time and that was supposed to be the extent of it, and even that proved confusing... ;) I'll try to clarify the language in the next version. > Section 3: Event Throttle Model > > This section raises two throttling models, which it > identifies as "strict" > and "leaky bucket" quarantines. > > The usage of the "strict" model should be clarified as > establishing the > minimum time period allowed between two notifications. I'll add text to that. > The > draft says that > the choice of which notification is sent is implementation dependent, > although it seems to assume a "newest" notification, where "newer" > notifications replace "older" ones if the minimum > notification interval time > has not elapsed. I suspect that this replacement model has a > lot of overlap > with filtering. Should we explicitly include a requirement that the > replacement policy be describable in the subscription process? The draft actually tries not to make that assumption (but fails obviously ;). It lists as examples the replacement you also mention, as well as a merging of notifications. But I don't quite understand how this would overlap with filtering, as it is internal to the notifier, and depends on the type and contents of a notification, e.g., is it stateless or stateful? I think adding a requirement that the subscriber needs to be able to dictate the policy regarding the treatment of notifications in the queue would actually create that overlap. In this case I would rather view filtering orthogonal to throttling. > This section also refers to what it calls a "leaky bucket > style algorithm", > which is probably a misnomer. Traditionally (at least in my > pointy head) a > "leaky bucket" refers to a FIFO queue with a variable > arrival rate and a > fixed departure rate. There might be input "bursts" at a > rate higher than > the output rate, resulting in a lengthening of the queue, > but the output > rate is held constant as long as the queue length is > non-zero. However, the > policy described in the draft is one of rate-averaging, > which is something > like a leaky-bucket that kicks in only if the sliding-window > average rate > exceeds the prescribed maximum. This could use some cleanup. Agreed. My treatment of queuing theory was obviously a bit rusty. ;) > Additionally, one might envision a rate-averaging queue that > enforces its > operation by discarding or combining notifications instead > of delaying them. This is what the leaky-bucket was supposed to describe. Will change the draft to reflect this. > So basically, there are two queue models proposed: > > 1) minimum fixed interval or period between notifications, where the > interval can be described as a time value like 5 seconds. > This can also be > described as maximum fixed rate, or notifications per unit > of time, like 0.2 > notifications per second or 1 notification per 5 seconds > (oddly enough, this > is the reciprocal of the minimum interval) > > 2) minimum average interval or period between notifications, > which is better > described as the maximum average rate of notifications and > best described in > notifications per unit of time, averaged over some time window. Agreed. > And two reasonable queue-servicing policies: > > 1) Delay notifications in a FIFO manner to conform to policy. > > 2) Discard out-of-profile notifications or combine them with other > notifications to result in a notification stream that > conforms to policy. Agreed. > Note that policy 1 can result in increasing queue depth if > the arrival rate > persists in exceeding the departure rate. Consequently, > practical systems > using 1 are likely to revert to 2 at some point. Efficiency > may also be > improvable by using a quenching mechanism to reduce the arrival rate. Right, and also a variable rate policy would be likely to employ both 1 and 2 to achieve the rate averaging queue. > Section 4, Example Use Case: > > This doesn't really describe a use case, but just presents > us with the > mathematical notation of the reciprocal relationship between > frequency and > period. Useful background, but a real use case (with actors, > etc.) would be > nice here too. > > Perhaps something like: > > Case 1: Alice subscribes to the status of Bob. Bob's status > is served by > server S. Alice tells S (subscribes with a notification > throttling policy) > that she wishes to receive notifications no more frequently > than once every > five seconds. Bob publishes a status of Red to the server S, > which notifies > Alice. > > Sub case a: After a delay of three seconds, Bob publishes a > status of Green > to S. S, which implements a policy of discarding out-of-profile > notifications, stores the status of Green but does not > notify Alice. After > three more seconds, Bob publishes a status of Blue to S. > Since six seconds > have elapsed since the last notification to Alice, S > notifies Alice that > Bob's status is now Blue. Note that in this sub-case, Alice is never > notified that Bob's status was Green, but the notifications > that she does > receive are timely. > > Sub case b: After a delay of three seconds, Bob publishes a > status of Green > to S. S, which implements of policy of delaying > out-of-profile notifications > so that they become compliant, stores the status of Bob. > After two more > seconds, S notifies Alice that Bob's status is now Green. > One second later, > Bob publishes a status of Blue. Again, S stores the new > state for Bob, but > does not immediately notify Alice. Four seconds later, S > notifies Alice that > Bob's status is now Blue. Note that in this sub-case, Alice > is notified of > all statuses published by Bob, but often has a different > understanding of > Bob's status than does Bob, because the notifications from S > to Alice are > delayed. I will add such a use-case to the draft. > REQ3: > > Says that "The notifier must be able to indicate that it > does not support > the use of a throttle mechanism in the subscription. This > would be better > worded as ". . . for a specific subscription", otherwise > we'll have people > thinking "in the subscription" means "in the SUBSCRIBE", > when we all know it > would have to be "in the response to the SUBSCRIBE". Fixed. > REQ6: > > Ends in "For example, local policy could dictate an even > lower rate of > notification than what the subscriber requires." Refer back > to my General > Comment earlier in this missive. It seems to me that this > would be better > worded as " . . . what the subscriber allows". I think we're having a > tendency to get confused about what the rate limit is asking for. The > subscriber is saying "I want to receive notifications no > more frequently > than once per X seconds", not "You MUST notify me EVERY X seconds." Good point. The intention was definitely not "MUST notify every X seconds". Will fix the wording. > REQ7: > > Says that security mechanisms "SHOULD be applied to > subscriptions . . . ". > This is trying to define operational guidelines at protocol > requirements > time. Rather, we should word this sort of thing to require a > capability to > be met by the mechanism to be developed. Perhaps "A throttle > mechanism MUST > allow for the application of authentication and integrity protection > mechanisms to subscriptions invoking that mechanism." Sounds all right to me. > > Section 6: Security Requirements > > Issue 1 points out that it might be possible for a > subscriber to set a > maximum notification interval longer than the subscription duration, > consequently resulting in only getting one notification per > subscription. > Should we add a new requirement on the order of "A notifier > receiving a > subscription request including throttling policy MUST be > able to response > with something having the semantic of 'That's a really > freaking stupid > idea'.? Or should we add a requirement more like "A > throttling mechanism > MUST include discussion of the situation resulting from a minimum > inter-notification period which exceeds the subscription duration and > include mechanisms for avoiding this situation and/or guidance to > implementers on the dangers of getting exactly what they asked for"? > > Issue 2 raises the possibility that a subscriber might set a > very short > minimum inter-notification period (or very high maximum > notification rate), > thereby causing the notifier to exhaust itself sending at > that frequency. > This is, well, bogus. As I pointed out above, the throttling > policy does not > tell the notifier the rate at which notifications should be > sent. Rather, it > tells the server the rate that notifications must not exceed. This is > something like a traffic sign. If the sign on the street > says "Speed Limit: > 30 kph", this does not force all cards to speed up to 30 kph. In most > situations (barring a few large motorways that have a > SEPARATE policy for > minimum speeds) driving at 28 kph, or even 20 kph, would be > just fine. > > Conclusion: Note that there is considerable potential for > confusion between > frequency (or rate) and period (or interval) in this > conversation. We should > be careful to say explicitly what we mean. Is it feasible to > use just one > term in all discussions? Yes. I would propose that the model only talks about queues at the notifier, and minimum intervals set by a subscriber. > I have the feeling that SIP is not > likely to be > well-suited to exceptionally frequent notifications. Is it > reasonable to > state a minimum period in seconds? This lets us use a > signed-16 range to > express inter-notification periods ranging from 1 second to > a little over 9 > hours. Do we need higher resolution than that? There's > probably a resolution > requirement that needs to be stated in this draft. This is probably reasonable, although a little bit into the implementation space. At some point I entertained the thought (I think Hisham suggested it), but didn't find a proper wording for such a requirement. But I'll try to come up with something proper, unless you have some text to suggest? Cheers, Aki > -- > 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 May 6 13:03: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 NAA29523 for ; Tue, 6 May 2003 13:03:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46HCSc09497 for sipping-archive@odin.ietf.org; Tue, 6 May 2003 13:12: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 h46HCS809494 for ; Tue, 6 May 2003 13:12: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 NAA29498 for ; Tue, 6 May 2003 13:03:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D5sf-0000cK-00 for sipping-web-archive@ietf.org; Tue, 06 May 2003 13:05:29 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19D5se-0000cH-00 for sipping-web-archive@ietf.org; Tue, 06 May 2003 13:05: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 h46HAS809319; Tue, 6 May 2003 13:10: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 h46H4k808215 for ; Tue, 6 May 2003 13:04: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 MAA29239 for ; Tue, 6 May 2003 12:55:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D5lD-0000Yl-00 for sipping@ietf.org; Tue, 06 May 2003 12:57:47 -0400 Received: from beamer.mchh.siemens.de ([194.138.158.163]) by ietf-mx with esmtp (Exim 4.12) id 19D5lB-0000Yi-00 for sipping@ietf.org; Tue, 06 May 2003 12:57:46 -0400 Received: from moody.mchh.siemens.de ([139.21.205.85]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id SAA12058 for ; Tue, 6 May 2003 18:58:35 +0200 (MET DST) Received: from mchh274e.demchh201e.icn.siemens.de (mchh274e.mchh.siemens.de [139.21.200.84]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id SAA07053 for ; Tue, 6 May 2003 18:58:34 +0200 (MET DST) Received: by mchh274e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Tue, 6 May 2003 18:58:12 +0200 Message-ID: <5B788FC2CAFBD6118BAE0030848B025C416CFC@LNN201E> From: Marjou Xavier To: "'sipping@ietf.org'" Subject: RE: [Sipping] conf: comments on draft-rosenberg-sipping-conferenc ing-framework-01 Date: Tue, 6 May 2003 18:57:43 +0200 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: , >> Something is not clear to me : is CPCP really mandatory to perform >> something as "simple" as calling many recipients via a focus (adhoc >> conference). > In an ad-hoc conference, the focus resides with one of the endpoints. > Therefore, an internal interface can be used to instruct the focus to > call out to additional users. So, in the case of ad-hoc, something as > "simple" as mass invitation does not require CPCP. >> With a centralized conference server, a client can use a series of REFER >> requests to bring new users into the conference. This is described in >> the document as a SIP mecahnism for adding users. However, for a large >> number of invitations, this is really inefficient, and thus a real >> control protocol like CPCP is needed. Is a CPCP body inside a SIP INVITE acceptable ? (I would like to avoid an additional round-trip delay for a CPCP request before the SIP request) Then we would also have an intermediate solution for those who want that "CPCP is SIP" : CPCP would be "inside" SIP (like SDP) >> In my opinion, it should be as simple as sending an >> e-mail to multiple recipients (Of course, having everybody in the >> "To" header is not possible in SIP, but having another header for >> giving the list of recipients whould be very nice). > Its not as simple as that. How would you report the results of that back > to the sender? For me, the conference package event with SUBSCRIBE/NOTIFY would perform the job _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 7 07:20: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 HAA23933 for ; Wed, 7 May 2003 07:20:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47BTGU05307 for sipping-archive@odin.ietf.org; Wed, 7 May 2003 07:29: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 h47BTG805304 for ; Wed, 7 May 2003 07:29: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 HAA23930 for ; Wed, 7 May 2003 07:19:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DMzi-0007Kn-00 for sipping-web-archive@ietf.org; Wed, 07 May 2003 07:21:54 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DMzh-0007Kj-00 for sipping-web-archive@ietf.org; Wed, 07 May 2003 07:21: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 h47BR3805225; Wed, 7 May 2003 07: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 h47BNb805049 for ; Wed, 7 May 2003 07:23:37 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23597; Wed, 7 May 2003 07:14:10 -0400 (EDT) Message-Id: <200305071114.HAA23597@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, 07 May 2003 07:14:10 -0400 Subject: [Sipping] I-D ACTION:draft-umschaden-smime-midcom-sip-proxy-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-end Security for Firewall/NAT Traversal within the Session Initiation Protocol (SIP) Author(s) : K. Umschaden et al. Filename : draft-umschaden-smime-midcom-sip-proxy-00.txt Pages : 37 Date : 2003-5-6 This document describes an extension for the Session Initiation Protocol (SIP), which enables end-to-end security of the Session Description Protocol (SDP) together with firewall/Network Address Translation (NAT) traversal. This solution relies on Secure Multipurpose Internet Mail Extension (S/MIME) and the middlebox communications (MIDCOM) protocol. The user authorises a proxy server to encrypt the session description on behalf of the user. The proxy determines the capabilities of the receiving party and encrypts the SDP for a SIP proxy server in the receiving domain. Using MIDCOM, each proxy can dynamically control its firewall to open pinholes or request NAT bindings for the media flows. As long as each end-user may contact its trustworthy SIP proxy via a secure connection and authorise this proxy to encrypt the signalling data, the session information is secured end-to-end. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-umschaden-smime-midcom-sip-proxy-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-umschaden-smime-midcom-sip-proxy-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-umschaden-smime-midcom-sip-proxy-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-5-6153238.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-umschaden-smime-midcom-sip-proxy-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-umschaden-smime-midcom-sip-proxy-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-6153238.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed May 7 18:15: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 SAA20496 for ; Wed, 7 May 2003 18:15:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47MOEo29747 for sipping-archive@odin.ietf.org; Wed, 7 May 2003 18:24: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 h47MOE829744 for ; Wed, 7 May 2003 18:24: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 SAA20445 for ; Wed, 7 May 2003 18:14:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DXDK-0005GC-00 for sipping-web-archive@ietf.org; Wed, 07 May 2003 18:16:38 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DXDJ-0005G9-00 for sipping-web-archive@ietf.org; Wed, 07 May 2003 18:16: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 h47MGb829445; Wed, 7 May 2003 18:16: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 h47MEv829374 for ; Wed, 7 May 2003 18:14: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 SAA19553 for ; Wed, 7 May 2003 18:05:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DX4L-0005Dw-00 for sipping@ietf.org; Wed, 07 May 2003 18:07:21 -0400 Received: from [138.26.5.240] (helo=uabexmb1.ad.uab.edu) by ietf-mx with esmtp (Exim 4.12) id 19DX4K-0005Dt-00 for sipping@ietf.org; Wed, 07 May 2003 18:07:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 7 May 2003 17:08:14 -0500 Message-ID: <4297DD64C36B80448637DC966CB492AE60459E@UABEXMB1.ad.uab.edu> Thread-Topic: Request for Technical Comments on ITU H.350 sipIdentity Thread-Index: AcMUx7MvWI6D/hpqQ92vEv3mIYyO5wAHOrjA From: "Jill B Gemmill" To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h47MEv829375 Subject: [Sipping] Request for Technical Comments on ITU H.350 sipIdentity Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit To Members of IETF SIPPING: The Video Development Initiative (ViDe www.vide.net) and Internet2 Video Middleware Working Group (VidMid http://middleware.internet2.edu/video/) would like to call your attention to a set of ITU-T documents developed by ITU-T Study Group 16 and known as "Directory Services Architecture for Multimedia Conferencing" (H.350). This ITU Recommendation describes a directory services architecture for multimedia conferencing using LDAP. Directory services can provide automated configuration of endpoints, association of persons with endpoints, searchable white pages, clickable, dialing, and user authentication based on authoritative data sources. This document describes a standardized LDAP schema to represent endpoints on the network and associate those endpoints with users. It discusses design and implementation considerations for the inter-relation of video and voice-specific directories, enterprise directories, call servers and endpoints. The recommendation includes a base document (H.350) and protocol-specific components include H.350.1 (H.323); H.350.2 (h.235); H.350.3 (H.320); H.350.4 (SIP); and H.350.5 (generic). Current drafts of these documents are available at http://middleware.internet2.edu/video/docs/H.350/ ; these recommendations are on track for ratification at the next meeting of Study Group 16 to be held later this month. We would very much appreciate your individual or group technical comments, particularly regarding H.350.4 (SIP) - we have been interested in developing a standardized directory interface for multimedia that contains protocol-specific information but which does not replace or revise the protocol. We are aware of at least one error in H.350.4 - sipURI is listed as case insensitive, which is incorrect. Please send your comments to my attention, and I will see that they are forwarded to Internet2 VidMid and also to the editor of the H.350 documents. Sincerely, Jill Gemmill jgemmill@uab.edu _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 9 14:14: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 OAA25674 for ; Fri, 9 May 2003 14:14:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h49IOeJ31972 for sipping-archive@odin.ietf.org; Fri, 9 May 2003 14:24: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 h49IOe831969 for ; Fri, 9 May 2003 14:24: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 OAA25662 for ; Fri, 9 May 2003 14:14:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ECPg-0006PE-00 for sipping-web-archive@ietf.org; Fri, 09 May 2003 14:16:08 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ECPf-0006PA-00 for sipping-web-archive@ietf.org; Fri, 09 May 2003 14:16: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 h49IH0831325; Fri, 9 May 2003 14:17: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 h49IDe831043 for ; Fri, 9 May 2003 14:13: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 OAA25046 for ; Fri, 9 May 2003 14:03:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ECF2-0006Fc-00 for sipping@ietf.org; Fri, 09 May 2003 14:05:08 -0400 Received: from bay7-dav16.bay7.hotmail.com ([64.4.10.120] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19ECF1-0006FF-00 for sipping@ietf.org; Fri, 09 May 2003 14:05:08 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 9 May 2003 11:05:34 -0700 Received: from 64.102.254.33 by bay7-dav16.bay7.hotmail.com with DAV; Fri, 09 May 2003 18:05:34 +0000 X-Originating-IP: [64.102.254.33] X-Originating-Email: [sip_developer@hotmail.com] From: "SIP Developer" To: "Attila Sipos" , , Cc: References: Date: Fri, 9 May 2003 14:05:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 09 May 2003 18:05:34.0640 (UTC) FILETIME=[96509300:01C31655] Subject: [Sipping] Re: [Sip-implementors] dtmf digits using INFO ... SIP authors ... Can you answer please ? Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 h49IH0831325 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h49IOe831969 Content-Transfer-Encoding: 8bit Hi All, I hate to say that but SIP community doesn't agree or think that there are lots of use and requirement for carrying DTMF Out-of-Band. Every month, I can see that someone asks the same question again and again that how do we send DTMF via INFO and Out-Of-Band . 3pcc needs it, lots of service creation environment needs it and doesn't it looks promising to have a way in SIP to do OOB DTMF just like h245-alphanumeric in H.323. If we think of applications, then there are lots of them that I can count which doesn't care about the timing info carried by RFC2833. And if we really care about timing, then carrying RFC2833 via notify (Again OOB) is promising. I really do not understand if this is a political issue to not promote SIP INFO for carrying DTMF or if someone can justify it to me that there is no use to carry DTMF OOB. SIP authors, can you answer why SIP INFO for carrying simple DTMF is not a standard solution ? Thanks, Rohan Kumar ----- Original Message ----- From: "Attila Sipos" To: ; Sent: Friday, May 09, 2003 9:50 AM Subject: RE: [Sip-implementors] dtmf digits using INFO > > Hello Zsolt, > > I still don't think there is a fully-agreed > standard. However, as much as I hate to say it, > CISCO have their own proposed standard which some > people (like us) interoperate with: > > http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122 > t/122t11/ftinfo.htm > > Regards, > > Attila > > Attila Sipos > Software Engineer > > VegaStream : A World of difference for your Integrated Communications > > (jo napot kivįnok) > > > > > -----Original Message----- > > From: Rizsanyi Zsolt [mailto:rizsanyi@myrealbox.com] > > Sent: 09 May 2003 13:41 > > To: sip-implementors@cs.columbia.edu > > Subject: [Sip-implementors] dtmf digits using INFO > > > > > > Hi! > > > > Could somebody refer me to a current standard or draft, on > > how to send dtmf > > digits using the INFO method? > > > > Thanks > > Zsolt Rizsanyi > > > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 9 14:36: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 OAA26577 for ; Fri, 9 May 2003 14:36:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h49IkrM01911 for sipping-archive@odin.ietf.org; Fri, 9 May 2003 14:46: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 h49Ikq801908 for ; Fri, 9 May 2003 14:46:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26556 for ; Fri, 9 May 2003 14:36:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EClA-0006Yl-00 for sipping-web-archive@ietf.org; Fri, 09 May 2003 14:38:20 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ECl9-0006Yi-00 for sipping-web-archive@ietf.org; Fri, 09 May 2003 14:38: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 h49IaL832666; Fri, 9 May 2003 14:36: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 h49IZw832639 for ; Fri, 9 May 2003 14:35:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26006 for ; Fri, 9 May 2003 14:25:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ECab-0006T9-00 for sipping@ietf.org; Fri, 09 May 2003 14:27:25 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19ECaa-0006T5-00 for sipping@ietf.org; Fri, 09 May 2003 14:27:25 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h49IRKct006536; Fri, 9 May 2003 11:27:21 -0700 (PDT) Received: from [128.107.170.122] ([128.107.170.122]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ADZ89140; Fri, 9 May 2003 11:27:19 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 09 May 2003 11:27:17 -0700 From: Cullen Jennings To: SIP Developer , Attila Sipos , , CC: Sipping Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h49IZw832640 Subject: [Sipping] Re: [Sip-implementors] dtmf digits using INFO ... SIP authors ... Can you answer please ? Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 h49IaL832666 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h49Ikq801908 Content-Transfer-Encoding: 8bit Have a look at the App-Interaction stuff and KPML - it's not fully baked yet but I think it will meet the needs of these sorts of applications. On 5/9/03 11:05 AM, "SIP Developer" wrote: > Hi All, > > I hate to say that but SIP community doesn't agree > or think that there are lots of use and requirement for carrying > DTMF Out-of-Band. > > Every month, I can see that someone asks the same question again and again > that how do we send DTMF via INFO and Out-Of-Band . > > 3pcc needs it, lots of service creation environment needs it and > doesn't it looks promising to have a way in SIP to do OOB > DTMF just like h245-alphanumeric in H.323. > > If we think of applications, then there are lots of them that I can > count which doesn't care about the timing info carried by RFC2833. > And if we really care about timing, then carrying RFC2833 via > notify (Again OOB) is promising. > > I really do not understand if this is a political issue to not promote > SIP INFO for carrying DTMF or if someone can justify it to me > that there is no use to carry DTMF OOB. > > SIP authors, can you answer why SIP INFO for carrying simple > DTMF is not a standard solution ? > > Thanks, > Rohan Kumar > > > ----- Original Message ----- > From: "Attila Sipos" > To: ; > Sent: Friday, May 09, 2003 9:50 AM > Subject: RE: [Sip-implementors] dtmf digits using INFO > > >> >> Hello Zsolt, >> >> I still don't think there is a fully-agreed >> standard. However, as much as I hate to say it, >> CISCO have their own proposed standard which some >> people (like us) interoperate with: >> >> > http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122 >> t/122t11/ftinfo.htm >> >> Regards, >> >> Attila >> >> Attila Sipos >> Software Engineer >> >> VegaStream : A World of difference for your Integrated Communications >> >> (jo napot kivįnok) >> >> >> >>> -----Original Message----- >>> From: Rizsanyi Zsolt [mailto:rizsanyi@myrealbox.com] >>> Sent: 09 May 2003 13:41 >>> To: sip-implementors@cs.columbia.edu >>> Subject: [Sip-implementors] dtmf digits using INFO >>> >>> >>> Hi! >>> >>> Could somebody refer me to a current standard or draft, on >>> how to send dtmf >>> digits using the INFO method? >>> >>> Thanks >>> Zsolt Rizsanyi >>> >>> _______________________________________________ >>> Sip-implementors mailing list >>> Sip-implementors@cs.columbia.edu >>> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >>> >> >> _______________________________________________ >> Sip-implementors mailing list >> Sip-implementors@cs.columbia.edu >> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >> > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 9 14:59: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 OAA27313 for ; Fri, 9 May 2003 14:59:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h49J9w003847 for sipping-archive@odin.ietf.org; Fri, 9 May 2003 15:09: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 h49J9w803844 for ; Fri, 9 May 2003 15:09: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 OAA27286 for ; Fri, 9 May 2003 14:59:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ED7V-0006gO-00 for sipping-web-archive@ietf.org; Fri, 09 May 2003 15:01:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ED7U-0006gL-00 for sipping-web-archive@ietf.org; Fri, 09 May 2003 15:01: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 h49IxH802555; Fri, 9 May 2003 14:59: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 h49Iwm802519 for ; Fri, 9 May 2003 14:58: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 OAA26936 for ; Fri, 9 May 2003 14:48:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ECwh-0006d4-00 for sipping@ietf.org; Fri, 09 May 2003 14:50:15 -0400 Received: from bay7-dav55.bay7.hotmail.com ([64.4.10.63] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19ECwg-0006d1-00 for sipping@ietf.org; Fri, 09 May 2003 14:50:14 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 9 May 2003 11:50:41 -0700 Received: from 64.102.254.33 by bay7-dav55.bay7.hotmail.com with DAV; Fri, 09 May 2003 18:50:41 +0000 X-Originating-IP: [64.102.254.33] X-Originating-Email: [sip_developer@hotmail.com] From: "SIP Developer" To: "Cullen Jennings" , "Attila Sipos" , , Cc: "Sipping" References: Subject: Re: [Sipping] Re: [Sip-implementors] dtmf digits using INFO ... SIP authors ... Can you answer please ? Date: Fri, 9 May 2003 14:50:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 09 May 2003 18:50:41.0358 (UTC) FILETIME=[E3A4F6E0:01C3165B] Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 h49IxH802555 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h49J9w803844 Content-Transfer-Encoding: 8bit Cullen, There is NO POINT in baking it FOREVER for something that will cover everything. Imagine the burden on developers since they have to develop SIP INFO, RFC2833 via NOTIFY, KPML and may be few more future proposals in the absence of SIP standards for something very basic (OOB DTMF) . Thanks, Rohan Kumar ----- Original Message ----- From: "Cullen Jennings" To: "SIP Developer" ; "Attila Sipos" ; ; Cc: "Sipping" Sent: Friday, May 09, 2003 2:27 PM Subject: [Sipping] Re: [Sip-implementors] dtmf digits using INFO ... SIP authors ... Can you answer please ? > > Have a look at the App-Interaction stuff and KPML - it's not fully baked yet > but I think it will meet the needs of these sorts of applications. > > > On 5/9/03 11:05 AM, "SIP Developer" wrote: > > > Hi All, > > > > I hate to say that but SIP community doesn't agree > > or think that there are lots of use and requirement for carrying > > DTMF Out-of-Band. > > > > Every month, I can see that someone asks the same question again and again > > that how do we send DTMF via INFO and Out-Of-Band . > > > > 3pcc needs it, lots of service creation environment needs it and > > doesn't it looks promising to have a way in SIP to do OOB > > DTMF just like h245-alphanumeric in H.323. > > > > If we think of applications, then there are lots of them that I can > > count which doesn't care about the timing info carried by RFC2833. > > And if we really care about timing, then carrying RFC2833 via > > notify (Again OOB) is promising. > > > > I really do not understand if this is a political issue to not promote > > SIP INFO for carrying DTMF or if someone can justify it to me > > that there is no use to carry DTMF OOB. > > > > SIP authors, can you answer why SIP INFO for carrying simple > > DTMF is not a standard solution ? > > > > Thanks, > > Rohan Kumar > > > > > > ----- Original Message ----- > > From: "Attila Sipos" > > To: ; > > Sent: Friday, May 09, 2003 9:50 AM > > Subject: RE: [Sip-implementors] dtmf digits using INFO > > > > > >> > >> Hello Zsolt, > >> > >> I still don't think there is a fully-agreed > >> standard. However, as much as I hate to say it, > >> CISCO have their own proposed standard which some > >> people (like us) interoperate with: > >> > >> > > http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122 > >> t/122t11/ftinfo.htm > >> > >> Regards, > >> > >> Attila > >> > >> Attila Sipos > >> Software Engineer > >> > >> VegaStream : A World of difference for your Integrated Communications > >> > >> (jo napot kivįnok) > >> > >> > >> > >>> -----Original Message----- > >>> From: Rizsanyi Zsolt [mailto:rizsanyi@myrealbox.com] > >>> Sent: 09 May 2003 13:41 > >>> To: sip-implementors@cs.columbia.edu > >>> Subject: [Sip-implementors] dtmf digits using INFO > >>> > >>> > >>> Hi! > >>> > >>> Could somebody refer me to a current standard or draft, on > >>> how to send dtmf > >>> digits using the INFO method? > >>> > >>> Thanks > >>> Zsolt Rizsanyi > >>> > >>> _______________________________________________ > >>> Sip-implementors mailing list > >>> Sip-implementors@cs.columbia.edu > >>> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > >>> > >> > >> _______________________________________________ > >> Sip-implementors mailing list > >> Sip-implementors@cs.columbia.edu > >> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > >> > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 12 19:34: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 TAA08717 for ; Mon, 12 May 2003 19:34:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4CN0N510739 for sipping-archive@odin.ietf.org; Mon, 12 May 2003 19:00: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 h4CN0NB10736 for ; Mon, 12 May 2003 19:00: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 TAA08707 for ; Mon, 12 May 2003 19:34:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FMpx-0005aO-00 for sipping-web-archive@ietf.org; Mon, 12 May 2003 19:36:05 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19FMpw-0005aK-00 for sipping-web-archive@ietf.org; Mon, 12 May 2003 19:36: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 h4CMxIB10611; Mon, 12 May 2003 18:59: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 h4CMw1B10575 for ; Mon, 12 May 2003 18:58: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 TAA08612 for ; Mon, 12 May 2003 19:31:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FMnf-0005Z7-00 for sipping@ietf.org; Mon, 12 May 2003 19:33:43 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19FMnf-0005Yv-00 for sipping@ietf.org; Mon, 12 May 2003 19:33:43 -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.6/8.12.6) with ESMTP id h4CNY0jH008237; Mon, 12 May 2003 16:34:02 -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 AHA32863; Mon, 12 May 2003 16:27:49 -0700 (PDT) Date: Mon, 12 May 2003 16:34:13 -0700 Subject: Re: [Sipping] Re: [Sip-implementors] dtmf digits using INFO ... SIP authors ... Can you answer please ? Content-Type: text/plain; delsp=yes; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Attila Sipos" , , , To: "SIP Developer" From: Rohan Mahy In-Reply-To: Message-Id: <3D6A4DF0-84D2-11D7-8E16-0003938AF740@cisco.com> X-Mailer: Apple Mail (2.552) X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4CMw2B10576 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 h4CMxIB10611 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4CN0NB10736 Content-Transfer-Encoding: 8bit Hi Rohan, The main reason to not carry DTMF in SIP INFOs is that there is a very good chance that you will get double-digits or otherwise corrupted digits because the signaling is not time-synchronized with the audio media. This issue is discussed in an expired draft which I wrote a long time ago, which I abandoned in favor of the work generated by the app-interaction design team. At this point my draft is useful only in that it explains how double digits tend to occur. my expired draft: http://www.softarmor.com/sipping/drafts/morgue/draft-mahy-sipping- signaled-digits-01.html the app-interaction design team drafts: http://www.softarmor.com/sipping/drafts/draft-burger-sipping-kpml-01.txt http://www.softarmor.com/sipping/drafts/draft-culpepper-sipping-app- interact-reqs-03.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 thanks, -rohan (Mahy) On Friday, May 9, 2003, at 11:05 AM, SIP Developer wrote: > Hi All, > > I hate to say that but SIP community doesn't agree > or think that there are lots of use and requirement for carrying > DTMF Out-of-Band. > > Every month, I can see that someone asks the same question again and > again > that how do we send DTMF via INFO and Out-Of-Band . > > 3pcc needs it, lots of service creation environment needs it and > doesn't it looks promising to have a way in SIP to do OOB > DTMF just like h245-alphanumeric in H.323. > > If we think of applications, then there are lots of them that I can > count which doesn't care about the timing info carried by RFC2833. > And if we really care about timing, then carrying RFC2833 via > notify (Again OOB) is promising. > > I really do not understand if this is a political issue to not promote > SIP INFO for carrying DTMF or if someone can justify it to me > that there is no use to carry DTMF OOB. > > SIP authors, can you answer why SIP INFO for carrying simple > DTMF is not a standard solution ? > > Thanks, > Rohan Kumar > > > ----- Original Message ----- > From: "Attila Sipos" > To: ; > Sent: Friday, May 09, 2003 9:50 AM > Subject: RE: [Sip-implementors] dtmf digits using INFO > > >> >> Hello Zsolt, >> >> I still don't think there is a fully-agreed >> standard. However, as much as I hate to say it, >> CISCO have their own proposed standard which some >> people (like us) interoperate with: >> >> > http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/ > 122newft/122 >> t/122t11/ftinfo.htm >> >> Regards, >> >> Attila >> >> Attila Sipos >> Software Engineer >> >> VegaStream : A World of difference for your Integrated Communications >> >> (jo napot kivįnok) >> >> >> >>> -----Original Message----- >>> From: Rizsanyi Zsolt [mailto:rizsanyi@myrealbox.com] >>> Sent: 09 May 2003 13:41 >>> To: sip-implementors@cs.columbia.edu >>> Subject: [Sip-implementors] dtmf digits using INFO >>> >>> >>> Hi! >>> >>> Could somebody refer me to a current standard or draft, on >>> how to send dtmf >>> digits using the INFO method? >>> >>> Thanks >>> Zsolt Rizsanyi >>> >>> _______________________________________________ >>> Sip-implementors mailing list >>> Sip-implementors@cs.columbia.edu >>> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >>> >> >> _______________________________________________ >> Sip-implementors mailing list >> Sip-implementors@cs.columbia.edu >> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >> > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP 13-May-2003 19:30:19 -0500,3058;000000000001-00000b00 Received: via dmail-2000(11) for +imap/ietf/SIPPING; Tue, 13 May 2003 19:30:19 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4E0U96n006594 for ; Tue, 13 May 2003 19:30:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DNjHB10586; Tue, 13 May 2003 19:45: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 h4DNheB10506 for ; Tue, 13 May 2003 19:43: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 UAA04843 for ; Tue, 13 May 2003 20:16:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Fjys-00010j-00 for sipping@ietf.org; Tue, 13 May 2003 20:18: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 19Fjyr-00010g-00 for sipping@ietf.org; Tue, 13 May 2003 20:18:49 -0400 Received: from txdwillis ([63.206.46.200]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4E0JL6n006521 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 13 May 2003 19:19:25 -0500 From: "Dean Willis" To: Date: Tue, 13 May 2003 19:18:55 -0500 Message-ID: <000a01c319ae$6d67a9e0$06f30a0a@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sipping] Test -- please ignore Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.52 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) Just probing the list server in a periodic maintenance function. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP 13-May-2003 23:14:38 -0500,3406;000000000001-00000b01 Received: via dmail-2000(11) for +imap/ietf/SIPPING; Tue, 13 May 2003 23:14:38 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4E4EV6n007969 for ; Tue, 13 May 2003 23:14:31 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E3RHB25551; Tue, 13 May 2003 23:27: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 h4E3QGB25531 for ; Tue, 13 May 2003 23:26: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 XAA08744 for ; Tue, 13 May 2003 23:59:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FnSE-000277-00 for sipping@ietf.org; Wed, 14 May 2003 00:01:22 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19FnSD-000274-00 for sipping@ietf.org; Wed, 14 May 2003 00:01:21 -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.6/8.12.6) with ESMTP id h4E41mDU022723; Tue, 13 May 2003 21:01:48 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHB69236; Tue, 13 May 2003 20:55:25 -0700 (PDT) Date: Tue, 13 May 2003 21:02:01 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: jon.peterson@neustar.biz, bcampbell@dynamicsoft.com, rohan@cisco.com, "'Dean Willis'" , gonzalo.Camarillo@ericsson.com To: "'sipping@ietf.org'" From: Rohan Mahy Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Status: No, hits=-2.1 required=5.0 tests=USER_AGENT_APPLEMAIL version=2.52 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) Hello Everyone, I'd like to begin Working Group Last Call on: http:/www.ietf.org/internet-drafts/draft-ietf-sipping-e164-02.txt this WGLC will end on June 13, 2003. thanks, -rohan _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP 14-May-2003 00:11:03 -0500,1904;000000000001-00000b02 Received: via dmail-2000(11) for +imap/ietf/SIPPING; Wed, 14 May 2003 00:11:03 -0500 (CDT) Return-Path: Received: from harjus.eng.song.fi (mail@harjus.eng.song.fi [195.10.149.20]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4E5Am6n008311 for ; Wed, 14 May 2003 00:10:51 -0500 Received: from jh by harjus.eng.song.fi with local (Exim 3.35 #1 (Debian)) id 19FoWw-0000Dm-00; Wed, 14 May 2003 08:10:18 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16065.53178.749541.152400@harjus.eng.song.fi> Date: Wed, 14 May 2003 08:10:18 +0300 To: Rohan Mahy Cc: "'sipping@ietf.org'" , jon.peterson@neustar.biz, bcampbell@dynamicsoft.com, "'Dean Willis'" , gonzalo.Camarillo@ericsson.com Subject: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt In-Reply-To: References: X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen X-Spam-Status: No, hits=-28.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_VM autolearn=ham version=2.52 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) Rohan Mahy writes: > I'd like to begin Working Group Last Call on: > > http:/www.ietf.org/internet-drafts/draft-ietf-sipping-e164-02.txt > > this WGLC will end on June 13, 2003. i must be seeing a VERY bad dream. the draft uses the wrong service field for sip: "sip+E2U" instead of "E2U+sip" as per draft-ietf-enum-rfc2916bis-06.txt. please discard the sipping draft from the archives AS SOON AS POSSIBLE so that not a single new implementer will find and read it. -- juha 14-May-2003 00:22:12 -0500,3615;000000000001-00000b03 Received: via dmail-2000(11) for +imap/ietf/SIPPING; Wed, 14 May 2003 00:22:12 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4E5M56n008379 for ; Wed, 14 May 2003 00:22:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E4ZEB29843; Wed, 14 May 2003 00:35: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 h4E4YMB29785 for ; Wed, 14 May 2003 00:34: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 BAA10188 for ; Wed, 14 May 2003 01:07:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FoW6-0002Sv-00 for sipping@ietf.org; Wed, 14 May 2003 01:09:26 -0400 Received: from harjus.eng.song.fi ([195.10.149.20] ident=mail) by ietf-mx with esmtp (Exim 4.12) id 19FoW5-0002Ss-00 for sipping@ietf.org; Wed, 14 May 2003 01:09:25 -0400 Received: from jh by harjus.eng.song.fi with local (Exim 3.35 #1 (Debian)) id 19FoWw-0000Dm-00; Wed, 14 May 2003 08:10:18 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16065.53178.749541.152400@harjus.eng.song.fi> Date: Wed, 14 May 2003 08:10:18 +0300 To: Rohan Mahy Cc: "'sipping@ietf.org'" , jon.peterson@neustar.biz, bcampbell@dynamicsoft.com, "'Dean Willis'" , gonzalo.Camarillo@ericsson.com Subject: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt 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: , X-Spam-Status: No, hits=-28.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_VM version=2.52 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) Rohan Mahy writes: > I'd like to begin Working Group Last Call on: > > http:/www.ietf.org/internet-drafts/draft-ietf-sipping-e164-02.txt > > this WGLC will end on June 13, 2003. i must be seeing a VERY bad dream. the draft uses the wrong service field for sip: "sip+E2U" instead of "E2U+sip" as per draft-ietf-enum-rfc2916bis-06.txt. please discard the sipping draft from the archives AS SOON AS POSSIBLE so that not a single new implementer will find and read 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 14-May-2003 02:26:55 -0500,3446;000000000001-00000b04 Received: via dmail-2000(11) for +imap/ietf/SIPPING; Wed, 14 May 2003 02:26:55 -0500 (CDT) Return-Path: Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4E7Ql6n009163 for ; Wed, 14 May 2003 02:26:47 -0500 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 h4E7POC11664; Wed, 14 May 2003 07:25:24 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 May 2003 03:27:15 -0400 Message-ID: <0449D80A0E9B614A83FA9031B07E8D3B257A6B@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Juha Heinanen'" , Rohan Mahy Cc: "'sipping@ietf.org'" , bcampbell@dynamicsoft.com, "'Dean Willis'" , gonzalo.Camarillo@ericsson.com Subject: RE: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt Date: Wed, 14 May 2003 03:27:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-2.9 required=5.0 tests=MSG_ID_ADDED_BY_MTA_3,QUOTED_EMAIL_TEXT autolearn=ham version=2.52 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) No, you're not suffering any bad dream - just an attack of rhetorical exaggeration and lax reading. The authors of sipping-e164 are aware of the rfc2916bis Internet-Draft, and have suitably referenced it in Section 7, which is entitled "Updates for rfc2916bis". It mentions the new enumservice format that concerns you so greatly below, and recommends that SIP applications accept either format for purposes of backwards compatibility - quite generous considering that rfc2916bis is just a I-D, not a standard. In the light of all this, it is hard for me to see a justification for banishing sipping-e164 from the I-D archives. But granted - the last time that sipping-e164 was updated (October 2002), rfc2916bis was a lot less mature than it is now. Given that a last call for rfc2916bis is also now in progress, it might make sense to update sipping-e164 to reference (normatively) the new rfc2916bis notation throughout, assuming that they will both go before the IESG at about the same time. A fair last call comment; we'll remedy this before sipping-e164 goes to the IESG. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Juha Heinanen [mailto:jh@lohi.eng.song.fi] > Sent: Tuesday, May 13, 2003 10:10 PM > To: Rohan Mahy > Cc: 'sipping@ietf.org'; jon.peterson@neustar.biz; > bcampbell@dynamicsoft.com; 'Dean Willis'; > gonzalo.Camarillo@ericsson.com > Subject: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt > > > Rohan Mahy writes: > > > I'd like to begin Working Group Last Call on: > > > > http:/www.ietf.org/internet-drafts/draft-ietf-sipping-e164-02.txt > > > > this WGLC will end on June 13, 2003. > > i must be seeing a VERY bad dream. the draft uses the wrong service > field for sip: "sip+E2U" instead of "E2U+sip" as per > draft-ietf-enum-rfc2916bis-06.txt. > > please discard the sipping draft from the archives AS SOON AS POSSIBLE > so that not a single new implementer will find and read it. > > -- juha > 14-May-2003 02:36:36 -0500,5113;000000000001-00000b05 Received: via dmail-2000(11) for +imap/ietf/SIPPING; Wed, 14 May 2003 02:36:36 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4E7aT6n009254 for ; Wed, 14 May 2003 02:36:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E6pGB17999; Wed, 14 May 2003 02:51: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 h4E6oSB17963 for ; Wed, 14 May 2003 02:50:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07865 for ; Wed, 14 May 2003 03:23:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Fqdl-0003Hg-00 for sipping@ietf.org; Wed, 14 May 2003 03:25:29 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx with esmtp (Exim 4.12) id 19Fqdk-0003HD-00 for sipping@ietf.org; Wed, 14 May 2003 03:25:28 -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 h4E7POC11664; Wed, 14 May 2003 07:25:24 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 May 2003 03:27:15 -0400 Message-ID: <0449D80A0E9B614A83FA9031B07E8D3B257A6B@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Juha Heinanen'" , Rohan Mahy Cc: "'sipping@ietf.org'" , bcampbell@dynamicsoft.com, "'Dean Willis'" , gonzalo.Camarillo@ericsson.com Subject: RE: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt Date: Wed, 14 May 2003 03:27:13 -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: , X-Spam-Status: No, hits=-2.9 required=5.0 tests=MSG_ID_ADDED_BY_MTA_3,QUOTED_EMAIL_TEXT version=2.52 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) No, you're not suffering any bad dream - just an attack of rhetorical exaggeration and lax reading. The authors of sipping-e164 are aware of the rfc2916bis Internet-Draft, and have suitably referenced it in Section 7, which is entitled "Updates for rfc2916bis". It mentions the new enumservice format that concerns you so greatly below, and recommends that SIP applications accept either format for purposes of backwards compatibility - quite generous considering that rfc2916bis is just a I-D, not a standard. In the light of all this, it is hard for me to see a justification for banishing sipping-e164 from the I-D archives. But granted - the last time that sipping-e164 was updated (October 2002), rfc2916bis was a lot less mature than it is now. Given that a last call for rfc2916bis is also now in progress, it might make sense to update sipping-e164 to reference (normatively) the new rfc2916bis notation throughout, assuming that they will both go before the IESG at about the same time. A fair last call comment; we'll remedy this before sipping-e164 goes to the IESG. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Juha Heinanen [mailto:jh@lohi.eng.song.fi] > Sent: Tuesday, May 13, 2003 10:10 PM > To: Rohan Mahy > Cc: 'sipping@ietf.org'; jon.peterson@neustar.biz; > bcampbell@dynamicsoft.com; 'Dean Willis'; > gonzalo.Camarillo@ericsson.com > Subject: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt > > > Rohan Mahy writes: > > > I'd like to begin Working Group Last Call on: > > > > http:/www.ietf.org/internet-drafts/draft-ietf-sipping-e164-02.txt > > > > this WGLC will end on June 13, 2003. > > i must be seeing a VERY bad dream. the draft uses the wrong service > field for sip: "sip+E2U" instead of "E2U+sip" as per > draft-ietf-enum-rfc2916bis-06.txt. > > please discard the sipping draft from the archives AS SOON AS POSSIBLE > so that not a single new implementer will find and read 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 14-May-2003 03:56:44 -0500,3487;000000000001-00000b06 Received: via dmail-2000(11) for +imap/ietf/SIPPING; Wed, 14 May 2003 03:56:44 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4E8uc6n009776 for ; Wed, 14 May 2003 03:56:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E89GB24764; Wed, 14 May 2003 04:09: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 h4E88mB24739 for ; Wed, 14 May 2003 04:08: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 EAA09523 for ; Wed, 14 May 2003 04:41:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FrrY-0003kv-00 for sipping@ietf.org; Wed, 14 May 2003 04:43:48 -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 19FrrX-0003ks-00 for sipping@ietf.org; Wed, 14 May 2003 04:43:47 -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 h4E8iX0Q004433; Wed, 14 May 2003 10:44:40 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 14 May 2003 10:43:20 +0200 Message-ID: From: "Gonzalo Camarillo Gonzalez (LMF)" To: "'sipping@ietf.org'" Cc: "Jon Peterson (E-mail)" , "Rohan Mahy (E-mail)" , "Dean Willis (E-mail)" Date: Wed, 14 May 2003 09:12:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] Last Call for early media use cases Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.52 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) Folks, in the last IETF meeting, we requested early media use cases that show the need of a "media coming" flag. So far, we have not received anything. We intend to release a new version of the early media draft in a week or so. So, that is the time you have to send me your use cases. Thanks, Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP 14-May-2003 13:35:23 -0500,6494;000000000001-00000b07 Received: via dmail-2000(11) for +imap/ietf/SIPPING; Wed, 14 May 2003 13:35:23 -0500 (CDT) Return-Path: Received: from znsgs01r.nortelnetworks.com (h21s128a211n47.user.nortelnetworks.com [47.211.128.21]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4EIZD6n014591 for ; Wed, 14 May 2003 13:35:14 -0500 Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4EIW7w29988; Wed, 14 May 2003 19:32:08 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 May 2003 19:32:09 +0100 Message-ID: From: "Mark Watson" To: "'Gonzalo Camarillo Gonzalez (LMF)'" , "'sipping@ietf.org'" Cc: "Jon Peterson (E-mail)" , "Rohan Mahy (E-mail)" , "Dean Willis (E-mail)" Subject: RE: [Sipping] Last Call for early media use cases Date: Wed, 14 May 2003 19:32:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31A47.1F6320FA" X-Spam-Status: No, hits=-1.0 required=5.0 tests=ASCII_FORM_ENTRY,HTML_20_30,HTML_MESSAGE,QUOTED_EMAIL_TEXT version=2.52 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) 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. ------_=3D_NextPart_001_01C31A47.1F6320FA Gonzalo, I think you have received plenty of emails on this topic. What is clear = is that there is no consensus either way that such an indication is or is = not required. Anyway, for my part I do not have any further information I can provide = you that I think has any prospect of convincing you. I still believe the = absence of some kind of additional indication will in practice lead to a less-than-ideal user experience, but I quite accept there is no = consensus right now. Regards, Mark > -----Original Message----- > From: Gonzalo Camarillo Gonzalez (LMF) > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: 14 May 2003 00:13 > To: 'sipping@ietf.org' > Cc: Jon Peterson (E-mail); Rohan Mahy (E-mail); Dean Willis (E-mail) > Subject: [Sipping] Last Call for early media use cases >=20 >=20 > Folks, >=20 > in the last IETF meeting, we requested early media use cases=20 > that show the need of a "media coming" flag. So far, we have=20 > not received anything. >=20 > We intend to release a new version of the early media draft=20 > in a week or so. So, that is the time you have to send me=20 > your use cases. >=20 > Thanks, >=20 > 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 >=20 ------_=3D_NextPart_001_01C31A47.1F6320FA [Enclosed text/html ] ------_=3D_NextPart_001_01C31A47.1F6320FA-- 14-May-2003 13:44:38 -0500,8197;000000000001-00000b08 Received: via dmail-2000(11) for +imap/ietf/SIPPING; Wed, 14 May 2003 = 13:44:38 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4EIiW6n014669 for ; Wed, 14 May 2003 13:44:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EHvRB04949; Wed, 14 May 2003 13:57: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 h4EHumB04860 for ; Wed, 14 May 2003 13: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 OAA29802 for ; Wed, 14 May 2003 14:29:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19G12N-0000Ka-00 for sipping@ietf.org; Wed, 14 May 2003 14:31:35 -0400 Received: from h21s128a211n47.user.nortelnetworks.com ([47.211.128.21] = helo=3Dznsgs01r.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 19G12M-0000KU-00 for sipping@ietf.org; Wed, 14 May 2003 14:31:34 -0400 Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com = [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP = id h4EIW7w29988; Wed, 14 May 2003 19:32:08 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service = (5.5.2653.19) id ; Wed, 14 May 2003 19:32:09 +0100 Message-ID: = From: "Mark Watson" To: "'Gonzalo Camarillo Gonzalez (LMF)'" , "'sipping@ietf.org'" Cc: "Jon Peterson (E-mail)" , "Rohan Mahy (E-mail)" , "Dean Willis (E-mail)" Subject: RE: [Sipping] Last Call for early media use cases Date: Wed, 14 May 2003 19:32:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary=3D"----_=3D_NextPart_001_01C31A47.1F6320FA" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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-Spam-Status: No, hits=3D-1.0 required=3D5.0 tests=3DASCII_FORM_ENTRY,HTML_20_30,HTML_MESSAGE,QUOTED_EMAIL_TEXT version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) 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. ------_=3D_NextPart_001_01C31A47.1F6320FA Gonzalo, I think you have received plenty of emails on this topic. What is clear = is that there is no consensus either way that such an indication is or is = not required. Anyway, for my part I do not have any further information I can provide = you that I think has any prospect of convincing you. I still believe the = absence of some kind of additional indication will in practice lead to a less-than-ideal user experience, but I quite accept there is no = consensus right now. Regards, Mark > -----Original Message----- > From: Gonzalo Camarillo Gonzalez (LMF) > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: 14 May 2003 00:13 > To: 'sipping@ietf.org' > Cc: Jon Peterson (E-mail); Rohan Mahy (E-mail); Dean Willis (E-mail) > Subject: [Sipping] Last Call for early media use cases >=20 >=20 > Folks, >=20 > in the last IETF meeting, we requested early media use cases=20 > that show the need of a "media coming" flag. So far, we have=20 > not received anything. >=20 > We intend to release a new version of the early media draft=20 > in a week or so. So, that is the time you have to send me=20 > your use cases. >=20 > Thanks, >=20 > 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 >=20 ------_=3D_NextPart_001_01C31A47.1F6320FA [Enclosed text/html ] ------_=3D_NextPart_001_01C31A47.1F6320FA-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP 14-May-2003 16:51:39 -0500,5088;000000000001-00000b09 Received: via dmail-2000(11) for +imap/ietf/SIPPING; Wed, 14 May 2003 = 16:51:39 -0500 (CDT) Return-Path: Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk = [193.118.201.102]) by bdsl.greycouncil.com (8.12.8/8.12.8) with SMTP id h4ELpT6n015948 for ; Wed, 14 May 2003 16:51:30 -0500 Received: by rsys001a.roke.co.uk with Internet Mail Service = (5.5.2653.19) id ; Wed, 14 May 2003 22:51:03 +0100 Received: from orion.roke.co.uk ([193.118.192.66]) by = rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service = Version 5.5.2653.13) id HSB1ZJT4; Wed, 14 May 2003 22:50:51 +0100 From: "Conroy, Lawrence (SMTP)" To: "Peterson, Jon" , "'Juha Heinanen'" , Rohan Mahy Cc: "'sipping@ietf.org'" , bcampbell@dynamicsoft.com, "'Dean Willis'" , = gonzalo.Camarillo@ericsson.com Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To:=20 <0449D80A0E9B614A83FA9031B07E8D3B257A6B@stntexch2.va.neustar.com> References:=20 <0449D80A0E9B614A83FA9031B07E8D3B257A6B@stntexch2.va.neustar.com> Date: Wed, 14 May 2003 22:51:03 +0100 Subject: RE: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt Content-Type: multipart/mixed; boundary=3D"------------InterScan_NT_MIME_Boundary" X-Spam-Status: No, hits=3D-26.1 required=3D5.0 tests=3DEMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=3Dham version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary At 3:27 am -0400 14/5/03, Peterson, Jon wrote: >No, you're not suffering any bad dream - just an attack of rhetorical >exaggeration and lax reading. The authors of sipping-e164 are aware of = the >rfc2916bis Internet-Draft, and have suitably referenced it in Section = 7, >which is entitled "Updates for rfc2916bis". It mentions the new = enumservice >format that concerns you so greatly below, and recommends that SIP >applications accept either format for purposes of backwards = compatibility - >quite generous considering that rfc2916bis is just a I-D, not a = standard. In >the light of all this, it is hard for me to see a justification for >banishing sipping-e164 from the I-D archives. > >But granted - the last time that sipping-e164 was updated (October = 2002), >rfc2916bis was a lot less mature than it is now. Given that a last = call for >rfc2916bis is also now in progress, it might make sense to update >sipping-e164 to reference (normatively) the new rfc2916bis notation >throughout, assuming that they will both go before the IESG at about = the >same time. A fair last call comment; we'll remedy this before = sipping-e164 >goes to the IESG. > >Jon Peterson >NeuStar, Inc. > >Juha Wrote: > > i must be seeing a VERY bad dream. the draft uses the wrong = service >> field for sip: "sip+E2U" instead of "E2U+sip" as per >> draft-ietf-enum-rfc2916bis-06.txt. >> >> please discard the sipping draft from the archives AS SOON AS = POSSIBLE > > so that not a single new implementer will find and read it. > > To which I reply: Hi folks, RFC2916 is going to be obsoleted by rfc2916bis-06 (if approved)? = Thus, this backward compatibility in sipping-e164 would be with be with an = obsoleted document (not even a current I-D). I have a lot of sympathy with Juha on this one - we have already had=20 fun with one bunch (strictly) implementing 2916 whilst the other bunch (strictly) = implement 2916bis - I'd prefer not continuing this. Was this a VERY bad dream?=20 - I fear not. =3D> Do you -REALLY- -REALLY- need backward compatibility? My vote's to just go with the 2916bis syntax throughout, and remove = reference to the soon to be obsoleted syntax in sipping-164? BTW, will we see an up-issued version as -02 IS out of date and has = some things that will/may/might change? all the best, Lawrence --=20 ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is = not : intended to create any contractual or legal : relationship. --------------InterScan_NT_MIME_Boundary Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, = Bracknell,=20 Berkshire. RG12 8FZ The information contained in this e-mail and any attachments is = confidential to Roke Manor Research Ltd and must not be passed to any = third party without permission. This communication is for information = only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- 14-May-2003 17:05:05 -0500,5976;000000000001-00000b0a Received: via dmail-2000(11) for +imap/ietf/SIPPING; Wed, 14 May 2003 = 17:05:05 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4EM4t6n016069 for ; Wed, 14 May 2003 17:04:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4ELGFB20772; Wed, 14 May 2003 17:16: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 h4ELFEB20747 for ; Wed, 14 May 2003 17:15: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 RAA07136 for ; Wed, 14 May 2003 17:48:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19G48L-0001oU-00 for sipping@ietf.org; Wed, 14 May 2003 17:49:57 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19G48K-0001oQ-00 for sipping@ietf.org; Wed, 14 May 2003 17:49:56 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service = (5.5.2653.19) id ; Wed, 14 May 2003 22:51:03 +0100 Received: from orion.roke.co.uk ([193.118.192.66]) by = rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service = Version 5.5.2653.13) id HSB1ZJT4; Wed, 14 May 2003 22:50:51 +0100 From: "Conroy, Lawrence (SMTP)" To: "Peterson, Jon" , "'Juha Heinanen'" , Rohan Mahy Cc: "'sipping@ietf.org'" , bcampbell@dynamicsoft.com, "'Dean Willis'" , = gonzalo.Camarillo@ericsson.com Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To:=20 <0449D80A0E9B614A83FA9031B07E8D3B257A6B@stntexch2.va.neustar.com> References:=20 <0449D80A0E9B614A83FA9031B07E8D3B257A6B@stntexch2.va.neustar.com> Date: Wed, 14 May 2003 22:51:03 +0100 Subject: RE: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt Content-Type: text/plain; charset=3D"us-ascii" ; format=3D"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: , X-Spam-Status: No, hits=3D-32.4 required=3D5.0 tests=3DEMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_LONG_DENSE version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) At 3:27 am -0400 14/5/03, Peterson, Jon wrote: >No, you're not suffering any bad dream - just an attack of rhetorical >exaggeration and lax reading. The authors of sipping-e164 are aware of = the >rfc2916bis Internet-Draft, and have suitably referenced it in Section = 7, >which is entitled "Updates for rfc2916bis". It mentions the new = enumservice >format that concerns you so greatly below, and recommends that SIP >applications accept either format for purposes of backwards = compatibility - >quite generous considering that rfc2916bis is just a I-D, not a = standard. In >the light of all this, it is hard for me to see a justification for >banishing sipping-e164 from the I-D archives. > >But granted - the last time that sipping-e164 was updated (October = 2002), >rfc2916bis was a lot less mature than it is now. Given that a last = call for >rfc2916bis is also now in progress, it might make sense to update >sipping-e164 to reference (normatively) the new rfc2916bis notation >throughout, assuming that they will both go before the IESG at about = the >same time. A fair last call comment; we'll remedy this before = sipping-e164 >goes to the IESG. > >Jon Peterson >NeuStar, Inc. > >Juha Wrote: > > i must be seeing a VERY bad dream. the draft uses the wrong = service >> field for sip: "sip+E2U" instead of "E2U+sip" as per >> draft-ietf-enum-rfc2916bis-06.txt. >> >> please discard the sipping draft from the archives AS SOON AS = POSSIBLE > > so that not a single new implementer will find and read it. > > To which I reply: Hi folks, RFC2916 is going to be obsoleted by rfc2916bis-06 (if approved)? = Thus, this backward compatibility in sipping-e164 would be with be with an = obsoleted document (not even a current I-D). I have a lot of sympathy with Juha on this one - we have already had=20 fun with one bunch (strictly) implementing 2916 whilst the other bunch (strictly) = implement 2916bis - I'd prefer not continuing this. Was this a VERY bad dream?=20 - I fear not. =3D> Do you -REALLY- -REALLY- need backward compatibility? My vote's to just go with the 2916bis syntax throughout, and remove = reference to the soon to be obsoleted syntax in sipping-164? BTW, will we see an up-issued version as -02 IS out of date and has = some things that will/may/might change? all the best, Lawrence --=20 ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is = not : intended to create any contractual or legal : relationship. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP 14-May-2003 20:57:18 -0500,8136;000000000001-00000b0b Received: via dmail-2000(11) for +imap/ietf/SIPPING; Wed, 14 May 2003 = 20:57:18 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4F1vA6n017390 for ; Wed, 14 May 2003 20:57:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4F1COB03385; Wed, 14 May 2003 21:12: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 h4F1BmB03366 for ; Wed, 14 May 2003 21: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 VAA12270 for ; Wed, 14 May 2003 21:44:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19G7pC-0002wY-00 for sipping@ietf.org; Wed, 14 May 2003 21:46:26 -0400 Received: from mail3.hosting.bora.net ([211.40.221.16]) by ietf-mx with smtp (Exim 4.12) id 19G7pA-0002wS-00 for sipping@ietf.org; Wed, 14 May 2003 21:46:24 -0400 Received: (qmail 6846 invoked from network); 15 May 2003 01:46:57 -0000 Received: from unknown (HELO thomas2000svr) (211.239.8.224) by mail3.hosting.bora.net with SMTP; 15 May 2003 01:46:57 -0000 From: "???? ???" To: Date: Thu, 15 May 2003 10:46:58 +0900 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=3D"----=3D_NextPart_000_0043_01C31ACF.4F688C30" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: [Sipping] Push-To-Talk with 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: , X-Spam-Status: No, hits=3D-3.4 required=3D5.0 tests=3DBASE64_ENC_TEXT,MSGID_GOOD_EXCHANGE,RCVD_IN_OSIRUSOFT_COM autolearn=3Dham version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) This is a multi-part message in MIME format. ------=3D_NextPart_000_0043_01C31ACF.4F688C30 Hello, Nokia, Siemens and Ericsson have announced tu”…ŠŃ”•ä…É”‘•Ł•±½Į„¹œ„ĮÕĶ µŃ¼µŃ…±¬…ĮĮ±„…Ń„½ø™½ČMŌŅęWGv÷&·2v—F‚u%2ęBf÷"gWGW&R4ręWGv÷&·2āF†W’vē]Č\ŁHŅT›ÜˆŚYŪ˜[[™Č]HŪŻ[‰Żš[™[žH[ܙHetailed information. Does someone of you know some detu…„°…‰½ÕŠŃ””AQPĶ„¹…±„¹œŻ„Ń M%@ü4)¼Ń”•ä…É”…‰½ÕŃŅ&&—G&F–öā–bGvņV÷ĘRvēBFņFĘ²FņF†R6ÖRw&÷WH]HŲ[YH[YOČ\™H\™HŪŪYH˜YČ܈\ŲŻ\ÜŚ[ŪœČ]bout this topics? regards, thomas lee. t€€€€€€€€€Q”½µ…Ģ1••Q•”¹„…° ½¹ĶÕ±Ń…¹ŃA½±åĮ„ą%¹ĶŃ„ŃÕѕŅöbFV6†ęöĘöw“b7VęvFņfVēGW&RF÷vW"ĀcRÓ"6×7VęrÖFöęwKŲ[™Ū˜[KZŻKŁ[Ż[ LĶKN KŪܙXU[ˆ Ī ‹L‹MML‹LĶLLH ^t. 511) Fax : +82-2-552-3510Mobile : +82-16-271-5507E-mau„°€čŃ”½µ…Ģ¹±••Į½±åĮ„ą¹½µUÉ°€čŻŻÜ¹Į½±åĮ„ą¹½“€€4(€€€€ŠŠ¢Š Š Š wpŻÜ ------=3D_NextPart_000_0043_01C31ACF.4F688C30 [Enclosed text/html ] ------=3D_NextPart_000_0043_01C31ACF.4F688C30-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP 14-May-2003 21:32:56 -0500,11696;000000000001-00000b0c Received: via dmail-2000(11) for +imap/ietf/SIPPING; Wed, 14 May 2003 = 21:32:56 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4F2Wn6n017582 for ; Wed, 14 May 2003 21:32:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4F1m7B05732; Wed, 14 May 2003 21:48: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 h4F1l6B05690 for ; Wed, 14 May 2003 21: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 WAA12828 for ; Wed, 14 May 2003 22:19:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19G8NL-00036W-00 for sipping@ietf.org; Wed, 14 May 2003 22:21:43 -0400 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] = helo=3Dzsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 19G8NK-00036H-00 for sipping@ietf.org; Wed, 14 May 2003 22:21:42 -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 h4F2MA629373; Wed, 14 May 2003 19:22:10 -0700 (PDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service = (5.5.2653.19) id ; Wed, 14 May 2003 19:21:40 -0700 Message-ID: = <2F1FC1DEA077D5119FAD00508BCFD6D2086BCFBC@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'jdrosen@dynamicsoft.com'" , "'sipping@ietf.org'" Date: Wed, 14 May 2003 19:21:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary=3D"----_=3D_NextPart_001_01C31A88.B82957DC" Subject: [Sipping] Questions and comments on = draft-rosenberg-sipping-ice-00 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Status: No, hits=3D1.9 required=3D5.0 tests=3DHTML_10_20,HTML_MESSAGE,SUBJ_HAS_UNIQ_ID version=3D2.52 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) 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. ------_=3D_NextPart_001_01C31A88.B82957DC Hi Jonathan, Better late than never I guess. I have a few questions/comments on=20 draft-rosenberg-sipping-ice-00.html. - Section 2 (the overview) says that the UAC should attempt to derive IP addresses with STUN, TURN, RSIP and VPN servers and place all of=20 these addresses in the offer SDP. Sections 3, 5.1 and 5.4 confirm = this=20 procedure. In the case of STUN, it means a dedicated STUN server as opposed to the peer-to-peer UA STUN server used at call setup. = However, section 12.3 may lead the reader to believe that a dedicated STUN=20 server) is "simply not used" and that instead the peer-to-peer UA = STUN servers are sufficient. The wording should be re-done to clarify that what is not used is the NAT classification process (the derivation of = the IP address using a dedicated STUN server is indeed used). At = least, I think this is what 12.3 is saying. If there was an example 9.3,=20 similar to 9.2 but where B calls A, I assume that B would include = both=20 LTA2 and PDTA2 in the offer, and that PDTA2 would be marked as derived. Is this correct? Since the 2 examples of section 9 do NOT = have a STUN-derived address for the calling party, it is even more = confusing. - Section 7.2 says that the derived-attribute refer to transport = addresses "learned from the entity to whom the SDP is being sent (referred to as the peer)". This is the same issues as the previous one. I don't = think this is correct. It is the transport address learned from the STUN query: in the initial offer, that address is NOT learned from the "peer" but from the dedicated STUN server. Correct? In the answer or = in a second round of offer (in an UPDATE), then is is indeed learned = from=20 the peer. Is this correct? - In examples 9.1 and 9.2, A only has one address, a local IPv4 = address.=20 The qvalue is set to 1.0 in the offer in both examples. According to=20 the rules 5.3, shouldn't the qvalue in the offer been set to 0.8=20 instead? - In example 9.1, can't we skip the whole peer-to-peer STUN query since both A and B know that no NATs are involved from their previous STUN=20 query to the dedicated STUN servers? I mean, when B receives A's offer, it sees only one address (non-derived), and it knows that itself has only a non-derived IP address. - In a few places (including the abstract), it is claimed that ICE is = less brittle than STUN. This may be a little misleading since ICE itselfs uses the STUN protocol. It should be clarified (as per my earlier = point),=20 that what is meant by "STUN" in this context is that traditional STUN = only is more brittle than ICE. Typos: - Section 2, third paragraph, first sentence. Replace "realsm" with=20 "realms". - In section 9.2, in the paragraph right before the description of the = UPDATE content, replace "has no offered" with "has not offered". ---- Fran=3DE7ois AUDET, Nortel Networks Tel: +1 408 495 3756 ------_=3D_NextPart_001_01C31A88.B82957DC [Enclosed text/html ] ------_=3D_NextPart_001_01C31A88.B82957DC-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP 15-May-2003 07:06:33 -0500,5234;000000000001-00000b0d Received: via dmail-2000(11) for +imap/ietf/SIPPING; Thu, 15 May 2003 = 07:06:33 -0500 (CDT) Return-Path: Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4FC6K6n021353 for ; Thu, 15 May 2003 07:06:21 -0500 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 h4FC4pC31658; Thu, 15 May 2003 12:04:54 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service = (5.5.2653.19) id ; Thu, 15 May 2003 08:06:44 -0400 Message-ID: = <0449D80A0E9B614A83FA9031B07E8D3B257A78@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Conroy, Lawrence (SMTP)'" , "'Juha Heinanen'" , Rohan Mahy Cc: "'sipping@ietf.org'" , bcampbell@dynamicsoft.com, "'Dean Willis'" , = gonzalo.Camarillo@ericsson.com Subject: RE: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt Date: Thu, 15 May 2003 08:06:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset=3D"iso-8859-1" X-Spam-Status: No, hits=3D-2.9 required=3D5.0 tests=3DMSG_ID_ADDED_BY_MTA_3,QUOTED_EMAIL_TEXT autolearn=3Dham version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) As I indicated in my last note, there will be an updated version, yes, = but it will not entirely neglect the soon-to-be-superannuated RFC2916. I = don't think it is too much to ask that SIP applications utilizing ENUM be = generous in what they receive with regard to enumservices - it just doesn't = seem costly to be backwards compatible with the original iteration of the = ENUM standard. If there are things other than the enumservice update that people would = like to see mended, this last call period would be a good time to let the = authors know. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk] > Sent: Wednesday, May 14, 2003 2:51 PM > To: Peterson, Jon; 'Juha Heinanen'; Rohan Mahy > Cc: 'sipping@ietf.org'; bcampbell@dynamicsoft.com; 'Dean Willis'; > gonzalo.Camarillo@ericsson.com > Subject: RE: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt >=20 >=20 > At 3:27 am -0400 14/5/03, Peterson, Jon wrote: > >No, you're not suffering any bad dream - just an attack of = rhetorical > >exaggeration and lax reading. The authors of sipping-e164=20 > are aware of the > >rfc2916bis Internet-Draft, and have suitably referenced it=20 > in Section 7, > >which is entitled "Updates for rfc2916bis". It mentions the=20 > new enumservice > >format that concerns you so greatly below, and recommends that SIP > >applications accept either format for purposes of backwards=20 > compatibility - > >quite generous considering that rfc2916bis is just a I-D,=20 > not a standard. In > >the light of all this, it is hard for me to see a justification for > >banishing sipping-e164 from the I-D archives. > > > >But granted - the last time that sipping-e164 was updated=20 > (October 2002), > >rfc2916bis was a lot less mature than it is now. Given that=20 > a last call for > >rfc2916bis is also now in progress, it might make sense to update > >sipping-e164 to reference (normatively) the new rfc2916bis notation > >throughout, assuming that they will both go before the IESG=20 > at about the > >same time. A fair last call comment; we'll remedy this=20 > before sipping-e164 > >goes to the IESG. > > > >Jon Peterson > >NeuStar, Inc. > > > >Juha Wrote: > > > i must be seeing a VERY bad dream. the draft uses the=20 > wrong service > >> field for sip: "sip+E2U" instead of "E2U+sip" as per > >> draft-ietf-enum-rfc2916bis-06.txt. > >> > >> please discard the sipping draft from the archives AS=20 > SOON AS POSSIBLE > > > so that not a single new implementer will find and read it. > > > > To which I reply: >=20 > Hi folks, > RFC2916 is going to be obsoleted by rfc2916bis-06 (if=20 > approved)? Thus, > this backward compatibility in sipping-e164 would be with be=20 > with an obsoleted > document (not even a current I-D). >=20 > I have a lot of sympathy with Juha on this one - we have already had=20 > fun with one > bunch (strictly) implementing 2916 whilst the other bunch=20 > (strictly) implement > 2916bis - I'd prefer not continuing this. Was this a VERY bad dream?=20 > - I fear not. >=20 > =3D> Do you -REALLY- -REALLY- need backward compatibility? >=20 > My vote's to just go with the 2916bis syntax throughout, and=20 > remove reference > to the soon to be obsoleted syntax in sipping-164? >=20 > BTW, will we see an up-issued version as -02 IS out of date=20 > and has some things > that will/may/might change? >=20 > all the best, > Lawrence > --=20 > -------------------------------------------------------------- > --------- > Roke Manor Research : This information is provided "as is"=20 > and is not > : intended to create any contractual or legal > : relationship. >=20 15-May-2003 07:17:36 -0500,6901;000000000001-00000b0e Received: via dmail-2000(11) for +imap/ietf/SIPPING; Thu, 15 May 2003 = 07:17:36 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4FCHO6n021506 for ; Thu, 15 May 2003 07:17:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FBV6B23688; Thu, 15 May 2003 07:31: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 h4FBUYB23640 for ; Thu, 15 May 2003 07:30: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 IAA05469 for ; Thu, 15 May 2003 08:03:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GHTn-0006Nq-00 for sipping@ietf.org; Thu, 15 May 2003 08:04:59 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx with esmtp (Exim 4.12) id 19GHTm-0006Nh-00 for sipping@ietf.org; Thu, 15 May 2003 08:04:58 -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 h4FC4pC31658; Thu, 15 May 2003 12:04:54 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service = (5.5.2653.19) id ; Thu, 15 May 2003 08:06:44 -0400 Message-ID: = <0449D80A0E9B614A83FA9031B07E8D3B257A78@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Conroy, Lawrence (SMTP)'" , "'Juha Heinanen'" , Rohan Mahy Cc: "'sipping@ietf.org'" , bcampbell@dynamicsoft.com, "'Dean Willis'" , = gonzalo.Camarillo@ericsson.com Subject: RE: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt Date: Thu, 15 May 2003 08:06:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset=3D"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: , X-Spam-Status: No, hits=3D-2.9 required=3D5.0 tests=3DMSG_ID_ADDED_BY_MTA_3,QUOTED_EMAIL_TEXT version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) As I indicated in my last note, there will be an updated version, yes, = but it will not entirely neglect the soon-to-be-superannuated RFC2916. I = don't think it is too much to ask that SIP applications utilizing ENUM be = generous in what they receive with regard to enumservices - it just doesn't = seem costly to be backwards compatible with the original iteration of the = ENUM standard. If there are things other than the enumservice update that people would = like to see mended, this last call period would be a good time to let the = authors know. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk] > Sent: Wednesday, May 14, 2003 2:51 PM > To: Peterson, Jon; 'Juha Heinanen'; Rohan Mahy > Cc: 'sipping@ietf.org'; bcampbell@dynamicsoft.com; 'Dean Willis'; > gonzalo.Camarillo@ericsson.com > Subject: RE: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt >=20 >=20 > At 3:27 am -0400 14/5/03, Peterson, Jon wrote: > >No, you're not suffering any bad dream - just an attack of = rhetorical > >exaggeration and lax reading. The authors of sipping-e164=20 > are aware of the > >rfc2916bis Internet-Draft, and have suitably referenced it=20 > in Section 7, > >which is entitled "Updates for rfc2916bis". It mentions the=20 > new enumservice > >format that concerns you so greatly below, and recommends that SIP > >applications accept either format for purposes of backwards=20 > compatibility - > >quite generous considering that rfc2916bis is just a I-D,=20 > not a standard. In > >the light of all this, it is hard for me to see a justification for > >banishing sipping-e164 from the I-D archives. > > > >But granted - the last time that sipping-e164 was updated=20 > (October 2002), > >rfc2916bis was a lot less mature than it is now. Given that=20 > a last call for > >rfc2916bis is also now in progress, it might make sense to update > >sipping-e164 to reference (normatively) the new rfc2916bis notation > >throughout, assuming that they will both go before the IESG=20 > at about the > >same time. A fair last call comment; we'll remedy this=20 > before sipping-e164 > >goes to the IESG. > > > >Jon Peterson > >NeuStar, Inc. > > > >Juha Wrote: > > > i must be seeing a VERY bad dream. the draft uses the=20 > wrong service > >> field for sip: "sip+E2U" instead of "E2U+sip" as per > >> draft-ietf-enum-rfc2916bis-06.txt. > >> > >> please discard the sipping draft from the archives AS=20 > SOON AS POSSIBLE > > > so that not a single new implementer will find and read it. > > > > To which I reply: >=20 > Hi folks, > RFC2916 is going to be obsoleted by rfc2916bis-06 (if=20 > approved)? Thus, > this backward compatibility in sipping-e164 would be with be=20 > with an obsoleted > document (not even a current I-D). >=20 > I have a lot of sympathy with Juha on this one - we have already had=20 > fun with one > bunch (strictly) implementing 2916 whilst the other bunch=20 > (strictly) implement > 2916bis - I'd prefer not continuing this. Was this a VERY bad dream?=20 > - I fear not. >=20 > =3D> Do you -REALLY- -REALLY- need backward compatibility? >=20 > My vote's to just go with the 2916bis syntax throughout, and=20 > remove reference > to the soon to be obsoleted syntax in sipping-164? >=20 > BTW, will we see an up-issued version as -02 IS out of date=20 > and has some things > that will/may/might change? >=20 > all the best, > Lawrence > --=20 > -------------------------------------------------------------- > --------- > Roke Manor Research : This information is provided "as is"=20 > and is not > : intended to create any contractual or legal > : relationship. >=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 15-May-2003 08:06:56 -0500,1952;000000000001-00000b0f Received: via dmail-2000(11) for +imap/ietf/SIPPING; Thu, 15 May 2003 = 08:06:56 -0500 (CDT) Return-Path: Received: from harjus.eng.song.fi (mail@harjus.eng.song.fi = [195.10.149.20]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4FD6m6n021852 for ; Thu, 15 May 2003 08:06:48 -0500 Received: from jh by harjus.eng.song.fi with local (Exim 3.35 #1 = (Debian)) id 19GIRE-0000I8-00; Thu, 15 May 2003 16:06:24 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=3Dus-ascii Content-Transfer-Encoding: 7bit Message-ID: <16067.37072.865297.570579@harjus.eng.song.fi> Date: Thu, 15 May 2003 16:06:24 +0300 To: "Peterson, Jon" Cc: "'Conroy, Lawrence (SMTP)'" , Rohan Mahy = , "'sipping@ietf.org'" , bcampbell@dynamicsoft.com, "'Dean Willis'" , = gonzalo.Camarillo@ericsson.com Subject: RE: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt In-Reply-To: = <0449D80A0E9B614A83FA9031B07E8D3B257A78@stntexch2.va.neustar.com> References: = <0449D80A0E9B614A83FA9031B07E8D3B257A78@stntexch2.va.neustar.com> X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen X-Spam-Status: No, hits=3D-28.6 required=3D5.0 tests=3DEMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_VM autolearn=3Dham version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) Peterson, Jon writes: > I don't > think it is too much to ask that SIP applications utilizing ENUM be = generous > in what they receive with regard to enumservices - it just doesn't = seem > costly to be backwards compatible with the original iteration of the = ENUM > standard. check, for example, with cisco and let me know when they accept enum replies with both formats. today they don't which is a very big problem.=20 -- juha 15-May-2003 08:18:18 -0500,3663;000000000001-00000b10 Received: via dmail-2000(11) for +imap/ietf/SIPPING; Thu, 15 May 2003 = 08:18:18 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4FDIB6n021934 for ; Thu, 15 May 2003 08:18:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FCWBB28675; Thu, 15 May 2003 08: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 h4FCVDB28603 for ; Thu, 15 May 2003 08:31:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07776 for ; Thu, 15 May 2003 09:03:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GIQS-00077W-00 for sipping@ietf.org; Thu, 15 May 2003 09:05:36 -0400 Received: from harjus.eng.song.fi ([195.10.149.20] ident=3Dmail) by ietf-mx with esmtp (Exim 4.12) id 19GIQR-00077T-00 for sipping@ietf.org; Thu, 15 May 2003 09:05:36 -0400 Received: from jh by harjus.eng.song.fi with local (Exim 3.35 #1 = (Debian)) id 19GIRE-0000I8-00; Thu, 15 May 2003 16:06:24 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=3Dus-ascii Content-Transfer-Encoding: 7bit Message-ID: <16067.37072.865297.570579@harjus.eng.song.fi> Date: Thu, 15 May 2003 16:06:24 +0300 To: "Peterson, Jon" Cc: "'Conroy, Lawrence (SMTP)'" , Rohan Mahy = , "'sipping@ietf.org'" , bcampbell@dynamicsoft.com, "'Dean Willis'" , = gonzalo.Camarillo@ericsson.com Subject: RE: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt In-Reply-To: = <0449D80A0E9B614A83FA9031B07E8D3B257A78@stntexch2.va.neustar.com> References: = <0449D80A0E9B614A83FA9031B07E8D3B257A78@stntexch2.va.neustar.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: , X-Spam-Status: No, hits=3D-28.6 required=3D5.0 tests=3DEMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_VM version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) Peterson, Jon writes: > I don't > think it is too much to ask that SIP applications utilizing ENUM be = generous > in what they receive with regard to enumservices - it just doesn't = seem > costly to be backwards compatible with the original iteration of the = ENUM > standard. check, for example, with cisco and let me know when they accept enum replies with both formats. today they don't which is a very big problem.=20 -- 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 15-May-2003 10:30:31 -0500,4982;000000000001-00000b11 Received: via dmail-2000(11) for +imap/ietf/SIPPING; Thu, 15 May 2003 = 10:30:31 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4FFUK6n022776 for ; Thu, 15 May 2003 10:30:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FEi3B06874; Thu, 15 May 2003 10:44: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 h4FEheB06834 for ; Thu, 15 May 2003 10:43: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 LAA11951 for ; Thu, 15 May 2003 11:16:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GKUa-00003y-00 for sipping@ietf.org; Thu, 15 May 2003 11:18:00 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19GKUa-00003v-00 for sipping@ietf.org; Thu, 15 May 2003 11:18:00 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service = (5.5.2653.19) id ; Thu, 15 May 2003 16:19:09 +0100 Received: from orion.roke.co.uk ([193.118.192.66]) by = rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service = Version 5.5.2653.13) id K0FN6Y56; Thu, 15 May 2003 16:19:06 +0100 From: "Conroy, Lawrence (SMTP)" To: sipping@ietf.org Cc: "Peterson, Jon" , Juha Heinanen Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Thu, 15 May 2003 16:19:21 +0100 Content-Type: text/plain; charset=3D"us-ascii" ; format=3D"flowed" Subject: [Sipping] e164 enumservice syntax 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: , X-Spam-Status: No, hits=3D-6.3 required=3D5.0 tests=3DSIGNATURE_LONG_DENSE autolearn=3Dham version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) Hi Folks, [renamed the thread to be more specific] * "Backward compatibility". There seem to be several choices here: (i) allow only RFC2916 syntax (ii) allow only rfc2916bis syntax (iii) allow both The e164-02 seems (apart from the add on in section 1 and section 7) to tend towards the first option (notably in the last sentence of section 5.1). However, with the inclusions of these caveats, it now seems to be sort of going for the last option. I object to this as it means we are producing an RFC that allows (or RECOMMENDs) syntax that we KNOW will be obsoleted in the very near future (unless someone needs to let me in on a secret :). I assume that -e164 is going to reference the 2916bis RFC, so it will be dependent on this - this isn't going to appear before 2916bis gets through the process. As part of the release of 2916bis, it obsoletes 2916 in the same way that 3403 obsoleted 2915. Thus -e164 WILL be referring to obsoleted documents and syntax. The current text does not deprecate this syntax, so the -02 version of the draft (i.e the one we're reviewing) is at least adrift from "normal" IETF practice (see RFC2026 = ss4.2.4,...). Now...given that 2916bis and the other enum drafts don't allow such backwards compatibility, why have it here? If this is a reference to RFC760 ss 3.2, then liberal means general flexibility with syntax; IMHO, -e164 does not need a specific reference to a (soon to be) Historic document. As Juha points out, this DOES cause confusion. As before, my vote's for option (ii). all the best, Lawrence --=20 ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is = not : intended to create any contractual or legal : relationship. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP 15-May-2003 10:32:23 -0500,6463;000000000001-00000b12 Received: via dmail-2000(11) for +imap/ietf/SIPPING; Thu, 15 May 2003 = 10:32:23 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4FFWE6n022793 for ; Thu, 15 May 2003 10:32:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FEbRB06086; Thu, 15 May 2003 10:37: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 h4FEadB05589 for ; Thu, 15 May 2003 10:36: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 LAA11866 for ; Thu, 15 May 2003 11:09:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GKNo-000029-00 for sipping@ietf.org; Thu, 15 May 2003 11:11:00 -0400 Received: from goalie.snowshore.com ([216.57.133.4] = helo=3Dwebshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 19GKNn-00001r-00 for sipping@ietf.org; Thu, 15 May 2003 11:10:59 -0400 Received: from zoe.office.snowshore.com(192.168.1.172) by = webshield.office.snowshore.com via csmap=20 id 9970; Thu, 15 May 2003 11:14:46 -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=3D"iso-8859-1" Subject: RE: [Sipping] conf: comments on = draft-rosenberg-sipping-conferencing-framework-01 Date: Thu, 15 May 2003 11:11:34 -0400 Message-ID: = <4A3384433CE2AB46A63468CB207E209D097C77@zoe.office.snowshore.com> Thread-Topic: [Sipping] conf: comments on = draft-rosenberg-sipping-conferencing-framework-01 Thread-Index: AcMKco2Qi9SqIWgYSg+Yf0l0fUHIuAQgNALQ From: "Eric Burger" To: "Jonathan Rosenberg" Cc: "Sipping (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id = h4FEadB05590 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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-Spam-Status: No, hits=3D-3.0 required=3D5.0 tests=3DQUOTED_EMAIL_TEXT,QUOTE_TWICE_1,SUBJ_HAS_UNIQ_ID autolearn=3Dham version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) My turn to apologize for being late. It's less than a month :-) Most everything looks good. Some minor points in-line. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thu, April 24, 2003 11:00 AM > To: Eric Burger > Cc: Sipping (E-mail) > Subject: Re: [Sipping] conf: comments on > draft-rosenberg-sipping-conferencing-framework-01 >=20 >=20 > My apologies for the delay in responding. Thanks for your comments. > Responses inline. >=20 > Eric Burger wrote: [snip] > > Section 3.1, 4th & 5th paragraphs The example URI > > ("discussion-on-dogs@example.com") would seem to contradict the > > admonition that "a conference URI is never constructed or guessed = by > > a user." The key point is the conference URI is opaque. It could > > mean something, or it could be a license plate. Requiring=20 > meaning is > > BAD. Requiring obscuration is also BAD. Just leave it as opaque = to > > the framework. >=20 > Having a URI with a mnemonic user part does not mean its no longer=20 > opaque to the system, no longer unique, or that the intent is=20 > for it to=20 > be guessed. For long lived conferences in particular, where=20 > there is a=20 > likelihood that someone will need to convey one over a phone, I see=20 > value in them being mnemonic. I think we agree here. That is: 1. There is value to having a mnemonic URI 2. The URI is opaque to the protocol. I was just pointing out that the text of the draft explicitly states = the conference URI must not be a mnemonic (see quote above). [snip] > > Section 5.2.1 Is it worth mentioning a stateful application=20 > server as > > a mechanism for running a conference? >=20 > I don't understand. 5.2.1 is talking about adding users to a=20 > conference.=20 > What does that have to do with using an application server? All INVITEs come from the application server. This means the = application server is fully aware of the state of all call legs; can = directly manipulate state, permissions, and media policy; and has the = added bonus of making CPCP entirely unnecessary. Given that the largest conference service bureaux in the world are on = the order of a few tens of thousands of ports, I don't think the = "application server doesn't scale like a proxy server" argument really = holds. [snip] > > Section 5.4.2 and 5.4.3 I don't really get the difference between > > these two examples. >=20 > One of them uses CPCP to remove a user. This can be done by=20 > an automata.=20 > The other uses a web application to remove a user. THis can=20 > only be done=20 > by a user. [snip] > So, just because both SIP and CPCP can change the state of a=20 > conference,=20 > does not mean that they are the same protocol. [snip] > CPCP, being a data transaction protocol, would also allow you to=20 > directly query for the list. Just because there is this sliver of=20 > overlap does not mean that they are the same protocol. A "sliver of overlap" is OK. A full set of overlap is not. Look at = the draft, for just about every operation, the draft says, "Here is the = way to do it with SIP, and here is the way to do it with CPCP." It may = be my misreading, but it sounds like there is a lot of overlap. [snip] _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP 15-May-2003 10:45:40 -0500,4735;000000000001-00000b13 Received: via dmail-2000(11) for +imap/ietf/SIPPING; Thu, 15 May 2003 = 10:45:40 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4FFjX6n022926 for ; Thu, 15 May 2003 10:45:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FF17B08175; Thu, 15 May 2003 11:01: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 h4FF0KB08127 for ; Thu, 15 May 2003 11:00: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 LAA12426 for ; Thu, 15 May 2003 11:32:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GKki-0000Ax-00 for sipping@ietf.org; Thu, 15 May 2003 11:34:40 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19GKkh-0000Au-00 for sipping@ietf.org; Thu, 15 May 2003 11:34:40 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service = (5.5.2653.19) id ; Thu, 15 May 2003 16:35:49 +0100 Received: from orion.roke.co.uk ([193.118.192.66]) by = rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service = Version 5.5.2653.13) id K0FN6Y72; Thu, 15 May 2003 16:35:45 +0100 From: "Conroy, Lawrence (SMTP)" To: sipping@ietf.org Cc: Rohan.Mahy@cisco.com, "Peterson, Jon" Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Thu, 15 May 2003 16:35:59 +0100 Content-Type: text/plain; charset=3D"us-ascii" ; format=3D"flowed" Subject: [Sipping] status of sipping-e164-02.txt//enum-sip-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: , X-Spam-Status: No, hits=3D-6.3 required=3D5.0 tests=3DSIGNATURE_LONG_DENSE autolearn=3Dham version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) Hi folks, [Renamed thread to be more specific] I'm not sure what the relationship is between this I-D and the enum-sip I-D. I had wondered if the sipping- draft was going to be superceded by the enum- draft, but there is a lot of useful exemplary information in the sipping- draft that gives good guidance to implementors. However, there are chunks of text in this one that seem appropriate for a 'sip' enumservice definition (e.g. section 5). Thus, what is the role for this draft; is it informational, or standards-track, and if so, what is it defining, given that there's also an enum-sip draft on the standards track? =3D> IMHO, the sipping- draft does need to be re-addressed in light of the 'sip' enumservices draft. At present there are overlaps in several of the sections. There are some more detailed issues, of course; notably in the treatment of order and preference fields in section 6.3 - time has moved on since this draft was issued, and it will need to be changed. Also, as an aside, some of the statements that seem to mandate a particular treatment do not include the usual SHALL, MUST, ..keywords. For example, the penultimate sentence in the 2nd paragraph of section 5.3, which is an instruction, but does not have MUST (only 'is = always'). This is followed immediately by a sentence that has a SHOULD. Choose. This draft needs an up-issue, IMHO, and a decision on whether it is standards-track or informational (it is silent on the matter). all the best, Lawrence --=20 ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is = not : intended to create any contractual or legal : relationship. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP 14-May-2003 03:45:10 -0500,1777;000000000000-00000b14 Received: via dmail-2000(11) for +imap/INCOMING; Wed, 14 May 2003 = 03:45:10 -0500 (CDT) Return-Path: Received: from albatross.tn.sw.ericsson.se = (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4E8j26n009678 for ; Wed, 14 May 2003 03:45:03 -0500 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 h4E8iX0Q004433; Wed, 14 May 2003 10:44:40 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service = (5.5.2655.55) id ; Wed, 14 May 2003 10:43:20 +0200 Message-ID: = From: "Gonzalo Camarillo Gonzalez (LMF)" To: "'sipping@ietf.org'" Cc: "Jon Peterson (E-mail)" , "Rohan Mahy (E-mail)" , "Dean Willis (E-mail)" Subject: Last Call for early media use cases Date: Wed, 14 May 2003 09:12:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset=3D"iso-8859-1" X-Spam-Status: No, hits=3D0.0 required=3D5.0 tests=3Dnone version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) Folks, in the last IETF meeting, we requested early media use cases that show = the need of a "media coming" flag. So far, we have not received = anything. We intend to release a new version of the early media draft in a week = or so. So, that is the time you have to send me your use cases. Thanks, Gonzalo 13-May-2003 23:02:49 -0500,1682;000000000001-00000b15 Received: via dmail-2000(11) for +imap/INCOMING; Tue, 13 May 2003 = 23:02:49 -0500 (CDT) Return-Path: Received: from sj-core-1.cisco.com (sj-core-1.cisco.com = [171.71.177.237]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4E42e6n007909 for ; Tue, 13 May 2003 23:02:40 -0500 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.6/8.12.6) with ESMTP id h4E41mDU022723; Tue, 13 May 2003 21:01:48 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHB69236; Tue, 13 May 2003 20:55:25 -0700 (PDT) Date: Tue, 13 May 2003 21:02:01 -0700 Subject: WGLC for draft-ietf-sipping-e164-02.txt Content-Type: text/plain; charset=3DUS-ASCII; format=3Dflowed Mime-Version: 1.0 (Apple Message framework v552) Cc: jon.peterson@neustar.biz, bcampbell@dynamicsoft.com, = rohan@cisco.com, "'Dean Willis'" , = gonzalo.Camarillo@ericsson.com To: "'sipping@ietf.org'" From: Rohan Mahy Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=3D-2.1 required=3D5.0 tests=3DUSER_AGENT_APPLEMAIL autolearn=3Dham version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) Hello Everyone, I'd like to begin Working Group Last Call on: http:/www.ietf.org/internet-drafts/draft-ietf-sipping-e164-02.txt this WGLC will end on June 13, 2003. thanks, -rohan 15-May-2003 13:40:44 -0500,6996;000000000001-00000b16 Received: via dmail-2000(11) for +imap/ietf/SIPPING; Thu, 15 May 2003 = 13:40:44 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4FIeY6n024326 for ; Thu, 15 May 2003 13:40:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FHu3B22250; Thu, 15 May 2003 13: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 h4FHtWB22224 for ; Thu, 15 May 2003 13: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 OAA17711 for ; Thu, 15 May 2003 14:27:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GNUD-0001MX-00 for sipping@ietf.org; Thu, 15 May 2003 14:29:49 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx with esmtp (Exim 4.12) id 19GNUC-0001MJ-00 for sipping@ietf.org; Thu, 15 May 2003 14:29:48 -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 h4FIUQC06622; Thu, 15 May 2003 18:30:26 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service = (5.5.2653.19) id ; Thu, 15 May 2003 14:32:20 -0400 Message-ID: = <0449D80A0E9B614A83FA9031B07E8D3B257A7D@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Conroy, Lawrence (SMTP)'" , sipping@ietf.org Cc: Juha Heinanen Date: Thu, 15 May 2003 14:32:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset=3D"iso-8859-1" Subject: [Sipping] RE: e164 enumservice syntax 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: , X-Spam-Status: No, hits=3D-2.9 required=3D5.0 tests=3DMSG_ID_ADDED_BY_MTA_3,QUOTED_EMAIL_TEXT autolearn=3Dham version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) I think we both agree that e164-02 specifies (iii), and I think e164-03 should as well. RF2026 does not mandate, as you seem to suggest, that behavior for backwards compatibility is illegal in IETF standards. ENUM = made a decision (the reasons for which are outside the scope of our work in SIPPING) to reverse its enumservice string format in order to break automatic backwards compatibility, yes. This does not change the fact = that several ENUM implementations have been constructed in the three years = since the publication of RFC2916 that use the service field format of = RFC2916. Some implementations, no doubt, use those formats today. There are numerous RFCs that contain guidance for dealing with implementations that are compliant with older versions of a = specification (for example, the SIP RFC, RFC3261, contains numerous references to = RFC2543 and quite a bit of behavior that is intended to foster backwards compatibility) - this is in no way suspect or broken from a process perspective. I don't think that ENUM clients acting on behalf of SIP applications which retrieve usable resource records should be forced to discard these records because the enumservice uses a standard format = that has been superannuated. Considering that there are probably = implementations out there in the field today that will return such records, I think = that would be a poor decision. I don't think any "confusion" that might = result from this has yet been substantiated. Nor do I think it is an unseemly burden for implementers to support two variations on a seven-character string instead of one. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk] > Sent: Thursday, May 15, 2003 8:19 AM > To: sipping@ietf.org > Cc: Peterson, Jon; Juha Heinanen > Subject: e164 enumservice syntax support >=20 >=20 > Hi Folks, > [renamed the thread to be more specific] > * "Backward compatibility". There seem to be several choices > here: (i) allow only RFC2916 syntax > (ii) allow only rfc2916bis syntax > (iii) allow both > The e164-02 seems (apart from the add on in section 1 and > section 7) to tend towards the first option (notably in the > last sentence of section 5.1). However, with the inclusions > of these caveats, it now seems to be sort of going for the > last option. > I object to this as it means we are producing an RFC that > allows (or RECOMMENDs) syntax that we KNOW will be obsoleted > in the very near future (unless someone needs to let me in > on a secret :). > I assume that -e164 is going to reference the 2916bis RFC, > so it will be dependent on this - this isn't going to appear > before 2916bis gets through the process. As part of the release > of 2916bis, it obsoletes 2916 in the same way that 3403 = obsoleted > 2915. Thus -e164 WILL be referring to obsoleted documents and > syntax. The current text does not deprecate this syntax, so the > -02 version of the draft (i.e the one we're reviewing) is at > least adrift from "normal" IETF practice (see RFC2026 = ss4.2.4,...). >=20 > Now...given that 2916bis and the other enum drafts don't allow > such backwards compatibility, why have it here? > If this is a reference to RFC760 ss 3.2, then liberal means > general flexibility with syntax; IMHO, -e164 does not need a > specific reference to a (soon to be) Historic document. > As Juha points out, this DOES cause confusion. As before, my > vote's for option (ii). >=20 > all the best, > Lawrence > --=20 > -------------------------------------------------------------- > --------- > Roke Manor Research : This information is provided "as is"=20 > and is not > : intended to create any contractual or legal > : relationship. >=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 15-May-2003 14:19:44 -0500,6048;000000000001-00000b17 Received: via dmail-2000(11) for +imap/ietf/SIPPING; Thu, 15 May 2003 = 14:19:44 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4FJJZ6n024599 for ; Thu, 15 May 2003 14:19:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4FITJB24806; Thu, 15 May 2003 14:29: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 h4FISoB24780 for ; Thu, 15 May 2003 14:28: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 PAA18731 for ; Thu, 15 May 2003 15:01:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GO0P-0001Zq-00 for sipping@ietf.org; Thu, 15 May 2003 15:03:05 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx with esmtp (Exim 4.12) id 19GO0P-0001Ze-00 for sipping@ietf.org; Thu, 15 May 2003 15:03:05 -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 h4FJ3dC07292; Thu, 15 May 2003 19:03:39 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service = (5.5.2653.19) id ; Thu, 15 May 2003 15:05:32 -0400 Message-ID: = <0449D80A0E9B614A83FA9031B07E8D3B257A80@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Conroy, Lawrence (SMTP)'" , sipping@ietf.org Cc: Rohan.Mahy@cisco.com Date: Thu, 15 May 2003 15:05:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset=3D"iso-8859-1" Subject: [Sipping] RE: status of sipping-e164-02.txt//enum-sip-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: , X-Spam-Status: No, hits=3D-3.5 required=3D5.0 tests=3DMSG_ID_ADDED_BY_MTA_3,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1 autolearn=3Dham version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) Unlike draft-ietf-enum-sip, draft-ietf-sipping-e164 exists to describe = how SIP implementations should handle E.164 numbers, which may appear in contexts in which ENUM is impracticable or uninformative (such as = gateway location scenarios, cases in which there is no ENUM record = corresponding to a particular E.164 number, etc). As you may have noted, it is not an enumservice definition, but it references and uses an enumservice = definition (see sipping-e164 reference [15]). While there are some overlaps = between the two drafts (draft-ietf-enum-sip, especially in Section 3, summarizes = some of the conclusions of sipping-e164), I don't feel these damage or devalue either of the documents. That much said, as I revise this document in response to last call comments, I'll try to seek out and remove any unhelpful redundancy. Redundancy with rfc2916bis, which has become = better specified over time, is probably more likely, and I'll also keep an eye = out for that. >=20 > There are some more detailed issues, of course; notably in the > treatment of order and preference fields in section 6.3 - time has > moved on since this draft was issued, and it will need to be changed. Um, while I don't think the behaviorial recommendations would really = change (i.e. use one order when you author ENUM records and differentiate by preference), I'd agree that 6.3 isn't so crucial, given that rfc2916bis = now has section 1.3. I could make 6.3 much shorter and less specific today; prior versions of rfc2916bis had much less guidance about dealing with order. > Also, as an aside, some of the statements that seem to mandate a > particular treatment do not include the usual SHALL, MUST, = ..keywords. > For example, the penultimate sentence in the 2nd paragraph of section > 5.3, which is an instruction, but does not have MUST (only 'is = always'). > This is followed immediately by a sentence that has a SHOULD. Choose. >=20 I think the "is always" in 5.3 is not an instruction - it's an = observation. The sentence following it is a normative instruction. Really, the "is always" sentence asserted only that in RFC2916 (and in bis), this "is always" how examples were constructed. That could be clearer, though, = sure, and it will be. > This draft needs an up-issue, IMHO, and a decision on whether it is > standards-track or informational (it is silent on the matter). As I said, I'll be issuing a new revision, and I'll incorporate the = comments above. However, IETF documents do not declare their intended status, at least as far as I know. sipping-e164 is not meant to be Informational - = it contains numerous normative guidelines, and was intended for PS.=20 Jon Peterson NeuStar, Inc. > all the best, > Lawrence > --=20 > -------------------------------------------------------------- > --------- > Roke Manor Research : This information is provided "as is"=20 > and is not > : intended to create any contractual or legal > : relationship. >=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 15-May-2003 19:57:05 -0500,6437;000000000001-00000b18 Received: via dmail-2000(11) for +imap/ietf/SIPPING; Thu, 15 May 2003 = 19:57:05 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4G0us6n026564 for ; Thu, 15 May 2003 19:56:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4G0CHB15192; Thu, 15 May 2003 20:12: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 h4G0BZB15165 for ; Thu, 15 May 2003 20:11:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28502 for ; Thu, 15 May 2003 20:43:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GTLk-0003DF-00 for sipping@ietf.org; Thu, 15 May 2003 20:45:28 -0400 Received: from auemail2.lucent.com ([192.11.223.163] = helo=3Dauemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19GTLe-0003DB-00 for sipping@ietf.org; Thu, 15 May 2003 20:45:22 -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.6/Switch-2.2.0) with ESMTP = id h4G0jWV16172 for ; Thu, 15 May 2003 20:45:32 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service = (5.5.2653.19) id ; Fri, 16 May 2003 01:45:31 +0100 Message-ID: = <475FF955A05DD411980D00508B6D5FB00877BB87@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Conroy, Lawrence (SMTP)'" , "'sipping@ietf.org'" Cc: "'Peterson, Jon'" , "'Juha Heinanen'" Subject: RE: [Sipping] e164 enumservice syntax support Date: Fri, 16 May 2003 01:45:26 +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: , X-Spam-Status: No, hits=3D-3.2 required=3D5.0 tests=3DQUOTED_EMAIL_TEXT autolearn=3Dham version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) Perhaps an appropriate AD can make a definitive statement on the future = of RFC 2916. It would appear to me that it is entirely inappropriate to have a = reference in a new RFC to an RFC that is already obsolete. So is this = the situation that will exist? This is not the same case as when a revised RFC refers to the previous = version of the same RFC. The appropriate place to cover that case is in = rfc2916bis with respect to RFC 2916, rather than in the sipping e164 = document. I understand that it does not do that. regards Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com=20 > -----Original Message----- > From: Conroy, Lawrence (SMTP) [mailto:lwc@roke.co.uk] > Sent: 15 May 2003 16:19 > To: sipping@ietf.org > Cc: Peterson, Jon; Juha Heinanen > Subject: [Sipping] e164 enumservice syntax support >=20 >=20 > Hi Folks, > [renamed the thread to be more specific] > * "Backward compatibility". There seem to be several choices > here: (i) allow only RFC2916 syntax > (ii) allow only rfc2916bis syntax > (iii) allow both > The e164-02 seems (apart from the add on in section 1 and > section 7) to tend towards the first option (notably in the > last sentence of section 5.1). However, with the inclusions > of these caveats, it now seems to be sort of going for the > last option. > I object to this as it means we are producing an RFC that > allows (or RECOMMENDs) syntax that we KNOW will be obsoleted > in the very near future (unless someone needs to let me in > on a secret :). > I assume that -e164 is going to reference the 2916bis RFC, > so it will be dependent on this - this isn't going to appear > before 2916bis gets through the process. As part of the release > of 2916bis, it obsoletes 2916 in the same way that 3403=20 > obsoleted > 2915. Thus -e164 WILL be referring to obsoleted documents and > syntax. The current text does not deprecate this syntax, so the > -02 version of the draft (i.e the one we're reviewing) is at > least adrift from "normal" IETF practice (see RFC2026=20 > ss4.2.4,...). >=20 > Now...given that 2916bis and the other enum drafts don't allow > such backwards compatibility, why have it here? > If this is a reference to RFC760 ss 3.2, then liberal means > general flexibility with syntax; IMHO, -e164 does not need a > specific reference to a (soon to be) Historic document. > As Juha points out, this DOES cause confusion. As before, my > vote's for option (ii). >=20 > all the best, > Lawrence > --=20 > -------------------------------------------------------------- > --------- > Roke Manor Research : This information is provided "as is"=20 > and is not > : intended to create any contractual or legal > : relationship. > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP >=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 16-May-2003 04:18:50 -0500,3560;000000000001-00000b19 Received: via dmail-2000(11) for +imap/ietf/SIPPING; Fri, 16 May 2003 = 04:18:50 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4G9Ia6n029955 for ; Fri, 16 May 2003 04:18:40 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4G8UEB23848; Fri, 16 May 2003 04:30: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 h4G8TLB23815 for ; Fri, 16 May 2003 04:29: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 FAA17053 for ; Fri, 16 May 2003 05:01:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Gb7X-0005QL-00 for sipping@ietf.org; Fri, 16 May 2003 05:03:19 -0400 Received: from smtp2.dataconnection.com ([192.91.191.8] = helo=3Dmiles.dataconnection.com) by ietf-mx with esmtp (Exim 4.12) id 19Gb7S-0005QH-00 for sipping@ietf.org; Fri, 16 May 2003 05:03:14 -0400 Received: by miles.datcon.co.uk with Internet Mail Service = (5.5.2656.59) id ; Fri, 16 May 2003 10:03:42 +0100 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F8B8E53D@baker.datcon.co.uk> From: Nicole Johnson To: "'sipping@ietf.org'" Date: Fri, 16 May 2003 10:03:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset=3D"iso-8859-1" Subject: [Sipping] [Sipping]Questions on = draft-ietf-sipping-connect-reuse-reqs-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: , X-Spam-Status: No, hits=3D0.8 required=3D5.0 tests=3DSUBJ_HAS_UNIQ_ID version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) I have a couple of questions about = draft-ietf-sipping-connect-reuse-reqs-00. 1. Intended scope of alias parameter. =20 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? 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 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?=20 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 16-May-2003 04:23:29 -0500,55379;000000000001-00000b1a Received: via dmail-2000(11) for +imap/ietf/SIPPING; Fri, 16 May 2003 = 04:23:29 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4G9N86n030018 for ; Fri, 16 May 2003 04:23:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4G8a6B24227; Fri, 16 May 2003 04:36: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 h4E7ToB20927 for ; Wed, 14 May 2003 03:29: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 EAA08900 for ; Wed, 14 May 2003 04:02:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FrFq-0003aJ-00 for sipping@ietf.org; Wed, 14 May 2003 04:04:50 -0400 Received: from n171-18.deltathree.com ([208.170.171.18] = helo=3Dexch-jlm2.deltathree.com) by ietf-mx with esmtp (Exim 4.12) id 19FrFo-0003aG-00 for sipping@ietf.org; Wed, 14 May 2003 04:04:49 -0400 Received: by n171-18.deltathree.com with Internet Mail Service = (5.5.2653.19) id ; Wed, 14 May 2003 11:05:19 +0300 Message-ID: = From: David Schwartz To: "'rohan@cisco.com'" Cc: "'Nachumf@audiocodes.com'" , "'sip_developer@hotmail.com'" , "'sipping@ietf.org'" , "'AttilaS@vegastream.com'" , "'sip-implementors@cs.columbia.edu'" , "'rizsanyi@neobee.net'" Date: Wed, 14 May 2003 11:05:18 +0300 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [Sipping] Re: [Sip-implementers] dtmf digits using INFO ... = SIPauthors ... Can you answer please ? Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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-Spam-Status: No, hits=3D-11.2 required=3D5.0 tests=3DASCII_FORM_ENTRY,EMAIL_ATTRIBUTION,HTML_20_30,HTML_MESSAGE, ORIGINAL_MESSAGE,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1 version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) Hi Rohan. I would like to add to Nachum's comment. Here at deltathree we have been using an IVR type system for about two = years now with originating sip devices contacting our network from many = different locations. For termination we are using Cisco Gateways that address the double digit issue (as Nachum stated). What we have found is that in locations that have very poor infrastructure (usually satellite) = RFC2833 is highly unreliable. In these locations where latency and packet loss are high, and the traffic may be bursty in nature, the retransmission = mechanism associated with INFO requests assures the arrival of all the digits = whereas 2833 is not providing us with the same completion rates.=20 When entering a PIN code for instance where the loss of even one digit = is destructive we have had higher success rates with INFO type solutions (vegastream, audiocodes, etc,) than we have had with pure RFC2833 = devices. True there is a longer delay associated with this approach as each = digit is sent only after receiving a 200 response but the alternative is in many cases not being able to enter the PIN at all. David Schwartz -----Original Message----- From: sipping-request@ietf.org [mailto:sipping-request@ietf.org] Sent: Tue, May 13, 2003 8:46 PM To: sipping@ietf.org Subject: Sipping digest, Vol 1 #1017 - 4 msgs Send Sipping mailing list submissions to sipping@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/sipping or, via email, send a message with subject or body 'help' to sipping-request@ietf.org You can reach the person managing the list at sipping-admin@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Sipping digest..." Today's Topics: 1. RE: Re: [Sip-implementors] dtmf digits using INFO ... SIPauthors = ... Can you answer please ? (Nachum Frid) 2. Re: Re: [Sip-implementors] dtmf digits using INFO ... SIPauthors = ... Can you answer please ? (Rohan Mahy) 3. RE: Re: [Sip-implementors] dtmf digits using INFO ... S IPauthors ... Can you answer please ? (Francois Audet) --__--__-- Message: 1 Subject: RE: [Sipping] Re: [Sip-implementors] dtmf digits using INFO = ... SIPauthors ... Can you answer please ? Date: Tue, 13 May 2003 19:42:06 +0200 From: "Nachum Frid" To: "Rohan Mahy" , "SIP Developer" Cc: , "Attila Sipos" , , Rohan, =20 In your draft you are describing the double DTMF problem: " Under this proposal, a User Agent MUST NOT send signaled digits = or telephone-events using the INFO method if the event was ever represented as a tone (as media). Only signals originated as = pure signaling MAY generate an INFO method. Failure to heed this requirement will result in double-detection of digits/events =20 If INFO is used incorrectly by a pair of PSTN gateways (for = example), the source gateway may detect a digit, send an INFO request = which is lost, and retransmit that request. The target gateway would send the original in-band tone to the PSTN when the audio media arrives, = later when the INFO arrives, the target gateway would render the same = tone again. It is quite likely that the INFO will arrive after the = media tone has been played (especially if multiple intermediaries are involved); the same digit would be played out again and this = will frequently cause systems in the PSTN to detect the same digit signaled twice." =20 =20 =20 Most of the PSTN gateways we are familiar with (Cisco, = AudioCodes) will mute the DTMF signal, when they are configured to use out of band DTMF(H.245 alphanumeric, or SIP INFO). Usually source gateway will = detect DTMF digit coming from the PSTN side and erase it from the voice stream = not relaying it to IP. Than, the INFO (or H.245) message is send to the = target gateway, which will regenerate the DTMF to the PSTN side, without = playing double digits. In H.323 it works already for few years. =20 Nachum =20 =20 -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com]=20 Sent: Tuesday, May 13, 2003 1:34 AM To: SIP Developer Cc: sipping@ietf.org; Attila Sipos; sip-implementors@cs.columbia.edu; rizsanyi@neobee.net Subject: Re: [Sipping] Re: [Sip-implementors] dtmf digits using INFO = ... SIPauthors ... Can you answer please ? =20 Hi Rohan, =20 The main reason to not carry DTMF in SIP INFOs is that there is = a very =20 good chance that you will get double-digits or otherwise = corrupted =20 digits because the signaling is not time-synchronized with the = audio media. This issue is discussed in an expired draft which I = wrote a =20 long time ago, which I abandoned in favor of the work generated = by the =20 app-interaction design team. At this point my draft is useful = only in that it explains how double digits tend to occur. =20 my expired draft: =20 = http://www.softarmor.com/sipping/drafts/morgue/draft-mahy-sipping-=20 signaled-digits-01.html =20 the app-interaction design team drafts: =20 =20 http://www.softarmor.com/sipping/drafts/draft-burger-sipping-kpml-01.txt= = http://www.softarmor.com/sipping/drafts/draft-culpepper-sipping-app-=20 interact-reqs-03.txt = http://www.softarmor.com/sipping/drafts/draft-jennings-sip-app-info-=20 00.txt = http://www.softarmor.com/sipping/drafts/draft-rosenberg-sipping-app-=20 interaction-framework-00.txt =20 =20 thanks, -rohan (Mahy) =20 =20 On Friday, May 9, 2003, at 11:05 AM, SIP Developer wrote: =20 > Hi All, > > I hate to say that but SIP community doesn't agree > or think that there are lots of use and requirement for = carrying > DTMF Out-of-Band. > > Every month, I can see that someone asks the same question = again and =20 > again > that how do we send DTMF via INFO and Out-Of-Band . > > 3pcc needs it, lots of service creation environment needs it = and > doesn't it looks promising to have a way in SIP to do OOB > DTMF just like h245-alphanumeric in H.323. > > If we think of applications, then there are lots of them that = I can > count which doesn't care about the timing info carried by = RFC2833. > And if we really care about timing, then carrying RFC2833 via > notify (Again OOB) is promising. > > I really do not understand if this is a political issue to not promote > SIP INFO for carrying DTMF or if someone can justify it to me > that there is no use to carry DTMF OOB. > > SIP authors, can you answer why SIP INFO for carrying simple > DTMF is not a standard solution ? > > Thanks, > Rohan Kumar > > > ----- Original Message ----- > From: "Attila Sipos" > To: ; > Sent: Friday, May 09, 2003 9:50 AM > Subject: RE: [Sip-implementors] dtmf digits using INFO > > >> >> Hello Zsolt, >> >> I still don't think there is a fully-agreed >> standard. However, as much as I hate to say it, >> CISCO have their own proposed standard which some >> people (like us) interoperate with: >> >> > = http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/=20 > 122newft/122 >> t/122t11/ftinfo.htm >> >> Regards, >> >> Attila >> >> Attila Sipos >> Software Engineer >> >> VegaStream : A World of difference for your Integrated Communications >> >> (jo napot kiv=E1nok) >> >> >> >>> -----Original Message----- >>> From: Rizsanyi Zsolt [mailto:rizsanyi@myrealbox.com] >>> Sent: 09 May 2003 13:41 >>> To: sip-implementors@cs.columbia.edu >>> Subject: [Sip-implementors] dtmf digits using INFO >>> >>> >>> Hi! >>> >>> Could somebody refer me to a current standard or draft, on >>> how to send dtmf >>> digits using the INFO method? >>> >>> Thanks >>> Zsolt Rizsanyi >>> >>> _______________________________________________ >>> Sip-implementors mailing list >>> Sip-implementors@cs.columbia.edu >>> = http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >>> >> >> _______________________________________________ >> Sip-implementors mailing list >> Sip-implementors@cs.columbia.edu >> = http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >> > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current = sip > Use sip@ietf.org for new developments of core SIP =20 =20 _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors --__--__-- Message: 2 Date: Tue, 13 May 2003 09:56:06 -0700 Subject: Re: [Sipping] Re: [Sip-implementors] dtmf digits using INFO = ... SIPauthors ... Can you answer please ? Cc: "SIP Developer" , , "Attila Sipos" , , To: "Nachum Frid" From: Rohan Mahy On Tuesday, May 13, 2003, at 10:42 AM, Nachum Frid wrote: > Rohan, > > In your draft you are describing the double DTMF problem: > " > Under this proposal, a User Agent MUST NOT send signaled = digits =20 > or > telephone-events using the INFO method if the event was = ever > represented as a tone (as media). Only signals originated = > as pure > signaling MAY generate an INFO method. Failure to heed = this > requirement will result in double-detection of = digits/events > > If INFO is used incorrectly by a pair of PSTN gateways (for =20 > example), > the source gateway may detect a digit, send an INFO request =20 > which is lost, and retransmit that request. The target gateway = would > send the > original in-band tone to the PSTN when the audio media = arrives, =20 > later > when the INFO arrives, the target gateway would render the = same =20 > tone > again. It is quite likely that the INFO will arrive after the = =20 > media > tone has been played (especially if multiple intermediaries = are > involved); the same digit would be played out again and this =20 > will > frequently cause systems in the PSTN to detect the same digit > signaled twice." > > > > Most of the PSTN gateways we are familiar with (Cisco, =20 > AudioCodes) will mute the DTMF signal, when they are configured to = use =20 > out of band DTMF(H.245 alphanumeric, or SIP INFO). Usually source =20 > gateway will detect DTMF digit coming from the PSTN side and erase it = =20 > from the voice stream not relaying it to IP. In my experience the muting/erasure is imprecise and imperfect at best. = =20 Frequently, by the time accurate detection occurs, a bit of tone has = already leaked out. If you tune your DSP to be more aggressive at =20 removing tones, then you can get false positives and mute harmonics of = speech. I could go on, but I think you get the idea. i have seen these = =20 problems with Cisco H.323 gateways and AudioCodes gateways that a Cisco = =20 aquisition OEMed, so you can't convince me the problem doesn't exist. > Than, the INFO (or H.245) message is send to the target gateway, =20 > which will regenerate the DTMF to the PSTN side, without playing =20 > double digits. In H.323 it works already for few years. It works poorly enough that the ITU added support for RFC 2833 in H.323 = =20 v4 to combat this problem. thanks, -rohan > Nachum > > > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Tuesday, May 13, 2003 1:34 AM > To: SIP Developer > Cc: sipping@ietf.org; Attila Sipos; sip-implementors@cs.columbia.edu; = =20 > rizsanyi@neobee.net > Subject: Re: [Sipping] Re: [Sip-implementors] dtmf digits using INFO = > ... SIPauthors ... Can you answer please ? > > Hi Rohan, > > The main reason to not carry DTMF in SIP INFOs is that there = is =20 > a very > good chance that you will get double-digits or otherwise =20 > corrupted > digits because the signaling is not time-synchronized with the = =20 > audio > media. This issue is discussed in an expired draft which I =20 > wrote a > long time ago, which I abandoned in favor of the work = generated =20 > by the > app-interaction design team. At this point my draft is useful = > only in > that it explains how double digits tend to occur. > > my expired draft: > > =20 > http://www.softarmor.com/sipping/drafts/morgue/draft-mahy-sipping- > signaled-digits-01.html > > the app-interaction design team drafts: > > =20 > http://www.softarmor.com/sipping/drafts/draft-burger-sipping-kpml-=20 > 01.txt > =20 > http://www.softarmor.com/sipping/drafts/draft-culpepper-sipping-app- > interact-reqs-03.txt > =20 > http://www.softarmor.com/sipping/drafts/draft-jennings-sip-app-info- > 00.txt > =20 > http://www.softarmor.com/sipping/drafts/draft-rosenberg-sipping-app- > interaction-framework-00.txt > > > thanks, > -rohan (Mahy) > > > On Friday, May 9, 2003, at 11:05 AM, SIP Developer wrote: > >> Hi All, >> >> I hate to say that but SIP community doesn't agree >> or think that there are lots of use and requirement for carrying >> DTMF Out-of-Band. >> >> Every month, I can see that someone asks the same question again and >> again >> that how do we send DTMF via INFO and Out-Of-Band . >> >> 3pcc needs it, lots of service creation environment needs it and >> doesn't it looks promising to have a way in SIP to do OOB >> DTMF just like h245-alphanumeric in H.323. >> >> If we think of applications, then there are lots of them that I can >> count which doesn't care about the timing info carried by RFC2833. >> And if we really care about timing, then carrying RFC2833 via >> notify (Again OOB) is promising. >> >> I really do not understand if this is a political issue to not = promote >> SIP INFO for carrying DTMF or if someone can justify it to me >> that there is no use to carry DTMF OOB. >> >> SIP authors, can you answer why SIP INFO for carrying simple >> DTMF is not a standard solution ? >> >> Thanks, >> Rohan Kumar >> >> >> ----- Original Message ----- >> From: "Attila Sipos" >> To: ; >> Sent: Friday, May 09, 2003 9:50 AM >> Subject: RE: [Sip-implementors] dtmf digits using INFO >> >> >>> >>> Hello Zsolt, >>> >>> I still don't think there is a fully-agreed >>> standard. However, as much as I hate to say it, >>> CISCO have their own proposed standard which some >>> people (like us) interoperate with: >>> >>> >> http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/ >> 122newft/122 >>> t/122t11/ftinfo.htm >>> >>> Regards, >>> >>> Attila >>> >>> Attila Sipos >>> Software Engineer >>> >>> VegaStream : A World of difference for your Integrated = Communications >>> >>> (jo napot kiv=E1nok) >>> >>> >>> >>>> -----Original Message----- >>>> From: Rizsanyi Zsolt [mailto:rizsanyi@myrealbox.com] >>>> Sent: 09 May 2003 13:41 >>>> To: sip-implementors@cs.columbia.edu >>>> Subject: [Sip-implementors] dtmf digits using INFO >>>> >>>> >>>> Hi! >>>> >>>> Could somebody refer me to a current standard or draft, on >>>> how to send dtmf >>>> digits using the INFO method? >>>> >>>> Thanks >>>> Zsolt Rizsanyi >>>> >>>> _______________________________________________ >>>> Sip-implementors mailing list >>>> Sip-implementors@cs.columbia.edu >>>> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >>>> >>> >>> _______________________________________________ >>> Sip-implementors mailing list >>> Sip-implementors@cs.columbia.edu >>> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >>> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the 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-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors --__--__-- Message: 3 From: "Francois Audet" To: "'Rohan Mahy'" , "'Nachum Frid'" Cc: "'SIP Developer'" , "'sipping@ietf.org'" , "'Attila Sipos'" , "'sip-implementors@cs.columbia.edu'" = , "'rizsanyi@neobee.net'" Subject: RE: [Sipping] Re: [Sip-implementors] dtmf digits using INFO = ... S IPauthors ... Can you answer please ? Date: Tue, 13 May 2003 11:20:30 -0700 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. ------_=3D_NextPart_001_01C3197C.55FF4E20 The main reason for adding RFC2833 support in H.323v4 (despite the fact t= he earlier version supported long tones out-of-band) were: - Interoperability with systems that use RFC2833. (That means for example SIP-to-H.323) - IVR/Call center applications where time synchronization is necessary. (This applies to SIP as well of course). For example, you could have a "menu" item in a voice application where pressing a digit will cause a recording to stop. You could end on somebody's mailbox, where pressing "9= " would terminate your recording. If you press 9 and the recording is stopp= ed a couple of second later because the signalling message took longer to arrive, you could unwillingly record something you didn't want to record (like an insult).=20 Of course this doesn't mean that you'd always need RFC2833 in-band (the proof is that H.323 systems have been running for years), but there are indeed difficulties with the current VoIP systems and IVR/Call Center/Voicemail. The main problem is the transistion from out-of-band to RFC2833. > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com]=20 > Sent: Tuesday, May 13, 2003 09:56 > To: Nachum Frid > Cc: SIP Developer; sipping@ietf.org; Attila Sipos;=20 > sip-implementors@cs.columbia.edu; rizsanyi@neobee.net > Subject: Re: [Sipping] Re: [Sip-implementors] dtmf digits=20 > using INFO ... SIPauthors ... Can you answer please ? >=20 >=20 >=20 > On Tuesday, May 13, 2003, at 10:42 AM, Nachum Frid wrote: >=20 > > Rohan, > > > > In your draft you are describing the double DTMF problem: > > " > > Under this proposal, a User Agent MUST NOT send=20 > signaled digits > > or > > telephone-events using the INFO method if the=20 > event was ever > > represented as a tone (as media). Only signals=20 > originated =20 > > as pure > > signaling MAY generate an INFO method. Failure=20 > to heed this > > requirement will result in double-detection of=20 > digits/events > > > > If INFO is used incorrectly by a pair of PSTN gateways (for > > example), > > the source gateway may detect a digit, send an INFO request =20 > > which is lost, and retransmit that request. The target=20 > gateway would =20 > > send the > > original in-band tone to the PSTN when the audio=20 > media arrives, =20 > > later > > when the INFO arrives, the target gateway would=20 > render the same =20 > > tone > > again. It is quite likely that the INFO will arrive=20 > after the =20 > > media > > tone has been played (especially if multiple=20 > intermediaries are > > involved); the same digit would be played out again=20 > and this =20 > > will > > frequently cause systems in the PSTN to detect the same digit > > signaled twice." > > > > > > > > Most of the PSTN gateways we are familiar with (Cisco, =20 > > AudioCodes) will mute the DTMF signal, when they are=20 > configured to use =20 > > out of band DTMF(H.245 alphanumeric, or SIP INFO). Usually=20 > source =20 > > gateway will detect DTMF digit coming from the PSTN side=20 > and erase it =20 > > from the voice stream not relaying it to IP. >=20 > In my experience the muting/erasure is imprecise and=20 > imperfect at best. =20 > Frequently, by the time accurate detection occurs, a bit of=20 > tone has =20 > already leaked out. If you tune your DSP to be more aggressive at =20 > removing tones, then you can get false positives and mute=20 > harmonics of =20 > speech. I could go on, but I think you get the idea. i have=20 > seen these =20 > problems with Cisco H.323 gateways and AudioCodes gateways=20 > that a Cisco =20 > aquisition OEMed, so you can't convince me the problem doesn't exist. >=20 > > Than, the INFO (or H.245) message is send to the target gateway, =20 > > which will regenerate the DTMF to the PSTN side, without playing =20 > > double digits. In H.323 it works already for few years. >=20 > It works poorly enough that the ITU added support for RFC=20 > 2833 in H.323 =20 > v4 to combat this problem. >=20 > thanks, > -rohan >=20 >=20 > > Nachum > > > > > > -----Original Message----- > > From: Rohan Mahy [mailto:rohan@cisco.com] > > Sent: Tuesday, May 13, 2003 1:34 AM > > To: SIP Developer > > Cc: sipping@ietf.org; Attila Sipos;=20 > sip-implementors@cs.columbia.edu; =20 > > rizsanyi@neobee.net > > Subject: Re: [Sipping] Re: [Sip-implementors] dtmf digits=20 > using INFO =20 > > ... SIPauthors ... Can you answer please ? > > > > Hi Rohan, > > > > The main reason to not carry DTMF in SIP INFOs is=20 > that there is =20 > > a very > > good chance that you will get double-digits or otherwise =20 > > corrupted > > digits because the signaling is not=20 > time-synchronized with the =20 > > audio > > media. This issue is discussed in an expired draft which I =20 > > wrote a > > long time ago, which I abandoned in favor of the=20 > work generated =20 > > by the > > app-interaction design team. At this point my draft=20 > is useful =20 > > only in > > that it explains how double digits tend to occur. > > > > my expired draft: > > > > =20 > > http://www.softarmor.com/sipping/drafts/morgue/draft-mahy-sipping- > > signaled-digits-01.html > > > > the app-interaction design team drafts: > > > > =20 > > http://www.softarmor.com/sipping/drafts/draft-burger-sipping-kpml-=20 > > 01.txt > > =20 > > http://www.softarmor.com/sipping/drafts/draft-culpepper-sipping-app- > > interact-reqs-03.txt > > =20 > > http://www.softarmor.com/sipping/drafts/draft-jennings-sip-app-info- > > 00.txt > > =20 > > http://www.softarmor.com/sipping/drafts/draft-rosenberg-sipping-app- > > interaction-framework-00.txt > > > > > > thanks, > > -rohan (Mahy) > > > > > > On Friday, May 9, 2003, at 11:05 AM, SIP Developer wrote: > > > >> Hi All, > >> > >> I hate to say that but SIP community doesn't agree > >> or think that there are lots of use and requirement for carrying > >> DTMF Out-of-Band. > >> > >> Every month, I can see that someone asks the same question=20 > again and > >> again > >> that how do we send DTMF via INFO and Out-Of-Band . > >> > >> 3pcc needs it, lots of service creation environment needs it and > >> doesn't it looks promising to have a way in SIP to do OOB > >> DTMF just like h245-alphanumeric in H.323. > >> > >> If we think of applications, then there are lots of them=20 > that I can > >> count which doesn't care about the timing info carried by RFC2833. > >> And if we really care about timing, then carrying RFC2833 via > >> notify (Again OOB) is promising. > >> > >> I really do not understand if this is a political issue to=20 > not promote > >> SIP INFO for carrying DTMF or if someone can justify it to me > >> that there is no use to carry DTMF OOB. > >> > >> SIP authors, can you answer why SIP INFO for carrying simple > >> DTMF is not a standard solution ? > >> > >> Thanks, > >> Rohan Kumar > >> > >> > >> ----- Original Message ----- > >> From: "Attila Sipos" > >> To: ; > >> Sent: Friday, May 09, 2003 9:50 AM > >> Subject: RE: [Sip-implementors] dtmf digits using INFO > >> > >> > >>> > >>> Hello Zsolt, > >>> > >>> I still don't think there is a fully-agreed > >>> standard. However, as much as I hate to say it, > >>> CISCO have their own proposed standard which some > >>> people (like us) interoperate with: > >>> > >>> > >> http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/ > >> 122newft/122 > >>> t/122t11/ftinfo.htm > >>> > >>> Regards, > >>> > >>> Attila > >>> > >>> Attila Sipos > >>> Software Engineer > >>> > >>> VegaStream : A World of difference for your Integrated=20 > Communications > >>> > >>> (jo napot kiv=E1nok) > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Rizsanyi Zsolt [mailto:rizsanyi@myrealbox.com] > >>>> Sent: 09 May 2003 13:41 > >>>> To: sip-implementors@cs.columbia.edu > >>>> Subject: [Sip-implementors] dtmf digits using INFO > >>>> > >>>> > >>>> Hi! > >>>> > >>>> Could somebody refer me to a current standard or draft, on > >>>> how to send dtmf > >>>> digits using the INFO method? > >>>> > >>>> Thanks > >>>> Zsolt Rizsanyi > >>>> > >>>> _______________________________________________ > >>>> Sip-implementors mailing list > >>>> Sip-implementors@cs.columbia.edu > >>>> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > >>>> > >>> > >>> _______________________________________________ > >>> Sip-implementors mailing list > >>> Sip-implementors@cs.columbia.edu > >>> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > >>> > >> _______________________________________________ > >> Sipping mailing list =20 > https://www1.ietf.org/mailman/listinfo/sipp> ing > >> This list=20 > is for NEW development of the application=20 > of SIP > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sip@ietf.org for new developments of core SIP > > > > > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@cs.columbia.edu > > =20 > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP ------_=3D_NextPart_001_01C3197C.55FF4E20 [Enclosed text/html ] -----Original Message-----
> > From: Rohan Mahy [ HREF=3D3D"mailto:rohan@cisco.com">mailto:rohan@cisco.com]
> > Sent: Tuesday, May 13, 2003 1:34 = AM
> > To: SIP Developer
> > Cc: sipping@ietf.org; Attila Sipos; =3D
> sip-implementors@cs.columbia.edu;  =
> > rizsanyi@neobee.net
> > Subject: Re: [Sipping] Re: =3D [Sip-implementors] dtmf digits
> using INFO 
> > ... SIPauthors ... Can you answer please = =3D ?
> >
> = >        =3D Hi Rohan,
> >
> = >        =3D The main reason to not carry DTMF in SIP INFOs is
> that there is 
> > a very
> = >        =3D good chance that you will get double-digits or otherwise 
> > corrupted
> = >        =3D digits because the signaling is not
> time-synchronized with the 
> > audio
> = >        =3D media.  This issue is discussed in an expired draft which I  = =3D
> > wrote a
> = >        =3D long time ago, which I abandoned in favor of the
> work generated 
> > by the
> = >        =3D app-interaction design team. At this point my draft
> is useful 
> > only in
> = >        =3D that it explains how double digits tend to occur.
> >
> = >        =3D my expired draft:
> >
> =3D >        
> > HREF=3D3D"http://www.softarmor.com/sipping/drafts/morgue/draft-mahy-sipp= in=3D g-" =3D TARGET=3D3D"_blank">http://www.softarmor.com/sipping/drafts/morgue/draft= -m=3D ahy-sipping-
> = >        =3D signaled-digits-01.html
> >
> = >        =3D the app-interaction design team drafts:
> >
> =3D >        
> > HREF=3D3D"http://www.softarmor.com/sipping/drafts/draft-burger-sipping-k= pm=3D l-" =3D TARGET=3D3D"_blank">http://www.softarmor.com/sipping/drafts/draft-burger= -s=3D ipping-kpml-
> > 01.txt
> =3D >        
> > HREF=3D3D"http://www.softarmor.com/sipping/drafts/draft-culpepper-sippin= g-=3D app-" =3D TARGET=3D3D"_blank">http://www.softarmor.com/sipping/drafts/draft-culpep= pe=3D r-sipping-app-
> = >        =3D interact-reqs-03.txt
> =3D >        
> > HREF=3D3D"http://www.softarmor.com/sipping/drafts/draft-jennings-sip-app= -i=3D nfo-" =3D TARGET=3D3D"_blank">http://www.softarmor.com/sipping/drafts/draft-jennin= gs=3D -sip-app-info-
> = >        =3D 00.txt
> =3D >        
> > HREF=3D3D"http://www.softarmor.com/sipping/drafts/draft-rosenberg-sippin= g-=3D app-" =3D TARGET=3D3D"_blank">http://www.softarmor.com/sipping/drafts/draft-rosenb= er=3D g-sipping-app-
> = >        =3D interaction-framework-00.txt
> >
> >
> = >        =3D thanks,
> = >        =3D -rohan (Mahy)
> >
> >
> = >        =3D On Friday, May 9, 2003, at 11:05 AM, SIP Developer wrote:
> >
> >> Hi All,
> >>
> >> I hate to say that but SIP community = =3D doesn't agree
> >> or think that there are lots of use = =3D and requirement for carrying
> >> DTMF Out-of-Band.
> >>
> >> Every month, I can see that someone = =3D asks the same question
> again and
> >> again
> >> that how do we send DTMF via INFO = and =3D Out-Of-Band .
> >>
> >> 3pcc needs it, lots of service =3D creation environment needs it and
> >> doesn't it looks promising to have a = =3D way in SIP to do OOB
> >> DTMF just like h245-alphanumeric in = =3D H.323.
> >>
> >> If we think of applications,  = =3D then there are lots of them
> that I can
> >> count which doesn't care about the = =3D timing info carried by RFC2833.
> >> And if we really care about timing, = =3D then carrying RFC2833 via
> >> notify (Again OOB) is =3D promising.
> >>
> >> I really do not understand if this = is =3D a political issue to
> not promote
> >> SIP INFO for carrying DTMF or if =3D someone can justify it to me
> >> that there is no use to carry DTMF = =3D OOB.
> >>
> >> SIP authors, can you answer why SIP = =3D INFO for carrying simple
> >> DTMF is not a standard solution =3D ?
> >>
> >> Thanks,
> >> Rohan Kumar
> >>
> >>
> >> ----- Original Message -----
> >> From: "Attila Sipos" =3D <AttilaS@vegastream.com>
> >> To: <rizsanyi@neobee.net>; =3D <sip-implementors@cs.columbia.edu>
> >> Sent: Friday, May 09, 2003 9:50 =3D AM
> >> Subject: RE: [Sip-implementors] dtmf = =3D digits using INFO
> >>
> >>
> >>>
> >>> Hello Zsolt,
> >>>
> >>> I still don't think there is a = =3D fully-agreed
> >>> standard.  However, as much = =3D as I hate to say it,
> >>> CISCO have their own proposed = =3D standard which some
> >>> people (like us) interoperate = =3D with:
> >>>
> >>>
> >> HREF=3D3D"http://www.cisco.com/univercd/cc/td/doc/product/software/ios12= 2/=3D " =3D TARGET=3D3D"_blank">http://www.cisco.com/univercd/cc/td/doc/product/soft= wa=3D re/ios122/
> >> 122newft/122
> >>> t/122t11/ftinfo.htm
> >>>
> >>> Regards,
> >>>
> >>> Attila
> >>>
> >>> Attila Sipos
> >>> Software Engineer
> >>> < HREF=3D3D"http://www.vegastream.com" =3D TARGET=3D3D"_blank">http://www.vegastream.com>
> >>> VegaStream : A World of = difference =3D for your Integrated
> Communications
> >>>
> >>> (jo napot kiv=3DE1nok)
> >>>
> >>>
> >>>
> >>>> -----Original =3D Message-----
> >>>> From: Rizsanyi Zsolt [ HREF=3D3D"mailto:rizsanyi@myrealbox.com">mailto:rizsanyi@myrealbox.com A>=3D ] > >>>> Sent: 09 May 2003 = 13:41 > >>>> To: =3D sip-implementors@cs.columbia.edu > >>>> Subject: [Sip-implementors] = =3D dtmf digits using INFO > >>>> > >>>> > >>>> Hi! > >>>> > >>>> Could somebody refer me to a = =3D current standard or draft, on > >>>> how to send dtmf > >>>> digits using the INFO =3D method? > >>>> > >>>> Thanks > >>>> Zsolt Rizsanyi > >>>> > >>>> =3D _______________________________________________ > >>>> Sip-implementors mailing =3D list > >>>> =3D Sip-implementors@cs.columbia.edu > >>>> HREF=3D3D"http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors= " =3D TARGET=3D3D"_blank">http://lists.cs.columbia.edu/mailman/listinfo/sip-im= pl=3D ementors
> >>>>
> >>>
> >>> =3D _______________________________________________
> >>> Sip-implementors mailing =3D list
> >>> =3D Sip-implementors@cs.columbia.edu
> >>> HREF=3D3D"http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors= " =3D TARGET=3D3D"_blank">http://lists.cs.columbia.edu/mailman/listinfo/sip-im= pl=3D ementors
> >>>
> >> =3D _______________________________________________
> >> Sipping mailing list 
> HREF=3D3D"https://www1.ietf.org/mailman/listinf=3D o/sipp" =3D TARGET=3D3D"_blank">https://www1.ietf.org/mailman/listinfo/sipp> = =3D ing
> >> This list
> is for NEW development of the application =3D
> of SIP
> >> Use sip-implementors@cs.columbia.edu = =3D for questions on current sip
> >> Use sip@ietf.org for new = developments =3D of core SIP
> >
> >
> = >        =3D _______________________________________________
> = >        =3D Sip-implementors mailing list
> = >        =3D Sip-implementors@cs.columbia.edu
> = >        =3D
> HREF=3D3D"http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors= " =3D TARGET=3D3D"_blank">http://lists.cs.columbia.edu/mailman/listinfo/sip-im= pl=3D ementors


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

------_=3D_NextPart_001_01C3197C.55FF4E20-- --__--__-- Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP End of Sipping Digest _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP 16-May-2003 04:25:56 -0500,8877;000000000000-00000b1b Received: via dmail-2000(11) for +imap/ietf/SIPPING; Fri, 16 May 2003 = 04:25:56 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4G9Pn6n030048 for ; Fri, 16 May 2003 04:25:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4G8a2B24207; Fri, 16 May 2003 04:36: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 h4DFSxB03323 for ; Tue, 13 May 2003 11:28: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 MAA18199; Tue, 13 May 2003 12:02:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FcGK-0005Qv-00; Tue, 13 May 2003 12:04:20 -0400 Received: from tssg.wit.ie ([193.1.185.11] helo=3Dmail.tssg.org) by ietf-mx with esmtp (Exim 4.12) id 19FcGI-0005Qq-00; Tue, 13 May 2003 12:04:18 -0400 Received: from boolard (unknown [10.37.1.56]) by mail.tssg.org (Postfix) with SMTP id 0C3131809A; Tue, 13 May 2003 17:05:54 +0100 (IST) From: "Shane McCormack" To: "Sipping@Ietf. Org" , "Sip@Ietf. Org" = Date: Tue, 13 May 2003 17:09:48 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=3D"----=3D_NextPart_000_001F_01C31972.75B44360" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [Sipping] PIDF format for spatial location Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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-Spam-Status: No, hits=3D-5.5 required=3D5.0 tests=3DHTML_60_70,HTML_MESSAGE,MSGID_GOOD_EXCHANGE version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) This is a multi-part message in MIME format. ------=3D_NextPart_000_001F_01C31972.75B44360 Hi, I have mailed the list before on this subject but I am still looking = for a bit more clarification on this subject. I need to retreive spatial = location in pidf format for work I am doing on my thesis. I know that work is being done in the Geopriv working group on a format = for sending such information. Just as a matter of doing things correctly = could somebody with any knowledge help me in by telling me the additional headers necessary, and any other thoughts = so i can put the correct information in my implementation and my thesis. Thank you 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 ------=3D_NextPart_000_001F_01C31972.75B44360 [Enclosed text/html ] ------=3D_NextPart_000_001F_01C31972.75B44360-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP 16-May-2003 04:26:56 -0500,3564;000000000000-00000b1c Received: via dmail-2000(11) for +imap/ietf/SIPPING; Fri, 16 May 2003 = 04:26:56 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4G9Qn6n030064 for ; Fri, 16 May 2003 04:26:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4G8a8B24247; Fri, 16 May 2003 04:36: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 h4FDmNB02422 for ; Thu, 15 May 2003 09: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 KAA10580 for ; Thu, 15 May 2003 10:20:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GJd7-0007Wj-00 for sipping@ietf.org; Thu, 15 May 2003 10:22:45 -0400 Received: from smtp2.dataconnection.com ([192.91.191.8] = helo=3Dmiles.dataconnection.com) by ietf-mx with esmtp (Exim 4.12) id 19GJd6-0007Wg-00 for sipping@ietf.org; Thu, 15 May 2003 10:22:44 -0400 Received: by miles.datcon.co.uk with Internet Mail Service = (5.5.2656.59) id ; Thu, 15 May 2003 15:23:22 +0100 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F8B8E539@baker.datcon.co.uk> From: Nicole Johnson To: "'sipping@ietf.org'" Date: Thu, 15 May 2003 15:23:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset=3D"iso-8859-1" Subject: [Sipping] [Sipping]Questions on = draft-ietf-sipping-connect-reuse-reqs-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: , X-Spam-Status: No, hits=3D0.8 required=3D5.0 tests=3DSUBJ_HAS_UNIQ_ID version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) I have a couple of questions about = draft-ietf-sipping-connect-reuse-reqs-00. 1. Intended scope of alias parameter. =20 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? 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 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?=20 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 16-May-2003 06:43:16 -0500,5772;000000000000-00000b1d Received: via dmail-2000(11) for +imap/ietf/SIPPING; Fri, 16 May 2003 = 06:43:16 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4GBh96n030837 for ; Fri, 16 May 2003 06:43:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GAs8B32749; Fri, 16 May 2003 06:54: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 h4GAolB32572 for ; Fri, 16 May 2003 06:50:47 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19539; Fri, 16 May 2003 07:22:48 -0400 (EDT) Message-Id: <200305161122.HAA19539@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=3D"NextPart" To: IETF-Announce: ; Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 16 May 2003 07:22:48 -0400 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-req-history-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: , X-Spam-Status: No, hits=3D2.2 required=3D5.0 tests=3DMIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=3D2.52 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) --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 : SIP Generic Request History Capability =FB Requirements Author(s) : M. Barnes et al. Filename : draft-ietf-sipping-req-history-03.txt Pages : 12 Date : 2003-5-15 =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-03.tx= t 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-ietf-sipping-req-history-03.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-03.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 --OtherAccess [Enclosed Message/External-body ] --OtherAccess [Enclosed Message/External-body 3D] --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 16-May-2003 08:38:45 -0500,3724;000000000000-00000b1e Received: via dmail-2000(11) for +imap/ietf/SIPPING; Fri, 16 May 2003 = 08:38:45 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4GDcY6n031679 for ; Fri, 16 May 2003 08:38:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GCj5B07772; Fri, 16 May 2003 08:45: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 h4GCi2B07668 for ; Fri, 16 May 2003 08:44:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22115 for ; Fri, 16 May 2003 09:16:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Gf5u-0006dQ-00 for sipping@ietf.org; Fri, 16 May 2003 09:17:54 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19Gf5t-0006bN-00 for sipping@ietf.org; Fri, 16 May 2003 09:17:53 -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 h4GDITkL022547 for ; Fri, 16 May 2003 09:18:29 -0400 (EDT) Received: from cisco.com ([161.44.79.220]) by cannon.cisco.com (Mirapoint) with ESMTP id ABJ23730; Fri, 16 May 2003 09:27:23 -0400 (EDT) Message-ID: <3EC4E526.9040306@cisco.com> Date: Fri, 16 May 2003 09:18:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) = Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping@ietf.org Subject: Re: [Sipping] I-D ACTION:draft-ietf-sipping-req-history-03.txt References: <200305161122.HAA19539@ietf.org> Content-Type: text/plain; charset=3Dus-ascii; format=3Dflowed 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: , X-Spam-Status: No, hits=3D-12.4 required=3D5.0 tests=3DREFERENCES,USER_AGENT_MOZILLA_UA autolearn=3Dham version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) I would like to take some issue with the voicemail example 10.2: For this to work in any meaningful way, UA-A and UA-B must both use=20 UA-VM as their voicemail server. While this may be a reasonable=20 assumption in cases where both get phone service from the same = provider,=20 it certainly doesn't work in all useful cases. For instance it doesn't=20 work if a call is forwarded from a business phone to a home phone. I think at a minimum the limitations of this approach should be=20 mentioned. (Better would be to simply decide this is a poor application = of History and remove the example.) Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP 16-May-2003 09:09:08 -0500,5188;000000000000-00000b1f Received: via dmail-2000(11) for +imap/ietf/SIPPING; Fri, 16 May 2003 = 09:09:08 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4GE906n031903 for ; Fri, 16 May 2003 09:09:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GDK4B10469; Fri, 16 May 2003 09:20: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 h4GDJaB10412 for ; Fri, 16 May 2003 09:19: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 JAA24699 for ; Fri, 16 May 2003 09:51:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GfeK-0007QD-00 for sipping@ietf.org; Fri, 16 May 2003 09:53:28 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19GfeJ-0007Pg-00 for sipping@ietf.org; Fri, 16 May 2003 09:53:27 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com = [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP = id h4GDrtf06312; Fri, 16 May 2003 08:53:56 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service = (5.5.2653.19) id ; Fri, 16 May 2003 08:53:56 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A09DABDCD@zrc2c000.us.nortel= .com> From: "Mary Barnes" To: "'Paul Kyzivat'" , sipping@ietf.org Subject: RE: [Sipping] I-D ACTION:draft-ietf-sipping-req-history-03.txt Date: Fri, 16 May 2003 08:53:54 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Status: No, hits=3D-3.1 required=3D5.0 tests=3DORIGINAL_MESSAGE autolearn=3Dham version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) Paul, Your point is well taken. There is a statement upfront around the limitations of the examples in the appendix, but I should probably re-iterate that in section 10 and explicitly highlight the limitations = of the scenario in 10.2 as to under which situations it might work like = this. I would like to keep this example, as I do think it is illustrative of = where one could use the request history capability. It wasn't at all the intention to be a prescriptive description of Voicemail services (which = is some of the wording I have in the last section of paragraph 1, which I = will re-emphasize in the appendix). Although, for the forwarding to home, I = would still think that it's a local policy decision at the proxy as to which = VM it would go to and that if you had forwarded to home that it would still = go to your office VM, which I think is consistent with the wording under the example. However, I can see that some of the wording likely ought to be changed as it is being too prescriptive around the service (and perhaps = your primary point), so I will also reword the text under the example flow. = =20 Thanks for your input, Mary. =20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Friday, May 16, 2003 8:19 AM To: sipping@ietf.org Subject: Re: [Sipping] I-D ACTION:draft-ietf-sipping-req-history-03.txt I would like to take some issue with the voicemail example 10.2: For this to work in any meaningful way, UA-A and UA-B must both use=20 UA-VM as their voicemail server. While this may be a reasonable=20 assumption in cases where both get phone service from the same = provider,=20 it certainly doesn't work in all useful cases. For instance it doesn't=20 work if a call is forwarded from a business phone to a home phone. I think at a minimum the limitations of this approach should be=20 mentioned. (Better would be to simply decide this is a poor application = of History and remove the example.) Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP 16-May-2003 12:32:06 -0500,4240;000000000000-00000b20 Received: via dmail-2000(11) for +imap/ietf/SIPPING; Fri, 16 May 2003 = 12:32:06 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4GHVu6n004105 for ; Fri, 16 May 2003 12:31:57 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GGkTB27686; Fri, 16 May 2003 12:46: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 h4GGjxB27667 for ; Fri, 16 May 2003 12:45: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 NAA03724 for ; Fri, 16 May 2003 13:17:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Giry-0001U9-00 for sipping@ietf.org; Fri, 16 May 2003 13:19:46 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by ietf-mx with esmtp (Exim 4.12) id 19Girx-0001U1-00 for sipping@ietf.org; Fri, 16 May 2003 13:19:46 -0400 Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com = [161.44.118.24]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h4GHKQJh022652; Fri, 16 May 2003 13:20:26 -0400 (EDT) Received: from cisco.com ([161.44.79.220]) by cannon.cisco.com (Mirapoint) with ESMTP id ABJ25991; Fri, 16 May 2003 13:29:17 -0400 (EDT) Message-ID: <3EC51DD9.5050407@cisco.com> Date: Fri, 16 May 2003 13:20:25 -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: Mary Barnes CC: sipping@ietf.org Subject: Re: [Sipping] I-D ACTION:draft-ietf-sipping-req-history-03.txt References: = <1B54FA3A2709D51195C800508BF9386A09DABDCD@zrc2c000.us.nortel.com> Content-Type: text/plain; charset=3Dus-ascii; format=3Dflowed 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: , X-Spam-Status: No, hits=3D-28.6 required=3D5.0 tests=3DEMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=3Dham version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) Mary Barnes wrote: >=20 > Although, for the forwarding to home, I would > still think that it's a local policy decision at the proxy as to = which VM it > would go to and that if you had forwarded to home that it would still = go to > your office VM, which I think is consistent with the wording under = the > example.=20 Just to make sure we are making exactly the same point: the example has the forwardee sending the request to the particular=20 voicemail server it deals with. Then that server is using the history=20 info to decide which of its mailboxes to use. In the office to home=20 case, home and office phones probably use different voicemail servers.=20 The voicemail server used at home will likely not contain a mailbox for = the office address. History just doesn't enter into a solution to this problem. Instead, = the=20 home phone must not go to voicemail. It must fail back to the proxy for = the office phone, which can then choose its own voicemail server and=20 mailbox. Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP 16-May-2003 17:14:49 -0500,4974;000000000001-00000b21 Received: via dmail-2000(11) for +imap/ietf/SIPPING; Fri, 16 May 2003 = 17:14:49 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4GMEe6n008950 for ; Fri, 16 May 2003 17:14:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GLUTB14778; Fri, 16 May 2003 17:30: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 h4GLTPB14724 for ; Fri, 16 May 2003 17:29: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 SAA11899 for ; Fri, 16 May 2003 18:00:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GnHw-0003Dx-00 for sipping@ietf.org; Fri, 16 May 2003 18:02:52 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19GnHq-0003DX-00 for sipping@ietf.org; Fri, 16 May 2003 18:02:46 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com = [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP = id h4GM2lf26601; Fri, 16 May 2003 17:02:47 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service = (5.5.2653.19) id ; Fri, 16 May 2003 17:02:48 -0500 Message-ID: = <1B54FA3A2709D51195C800508BF9386A09DABDD6@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Paul Kyzivat'" Cc: sipping@ietf.org Subject: Example 10.2 - should we remove it? (was RE: [Sipping] I-D = ACTIO N:draft-ietf-sipping-req-history-03.txt Date: Fri, 16 May 2003 17:02:47 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-Spam-Status: No, hits=3D-12.8 required=3D5.0 tests=3DEMAIL_ATTRIBUTION,ORIGINAL_MESSAGE,QUOTED_EMAIL_TEXT autolearn=3Dham version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) Paul, I agree for the scenario whereby there is a VM server at home, you = likely wouldn't need History-Info. This example, with the current = introductory wording, is clearly restricted to a single VM server in an enterprise environment. So, perhaps your original suggestion to remove the = example altogether is well-taken. =20 Are there any other views? Everytime we've discussed this particular example, the discussion has ratholed, so I don't want to digress into = that, but rather would like feedback on whether anyone has any problems with removing this particular example? (We do have more flows in the = solutions document, as well, making them not nearly as useful as they were originally). =20 Mary.=20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Friday, May 16, 2003 12:20 PM To: Barnes, Mary [NGC:B602:EXCH] Cc: sipping@ietf.org Subject: Re: [Sipping] I-D ACTION:draft-ietf-sipping-req-history-03.txt Mary Barnes wrote: >=20 > Although, for the forwarding to home, I would > still think that it's a local policy decision at the proxy as to = which VM it > would go to and that if you had forwarded to home that it would still = go to > your office VM, which I think is consistent with the wording under = the > example.=20 Just to make sure we are making exactly the same point: the example has the forwardee sending the request to the particular=20 voicemail server it deals with. Then that server is using the history=20 info to decide which of its mailboxes to use. In the office to home=20 case, home and office phones probably use different voicemail servers.=20 The voicemail server used at home will likely not contain a mailbox for = the office address. History just doesn't enter into a solution to this problem. Instead, = the=20 home phone must not go to voicemail. It must fail back to the proxy for = the office phone, which can then choose its own voicemail server and=20 mailbox. Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP 19-May-2003 00:01:33 -0500,7574;000000000000-00000b22 Received: via dmail-2000(11) for +imap/ietf/SIPPING; Mon, 19 May 2003 = 00:01:33 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4J51Q6n005977 for ; Mon, 19 May 2003 00:01:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J4HjB00434; Mon, 19 May 2003 00: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 h4J48TB32631 for ; Mon, 19 May 2003 00:08:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25213; Mon, 19 May 2003 00:39:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HcSG-0007AU-00; Mon, 19 May 2003 00:40:56 -0400 Received: from f81.law12.hotmail.com ([64.4.19.81] helo=3Dhotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19HcSF-00079v-00; Mon, 19 May 2003 00:40:56 -0400 Received: from mail pickup service by hotmail.com with Microsoft = SMTPSVC; Sun, 18 May 2003 21:41:42 -0700 Received: from 193.220.224.9 by lw12fd.law12.hotmail.msn.com with HTTP; Mon, 19 May 2003 04:41:41 GMT X-Originating-IP: [193.220.224.9] X-Originating-Email: [rajarshi_chakraborty@hotmail.com] From: "Rajarshi Chakraborty" To: drage@lucent.com, ashishn@mahindrabt.com, = asanth01@sprintspectrum.com, sip@ietf.org Cc: sipping@ietf.org Date: Mon, 19 May 2003 04:41:41 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=3Dflowed Message-ID: X-OriginalArrivalTime: 19 May 2003 04:41:42.0365 (UTC) = FILETIME=3D[F1C4F8D0:01C31DC0] Subject: [Sipping] SIP mobility in WLAN Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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-Spam-Status: No, hits=3D0.4 required=3D5.0 tests=3DMAILTO_TO_SPAM_ADDR version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) 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=20 too trivial to be addressed specially? I am specially interested in=20 situations of handoffs (in this case, the IP changes as soon as the = host=20 shifts from the zone around one hotspot to another). Should SIP bother = at=20 all to detect IP changes or should the control be completely outside = SIP? I=20 mean should it be some other module that has the responsibility of = informing=20 the SIP stack in the mobile host about the IP changes, so that the host = may=20 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]"=20 , "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=20 reference to 3GPP TS 23.002 to see how these entities fit together into = the=20 entire 3GPP architecture. The SIP protocol application is covered in 3GPP TS 24.229 with example = flows=20 in 3GPP TS 24.228. These documents may be found at: ftp://ftp.3gpp.org/Specs/latest/Rel-5/=20 3GPP uses these specifications over GPRS to provide mobility. There is a parallel set of 3GPP2 specifications, substantially of = common=20 text, that uses the same architecture over mobile IP, instead of GPRS. = These=20 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=20 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,=20 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=20 up for this ? > This has been addressed in 3GPP standards. Please refer to the 3GPP = All=20 IP architecture specifications. SIP is said to be a better alternative than Mobile IP. Can I have some=20 latest development document references ? > SIP is not going to replace Mobile IP. It is going to leverage = Mobile IP=20 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/=20 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 19-May-2003 02:41:28 -0500,2687;000000000001-00000b23 Received: via dmail-2000(11) for +imap/ietf/SIPPING; Mon, 19 May 2003 = 02:41:28 -0500 (CDT) Return-Path: Received: from mail3.dynamicsoft.com ([63.113.44.69]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4J7fH6n006823 for ; Mon, 19 May 2003 02:41:17 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h4J7eMdh014224; Mon, 19 May 2003 03:40:23 -0400 (EDT) Message-ID: <3EC88A61.1020405@dynamicsoft.com> Date: Mon, 19 May 2003 03:40:17 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) = Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juha Heinanen CC: "Peterson, Jon" , "'Conroy, Lawrence (SMTP)'" , Rohan Mahy = , "'sipping@ietf.org'" , bcampbell@dynamicsoft.com, "'Dean Willis'" , = gonzalo.Camarillo@ericsson.com Subject: Re: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt References: = <0449D80A0E9B614A83FA9031B07E8D3B257A78@stntexch2.va.neustar.com> = <16067.37072.865297.570579@harjus.eng.song.fi> In-Reply-To: <16067.37072.865297.570579@harjus.eng.song.fi> Content-Type: text/plain; charset=3Dus-ascii; format=3Dflowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=3D-31.9 required=3D5.0 tests=3DEMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=3Dham version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) Juha Heinanen wrote: > Peterson, Jon writes: >=20 > > I don't > > think it is too much to ask that SIP applications utilizing ENUM = be generous > > in what they receive with regard to enumservices - it just = doesn't seem > > costly to be backwards compatible with the original iteration of = the ENUM > > standard. >=20 > check, for example, with cisco and let me know when they accept enum > replies with both formats. today they don't which is a very big > problem.=20 Sounds like a good reason to document that you should be supporting=20 both. I think recommending that has only benefits and no drawbacks. -Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com 19-May-2003 02:51:23 -0500,4445;000000000000-00000b24 Received: via dmail-2000(11) for +imap/ietf/SIPPING; Mon, 19 May 2003 = 02:51:23 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4J7pC6n006874 for ; Mon, 19 May 2003 02:51:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J789B23721; Mon, 19 May 2003 03:08: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 h4J77GB23160 for ; Mon, 19 May 2003 03:07:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10877 for ; Mon, 19 May 2003 03:37:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HfFI-0000mB-00 for sipping@ietf.org; Mon, 19 May 2003 03:39:44 -0400 Received: from [63.113.44.69] (helo=3Dmail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19HfFI-0000lf-00 for sipping@ietf.org; Mon, 19 May 2003 03:39:44 -0400 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h4J7eMdh014224; Mon, 19 May 2003 03:40:23 -0400 (EDT) Message-ID: <3EC88A61.1020405@dynamicsoft.com> Date: Mon, 19 May 2003 03:40:17 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) = Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juha Heinanen CC: "Peterson, Jon" , "'Conroy, Lawrence (SMTP)'" , Rohan Mahy = , "'sipping@ietf.org'" , bcampbell@dynamicsoft.com, "'Dean Willis'" , = gonzalo.Camarillo@ericsson.com Subject: Re: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt References: = <0449D80A0E9B614A83FA9031B07E8D3B257A78@stntexch2.va.neustar.com> = <16067.37072.865297.570579@harjus.eng.song.fi> In-Reply-To: <16067.37072.865297.570579@harjus.eng.song.fi> Content-Type: text/plain; charset=3Dus-ascii; format=3Dflowed 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: , X-Spam-Status: No, hits=3D-37.7 required=3D5.0 tests=3DEMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_LONG_SPARSE, USER_AGENT_MOZILLA_UA version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) Juha Heinanen wrote: > Peterson, Jon writes: >=20 > > I don't > > think it is too much to ask that SIP applications utilizing ENUM = be generous > > in what they receive with regard to enumservices - it just = doesn't seem > > costly to be backwards compatible with the original iteration of = the ENUM > > standard. >=20 > check, for example, with cisco and let me know when they accept enum > replies with both formats. today they don't which is a very big > problem.=20 Sounds like a good reason to document that you should be supporting=20 both. I think recommending that has only benefits and no drawbacks. -Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP 19-May-2003 02:53:54 -0500,2027;000000000001-00000b25 Received: via dmail-2000(11) for +imap/ietf/SIPPING; Mon, 19 May 2003 = 02:53:54 -0500 (CDT) Return-Path: Received: from harjus.eng.song.fi (mail@harjus.eng.song.fi = [195.10.149.20]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4J7rl6n006891 for ; Mon, 19 May 2003 02:53:48 -0500 Received: from jh by harjus.eng.song.fi with local (Exim 3.35 #1 = (Debian)) id 19HfSR-0000ev-00; Mon, 19 May 2003 10:53:19 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=3Dus-ascii Content-Transfer-Encoding: 7bit Message-ID: <16072.36207.874392.484051@harjus.eng.song.fi> Date: Mon, 19 May 2003 10:53:19 +0300 To: Jonathan Rosenberg Cc: "Peterson, Jon" , "'Conroy, Lawrence (SMTP)'" , Rohan Mahy = , "'sipping@ietf.org'" , bcampbell@dynamicsoft.com, "'Dean Willis'" , = gonzalo.Camarillo@ericsson.com Subject: Re: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt In-Reply-To: <3EC88A61.1020405@dynamicsoft.com> References: = <0449D80A0E9B614A83FA9031B07E8D3B257A78@stntexch2.va.neustar.com> <16067.37072.865297.570579@harjus.eng.song.fi> <3EC88A61.1020405@dynamicsoft.com> X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen X-Spam-Status: No, hits=3D-28.6 required=3D5.0 tests=3DEMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_VM autolearn=3Dham version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) Jonathan Rosenberg writes: > Sounds like a good reason to document that you should be supporting=20 > both. I think recommending that has only benefits and no drawbacks. yes, we have way passed the point where the "old" service field format need not be supported. because the "old" format must be supported for ever, the question raises: why does it make sense to define the new format at all. -- juha 19-May-2003 03:04:05 -0500,3738;000000000001-00000b26 Received: via dmail-2000(11) for +imap/ietf/SIPPING; Mon, 19 May 2003 = 03:04:05 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4J83x6n006999 for ; Mon, 19 May 2003 03:03:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J7L8B24350; Mon, 19 May 2003 03:21: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 h4J7K1B24308 for ; Mon, 19 May 2003 03:20: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 DAA11178 for ; Mon, 19 May 2003 03:50:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HfRd-0000rZ-00 for sipping@ietf.org; Mon, 19 May 2003 03:52:29 -0400 Received: from harjus.eng.song.fi ([195.10.149.20] ident=3Dmail) by ietf-mx with esmtp (Exim 4.12) id 19HfRc-0000rW-00 for sipping@ietf.org; Mon, 19 May 2003 03:52:28 -0400 Received: from jh by harjus.eng.song.fi with local (Exim 3.35 #1 = (Debian)) id 19HfSR-0000ev-00; Mon, 19 May 2003 10:53:19 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=3Dus-ascii Content-Transfer-Encoding: 7bit Message-ID: <16072.36207.874392.484051@harjus.eng.song.fi> Date: Mon, 19 May 2003 10:53:19 +0300 To: Jonathan Rosenberg Cc: "Peterson, Jon" , "'Conroy, Lawrence (SMTP)'" , Rohan Mahy = , "'sipping@ietf.org'" , bcampbell@dynamicsoft.com, "'Dean Willis'" , = gonzalo.Camarillo@ericsson.com Subject: Re: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt In-Reply-To: <3EC88A61.1020405@dynamicsoft.com> References: = <0449D80A0E9B614A83FA9031B07E8D3B257A78@stntexch2.va.neustar.com> <16067.37072.865297.570579@harjus.eng.song.fi> <3EC88A61.1020405@dynamicsoft.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: , X-Spam-Status: No, hits=3D-28.6 required=3D5.0 tests=3DEMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_VM version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) Jonathan Rosenberg writes: > Sounds like a good reason to document that you should be supporting=20 > both. I think recommending that has only benefits and no drawbacks. yes, we have way passed the point where the "old" service field format need not be supported. because the "old" format must be supported for ever, the question raises: why does it make sense to define the new format at all. -- 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 19-May-2003 03:25:25 -0500,4676;000000000000-00000b27 Received: via dmail-2000(11) for +imap/ietf/SIPPING; Mon, 19 May 2003 = 03:25:25 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4J8PH6n007134 for ; Mon, 19 May 2003 03:25:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J7g4B26179; Mon, 19 May 2003 03:42: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 h4J7fhB26155 for ; Mon, 19 May 2003 03:41: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 EAA11580 for ; Mon, 19 May 2003 04:12:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Hfmd-0000xi-00 for sipping@ietf.org; Mon, 19 May 2003 04:14:11 -0400 Received: from [63.113.44.69] (helo=3Dmail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19Hfmc-0000xc-00 for sipping@ietf.org; Mon, 19 May 2003 04:14:10 -0400 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h4J8F1dh014248; Mon, 19 May 2003 04:15:01 -0400 (EDT) Message-ID: <3EC8927F.9070907@dynamicsoft.com> Date: Mon, 19 May 2003 04:14:55 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) = Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marjou Xavier CC: "'sipping@ietf.org'" Subject: Re: [Sipping] conf: comments on = draft-rosenberg-sipping-conferenc ing-framework-01 References: <5B788FC2CAFBD6118BAE0030848B025C416CFC@LNN201E> In-Reply-To: <5B788FC2CAFBD6118BAE0030848B025C416CFC@LNN201E> Content-Type: text/plain; charset=3Dus-ascii; format=3Dflowed 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: , X-Spam-Status: No, hits=3D-37.7 required=3D5.0 tests=3DEMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_LONG_SPARSE, USER_AGENT_MOZILLA_UA autolearn=3Dham version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) response inline. Marjou Xavier wrote: >>> Something is not clear to me : is CPCP really mandatory to >>> perform something as "simple" as calling many recipients via a >>> focus (adhoc conference). >=20 >=20 >> In an ad-hoc conference, the focus resides with one of the >> endpoints. Therefore, an internal interface can be used to >> instruct the focus to call out to additional users. So, in the >> case of ad-hoc, something as "simple" as mass invitation does not >> require CPCP. >=20 >=20 >>> With a centralized conference server, a client can use a series >>> of REFER requests to bring new users into the conference. This >>> is described in the document as a SIP mecahnism for adding >>> users. However, for a large number of invitations, this is >>> really inefficient, and thus a real control protocol like CPCP >>> is needed. >=20 >=20 > Is a CPCP body inside a SIP INVITE acceptable ? (I would like to > avoid an additional round-trip delay for a CPCP request before the > SIP request) What additional round trip delay? If you use CPCP it would mean you=20 dont use refer. -Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP 19-May-2003 03:39:50 -0500,6462;000000000001-00000b28 Received: via dmail-2000(11) for +imap/ietf/SIPPING; Mon, 19 May 2003 = 03:39:50 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4J8dg6n007217 for ; Mon, 19 May 2003 03:39:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J7v4B27074; Mon, 19 May 2003 03:57: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 h4J7uUB27035 for ; Mon, 19 May 2003 03:56: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 EAA12241 for ; Mon, 19 May 2003 04:27:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Hg0w-00018i-00 for sipping@ietf.org; Mon, 19 May 2003 04:28:58 -0400 Received: from [63.113.44.69] (helo=3Dmail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19Hg0v-00017s-00 for sipping@ietf.org; Mon, 19 May 2003 04:28:57 -0400 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h4J8Tmdh014255; Mon, 19 May 2003 04:29:48 -0400 (EDT) Message-ID: <3EC895F6.6070802@dynamicsoft.com> Date: Mon, 19 May 2003 04:29:42 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) = Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Burger CC: "Sipping (E-mail)" Subject: Re: [Sipping] conf: comments on = draft-rosenberg-sipping-conferencing-framework-01 References: = <4A3384433CE2AB46A63468CB207E209D097C77@zoe.office.snowshore.com> In-Reply-To: = <4A3384433CE2AB46A63468CB207E209D097C77@zoe.office.snowshore.com> Content-Type: text/plain; charset=3Dus-ascii; format=3Dflowed 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: , X-Spam-Status: No, hits=3D-37.5 required=3D5.0 tests=3DEMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES, SIGNATURE_LONG_SPARSE,SUBJ_HAS_UNIQ_ID, USER_AGENT_MOZILLA_UA autolearn=3Dham version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) Eric Burger wrote: >> Having a URI with a mnemonic user part does not mean its no >> longer opaque to the system, no longer unique, or that the intent >> is for it to be guessed. For long lived conferences in >> particular, where there is a likelihood that someone will need to >> convey one over a phone, I see value in them being mnemonic. >=20 >=20 > I think we agree here. That is: 1. There is value to having a > mnemonic URI 2. The URI is opaque to the protocol. >=20 > I was just pointing out that the text of the draft explicitly > states the conference URI must not be a mnemonic (see quote above). I think the new text in sipping-00 is OK. >=20 >=20 > [snip] >=20 >=20 >>> Section 5.2.1 Is it worth mentioning a stateful application >>=20 >> server as >>=20 >>> a mechanism for running a conference? >>=20 >> I don't understand. 5.2.1 is talking about adding users to a=20 >> conference. What does that have to do with using an application >> server? >=20 >=20 > All INVITEs come from the application server. This means the > application server is fully aware of the state of all call legs; > can directly manipulate state, permissions, and media policy; and > has the added bonus of making CPCP entirely unnecessary. >=20 > Given that the largest conference service bureaux in the world are > on the order of a few tens of thousands of ports, I don't think the > "application server doesn't scale like a proxy server" argument > really holds. I still dont see what this has to do with section 5.2.1. >=20 > [snip] >=20 >=20 >>> Section 5.4.2 and 5.4.3 I don't really get the difference >>> between these two examples. >>=20 >> One of them uses CPCP to remove a user. This can be done by an >> automata. The other uses a web application to remove a user. THis >> can only be done by a user. >=20 > [snip] >=20 >> So, just because both SIP and CPCP can change the state of a=20 >> conference, does not mean that they are the same protocol. >=20 > [snip] >=20 >> CPCP, being a data transaction protocol, would also allow you to >> directly query for the list. Just because there is this sliver >> of overlap does not mean that they are the same protocol. >=20 >=20 > A "sliver of overlap" is OK. A full set of overlap is not. Look > at the draft, for just about every operation, the draft says, "Here > is the way to do it with SIP, and here is the way to do it with > CPCP." It may be my misreading, but it sounds like there is a lot > of overlap. Thats because the framework is not touching on the breadth of CPCP,=20 which would also set general conference policy (like who is allowed to=20 join, who can moderate, name of the conference, etc.). Those=20 conference operations which are of the flavor "create this dialog" can=20 be done with SIP, but only those operations. -Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP 19-May-2003 08:52:13 -0500,4806;000000000000-00000b29 Received: via dmail-2000(11) for +imap/ietf/SIPPING; Mon, 19 May 2003 = 08:52:13 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4JDq56n009655 for ; Mon, 19 May 2003 08:52:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JD89B17585; Mon, 19 May 2003 09:08: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 h4JD74B16741 for ; Mon, 19 May 2003 09: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 JAA20516 for ; Mon, 19 May 2003 09:37:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Hkr7-0003SQ-00 for sipping@ietf.org; Mon, 19 May 2003 09:39:09 -0400 Received: from relay2.clb.oleane.net ([213.56.31.22]) by ietf-mx with esmtp (Exim 4.12) id 19Hkr1-0003RO-00 for sipping@ietf.org; Mon, 19 May 2003 09:39:03 -0400 Received: from oleane ([194.250.212.114])=20 by relay2.clb.oleane.net with SMTP id h4JDdFl4003480 for ; Mon, 19 May 2003 15:39:15 +0200 Message-ID: <10a201c31e0c$95aeaf40$0601a8c0@oleane.com> From: "Peter Lewis" To: Date: Mon, 19 May 2003 15:43:09 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=3D"----=3D_NextPart_000_109F_01C31E1D.58ECBAA0" 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 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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-Spam-Status: No, hits=3D1.6 required=3D5.0 tests=3DHTML_30_40,HTML_MESSAGE,RCVD_IN_UNCONFIRMED_DSBL version=3D2.52 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) This is a multi-part message in MIME format. ------=3D_NextPart_000_109F_01C31E1D.58ECBAA0 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 extendeed to June 15. Please get all details at: http://www.upperside.fr/sip2004/sip2004cfp.htm ------=3D_NextPart_000_109F_01C31E1D.58ECBAA0 [Enclosed text/html ] ------=3D_NextPart_000_109F_01C31E1D.58ECBAA0-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP 19-May-2003 16:16:30 -0500,4773;000000000001-00000b2a Received: via dmail-2000(11) for +imap/ietf/SIPPING; Mon, 19 May 2003 = 16:16:30 -0500 (CDT) Return-Path: Received: from sj-core-1.cisco.com (sj-core-1.cisco.com = [171.71.177.237]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4JLGL6n012695 for ; Mon, 19 May 2003 16:16:22 -0500 Received: from cisco.com (sjc-vpn3-438.cisco.com [10.21.65.182]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4JLFVeS023172; Mon, 19 May 2003 14:15:31 -0700 (PDT) Message-ID: <3EC94970.8A6AE7E@cisco.com> Date: Mon, 19 May 2003 17:15:28 -0400 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Gonzalo Camarillo Gonzalez (LMF)" = CC: "'sipping@ietf.org'" , "Jon Peterson (E-mail)" , "Rohan Mahy (E-mail)" , "Dean Willis (E-mail)" Subject: Re: [Sipping] Last Call for early media use cases References: = Content-Type: text/plain; charset=3Dus-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=3D-22.8 required=3D5.0 tests=3DEMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=3Dham version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) I believe it is useful to have a flag that indicates the "early media = is coming", which would suggest to the UAC that it probably should not = be generating local ringback. Motivation for such a flag is to avoid the = potential race between generating local ringback and having in-band = media turning such local ringback off. It applies equally well to the = intelligent SIP endpoint and the decomposed gateway, although it may be = more obvious for the decomposed gateway. You may argue, that signaling should be = faster than media, that you can have a small delay in applying the = local ringback, etc, however they all amount to heuristics. Also, consider = that the far-end side may be using silence suppression, and the = potential for the race to occur becomes greater. By having (and using) this flag, the = race is avoided. This brings me to another issue. So far, the ringback/early media/media = discussion has mainly focused on having media received turning local ringback off. A great deal of concern has been expressed with the = robustness of this principle and I agree with this concern. It turns = out we already have an example that breaks this model, namely comedia which = specifies that: "Endpoints that specify direction:active MUST be prepared to receive on = the ports from which they send. Once they learn the IP address and = port of their peer from the peer's SDP, they SHOULD immediately send some kind = of media (even if just comfort noise) to each of these ports." In other words, use of comedia may turn off local ringback. In general, = NAT/firewall traversal incurs this problem as it may need to refresh bindings/pinholes (as described in STUN) before a call has been = answered, and there will probably be other cases too. This strongly = suggests that the current "local ringaback turned off by early media" design is = simply too fragile. We could for example: 1. Have a way of determining/indicating that some early media packets = should not override local ringback or whatever else might be going on = (this could potentially just be by convention, e.g. silence suppression = packets should not affect local ringback, which would then be a = sanctioned way of doing RTP connectivity things without affecting early media) 2. Have a way of turning local ringback back on after it has been = turned off due to receipt of early media (consider the case where = forking lead to multiple early dialogs, but just one early media stream, and all of a = sudden that early media stream disappers). It would be good if the early media draft could address these issues as = well. -- Flemming "Gonzalo Camarillo Gonzalez (LMF)" wrote: > Folks, > > in the last IETF meeting, we requested early media use cases that = show the need of a "media coming" flag. So far, we have not received = anything. > > We intend to release a new version of the early media draft in a week = or so. So, that is the time you have to send me your use cases. > > Thanks, > > Gonzalo > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP 19-May-2003 16:38:52 -0500,6480;000000000000-00000b2b Received: via dmail-2000(11) for +imap/ietf/SIPPING; Mon, 19 May 2003 = 16:38:52 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4JLcj6n012866 for ; Mon, 19 May 2003 16:38:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JKh7B17807; Mon, 19 May 2003 16:43: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 h4JKgdB17785 for ; Mon, 19 May 2003 16:42: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 RAA05910 for ; Mon, 19 May 2003 17:13:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Hry6-0006W1-00 for sipping@ietf.org; Mon, 19 May 2003 17:14:50 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19Hry5-0006VG-00 for sipping@ietf.org; Mon, 19 May 2003 17:14:49 -0400 Received: from cisco.com (sjc-vpn3-438.cisco.com [10.21.65.182]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4JLFVeS023172; Mon, 19 May 2003 14:15:31 -0700 (PDT) Message-ID: <3EC94970.8A6AE7E@cisco.com> Date: Mon, 19 May 2003 17:15:28 -0400 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Gonzalo Camarillo Gonzalez (LMF)" = CC: "'sipping@ietf.org'" , "Jon Peterson (E-mail)" , "Rohan Mahy (E-mail)" , "Dean Willis (E-mail)" Subject: Re: [Sipping] Last Call for early media use cases References: Content-Type: text/plain; charset=3Dus-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: , X-Spam-Status: No, hits=3D-22.8 required=3D5.0 tests=3DEMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) I believe it is useful to have a flag that indicates the "early media = is coming", which would suggest to the UAC that it probably should not = be generating local ringback. Motivation for such a flag is to avoid the = potential race between generating local ringback and having in-band = media turning such local ringback off. It applies equally well to the = intelligent SIP endpoint and the decomposed gateway, although it may be = more obvious for the decomposed gateway. You may argue, that signaling should be = faster than media, that you can have a small delay in applying the = local ringback, etc, however they all amount to heuristics. Also, consider = that the far-end side may be using silence suppression, and the = potential for the race to occur becomes greater. By having (and using) this flag, the = race is avoided. This brings me to another issue. So far, the ringback/early media/media = discussion has mainly focused on having media received turning local ringback off. A great deal of concern has been expressed with the = robustness of this principle and I agree with this concern. It turns = out we already have an example that breaks this model, namely comedia which = specifies that: "Endpoints that specify direction:active MUST be prepared to receive on = the ports from which they send. Once they learn the IP address and = port of their peer from the peer's SDP, they SHOULD immediately send some kind = of media (even if just comfort noise) to each of these ports." In other words, use of comedia may turn off local ringback. In general, = NAT/firewall traversal incurs this problem as it may need to refresh bindings/pinholes (as described in STUN) before a call has been = answered, and there will probably be other cases too. This strongly = suggests that the current "local ringaback turned off by early media" design is = simply too fragile. We could for example: 1. Have a way of determining/indicating that some early media packets = should not override local ringback or whatever else might be going on = (this could potentially just be by convention, e.g. silence suppression = packets should not affect local ringback, which would then be a = sanctioned way of doing RTP connectivity things without affecting early media) 2. Have a way of turning local ringback back on after it has been = turned off due to receipt of early media (consider the case where = forking lead to multiple early dialogs, but just one early media stream, and all of a = sudden that early media stream disappers). It would be good if the early media draft could address these issues as = well. -- Flemming "Gonzalo Camarillo Gonzalez (LMF)" wrote: > Folks, > > in the last IETF meeting, we requested early media use cases that = show the need of a "media coming" flag. So far, we have not received = anything. > > We intend to release a new version of the early media draft in a week = or so. So, that is the time you have to send me your use cases. > > Thanks, > > Gonzalo > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP 19-May-2003 16:45:29 -0500,17410;000000000000-00000b2c Received: via dmail-2000(11) for +imap/ietf/SIPPING; Mon, 19 May 2003 = 16:45:29 -0500 (CDT) Return-Path: Received: from auemail1.firewall.lucent.com (auemail1.lucent.com = [192.11.223.161]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4JLjI6o012913 (version=3DTLSv1/SSLv3 cipher=3DEDH-RSA-DES-CBC3-SHA bits=3D168 = verify=3DNO) for ; Mon, 19 May 2003 16:45:19 -0500 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com = [135.1.23.83]) by auemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP = id h4JLjBN01351 for ; Mon, 19 May 2003 17:45:11 -0400 (EDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service = (5.5.2653.19) id ; Mon, 19 May 2003 16:45:11 -0500 Message-ID: = From: "Ejzak, Richard P (Richard)" To: "'Gonzalo Camarillo Gonzalez (LMF)'" , "'sipping@ietf.org'" Cc: "Jon Peterson (E-mail)" , "Rohan Mahy (E-mail)" , "Dean Willis (E-mail)" Subject: RE: [Sipping] Last Call for early media use cases Date: Mon, 19 May 2003 16:45:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary=3D"----_=3D_NextPart_000_01C31E4F.EA121D72" X-Spam-Status: No, hits=3D-3.1 required=3D5.0 tests=3DORIGINAL_MESSAGE autolearn=3Dham version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) 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. ------_=3D_NextPart_000_01C31E4F.EA121D72 Gonzalo, Please excuse my tardiness in responding to your request for early = media use cases. I believe the attachment includes an example = configuration and call flow that clearly illustrates some problems that = need to be solved with the existing SIP early media procedures. Thanks, Richard Ejzak Lucent Technologies -----Original Message----- From: Gonzalo Camarillo Gonzalez (LMF) [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: Wednesday, May 14, 2003 2:13 AM To: 'sipping@ietf.org' Cc: Jon Peterson (E-mail); Rohan Mahy (E-mail); Dean Willis (E-mail) Subject: [Sipping] Last Call for early media use cases Folks, in the last IETF meeting, we requested early media use cases that show = the need of a "media coming" flag. So far, we have not received = anything. We intend to release a new version of the early media draft in a week = or so. So, that is the time you have to send me your use cases. Thanks, Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP ------_=3D_NextPart_000_01C31E4F.EA121D72 Early Media Use Case The following figure is an example call flow highlighting a range of = issues associated with control of early media. In this scenario, A and = D are gateway controllers performing interworking with other networks = using in-band call progress information, B is a network feature server = performing two call forwarding procedures (C to D and then D to E), and = C and E are SIP endpoints providing only out-of-band call progress = information. B is required to behave as a B2BUA since gateways are = known to have difficulties with SIP forking procedures, which would = otherwise be required in this forwarding scenario for B to behave as a = SIP proxy. C and E are shown performing delayed SDP negotiation, which = may occur due to resource reservation delays at a mobile endpoint or = for other reasons. The scenario also assumes the use of a SIP profile = including the use of reliable provisional responses and preconditions, = although PRACK transactions without SDP and other details are not = shown. 181 responses may occur during the scenario to report = forwarding, but are not shown since they do not affect the processing = of early media. Cleanup of dialogs with C and D after forwarding using = CANCELs and/or final responses is also not shown to limit clutter in = the figure. A B C D = E |(1) INVITE sdp1 |(2) INVITE sdp1 | | = | |----------------->|----------------->| | = | |(4) 180 |(3) 180 | | = | |<-----------------|<-----------------| | = | | | | | = | |(6) 183 sdp2 |(5) 183 sdp2 | | = | |<-----------------|<-----------------| | = | | | | | = | | | |(7) INVITE(no SDP)| = | | |------------------------------------>| = | |(9) 183 | |(8) 183 sdp3 | = | |<-----------------|<------------------------------------| = | |(10) UPDATE sdp3 | | | = | |<-----------------| | | = | |(11) 200 OK sdp4 | |(12) PRACK sdp4 | = | |----------------->|------------------------------------>| = | | | |(13) 200 OK | = | | |<------------------------------------| = | | | | | = | |(15) 180 | |(14) 180 | = | |<-----------------|<------------------------------------| = | | | | | = | | | | |(16) = INVITE(noSDP)| | = |------------------------------------------------------->| |(18) 180 | | |(17) 180 = | |<-----------------|<---------------------------------------------------= ----| | | | | = =3D | |(20) 183 | | |(19) 183 sdp5 = =3D | |<-----------------|<---------------------------------------------------= =3D ----| |(21) UPDATE sdp5 | | | = =3D | |<-----------------| | | = =3D | |(22) 200 OK sdp6 | | |(23) PRACK = =3D sdp6 | |----------------->|----------------------------------------------------= =3D --->| | | | |(24) 200 OK = =3D | | = |<---------------------------------------------------=3D ----| | | | | = =3D | |(26) 200 OK (INV) | | |(25) 200 OK = =3D (INV) | |<-----------------|<---------------------------------------------------= =3D ----| |(27) ACK | | |(28) ACK = =3D | |----------------->|----------------------------------------------------= =3D --->| At message (4), gateway controller A begins playing local ringing to = =3D the originating party (not shown) to represent alerting at C (which =3D provides only out-of-band call progress information). Some time later, = =3D when C is able to respond to the media offer in (2), it sends a 183 =3D response with SDP (5) to B, which sends another 183 response with SDP = =3D (6) to A, completing SDP negotiation between A and C. This is the =3D first case in which an early media issue arises. A must be prepared to = =3D override local ringing in the presence of in-band media to avoid the = =3D potential for media clipping at called party answer. To avoid =3D premature termination of local ringing after (6), C must avoid sending = =3D any media until called party answer occurs. There should be a =3D documented convention covering precisely what triggers the transition = =3D to in-band media - whether it be the existence of any RTP packets or = =3D the existence of media content in RTP packets above some noise =3D threshold. The use of a noise threshold would allow RTP playout =3D adjustments to occur prior to the transmission of any content, and is = =3D preferred. At some point after (6), B performs forwarding from C to gateway =3D controller D. D establishes new media at (8) and provides indication = =3D of called party alerting at (14). Following SDP offer/answer rules for = =3D reliable provisional responses in RFC 3262, RFC 3264 and RFC 3311, B = =3D separates sdp3 from (8) and sends the 183 and sdp3 to A in messages (9) = =3D and (10), respectively. This is the second case in which an early =3D media issue arises. A has no basis to treat the media established with = =3D D in (10) and (11) any differently from the media established with C in = =3D (6). So A must rely on the presence of media (however this is defined) = =3D from D for A to stop playing local ringing and pass in-band call =3D progress information from D to the calling party. If a noise threshold = =3D is used to identify the presence of in-band media and in-band call =3D progress information from D begins with a protracted period of silence = =3D (noise), due to various possible network conditions, then A will =3D continue to play local ringing even though silence would provide a more = =3D accurate indication of call progress. When called party alerting indication comes from D at (14) and (15), A = =3D would presumably not change early media handling. Either in-band media = =3D was detected after (11) and local ringing was turned off in preference = =3D to in-band media, or no in-band media was detected after (11) and local = =3D ringing continued. But in this scenario sometime after (15), B performs forwarding from D = =3D to endpoint E (which provides only out-of-band call progress =3D information). The 180 from E (18) should immediately trigger the =3D playing of local ringing at A, but A has no basis to distinguish the = =3D condition at (18) from the condition at (15). This is the third early = =3D media issue. A may be able to deduce from the absence of media from D = =3D that it should start generating local ringing at (18), but there =3D appears to be no way to do this reliably. There are seconds of silence = =3D even during active in-band call progress information, so it's not clear = =3D what would trigger A to begin local ringing. The early media issues = =3D associated with the remainder of the scenario have already been =3D discussed for messages (5) and (6). Early Media Issues Summarizing the three early media issues described in the preceding =3D section: 1) A gateway playing local ringing in response to receipt of 180 should = =3D be prepared to give priority to media from the network at answer to =3D avoid clipping. In-band media detection should be based on the =3D presence of media content rather than just the presence of RTP packets = =3D to avoid waiting for RTP playout adjustments. 2) A similar technique to 1) could handle a transition from local =3D ringing to in-band call progress information. Unfortunately, this =3D technique is not robust in detecting this transition when the intended = =3D in-band information is silence. A gateway may replace periods of =3D intended silence with local ringing. 3) A gateway passing in-band call progress information has difficulty = =3D identifying when it should transition to playing local ringing. Using = =3D the absence of in-band call progress information as a trigger to =3D initiate local ringing is unreliable and subject to significant delay. Potential Solution Problems 2) and 3) in the preceding section can be readily solved with = =3D the introduction of one minor change: a new piece of information =3D associated with any 18x response to indicate when in-band call progress = =3D information is available. The following figure uses the same scenario = =3D in the preceding use case but includes the use of the in-band (IB) =3D indication in the 18x responses as appropriate. This solution is =3D presented for illustrative purposes only. Other solutions also exist = =3D but all require the addition of some new information to one or more 18x = =3D responses. A B C D = =3D E |(1) INVITE sdp1 |(2) INVITE sdp1 | | = =3D | |----------------->|----------------->| | = =3D | |(4) 180 |(3) 180 | | = =3D | |<-----------------|<-----------------| | = =3D | | | | | = =3D | |(6) 183 sdp2 |(5) 183 sdp2 | | = =3D | |<-----------------|<-----------------| | = =3D | | | | | = =3D | | | |(7) INVITE(no SDP)| = =3D | | |------------------------------------>| = =3D | |(9) 183 IB | |(8) 183 IB sdp3 | = =3D | |<-----------------|<------------------------------------| = =3D | |(10) UPDATE sdp3 | | | = =3D | |<-----------------| | | = =3D | |(11) 200 OK sdp4 | |(12) PRACK sdp4 | = =3D | |----------------->|------------------------------------>| = =3D | | | |(13) 200 OK | = =3D | | |<------------------------------------| = =3D | | | | | = =3D | |(15) 180 IB | |(14) 180 IB | = =3D | |<-----------------|<------------------------------------| = =3D | | | | | = =3D | | | | |(16) =3D INVITE(noSDP)| | =3D |------------------------------------------------------->| |(18) 180 | | |(17) 180 = =3D | |<-----------------|<---------------------------------------------------= =3D ----| | | | | = =3D | |(20) 183 | | |(19) 183 sdp5 = =3D | |<-----------------|<---------------------------------------------------= =3D ----| |(21) UPDATE sdp5 | | | = =3D | |<-----------------| | | = =3D | |(22) 200 OK sdp6 | | |(23) PRACK = =3D sdp6 | |----------------->|----------------------------------------------------= =3D --->| | | | |(24) 200 OK = =3D | | =3D |<-------------------------------------------------------| | | | | = =3D | |(26) 200 OK (INV) | | |(25) 200 OK = =3D (INV) | |<-----------------|<---------------------------------------------------= =3D ----| |(27) ACK | | |(28) ACK = =3D | |----------------->|----------------------------------------------------= =3D --->| A interprets 183 (6) as an indication that local ringing should =3D continue until called party media is detected since there is no IB =3D indication. 183 IB (8) and 183 IB (9) cause A to stop local ringing in = =3D preference to in-band media. There is no possibility of missing =3D intended periods of in-band silence. 180 IB (14) and 180 IB (15) =3D clearly indicate to A that there is called party alerting but the =3D in-band information should be passed to the calling party rather than = =3D local ringing. Finally, 180 (18) and 183 (20) clearly indicate that A = =3D should generate local ringing until called party answer or some other = =3D change in early media handling. This flow is identical to the original = =3D flow except for the addition of the IB indication to four of the =3D provisional responses in (8), (9), (14) and (15). ------_=3D_NextPart_000_01C31E4F.EA121D72-- 19-May-2003 16:57:07 -0500,19029;000000000001-00000b2d Received: via dmail-2000(11) for +imap/ietf/SIPPING; Mon, 19 May 2003 = 16:57:07 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4JLuw6n012980 for ; Mon, 19 May 2003 16:56:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JLDDB20826; Mon, 19 May 2003 17:13: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 h4JLCGB20775 for ; Mon, 19 May 2003 17:12: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 RAA06868 for ; Mon, 19 May 2003 17:42:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HsQl-0006nj-00 for sipping@ietf.org; Mon, 19 May 2003 17:44:27 -0400 Received: from auemail1.lucent.com ([192.11.223.161] = helo=3Dauemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19HsQk-0006nU-00 for sipping@ietf.org; Mon, 19 May 2003 17:44:26 -0400 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com = [135.1.23.83]) by auemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP = id h4JLjBN01356 for ; Mon, 19 May 2003 17:45:11 -0400 (EDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service = (5.5.2653.19) id ; Mon, 19 May 2003 16:45:11 -0500 Message-ID: = From: "Ejzak, Richard P (Richard)" To: "'Gonzalo Camarillo Gonzalez (LMF)'" , "'sipping@ietf.org'" Cc: "Jon Peterson (E-mail)" , "Rohan Mahy (E-mail)" , "Dean Willis (E-mail)" Subject: RE: [Sipping] Last Call for early media use cases Date: Mon, 19 May 2003 16:45:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary=3D"----_=3D_NextPart_000_01C31E4F.EA121D72" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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-Spam-Status: No, hits=3D-3.1 required=3D5.0 tests=3DORIGINAL_MESSAGE version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) 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. ------_=3D_NextPart_000_01C31E4F.EA121D72 Gonzalo, Please excuse my tardiness in responding to your request for early = media use cases. I believe the attachment includes an example = configuration and call flow that clearly illustrates some problems that = need to be solved with the existing SIP early media procedures. Thanks, Richard Ejzak Lucent Technologies -----Original Message----- From: Gonzalo Camarillo Gonzalez (LMF) [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: Wednesday, May 14, 2003 2:13 AM To: 'sipping@ietf.org' Cc: Jon Peterson (E-mail); Rohan Mahy (E-mail); Dean Willis (E-mail) Subject: [Sipping] Last Call for early media use cases Folks, in the last IETF meeting, we requested early media use cases that show = the need of a "media coming" flag. So far, we have not received = anything. We intend to release a new version of the early media draft in a week = or so. So, that is the time you have to send me your use cases. Thanks, Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP ------_=3D_NextPart_000_01C31E4F.EA121D72 Early Media Use Case The following figure is an example call flow highlighting a range of = issues associated with control of early media. In this scenario, A and = D are gateway controllers performing interworking with other networks = using in-band call progress information, B is a network feature server = performing two call forwarding procedures (C to D and then D to E), and = C and E are SIP endpoints providing only out-of-band call progress = information. B is required to behave as a B2BUA since gateways are = known to have difficulties with SIP forking procedures, which would = otherwise be required in this forwarding scenario for B to behave as a = SIP proxy. C and E are shown performing delayed SDP negotiation, which = may occur due to resource reservation delays at a mobile endpoint or = for other reasons. The scenario also assumes the use of a SIP profile = including the use of reliable provisional responses and preconditions, = although PRACK transactions without SDP and other details are not = shown. 181 responses may occur during the scenario to report = forwarding, but are not shown since they do not affect the processing = of early media. Cleanup of dialogs with C and D after forwarding using = CANCELs and/or final responses is also not shown to limit clutter in = the figure. A B C D = E |(1) INVITE sdp1 |(2) INVITE sdp1 | | = | |----------------->|----------------->| | = | |(4) 180 |(3) 180 | | = | |<-----------------|<-----------------| | = | | | | | = | |(6) 183 sdp2 |(5) 183 sdp2 | | = | |<-----------------|<-----------------| | = | | | | | = | | | |(7) INVITE(no SDP)| = | | |------------------------------------>| = | |(9) 183 | |(8) 183 sdp3 | = | |<-----------------|<------------------------------------| = | |(10) UPDATE sdp3 | | | = | |<-----------------| | | = | |(11) 200 OK sdp4 | |(12) PRACK sdp4 | = | |----------------->|------------------------------------>| = | | | |(13) 200 OK | = | | |<------------------------------------| = | | | | | = | |(15) 180 | |(14) 180 | = | |<-----------------|<------------------------------------| = | | | | | = | | | | |(16) = INVITE(noSDP)| | = |------------------------------------------------------->| |(18) 180 | | |(17) 180 = | |<-----------------|<---------------------------------------------------= ----| | | | | = =3D | |(20) 183 | | |(19) 183 sdp5 = =3D | |<-----------------|<---------------------------------------------------= =3D ----| |(21) UPDATE sdp5 | | | = =3D | |<-----------------| | | = =3D | |(22) 200 OK sdp6 | | |(23) PRACK = =3D sdp6 | |----------------->|----------------------------------------------------= =3D --->| | | | |(24) 200 OK = =3D | | = |<---------------------------------------------------=3D ----| | | | | = =3D | |(26) 200 OK (INV) | | |(25) 200 OK = =3D (INV) | |<-----------------|<---------------------------------------------------= =3D ----| |(27) ACK | | |(28) ACK = =3D | |----------------->|----------------------------------------------------= =3D --->| At message (4), gateway controller A begins playing local ringing to = =3D the originating party (not shown) to represent alerting at C (which =3D provides only out-of-band call progress information). Some time later, = =3D when C is able to respond to the media offer in (2), it sends a 183 =3D response with SDP (5) to B, which sends another 183 response with SDP = =3D (6) to A, completing SDP negotiation between A and C. This is the =3D first case in which an early media issue arises. A must be prepared to = =3D override local ringing in the presence of in-band media to avoid the = =3D potential for media clipping at called party answer. To avoid =3D premature termination of local ringing after (6), C must avoid sending = =3D any media until called party answer occurs. There should be a =3D documented convention covering precisely what triggers the transition = =3D to in-band media - whether it be the existence of any RTP packets or = =3D the existence of media content in RTP packets above some noise =3D threshold. The use of a noise threshold would allow RTP playout =3D adjustments to occur prior to the transmission of any content, and is = =3D preferred. At some point after (6), B performs forwarding from C to gateway =3D controller D. D establishes new media at (8) and provides indication = =3D of called party alerting at (14). Following SDP offer/answer rules for = =3D reliable provisional responses in RFC 3262, RFC 3264 and RFC 3311, B = =3D separates sdp3 from (8) and sends the 183 and sdp3 to A in messages (9) = =3D and (10), respectively. This is the second case in which an early =3D media issue arises. A has no basis to treat the media established with = =3D D in (10) and (11) any differently from the media established with C in = =3D (6). So A must rely on the presence of media (however this is defined) = =3D from D for A to stop playing local ringing and pass in-band call =3D progress information from D to the calling party. If a noise threshold = =3D is used to identify the presence of in-band media and in-band call =3D progress information from D begins with a protracted period of silence = =3D (noise), due to various possible network conditions, then A will =3D continue to play local ringing even though silence would provide a more = =3D accurate indication of call progress. When called party alerting indication comes from D at (14) and (15), A = =3D would presumably not change early media handling. Either in-band media = =3D was detected after (11) and local ringing was turned off in preference = =3D to in-band media, or no in-band media was detected after (11) and local = =3D ringing continued. But in this scenario sometime after (15), B performs forwarding from D = =3D to endpoint E (which provides only out-of-band call progress =3D information). The 180 from E (18) should immediately trigger the =3D playing of local ringing at A, but A has no basis to distinguish the = =3D condition at (18) from the condition at (15). This is the third early = =3D media issue. A may be able to deduce from the absence of media from D = =3D that it should start generating local ringing at (18), but there =3D appears to be no way to do this reliably. There are seconds of silence = =3D even during active in-band call progress information, so it's not clear = =3D what would trigger A to begin local ringing. The early media issues = =3D associated with the remainder of the scenario have already been =3D discussed for messages (5) and (6). Early Media Issues Summarizing the three early media issues described in the preceding =3D section: 1) A gateway playing local ringing in response to receipt of 180 should = =3D be prepared to give priority to media from the network at answer to =3D avoid clipping. In-band media detection should be based on the =3D presence of media content rather than just the presence of RTP packets = =3D to avoid waiting for RTP playout adjustments. 2) A similar technique to 1) could handle a transition from local =3D ringing to in-band call progress information. Unfortunately, this =3D technique is not robust in detecting this transition when the intended = =3D in-band information is silence. A gateway may replace periods of =3D intended silence with local ringing. 3) A gateway passing in-band call progress information has difficulty = =3D identifying when it should transition to playing local ringing. Using = =3D the absence of in-band call progress information as a trigger to =3D initiate local ringing is unreliable and subject to significant delay. Potential Solution Problems 2) and 3) in the preceding section can be readily solved with = =3D the introduction of one minor change: a new piece of information =3D associated with any 18x response to indicate when in-band call progress = =3D information is available. The following figure uses the same scenario = =3D in the preceding use case but includes the use of the in-band (IB) =3D indication in the 18x responses as appropriate. This solution is =3D presented for illustrative purposes only. Other solutions also exist = =3D but all require the addition of some new information to one or more 18x = =3D responses. A B C D = =3D E |(1) INVITE sdp1 |(2) INVITE sdp1 | | = =3D | |----------------->|----------------->| | = =3D | |(4) 180 |(3) 180 | | = =3D | |<-----------------|<-----------------| | = =3D | | | | | = =3D | |(6) 183 sdp2 |(5) 183 sdp2 | | = =3D | |<-----------------|<-----------------| | = =3D | | | | | = =3D | | | |(7) INVITE(no SDP)| = =3D | | |------------------------------------>| = =3D | |(9) 183 IB | |(8) 183 IB sdp3 | = =3D | |<-----------------|<------------------------------------| = =3D | |(10) UPDATE sdp3 | | | = =3D | |<-----------------| | | = =3D | |(11) 200 OK sdp4 | |(12) PRACK sdp4 | = =3D | |----------------->|------------------------------------>| = =3D | | | |(13) 200 OK | = =3D | | |<------------------------------------| = =3D | | | | | = =3D | |(15) 180 IB | |(14) 180 IB | = =3D | |<-----------------|<------------------------------------| = =3D | | | | | = =3D | | | | |(16) =3D INVITE(noSDP)| | =3D |------------------------------------------------------->| |(18) 180 | | |(17) 180 = =3D | |<-----------------|<---------------------------------------------------= =3D ----| | | | | = =3D | |(20) 183 | | |(19) 183 sdp5 = =3D | |<-----------------|<---------------------------------------------------= =3D ----| |(21) UPDATE sdp5 | | | = =3D | |<-----------------| | | = =3D | |(22) 200 OK sdp6 | | |(23) PRACK = =3D sdp6 | |----------------->|----------------------------------------------------= =3D --->| | | | |(24) 200 OK = =3D | | =3D |<-------------------------------------------------------| | | | | = =3D | |(26) 200 OK (INV) | | |(25) 200 OK = =3D (INV) | |<-----------------|<---------------------------------------------------= =3D ----| |(27) ACK | | |(28) ACK = =3D | |----------------->|----------------------------------------------------= =3D --->| A interprets 183 (6) as an indication that local ringing should =3D continue until called party media is detected since there is no IB =3D indication. 183 IB (8) and 183 IB (9) cause A to stop local ringing in = =3D preference to in-band media. There is no possibility of missing =3D intended periods of in-band silence. 180 IB (14) and 180 IB (15) =3D clearly indicate to A that there is called party alerting but the =3D in-band information should be passed to the calling party rather than = =3D local ringing. Finally, 180 (18) and 183 (20) clearly indicate that A = =3D should generate local ringing until called party answer or some other = =3D change in early media handling. This flow is identical to the original = =3D flow except for the addition of the IB indication to four of the =3D provisional responses in (8), (9), (14) and (15). ------_=3D_NextPart_000_01C31E4F.EA121D72-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP 20-May-2003 12:33:45 -0500,13291;000000000000-00000000 Received: via dmail-2000(11) for +imap/ietf/SIPPING; Tue, 20 May 2003 = 12:33:45 -0500 (CDT) Return-Path: Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com = [47.103.122.112]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4KHXb6n020978 for ; Tue, 20 May 2003 12:33:38 -0500 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 h4KHWSB10417; Tue, 20 May 2003 12:32:28 -0500 (CDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service = (5.5.2653.19) id ; Tue, 20 May 2003 10:32:28 -0700 Message-ID: = <2F1FC1DEA077D5119FAD00508BCFD6D20885933A@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Ejzak, Richard P (Richard)'" , "'Gonzalo Camarillo Gonzalez (LMF)'" = , "'sipping@ietf.org'" Cc: "'Jon Peterson (E-mail)'" , "'Rohan Mahy (E-mail)'" , "'Dean Willis (E-mail)'" Subject: RE: [Sipping] Last Call for early media use cases Date: Tue, 20 May 2003 10:32:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary=3D"----_=3D_NextPart_001_01C31EF5.C4F625B4" X-Spam-Status: No, hits=3D-1.0 required=3D5.0 tests=3DASCII_FORM_ENTRY,HTML_20_30,HTML_MESSAGE,QUOTED_EMAIL_TEXT version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) 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. ------_=3D_NextPart_001_01C31EF5.C4F625B4 Thanks Richard, this is exactly one of the scenario I had in mind. Now let's look at a different but very similar scenario (which is the one that worries me most). Assume the same exact call flows, but where the calls to C, D and E are not done in sequence, but in parrallel (i.e., parallel forking). From A's perspective, the scenario is exactly the same except that it will receive the provisional responses from B, C, D and E in random order, and much closer together. Let's assume that they arrive in the following order (E, C, D), milliseconds apart. It wouldn't make sense to change the ringing patterns "sequentially" because they are not sequenced, but parallel. With the current proposal (and no means to distinguish between parrallel forked calls and=20 sequential calls), we would end-up with D's ringing (out-of-band) and=20 E's answer. If D was busy (in-band), the user would hear "busy" tone=20 followed by an answer, which is not acceptable. Two solutions exist for that problem: - That ALL forking entities be B2BUAs and shield this problem from the = UAs. If there is even just one forking proxy out there (making calls in=20 parallel), we will get the problem. I'm sceptical that we can = convince the whole world NOT to use forking proxies to make parallel calls. - That forking proxies tag along a "parrallel forking" indication that=20 will be provided to the called UAs. This indication will tell the UA = that=20 in-band ringing (or other tones) in early media shall NOT be used because it is useless (early media for answer of course would still = be valid). (It may make sense also to let the UA sending the original = invite know about the forking so it can provide appropriate treatment for = the user: a tone, or display indication). The second solution is in my opinion the best. And it would be = compatible with your proposal for sequential forwarding. Proxies (or B2BUAs) doing sequential forwarding would NOT put this "parallel forking" indication. Your proposed in-band call progress indication would solve the problem=20 nicely. Proxies (or B2BUAs) doing parralel forking would put the "parallel = forking" indication. This would prohibit the UAs receiving the INVITE to=20 do in-band call progress tones (i.e., they wouldn't be allowed to = include your in-band call progress indication).=20 In combination, the "in-band call progress indication" and the = "parralel forking indiction" would solve all the scenarios that were worrying me. > -----Original Message----- > From: Ejzak, Richard P (Richard) [mailto:ejzak@lucent.com]=20 > Sent: Monday, May 19, 2003 14:45 > To: 'Gonzalo Camarillo Gonzalez (LMF)'; 'sipping@ietf.org' > Cc: Jon Peterson (E-mail); Rohan Mahy (E-mail); Dean Willis (E-mail) > Subject: RE: [Sipping] Last Call for early media use cases >=20 >=20 > Gonzalo, > Please excuse my tardiness in responding to your request for=20 > early media use cases. I believe the attachment includes an=20 > example configuration and call flow that clearly illustrates=20 > some problems that need to be solved with the existing SIP=20 > early media procedures. >=20 > Thanks, >=20 > Richard Ejzak > Lucent Technologies >=20 > -----Original Message----- > From: Gonzalo Camarillo Gonzalez (LMF)=20 > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Wednesday,=20 > May 14, 2003 2:13 AM > To: 'sipping@ietf.org' > Cc: Jon Peterson (E-mail); Rohan Mahy (E-mail); Dean Willis (E-mail) > Subject: [Sipping] Last Call for early media use cases >=20 >=20 > Folks, >=20 > in the last IETF meeting, we requested early media use cases=20 > that show the need of a "media coming" flag. So far, we have=20 > not received anything. >=20 > We intend to release a new version of the early media draft=20 > in a week or so. So, that is the time you have to send me=20 > your use cases. >=20 > Thanks, >=20 > 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=20 > sip Use sip@ietf.org for new developments of core SIP >=20 >=20 ------_=3D_NextPart_001_01C31EF5.C4F625B4 [Enclosed text/html ] ------_=3D_NextPart_001_01C31EF5.C4F625B4-- 20-May-2003 12:55:38 -0500,14963;000000000000-00000000 Received: via dmail-2000(11) for +imap/ietf/SIPPING; Tue, 20 May 2003 = 12:55:38 -0500 (CDT) Return-Path: Received: from www1.ietf.org (ietf.org [132.151.1.19]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4KHtS6n021124 for ; Tue, 20 May 2003 12:55:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KH1GB18099; Tue, 20 May 2003 13:01: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 h4KH05B18037 for ; Tue, 20 May 2003 13:00:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22314 for ; Tue, 20 May 2003 13:33:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IAxq-000764-00 for sipping@ietf.org; Tue, 20 May 2003 13:31:50 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19IAxq-000760-00 for sipping@ietf.org; Tue, 20 May 2003 13:31:50 -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 h4KHWSB10417; Tue, 20 May 2003 12:32:28 -0500 (CDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service = (5.5.2653.19) id ; Tue, 20 May 2003 10:32:28 -0700 Message-ID: = <2F1FC1DEA077D5119FAD00508BCFD6D20885933A@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Ejzak, Richard P (Richard)'" , "'Gonzalo Camarillo Gonzalez (LMF)'" = , "'sipping@ietf.org'" Cc: "'Jon Peterson (E-mail)'" , "'Rohan Mahy (E-mail)'" , "'Dean Willis (E-mail)'" Subject: RE: [Sipping] Last Call for early media use cases Date: Tue, 20 May 2003 10:32:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary=3D"----_=3D_NextPart_001_01C31EF5.C4F625B4" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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-Spam-Status: No, hits=3D-1.0 required=3D5.0 tests=3DASCII_FORM_ENTRY,HTML_20_30,HTML_MESSAGE,QUOTED_EMAIL_TEXT version=3D2.52 X-Spam-Level:=20 X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp) 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. ------_=3D_NextPart_001_01C31EF5.C4F625B4 Thanks Richard, this is exactly one of the scenario I had in mind. Now let's look at a different but very similar scenario (which is the one that worries me most). Assume the same exact call flows, but where the calls to C, D and E are not done in sequence, but in parrallel (i.e., parallel forking). From A's perspective, the scenario is exactly the same except that it will receive the provisional responses from B, C, D and E in random order, and much closer together. Let's assume that they arrive in the following order (E, C, D), milliseconds apart. It wouldn't make sense to change the ringing patterns "sequentially" because they are not sequenced, but parallel. With the current proposal (and no means to distinguish between parrallel forked calls and=20 sequential calls), we would end-up with D's ringing (out-of-band) and=20 E's answer. If D was busy (in-band), the user would hear "busy" tone=20 followed by an answer, which is not acceptable. Two solutions exist for that problem: - That ALL forking entities be B2BUAs and shield this problem from the = UAs. If there is even just one forking proxy out there (making calls in=20 parallel), we will get the problem. I'm sceptical that we can = convince the whole world NOT to use forking proxies to make parallel calls. - That forking proxies tag along a "parrallel forking" indication that=20 will be provided to the called UAs. This indication will tell the UA = that=20 in-band ringing (or other tones) in early media shall NOT be used because it is useless (early media for answer of course would still = be valid). (It may make sense also to let the UA sending the original = invite know about the forking so it can provide appropriate treatment for = the user: a tone, or display indication). The second solution is in my opinion the best. And it would be = compatible with your proposal for sequential forwarding. Proxies (or B2BUAs) doing sequential forwarding would NOT put this "parallel forking" indication. Your proposed in-band call progress indication would solve the problem=20 nicely. Proxies (or B2BUAs) doing parralel forking would put the "parallel = forking" indication. This would prohibit the UAs receiving the INVITE to=20 do in-band call progress tones (i.e., they wouldn't be allowed to = include your in-band call progress indication).=20 In combination, the "in-band call progress indication" and the = "parralel forking indiction" would solve all the scenarios that were worrying me. > -----Original Message----- > From: Ejzak, Richard P (Richard) [mailto:ejzak@lucent.com]=20 > Sent: Monday, May 19, 2003 14:45 > To: 'Gonzalo Camarillo Gonzalez (LMF)'; 'sipping@ietf.org' > Cc: Jon Peterson (E-mail); Rohan Mahy (E-mail); Dean Willis (E-mail) > Subject: RE: [Sipping] Last Call for early media use cases >=20 >=20 > Gonzalo, > Please excuse my tardiness in responding to your request for=20 > early media use cases. I believe the attachment includes an=20 > example configuration and call flow that clearly illustrates=20 > some problems that need to be solved with the existing SIP=20 > early media procedures. >=20 > Thanks, >=20 > Richard Ejzak > Lucent Technologies >=20 > -----Original Message----- > From: Gonzalo Camarillo Gonzalez (LMF)=20 > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Wednesday,=20 > May 14, 2003 2:13 AM > To: 'sipping@ietf.org' > Cc: Jon Peterson (E-mail); Rohan Mahy (E-mail); Dean Willis (E-mail) > Subject: [Sipping] Last Call for early media use cases >=20 >=20 > Folks, >=20 > in the last IETF meeting, we requested early media use cases=20 > that show the need of a "media coming" flag. So far, we have=20 > not received anything. >=20 > We intend to release a new version of the early media draft=20 > in a week or so. So, that is the time you have to send me=20 > your use cases. >=20 > Thanks, >=20 > 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=20 > sip Use sip@ietf.org for new developments of core SIP >=20 >=20 ------_=3D_NextPart_001_01C31EF5.C4F625B4 [Enclosed text/html ] ------_=3D_NextPart_001_01C31EF5.C4F625B4-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP ------_=_NextPart_000_01C32350.9CD8ECA6-- From mailnull@www1.ietf.org Tue May 20 16:12:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28625 for ; Tue, 20 May 2003 16:12:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4KJcR030692 for sipping-archive@odin.ietf.org; Tue, 20 May 2003 15:38: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 h4KJcRB30689 for ; Tue, 20 May 2003 15:38:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28611 for ; Tue, 20 May 2003 16:11:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IDR3-0000OI-00 for sipping-web-archive@ietf.org; Tue, 20 May 2003 16:10:09 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19IDR3-0000OF-00 for sipping-web-archive@ietf.org; Tue, 20 May 2003 16:10: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 h4KJb9B29799; Tue, 20 May 2003 15:37: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 h4KJaEB29707 for ; Tue, 20 May 2003 15:36: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 QAA28562 for ; Tue, 20 May 2003 16:09:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IDOu-0000N6-00 for sipping@ietf.org; Tue, 20 May 2003 16:07:56 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19IDOu-0000Mo-00 for sipping@ietf.org; Tue, 20 May 2003 16:07:56 -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 h4KK8ex7020345; Tue, 20 May 2003 13:08:42 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHH51736; Tue, 20 May 2003 13:01:18 -0700 (PDT) Date: Tue, 20 May 2003 13:09:03 -0700 Subject: Re: [Sipping] [Sipping]Questions on draft-ietf-sipping-connect-reuse-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: <53F74F5A7B94D511841C00B0D0AB16F8B8E539@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, 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 Tue May 20 16:12: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 QAA28655 for ; Tue, 20 May 2003 16:12:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4KJcje30717 for sipping-archive@odin.ietf.org; Tue, 20 May 2003 15: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 h4KJciB30714 for ; Tue, 20 May 2003 15:38: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 QAA28622 for ; Tue, 20 May 2003 16:11:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IDRL-0000OV-00 for sipping-web-archive@ietf.org; Tue, 20 May 2003 16:10:27 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19IDRK-0000OS-00 for sipping-web-archive@ietf.org; Tue, 20 May 2003 16:10: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 h4KJbOB30221; Tue, 20 May 2003 15:37: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 h4KJaRB29715 for ; Tue, 20 May 2003 15:36: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 QAA28569 for ; Tue, 20 May 2003 16:09:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IDP8-0000NG-00 for sipping@ietf.org; Tue, 20 May 2003 16:08:10 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19IDP7-0000N3-00 for sipping@ietf.org; Tue, 20 May 2003 16:08:09 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4KK8veS010801; Tue, 20 May 2003 13:08:58 -0700 (PDT) Received: from [64.101.40.244] (dhcp-64-101-40-244.cisco.com [64.101.40.244]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AEI32530; Tue, 20 May 2003 13:08:56 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 20 May 2003 10:15:24 -0700 Subject: Re: [Sipping] WGLC for draft-ietf-sipping-e164-02.txt From: Cullen Jennings To: Juha Heinanen , Jon Peterson , Sipping Message-ID: In-Reply-To: <16067.37072.865297.570579@harjus.eng.song.fi> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 5/15/03 6:06 AM, "Juha Heinanen" wrote: > Peterson, Jon writes: > >> I don't >> think it is too much to ask that SIP applications utilizing ENUM be generous >> in what they receive with regard to enumservices - it just doesn't seem >> costly to be backwards compatible with the original iteration of the ENUM >> standard. > > check, for example, with cisco and let me know when they accept enum > replies with both formats. today they don't which is a very big > problem. > > -- juha If it is the right thing to do, and does not put huge burden on the implementers (which I don't think this does), I suspect most the vendors will implement both. My guess would be that the timeline for a vendor to support both would be very similar to the timeline to support just the new thing. This is the case for Cisco. I'd rather not have two things if one would do - it's not so much the implementation issues but ongoing interoperability and test issues. I sort of question the idea that this is deployed enough that we have to be backwards compatible on it. Is this really true? I could be convinced either way. Cullen _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue May 20 16:18: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 QAA28754 for ; Tue, 20 May 2003 16:18:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4KJiah30978 for sipping-archive@odin.ietf.org; Tue, 20 May 2003 15:44: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 h4KJiaB30975 for ; Tue, 20 May 2003 15:44: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 QAA28745 for ; Tue, 20 May 2003 16:17:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IDX0-0000QM-00 for sipping-web-archive@ietf.org; Tue, 20 May 2003 16:16:18 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19IDX0-0000QJ-00 for sipping-web-archive@ietf.org; Tue, 20 May 2003 16:16: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 h4KJhQB30925; Tue, 20 May 2003 15:43: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 h4KJgJB30882 for ; Tue, 20 May 2003 15:42:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28704 for ; Tue, 20 May 2003 16:15:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IDUn-0000PZ-00 for sipping@ietf.org; Tue, 20 May 2003 16:14:01 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19IDUn-0000PQ-00 for sipping@ietf.org; Tue, 20 May 2003 16:14:01 -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 h4KKEmx5027990; Tue, 20 May 2003 13:14: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 AHH52437; Tue, 20 May 2003 13:07:27 -0700 (PDT) Date: Tue, 20 May 2003 13:15:15 -0700 Subject: Re: [Sipping] Push-To-Talk with SIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: From: Rohan Mahy In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.552) X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4KJgJB30883 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 h4KJhQB30925 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4KJiaB30975 Content-Transfer-Encoding: 8bit Hi, Push to talk can be implemented by merely setting up a session between the speaker and the target when the UA becomes available and leaving the session open, but only sending audio media over that session when a button is pushed. The session can be verified for liveness by using the session-timer, and the target suddenly reappearing after an absence can be detected using the registration package. Perhaps someone could write a draft describing this usage? thanks, -rohan On Wednesday, May 14, 2003, at 06:46 PM, ???? ??? wrote: > Hello, >   > Nokia, Siemens and Ericsson have announced that they are developing a > push-to-talk application for GSM networks with GPRS and for future 3G > networks. They want to use SIP for signaling but I couldn't find any > more detailed information. >   > Does someone of you know some detail about the PTT signaling with SIP? > Do they care about arbitration if two people want to talk to the same > group at the same time? Are there some drafts or discussions about > this topics? >   > regards, > thomas lee. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 20 19:24: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 TAA05470 for ; Tue, 20 May 2003 19:24:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4KMok612866 for sipping-archive@odin.ietf.org; Tue, 20 May 2003 18:50: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 h4KMojB12863 for ; Tue, 20 May 2003 18:50: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 TAA05464 for ; Tue, 20 May 2003 19:23:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IGR6-0001jI-00 for sipping-web-archive@ietf.org; Tue, 20 May 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 19IGR5-0001jF-00 for sipping-web-archive@ietf.org; Tue, 20 May 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 h4KMncB12794; Tue, 20 May 2003 18:49: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 h4KMlpB12684 for ; Tue, 20 May 2003 18:47: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 TAA05386; Tue, 20 May 2003 19:20:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IGOH-0001i2-00; Tue, 20 May 2003 19:19:29 -0400 Received: from gateway.hns.com ([208.236.67.14]) by ietf-mx with esmtp (Exim 4.12) id 19IGOG-0001hz-00; Tue, 20 May 2003 19:19:28 -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 h4KNKgUk018000; Tue, 20 May 2003 19:20:42 -0400 (EDT) Received: from atlas (atlas.hns.com [139.85.177.110]) by excore8.hns.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h4KNKbsf019006; Tue, 20 May 2003 19:20:37 -0400 (EDT) To: Rohan Mahy Cc: sipping@ietf.org, sipping-admin@ietf.org, thomas.lee@polypix.com Subject: Re: [Sipping] Push-To-Talk with SIP MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Arjun Roychowdhury" Date: Tue, 20 May 2003 19:20:32 -0400 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.12 |February 13, 2003) at 05/20/2003 07:18:39 PM, Serialize complete at 05/20/2003 07:18:39 PM Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4KMlpB12685 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 h4KMncB12794 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4KMojB12863 Content-Transfer-Encoding: 8bit Rohan, though this method has been mentioned before it does have issues like keeping a session active in all billing entities as well as on UAs. This becomes an issue especially when billing agents may not be in media path (in the SIP implementation). In addition, this would mean that end-phones would necessarily have to be able to maintain atleast two calls (one PTT mode, and the other normal mode ). In addition, needless to mention, in PTT any one can burst talk to any other person within a particular group - which has implications , for example, if A is already 'PTTing' with B and C sends a PTT to A, how does A handle the call if its already in 'session' ? Another call ? Adhoc mix ? etc. etc. For this very reason, some people are also considering 'session less' approaches as well, which have their own issues wrt. voice packet continuity. It may be a good idea to discuss an approach and its associated benefits and the requirements. regds arjun -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301 212 7860 Rohan Mahy Sent by: sipping-admin@ietf.org 05/20/2003 04:15 PM To: cc: Subject: Re: [Sipping] Push-To-Talk with SIP Hi, Push to talk can be implemented by merely setting up a session between the speaker and the target when the UA becomes available and leaving the session open, but only sending audio media over that session when a button is pushed. The session can be verified for liveness by using the session-timer, and the target suddenly reappearing after an absence can be detected using the registration package. Perhaps someone could write a draft describing this usage? thanks, -rohan On Wednesday, May 14, 2003, at 06:46 PM, ???? ??? wrote: > Hello, >   > Nokia, Siemens and Ericsson have announced that they are developing a > push-to-talk application for GSM networks with GPRS and for future 3G > networks. They want to use SIP for signaling but I couldn't find any > more detailed information. >   > Does someone of you know some detail about the PTT signaling with SIP? > Do they care about arbitration if two people want to talk to the same > group at the same time? Are there some drafts or discussions about > this topics? >   > regards, > thomas lee. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 20 22:49: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 WAA09248 for ; Tue, 20 May 2003 22:49:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4L2G7426394 for sipping-archive@odin.ietf.org; Tue, 20 May 2003 22:16: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 h4L2G7B26391 for ; Tue, 20 May 2003 22:16: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 WAA09228 for ; Tue, 20 May 2003 22:49:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IJdk-0002ac-00 for sipping-web-archive@ietf.org; Tue, 20 May 2003 22:47:41 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19IJdk-0002aZ-00 for sipping-web-archive@ietf.org; Tue, 20 May 2003 22:47:40 -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 h4L2EpB26347; Tue, 20 May 2003 22:14: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 h4L2DtB26315 for ; Tue, 20 May 2003 22:13:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09220 for ; Tue, 20 May 2003 22:46:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IJbd-0002aN-00 for sipping@ietf.org; Tue, 20 May 2003 22:45:29 -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 19IJbc-0002aK-00 for sipping@ietf.org; Tue, 20 May 2003 22:45:28 -0400 Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h4L2kl0J007175 for ; Wed, 21 May 2003 04:46:47 +0200 (MEST) Received: by esealnt611.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 21 May 2003 04:46:55 +0200 Message-ID: From: "Gonzalo Camarillo Gonzalez (LMF)" To: "'Rohan Mahy'" , thomas.lee@polypix.com Cc: sipping@ietf.org Subject: RE: [Sipping] Push-To-Talk with SIP Date: Wed, 21 May 2003 04:46:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4L2DtB26316 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 h4L2EpB26347 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4L2G7B26391 Content-Transfer-Encoding: 8bit Rohan, a push-to-talk service would include some form of floor control as well. Gonzalo -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com] Sent: Tuesday, May 20, 2003 11:15 PM To: thomas.lee@polypix.com Cc: sipping@ietf.org Subject: Re: [Sipping] Push-To-Talk with SIP Hi, Push to talk can be implemented by merely setting up a session between the speaker and the target when the UA becomes available and leaving the session open, but only sending audio media over that session when a button is pushed. The session can be verified for liveness by using the session-timer, and the target suddenly reappearing after an absence can be detected using the registration package. Perhaps someone could write a draft describing this usage? thanks, -rohan On Wednesday, May 14, 2003, at 06:46 PM, ???? ??? wrote: > Hello, >   > Nokia, Siemens and Ericsson have announced that they are developing a > push-to-talk application for GSM networks with GPRS and for future 3G > networks. They want to use SIP for signaling but I couldn't find any > more detailed information. >   > Does someone of you know some detail about the PTT signaling with SIP? > Do they care about arbitration if two people want to talk to the same > group at the same time? Are there some drafts or discussions about > this topics? >   > regards, > thomas lee. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 20 23:45: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 XAA10107 for ; Tue, 20 May 2003 23:45:08 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4L3BjS29837 for sipping-archive@odin.ietf.org; Tue, 20 May 2003 23:11: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 h4L3BjB29834 for ; Tue, 20 May 2003 23:11: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 XAA10038 for ; Tue, 20 May 2003 23:44:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IKVa-0002lv-00 for sipping-web-archive@ietf.org; Tue, 20 May 2003 23:43:18 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19IKVa-0002ls-00 for sipping-web-archive@ietf.org; Tue, 20 May 2003 23:43: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 h4L37HB29257; Tue, 20 May 2003 23:07: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 h4L369B28770 for ; Tue, 20 May 2003 23:06: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 XAA09975 for ; Tue, 20 May 2003 23:39:02 -0400 (EDT) From: ssubir@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IKQA-0002kA-00 for sipping@ietf.org; Tue, 20 May 2003 23:37:42 -0400 Received: from [164.164.94.116] (helo=hss.hns.com) by ietf-mx with esmtp (Exim 4.12) id 19IKQ8-0002k7-00 for sipping@ietf.org; Tue, 20 May 2003 23:37:41 -0400 Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hss.hns.com (8.11.6/8.11.2) with SMTP id h4L3c9M25010; Wed, 21 May 2003 09:08:10 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256D2D.0013F07C ; Wed, 21 May 2003 09:07:47 +0530 X-Lotus-FromDomain: HSSBLR To: "Gonzalo Camarillo Gonzalez (LMF)" cc: "'Rohan Mahy'" , thomas.lee@polypix.com, sipping@ietf.org Message-ID: <65256D2D.0013EEF4.00@sampark.hss.hns.com> Date: Wed, 21 May 2003 09:07:43 +0530 Subject: RE: [Sipping] Push-To-Talk with SIP 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: , Is there a definition what this service means? I have looked at Comverse, Winphoria, Comworks implementation and that is more of Buddylist based feature where I can see who is available and speak accordingly. If this is what is Push-To-Talk, I am not sure if we need a new draft. May be we need to define this functionality to start with before someone can come with a draft. Thanks, Subir "Gonzalo Camarillo Gonzalez (LMF)" on 05/21/2003 08:16:42 AM To: "'Rohan Mahy'" , thomas.lee@polypix.com cc: sipping@ietf.org (bcc: Subir Saha/HSSBLR) Subject: RE: [Sipping] Push-To-Talk with SIP Rohan, a push-to-talk service would include some form of floor control as well. Gonzalo -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com] Sent: Tuesday, May 20, 2003 11:15 PM To: thomas.lee@polypix.com Cc: sipping@ietf.org Subject: Re: [Sipping] Push-To-Talk with SIP Hi, Push to talk can be implemented by merely setting up a session between the speaker and the target when the UA becomes available and leaving the session open, but only sending audio media over that session when a button is pushed. The session can be verified for liveness by using the session-timer, and the target suddenly reappearing after an absence can be detected using the registration package. Perhaps someone could write a draft describing this usage? thanks, -rohan On Wednesday, May 14, 2003, at 06:46 PM, ???? ??? wrote: > Hello, > > Nokia, Siemens and Ericsson have announced that they are developing a > push-to-talk application for GSM networks with GPRS and for future 3G > networks. They want to use SIP for signaling but I couldn't find any > more detailed information. > > Does someone of you know some detail about the PTT signaling with SIP? > Do they care about arbitration if two people want to talk to the same > group at the same time? Are there some drafts or discussions about > this topics? > > regards, > thomas lee. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 20 23:56: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 XAA10267 for ; Tue, 20 May 2003 23:56:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4L3NZS30175 for sipping-archive@odin.ietf.org; Tue, 20 May 2003 23:23: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 h4L3NZB30172 for ; Tue, 20 May 2003 23:23: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 XAA10262 for ; Tue, 20 May 2003 23:56:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IKh2-0002od-00 for sipping-web-archive@ietf.org; Tue, 20 May 2003 23:55:08 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19IKh1-0002oa-00 for sipping-web-archive@ietf.org; Tue, 20 May 2003 23:55: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 h4L3JGB30030; Tue, 20 May 2003 23:19: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 h4L3I7B29998 for ; Tue, 20 May 2003 23:18:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10187 for ; Tue, 20 May 2003 23:50:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IKbj-0002nS-00 for sipping@ietf.org; Tue, 20 May 2003 23:49:39 -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 19IKbi-0002nO-00 for sipping@ietf.org; Tue, 20 May 2003 23:49:38 -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 h4L3op0J013396; Wed, 21 May 2003 05:50:51 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 21 May 2003 05:50:58 +0200 Message-ID: From: "Gonzalo Camarillo Gonzalez (LMF)" To: "'ssubir@hss.hns.com'" Cc: "'Rohan Mahy'" , thomas.lee@polypix.com, sipping@ietf.org Subject: RE: [Sipping] Push-To-Talk with SIP Date: Wed, 21 May 2003 05:50:46 +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: , Subir, as far as I understand, "Push-To-Talk" is a service offered by a specific company. Other companies offering that type of service need to call it something different. All those services have common functionality, but they have differences as well. There is not *a* PTT service definition (right now). Gonzalo -----Original Message----- From: ssubir@hss.hns.com [mailto:ssubir@hss.hns.com] Sent: Wednesday, May 21, 2003 6:38 AM To: Gonzalo Camarillo Gonzalez (LMF) Cc: 'Rohan Mahy'; thomas.lee@polypix.com; sipping@ietf.org Subject: RE: [Sipping] Push-To-Talk with SIP Is there a definition what this service means? I have looked at Comverse, Winphoria, Comworks implementation and that is more of Buddylist based feature where I can see who is available and speak accordingly. If this is what is Push-To-Talk, I am not sure if we need a new draft. May be we need to define this functionality to start with before someone can come with a draft. Thanks, Subir "Gonzalo Camarillo Gonzalez (LMF)" on 05/21/2003 08:16:42 AM To: "'Rohan Mahy'" , thomas.lee@polypix.com cc: sipping@ietf.org (bcc: Subir Saha/HSSBLR) Subject: RE: [Sipping] Push-To-Talk with SIP Rohan, a push-to-talk service would include some form of floor control as well. Gonzalo -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com] Sent: Tuesday, May 20, 2003 11:15 PM To: thomas.lee@polypix.com Cc: sipping@ietf.org Subject: Re: [Sipping] Push-To-Talk with SIP Hi, Push to talk can be implemented by merely setting up a session between the speaker and the target when the UA becomes available and leaving the session open, but only sending audio media over that session when a button is pushed. The session can be verified for liveness by using the session-timer, and the target suddenly reappearing after an absence can be detected using the registration package. Perhaps someone could write a draft describing this usage? thanks, -rohan On Wednesday, May 14, 2003, at 06:46 PM, ???? ??? wrote: > Hello, > > Nokia, Siemens and Ericsson have announced that they are developing a > push-to-talk application for GSM networks with GPRS and for future 3G > networks. They want to use SIP for signaling but I couldn't find any > more detailed information. > > Does someone of you know some detail about the PTT signaling with SIP? > Do they care about arbitration if two people want to talk to the same > group at the same time? Are there some drafts or discussions about > this topics? > > regards, > thomas lee. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 21 00:11: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 AAA10551 for ; Wed, 21 May 2003 00:11:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4L3cMv31505 for sipping-archive@odin.ietf.org; Tue, 20 May 2003 23: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 h4L3cLB31502 for ; Tue, 20 May 2003 23:38:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10532 for ; Wed, 21 May 2003 00:11:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IKvK-0002ri-00 for sipping-web-archive@ietf.org; Wed, 21 May 2003 00:09:54 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19IKvJ-0002rf-00 for sipping-web-archive@ietf.org; Wed, 21 May 2003 00:09: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 h4L3bBB30876; Tue, 20 May 2003 23:37: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 h4L3aTB30583 for ; Tue, 20 May 2003 23:36: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 AAA10490 for ; Wed, 21 May 2003 00:09:21 -0400 (EDT) From: ssubir@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IKtV-0002rG-00 for sipping@ietf.org; Wed, 21 May 2003 00:08:01 -0400 Received: from [164.164.94.116] (helo=hss.hns.com) by ietf-mx with esmtp (Exim 4.12) id 19IKtS-0002rD-00 for sipping@ietf.org; Wed, 21 May 2003 00:07:59 -0400 Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hss.hns.com (8.11.6/8.11.2) with SMTP id h4L48DM25502; Wed, 21 May 2003 09:38:14 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256D2D.0016B3B0 ; Wed, 21 May 2003 09:37:57 +0530 X-Lotus-FromDomain: HSSBLR To: "Gonzalo Camarillo Gonzalez (LMF)" cc: "'Rohan Mahy'" , thomas.lee@polypix.com, sipping@ietf.org Message-ID: <65256D2D.0016B2E6.00@sampark.hss.hns.com> Date: Wed, 21 May 2003 09:37:55 +0530 Subject: RE: [Sipping] Push-To-Talk with SIP 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: , Gonzalo: In that case, may be, we can start form here - trying to define a Push to talk service and then see what is missing in SIP/SIMPLE to achive such functionality! Subir "Gonzalo Camarillo Gonzalez (LMF)" on 05/21/2003 09:20:46 AM To: Subir Saha/HSSBLR cc: "'Rohan Mahy'" , thomas.lee@polypix.com, sipping@ietf.org Subject: RE: [Sipping] Push-To-Talk with SIP Subir, as far as I understand, "Push-To-Talk" is a service offered by a specific company. Other companies offering that type of service need to call it something different. All those services have common functionality, but they have differences as well. There is not *a* PTT service definition (right now). Gonzalo -----Original Message----- From: ssubir@hss.hns.com [mailto:ssubir@hss.hns.com] Sent: Wednesday, May 21, 2003 6:38 AM To: Gonzalo Camarillo Gonzalez (LMF) Cc: 'Rohan Mahy'; thomas.lee@polypix.com; sipping@ietf.org Subject: RE: [Sipping] Push-To-Talk with SIP Is there a definition what this service means? I have looked at Comverse, Winphoria, Comworks implementation and that is more of Buddylist based feature where I can see who is available and speak accordingly. If this is what is Push-To-Talk, I am not sure if we need a new draft. May be we need to define this functionality to start with before someone can come with a draft. Thanks, Subir "Gonzalo Camarillo Gonzalez (LMF)" on 05/21/2003 08:16:42 AM To: "'Rohan Mahy'" , thomas.lee@polypix.com cc: sipping@ietf.org (bcc: Subir Saha/HSSBLR) Subject: RE: [Sipping] Push-To-Talk with SIP Rohan, a push-to-talk service would include some form of floor control as well. Gonzalo -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com] Sent: Tuesday, May 20, 2003 11:15 PM To: thomas.lee@polypix.com Cc: sipping@ietf.org Subject: Re: [Sipping] Push-To-Talk with SIP Hi, Push to talk can be implemented by merely setting up a session between the speaker and the target when the UA becomes available and leaving the session open, but only sending audio media over that session when a button is pushed. The session can be verified for liveness by using the session-timer, and the target suddenly reappearing after an absence can be detected using the registration package. Perhaps someone could write a draft describing this usage? thanks, -rohan On Wednesday, May 14, 2003, at 06:46 PM, ???? ??? wrote: > Hello, > > Nokia, Siemens and Ericsson have announced that they are developing a > push-to-talk application for GSM networks with GPRS and for future 3G > networks. They want to use SIP for signaling but I couldn't find any > more detailed information. > > Does someone of you know some detail about the PTT signaling with SIP? > Do they care about arbitration if two people want to talk to the same > group at the same time? Are there some drafts or discussions about > this topics? > > regards, > thomas lee. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 21 01:31: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 BAA12799 for ; Wed, 21 May 2003 01:31:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4L4wC303653 for sipping-archive@odin.ietf.org; Wed, 21 May 2003 00:58: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 h4L4wCB03650 for ; Wed, 21 May 2003 00:58: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 BAA12786 for ; Wed, 21 May 2003 01:31:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IMAY-0003C3-00 for sipping-web-archive@ietf.org; Wed, 21 May 2003 01:29:43 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19IMAY-0003C0-00 for sipping-web-archive@ietf.org; Wed, 21 May 2003 01:29: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 h4L4vBB03606; Wed, 21 May 2003 00:57: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 h4JILOB07935 for ; Mon, 19 May 2003 14:21: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 OAA00676; Mon, 19 May 2003 14:51:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HplT-0005lJ-00; Mon, 19 May 2003 14:53:39 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19HplN-0005l6-00; Mon, 19 May 2003 14:53:33 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h4JIrrx5004438; Mon, 19 May 2003 11:53:53 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AEH18338; Mon, 19 May 2003 11:53:52 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA06598; Mon, 19 May 2003 11:53:52 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16073.10303.881278.809327@thomasm-u1.cisco.com> Date: Mon, 19 May 2003 11:53:51 -0700 (PDT) To: "Santharam, Arun [NTWK SVCS]" Cc: "Rajarshi Chakraborty" , , , , In-Reply-To: <28B9108644E492469B911D587AABC97C023DEB80@PKDWB01C.ad.sprint.com> References: <28B9108644E492469B911D587AABC97C023DEB80@PKDWB01C.ad.sprint.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Subject: [Sipping] [Sip] RE: SIP mobility in WLAN Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Santharam, Arun [NTWK SVCS] writes: > > 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. I think it's a little bit more complicated than this. As with most things, it often makes sense to have logic at many different layers depending on the actual situation you find yourself in. For example, since there isn't route optimization for IPv4, a reinvite with the new correct CoA would rid yourself of the dog-leg through the home agent. But it might complicate QoS reservations and/or treatment, etc. Which is a round about way of saying "it depends". Mike _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed May 21 01:31: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 BAA12813 for ; Wed, 21 May 2003 01:31:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4L4wZQ03675 for sipping-archive@odin.ietf.org; Wed, 21 May 2003 00:58: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 h4L4wZB03672 for ; Wed, 21 May 2003 00:58: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 BAA12796 for ; Wed, 21 May 2003 01:31:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IMAv-0003CE-00 for sipping-web-archive@ietf.org; Wed, 21 May 2003 01:30:05 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19IMAu-0003CB-00 for sipping-web-archive@ietf.org; Wed, 21 May 2003 01:30: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 h4L4v7B03585; Wed, 21 May 2003 00:57: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 h4JI23B06254 for ; Mon, 19 May 2003 14:02:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29866; Mon, 19 May 2003 14:32:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HpSU-0005Zs-00; Mon, 19 May 2003 14:34:02 -0400 Received: from smtpgw6.sprintspectrum.com ([207.40.188.14]) by ietf-mx with esmtp (Exim 4.12) id 19HpSO-0005Zn-00; Mon, 19 May 2003 14:33:56 -0400 Received: from smtpgw8.it.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw6.sprintspectrum.com (8.12.9/8.12.8) with ESMTP id h4JIYg4x011125; Mon, 19 May 2003 13:34:42 -0500 (CDT) Received: from PKDWG02A.ad.sprint.com (PKDWG02A.corp.sprint.com [10.185.12.80]) by smtpgw8.it.sprintspectrum.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4JIYgQ07516; Mon, 19 May 2003 13:34:42 -0500 (CDT) Received: from PKDWB01C.ad.sprint.com ([10.185.12.21]) by PKDWG02A.ad.sprint.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 19 May 2003 13:34:38 -0500 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" Date: Mon, 19 May 2003 13:34:33 -0500 Message-ID: <28B9108644E492469B911D587AABC97C023DEB80@PKDWB01C.ad.sprint.com> Thread-Topic: SIP mobility in WLAN Thread-Index: AcMdwPQXxStz+QMGSTyaItcsGcp5lAAc8ETQ From: "Santharam, Arun [NTWK SVCS]" To: "Rajarshi Chakraborty" , , , Cc: X-OriginalArrivalTime: 19 May 2003 18:34:38.0897 (UTC) FILETIME=[4E1A9210:01C31E35] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4JI23B06256 Subject: [Sipping] RE: SIP mobility in WLAN Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit If 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 From mailnull@www1.ietf.org Wed May 21 09:00: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 JAA18572 for ; Wed, 21 May 2003 09:00:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4LCRSq14332 for sipping-archive@odin.ietf.org; Wed, 21 May 2003 08:27: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 h4LCRRB14328 for ; Wed, 21 May 2003 08:27:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18545 for ; Wed, 21 May 2003 09:00:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ITBB-0005zD-00 for sipping-web-archive@ietf.org; Wed, 21 May 2003 08:58:49 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ITBA-0005zA-00 for sipping-web-archive@ietf.org; Wed, 21 May 2003 08:58: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 h4LCMnB13919; Wed, 21 May 2003 08:22: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 h4LCK1B13657 for ; Wed, 21 May 2003 08:20: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 IAA18079 for ; Wed, 21 May 2003 08:52:44 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IT3y-0005pn-00 for sipping@ietf.org; Wed, 21 May 2003 08:51:22 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19IT3x-0005pk-00 for sipping@ietf.org; Wed, 21 May 2003 08:51:22 -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 h4LCqcD26626 for ; Wed, 21 May 2003 15:52:38 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 21 May 2003 15:52:37 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 21 May 2003 15:52:37 +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] Push-To-Talk with SIP Date: Wed, 21 May 2003 15:52:36 +0300 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194527B@esebe013.ntc.nokia.com> Thread-Topic: [Sipping] Push-To-Talk with SIP Thread-Index: AcMfDTL96oTY0JtJTMezi2BPhgmTpwAiRctw To: , Cc: X-OriginalArrivalTime: 21 May 2003 12:52:37.0619 (UTC) FILETIME=[DB4B8C30:01C31F97] X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4LCK1B13658 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 h4LCMnB13919 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4LCRRB14328 Content-Transfer-Encoding: 8bit Hi Rohan, I think this is one way to look at the push to talk feature, but maybe not exactly "mainstream". Most of the push to talk services I'm aware of are similar to a walkie talkie service, where a group of people are participating, out of which only one at a time can send media to the others. "Requesting the floor" in this case is usually done with the "tangent" button. So in my opinion, push to talk is a conference, with a specific type of conference and media policy associated with it. As such, I don't think it's the IETF's business to define those policies but provide tools for setting/manipulating them, which I guess the conference DT is already doing. -Aki > -----Original Message----- > From: ext Rohan Mahy [mailto:rohan@cisco.com] > Sent: 20 May, 2003 23:15 > To: thomas.lee@polypix.com > Cc: sipping@ietf.org > Subject: Re: [Sipping] Push-To-Talk with SIP > > > > Hi, > > Push to talk can be implemented by merely setting up a > session between > the speaker and the target when the UA becomes available and leaving > the session open, but only sending audio media over that > session when a > button is pushed. The session can be verified for liveness by using > the session-timer, and the target suddenly reappearing after > an absence > can be detected using the registration package. Perhaps > someone could > write a draft describing this usage? > > thanks, > -rohan > > > On Wednesday, May 14, 2003, at 06:46 PM, ???? ??? wrote: > > > Hello, > >   > > Nokia, Siemens and Ericsson have announced that they are > developing a > > push-to-talk application for GSM networks with GPRS and > for future 3G > > networks. They want to use SIP for signaling but I > couldn't find any > > more detailed information. > >   > > Does someone of you know some detail about the PTT > signaling with SIP? > > Do they care about arbitration if two people want to talk > to the same > > group at the same time? Are there some drafts or discussions about > > this topics? > >   > > regards, > > thomas lee. > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 21 10:06: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 KAA21971 for ; Wed, 21 May 2003 10:06:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4LDXa820240 for sipping-archive@odin.ietf.org; Wed, 21 May 2003 09:33: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 h4LDXaB20237 for ; Wed, 21 May 2003 09:33: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 KAA21915 for ; Wed, 21 May 2003 10:06:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IUD9-0006z7-00 for sipping-web-archive@ietf.org; Wed, 21 May 2003 10:04:55 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19IUD9-0006z4-00 for sipping-web-archive@ietf.org; Wed, 21 May 2003 10:04: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 h4LDVcB20085; Wed, 21 May 2003 09: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 h4LDSVB19915 for ; Wed, 21 May 2003 09:28: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 KAA21485 for ; Wed, 21 May 2003 10:01:11 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IU8E-0006wY-00 for sipping@ietf.org; Wed, 21 May 2003 09:59:50 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19IU8E-0006wV-00 for sipping@ietf.org; Wed, 21 May 2003 09:59:50 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4LE1B717736 for ; Wed, 21 May 2003 17:01:11 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 21 May 2003 17:01:07 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 21 May 2003 17:01:06 +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: Wed, 21 May 2003 17:01:06 +0300 Message-ID: Thread-Topic: [Sipping] Push-To-Talk with SIP Thread-Index: AcMfDTL96oTY0JtJTMezi2BPhgmTpwAiRctwAAKhabA= To: X-OriginalArrivalTime: 21 May 2003 14:01:07.0008 (UTC) FILETIME=[6CAE8C00:01C31FA1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4LDSVB19916 Subject: [Sipping] Conferencing BOF/WG Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, There has been discussion about a possible (SIP?) Conferencing BOF in the forthcoming Vienna IETF meeting, so that Conferencing related work from SIPPING and MMUSIC would be trasfered to a new WG. Is this already definite or just a proposal? Is anyone working on the charter proposal for this? Markus _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 21 10:17: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 KAA23018 for ; Wed, 21 May 2003 10:17:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4LDiXY21763 for sipping-archive@odin.ietf.org; Wed, 21 May 2003 09:44: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 h4LDiWB21760 for ; Wed, 21 May 2003 09:44: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 KAA22982 for ; Wed, 21 May 2003 10:17:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IUNk-00073f-00 for sipping-web-archive@ietf.org; Wed, 21 May 2003 10:15:52 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19IUNj-00073c-00 for sipping-web-archive@ietf.org; Wed, 21 May 2003 10:15: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 h4LDhJB21679; Wed, 21 May 2003 09:43: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 h4LDguB21625 for ; Wed, 21 May 2003 09:42: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 KAA22893; Wed, 21 May 2003 10:15:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IUMB-00072t-00; Wed, 21 May 2003 10:14:15 -0400 Received: from gateway.hns.com ([208.236.67.14]) by ietf-mx with esmtp (Exim 4.12) id 19IUMA-00072q-00; Wed, 21 May 2003 10:14:14 -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 h4LEFTUk007296; Wed, 21 May 2003 10:15:29 -0400 (EDT) Received: from atlas (atlas.hns.com [139.85.177.110]) by excore8.hns.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h4LEFNsf003348; Wed, 21 May 2003 10:15:23 -0400 (EDT) To: aki.niemi@nokia.com Cc: rohan@cisco.com, sipping@ietf.org, sipping-admin@ietf.org, thomas.lee@polypix.com Subject: RE: [Sipping] Push-To-Talk with SIP MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Arjun Roychowdhury" Date: Wed, 21 May 2003 10:15:22 -0400 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.12 |February 13, 2003) at 05/21/2003 10:13:25 AM, Serialize complete at 05/21/2003 10:13:25 AM Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4LDguB21626 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 h4LDhJB21679 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4LDiWB21760 Content-Transfer-Encoding: 8bit I think to avoid confusion, it may be better to reword this is a 'session less two way radio service', with session less being the key item. I believe this was the original question of the poster. Whether this particular approach makes sense to be done in SIP and especially in the purview of the IETF is another question. regds arjun -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301 212 7860 aki.niemi@nokia.com Sent by: sipping-admin@ietf.org 05/21/2003 08:52 AM To: , cc: Subject: RE: [Sipping] Push-To-Talk with SIP Hi Rohan, I think this is one way to look at the push to talk feature, but maybe not exactly "mainstream". Most of the push to talk services I'm aware of are similar to a walkie talkie service, where a group of people are participating, out of which only one at a time can send media to the others. "Requesting the floor" in this case is usually done with the "tangent" button. So in my opinion, push to talk is a conference, with a specific type of conference and media policy associated with it. As such, I don't think it's the IETF's business to define those policies but provide tools for setting/manipulating them, which I guess the conference DT is already doing. -Aki > -----Original Message----- > From: ext Rohan Mahy [mailto:rohan@cisco.com] > Sent: 20 May, 2003 23:15 > To: thomas.lee@polypix.com > Cc: sipping@ietf.org > Subject: Re: [Sipping] Push-To-Talk with SIP > > > > Hi, > > Push to talk can be implemented by merely setting up a > session between > the speaker and the target when the UA becomes available and leaving > the session open, but only sending audio media over that > session when a > button is pushed. The session can be verified for liveness by using > the session-timer, and the target suddenly reappearing after > an absence > can be detected using the registration package. Perhaps > someone could > write a draft describing this usage? > > thanks, > -rohan > > > On Wednesday, May 14, 2003, at 06:46 PM, ???? ??? wrote: > > > Hello, > >   > > Nokia, Siemens and Ericsson have announced that they are > developing a > > push-to-talk application for GSM networks with GPRS and > for future 3G > > networks. They want to use SIP for signaling but I > couldn't find any > > more detailed information. > >   > > Does someone of you know some detail about the PTT > signaling with SIP? > > Do they care about arbitration if two people want to talk > to the same > > group at the same time? Are there some drafts or discussions about > > this topics? > >   > > regards, > > thomas lee. > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 21 12:40: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 MAA27733 for ; Wed, 21 May 2003 12:40:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4LG7fU02536 for sipping-archive@odin.ietf.org; Wed, 21 May 2003 12:07:41 -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 h4LG7fB02531 for ; Wed, 21 May 2003 12:07: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 MAA27711 for ; Wed, 21 May 2003 12:40:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IWcE-0000SD-00 for sipping-web-archive@ietf.org; Wed, 21 May 2003 12:38:58 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19IWcD-0000SA-00 for sipping-web-archive@ietf.org; Wed, 21 May 2003 12:38: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 h4LG6PB01522; Wed, 21 May 2003 12:06: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 h4LG2LB00888 for ; Wed, 21 May 2003 12:02: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 MAA27532 for ; Wed, 21 May 2003 12:34:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IWX3-0000OJ-00 for sipping@ietf.org; Wed, 21 May 2003 12:33:37 -0400 Received: from pmesmtp02.wcom.com ([199.249.20.2]) by ietf-mx with esmtp (Exim 4.12) id 19IWX2-0000Nz-00 for sipping@ietf.org; Wed, 21 May 2003 12:33:36 -0400 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0HF80052XWPGRK@firewall.wcom.com> for sipping@ietf.org; Wed, 21 May 2003 16:34:28 +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 <0HF800701WOVP2@pmismtp02.wcomnet.com>; Wed, 21 May 2003 16:34:28 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.104.3]) by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HF800703WNPJ0@pmismtp02.wcomnet.com>; Wed, 21 May 2003 16:33:27 +0000 (GMT) Date: Wed, 21 May 2003 11:33:25 -0500 From: Alan Johnston Subject: Re: [Sipping] Conferencing BOF/WG In-reply-to: X-Sender: Alan.Johnston@pop.mcit.com To: Markus.Isomaki@nokia.com, sipping@ietf.org Message-id: <5.2.1.1.0.20030521112834.01910690@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 Markus, Yes, a BOF is being planned but is not on the agenda yet. The documents which have not become SIPPING WG documents from the SIPPING Design Team would be the basis (http://ee.wustl.edu/~alan/sip-conf) When we have more news including a mailing list for discussion of the proposed charter and documents, we'll announce on the SIP, SIPPING, and MMUSIC lists. Thanks, Alan Johnston MCI At 05:01 PM 5/21/2003 +0300, Markus.Isomaki@nokia.com wrote: >Hi, > >There has been discussion about a possible (SIP?) Conferencing BOF in the >forthcoming Vienna IETF meeting, so that Conferencing related work from >SIPPING and MMUSIC would be trasfered to a new WG. Is this already >definite or just a proposal? Is anyone working on the charter proposal for >this? > >Markus >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 22 05:38: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 FAA06205 for ; Thu, 22 May 2003 05:38:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4M95uu16908 for sipping-archive@odin.ietf.org; Thu, 22 May 2003 05:05: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 h4M95uB16905 for ; Thu, 22 May 2003 05:05: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 FAA06180 for ; Thu, 22 May 2003 05:38:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ImVH-00078Y-00 for sipping-web-archive@ietf.org; Thu, 22 May 2003 05:36:51 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ImVG-00078U-00 for sipping-web-archive@ietf.org; Thu, 22 May 2003 05:36: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 h4M94XB16798; Thu, 22 May 2003 05: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 h4M90GB16572 for ; Thu, 22 May 2003 05:00:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05964; Thu, 22 May 2003 05:32:33 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ImPn-00074W-00; Thu, 22 May 2003 05:31:11 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19ImPm-00074T-00; Thu, 22 May 2003 05:31:10 -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 h4M9WWD24545; Thu, 22 May 2003 12:32:32 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 22 May 2003 12:32:28 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 22 May 2003 12:32:27 +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] Push-To-Talk with SIP Date: Thu, 22 May 2003 12:32:26 +0300 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194527E@esebe013.ntc.nokia.com> Thread-Topic: [Sipping] Push-To-Talk with SIP Thread-Index: AcMfo3XSWkPVwZ3FRoG/qHOdNhyuUgAoAlRA To: Cc: , , , X-OriginalArrivalTime: 22 May 2003 09:32:27.0333 (UTC) FILETIME=[0F051750:01C32045] X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4M90GB16573 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 h4M94XB16798 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4M95uB16905 Content-Transfer-Encoding: 8bit Hi Arjun, I don't really understand what you mean by 'session less', could you elaborate a bit? Do you mean to say there is no application state maintained at the endpoints? And to me, the original question seemed to be whether there have been any drafts or discussions w.r.t. push to talk and SIP in the IETF. And the enswer to that would have to be no, but the conferencing work in SIPPING seems to be covering related issues, e.g., floor control, and media policy. Regards, Aki > -----Original Message----- > From: ext Arjun Roychowdhury [mailto:aroychow@hns.com] > Sent: 21 May, 2003 17:15 > To: Niemi Aki (NMP/Helsinki) > Cc: rohan@cisco.com; sipping@ietf.org; sipping-admin@ietf.org; > thomas.lee@polypix.com > Subject: RE: [Sipping] Push-To-Talk with SIP > > > I think to avoid confusion, it may be better to reword this > is a 'session > less two way radio service', > with session less being the key item. I believe this was the > original > question of the poster. > > Whether this particular approach makes sense to be done in SIP and > especially in the purview of the IETF is another question. > > regds > arjun > > -- > Arjun Roychowdhury @ Hughes Software Systems > 11717 Exploration Lane, Germantown MD 20876 > (O): 301 212 7860 > > > > > aki.niemi@nokia.com > Sent by: sipping-admin@ietf.org > 05/21/2003 08:52 AM > > > To: , > cc: > Subject: RE: [Sipping] Push-To-Talk with SIP > > > Hi Rohan, > > I think this is one way to look at the push to talk feature, > but maybe not > exactly "mainstream". Most of the push to talk services I'm > aware of are > similar to a walkie talkie service, where a group of people are > participating, out of which only one at a time can send media to the > others. "Requesting the floor" in this case is usually done with the > "tangent" button. > > So in my opinion, push to talk is a conference, with a > specific type of > conference and media policy associated with it. As such, I > don't think > it's the IETF's business to define those policies but > provide tools for > setting/manipulating them, which I guess the conference DT > is already > doing. > > -Aki > > > -----Original Message----- > > From: ext Rohan Mahy [mailto:rohan@cisco.com] > > Sent: 20 May, 2003 23:15 > > To: thomas.lee@polypix.com > > Cc: sipping@ietf.org > > Subject: Re: [Sipping] Push-To-Talk with SIP > > > > > > > > Hi, > > > > Push to talk can be implemented by merely setting up a > > session between > > the speaker and the target when the UA becomes available > and leaving > > the session open, but only sending audio media over that > > session when a > > button is pushed. The session can be verified for > liveness by using > > the session-timer, and the target suddenly reappearing after > > an absence > > can be detected using the registration package. Perhaps > > someone could > > write a draft describing this usage? > > > > thanks, > > -rohan > > > > > > On Wednesday, May 14, 2003, at 06:46 PM, ???? ??? wrote: > > > > > Hello, > > >   > > > Nokia, Siemens and Ericsson have announced that they are > > developing a > > > push-to-talk application for GSM networks with GPRS and > > for future 3G > > > networks. They want to use SIP for signaling but I > > couldn't find any > > > more detailed information. > > >   > > > Does someone of you know some detail about the PTT > > signaling with SIP? > > > Do they care about arbitration if two people want to talk > > to the same > > > group at the same time? Are there some drafts or > discussions about > > > this topics? > > >   > > > regards, > > > thomas lee. > > > > _______________________________________________ > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 22 08:17: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 IAA10736 for ; Thu, 22 May 2003 08:17:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4MBijN31466 for sipping-archive@odin.ietf.org; Thu, 22 May 2003 07:44: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 h4MBijB31462 for ; Thu, 22 May 2003 07:44: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 IAA10732 for ; Thu, 22 May 2003 08:16:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ioyu-0000ny-00 for sipping-web-archive@ietf.org; Thu, 22 May 2003 08:15:36 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ioyu-0000nv-00 for sipping-web-archive@ietf.org; Thu, 22 May 2003 08:15: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 h4MBgVB31316; Thu, 22 May 2003 07:42: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 h4MBfKB31269 for ; Thu, 22 May 2003 07:41: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 IAA10635 for ; Thu, 22 May 2003 08:13:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Iovc-0000lD-00 for sipping@ietf.org; Thu, 22 May 2003 08:12:12 -0400 Received: from smtp2.dataconnection.com ([192.91.191.8] helo=miles.dataconnection.com) by ietf-mx with esmtp (Exim 4.12) id 19Iovb-0000kA-00 for sipping@ietf.org; Thu, 22 May 2003 08:12:11 -0400 Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2656.59) id ; Thu, 22 May 2003 13:13:09 +0100 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F8B8E554@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: Thu, 22 May 2003 13:12:48 +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: , 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. 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. 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? 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 Thu May 22 08:28: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 IAA11145 for ; Thu, 22 May 2003 08:28:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4MBtuS32309 for sipping-archive@odin.ietf.org; Thu, 22 May 2003 07:55: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 h4MBtuB32306 for ; Thu, 22 May 2003 07: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 IAA11127 for ; Thu, 22 May 2003 08:28:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ip9j-0000vW-00 for sipping-web-archive@ietf.org; Thu, 22 May 2003 08:26:47 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ip9i-0000vT-00 for sipping-web-archive@ietf.org; Thu, 22 May 2003 08:26: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 h4MBm8B31777; Thu, 22 May 2003 07:48: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 h4MBl4B31708 for ; Thu, 22 May 2003 07:47:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10858; Thu, 22 May 2003 08:19:18 -0400 (EDT) From: aroychow@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ip19-0000pP-00; Thu, 22 May 2003 08:17:55 -0400 Received: from gateway.hns.com ([208.236.67.14]) by ietf-mx with esmtp (Exim 4.12) id 19Ip16-0000pL-00; Thu, 22 May 2003 08:17:52 -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 h4MCJ7un008571; Thu, 22 May 2003 08:19:08 -0400 (EDT) Received: from atlas (atlas.hns.com [139.85.177.110]) by excore8.hns.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h4MCJ1sf012222; Thu, 22 May 2003 08:19:01 -0400 (EDT) To: aki.niemi@nokia.com Cc: aroychow@hns.com, rohan@cisco.com, sipping@ietf.org, sipping-admin@ietf.org, thomas.lee@polypix.com Subject: RE: [Sipping] Push-To-Talk with SIP MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Thu, 22 May 2003 08:18:27 -0400 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.12 |February 13, 2003) at 05/22/2003 08:17:04 AM, Serialize complete at 05/22/2003 08:17:04 AM Content-Type: multipart/alternative; boundary="=_alternative 0043997085256D2E_=" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 0043997085256D2E_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Aki, By 'session less' I mean not having an INVITE-OK-ACK to actually establish = the call before you could talk. Application state would be maintained during one 'push-release' operation and forgotten after that (except for=20 the administrative states like which was the gruop set I was talking to). Different algorithms have been suggested for this 'voice over IM' =3D> some= =20 are also patented @ the uspto (I think someone had posted the patent no. in the impp archive some time ago) Anyway, therefore, I realize this may not be something that the ietf sip=20 grp wants to take up unless there is a compelling reason=20 go into into this 2 way radio service. With respect to the original Q, I=20 agree that one could conceptualize that a call in session with RTP bursts and conferencing thrown in could look like a '2 way radio service'=20 =3D but due to the nature of its persistance of state for a much longer time than currently known implementations not using SIP, the charging=20 model and complexities would likely not be the same, for what ever its=20 worth. regds arjun -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301 212 7860=20 aki.niemi@nokia.com Sent by: sipping-admin@ietf.org 05/22/2003 05:32 AM =20 To: cc: , , ,=20 Subject: RE: [Sipping] Push-To-Talk with SIP Hi Arjun, I don't really understand what you mean by 'session less', could you=20 elaborate a bit? Do you mean to say there is no application state=20 maintained at the endpoints?=20 And to me, the original question seemed to be whether there have been any=20 drafts or discussions w.r.t. push to talk and SIP in the IETF. And the=20 enswer to that would have to be no, but the conferencing work in SIPPING=20 seems to be covering related issues, e.g., floor control, and media=20 policy. Regards,=20 Aki > -----Original Message----- > From: ext Arjun Roychowdhury [mailto:aroychow@hns.com] > Sent: 21 May, 2003 17:15 > To: Niemi Aki (NMP/Helsinki) > Cc: rohan@cisco.com; sipping@ietf.org; sipping-admin@ietf.org; > thomas.lee@polypix.com > Subject: RE: [Sipping] Push-To-Talk with SIP >=20 >=20 > I think to avoid confusion, it may be better to reword this=20 > is a 'session=20 > less two way radio service', > with session less being the key item. I believe this was the=20 > original=20 > question of the poster. >=20 > Whether this particular approach makes sense to be done in SIP and=20 > especially in the purview of the IETF is another question. >=20 > regds > arjun >=20 > -- > Arjun Roychowdhury @ Hughes Software Systems > 11717 Exploration Lane, Germantown MD 20876 > (O): 301 212 7860=20 >=20 >=20 >=20 >=20 > aki.niemi@nokia.com > Sent by: sipping-admin@ietf.org > 05/21/2003 08:52 AM >=20 >=20 > To: , > cc: > Subject: RE: [Sipping] Push-To-Talk with SIP >=20 >=20 > Hi Rohan, >=20 > I think this is one way to look at the push to talk feature,=20 > but maybe not=20 > exactly "mainstream". Most of the push to talk services I'm=20 > aware of are=20 > similar to a walkie talkie service, where a group of people are=20 > participating, out of which only one at a time can send media to the=20 > others. "Requesting the floor" in this case is usually done with the=20 > "tangent" button. >=20 > So in my opinion, push to talk is a conference, with a=20 > specific type of=20 > conference and media policy associated with it. As such, I=20 > don't think=20 > it's the IETF's business to define those policies but=20 > provide tools for=20 > setting/manipulating them, which I guess the conference DT=20 > is already=20 > doing.=20 >=20 > -Aki >=20 > > -----Original Message----- > > From: ext Rohan Mahy [mailto:rohan@cisco.com] > > Sent: 20 May, 2003 23:15 > > To: thomas.lee@polypix.com > > Cc: sipping@ietf.org > > Subject: Re: [Sipping] Push-To-Talk with SIP > >=20 > >=20 > >=20 > > Hi, > >=20 > > Push to talk can be implemented by merely setting up a=20 > > session between=20 > > the speaker and the target when the UA becomes available=20 > and leaving=20 > > the session open, but only sending audio media over that=20 > > session when a=20 > > button is pushed. The session can be verified for=20 > liveness by using=20 > > the session-timer, and the target suddenly reappearing after=20 > > an absence=20 > > can be detected using the registration package. Perhaps=20 > > someone could=20 > > write a draft describing this usage? > >=20 > > thanks, > > -rohan > >=20 > >=20 > > On Wednesday, May 14, 2003, at 06:46 PM, ???? ??? wrote: > >=20 > > > Hello, > > > =A0 > > > Nokia, Siemens and Ericsson have announced that they are=20 > > developing a=20 > > > push-to-talk application for GSM networks with GPRS and=20 > > for future 3G=20 > > > networks. They want to use SIP for signaling but I=20 > > couldn't find any=20 > > > more detailed information. > > > =A0 > > > Does someone of you know some detail about the PTT=20 > > signaling with SIP? > > > Do they care about arbitration if two people want to talk=20 > > to the same=20 > > > group at the same time? Are there some drafts or=20 > discussions about=20 > > > this topics? > > > =A0 > > > regards, > > > thomas lee. > >=20 > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > Sipping mailing list=20 > https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > >=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP >=20 >=20 >=20 >=20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 0043997085256D2E_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Aki,
By 'session less' I mean not having = an INVITE-OK-ACK to actually establish the call before you could talk. Appl= ication state would be maintained
during one 'push-release' operation = and forgotten after that (except for the administrative states like which w= as the gruop set I was talking to).

Different algorithms have been sugge= sted for this 'voice over IM' =3D> some are also patented @ the uspto (I= think someone had posted the patent no.
in the impp archive some time ago)

Anyway, therefore, I realize this ma= y not be something that the ietf sip grp wants to take up unless there is a= compelling reason
go into into this 2 way radio servic= e. With respect to the original Q, I agree that one could conceptualize tha= t a call in session with RTP
bursts and conferencing thrown in co= uld look like a '2 way radio service' =3D but due to the nature of its pers= istance of state for a much longer
time than currently known implementa= tions not using SIP, the charging model and complexities would likely not b= e the same, for what ever its worth.

regds
arjun

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


aki.niemi@nokia.com
Sent by: sipping-admin@ietf.org

05/22/2003 05:32 AM

       
        To: &nbs= p;      <aroychow@hns.com>
        cc: &nbs= p;      <rohan@cisco.com>, <sipping@ietf.org>, &= lt;sipping-admin@ietf.org>, <thomas.lee@polypix.com>
        Subject:=        RE: [Sipping] Push-To-Talk with SIP


Hi Arjun,

I don't really understand what you mean by 'session less', could you elabor= ate a bit? Do you mean to say there is no application state maintained at t= he endpoints?

And to me, the original question seemed to be whether there have been any d= rafts or discussions w.r.t. push to talk and SIP in the IETF. And the enswe= r to that would have to be no, but the conferencing work in SIPPING seems t= o be covering related issues, e.g., floor control, and media policy.

Regards,                
Aki


> -----Original Message-----
> From: ext Arjun Roychowdhury [mailto:aroychow@hns.com]
> Sent: 21 May, 2003 17:15
> To: Niemi Aki (NMP/Helsinki)
> Cc: rohan@cisco.com; sipping@ietf.org; sipping-admin@ietf.org;
> thomas.lee@polypix.com
> Subject: RE: [Sipping] Push-To-Talk with SIP
>
>
> I think to avoid confusion, it may be better to reword this
> is a 'session
> less two way radio service',
> with session less being the key item. I believe this was the
> original
> question of the poster.
>
> Whether this particular approach makes sense to be done in SIP and > especially in the purview of the IETF  is another question.
>
> regds
> arjun
>
> --
> Arjun Roychowdhury @ Hughes Software Systems
> 11717 Exploration Lane, Germantown MD 20876
> (O): 301 212 7860
>
>
>
>
> aki.niemi@nokia.com
> Sent by: sipping-admin@ietf.org
> 05/21/2003 08:52 AM
>
>  
>         To:     <rohan@cisco.com>= , <thomas.lee@polypix.com>
>         cc:     <sipping@ietf.org>= ;
>         Subject:        RE: [= Sipping] Push-To-Talk with SIP
>
>
> Hi Rohan,
>
> I think this is one way to look at the push to talk feature,
> but maybe not
> exactly "mainstream". Most of the push to talk services I'm=
> aware of are
> similar to a walkie talkie service, where a group of people are
> participating, out of which only one at a time can send media to the =
> others. "Requesting the floor" in this case is usually done= with the
> "tangent" button.
>
> So in my opinion, push to talk is a conference, with a
> specific type of
> conference and media policy associated with it. As such, I
> don't think
> it's the IETF's business to define those policies but
> provide tools for
> setting/manipulating them, which I guess the conference DT
> is already
> doing.
>
>                  -Aki
>
>  > -----Original Message-----
>  > From: ext Rohan Mahy [mailto:rohan@cisco.com]
>  > Sent: 20 May, 2003 23:15
>  > To: thomas.lee@polypix.com
>  > Cc: sipping@ietf.org
>  > Subject: Re: [Sipping] Push-To-Talk with SIP
>  >
>  >
>  >
>  > Hi,
>  >
>  > Push to talk can be implemented by merely setting up a
>  > session between
>  > the speaker and the target when the UA becomes available <= br> > and leaving
>  > the session open, but only sending audio media over that <= br> >  > session when a
>  > button is pushed.  The session can be verified for > liveness by using
>  > the session-timer, and the target suddenly reappearing aft= er
>  > an absence
>  > can be detected using the registration package.  Perh= aps
>  > someone could
>  > write a draft describing this usage?
>  >
>  > thanks,
>  > -rohan
>  >
>  >
>  > On Wednesday, May 14, 2003, at 06:46 PM, ???? ??? wrote: >  >
>  > > Hello,
>  > > =A0
>  > > Nokia, Siemens and Ericsson have announced that they = are
>  > developing a
>  > > push-to-talk application for GSM networks with GPRS a= nd
>  > for future 3G
>  > > networks. They want to use SIP for signaling but I >  > couldn't find any
>  > > more detailed information.
>  > > =A0
>  > > Does someone of you know some detail about the PTT >  > signaling with SIP?
>  > > Do they care about arbitration if two people want to = talk
>  > to the same
>  > > group at the same time? Are there some drafts or
> discussions about
>  > > this topics?
>  > > =A0
>  > > regards,
>  > > thomas lee.
>  >
>  > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F
>  > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
>  > This list is for NEW development of the application of SIP=
>  > Use sip-implementors@cs.columbia.edu for questions on curr= ent sip
>  > Use sip@ietf.org for new developments of core SIP
>  >
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sip= ping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
>
>
>
>
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.ed= u for questions on current sip
Use sip@ietf.org for new developments of core SIP

--=_alternative 0043997085256D2E_=-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 22 09:19: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 JAA12708 for ; Thu, 22 May 2003 09:19:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4MCkw205070 for sipping-archive@odin.ietf.org; Thu, 22 May 2003 08: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 h4MCkwB05065 for ; Thu, 22 May 2003 08:46: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 JAA12673 for ; Thu, 22 May 2003 09:19:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ipx6-0001Nh-00 for sipping-web-archive@ietf.org; Thu, 22 May 2003 09:17:48 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ipx5-0001Ne-00 for sipping-web-archive@ietf.org; Thu, 22 May 2003 09:17: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 h4MCjiB04934; Thu, 22 May 2003 08:45: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 h4MCglB04630 for ; Thu, 22 May 2003 08:42: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 JAA12335 for ; Thu, 22 May 2003 09:15:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ipt3-0001Hd-00 for sipping@ietf.org; Thu, 22 May 2003 09:13:37 -0400 Received: from taurus.polito.it ([130.192.1.8]) by ietf-mx with smtp (Exim 4.12) id 19Ipt2-0001Gf-00 for sipping@ietf.org; Thu, 22 May 2003 09:13:36 -0400 Received: (qmail 6080 invoked from network); 22 May 2003 13:17:26 -0000 Received: from sl-srv0.polito.it (HELO vaio) (130.192.1.240) by 0 with SMTP; 22 May 2003 13:17:26 -0000 Message-ID: <002701c32063$dd0db4e0$f001c082@vaio> From: "Roberto Tealdi" To: , Date: Thu, 22 May 2003 15:12:45 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0021_01C32074.99469220" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [Sipping] [SIP] Hierarchical Registration Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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_0021_01C32074.99469220 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0022_01C32074.99469220" ------=_NextPart_001_0022_01C32074.99469220 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello All, I'm new on SIP, I have a question about registration procedures, = expecially the Hierarchical Registration described in Shulzrinne's = article "Application-Layer Mobility Using SIP". Suppose this scenario, there are 2 domains (Visited Network and Home = Network) and there is a SIP registrar proxy in each domain;=20 1) a user in the visited network wants to register himself at his home = network. UAC sends a REGISTER message; in this message the Contact = header is set with the current IP address of the UAC. The message has a = digital signature in order to provide integrity and authentication, such = digital signature include the following headers: To, From, Contact, = Date, C-Seq, Call-ID. 2) Suppose to implement the hierarchical registration as described in = some Schulzrinne's articles: the SIP outbound proxy in the visited = domain when receives this message has to change the Contact header = putting in it its own address, before forwarding the REGISTER message to = the user's home network. This is done in order to receive and inspect = (by the proxy in the visited network) all incoming messages for the user = visiting in. But if the Contact header is changed, the digital signature = is compromised. The UAC should know the "correct" Contact value before doing the digital = signature in his REGISTER messages. How can the proxy do to "inform" the UAC about this "correct" value? Are = there existing mechanism? Is possible to do it with 4xx messages? Note: the UAC signs his messages with his private key, the visited proxy = do not know this key. I was supposing that this would be a possible solution (see the = Scenario.txt attach): The Visited Proxy in the "4xx Contact Not Acceptable" notify the UAC the = correct value to put in the Contact header, and in the successive = REGISTER message the UAC fill the header with this new value. The = Visited Register does not need to made any changes in the REGISTER = message so the digital signature is still valid. It would be possible this solution or there are other mechanisms? Thank you very much for Your helps. Roby. ------=_NextPart_001_0022_01C32074.99469220 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello All,
 
I'm new on SIP, I have a question about = registration procedures, expecially the Hierarchical Registration = described in=20 Shulzrinne's article "Application-Layer Mobility Using = SIP".
 
Suppose this scenario, there are 2 = domains (Visited=20 Network and Home Network) and there is a SIP registrar proxy in each = domain;=20

1) a user in the visited network wants to register = himself  at=20 his home network. UAC sends a REGISTER message; in this message the = Contact=20 header is set with the current IP address of the UAC. The message has a = digital=20 signature in order to provide integrity and authentication, such = digital=20 signature include the following headers: To, From, Contact, Date, C-Seq, = Call-ID.

2) Suppose to implement the hierarchical registration as = described in some Schulzrinne's articles: the SIP outbound proxy in = the=20 visited domain when receives this message has to change the Contact = header=20 putting in it its own address, before forwarding the REGISTER = message to=20 the user's home network. This is done in order to receive and = inspect=20 (by the proxy in the visited network) all incoming messages for the = user=20 visiting in. But if the Contact header is changed, the digital signature = is=20 compromised.

The UAC should know the "correct" Contact value = before doing=20 the digital signature in his REGISTER messages.

How can the proxy = do to=20 "inform" the UAC about this "correct" value? Are there existing = mechanism? Is=20 possible to do it with 4xx messages?
 
Note: the UAC signs his messages with = his private=20 key, the visited proxy do not know this key.

I was supposing that = this=20 would be a possible solution (see the Scenario.txt attach):

The = Visited=20 Proxy in the "4xx Contact Not Acceptable" notify the UAC the = correct value=20 to put in the Contact header, and in the successive REGISTER message the = UAC=20 fill the header with this new value. The Visited Register does not need = to made=20 any changes in the REGISTER message so the digital signature is still=20 valid.
 
It would be = possible this=20 solution or there are other mechanisms?

Thank you very much for Your=20 helps.
Roby.
 ------=_NextPart_001_0022_01C32074.99469220-- ------=_NextPart_000_0021_01C32074.99469220 Content-Type: text/plain; name="Scenario.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Scenario.txt" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable UAC Visited Registrar = Home Registrar | REGISTER | = | |--------------------------------------------->| = | | | = | | 4xx Contact Address Not Acceptable | = | |<---------------------------------------------| | =20 | | = | | REGISTER (with new Contact) | = | |--------------------------------------------->| = | | | = REGISTER | | = |----------------------------------------->| | | = | | | 200 = OK | | = |<-----------------------------------------| | 200 OK | = | |<---------------------------------------------| = | | | = | ------=_NextPart_000_0021_01C32074.99469220-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 22 12:48: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 MAA21099 for ; Thu, 22 May 2003 12:48:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4MGFiA24715 for sipping-archive@odin.ietf.org; Thu, 22 May 2003 12: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 h4MGFiB24711 for ; Thu, 22 May 2003 12: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 MAA21066 for ; Thu, 22 May 2003 12:47:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ItD4-0003S9-00 for sipping-web-archive@ietf.org; Thu, 22 May 2003 12:46:30 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ItD3-0003S6-00 for sipping-web-archive@ietf.org; Thu, 22 May 2003 12:46: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 h4MGE7B24615; Thu, 22 May 2003 12:14: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 h4MGCPB24526 for ; Thu, 22 May 2003 12:12: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 MAA20983 for ; Thu, 22 May 2003 12:44:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19It9q-0003QE-00 for sipping@ietf.org; Thu, 22 May 2003 12:43:10 -0400 Received: from smtp.dataconnection.com ([192.91.191.4] helo=coltrane.dataconnection.com) by ietf-mx with esmtp (Exim 4.12) id 19It9q-0003Ot-00 for sipping@ietf.org; Thu, 22 May 2003 12:43:10 -0400 Received: by coltrane.datcon.co.uk with Internet Mail Service (5.5.2656.59) id ; Thu, 22 May 2003 17:43:57 +0100 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F8B8E55C@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: Thu, 22 May 2003 17:43:46 +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, I think that the requirements should be modified to clarify the scope of the alias parameter. I suggest we could add "The mechanism SHOULD allow the reuse of an existing connection for requests and responses sent both outside a dialog and within one or more dialogs" to the end of requirement 1 in section 3. I also have a question about the lifetime of the alias. Should the alias be destroyed as soon as the connection is lost, or is there a reason why you might want to maintain the alias for any time after? Is it worth clarifying this in the draft, perhaps at the beginning of section 4 in the overview of the mechanism? 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 Fri May 23 12:16: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 MAA11085 for ; Fri, 23 May 2003 12:16:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4NGFap25531 for sipping-archive@odin.ietf.org; Fri, 23 May 2003 12:15: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 h4NGFaB25528 for ; Fri, 23 May 2003 12:15: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 MAA11047 for ; Fri, 23 May 2003 12:15:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JFBI-00064Y-00 for sipping-web-archive@ietf.org; Fri, 23 May 2003 12:14:08 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19JFBH-00064U-00 for sipping-web-archive@ietf.org; Fri, 23 May 2003 12:14: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 h4NGEJB25400; Fri, 23 May 2003 12:14: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 h4MEOZB14110 for ; Thu, 22 May 2003 10:24: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 KAA17101; Thu, 22 May 2003 10:56:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IrTX-0002Tt-00; Thu, 22 May 2003 10:55:23 -0400 Received: from gateway.hns.com ([208.236.67.13]) by ietf-mx with esmtp (Exim 4.12) id 19IrTW-0002Tq-00; Thu, 22 May 2003 10:55:22 -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 h4MEufun001413; Thu, 22 May 2003 10:56:41 -0400 (EDT) Received: from atlas (atlas.hns.com [139.85.177.110]) by excore8.hns.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h4MEuZsf011733; Thu, 22 May 2003 10:56:35 -0400 (EDT) To: Cc: rohan@cisco.com, sipping@ietf.org, sipping-admin@ietf.org, thomas.lee@polypix.com Subject: RE: [Sipping] Push-To-Talk with SIP - Agreed - {End of Thread } MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Arjun Roychowdhury" Date: Thu, 22 May 2003 10:56:33 -0400 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.12 |February 13, 2003) at 05/22/2003 10:54:37 AM, Serialize complete at 05/22/2003 10:54:37 AM 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: , -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301 212 7860 05/22/2003 10:50 AM To: cc: , , , Subject: RE: [Sipping] Push-To-Talk with SIP Arjun, Judging from your answer (especially the 'voice over IM' part) I think we might have been talking about two different services under the same name. Likewise, the fact that in this thread already there have been at least three different interpretations of what a push to talk service means for SIP, makes me wonder whether this is a worthwhile debate to have in the IETF at all. I.e., let the market do the branding game. ;-) We should come back when there is a specific SIP issue to address (whatever the service), IMHO. Cheers, Aki -----Original Message----- From: ext aroychow@hss.hns.com [mailto:aroychow@hss.hns.com] Sent: 22 May, 2003 15:18 To: Niemi Aki (NMP/Helsinki) Cc: aroychow@hns.com; rohan@cisco.com; sipping@ietf.org; sipping-admin@ietf.org; thomas.lee@polypix.com Subject: RE: [Sipping] Push-To-Talk with SIP Aki, By 'session less' I mean not having an INVITE-OK-ACK to actually establish the call before you could talk. Application state would be maintained during one 'push-release' operation and forgotten after that (except for the administrative states like which was the gruop set I was talking to). Different algorithms have been suggested for this 'voice over IM' => some are also patented @ the uspto (I think someone had posted the patent no. in the impp archive some time ago) Anyway, therefore, I realize this may not be something that the ietf sip grp wants to take up unless there is a compelling reason go into into this 2 way radio service. With respect to the original Q, I agree that one could conceptualize that a call in session with RTP bursts and conferencing thrown in could look like a '2 way radio service' = but due to the nature of its persistance of state for a much longer time than currently known implementations not using SIP, the charging model and complexities would likely not be the same, for what ever its worth. regds arjun -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301 212 7860 aki.niemi@nokia.com Sent by: sipping-admin@ietf.org 05/22/2003 05:32 AM To: cc: , , , Subject: RE: [Sipping] Push-To-Talk with SIP Hi Arjun, I don't really understand what you mean by 'session less', could you elaborate a bit? Do you mean to say there is no application state maintained at the endpoints? And to me, the original question seemed to be whether there have been any drafts or discussions w.r.t. push to talk and SIP in the IETF. And the enswer to that would have to be no, but the conferencing work in SIPPING seems to be covering related issues, e.g., floor control, and media policy. Regards, Aki > -----Original Message----- > From: ext Arjun Roychowdhury [mailto:aroychow@hns.com] > Sent: 21 May, 2003 17:15 > To: Niemi Aki (NMP/Helsinki) > Cc: rohan@cisco.com; sipping@ietf.org; sipping-admin@ietf.org; > thomas.lee@polypix.com > Subject: RE: [Sipping] Push-To-Talk with SIP > > > I think to avoid confusion, it may be better to reword this > is a 'session > less two way radio service', > with session less being the key item. I believe this was the > original > question of the poster. > > Whether this particular approach makes sense to be done in SIP and > especially in the purview of the IETF is another question. > > regds > arjun > > -- > Arjun Roychowdhury @ Hughes Software Systems > 11717 Exploration Lane, Germantown MD 20876 > (O): 301 212 7860 > > > > > aki.niemi@nokia.com > Sent by: sipping-admin@ietf.org > 05/21/2003 08:52 AM > > > To: , > cc: > Subject: RE: [Sipping] Push-To-Talk with SIP > > > Hi Rohan, > > I think this is one way to look at the push to talk feature, > but maybe not > exactly "mainstream". Most of the push to talk services I'm > aware of are > similar to a walkie talkie service, where a group of people are > participating, out of which only one at a time can send media to the > others. "Requesting the floor" in this case is usually done with the > "tangent" button. > > So in my opinion, push to talk is a conference, with a > specific type of > conference and media policy associated with it. As such, I > don't think > it's the IETF's business to define those policies but > provide tools for > setting/manipulating them, which I guess the conference DT > is already > doing. > > -Aki > > > -----Original Message----- > > From: ext Rohan Mahy [mailto:rohan@cisco.com] > > Sent: 20 May, 2003 23:15 > > To: thomas.lee@polypix.com > > Cc: sipping@ietf.org > > Subject: Re: [Sipping] Push-To-Talk with SIP > > > > > > > > Hi, > > > > Push to talk can be implemented by merely setting up a > > session between > > the speaker and the target when the UA becomes available > and leaving > > the session open, but only sending audio media over that > > session when a > > button is pushed. The session can be verified for > liveness by using > > the session-timer, and the target suddenly reappearing after > > an absence > > can be detected using the registration package. Perhaps > > someone could > > write a draft describing this usage? > > > > thanks, > > -rohan > > > > > > On Wednesday, May 14, 2003, at 06:46 PM, ???? ??? wrote: > > > > > Hello, > > > > > > Nokia, Siemens and Ericsson have announced that they are > > developing a > > > push-to-talk application for GSM networks with GPRS and > > for future 3G > > > networks. They want to use SIP for signaling but I > > couldn't find any > > > more detailed information. > > > > > > Does someone of you know some detail about the PTT > > signaling with SIP? > > > Do they care about arbitration if two people want to talk > > to the same > > > group at the same time? Are there some drafts or > discussions about > > > this topics? > > > > > > regards, > > > thomas lee. > > > > _______________________________________________ > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 23 12: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 MAA11101 for ; Fri, 23 May 2003 12:16:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4NGFin25553 for sipping-archive@odin.ietf.org; Fri, 23 May 2003 12: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 h4NGFiB25550 for ; Fri, 23 May 2003 12: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 MAA11052 for ; Fri, 23 May 2003 12:15:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JFBQ-00064e-00 for sipping-web-archive@ietf.org; Fri, 23 May 2003 12:14:16 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19JFBP-00064b-00 for sipping-web-archive@ietf.org; Fri, 23 May 2003 12:14: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 h4NGDiB25320; Fri, 23 May 2003 12:13: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 h4MEIIB13695 for ; Thu, 22 May 2003 10:18: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 KAA16916; Thu, 22 May 2003 10:50:29 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IrNS-0002Po-00; Thu, 22 May 2003 10:49:06 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19IrNR-0002Pi-00; Thu, 22 May 2003 10:49:06 -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 h4MEoSD26643; Thu, 22 May 2003 17:50:28 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 22 May 2003 17:50:28 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 22 May 2003 17:50:28 +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] Push-To-Talk with SIP Date: Thu, 22 May 2003 17:50:27 +0300 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945281@esebe013.ntc.nokia.com> Thread-Topic: [Sipping] Push-To-Talk with SIP Thread-Index: AcMgZB9FdwIcSesXT6CRBPmjxfikWAACLvlA To: Cc: , , , X-OriginalArrivalTime: 22 May 2003 14:50:28.0139 (UTC) FILETIME=[7C1107B0:01C32071] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4MEIIB13696 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 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, Judging from your answer (especially the 'voice over IM' part) I think we might have been talking about two different services under the same name. Likewise, the fact that in this thread already there have been at least three different interpretations of what a push to talk service means for SIP, makes me wonder whether this is a worthwhile debate to have in the IETF at all. I.e., let the market do the branding game. ;-) We should come back when there is a specific SIP issue to address (whatever the service), IMHO. Cheers, Aki -----Original Message----- From: ext aroychow@hss.hns.com [mailto:aroychow@hss.hns.com] Sent: 22 May, 2003 15:18 To: Niemi Aki (NMP/Helsinki) Cc: aroychow@hns.com; rohan@cisco.com; sipping@ietf.org; sipping-admin@ietf.org; thomas.lee@polypix.com Subject: RE: [Sipping] Push-To-Talk with SIP Aki, By 'session less' I mean not having an INVITE-OK-ACK to actually establish the call before you could talk. Application state would be maintained during one 'push-release' operation and forgotten after that (except for the administrative states like which was the gruop set I was talking to). Different algorithms have been suggested for this 'voice over IM' => some are also patented @ the uspto (I think someone had posted the patent no. in the impp archive some time ago) Anyway, therefore, I realize this may not be something that the ietf sip grp wants to take up unless there is a compelling reason go into into this 2 way radio service. With respect to the original Q, I agree that one could conceptualize that a call in session with RTP bursts and conferencing thrown in could look like a '2 way radio service' = but due to the nature of its persistance of state for a much longer time than currently known implementations not using SIP, the charging model and complexities would likely not be the same, for what ever its worth. regds arjun -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301 212 7860 aki.niemi@nokia.com Sent by: sipping-admin@ietf.org 05/22/2003 05:32 AM To: cc: , , , Subject: RE: [Sipping] Push-To-Talk with SIP Hi Arjun, I don't really understand what you mean by 'session less', could you elaborate a bit? Do you mean to say there is no application state maintained at the endpoints? And to me, the original question seemed to be whether there have been any drafts or discussions w.r.t. push to talk and SIP in the IETF. And the enswer to that would have to be no, but the conferencing work in SIPPING seems to be covering related issues, e.g., floor control, and media policy. Regards, Aki > -----Original Message----- > From: ext Arjun Roychowdhury [mailto:aroychow@hns.com] > Sent: 21 May, 2003 17:15 > To: Niemi Aki (NMP/Helsinki) > Cc: rohan@cisco.com; sipping@ietf.org; sipping-admin@ietf.org; > thomas.lee@polypix.com > Subject: RE: [Sipping] Push-To-Talk with SIP > > > I think to avoid confusion, it may be better to reword this > is a 'session > less two way radio service', > with session less being the key item. I believe this was the > original > question of the poster. > > Whether this particular approach makes sense to be done in SIP and > especially in the purview of the IETF is another question. > > regds > arjun > > -- > Arjun Roychowdhury @ Hughes Software Systems > 11717 Exploration Lane, Germantown MD 20876 > (O): 301 212 7860 > > > > > aki.niemi@nokia.com > Sent by: sipping-admin@ietf.org > 05/21/2003 08:52 AM > > > To: , > cc: > Subject: RE: [Sipping] Push-To-Talk with SIP > > > Hi Rohan, > > I think this is one way to look at the push to talk feature, > but maybe not > exactly "mainstream". Most of the push to talk services I'm > aware of are > similar to a walkie talkie service, where a group of people are > participating, out of which only one at a time can send media to the > others. "Requesting the floor" in this case is usually done with the > "tangent" button. > > So in my opinion, push to talk is a conference, with a > specific type of > conference and media policy associated with it. As such, I > don't think > it's the IETF's business to define those policies but > provide tools for > setting/manipulating them, which I guess the conference DT > is already > doing. > > -Aki > > > -----Original Message----- > > From: ext Rohan Mahy [mailto:rohan@cisco.com] > > Sent: 20 May, 2003 23:15 > > To: thomas.lee@polypix.com > > Cc: sipping@ietf.org > > Subject: Re: [Sipping] Push-To-Talk with SIP > > > > > > > > Hi, > > > > Push to talk can be implemented by merely setting up a > > session between > > the speaker and the target when the UA becomes available > and leaving > > the session open, but only sending audio media over that > > session when a > > button is pushed. The session can be verified for > liveness by using > > the session-timer, and the target suddenly reappearing after > > an absence > > can be detected using the registration package. Perhaps > > someone could > > write a draft describing this usage? > > > > thanks, > > -rohan > > > > > > On Wednesday, May 14, 2003, at 06:46 PM, ???? ??? wrote: > > > > > Hello, > > > > > > Nokia, Siemens and Ericsson have announced that they are > > developing a > > > push-to-talk application for GSM networks with GPRS and > > for future 3G > > > networks. They want to use SIP for signaling but I > > couldn't find any > > > more detailed information. > > > > > > Does someone of you know some detail about the PTT > > signaling with SIP? > > > Do they care about arbitration if two people want to talk > > to the same > > > group at the same time? Are there some drafts or > discussions about > > > this topics? > > > > > > regards, > > > thomas lee. > > > > _______________________________________________ > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 23 12:43: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 MAA12570 for ; Fri, 23 May 2003 12:43:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4NGh5Z30560 for sipping-archive@odin.ietf.org; Fri, 23 May 2003 12:43: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 h4NGh5B30557 for ; Fri, 23 May 2003 12:43: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 MAA12548 for ; Fri, 23 May 2003 12:43:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JFbs-0006YJ-00 for sipping-web-archive@ietf.org; Fri, 23 May 2003 12:41:36 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19JFbs-0006YG-00 for sipping-web-archive@ietf.org; Fri, 23 May 2003 12:41: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 h4NGfYB29959; Fri, 23 May 2003 12:41: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 h4MGGsB24768 for ; Thu, 22 May 2003 12:16: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 MAA21136 for ; Thu, 22 May 2003 12:49:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ItEC-0003Se-00 for sipping@ietf.org; Thu, 22 May 2003 12:47:40 -0400 Received: from smtp6.mindspring.com ([207.69.200.110]) by ietf-mx with esmtp (Exim 4.12) id 19ItEA-0003SV-00 for sipping@ietf.org; Thu, 22 May 2003 12:47:38 -0400 Received: from user-2iveraf.dialup.mindspring.com ([165.247.109.79] helo=Vlgz) by smtp6.mindspring.com with smtp (Exim 3.33 #1) id 19ItF1-0006BV-00 for sipping@ietf.org; Thu, 22 May 2003 12:48:31 -0400 From: fluffy To: sipping@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=RO8K8208tRZYu2qItJ0d51911w4p1u Message-Id: Date: Thu, 22 May 2003 12:48:31 -0400 Subject: [Sipping] Re:sipping,welcome to my hometown Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --RO8K8208tRZYu2qItJ0d51911w4p1u Content-Type: text/html; Content-Transfer-Encoding: quoted-printable --RO8K8208tRZYu2qItJ0d51911w4p1u Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: space, .scr, Content-Type: audio/x-midi] The attachment file in the message has been removed by eManager. --RO8K8208tRZYu2qItJ0d51911w4p1u Content-Type: application/octet-stream; name=two_f[1].htm Content-Transfer-Encoding: base64 Content-ID: PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlv bmFsLy9FTiINCgkiaHR0cDovL3d3dy53My5vcmcvVFIvMTk5OS9SRUMtaHRtbDQwMS0xOTk5 MTIyNC9sb29zZS5kdGQiPg0KPEhUTUw+DQo8SEVBRD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNv bnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXdpbmRvd3MtMTI1MiI+ DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LUxhbmd1YWdlIiBjb250ZW50PSJlbi11cyI+ DQo8bWV0YSBuYW1lPSJNU1NtYXJ0VGFnc1ByZXZlbnRQYXJzaW5nIiBjb250ZW50PSJUUlVF Ij4NCjxUSVRMRT5IVE1MIFRhYmxlIFR1dG9yaWFscywgTGVzc29uIDJmLCBDZWxscGFkZGlu ZyBhbmQgQ2VsbHNwYWNpbmc8L1RJVExFPg0KPE1FVEEgTkFNRT0iS0VZV09SRFMiIENPTlRF TlQ9Imh0bWwgdGFibGUgdHV0b3JpYWwsaHRtbCx0YWJsZSx0YWJsZXMsdHV0b3JpYWwsYmFj a2dyb3VuZCxpbWFnZSxoZWFkaW5ncyx0YWJsZSByb3dzLHRhYmxlIGRhdGEsdGFibGUgZWxl bWVudHMsdGFibGUgaGVhZGluZyxoaXRtaWxsIj4NCjxNRVRBIE5BTUU9IkRFU0NSSVBUSU9O IiBDT05URU5UPSJUdXRvcmlhbHMgZm9yIGJlZ2lubmVycyBhYm91dCBob3cgdG8gY29kZSB0 YWJsZXMgdXNpbmcgSFRNTDsgaW5jbHVkZXMgdGFibGUgYmFja2dyb3VuZHMsIGltYWdlcywg aGVhZGluZ3MsIGRhdGEgY2VsbHMsIGJvcmRlcmNvbG9yLCBhbmQgbW9yZS4uLiI+DQo8TUVU QSBOQU1FPSJWVzk2Lm9iamVjdHR5cGUiIENPTlRFTlQ9IkRvY3VtZW50Ij4NCjxNRVRBIE5B TUU9IlJBVElORyIgQ09OVEVOVD0iR2VuZXJhbCI+DQo8TUVUQSBOQU1FPSJSRVZJU0lULUFG VEVSIiBDT05URU5UPSIxMCBEQVlTIj4NCjxNRVRBIG5hbWU9IkNPUFlSSUdIVCIgQ09OVEVO VD0iQ29weXJpZ2h0IKkgMTk5OC0yMDAzIGhpdG1pbGwuY29tIj4NCjxNRVRBIG5hbWU9IlJP Qk9UUyIgQ09OVEVOVD0iQUxMLElOREVYIj4NCjxNRVRBIEhUVFAtRVFVSVY9XCJleHBpcmVz XCIgQ09OVEVOVD1cIjBcIj4NCjxNRVRBIEhUVFAtRVFVSVY9XCJwcmFnbWFcIiBDT05URU5U PVwiTk8tQ0FDSEVcIj4NCjxMSU5LIFJFVj1tYWRlIGhyZWY9Im1haWx0bzp3ZWJtYXN0ZXJA aGl0bWlsbC5jb20iPg0KPE1FVEEgaHR0cC1lcXVpdj0iUGFnZS1FbnRlciIgY29udGVudD0i cmV2ZWFsVHJhbnMoRHVyYXRpb249Mi4wLFRyYW5zaXRpb249MjMpIj4NCiAgIDxTQ1JJUFQg TEFOR1VBR0U9IkphdmFTY3JpcHQiPg0KICAgPCEtLSBIaWRlIHNjcmlwdCBmcm9tIG9sZCBi cm93c2Vycw0KICAgaWYgKHRvcC5sb2NhdGlvbiAhPSBzZWxmLmxvY2F0aW9uKSB7DQogICAg ICAgIHRvcC5sb2NhdGlvbiA9IHNlbGYubG9jYXRpb24NCiAgIH0NCiAgIC8vIEVuZCAtLT4N CiAgIDwvU0NSSVBUPg0KPExJTksgUkVMPSJzdHlsZXNoZWV0IiBUWVBFPSJ0ZXh0L2NzcyIg SFJFRj0iLi4vLi4vc3R5bGUvbnVldmExLmNzcyI+DQo8U1RZTEUgVFlQRT0idGV4dC9jc3Mi Pg0KICA8IS0tDQogICN0aXRsZXttYXJnaW4tdG9wOjUwO21hcmdpbi1ib3R0b206NDA7fQ0K ICBIMnttYXJnaW4tdG9wOjE7bWFyZ2luLWJvdHRvbTo0MDtmb250LWZhbWlseToiTHVjaWRh IFNhbnMiLEhlbHZldGljYSxzYW5zLXNlcmlmO30NCiAgSDN7bWFyZ2luLXRvcDoxO21hcmdp bi1ib3R0b206MTtmb250LWZhbWlseToiTHVjaWRhIFNhbnMiLEhlbHZldGljYSxzYW5zLXNl cmlmO30NCiAgDQpQe21hcmdpbi1sZWZ0OjEwO21hcmdpbi1yaWdodDoxMDt9DQpINXttYXJn aW4tdG9wOjY7IHRleHQtYWxpZ246Y2VudGVyO30NCiAgLm1pY3Jve2xldHRlci1zcGFjaW5n OjFweDtmb250LWZhbWlseTpIZWx2ZXRpY2EsQXJpYWwsc2Fucy1zZXJpZjt9DQogICNob3Jp em9udGFse21hcmdpbi10b3A6MzA7bWFyZ2luLWJvdHRvbTozMDt9DQogIC5uYXZ7Y29sb3I9 ImJsdWUiO21hcmdpbi1sZWZ0OjI1O2ZvbnQtc2l6ZToxNHB0O2xldHRlci1zcGFjaW5nOjFw eDtmb250LXdlaWdodDo2MDA7DQoJZm9udC1mYW1pbHk6Ikx1Y2lkYSBIYW5kd3JpdGluZyBJ dGFsaWMiLHNjcmlwdCxzYW5zLXNlcmlmOyJ9DQogIEJMT0NLUVVPVEV7dGV4dC1hbGlnbjps ZWZ0O21hcmdpbi1sZWZ0OjE1MDttYXJnaW4tcmlnaHQ6MTUwOw0KCWZvbnQtc2l6ZToxMnB0 OyBsZXR0ZXItc3BhY2luZzoxcHg7DQoJbGluZS1oZWlnaHQ6MS40OyBmb250LXdlaWdodDo2 MDA7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IiwiQ291cmllciIsc2Fucy1zZXJpZjt9 DQogIA0KICAucmVmMSB7Y29sb3I6Izg0NEQxODsgZm9udC1zaXplOjFlbTsgZm9udC13ZWln aHQ6Ym9sZDsgbGV0dGVyLXNwYWNpbmc6MnB4Ow0KICAgICAgICAgIGZvbnQtZmFtaWx5OkFy aWFsLCBzYW5zLXNlcmlmOyBtYXJnaW4tYm90dG9tOjUwcHg7fQ0KICAgUHt0ZXh0LWFsaWdu Omp1c3RpZnk7bWFyZ2luLWxlZnQ6MTAwO21hcmdpbi1yaWdodDoxMDA7Zm9udC1zaXplOjEz cHQ7IGxpbmUtaGVpZ2h0OjEuNjsNCiAgICAgZm9udC1mYW1pbHk6SGVsdmV0aWNhLFRhaG9t YSwgc2Fucy1zZXJpZjt9DQogIC5pbnNldCB7Y29sb3I6IzAwN0ZGRjsgIGZvbnQtc2l6ZTox OHB4OyBmb250LXdlaWdodDogNTAwOyANCiAgICAgICAgICBmb250LWZhbWlseTphcmlhbCwg aGVsdmV0aWNhLCBzYW5zLXNlcmlmO30NCiAgLmluZGV4IHsgZm9udC1zaXplOjE1cHQ7IGxp bmUtaGVpZ2h0OiAxLjNlbTsgbGV0dGVyLXNwYWNpbmc6IDNweDsgZm9udC13ZWlnaHQ6ODAw OyANCiAgICAgICAgICBjb2xvcjojMDA3RkZGOyBmb250LWZhbWlseTpBcmlhbCwgSGVsdmV0 aWNhLCBzYW5zLXNlcmlmO30NCiAgLmxlZnQgIHtjb2xvcjogIzAwN0ZGRjsgZm9udC1zaXpl OiAyMHB4OyBsZXR0ZXItc3BhY2luZzogMnB0OyBmb250LXdlaWdodDogODAwOyAgICAgICAg ICAgDQogICAgICAgICAgIGxpbmUtaGVpZ2h0OjEuNWVtOyBmb250LXN0eWxlOiBpdGFsaWM7 IGZvbnQtZmFtaWx5OiAiVGltZXMgTmV3IFJvbWFuIiwgdGltZXMsIHNlcmlmO30NCiAgLnNt YWxsIHtjb2xvcjogYnJvd247IG1hcmdpbi1sZWZ0OiAxMHB4OyBmb250LXNpemU6OXB0OyBs ZXR0ZXItc3BhY2luZzoycHg7IGZvbnQtd2VpZ2h0OjYwMDsNCiAgICAgICAgICAgbGluZS1o ZWlnaHQ6MS41ZW07IGZvbnQtZmFtaWx5OmFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWY7 fQ0KICAjdGluZGV4Ym90dG9te21hcmdpbi10b3A6NDA7IG1hcmdpbi1ib3R0b206MzU7fQ0K ICAtLT4NCjwvU1RZTEU+DQo8L0hFQUQ+ICANCjxCT0RZIEJBQ0tHUk9VTkQgPSAiLi4vLi4v aW1hZ2VzL2JnX2NnMjQuanBnIiBCR0NPTE9SPSIjRTFGQ0ZGIiBWTElOSz0iI0NCMDZFRSIg TElOSz0iYmx1ZSI+DQo8QSBOQU1FPSJ0b3AiPjwvQT4NCjxBIE5BTUU9InR3b19mIj48L0E+ DQo8ZGl2IGFsaWduPSJjZW50ZXIiPjxjZW50ZXI+DQo8VEFCTEUgYWxpZ249ImNlbnRlciIg V0lEVEg9IjgwJSIgQk9SREVSPSIwIiAgQ0VMTFNQQUNJTkc9IjAiICBDRUxMUEFERElORz0i MCI+PFRSPg0KICA8VEQgVkFMSUdOPSJ0b3AiIFdJRFRIPSIzMCUiPiAgICAgDQoJICAgICAg PERJViBDTEFTUz0ibWljcm8iPnd3dy5oaXRtaWxsLmNvbS88L0RJVj4gICAgICAgICAgICAN CiAgICAgICAgICAgICAgPEEgSFJFRj0iLi4vLi4vaW5kZXguaHRtbCI+PElNRyBTUkM9Ii4u Ly4uL2ltYWdlcy9oaXRtMi5qcGciIFdJRFRIPSIxNTAiIEhFSUdIVD0iNDYiIEJPUkRFUj0i MSIgQUxUPSJsaW5rIHRvIGhpdG1pbGwuY29tIj48L0E+DQoJPEJSPiZuYnNwOzxCUj4NCgk8 RElWIENMQVNTPSJuYXYiPjxBIEhSRUY9InR3b19lLmh0bWwiPkJhY2s8L0E+IHwNCiAgICAg ICAgPEEgSFJFRj0idHdvX2cuaHRtbCI+TmV4dDwvQT4NCiAgICAgICAgPC9ESVY+DQogIDwv VEQ+ICAgICAJICAgIA0KICAgICAgPFREIFZBTElHTj0idG9wIiBXSURUSD0iMTAlIj4mbmJz cDs8L1REPiAgICAgDQogICAgICA8VEQgV0lEVEg9IjYwJSIgVkFMSUdOPSJ0b3AiIEFMSUdO PSJsZWZ0Ij4NCiAgICAgIDxESVYgQ0xBU1M9ImluZGV4dG9wIj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgIA0KICAgICAgPFNDUklQVCBMQU5H VUFHRT0iSmF2YXNjcmlwdCIgU1JDPSIuLi8uLi9zY3JpcHRzL2RhdGUuanMiPjwvU0NSSVBU Pg0KICAgICAgPC9ESVY+PEJSPg0KICAgICAgPFRBQkxFIFdJRFRIPSIxMDAlIiBCT1JERVI9 IjAiIENFTExTUEFDSU5HPSIwIj4NCiAgICAgICAgPFRSPg0KICAgICAgICAgICAgPFREIEFM SUdOPSJjZW50ZXIiIFZBTElHTj0idG9wIj4NCiAgICAgICAgICAgICAgICAgICAgJm5ic3A7 ICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgPC9URD4NCiAgICAgICAgPC9UUj4NCiAg ICAgIDwvVEFCTEU+DQogICA8L1REPg0KIDwvVFI+DQo8L1RBQkxFPjxCUj4gDQo8IS0tICoq KioqKioqKiBMZXNzb24gMmY6IENFTExQQURESU5HIGFuZCBDRUxMU1BBQ0lORyAqKioqKioq KiAtLT4NCjxESVYgQUxJR049ImNlbnRlciI+DQo8SU1HIElEPSJ0aXRsZSIgQk9SREVSPSIw IiBTUkM9Ii4uL2ltYWdlcy90YWJsZXMuZ2lmIiBXSURUSD0iMzMxIiBIRUlHSFQ9IjExMiIg QUxUPSJIVE1MIFRhYmxlIFR1dG9yaWFsIj4NCjxIMz5MZXNzb24gMmY8L0gzPg0KDQo8SDMg U1RZTEU9Im1hcmdpbi1ib3R0b206NDA7Ij5UaGUgQ0VMTFBBRERJTkcgYW5kPEJSPiZhbXA7 Jm5ic3A7Q0VMTFNQQUNJTkc8QlI+QXR0cmlidXRlcyBvZiB0aGUgVGFibGUgRWxlbWVudDwv SDM+DQo8RElWIENMQVNTPSJhZ2FpbiIgU1RZTEU9ImxpbmUtaGVpZ2h0OjEuNjsgbWFyZ2lu LWxlZnQ6MjUwOyI+PCEtLSoqKiBMZXNzb24gTGlzdCAqKiotLT4NCiAgICAgICAgPEEgSFJF Rj0ibGVzc29uMi5odG1sI2FsaWduIj5BTElHTjwvQT48QlI+CQ0KICAgICAgICA8QSBIUkVG PSJ0d29fYi5odG1sI2JhY2tncm91bmQiPkJBQ0tHUk9VTkQ8L0E+PEJSPiAgICAgICAJDQog ICAgICAgIDxBIEhSRUY9InR3b19jLmh0bWwjYmdjb2xvciI+QkdDT0xPUjwvQT48QlI+DQog ICAgICAgIDxBIEhSRUY9InR3b19jLmh0bWwjYm9yZGVyIj5CT1JERVI8L0E+PEJSPg0KICAg ICAgICA8QSBIUkVGPSJ0d29fZC5odG1sI2JvcmRlcmNvbG9yIj5CT1JERVJDT0xPUjwvQT48 QlI+DQogICAgICAgIDxBIEhSRUY9InR3b19lLmh0bWwjYm9yZGVyY29sb3JsaWdodCI+Qk9S REVSQ09MT1JMSUdIVDwvQT48QlI+DQogICAgICAgIDxBIEhSRUY9InR3b19lLmh0bWwjYm9y ZGVyY29sb3JkYXJrIj5CT1JERVJDT0xPUkRBUks8L0E+PEJSPg0KICAgICAgICA8QSBIUkVG PSJ0d29fZi5odG1sI2NlbGxwYWRkaW5nIj48Yj5DRUxMUEFERElORzwvQT48QlI+DQogICAg ICAgIDxBIEhSRUY9InR3b19mLmh0bWwjY2VsbHNwYWNpbmciPkNFTExTUEFDSU5HPC9iPjwv QT48QlI+DQogICAgICAgIDxBIEhSRUY9InR3b19nLmh0bWwjY29scyI+Q09MUzwvQT48QlI+ DQogICAgICAgIDxBIEhSRUY9InR3b19nLmh0bWwjY29sc3BhbiI+Q09MU1BBTjwvQT48QlI+ DQogICAgICAgIDxBIEhSRUY9InR3b19oLmh0bWwjZnJhbWUiPkZSQU1FPC9BPjxCUj4gICAg ICAgDQogICAgICAgIDxBIEhSRUY9InR3b19pLmh0bWwjaHNwYWNlIj5IU1BBQ0U8L0E+PEJS Pg0KICAgICAgICA8QSBIUkVGPSJ0d29fai5odG1sI3Jvd3NwYW4iPlJPV1NQQU48L0E+PEJS Pg0KICAgICAgICA8QSBIUkVGPSJ0d29fay5odG1sI3ZzcGFjZSI+VlNQQUNFPC9BPjxCUj4N CiAgICAgICAgPGEgaHJlZj0idHdvX2suaHRtbCN3aWR0aCI+V0lEVEg8L2E+PGJyPg0KPC9E SVY+DQo8QlI+Jm5ic3A7PEJSPg0KPGltZyBzcmM9Ii4uLy4uL2ltYWdlcy8xeDEuZ2lmIiBi b3JkZXI9IjAiIHdpZHRoPSIxIiBoZWlnaHQ9IjYwIj48YnI+DQo8QSBOQU1FPSJjZWxscGFk ZGluZyI+PC9BPg0KPEgzPkNFTExQQURESU5HPC9IMz4NCjx0YWJsZSB3aWR0aD0iNzAwIiBh bGlnbj0iY2VudGVyIiBib3JkZXI9IjAiIGJnY29sb3I9IiNGQUY3RkIiPjx0ciB2YWxpZ249 InRvcCI+PHRkPg0KPGRpdiBjbGFzcz0iYWdhaW4iIHN0eWxlPSJtYXJnaW4tbGVmdDo1O21h cmdpbi1yaWdodDo1O21hcmdpbi1ib3R0b206MTU7Ij4NClRoaW5rIG9mIENFTExQQURESU5H IGFzIHRoZSB3aWR0aCBvZiB0aGUgaW5zaWRlIGNlbGwgYm9yZGVycyBmb3IgdGhlIHRhYmxl IGNlbGxzLiAgSXQgaXMgYW4gYXR0cmlidXRlIG9mIHRoZSAmbHQ7VEFCTEUmZ3Q7IGVsZW1l bnQgd2hpY2ggaXMgc2V0IGZvciB0aGUgZW50aXJlIHRhYmxlIGluIHRoZSB0YWJsZSB0YWcu ICBJbiB0aGUgdGFibGUgYmVsb3csIEkgaGF2ZSBzZXQgdGhlIENFTExQQURESU5HPSIxOCIu PC9kaXY+DQo8VEFCTEUgV0lEVEg9IjUwMCIgYWxpZ249ImNlbnRlciIgQk9SREVSPSIyIiBi b3JkZXJjb2xvcj0iIzU0NjBGNSIgY2VsbHNwYWNpbmc9IjIiIENFTExQQURESU5HPSIxOCIN CiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxNjsiPg0KPFRSPg0KICA8VEQ+QWxsIGNlbGxzIGhh dmUgYSBjZWxscGFkZGluZyBvZiAiMTgiPC9URD4NCiAgPFREPiZuYnNwOzwvVEQ+DQogIDxU RD4gJm5ic3A7SSBsZWZ0IHRoZSBtaWRkbGUgY2VsbCBlbXB0eSwgZXhjZXB0IGZvciBhIHNw YWNlLjxCUj4NCiAgIEkgYWxzbyBzdGFydGVkIHRoZSBmaXJzdCBzZW50ZW5jZSBvZiB0aGlz IGNlbGwgd2l0aCBhIHNwYWNlLjwvVEQ+DQo8L1RSPg0KPC9UQUJMRT4NCjwhLS0gKioqKioq KioqKioqKioqIGVuZCBvZiB0YWJsZSAqKioqKioqKioqKioqKioqKiogLS0+DQo8ZGl2IGNs YXNzPSJhZ2FpbiIgc3R5bGU9Im1hcmdpbi1sZWZ0OjU7bWFyZ2luLXJpZ2h0OjU7bWFyZ2lu LWJvdHRvbToxNjsiPkJlbG93LCB0aGUgY2VsbHBhZGRpbmcgaXMgc2V0IGF0IDIwLCB0aGUg Qk9SREVSIGlzIDI7IENFTExTUEFDSU5HPSIwIi48L2Rpdj4NCjxUQUJMRSB3aWR0aD0iMzAw IiBhbGlnbj0iY2VudGVyIkNFTExQQURESU5HPSIyMCIgQk9SREVSPSIyIiBCT1JERVJDT0xP Uj0ibmF2eSIgQ0VMTFNQQUNJTkc9IjAiPjxUUj4NCjxURD54eHh4eHh4PEJSPlhYWFhYWFg8 QlI+eHh4eHh4eDxCUj5YWFhYWFhYPC9URD4NCjxURD54eHh4eHh4PEJSPlhYWFhYWFg8QlI+ eHh4eHh4eDxCUj5YWFhYWFhYPC9URD4NCjxURD54eHh4eHh4PEJSPlhYWFhYWFg8QlI+eHh4 eHh4eDxCUj5YWFhYWFhYPC9URD4NCjwvVFI+DQo8VFI+DQo8VEQ+eHh4eHh4eDxCUj5YWFhY WFhYPEJSPnh4eHh4eHg8QlI+WFhYWFhYWDwvVEQ+DQo8VEQ+eHh4eHh4eDxCUj5YWFhYWFhY PEJSPnh4eHh4eHg8QlI+WFhYWFhYWDwvVEQ+DQo8VEQ+eHh4eHh4eDxCUj5YWFhYWFhYPEJS Pnh4eHh4eHg8QlI+WFhYWFhYWDwvVEQ+DQo8L1RSPg0KPC9UQUJMRT4NCjxkaXYgY2xhc3M9 ImFnYWluIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NTttYXJnaW4tcmlnaHQ6NTttYXJnaW4tdG9w OjIwOyI+VGhlIENFTExQQURESU5HIG9mIHRoZSBmaXJzdCB0YWJsZSB3YXMgMTggcGl4ZWxz IGFuZCB0aGUgQ0VMTFBBRERJTkcgb2YgdGhlIHNlY29uZCB0YWJsZSB3YXMgMjAgcGl4ZWxz LiAgQ29tcGFyZSB0aGUgaW5uZXIgYm9yZGVyIHNwYWNpbmcgKHdoaXRlIHNwYWNlIHBhZGRp bmcgYXJvdW5kIHRoZSBjZWxsIGNvbnRlbnRzKSBvZiAgZWFjaCBjZWxsIGFuZCBpdHMgY29u dGVudHMgZnJvbSB0aGUgZmlyc3QgdGFibGUgdG8gdGhlIHNlY29uZCB0YWJsZS4gIENhbiB5 b3Ugbm90aWNlIHRoZSBkaWZmZXJlbmNlIG9mIDIgcGl4ZWxzIGluIHRoZSBjZWxscGFkZGlu ZyBmcm9tIG9uZSB0YWJsZSB0byB0aGUgbmV4dD8gPEI+Q0VMTFBBRERJTkcgcmVmZXJzIHRv IHRoZSBpbm5lciBtYXJnaW5zIG9mIGZyZWUgc3BhY2UgdGhhdCBlYWNoIGNlbGwgb2YgYSB0 YWJsZSBoYXMgYXMgaXRzICJwYWRkZWQiIGJvcmRlci48L0I+ICBJdCBpcyBhIGNlbGwgYm9y ZGVyIG9mICJ3aGl0ZSBzcGFjZSIgaW5zaWRlIHRoZSBpbmRpdmlkdWFsIGNlbGxzIG9mIGEg dGFibGUuDQpJZiBhIHRhYmxlIGhhcyBvbmx5IG9uZSBjZWxsLCBvciBoYXMgb25lIGh1bmRy ZWQgY2VsbHMsIHRoZSBhdHRyaWJ1dGUgb2YgY2VsbHNwYWNpbmcgaXMgd3JpdHRlbiBvbmx5 IG9uY2UgaW4gdGhlIHRhYmxlIHRhZy48L2Rpdj4NCg0KPCEtLSAqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKiogZW5kIG9mIHRhYmxlICoqKioqKioqKioqKioqKioqKiAt LT4NCjxpbWcgc3JjPSIuLi8uLi9pbWFnZXMvMXgxLmdpZiIgYm9yZGVyPSIwIiB3aWR0aD0i MSIgaGVpZ2h0PSI1MCI+DQo8aHIgd2lkdGg9IjUwMCIgc2l6ZT0iMyIgY29sb3I9IiNFM0FE RkUiPg0KPGltZyBzcmM9Ii4uLy4uL2ltYWdlcy8xeDEuZ2lmIiBib3JkZXI9IjAiIHdpZHRo PSIxIiBoZWlnaHQ9IjYwIj4NCjwvRElWPg0KPCEtLSAqKioqKioqKioqKioqKioqKioqKioq KioqKiogQ0VMTFNQQUNJTkcgKioqKioqKioqKioqKioqKiogLS0+DQo8QSBOQU1FPSJjZWxs c3BhY2luZyI+PC9BPg0KPEgzPkNFTExTUEFDSU5HPC9IMz4NCg0KPGRpdiBjbGFzcz0iYWdh aW4iIHN0eWxlPSJtYXJnaW4tbGVmdDo1O21hcmdpbi1yaWdodDo1O21hcmdpbi10b3A6MzA7 bWFyZ2luLWJvdHRvbToyMDsiPkNFTExTUEFDSU5HLCBvbiB0aGUgb3RoZXIgaGFuZCwgcmVm ZXJzIHRvIGhvdyBzcGFjZSBpcyBsZWZ0IGJldHdlZW4gZWFjaCBjZWxsIHdhbGwgaW4gYSB0 YWJsZS4gIElmIHlvdSB3YW50IG5vIHNwYWNlcyBhdCBhbGwsIHlvdSBNVVNUIHNldCBDRUxM U1BBQ0lORz0iMCIsIG90aGVyd2lzZSB0aGUgZGVmYXVsdCBpcyBDRUxMU1BBQ0lORz0iMSIs IGV2ZW4gaWYgeW91IGRvbid0IGV2ZW4gbWVudGlvbiBDRUxMU1BBQ0lORy4gIEluIHRoZSBm aXJzdCB0YWJsZSBiZWxvdywgSSB3aWxsIHNldCBCT1JERVI9IjMiIENFTExTUEFDSU5HPSI0 IiBhbmQgQ0VMTFBBRERJTkc9IjEwIi48L2Rpdj4NCjxESVYgQUxJR049ImNlbnRlciI+DQo8 VEFCTEUgQk9SREVSPSIzIiB3aWR0aD0iMzUwIiBCT1JERVJDT0xPUj0iYmx1ZSIgQkdDT0xP Uj0id2hpdGUiIENFTExTUEFDSU5HPSI0IiBDRUxMUEFERElORz0iMjAiIA0Kc3R5bGU9Im1h cmdpbi1ib3R0b206MzA7Ij4NCjxUUiB2YWxpZ249InRvcCI+PHRkIHdpZHRoPSIxMDAiPiZu YnNwOzwvdGQ+DQo8dGQgd2lkdGg9IjEwMCI+Jm5ic3A7PC90ZD48L3RyPg0KPHRyPg0KIDx0 ZCB3aWR0aD0iMTAwIj5jZWxsc3BhY2luZz0iNCIgY2VsbHBhZGRpbmc9IjIwIjwvdGQ+DQog PHRkPiZuYnNwOzwvdGQ+DQo8L1RSPjwvVEFCTEU+DQoNCjxkaXYgY2xhc3M9ImFnYWluIiBz dHlsZT0ibWFyZ2luLWxlZnQ6NTttYXJnaW4tcmlnaHQ6NTttYXJnaW4tdG9wOjMwO21hcmdp bi1ib3R0b206MjA7Ij5OZXh0IHRhYmxlcywgQ0VMTFNQQUNJTkc9IjEwIiBDRUxMUEFERElO Rz0iNCI8L2Rpdj4gICAgICAgIA0KPFRBQkxFIEJPUkRFUj0iMyIgQk9SREVSQ09MT1I9ImJs dWUiIEJHQ09MT1I9IndoaXRlIiBDRUxMU1BBQ0lORz0iMTAiIENFTExQQURESU5HPSI0IiA+ DQo8VFIgVkFMSUdOPSJ0b3AiPg0KPFREPkEgb25lLWNlbGwgdGFibGUuIENlbGxzcGFjaW5n IGlzIDEwIHBpeGVscy48YnI+Q2VsbHBhZGRpbmcgaXMgNCBwaXhlbHMuPC9URD48L1RSPjwv VEFCTEU+PGJyPg0KDQo8VEFCTEUgQk9SREVSPSIzIiBCT1JERVJDT0xPUj0iYmx1ZSIgQkdD T0xPUj0id2hpdGUiIENFTExTUEFDSU5HPSIxMCIgQ0VMTFBBRERJTkc9IjQiID4NCjxUUiBW QUxJR049InRvcCI+DQo8VEQ+QSB0d28tY2VsbCB0YWJsZS4gQ2VsbHNwYWNpbmcgaXMgMTAg cGl4ZWxzLjwvVEQ+PC9UUj4NCjxURD5DZWxscGFkZGluZyBpcyA0LjwvdGQ+PC90cj48L1RB QkxFPg0KDQo8ZGl2IGNsYXNzPSJhZ2FpbiIgc3R5bGU9Im1hcmdpbi1sZWZ0OjU7bWFyZ2lu LXJpZ2h0OjU7bWFyZ2luLXRvcDozMDttYXJnaW4tYm90dG9tOjIwOyI+PEI+Tm90ZTo8L2I+ PEJSPlRoZSBzcGFjZSBiZXR3ZWVuIHRoZSBjZWxscyBhY3Jvc3MgdGhlIHJvd3Mgd2lsbCBv bmx5IGJlIGNvbnRyb2xsZWQgaWYgeW91IHVzZSB0aGUgY2VsbHNwYWNpbmdhdHRyaWJ1dGVz IGluIGNvbWJpbmF0aW9uIHdpdGggYSBXSURUSCBzZXR0aW5nIGZvciBlYWNoIGNlbGwgaW4g dGhlIGZpcnN0IHJvdy48L2Rpdj4NCg0KPCEtLSAqKioqKioqKioqKioqKioqKiogZnVubnkg dGFibGUgKioqKioqKioqKioqKioqKioqIC0tPg0KPERJViBBTElHTj0iY2VudGVyIj48VEFC TEUgQ0VMTFBBRERJTkc9IjEyIiBDRUxMU1BBQ0lORz0iNCIgQk9SREVSPSIyIiBCT1JERVJD T0xPUj0icmVkIg0Kc3R5bGU9Im1hcmdpbi1ib3R0b206MzA7Ij4NCjxUUiBWQUxJR049InRv cCI+DQoJPFREIFdJRFRIPSIxMDAiPlJvdyAxIENlbGwgMTxCUj4mbHQ7VEQgV0lEVEg9IjEw MCImZ3Q7PC9URD4NCgk8VEQgV0lEVEg9IjEwMCI+Um93IDEgQ2VsbCAyPEJSPiZsdDtURCBX SURUSD0iMTAwIiZndDs8L1REPg0KCTxURCBXSURUSD0iMTAwIj5DRUxMUEFERElORz0iMTIi PEJSPkNFTExTUEFDSU5HPSI0IjxCUj5CT1JERVI9IjIiPEJSPiZsdDtURCBXSURUSD0iMTAw IiZndDs8L1REPjwvVFI+DQoNCjxUUiBWQUxJR049InRvcCI+DQoJPFREIEJHQ09MT1I9ImFx dWEiPlJvdyAyIENlbGwgMTxCUj48L1REPg0KCTxURCBCR0NPTE9SPSJhcXVhIj5Sb3cgMiBD ZWxsIDI8L1REPg0KCTxURCBCR0NPTE9SPSJhcXVhIj5DZWxsIDM8QlI+RG8gbm90IHNldCB0 aGU8QlI+d2lkdGggZm9yIHRoZSBjZWxsczxCUj5vZiB0aGUgc2Vjb25kIAlyb3cuPEJSPg0K CVRoZXkgd2lsbCBwbGF5IDxCUj5mb2xsb3ctdGhlLWxlYWRlciwgPEJSPmRvaW5nIHdoYXRl dmVyIHRoZSA8QlI+Y2VsbCBhYm92ZSBpdCBkaWQuDQoJPC9URD4NCjwvVFI+DQo8L1RBQkxF PjwvRElWPg0KPGRpdiBjbGFzcz0iYWdhaW4iIHN0eWxlPSJtYXJnaW4tbGVmdDo1O21hcmdp bi1yaWdodDo1O21hcmdpbi1ib3R0b206MjA7Ij5UaGUgd2F5IHRvIHNldCBhIGNlbGwgd2lk dGggc2V0dGluZyBpcyB0byBpbnNlcnQgaXQgaW5zaWRlIHRoZSAmbHQ7VEQgV0lEVEg9IjEw MCImZ3Q7LjwvYnI+DQpXaGF0IGhhcHBlbnMgaWYgeW91IHNldCB0aGUgY2VsbHNwYWNpbmcg YW5kIHVzZSB0aGUgVEFCTEUgV0lEVEggYnV0IG5vdCB0aGUgQ0VMTCBXSURUSCBzZXR0aW5n cz8gIFlvdSB3aWxsIGdldCB0aGUgY29ycmVjdCBjZWxsc3BhY2luZyBhZ2FpbiwgYnV0IHRo ZSBjZWxscyB3aWxsICJkaXNjb3ZlciIgdGhlaXIgb3duIHdpZHRoIi4gIFNlZSB0aGUgZXhh bXBsZSBiZWxvdzo8L2Rpdj4NCg0KPFRBQkxFIFdJRFRIPSIzMDAiIENFTExTUEFDSU5HPSI0 IiBDRUxMUEFERElORz0iOCIgQk9SREVSPSIyIiBCT1JERVJDT0xPUj0iYmx1ZSI+PFRSPg0K PFREPiZuYnNwOzwvVEQ+DQo8VEQ+Jm5ic3A7PC9URD4NCjxURD4mbmJzcDs8L1REPg0KPC9U Uj48L1RBQkxFPg0KDQo8QkxPQ0tRVU9URT4NCiZsdDtUQUJMRSBXSURUSD0iMzAwIiBDRUxM U1BBQ0lORz0iNCIgQ0VMTFBBRERJTkc9IjgiIEJPUkRFUj0iMiIgQk9SREVSQ09MT1I9ImJs dWUiPiZsdDtUUj48QlI+DQombHQ7VEQmZ3Q7Jm5ic3A7JmFtcDtuYnNwOyZsdDsvVEQmZ3Q7 PEJSPg0KJmx0O1REJmd0OyZuYnNwOyZhbXA7bmJzcDsmbHQ7L1REJmd0OzxCUj4NCiZsdDtU RCZndDsmbmJzcDsmYW1wO25ic3A7Jmx0Oy9URCZndDs8QlI+DQombHQ7L1RSJmd0OyZsdDsv VEFCTEUmZ3Q7PEJSPjwvQkxPQ0tRVU9URT4NCjxBIE5BTUU9Im5vbi1icmVha2luZyBzcGFj ZSI+PC9BPg0KPGRpdiBjbGFzcz0iYWdhaW4iIHN0eWxlPSJtYXJnaW4tbGVmdDo1O21hcmdp bi1yaWdodDo1OyI+PGI+VGlwOjxicj5Db2RlIGEgbm9uLWJyZWFraW5nIHNwYWNlLCA8Qj4m YW1wO25ic3A7PC9CPiAsaW4gZXZlcnkgImVtcHR5IiB0YWJsZSBjZWxsLCBqdXN0IHNvIHRo YXQgdGhlIGNlbGwgaXMgdHJpY2tlZCBpbnRvIHRoaW5raW5nIGl0IGlzICJob2xkaW5nIHNv bWV0aGluZyIuICBJdCBiZWdpbnMgd2l0aCB0aGUgYW1wZXJzYW5kIHRoZW4gdGhlIGxldHRl cnMgbmJzcCBhbmQgZm9sbG93ZWQgYnkgYSBzZW1pY29sb24gKCA7ICkuICAoICZhbXA7bmJz cDsgKTwvYj4NCjwvZGl2Pg0KPGltZyBzcmM9Ii4uLy4uL2ltYWdlcy8xeDEuZ2lmIiBib3Jk ZXI9IjAiIHdpZHRoPSIxIiBoZWlnaHQ9IjUwIj4NCg0KCTxDRU5URVI+PERJViBDTEFTUz0i bmF2IiBTVFlMRT0ibWFyZ2luLXRvcDo2MDsiPjxBIEhSRUY9InR3b19lLmh0bWwiPkJhY2s8 L0E+IHwNCiAgICAgICAgPEEgSFJFRj0idHdvX2cuaHRtbCI+TmV4dDwvQT4NCiAgICAgICAg PC9ESVY+PC9DRU5URVI+DQo8aW1nIHNyYz0iLi4vLi4vaW1hZ2VzLzF4MS5naWYiIGJvcmRl cj0iMCIgd2lkdGg9IjEiIGhlaWdodD0iMzAiPjxicj4NCjxESVYgQ0xBU1M9ImluZGV4Ym90 dG9tIj4gICAgDQogICAgICA8QSBIUkVGPSJ0YWJsZXMuaHRtbCI+TGVzc29uICMxPC9BPiB8 IA0KICAgICAgPEEgSFJFRj0ibGVzc29uMi5odG1sIj5CZWdpbm5pbmcgb2YgTGVzc29uIzI8 L0E+PEJSPiZuYnNwOzxCUj4NCiAgICAgIDxhIGhyZWY9Ii4uLy4uL2ludGVybmV0L3NlYXJj aGVuZ2luZXMzLmh0bWwjbGlzdCI+U2VhcmNoPC9hPiB8DQoJICA8YSBocmVmPSIuLi8uLi93 ZWJzZXJ2aWNlcy9tYWluLmFzcCI+V2ViIFNlcnZpY2VzPC9hPjxicj4mbmJzcDs8YnI+DQoN CiAgICAgIDxBIEhSRUY9IiN0b3AiPlRvcDwvQT4gfA0KICAgICAgPEEgSFJFRj0iLi4vLi4v aW50ZXJuZXQvbmV3cy5odG1sIj5OZXdzPC9BPiB8ICAgICANCiAgICAgIDxBIEhSRUY9Ii4u Ly4uL2ludGVybmV0L3RyYXZlbC5odG1sIj5UcmF2ZWw8L0E+IHwNCiAgICAgIDxhIGhyZWY9 Ii4uLy4uL2NvbXB1dGVycy9pbmRleC5odG1sIj5Db21wdXRlcnM8L2E+IDxicj4NCiAgICAg IDxhIGhyZWY9Ii4uLy4uL2ludGVybmV0L2luZGV4Lmh0bWwiPkludGVybmV0PC9hPiB8DQog ICAgICA8YSBocmVmPSIuLi9pbmRleC5odG1sIj5IVE1MPC9hPiB8DQogICAgICA8YSBocmVm PSIuLi8uLi9kaHRtbC9pbmRleC5odG1sIj5EeW5hbWljIEhUTUw8L2E+IHwNCiAgICAgIDxB IEhSRUY9Ii4uLy4uL3htbC94bWwuaHRtbCI+WE1MPC9BPiA8YnI+DQogICAgICA8QSBIUkVG PSIuLi8uLi9wcm9ncmFtbWluZy9pbmRleC5odG1sIj5Qcm9ncmFtbWluZzwvQT4gfA0KICAg ICAgPGEgaHJlZj0iLi4vLi4vcHJvZ3JhbW1pbmcvanMvamF2YXNjcmlwdC5odG1sIj5KYXZh U2NyaXB0PC9hPiB8DQogICAgICA8QSBIUkVGPSIuLi8uLi9wcm9ncmFtbWluZy9hc3AvYXNw X2lkZXgyLmh0bWwiPkFTUDwvQT4gfA0KICAgICAgPEEgSFJFRj0iLi4vLi4vaW5kZXguaHRt Ij5Ib21lPC9BPg0KPC9ESVY+DQo8IS0tIENsb3N1cmUgb2YgRG9jdW1lbnQgLS0+DQo8RElW IENMQVNTPSJib3R0b20iPg0KPEEgSFJFRj0ibWFpbHRvOndlYm1hc3RlckBoaXRtaWxsLmNv bSI+d2VibWFzdGVyQGhpdG1pbGwuY29tPC9BPjxCUj4mbmJzcDs8QlI+ICAgICANClVwZGF0 ZWQgPHNjcmlwdCBsYW5ndWFnZT0iSmF2YVNjcmlwdCIgc3JjPSIuLi8uLi9zY3JpcHRzL2Rh dGUuanMiPjwvc2NyaXB0PjxCUj4NCiZjb3B5OyBoaXRtaWxsLmNvbTxCUj5BbGwgUmlnaHRz IFJlc2VydmVkPC9ESVY+PEJSPiZuYnNwOzxCUj4NCjwvRElWPg0KPC9CT0RZPg0KPC9IVE1M Pj== --RO8K8208tRZYu2qItJ0d51911w4p1u-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 23 13:55: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 NAA17263 for ; Fri, 23 May 2003 13:55:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4NHtFl14164 for sipping-archive@odin.ietf.org; Fri, 23 May 2003 13:55: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 h4NHtFB14161 for ; Fri, 23 May 2003 13:55: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 NAA17238 for ; Fri, 23 May 2003 13:55:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JGjh-0000Rv-00 for sipping-web-archive@ietf.org; Fri, 23 May 2003 13:53:45 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19JGjg-0000Rs-00 for sipping-web-archive@ietf.org; Fri, 23 May 2003 13:53: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 h4NHqtB12901; Fri, 23 May 2003 13:52: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 h4NCtcB12726 for ; Fri, 23 May 2003 08:55: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 JAA04389; Fri, 23 May 2003 09:27:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JCYX-0004qG-00; Fri, 23 May 2003 09:25:57 -0400 Received: from [208.236.67.14] (helo=gateway.hns.com) by ietf-mx with esmtp (Exim 4.12) id 19JCYW-0004qD-00; Fri, 23 May 2003 09:25:56 -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 h4NDRDun028515; Fri, 23 May 2003 09:27:14 -0400 (EDT) Received: from atlas (atlas.hns.com [139.85.177.110]) by excore8.hns.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h4NDR7sf018347; Fri, 23 May 2003 09:27:07 -0400 (EDT) To: Cc: aki.niemi@nokia.com, rohan@cisco.com, sipping@ietf.org, sipping-admin@ietf.org, thomas.lee@polypix.com Subject: RE: [Sipping] Push-To-Talk with SIP MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Arjun Roychowdhury" Date: Fri, 23 May 2003 09:27:03 -0400 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.12 |February 13, 2003) at 05/23/2003 09:25:09 AM, Serialize complete at 05/23/2003 09:25:09 AM 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: , Markus, I agree. Which is why I referred to the service as '2 way radio' and not PTT , since that term is somewhat synonymous to a particular implementation methodology. Aki and I discussed this in offline e-mails and concluded for this very reason that it doesnt make sense to continue this thread , at least for now, in the IETF :-) regds arjun -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301 212 7860 05/23/2003 09:20 AM To: aroychow@hns.com, cc: , , , , Subject: RE: [Sipping] Push-To-Talk with SIP Hi Arjun, I guess there are several ways to implement "push to talk" type of service. It depends what kind of requirements you have. Sending voice clips inside IM is one type of service, but if you want to do multi-party communication and floor control, that may not be the best way. Another way is to model the communication as conferences (as in SIPPING Conferencing Framework), in which case you will use INVITE-OK-ACK to join and BYE to leave. But as said, there are many ways to implement the actual service using SIP, SIMPLE, conferencing specifications, floor control etc. that it does not seem something that really fits into IETF scope. Of course IETF should continue developing the basic building blocks such as messaging and conferencing related specifications. Markus -----Original Message----- From: ext aroychow@hss.hns.com [mailto:aroychow@hss.hns.com] Sent: 22 May, 2003 15:18 To: Niemi Aki (NMP/Helsinki) Cc: aroychow@hns.com; rohan@cisco.com; sipping@ietf.org; sipping-admin@ietf.org; thomas.lee@polypix.com Subject: RE: [Sipping] Push-To-Talk with SIP Aki, By 'session less' I mean not having an INVITE-OK-ACK to actually establish the call before you could talk. Application state would be maintained during one 'push-release' operation and forgotten after that (except for the administrative states like which was the gruop set I was talking to). Different algorithms have been suggested for this 'voice over IM' => some are also patented @ the uspto (I think someone had posted the patent no. in the impp archive some time ago) Anyway, therefore, I realize this may not be something that the ietf sip grp wants to take up unless there is a compelling reason go into into this 2 way radio service. With respect to the original Q, I agree that one could conceptualize that a call in session with RTP bursts and conferencing thrown in could look like a '2 way radio service' = but due to the nature of its persistance of state for a much longer time than currently known implementations not using SIP, the charging model and complexities would likely not be the same, for what ever its worth. regds arjun -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301 212 7860 aki.niemi@nokia.com Sent by: sipping-admin@ietf.org 05/22/2003 05:32 AM To: cc: , , , Subject: RE: [Sipping] Push-To-Talk with SIP Hi Arjun, I don't really understand what you mean by 'session less', could you elaborate a bit? Do you mean to say there is no application state maintained at the endpoints? And to me, the original question seemed to be whether there have been any drafts or discussions w.r.t. push to talk and SIP in the IETF. And the enswer to that would have to be no, but the conferencing work in SIPPING seems to be covering related issues, e.g., floor control, and media policy. Regards, Aki > -----Original Message----- > From: ext Arjun Roychowdhury [mailto:aroychow@hns.com] > Sent: 21 May, 2003 17:15 > To: Niemi Aki (NMP/Helsinki) > Cc: rohan@cisco.com; sipping@ietf.org; sipping-admin@ietf.org; > thomas.lee@polypix.com > Subject: RE: [Sipping] Push-To-Talk with SIP > > > I think to avoid confusion, it may be better to reword this > is a 'session > less two way radio service', > with session less being the key item. I believe this was the > original > question of the poster. > > Whether this particular approach makes sense to be done in SIP and > especially in the purview of the IETF is another question. > > regds > arjun > > -- > Arjun Roychowdhury @ Hughes Software Systems > 11717 Exploration Lane, Germantown MD 20876 > (O): 301 212 7860 > > > > > aki.niemi@nokia.com > Sent by: sipping-admin@ietf.org > 05/21/2003 08:52 AM > > > To: , > cc: > Subject: RE: [Sipping] Push-To-Talk with SIP > > > Hi Rohan, > > I think this is one way to look at the push to talk feature, > but maybe not > exactly "mainstream". Most of the push to talk services I'm > aware of are > similar to a walkie talkie service, where a group of people are > participating, out of which only one at a time can send media to the > others. "Requesting the floor" in this case is usually done with the > "tangent" button. > > So in my opinion, push to talk is a conference, with a > specific type of > conference and media policy associated with it. As such, I > don't think > it's the IETF's business to define those policies but > provide tools for > setting/manipulating them, which I guess the conference DT > is already > doing. > > -Aki > > > -----Original Message----- > > From: ext Rohan Mahy [mailto:rohan@cisco.com] > > Sent: 20 May, 2003 23:15 > > To: thomas.lee@polypix.com > > Cc: sipping@ietf.org > > Subject: Re: [Sipping] Push-To-Talk with SIP > > > > > > > > Hi, > > > > Push to talk can be implemented by merely setting up a > > session between > > the speaker and the target when the UA becomes available > and leaving > > the session open, but only sending audio media over that > > session when a > > button is pushed. The session can be verified for > liveness by using > > the session-timer, and the target suddenly reappearing after > > an absence > > can be detected using the registration package. Perhaps > > someone could > > write a draft describing this usage? > > > > thanks, > > -rohan > > > > > > On Wednesday, May 14, 2003, at 06:46 PM, ???? ??? wrote: > > > > > Hello, > > > > > > Nokia, Siemens and Ericsson have announced that they are > > developing a > > > push-to-talk application for GSM networks with GPRS and > > for future 3G > > > networks. They want to use SIP for signaling but I > > couldn't find any > > > more detailed information. > > > > > > Does someone of you know some detail about the PTT > > signaling with SIP? > > > Do they care about arbitration if two people want to talk > > to the same > > > group at the same time? Are there some drafts or > discussions about > > > this topics? > > > > > > regards, > > > thomas lee. > > > > _______________________________________________ > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 23 13:55: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 NAA17280 for ; Fri, 23 May 2003 13:55:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4NHtH414183 for sipping-archive@odin.ietf.org; Fri, 23 May 2003 13:55: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 h4NHtHB14180 for ; Fri, 23 May 2003 13:55: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 NAA17242 for ; Fri, 23 May 2003 13:55:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JGjj-0000S1-00 for sipping-web-archive@ietf.org; Fri, 23 May 2003 13:53:47 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19JGjj-0000Ry-00 for sipping-web-archive@ietf.org; Fri, 23 May 2003 13:53: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 h4NHqpB12833; Fri, 23 May 2003 13:52: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 h4NCn3B12444 for ; Fri, 23 May 2003 08:49: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 JAA04269; Fri, 23 May 2003 09:20:47 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JCSB-0004o7-00; Fri, 23 May 2003 09:19:23 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19JCSA-0004nz-00; Fri, 23 May 2003 09:19:22 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4NDKk701045; Fri, 23 May 2003 16:20:46 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 23 May 2003 16:20:45 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 23 May 2003 16:20:45 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3212E.1DF434B6" Subject: RE: [Sipping] Push-To-Talk with SIP Date: Fri, 23 May 2003 16:20:45 +0300 Message-ID: Thread-Topic: [Sipping] Push-To-Talk with SIP Thread-Index: AcMgZSsai7/NKAl0QZOe6NUdSbSlnAAx+FVg To: , Cc: , , , , X-OriginalArrivalTime: 23 May 2003 13:20:45.0742 (UTC) FILETIME=[1E522CE0:01C3212E] Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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_01C3212E.1DF434B6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Arjun, =20 I guess there are several ways to implement "push to talk" type of = service. It depends what kind of requirements you have. Sending voice = clips inside IM is one type of service, but if you want to do = multi-party communication and floor control, that may not be the best = way. Another way is to model the communication as conferences (as in = SIPPING Conferencing Framework), in which case you will use = INVITE-OK-ACK to join and BYE to leave. But as said, there are many ways = to implement the actual service using SIP, SIMPLE, conferencing = specifications, floor control etc. that it does not seem something that = really fits into IETF scope. Of course IETF should continue developing = the basic building blocks such as messaging and conferencing related = specifications. =20 Markus -----Original Message----- From: ext aroychow@hss.hns.com [mailto:aroychow@hss.hns.com] Sent: 22 May, 2003 15:18 To: Niemi Aki (NMP/Helsinki) Cc: aroychow@hns.com; rohan@cisco.com; sipping@ietf.org; = sipping-admin@ietf.org; thomas.lee@polypix.com Subject: RE: [Sipping] Push-To-Talk with SIP Aki,=20 By 'session less' I mean not having an INVITE-OK-ACK to actually = establish the call before you could talk. Application state would be = maintained=20 during one 'push-release' operation and forgotten after that (except for = the administrative states like which was the gruop set I was talking = to).=20 Different algorithms have been suggested for this 'voice over IM' =3D> = some are also patented @ the uspto (I think someone had posted the = patent no.=20 in the impp archive some time ago)=20 Anyway, therefore, I realize this may not be something that the ietf sip = grp wants to take up unless there is a compelling reason=20 go into into this 2 way radio service. With respect to the original Q, I = agree that one could conceptualize that a call in session with RTP=20 bursts and conferencing thrown in could look like a '2 way radio = service' =3D but due to the nature of its persistance of state for a = much longer=20 time than currently known implementations not using SIP, the charging = model and complexities would likely not be the same, for what ever its = worth.=20 regds=20 arjun=20 -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301 212 7860 =20 aki.niemi@nokia.com=20 Sent by: sipping-admin@ietf.org=20 05/22/2003 05:32 AM=20 =20 To: =20 cc: , , = , =20 Subject: RE: [Sipping] Push-To-Talk with SIP Hi Arjun, I don't really understand what you mean by 'session less', could you = elaborate a bit? Do you mean to say there is no application state = maintained at the endpoints?=20 And to me, the original question seemed to be whether there have been = any drafts or discussions w.r.t. push to talk and SIP in the IETF. And = the enswer to that would have to be no, but the conferencing work in = SIPPING seems to be covering related issues, e.g., floor control, and = media policy. Regards, =20 Aki > -----Original Message----- > From: ext Arjun Roychowdhury [mailto:aroychow@hns.com] > Sent: 21 May, 2003 17:15 > To: Niemi Aki (NMP/Helsinki) > Cc: rohan@cisco.com; sipping@ietf.org; sipping-admin@ietf.org; > thomas.lee@polypix.com > Subject: RE: [Sipping] Push-To-Talk with SIP >=20 >=20 > I think to avoid confusion, it may be better to reword this=20 > is a 'session=20 > less two way radio service', > with session less being the key item. I believe this was the=20 > original=20 > question of the poster. >=20 > Whether this particular approach makes sense to be done in SIP and=20 > especially in the purview of the IETF is another question. >=20 > regds > arjun >=20 > -- > Arjun Roychowdhury @ Hughes Software Systems > 11717 Exploration Lane, Germantown MD 20876 > (O): 301 212 7860=20 >=20 >=20 >=20 >=20 > aki.niemi@nokia.com > Sent by: sipping-admin@ietf.org > 05/21/2003 08:52 AM >=20 > =20 > To: , > cc: > Subject: RE: [Sipping] Push-To-Talk with SIP >=20 >=20 > Hi Rohan, >=20 > I think this is one way to look at the push to talk feature,=20 > but maybe not=20 > exactly "mainstream". Most of the push to talk services I'm=20 > aware of are=20 > similar to a walkie talkie service, where a group of people are=20 > participating, out of which only one at a time can send media to the=20 > others. "Requesting the floor" in this case is usually done with the=20 > "tangent" button. >=20 > So in my opinion, push to talk is a conference, with a=20 > specific type of=20 > conference and media policy associated with it. As such, I=20 > don't think=20 > it's the IETF's business to define those policies but=20 > provide tools for=20 > setting/manipulating them, which I guess the conference DT=20 > is already=20 > doing.=20 >=20 > -Aki >=20 > > -----Original Message----- > > From: ext Rohan Mahy [mailto:rohan@cisco.com] > > Sent: 20 May, 2003 23:15 > > To: thomas.lee@polypix.com > > Cc: sipping@ietf.org > > Subject: Re: [Sipping] Push-To-Talk with SIP > >=20 > >=20 > >=20 > > Hi, > >=20 > > Push to talk can be implemented by merely setting up a=20 > > session between=20 > > the speaker and the target when the UA becomes available=20 > and leaving=20 > > the session open, but only sending audio media over that=20 > > session when a=20 > > button is pushed. The session can be verified for=20 > liveness by using=20 > > the session-timer, and the target suddenly reappearing after=20 > > an absence=20 > > can be detected using the registration package. Perhaps=20 > > someone could=20 > > write a draft describing this usage? > >=20 > > thanks, > > -rohan > >=20 > >=20 > > On Wednesday, May 14, 2003, at 06:46 PM, ???? ??? wrote: > >=20 > > > Hello, > > > =20 > > > Nokia, Siemens and Ericsson have announced that they are=20 > > developing a=20 > > > push-to-talk application for GSM networks with GPRS and=20 > > for future 3G=20 > > > networks. They want to use SIP for signaling but I=20 > > couldn't find any=20 > > > more detailed information. > > > =20 > > > Does someone of you know some detail about the PTT=20 > > signaling with SIP? > > > Do they care about arbitration if two people want to talk=20 > > to the same=20 > > > group at the same time? Are there some drafts or=20 > discussions about=20 > > > this topics? > > > =20 > > > regards, > > > thomas lee. > >=20 > > _______________________________________________ > > Sipping mailing list =20 > https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP >=20 >=20 >=20 >=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP=20 Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP ------_=_NextPart_001_01C3212E.1DF434B6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Arjun,
 
I=20 guess there are several ways to implement "push to talk" type of = service. It=20 depends what kind of requirements you have. Sending voice clips inside = IM is one=20 type of service, but if you want to do multi-party communication and = floor=20 control, that may not be the best way. Another way is to model the=20 communication as conferences (as in SIPPING Conferencing = Framework), in=20 which case you will use INVITE-OK-ACK to join and BYE to leave. But as = said,=20 there are many ways to implement the actual service using SIP, SIMPLE,=20 conferencing specifications, floor control etc. that it does not seem = something=20 that really fits into IETF scope. Of course IETF should continue = developing the=20 basic building blocks such as messaging and conferencing related=20 specifications.
 
Markus
-----Original Message-----
From: ext = aroychow@hss.hns.com=20 [mailto:aroychow@hss.hns.com]
Sent: 22 May, 2003 = 15:18
To:=20 Niemi Aki (NMP/Helsinki)
Cc: aroychow@hns.com; = rohan@cisco.com;=20 sipping@ietf.org; sipping-admin@ietf.org;=20 thomas.lee@polypix.com
Subject: RE: [Sipping] Push-To-Talk = with=20 SIP


Aki,
By 'session less' I mean not having an = INVITE-OK-ACK to=20 actually establish the call before you could talk. Application state = would be=20 maintained
during one = 'push-release'=20 operation and forgotten after that (except for the administrative = states like=20 which was the gruop set I was talking to).

Different algorithms have been suggested = for this=20 'voice over IM' =3D> some are also patented @ the uspto (I think = someone had=20 posted the patent no.
in = the impp=20 archive some time ago)

Anyway,=20 therefore, I realize this may not be something that the ietf sip grp = wants to=20 take up unless there is a compelling reason
go into into this 2 way radio service. With respect to the = original Q,=20 I agree that one could conceptualize that a call in session with = RTP=20
bursts and conferencing thrown in = could look=20 like a '2 way radio service' =3D but due to the nature of its = persistance of=20 state for a much longer
time than=20 currently known implementations not using SIP, the charging model and=20 complexities would likely not be the same, for what ever its = worth.=20

regds
arjun

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


aki.niemi@nokia.com=20
Sent by: = sipping-admin@ietf.org=20

05/22/2003 05:32 AM =

        =
        To: =    =20    <aroychow@hns.com>
        cc:      =20  <rohan@cisco.com>, <sipping@ietf.org>,=20 <sipping-admin@ietf.org>, = <thomas.lee@polypix.com>=20
        = Subject:=20        RE: [Sipping] Push-To-Talk with=20 SIP



Hi=20 Arjun,

I don't really understand what you mean by 'session = less', could=20 you elaborate a bit? Do you mean to say there is no application state=20 maintained at the endpoints?

And to me, the original question = seemed=20 to be whether there have been any drafts or discussions w.r.t. push to = talk=20 and SIP in the IETF. And the enswer to that would have to be no, but = the=20 conferencing work in SIPPING seems to be covering related issues, = e.g., floor=20 control, and media policy.

Regards,         =  =20      
Aki


> -----Original=20 Message-----
> From: ext Arjun Roychowdhury=20 [mailto:aroychow@hns.com]
> Sent: 21 May, 2003 17:15
> To: = Niemi=20 Aki (NMP/Helsinki)
> Cc: rohan@cisco.com; sipping@ietf.org;=20 sipping-admin@ietf.org;
> thomas.lee@polypix.com
> = Subject: RE:=20 [Sipping] Push-To-Talk with SIP
>
>
> I think to = avoid=20 confusion, it may be better to reword this
> is a 'session =
>=20 less two way radio service',
> with session less being the key = item. I=20 believe this was the
> original
> question of the=20 poster.
>
> Whether this particular approach makes sense = to be=20 done in SIP and
> especially in the purview of the IETF =  is=20 another question.
>
> regds
> arjun
> =
>=20 --
> Arjun Roychowdhury @ Hughes Software Systems
> 11717=20 Exploration Lane, Germantown MD 20876
> (O): 301 212 7860 =
>=20
>
>
>
> aki.niemi@nokia.com
> Sent = by:=20 sipping-admin@ietf.org
> 05/21/2003 08:52 AM
>
>=20  
>         To:    =20 <rohan@cisco.com>, <thomas.lee@polypix.com>
>   =  =20     cc:     <sipping@ietf.org>
> =    =20     Subject:        RE: [Sipping] = Push-To-Talk=20 with SIP
>
>
> Hi Rohan,
>
> I think = this is=20 one way to look at the push to talk feature,
> but maybe not =
>=20 exactly "mainstream". Most of the push to talk services I'm
> = aware of=20 are
> similar to a walkie talkie service, where a group of = people are=20
> participating, out of which only one at a time can send media = to the=20
> others. "Requesting the floor" in this case is usually done = with the=20
> "tangent" button.
>
> So in my opinion, push to = talk is=20 a conference, with a
> specific type of
> conference and = media=20 policy associated with it. As such, I
> don't think
> = it's the=20 IETF's business to define those policies but
> provide tools = for=20
> setting/manipulating them, which I guess the conference DT =
>=20 is already
> doing.
>
>       =  =20          -Aki
>
>  >=20 -----Original Message-----
>  > From: ext Rohan Mahy=20 [mailto:rohan@cisco.com]
>  > Sent: 20 May, 2003 = 23:15
>=20  > To: thomas.lee@polypix.com
>  > Cc:=20 sipping@ietf.org
>  > Subject: Re: [Sipping] = Push-To-Talk with=20 SIP
>  >
>  >
>  > =
>=20  > Hi,
>  >
>  > Push to talk can = be=20 implemented by merely setting up a
>  > session between =
>  > the speaker and the target when the UA becomes = available=20
> and leaving
>  > the session open, but only = sending=20 audio media over that
>  > session when a
> =  >=20 button is pushed.  The session can be verified for
> = liveness by=20 using
>  > the session-timer, and the target suddenly=20 reappearing after
>  > an absence
>  > = can be=20 detected using the registration package.  Perhaps
> =  >=20 someone could
>  > write a draft describing this = usage?
>=20  >
>  > thanks,
>  > = -rohan
>=20  >
>  >
>  > On Wednesday, May = 14, 2003,=20 at 06:46 PM, ???? ??? wrote:
>  >
>  > = >=20 Hello,
>  > >  
>  > > Nokia, = Siemens=20 and Ericsson have announced that they are
>  > = developing a=20
>  > > push-to-talk application for GSM networks = with GPRS=20 and
>  > for future 3G
>  > > = networks. They=20 want to use SIP for signaling but I
>  > couldn't find = any=20
>  > > more detailed information.
>  > = >=20  
>  > > Does someone of you know some detail = about the=20 PTT
>  > signaling with SIP?
>  > > Do = they=20 care about arbitration if two people want to talk
>  > = to the=20 same
>  > > group at the same time? Are there some = drafts or=20
> discussions about
>  > > this = topics?
>=20  > >  
>  > > regards,
> =  >=20 > thomas lee.
>  >
>  >=20 _______________________________________________
>  > = Sipping=20 mailing list  
>=20 https://www1.ietf.org/mailman/listinfo/sipping
>  > This = list is=20 for NEW development of the application of SIP
>  > Use=20 sip-implementors@cs.columbia.edu for questions on current sip
>=20  > Use sip@ietf.org for new developments of core SIP
>=20  >
> = _______________________________________________
>=20 Sipping mailing list=20  https://www1.ietf.org/mailman/listinfo/sipping
> This list = is for=20 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=20 mailing list =  https://www1.ietf.org/mailman/listinfo/sipping
This list=20 is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for = questions=20 on current sip
Use sip@ietf.org for new developments of core=20 SIP


------_=_NextPart_001_01C3212E.1DF434B6-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 27 02:07: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 CAA24077 for ; Tue, 27 May 2003 02:07:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4R676N10623 for sipping-archive@odin.ietf.org; Tue, 27 May 2003 02:07: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 h4R675B10611 for ; Tue, 27 May 2003 02:07: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 CAA23549 for ; Tue, 27 May 2003 02:06:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KXa8-00000O-00 for sipping-web-archive@ietf.org; Tue, 27 May 2003 02:05:08 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19KXa8-00000K-00 for sipping-web-archive@ietf.org; Tue, 27 May 2003 02:05: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 h4R65pB09391; Tue, 27 May 2003 02:05: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 h4R64YB07338 for ; Tue, 27 May 2003 02:04: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 CAA21022 for ; Tue, 27 May 2003 02:04:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KXXh-0007n1-00 for sipping@ietf.org; Tue, 27 May 2003 02:02:37 -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 19KXXg-0007mv-00 for sipping@ietf.org; Tue, 27 May 2003 02:02:36 -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 h4R64Zbj028153; Tue, 27 May 2003 08:04:35 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 27 May 2003 08:04:34 +0200 Message-ID: From: "Gonzalo Camarillo Gonzalez (LMF)" 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)" Date: Tue, 27 May 2003 08:03:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] WGLC for Q.SIP-SIP mapping draft Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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 From mailnull@www1.ietf.org Thu May 29 07:29:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27242 for ; Thu, 29 May 2003 07:29:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4TBSuK12407 for sipping-archive@odin.ietf.org; Thu, 29 May 2003 07:28: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 h4TBSuB12404 for ; Thu, 29 May 2003 07:28: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 HAA27205 for ; Thu, 29 May 2003 07:28:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LLYz-0005XW-00 for sipping-web-archive@ietf.org; Thu, 29 May 2003 07:27:17 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LLYy-0005XS-00 for sipping-web-archive@ietf.org; Thu, 29 May 2003 07:27:16 -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 h4TBQeB12271; Thu, 29 May 2003 07:26:41 -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 h4TBJoB11970 for ; Thu, 29 May 2003 07:19:50 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26821; Thu, 29 May 2003 07:19:49 -0400 (EDT) Message-Id: <200305291119.HAA26821@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, 29 May 2003 07:19:48 -0400 Subject: [Sipping] I-D ACTION:draft-elwell-sipping-identity-interworking-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 : User identification in a SIP/QSIG environment Author(s) : J. Elwell Filename : draft-elwell-sipping-identity-interworking-00.txt Pages : 31 Date : 2003-5-28 This document examines means of identifying or naming users of telephony services within an enterprise. Numeric names (numbers) are used in traditional Private Integrated Services Networks (PISNs) using QSIG as the network signalling protocol. They are also used for external communication, e.g., with a public Integrated Services Digital Network (ISDN). Names need not be numeric in Internet Protocol (IP) networks employing signalling protocols such as the Session Initiation Protocol (SIP). This document therefore looks at naming schemes that are appropriate within enterprise IP networks, in particular enterprise IP networks employing SIP as the signalling protocol. It also investigates naming schemes that are appropriate in a mixed QSIG/SIP enterprise network and the treatment of names at an interworking point. It details the use of names not only for selecting a user to participate in a call, but also as a means of identifying a user in a call to other users in that call. ENUM and private ENUM-like services are also examined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-elwell-sipping-identity-interworking-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-elwell-sipping-identity-interworking-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-elwell-sipping-identity-interworking-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-5-29072702.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-elwell-sipping-identity-interworking-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-elwell-sipping-identity-interworking-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-29072702.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu May 29 10:57: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 KAA06382 for ; Thu, 29 May 2003 10:57:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4TEvLH27500 for sipping-archive@odin.ietf.org; Thu, 29 May 2003 10:57: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 h4TEvKB27496 for ; Thu, 29 May 2003 10:57:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06371 for ; Thu, 29 May 2003 10:57:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LOob-0007cp-00 for sipping-web-archive@ietf.org; Thu, 29 May 2003 10:55:37 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LOoU-0007cj-00 for sipping-web-archive@ietf.org; Thu, 29 May 2003 10:55: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 h4TEoqB27304; Thu, 29 May 2003 10:50:52 -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 h4TEnRB27229 for ; Thu, 29 May 2003 10: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 KAA06224 for ; Thu, 29 May 2003 10:49:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LOgy-0007aa-00 for sipping@ietf.org; Thu, 29 May 2003 10:47:44 -0400 Received: from mailgate.siemenscomms.co.uk ([194.129.217.115]) by ietf-mx with esmtp (Exim 4.12) id 19LOgx-0007aJ-00 for sipping@ietf.org; Thu, 29 May 2003 10:47:43 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #45905) id <0HFN00201L3XF2@siemenscomms.co.uk> for sipping@ietf.org; Thu, 29 May 2003 15:48:03 +0100 (BST) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #45905) with ESMTP id <0HFN0028JL3U9C@siemenscomms.co.uk> for sipping@ietf.org; Thu, 29 May 2003 15:47:54 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Thu, 29 May 2003 15:48:31 +0100 Content-return: allowed Date: Thu, 29 May 2003 15:37:38 +0100 From: "Elwell, John" Subject: RE: [Sipping] I-D ACTION:draft-elwell-sipping-identity-interworki ng-00.txt To: "'sipping@ietf.org'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT This document has been produced in ECMA, and comments of the SIP community are invited prior to finalisation of the ECMA publication during the coming weeks. john.elwell@siemens.com > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: 29 May 2003 12:20 > Cc: sipping@ietf.org > Subject: [Sipping] I-D > ACTION:draft-elwell-sipping-identity-interworking-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : User identification in a SIP/QSIG environment > Author(s) : J. Elwell > Filename : > draft-elwell-sipping-identity-interworking-00.txt > Pages : 31 > Date : 2003-5-28 > > This document examines means of identifying or naming users of > telephony services within an enterprise. Numeric names (numbers) are > used in traditional Private Integrated Services Networks (PISNs) > using QSIG as the network signalling protocol. They are also used for > external communication, e.g., with a public Integrated Services > Digital Network (ISDN). Names need not be numeric in Internet > Protocol (IP) networks employing signalling protocols such as the > Session Initiation Protocol (SIP). This document therefore looks at > naming schemes that are appropriate within enterprise IP networks, in > particular enterprise IP networks employing SIP as the signalling > protocol. It also investigates naming schemes that are appropriate in > a mixed QSIG/SIP enterprise network and the treatment of names at an > interworking point. It details the use of names not only for > selecting a user to participate in a call, but also as a means of > identifying a user in a call to other users in that call. ENUM and > private ENUM-like services are also examined. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-elwell-sipping-ident ity-interworking-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-elwell-sipping-identity-interworking-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-elwell-sipping-identity-interworking-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu May 29 15:29: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 PAA16446 for ; Thu, 29 May 2003 15:29:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4TJSiH14894 for sipping-archive@odin.ietf.org; Thu, 29 May 2003 15:28: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 h4TJSiB14889 for ; Thu, 29 May 2003 15:28:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16434 for ; Thu, 29 May 2003 15:28:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LT3I-0001nE-00 for sipping-web-archive@ietf.org; Thu, 29 May 2003 15:27:04 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LT3H-0001nB-00 for sipping-web-archive@ietf.org; Thu, 29 May 2003 15:27: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 h4TJPBB14794; Thu, 29 May 2003 15:25: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 h4TJNaB14713 for ; Thu, 29 May 2003 15:23: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 PAA16297 for ; Thu, 29 May 2003 15:23:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LSyK-0001lQ-00 for sipping@ietf.org; Thu, 29 May 2003 15:21:56 -0400 Received: from [12.147.96.23] (helo=lmmx1.fl.icn.siemens.com) by ietf-mx with esmtp (Exim 4.12) id 19LSyK-0001lN-00 for sipping@ietf.org; Thu, 29 May 2003 15:21:56 -0400 Received: from boca210a.boca.ssc.siemens.com (brfw1ext.fl.icn.siemens.com [12.147.96.10]) by lmmx1.fl.icn.siemens.com (8.9.3p2/8.9.3) with ESMTP id PAA26335 for ; Thu, 29 May 2003 15:23:34 -0400 (EDT) Received: by BOCA210A with Internet Mail Service (5.5.2653.19) id ; Thu, 29 May 2003 15:23:34 -0400 Message-ID: From: "Sarkar, Uttam" To: "'sipping@ietf.org'" Date: Thu, 29 May 2003 15:23:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] SIP and TCP transport.... Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Hi All, 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. 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. Thanks, Uttam Sarkar B2BUA A<----------->| | |<-------------->B | | _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 29 15:32: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 PAA16575 for ; Thu, 29 May 2003 15:32:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4TJVXX15008 for sipping-archive@odin.ietf.org; Thu, 29 May 2003 15:31: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 h4TJVWB15005 for ; Thu, 29 May 2003 15:31: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 PAA16543 for ; Thu, 29 May 2003 15:31:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LT60-0001of-00 for sipping-web-archive@ietf.org; Thu, 29 May 2003 15:29:52 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LT60-0001oc-00 for sipping-web-archive@ietf.org; Thu, 29 May 2003 15:29: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 h4TJS7B14868; Thu, 29 May 2003 15:28: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 h4TJOJB14733 for ; Thu, 29 May 2003 15:24: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 PAA16312 for ; Thu, 29 May 2003 15:24:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LSz1-0001lZ-00 for sipping@ietf.org; Thu, 29 May 2003 15:22:39 -0400 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 19LSz0-0001lW-00 for sipping@ietf.org; Thu, 29 May 2003 15:22:38 -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 h4TJNg524574; Thu, 29 May 2003 12:23:43 -0700 (PDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 29 May 2003 12:23:13 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D208B71718@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Elwell, John'" , "'sipping@ietf.org'" Subject: RE: [Sipping] I-D ACTION:draft-elwell-sipping-identity-interworki ng-00.txt Date: Thu, 29 May 2003 12:23:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32617.BE1C523A" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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_01C32617.BE1C523A Content-Type: text/plain Hi John, This is a very useful document. In any case, I've got a few comments: - I would like to see a mention of how to relate SIP URIs and tel URIs for QSIG phone numbers by putting an explicit reference to section 19.1.6 of RFC 3261. This could be somewhere in your draft, perhaps in section 11.2.2. - There doesn't seem to be much guidance in your draft of how to indicate QSIG type of number information using the phone-context. This is precisely the type of thing that the phone-context was created to do for "local" numbers (i.e., within a private domain). For example, a enterprise foo.com might decide to use the following mapping for NPI/TON to phone-context: NPI=Private ISO/IEC 11571, TON= phone-context= ----------------------------------------------------- level 2 regional number level2.foo.com level 1 regional number level1.foo.com local (level 0) number level0.foo.com PISN-specific number special.foo.com unknown number unknown.foo.com Of course, an enterprise could choose to use a phone-context of foo.com as the highest level of the phone number hierarchy, be it Level 2 or Level 1. Also, the host could be diffent that the domain in the phone-context: you could have foo.com in the phone-context and serviceprovider.net as the host domain. Also, this is just an example: the idea is that the enterprise would assign diffent phone contextes to different QSIG types of number. This would yield SIP URIs like sip:53756;phone-context=level0.foo.com@foo.com;user=phone sip:265-3756;phone-context=level1.foo.com@foo.com;user=phone sip:6-911;phone-context=secial.foo.com@foo.com;user=phone This is probably something that should also go in section 11.2.2. All this is very much in line with draft-antti-rfc2806bis-08. > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Thursday, May 29, 2003 07:38 > To: 'sipping@ietf.org' > Subject: RE: [Sipping] I-D > ACTION:draft-elwell-sipping-identity-interworki ng-00.txt > > > This document has been produced in ECMA, and comments of the > SIP community are invited prior to finalisation of the ECMA > publication during the coming weeks. > > john.elwell@siemens.com > > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: 29 May 2003 12:20 > > Cc: sipping@ietf.org > > Subject: [Sipping] I-D > > ACTION:draft-elwell-sipping-identity-interworking-00.txt > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > > > > Title : User identification in a SIP/QSIG environment > > Author(s) : J. Elwell > > Filename : > > draft-elwell-sipping-identity-interworking-00.txt > > Pages : 31 > > Date : 2003-5-28 > > > > This document examines means of identifying or naming users of > > telephony services within an enterprise. Numeric names > (numbers) are > > used in traditional Private Integrated Services Networks (PISNs) > > using QSIG as the network signalling protocol. They are > also used for > > external communication, e.g., with a public Integrated Services > > Digital Network (ISDN). Names need not be numeric in Internet > > Protocol (IP) networks employing signalling protocols such as the > > Session Initiation Protocol (SIP). This document therefore looks at > > naming schemes that are appropriate within enterprise IP > networks, in > > particular enterprise IP networks employing SIP as the signalling > > protocol. It also investigates naming schemes that are > appropriate in > > a mixed QSIG/SIP enterprise network and the treatment of > names at an > > interworking point. It details the use of names not only for > > selecting a user to participate in a call, but also as a means of > > identifying a user in a call to other users in that call. ENUM and > > private ENUM-like services are also examined. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-elwell-sipping-ident > ity-interworking-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-elwell-sipping-identity-interworking-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-elwell-sipping-identity-interworking-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 ------_=_NextPart_001_01C32617.BE1C523A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sipping] I-D = ACTION:draft-elwell-sipping-identity-interworki ng-00.txt

Hi John,

This is a very useful document.

In any case, I've got a few comments:

- I would like to see a mention of how to relate SIP = URIs and tel URIs
  for QSIG phone numbers by putting an explicit = reference to section
  19.1.6 of RFC 3261. This could be somewhere = in your draft, perhaps in
  section 11.2.2.

- There doesn't seem to be much guidance in your = draft of how to
  indicate QSIG type of number information = using the phone-context.
  This is precisely the type of thing that the = phone-context was
  created to do for "local" numbers = (i.e., within a private domain).
  For example, a enterprise foo.com might = decide to use the following
  mapping for NPI/TON to phone-context:

        NPI=3DPrivate = ISO/IEC 11571, TON=3D phone-context=3D
      = -----------------------------------------------------
        level 2 = regional number         =         level2.foo.com
        level 1 = regional number         =         level1.foo.com
        local = (level 0) number          =         level0.foo.com
        PISN-specific number    =         =         special.foo.com
        unknown = number          =         =         unknown.foo.com

  Of course, an enterprise could choose to use a = phone-context of foo.com
  as the highest level of the phone number = hierarchy, be it Level 2 or Level 1.
  Also, the host could be diffent that the = domain in the phone-context: you
  could have foo.com in the phone-context and = serviceprovider.net as the host
  domain. Also, this is just an example: the = idea is that the enterprise
  would assign diffent phone contextes to = different QSIG types of number.

  This would yield SIP URIs like
        sip:53756;phone-context=3Dlevel0.foo.com@foo.com;user=3Dphone
        sip:265-3756;phone-context=3Dlevel1.foo.com@foo.com;user=3Dphon= e
        sip:6-911;phone-context=3Dsecial.foo.com@foo.com;user=3Dphone
 
  This is probably something that should also = go in section 11.2.2.
 
  All this is very much in line with = draft-antti-rfc2806bis-08.

> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@siemens.com]
> Sent: Thursday, May 29, 2003 07:38
> To: 'sipping@ietf.org'
> Subject: RE: [Sipping] I-D
> ACTION:draft-elwell-sipping-identity-interworki = ng-00.txt
>
>
> This document has been produced in ECMA, and = comments of the
> SIP community are invited prior to finalisation = of the ECMA
> publication during the coming weeks.
>
> john.elwell@siemens.com
>
>
> > -----Original Message-----
> > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org= ]
> > Sent: 29 May 2003 12:20
> > Cc: sipping@ietf.org
> > Subject: [Sipping] I-D
> > = ACTION:draft-elwell-sipping-identity-interworking-00.txt
> >
> >
> > A New Internet-Draft is available from the = on-line
> > Internet-Drafts directories.
> >
> >
> >     Title   =         : User identification in a = SIP/QSIG environment
> >     = Author(s)       : J. Elwell
> >     = Filename        :
> > = draft-elwell-sipping-identity-interworking-00.txt
> >     Pages   =         : 31
> >     Date    =         : 2003-5-28
> >    
> > This document examines means of = identifying or naming users of
> > telephony services within an enterprise. = Numeric names
> (numbers) are
> > used in traditional Private Integrated = Services Networks (PISNs)
> > using QSIG as the network signalling = protocol. They are
> also used for
> > external communication, e.g., with a = public Integrated Services
> > Digital Network (ISDN). Names need not be = numeric in Internet
> > Protocol (IP) networks employing = signalling protocols such as the
> > Session Initiation Protocol (SIP). This = document therefore looks at
> > naming schemes that are appropriate within = enterprise IP
> networks, in
> > particular enterprise IP networks = employing SIP as the signalling
> > protocol. It also investigates naming = schemes that are
> appropriate in
> > a mixed QSIG/SIP enterprise network and = the treatment of
> names at an
> > interworking point. It details the use of = names not only for
> > selecting a user to participate in a call, = but also as a means of
> > identifying a user in a call to other = users in that call. ENUM and
> > private ENUM-like services are also = examined.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-elwell-sippi= ng-ident
> ity-interworking-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-elwell-sipping-identity-interworking-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-elwell-sipping-identity-interworking-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. = _______________________________________________

Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the 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_01C32617.BE1C523A-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 29 18:34: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 SAA24586 for ; Thu, 29 May 2003 18:34:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4TMXc228114 for sipping-archive@odin.ietf.org; Thu, 29 May 2003 18:33: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 h4TMXcB28111 for ; Thu, 29 May 2003 18:33: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 SAA24579 for ; Thu, 29 May 2003 18:33:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LVwA-0003TU-00 for sipping-web-archive@ietf.org; Thu, 29 May 2003 18:31:54 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LVw9-0003TQ-00 for sipping-web-archive@ietf.org; Thu, 29 May 2003 18:31: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 h4TMQTB27880; Thu, 29 May 2003 18:26: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 h4TMMiB27710 for ; Thu, 29 May 2003 18:22: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 SAA24257 for ; Thu, 29 May 2003 18:22:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LVlc-0003Pa-00 for sipping@ietf.org; Thu, 29 May 2003 18:21:00 -0400 Received: from radvmail.radvision.com ([12.44.63.10] helo=radvpost.RADVISION.com) by ietf-mx with esmtp (Exim 4.12) id 19LVlb-0003PX-00 for sipping@ietf.org; Thu, 29 May 2003 18:20:59 -0400 Received: by radvpost.radvision.com with Internet Mail Service (5.5.2653.19) id <2JB4JX4D>; Thu, 29 May 2003 18:19:55 -0400 Message-ID: From: Orit Levin To: "'Eric Burger'" Cc: "Sipping (E-mail)" Date: Thu, 29 May 2003 18:19:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Sipping] 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: , 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 mailnull@www1.ietf.org Fri May 30 07:20: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 HAA28842 for ; Fri, 30 May 2003 07:20:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UBK0A25136 for sipping-archive@odin.ietf.org; Fri, 30 May 2003 07:20: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 h4UBK0B25128 for ; Fri, 30 May 2003 07:20: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 HAA28802 for ; Fri, 30 May 2003 07:19:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Lhtr-00029z-00 for sipping-web-archive@ietf.org; Fri, 30 May 2003 07:18:19 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Lhtq-00029w-00 for sipping-web-archive@ietf.org; Fri, 30 May 2003 07:18: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 h4UBIZB24928; Fri, 30 May 2003 07:18: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 h4UBDqB24753 for ; Fri, 30 May 2003 07:13:52 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28125; Fri, 30 May 2003 07:13:50 -0400 (EDT) Message-Id: <200305301113.HAA28125@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, 30 May 2003 07:13:49 -0400 Subject: [Sipping] I-D ACTION:draft-victor-fullmesh-reqts-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 X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h4UBIZB24928 Content-Transfer-Encoding: quoted-printable A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. Title : Requirements for Full-mesh Conference Model using=20 Baseline Session Initiation Protocol Author(s) : V. Paulsamy Filename : draft-victor-fullmesh-reqts-00.txt Pages : 7 Date : 2003-5-29 =09 This memo enumerates requirements to realize full-mesh multiparty=20 conferencing using baseline Session Initiation Protocol. Primary=20 requirement is to advertise conference members=C6 addresses to new=20 participants by concatenating multiple SDP session descriptions=20 together. This particular requirement can solve several well-known=20 problems, including disjoint meshes and race conditions, that are=20 lingering in full-mesh conferencing for a while now. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-victor-fullmesh-reqts-00.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-victor-fullmesh-reqts-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-victor-fullmesh-reqts-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. --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-5-29161442.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-victor-fullmesh-reqts-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-victor-fullmesh-reqts-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-29161442.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 May 30 09:57:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07695 for ; Fri, 30 May 2003 09:57:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UDun104253 for sipping-archive@odin.ietf.org; Fri, 30 May 2003 09:56: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 h4UDunB04250 for ; Fri, 30 May 2003 09:56: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 JAA07658 for ; Fri, 30 May 2003 09:56:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LkLZ-0004iT-00 for sipping-web-archive@ietf.org; Fri, 30 May 2003 09:55:05 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LkLY-0004iP-00 for sipping-web-archive@ietf.org; Fri, 30 May 2003 09:55: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 h4UDtQB04114; Fri, 30 May 2003 09:55: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 h4UDqVB03967 for ; Fri, 30 May 2003 09:52: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 JAA07360 for ; Fri, 30 May 2003 09:52:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LkHO-0004eV-00 for sipping@ietf.org; Fri, 30 May 2003 09:50:46 -0400 Received: from mailgate.siemenscomms.co.uk ([194.129.217.115]) by ietf-mx with esmtp (Exim 4.12) id 19LkHN-0004e9-00 for sipping@ietf.org; Fri, 30 May 2003 09:50:45 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #45905) id <0HFP00301D5GUQ@siemenscomms.co.uk> for sipping@ietf.org; Fri, 30 May 2003 14:51:16 +0100 (BST) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #45905) with ESMTP id <0HFP003MFD5GDA@siemenscomms.co.uk>; Fri, 30 May 2003 14:51:16 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Fri, 30 May 2003 14:51:54 +0100 Content-return: allowed Date: Fri, 30 May 2003 14:52:17 +0100 From: "Elwell, John" Subject: RE: [Sipping] I-D ACTION:draft-elwell-sipping-identity-interworki ng-00.txt To: "'Francois Audet'" , "'sipping@ietf.org'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; 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 Francois, Thanks for your comments. Concerning your point about phone-context, I am not sure that this parameter is defined for a SIP URI (as opposed to a Tel URL). The only reference I can find in RFC3261 is an example at the end of 19.1.6. I agree that your proposed use of this parameter might be useful, but I am reluctant to propose anything without a clearer indication that this is indeed a standard part of the SIP URI. Any other opinions? John John Elwell - Technical Consultant Tel: +44 (0)115 943 4989 Fax: +44 (0)115 943 4969 e-mail: mailto:john.elwell@siemens.com web: http://www.siemens-design-services.com Siemens Communications Technology Drive, Beeston, Nottingham, NG9 1LA. England. "Siemens Communications - a division of Siemens plc, Registered No: 727817, England. Registered office: Siemens House, Oldbury, Bracknell, Berkshire, RG12 8FZ. This communication contains information which is confidential and may also be privileged. It is for the exclusive use of the addressee. If you are not the addressee please note that any distribution, reproduction, copying, publication or use of this communication or the information is prohibited. If you have received this communication in error, please contact us immediately and also delete the communication from your computer. We accept no liability for any loss or damage suffered by any person arising from use of this e-mail." -----Original Message----- From: Francois Audet [mailto:audet@nortelnetworks.com] Sent: 29 May 2003 20:23 To: 'Elwell, John'; 'sipping@ietf.org' Subject: RE: [Sipping] I-D ACTION:draft-elwell-sipping-identity-interworki ng-00.txt Hi John, This is a very useful document. In any case, I've got a few comments: - I would like to see a mention of how to relate SIP URIs and tel URIs for QSIG phone numbers by putting an explicit reference to section 19.1.6 of RFC 3261. This could be somewhere in your draft, perhaps in section 11.2.2. - There doesn't seem to be much guidance in your draft of how to indicate QSIG type of number information using the phone-context. This is precisely the type of thing that the phone-context was created to do for "local" numbers (i.e., within a private domain). For example, a enterprise foo.com might decide to use the following mapping for NPI/TON to phone-context: NPI=Private ISO/IEC 11571, TON= phone-context= ----------------------------------------------------- level 2 regional number level2.foo.com level 1 regional number level1.foo.com local (level 0) number level0.foo.com PISN-specific number special.foo.com unknown number unknown.foo.com Of course, an enterprise could choose to use a phone-context of foo.com as the highest level of the phone number hierarchy, be it Level 2 or Level 1. Also, the host could be diffent that the domain in the phone-context: you could have foo.com in the phone-context and serviceprovider.net as the host domain. Also, this is just an example: the idea is that the enterprise would assign diffent phone contextes to different QSIG types of number. This would yield SIP URIs like sip:53756;phone-context=level0.foo.com@foo.com;user=phone sip:265-3756;phone-context=level1.foo.com@foo.com;user=phone sip:6-911;phone-context=secial.foo.com@foo.com;user=phone This is probably something that should also go in section 11.2.2. All this is very much in line with draft-antti-rfc2806bis-08. > -----Original Message----- > From: Elwell, John [ mailto:john.elwell@siemens.com ] > Sent: Thursday, May 29, 2003 07:38 > To: 'sipping@ietf.org' > Subject: RE: [Sipping] I-D > ACTION:draft-elwell-sipping-identity-interworki ng-00.txt > > > This document has been produced in ECMA, and comments of the > SIP community are invited prior to finalisation of the ECMA > publication during the coming weeks. > > john.elwell@siemens.com > > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [ mailto:Internet-Drafts@ietf.org ] > > Sent: 29 May 2003 12:20 > > Cc: sipping@ietf.org > > Subject: [Sipping] I-D > > ACTION:draft-elwell-sipping-identity-interworking-00.txt > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > > > > Title : User identification in a SIP/QSIG environment > > Author(s) : J. Elwell > > Filename : > > draft-elwell-sipping-identity-interworking-00.txt > > Pages : 31 > > Date : 2003-5-28 > > > > This document examines means of identifying or naming users of > > telephony services within an enterprise. Numeric names > (numbers) are > > used in traditional Private Integrated Services Networks (PISNs) > > using QSIG as the network signalling protocol. They are > also used for > > external communication, e.g., with a public Integrated Services > > Digital Network (ISDN). Names need not be numeric in Internet > > Protocol (IP) networks employing signalling protocols such as the > > Session Initiation Protocol (SIP). This document therefore looks at > > naming schemes that are appropriate within enterprise IP > networks, in > > particular enterprise IP networks employing SIP as the signalling > > protocol. It also investigates naming schemes that are > appropriate in > > a mixed QSIG/SIP enterprise network and the treatment of > names at an > > interworking point. It details the use of names not only for > > selecting a user to participate in a call, but also as a means of > > identifying a user in a call to other users in that call. ENUM and > > private ENUM-like services are also examined. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-elwell-sipping-ident > ity-interworking-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-elwell-sipping-identity-interworking-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-elwell-sipping-identity-interworking-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 mailnull@www1.ietf.org Fri May 30 10:18: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 KAA09665 for ; Fri, 30 May 2003 10:18:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UEHaU06582 for sipping-archive@odin.ietf.org; Fri, 30 May 2003 10:17: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 h4UEHaB06579 for ; Fri, 30 May 2003 10:17: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 KAA09627 for ; Fri, 30 May 2003 10:17:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Lkff-0004wv-00 for sipping-web-archive@ietf.org; Fri, 30 May 2003 10:15:52 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Lkff-0004wr-00 for sipping-web-archive@ietf.org; Fri, 30 May 2003 10:15: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 h4UEFLB06387; Fri, 30 May 2003 10:15: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 h4UEEaB06317 for ; Fri, 30 May 2003 10:14: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 KAA09342 for ; Fri, 30 May 2003 10:14:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Lkcl-0004uc-00 for sipping@ietf.org; Fri, 30 May 2003 10:12:51 -0400 Received: from law11-f12.law11.hotmail.com ([64.4.17.12] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19Lkcl-0004uP-00 for sipping@ietf.org; Fri, 30 May 2003 10:12:51 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 30 May 2003 07:14:00 -0700 Received: from 195.69.162.130 by lw11fd.law11.hotmail.msn.com with HTTP; Fri, 30 May 2003 14:14:00 GMT X-Originating-IP: [195.69.162.130] X-Originating-Email: [simon_issa79@hotmail.com] From: "simon issa" To: sipping@ietf.org Date: Fri, 30 May 2003 14:14:00 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 May 2003 14:14:00.0873 (UTC) FILETIME=[B7A8B990:01C326B5] Subject: [Sipping] Sip/Simple Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Dear Sirs, I would like to know if there is any sip client that is used for instant messaging , my search is for a Sip/Simple IM client , I have been told by my friend that the msn messenger 4.6 does use Sip . Does anyone know how to connect to a sip server using msn messenger 4.6. I have been told also that the windows messenger ( for xp ) uses sip too , but I have not tried it yet . Does anyone know if there is a Simple library in C language , the Sip library is just beyond my need and is very big to understand and use. Any help would be dramatically appreciated !!! Regards. _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri May 30 10:42: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 KAA10970 for ; Fri, 30 May 2003 10:42:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UEgNu08955 for sipping-archive@odin.ietf.org; Fri, 30 May 2003 10:42: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 h4UEgNB08952 for ; Fri, 30 May 2003 10:42: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 KAA10948 for ; Fri, 30 May 2003 10:42:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ll3e-0005GM-00 for sipping-web-archive@ietf.org; Fri, 30 May 2003 10:40:38 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ll3d-0005GJ-00 for sipping-web-archive@ietf.org; Fri, 30 May 2003 10:40: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 h4UEfAB08887; Fri, 30 May 2003 10:41: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 h4UEbrB08674 for ; Fri, 30 May 2003 10:37: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 KAA10723; Fri, 30 May 2003 10:37:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LkzI-0005EH-00; Fri, 30 May 2003 10:36:08 -0400 Received: from terra.polito.it ([130.192.3.81] helo=polito.it) by ietf-mx with esmtp (Exim 4.12) id 19LkzH-0005EE-00; Fri, 30 May 2003 10:36:08 -0400 Received: from [130.192.1.21] (HELO polito.it) by polito.it (CommuniGate Pro SMTP 4.1b2) with ESMTP-TLS id 7855459; Fri, 30 May 2003 16:30:55 +0200 Message-ID: <3ED75A29.8070500@polito.it> Date: Fri, 30 May 2003 15:18:33 +0200 From: Corrado Derenale Reply-To: derenale@polito.it User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 To: vesa.torvinen@ericsson.fi CC: jari.arkko@ericson.fi, aki.niemi@nokia.com, sipping@ietf.org, sip@ietf.org Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020104090105060907060505" Subject: [Sipping] SIP and EAP Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 cryptographically signed message in MIME format. --------------ms020104090105060907060505 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear all, I saw the Torval proposal for authenticate SIP messages with EAP. The IETF document draft-torvinen-http-eap-02.txt Was that proposal been inserted in a new draft or RFC? We are working to find an extensible authentication schema for SIP and are we now evaluating that old proposal. Thank you in advance, Corrado Derenale. --------------ms020104090105060907060505 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIV4zCC BIMwggNroAMCAQICAQswDQYJKoZIhvcNAQEFBQAwQTEQMA4GA1UEChMHRXVyb1BLSTEtMCsG A1UEAxMkRXVyb1BLSSBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAxMTIxMjEw MDAwMFoXDTA2MTIzMTEwMDAwMFowUTELMAkGA1UEBhMCSVQxEDAOBgNVBAoTB0V1cm9QS0kx MDAuBgNVBAMTJ0V1cm9QS0kgSXRhbGlhbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAP7ay1Eyxgv7fW1lpkRT4bljS3Cf7Z5m/KaX pQEsMQfihBXvocVGVqYCTbXl1u+9rbyVV8MtoaZFE2Eb+8tKTA6D2UJpVln2GinHi1Cs+wIV 6Sz55wKaN3tKzGMw3L/H3ADNiYottP//ge3S1P6j0bcGhQ/p/xOGzmALt8CB7KCtn9+VHV8D vcmOqmmQVcymUz9MCN68ZzfLvefAnUzWoIN72fxJDRG8szLj1IYxHOPsoLVID20yGDdyppHt Vr1xUY4rGo5jPCuI79/QxNhQeDyWQo2x2jqM3nVmVXDFRJIms1j7BWpuiEhs0ZJWkaQXd29g mBeZopvMKyAXO3XDDv8CAwEAAaOCAXQwggFwMEwGCWCGSAGG+EIBDQQ/Fj1Jc3N1ZWQgdW5k ZXIgcG9saWN5OgogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9yb290L2Nwcy8xLjEvMDgG CCsGAQUFBwEBBCwwKjAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AuZXVyb3BraS5vcmc6ODAy NjA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3Js L2NybC5kZXIwTgYDVR0gBEcwRTBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6 Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzAfBgNVHSMEGDAWgBSM3IuxpUqQ 506Icxg8ndVefuSyzTAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIB9jAdBgNVHQ4EFgQUqjwT yUkLXM240yDgxZWXMzNdJBMwDQYJKoZIhvcNAQEFBQADggEBAGuphjJQE0RQ28euKSOZ7Q4b vGgPeO8WgGiUHrpZ6vI2+/knSqqK0AQ7j5+4viGMJgm2x8JnYq9ZYy1i0wFrYIxE/G2fw8cW 1P/8sCNzqTj+SO0/2KpJ0BkvuTSG2r1NTeg6a5r61a4jUqp4upKxuzgu6unsw/+RkU2KzlNm 053JOcsM82dIN3NBr+hZs/0IFiMW1GJB2P7225WWDF01OtQcmLYspoiffUPy2g+g4FD5IxHF HKvCG1b9zHmfJoaDn5y+kQQpHs/ZIZeUyNe9ULifu3GgGQKp9sj6bpbGfjW3LAhhG6Ldhf8+ Azi6vNmzQwCbegU26NFazErhLS5qDXQwggU+MIIEJqADAgECAgIBaDANBgkqhkiG9w0BAQUF ADBRMQswCQYDVQQGEwJJVDEQMA4GA1UEChMHRXVyb1BLSTEwMC4GA1UEAxMnRXVyb1BLSSBJ dGFsaWFuIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTAxMTIxNDEwMDAwMFoXDTA2MTIz MTA5MDAwMFowZTELMAkGA1UEBhMCSVQxHjAcBgNVBAoTFVBvbGl0ZWNuaWNvIGRpIFRvcmlu bzE2MDQGA1UEAxMtUG9saXRlY25pY28gZGkgVG9yaW5vIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9sfcfWMG/mS8O69abPfnUWci 6TfUncSlfs8SzpwAsoW1/OJpGVtxq1yKQrP8WqiixEcZWSvnlOcyRj/C0tz3JLQKSAyrHKGS Dkn5Md4HCue+L1JHQ3Ba14eQOj7rAugFgE+6LenTAvguOQl74/t9C93Ldm1NY+t1Fs36oPhP JQ5inrZ6D8P9ol4s/ecyPhhQaU1tioqQy1d01gXTrmI2eH6Ui0AkyexVcxFpXR7qnvPV7huE +ZTDU77t9jx24smmJuSxlA8HQS8I+qCytDhOYsKm676n1a4wpE9VunoVAm/+7tajm31ZYaxT njX891kfFGoFi/J3tIRc67vh8Joy+wIDAQABo4ICCjCCAgYwdQYJYIZIAYb4QgENBGgWZklz c3VlZCB1bmRlciBwb2xpY2llczoKIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9j cHMvMS4xLwogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4xLzBcBggrBgEF BQcBAQRQME4wKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwLmV1cm9wa2kub3JnOjgwMjYwIgYI KwYBBQUHMAKGFmh0dHA6Ly93d3cuZXVyb3BraS5vcmcwOwYDVR0fBDQwMjAwoC6gLIYqaHR0 cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcmwwMi9jcmwuZGVyMIGTBgNVHSAEgYswgYgw QwYKKwYBBAGpBwEBATA1MDMGCCsGAQUFBwIBFidodHRwOi8vd3d3LmV1cm9wa2kub3JnL2Nh L3Jvb3QvY3BzLzEuMS8wQQYKKwYBBAGpBwIBATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vd3d3 LmV1cm9wa2kub3JnL2NhL2l0L2Nwcy8xLjEvMB8GA1UdIwQYMBaAFKo8E8lJC1zNuNMg4MWV lzMzXSQTMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgH2MB0GA1UdDgQWBBT0DG1tnl9M YlY5geDe+Y8vN6CExTANBgkqhkiG9w0BAQUFAAOCAQEAXx26gpm/oiG7ti2+e1Lwmnqn6jk0 ihxIxccazoTAjWzq60x+MhIJsIgRfGtv5U2XzEWc15UZru6srk8TqctT6EbqRMTCtx6mxPd6 RpKp3jepigGOkwnJsnjjUPC/tHmfJHNcll3Rk6a4OIvazlwOoCuQ8D0N9sAGtx35+T+tAyph NU9yHtC3dpvQotLmJFo2Pr6sTy2ijCqQnHxJ2sZUEAlNEunKFP8y3uPfwvE0FEC7lONkUx+U 79yAlwPvBvASUopIQPy7BQ9IMupkj/1DmUvml/05f+DYv2x7UbiUlp1ksQXzs+WLxB2NADfn CaPNvqphRz5KhJGOTJpc8CZ+UDCCBgkwggTxoAMCAQICAgEZMA0GCSqGSIb3DQEBBQUAMGUx CzAJBgNVBAYTAklUMR4wHAYDVQQKExVQb2xpdGVjbmljbyBkaSBUb3Jpbm8xNjA0BgNVBAMT LVBvbGl0ZWNuaWNvIGRpIFRvcmlubyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wMjEw MzEwNzAwMDBaFw0wMzEyMzEwOTAwMDBaMHwxCzAJBgNVBAYTAklUMR4wHAYDVQQKExVQb2xp dGVjbmljbyBkaSBUb3Jpbm8xMTAvBgNVBAsTKERpcGFydGltZW50byBkaSBBdXRvbWF0aWNh IGUgSW5mb3JtYXRpY2ExGjAYBgNVBAMTEUNvcnJhZG8gIERlcmVuYWxlMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAo9UqtuwtaPmMSHeee4DPi2fiRCbSUCG32jlAYeAqoXvx 3rBwfDWHoZvvSn73sYlHptbHdQpp/M0N1RkCSDQGMxSvzoXhy3GYrM63Oy/Tjpfe8R05gnVn 6Q4x9CGNr5Zm5RZWOp12KY2jCb9Q4+krFESFSgB6PUBr/WJnCM4NotvhrYBsdjl1Jaww0A9Y Dyc70Igw9ZqEJ1n5iK3EA8kcv3HyA+NkANXZbz0nCuPkcCw/ixvbGmne09TFTDxwZeXAZtS5 FthofBMk6XOfKE5kgv+6qSUGOh9/myZ3xIS0smbI3BlFqlCawfRrK6YbNjGJRDY7t9hqcrFf Vw1GcwiPowIDAQABo4ICqjCCAqYwgZUGCWCGSAGG+EIBDQSBhxaBhElzc3VlZCB1bmRlciBw b2xpY2llczoKIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLwogaHR0 cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4xLwogaHR0cDovL2NhLnBvbGl0by5p dC9jcHMvMi4xLzARBglghkgBhvhCAQEEBAMCALAwYwYIKwYBBQUHAQEEVzBVMCgGCCsGAQUF BzABhhxodHRwOi8vb2NzcC5ldXJvcGtpLm9yZzo4MDI2MCkGCCsGAQUFBzAChh1odHRwOi8v d3d3LmV1cm9wa2kub3JnL2NhL2l0LzAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY2EucG9s aXRvLml0L2NybDAyL2NybC5kZXIwDAYDVR0TAQH/BAIwADA1BgNVHREELjAsgRJkZXJlbmFs ZUBwb2xpdG8uaXSgFgYKKwYBBAGVYgIBAaAIFgYwMDQzMTcwgc0GA1UdIASBxTCBwjBDBgor BgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9v dC9jcHMvMS4xLzBBBgorBgEEAakHAgEBMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly93d3cuZXVy b3BraS5vcmcvY2EvaXQvY3BzLzEuMS8wOAYKKwYBBAGVYgECATAqMCgGCCsGAQUFBwIBFhxo dHRwOi8vY2EucG9saXRvLml0L2Nwcy8yLjEvMAsGA1UdDwQEAwIE8DAdBgNVHQ4EFgQUfv1U IDpaQBgx9HOFgy8jgA6oWikwHwYDVR0jBBgwFoAU9AxtbZ5fTGJWOYHg3vmPLzeghMUwDQYJ KoZIhvcNAQEFBQADggEBAMe3Au36OVIuXcODCOye1r9cPdvyy7DzQuGqJEP3JPt06c+WEMzH mtJK2rb879X03wOsHxP4QyQxhiplQUkpw/9nx895PHZhOGm7gagpDuIu9UeFC6Pxn64i0iQV phyxUYtY0veDDLXngYbZpgTuD96ljonB1hRlZqopndrY3J/lIk5zqEei31Di5SslYhT2jsEw bQ+vhNtdo7+1Jpzj/movT5zvkD6gdBuwQqHG6oaLaoPECYOpvN8UW0Xy7J1mX/S3+G86HF2R 4xhNzl2LOnnsXhLPkOwucZVzy/G7c764T9OAdnB5djgd/u9afP11wkHjVIOxu8DFlF9oiRGf lx4wggYJMIIE8aADAgECAgIBGTANBgkqhkiG9w0BAQUFADBlMQswCQYDVQQGEwJJVDEeMBwG A1UEChMVUG9saXRlY25pY28gZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xpdGVjbmljbyBkaSBU b3Jpbm8gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDIxMDMxMDcwMDAwWhcNMDMxMjMx MDkwMDAwWjB8MQswCQYDVQQGEwJJVDEeMBwGA1UEChMVUG9saXRlY25pY28gZGkgVG9yaW5v MTEwLwYDVQQLEyhEaXBhcnRpbWVudG8gZGkgQXV0b21hdGljYSBlIEluZm9ybWF0aWNhMRow GAYDVQQDExFDb3JyYWRvICBEZXJlbmFsZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAKPVKrbsLWj5jEh3nnuAz4tn4kQm0lAht9o5QGHgKqF78d6wcHw1h6Gb70p+97GJR6bW x3UKafzNDdUZAkg0BjMUr86F4ctxmKzOtzsv046X3vEdOYJ1Z+kOMfQhja+WZuUWVjqddimN owm/UOPpKxREhUoAej1Aa/1iZwjODaLb4a2AbHY5dSWsMNAPWA8nO9CIMPWahCdZ+YitxAPJ HL9x8gPjZADV2W89Jwrj5HAsP4sb2xpp3tPUxUw8cGXlwGbUuRbYaHwTJOlznyhOZIL/uqkl Bjoff5smd8SEtLJmyNwZRapQmsH0ayumGzYxiUQ2O7fYanKxX1cNRnMIj6MCAwEAAaOCAqow ggKmMIGVBglghkgBhvhCAQ0EgYcWgYRJc3N1ZWQgdW5kZXIgcG9saWNpZXM6CiBodHRwOi8v d3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3BzLzEuMS8KIGh0dHA6Ly93d3cuZXVyb3BraS5v cmcvY2EvaXQvY3BzLzEuMS8KIGh0dHA6Ly9jYS5wb2xpdG8uaXQvY3BzLzIuMS8wEQYJYIZI AYb4QgEBBAQDAgCwMGMGCCsGAQUFBwEBBFcwVTAoBggrBgEFBQcwAYYcaHR0cDovL29jc3Au ZXVyb3BraS5vcmc6ODAyNjApBggrBgEFBQcwAoYdaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9j YS9pdC8wMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NhLnBvbGl0by5pdC9jcmwwMi9jcmwu ZGVyMAwGA1UdEwEB/wQCMAAwNQYDVR0RBC4wLIESZGVyZW5hbGVAcG9saXRvLml0oBYGCisG AQQBlWICAQGgCBYGMDA0MzE3MIHNBgNVHSAEgcUwgcIwQwYKKwYBBAGpBwEBATA1MDMGCCsG AQUFBwIBFidodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3BzLzEuMS8wQQYKKwYB BAGpBwIBATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL2l0L2Nw cy8xLjEvMDgGCisGAQQBlWIBAgEwKjAoBggrBgEFBQcCARYcaHR0cDovL2NhLnBvbGl0by5p dC9jcHMvMi4xLzALBgNVHQ8EBAMCBPAwHQYDVR0OBBYEFH79VCA6WkAYMfRzhYMvI4AOqFop MB8GA1UdIwQYMBaAFPQMbW2eX0xiVjmB4N75jy83oITFMA0GCSqGSIb3DQEBBQUAA4IBAQDH twLt+jlSLl3Dgwjsnta/XD3b8suw80LhqiRD9yT7dOnPlhDMx5rSStq2/O/V9N8DrB8T+EMk MYYqZUFJKcP/Z8fPeTx2YThpu4GoKQ7iLvVHhQuj8Z+uItIkFaYcsVGLWNL3gwy154GG2aYE 7g/epY6JwdYUZWaqKZ3a2Nyf5SJOc6hHot9Q4uUrJWIU9o7BMG0Pr4TbXaO/tSac4/5qL0+c 75A+oHQbsEKhxuqGi2qDxAmDqbzfFFtF8uydZl/0t/hvOhxdkeMYTc5dizp57F4Sz5DsLnGV c8vxu3O+uE/TgHZweXY4Hf7vWnz9dcJB41SDsbvAxZRfaIkRn5ceMYICxTCCAsECAQEwazBl MQswCQYDVQQGEwJJVDEeMBwGA1UEChMVUG9saXRlY25pY28gZGkgVG9yaW5vMTYwNAYDVQQD Ey1Qb2xpdGVjbmljbyBkaSBUb3Jpbm8gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAgEZMAkG BSsOAwIaBQCgggEvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTAzMDUzMDEzMTgzM1owIwYJKoZIhvcNAQkEMRYEFHCtD3YXdakJepxAkUhfHpjeJlTXMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMHwGCyqGSIb3DQEJEAILMW2gazBlMQswCQYD VQQGEwJJVDEeMBwGA1UEChMVUG9saXRlY25pY28gZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xp dGVjbmljbyBkaSBUb3Jpbm8gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAgEZMA0GCSqGSIb3 DQEBAQUABIIBAJSds7qDuU3WCafwaCjHC9AobRL4dicbGM2wVn8x0/dkNST9p9Cz9QSmZ/Tm JLUtFRoMy8BA8GU04ilLBM9MRkj03Pb3vHcSRL+Qi5Oxgcm67HtCYTBQJe1tVIH+P8oD7k1s 30d/0eKRWkXargyr+nzvfOt/0iXhqaapM/bRo/wMQgdNa9i0vTCtVXCQI3jAT1DULLvnIgtg yn1bP8i4WLXBD3rg3obur5j2hFKDcIBWDzUdjMXLDYJGG+503r+q9rypv/Txr7bfsvehY4vf A4bPyxT9s99KdFEgNNUnU/V8/j3mUkTLeTJNB0YYpR0CjqAnTTuqUMVRZDZK9Gg9OiAAAAAA AAA= --------------ms020104090105060907060505-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 30 10: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 KAA11486 for ; Fri, 30 May 2003 10:57:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UEv7C09664 for sipping-archive@odin.ietf.org; Fri, 30 May 2003 10:57: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 h4UEv7B09661 for ; Fri, 30 May 2003 10:57: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 KAA11465 for ; Fri, 30 May 2003 10:57:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LlHt-0005Mi-00 for sipping-web-archive@ietf.org; Fri, 30 May 2003 10:55:21 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LlHt-0005Mf-00 for sipping-web-archive@ietf.org; Fri, 30 May 2003 10:55: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 h4UEtXB09559; Fri, 30 May 2003 10:55: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 h4UEkaB09158 for ; Fri, 30 May 2003 10:46: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 KAA11122 for ; Fri, 30 May 2003 10:46:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ll7j-0005IT-00 for sipping@ietf.org; Fri, 30 May 2003 10:44:51 -0400 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 19Ll7i-0005IM-00 for sipping@ietf.org; Fri, 30 May 2003 10:44:51 -0400 Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 50A2D6A908; Fri, 30 May 2003 17:46:29 +0300 (EEST) Message-ID: <3ED76E63.4080502@piuha.net> Date: Fri, 30 May 2003 17:44:51 +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: derenale@polito.it Cc: vesa.torvinen@ericsson.fi, aki.niemi@nokia.com, sipping@ietf.org Subject: Re: [Sipping] SIP and EAP References: <3ED75A29.8070500@polito.it> In-Reply-To: <3ED75A29.8070500@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 Corrado Derenale wrote: > Dear all, > I saw the Torval proposal for authenticate SIP messages with EAP. > > The IETF document draft-torvinen-http-eap-02.txt > > Was that proposal been inserted in a new draft or RFC? > > We are working to find an extensible authentication schema for SIP and > are we now evaluating that old proposal. This old proposal was later replaced with the use of the specifically needed authentication scheme (UMTS AKA) in the context of Digest framework. The reasons for this switch included the desire to keep EAP only for network access authorization purposes, and the desire to minimize impacts to SIP. See also RFC 3310. --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 Fri May 30 14:02: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 OAA19196 for ; Fri, 30 May 2003 14:02:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UI2IV23703 for sipping-archive@odin.ietf.org; Fri, 30 May 2003 14:02: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 h4UI2IB23700 for ; Fri, 30 May 2003 14:02: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 OAA19189 for ; Fri, 30 May 2003 14:02:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LoB7-0007CY-00 for sipping-web-archive@ietf.org; Fri, 30 May 2003 14:00:33 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LoB6-0007CV-00 for sipping-web-archive@ietf.org; Fri, 30 May 2003 14:00:32 -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 h4UHvjB23469; Fri, 30 May 2003 13:57: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 h4UHuoB23434 for ; Fri, 30 May 2003 13:56: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 NAA19107 for ; Fri, 30 May 2003 13:56:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Lo5p-0007B2-00 for sipping@ietf.org; Fri, 30 May 2003 13:55:05 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19Lo5o-0007Ay-00 for sipping@ietf.org; Fri, 30 May 2003 13:55:04 -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 h4UHtsx23018; Fri, 30 May 2003 12:55:54 -0500 (CDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 May 2003 10:55:54 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D208BD27D0@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Elwell, John'" , "'sipping@ietf.org'" , "'Henning Schulzrinne'" Subject: RE: [Sipping] I-D ACTION:draft-elwell-sipping-identity-interworki ng-00.txt Date: Fri, 30 May 2003 10:55:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C326D4.B55F0E36" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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_01C326D4.B55F0E36 Content-Type: text/plain Hi John, In the SIP BNF description in RFC3261, on page 223, it is stated that if the userinfo in the SIP-URI is a telephone-subscriber (as opposed to a user), then the telephone-subscriber BNF is defined in RFC2806. (Although not explicitely stated, I assume it also means that the "user=phone" user-param needs to be included). Perhaps Henning can confirm? The guidance I have described below is indeed when a telephone-subscriber instead of a user (for the userinfo) is used. I think it would be very useful to spell out that type of guidance in the QSIG identity interworking draft. Of course, it would also be doable to use the user instead of the telephone-subscriber field in the userinfo. In that case, essentially any type of user@hostport format is allowed, and there is not much guidance we can give. It then becomes a matter of converting phone numbers to SIP URIs. QSIG-Private/Level1=265-3756 could be mapped to sip:2653756@foo.com, (or sip:audet@foo.com for that matter). > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Friday, May 30, 2003 06:52 > To: Audet, Francois [SC100:4K02:EXCH]; 'sipping@ietf.org' > Subject: RE: [Sipping] I-D > ACTION:draft-elwell-sipping-identity-interworki ng-00.txt > > > Francois, > > Thanks for your comments. Concerning your point about > phone-context, I am not sure that this parameter is defined > for a SIP URI (as opposed to a Tel URL). The only reference I > can find in RFC3261 is an example at the end of 19.1.6. I > agree that your proposed use of this parameter might be > useful, but I am reluctant to propose anything without a > clearer indication that this is indeed a standard part of the > SIP URI. Any other opinions? > > John > > John Elwell - Technical Consultant > Tel: +44 (0)115 943 4989 > Fax: +44 (0)115 943 4969 > e-mail: mailto:john.elwell@siemens.com > > web: http://www.siemens-design-services.com > > > Siemens Communications > Technology Drive, Beeston, Nottingham, NG9 1LA. England. > > "Siemens Communications - a division of Siemens plc, > Registered No: 727817, England. Registered office: Siemens > House, Oldbury, Bracknell, Berkshire, RG12 8FZ. > > This communication contains information which is confidential > and may also be privileged. It is for the exclusive use of > the addressee. If you are not the addressee please note that > any distribution, reproduction, copying, publication or use > of this communication or the information is prohibited. If > you have received this communication in error, please contact > us immediately and also delete the communication from your > computer. We accept no liability for any loss or damage > suffered by any person arising from use of this e-mail." > > > > -----Original Message----- > From: Francois Audet [mailto:audet@nortelnetworks.com] > Sent: 29 May 2003 20:23 > To: 'Elwell, John'; 'sipping@ietf.org' > Subject: RE: [Sipping] I-D > ACTION:draft-elwell-sipping-identity-interworki > ng-00.txt > > > > Hi John, > > This is a very useful document. > > In any case, I've got a few comments: > > - I would like to see a mention of how to relate SIP URIs and > tel URIs > for QSIG phone numbers by putting an explicit reference to section > 19.1.6 of RFC 3261. This could be somewhere in your draft, > perhaps in > section 11.2.2. > > - There doesn't seem to be much guidance in your draft of how to > indicate QSIG type of number information using the phone-context. > This is precisely the type of thing that the phone-context was > created to do for "local" numbers (i.e., within a private domain). > For example, a enterprise foo.com might decide to use the following > mapping for NPI/TON to phone-context: > > NPI=Private ISO/IEC 11571, TON= phone-context= > ----------------------------------------------------- > level 2 regional number level2.foo.com > level 1 regional number level1.foo.com > local (level 0) number level0.foo.com > PISN-specific number special.foo.com > unknown number unknown.foo.com > > Of course, an enterprise could choose to use a > phone-context of foo.com > as the highest level of the phone number hierarchy, be it > Level 2 or Level 1. > Also, the host could be diffent that the domain in the > phone-context: you > could have foo.com in the phone-context and > serviceprovider.net as the host > domain. Also, this is just an example: the idea is that the > enterprise > would assign diffent phone contextes to different QSIG > types of number. > > This would yield SIP URIs like > sip:53756;phone-context=level0.foo.com@foo.com;user=phone > sip:265-3756;phone-context=level1.foo.com@foo.com;user=phone > sip:6-911;phone-context=secial.foo.com@foo.com;user=phone > > This is probably something that should also go in section 11.2.2. > > All this is very much in line with draft-antti-rfc2806bis-08. > > > -----Original Message----- > > From: Elwell, John [ mailto:john.elwell@siemens.com > ] > > Sent: Thursday, May 29, 2003 07:38 > > To: 'sipping@ietf.org' > > Subject: RE: [Sipping] I-D > > ACTION:draft-elwell-sipping-identity-interworki ng-00.txt > > > > > > This document has been produced in ECMA, and comments of the > > SIP community are invited prior to finalisation of the ECMA > > publication during the coming weeks. > > > > john.elwell@siemens.com > > > > > > > -----Original Message----- > > > From: Internet-Drafts@ietf.org [ mailto:Internet-Drafts@ietf.org > ] > > > Sent: 29 May 2003 12:20 > > > Cc: sipping@ietf.org > > > Subject: [Sipping] I-D > > > ACTION:draft-elwell-sipping-identity-interworking-00.txt > > > > > > > > > A New Internet-Draft is available from the on-line > > > Internet-Drafts directories. > > > > > > > > > Title : User identification in a SIP/QSIG > environment > > > Author(s) : J. Elwell > > > Filename : > > > draft-elwell-sipping-identity-interworking-00.txt > > > Pages : 31 > > > Date : 2003-5-28 > > > > > > This document examines means of identifying or naming users of > > > telephony services within an enterprise. Numeric names > > (numbers) are > > > used in traditional Private Integrated Services Networks (PISNs) > > > using QSIG as the network signalling protocol. They are > > also used for > > > external communication, e.g., with a public Integrated Services > > > Digital Network (ISDN). Names need not be numeric in Internet > > > Protocol (IP) networks employing signalling protocols such as the > > > Session Initiation Protocol (SIP). This document > therefore looks at > > > naming schemes that are appropriate within enterprise IP > > networks, in > > > particular enterprise IP networks employing SIP as the signalling > > > protocol. It also investigates naming schemes that are > > appropriate in > > > a mixed QSIG/SIP enterprise network and the treatment of > > names at an > > > interworking point. It details the use of names not only for > > > selecting a user to participate in a call, but also as a means of > > > identifying a user in a call to other users in that call. > ENUM and > > > private ENUM-like services are also examined. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-elwell-sipping-ident > > > ity-interworking-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-elwell-sipping-identity-interworking-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-elwell-sipping-identity-interworking-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 > > ------_=_NextPart_001_01C326D4.B55F0E36 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sipping] I-D = ACTION:draft-elwell-sipping-identity-interworki ng-00.txt

Hi John,

In the SIP BNF description in RFC3261, on page 223, = it is stated
that if the userinfo in the SIP-URI is a = telephone-subscriber
(as opposed to a user), then the = telephone-subscriber BNF is
defined in RFC2806. (Although not explicitely = stated, I assume
it also means that the "user=3Dphone" = user-param needs to be
included). Perhaps Henning can confirm?

The guidance I have described below is indeed when = a
telephone-subscriber instead of a user (for the = userinfo) is
used. I think it would be very useful to spell out = that
type of guidance in the QSIG identity interworking = draft.

Of course, it would also be doable to use the user = instead of the
telephone-subscriber field in the userinfo. In that = case,
essentially any type of user@hostport format is = allowed, and there
is not much guidance we can give. It then becomes a = matter of
converting phone numbers to SIP URIs. = QSIG-Private/Level1=3D265-3756 could
be mapped to sip:2653756@foo.com, (or = sip:audet@foo.com for that matter).

> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@siemens.com]
> Sent: Friday, May 30, 2003 06:52
> To: Audet, Francois [SC100:4K02:EXCH]; = 'sipping@ietf.org'
> Subject: RE: [Sipping] I-D
> ACTION:draft-elwell-sipping-identity-interworki = ng-00.txt
>
>
> Francois,
> 
> Thanks for your comments. Concerning your point = about
> phone-context, I am not sure that this = parameter is defined
> for a SIP URI (as opposed to a Tel URL). The = only reference I
> can find in RFC3261 is an example at the end of = 19.1.6. I
> agree that your proposed use of this parameter = might be
> useful, but I am reluctant to propose anything = without a
> clearer indication that this is indeed a = standard part of the
> SIP URI. Any other opinions?
> 
> John
> 
> John Elwell - Technical Consultant
> Tel: +44 (0)115 943 4989
> Fax: +44 (0)115 943 4969
> e-mail: mailto:john.elwell@siemens.com
> <mailto:john.elwell@siemens.com> 
> web: http://www.siemens-design-services.com
> <http://www.siemens-design-services.com/>  =
>
> Siemens Communications
> Technology Drive, Beeston, Nottingham, NG9 = 1LA.  England.
>
> "Siemens Communications - a division of = Siemens plc, 
> Registered No: 727817, England. Registered = office: Siemens
> House, Oldbury, Bracknell, Berkshire, RG12 = 8FZ.
>
> This communication contains information which = is confidential
> and may also be privileged. It is for the = exclusive use of
> the addressee. If you are not the addressee = please note that
> any distribution, reproduction, copying, = publication or use
> of this communication or the information is = prohibited. If
> you have received this communication in error, = please contact
> us immediately and also delete the = communication from your
> computer. We accept no liability for any loss = or damage
> suffered by any person arising from use of this = e-mail."
>
> 
>
> -----Original Message-----
> From: Francois Audet [mailto:audet@nortelnetworks.com= ]
> Sent: 29 May 2003 20:23
> To: 'Elwell, John'; 'sipping@ietf.org'
> Subject: RE: [Sipping] I-D
> = ACTION:draft-elwell-sipping-identity-interworki
> ng-00.txt
>
>
>
> Hi John,
>
> This is a very useful document.
>
> In any case, I've got a few comments:
>
> - I would like to see a mention of how to = relate SIP URIs and
> tel URIs
>   for QSIG phone numbers by putting = an explicit reference to section
>   19.1.6 of RFC 3261. This could be = somewhere in your draft,
> perhaps in
>   section 11.2.2.
>
> - There doesn't seem to be much guidance in = your draft of how to
>   indicate QSIG type of number = information using the phone-context.
>   This is precisely the type of thing = that the phone-context was
>   created to do for "local" = numbers (i.e., within a private domain).
>   For example, a enterprise foo.com = might decide to use the following
>   mapping for NPI/TON to = phone-context:
>
>         = NPI=3DPrivate ISO/IEC 11571, TON=3D phone-context=3D
>       = -----------------------------------------------------
>         = level 2 regional = number           =       level2.foo.com
>         = level 1 regional = number           =       level1.foo.com
>         = local (level 0) = number           =        level0.foo.com
>         = PISN-specific = number           =          special.foo.com =
>         = unknown = number           =             =    unknown.foo.com
>
>   Of course, an enterprise could = choose to use a
> phone-context of foo.com
>   as the highest level of the phone = number hierarchy, be it
> Level 2 or Level 1.
>   Also, the host could be diffent = that the domain in the
> phone-context: you
>   could have foo.com in the = phone-context and
> serviceprovider.net as the host
>   domain. Also, this is just an = example: the idea is that the
> enterprise
>   would assign diffent phone = contextes to different QSIG
> types of number.
>
>   This would yield SIP URIs like =
>         = sip:53756;phone-context=3Dlevel0.foo.com@foo.com;user=3Dphone
>         = sip:265-3756;phone-context=3Dlevel1.foo.com@foo.com;user=3Dphone =
>         = sip:6-911;phone-context=3Dsecial.foo.com@foo.com;user=3Dphone
>  
>   This is probably something that = should also go in section 11.2.2.
>  
>   All this is very much in line with = draft-antti-rfc2806bis-08.
>
> > -----Original Message-----
> > From: Elwell, John [ mailto:john.elwell@siemens.com
> <mailto:john.elwell@siemens.com> ]
> > Sent: Thursday, May 29, 2003 07:38
> > To: 'sipping@ietf.org'
> > Subject: RE: [Sipping] I-D
> > = ACTION:draft-elwell-sipping-identity-interworki ng-00.txt
> >
> >
> > This document has been produced in ECMA, = and comments of the
> > SIP community are invited prior to = finalisation of the ECMA
> > publication during the coming weeks. =
> >
> > john.elwell@siemens.com
> >
> >
> > > -----Original Message-----
> > > From: Internet-Drafts@ietf.org [ mailto:Internet-Drafts@ietf.org=
> <mailto:Internet-Drafts@ietf.org= > ]
> > > Sent: 29 May 2003 12:20
> > > Cc: sipping@ietf.org
> > > Subject: [Sipping] I-D
> > > = ACTION:draft-elwell-sipping-identity-interworking-00.txt
> > >
> > >
> > > A New Internet-Draft is available = from the on-line
> > > Internet-Drafts directories.
> > >
> > >
> > >     = Title           : = User identification in a SIP/QSIG
> environment
> > >     = Author(s)       : J. Elwell
> > >     = Filename        :
> > > = draft-elwell-sipping-identity-interworking-00.txt
> > >     = Pages           : 31 =
> > >     = Date            = : 2003-5-28
> > >    
> > > This document examines means of = identifying or naming users of
> > > telephony services within an = enterprise. Numeric names
> > (numbers) are
> > > used in traditional Private = Integrated Services Networks (PISNs)
> > > using QSIG as the network signalling = protocol. They are
> > also used for
> > > external communication, e.g., with a = public Integrated Services
> > > Digital Network (ISDN). Names need = not be numeric in Internet
> > > Protocol (IP) networks employing = signalling protocols such as the
> > > Session Initiation Protocol (SIP). = This document
> therefore looks at
> > > naming schemes that are appropriate = within enterprise IP
> > networks, in
> > > particular enterprise IP networks = employing SIP as the signalling
> > > protocol. It also investigates naming = schemes that are
> > appropriate in
> > > a mixed QSIG/SIP enterprise network = and the treatment of
> > names at an
> > > interworking point. It details the = use of names not only for
> > > selecting a user to participate in a = call, but also as a means of
> > > identifying a user in a call to other = users in that call.
> ENUM and
> > > private ENUM-like services are also = examined.
> > >
> > > A URL for this Internet-Draft = is:
> > > http://www.ietf.org/internet-drafts/draft-elwell-sippi= ng-ident
> <http://www.ietf.org/internet-drafts/draft-elwell-sippi= ng-ident> 
> > ity-interworking-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-elwell-sipping-identity-interworking-00.txt". =
> >
> > A list of Internet-Drafts directories can = be found in
> http://www.ietf.org/shadow.html <http://www.ietf.org/shadow.html> 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> <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-elwell-sipping-identity-interworking-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
> <https://www1.ietf.org/mailman/listinfo/sipping>=  
> This list is for NEW development of the = 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_01C326D4.B55F0E36-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 30 14:55: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 OAA21421 for ; Fri, 30 May 2003 14:55:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UIsf627936 for sipping-archive@odin.ietf.org; Fri, 30 May 2003 14:54:41 -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 h4UIsfB27933 for ; Fri, 30 May 2003 14:54:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21401 for ; Fri, 30 May 2003 14:54:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Lozn-00001z-00 for sipping-web-archive@ietf.org; Fri, 30 May 2003 14:52:55 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Lozm-00001u-00 for sipping-web-archive@ietf.org; Fri, 30 May 2003 14:52: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 h4UIrQB27841; Fri, 30 May 2003 14:53: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 h4UIq3B27778 for ; Fri, 30 May 2003 14:52: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 OAA21327 for ; Fri, 30 May 2003 14:51:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LoxF-00000Y-00 for sipping@ietf.org; Fri, 30 May 2003 14:50:17 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19LoxE-00000T-00 for sipping@ietf.org; Fri, 30 May 2003 14:50:16 -0400 Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h4UIpukN017483 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 30 May 2003 14:51:56 -0400 (EDT) Received: from grandcentral.cs.columbia.edu (localhost [127.0.0.1]) by grandcentral.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h4UIpt5U028822; Fri, 30 May 2003 14:51:55 -0400 (EDT) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.12.9/8.12.9/Submit) id h4UIptlQ028819; Fri, 30 May 2003 14:51:55 -0400 (EDT) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <16087.43083.30611.581059@grandcentral.cs.columbia.edu> Date: Fri, 30 May 2003 14:51:55 -0400 To: sipping@ietf.org Cc: victor@tamura-broad.com Subject: Re: [Sipping] I-D ACTION:draft-victor-fullmesh-reqts-00.txt In-Reply-To: <200305301113.HAA28125@ietf.org> References: <200305301113.HAA28125@ietf.org> X-Mailer: VM 7.14 under Emacs 20.7.1 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4UIq3B27779 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org 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 h4UIrQB27841 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4UIsfB27933 Content-Transfer-Encoding: 8bit On Friday, May 30 2003, "Internet-Drafts@ietf.org" wrote to "IETF-Announce: ;, sipping@ietf.org" saying: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Requirements for Full-mesh Conference Model using > Baseline Session Initiation Protocol > Author(s) : V. Paulsamy > Filename : draft-victor-fullmesh-reqts-00.txt > Pages : 7 > Date : 2003-5-29 > > This memo enumerates requirements to realize full-mesh multiparty > conferencing using baseline Session Initiation Protocol. Primary > requirement is to advertise conference membersĘ addresses to new > participants by concatenating multiple SDP session descriptions > together. This particular requirement can solve several well-known > problems, including disjoint meshes and race conditions, that are > lingering in full-mesh conferencing for a while now. I've read over this document; it's not really a requirements document, but rather an argument for a particular approach to solving the problem. It seems to imply that a minor protocol modification can be used to cause baseline SIP to support full mesh conferences. This clearly isn't true; end points are going to have to negotiate support for it, since current end points don't support it. The idea of carrying end point identifiers in SDP isn't necessarily a bad one, though. I've been studying on full mesh conferencing, and after writing a simulator for full mesh conferencing, using a simplified model of SIP, I think the problem is rather more complicated than Victor realizes. I've written a paper on it, which I'll be presenting at NOSSDAV next week. It's available from my homepage -- . I think this would be useful input to further discussion of full mesh conferencing, since I've explained a lot of the relevant issues there rather better than I could do it off the top of my head in e-mail. -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-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 May 30 19:35: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 TAA03337 for ; Fri, 30 May 2003 19:35:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UNZT617019 for sipping-archive@odin.ietf.org; Fri, 30 May 2003 19:35: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 h4UNZSB17016 for ; Fri, 30 May 2003 19:35: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 TAA03334 for ; Fri, 30 May 2003 19:35:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LtNa-0002cS-00 for sipping-web-archive@ietf.org; Fri, 30 May 2003 19:33:46 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LtNZ-0002cP-00 for sipping-web-archive@ietf.org; Fri, 30 May 2003 19:33: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 h4UNXbB16923; Fri, 30 May 2003 19:33: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 h4UNWCB16830 for ; Fri, 30 May 2003 19:32:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03215 for ; Fri, 30 May 2003 19:32:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LtKQ-0002a7-00 for sipping@ietf.org; Fri, 30 May 2003 19:30:30 -0400 Received: from mail26c.sbc-webhosting.com ([216.173.237.166]) by ietf-mx with smtp (Exim 4.12) id 19LtKP-0002a4-00 for sipping@ietf.org; Fri, 30 May 2003 19:30:29 -0400 Received: from www.tamura-broad.com (64.143.38.143) by mail26c.sbc-webhosting.com (RS ver 1.0.80vs) with SMTP id 3-0123457518; Fri, 30 May 2003 19:31:59 -0400 (EDT) Reply-To: From: "Victor A Paulsamy" To: "'Jonathan Lennox'" , Cc: Subject: RE: [Sipping] I-D ACTION:draft-victor-fullmesh-reqts-00.txt Date: Fri, 30 May 2003 16:31:54 -0700 Organization: Tamura Corp Message-ID: <002401c32703$a7d22c60$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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <16087.43083.30611.581059@grandcentral.cs.columbia.edu> X-Loop-Detect: 1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4UNWCB16831 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 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 Inline ... -----Original Message----- >From: Jonathan Lennox [mailto:lennox@cs.columbia.edu] >It seems to imply that a minor protocol modification can be used to cause >baseline SIP to support full mesh conferences. This clearly isn't true; >end >points are going to have to negotiate support for it, since current end >points don't support it. The idea of carrying end point identifiers in SDP >isn't necessarily a bad one, though. This is a good point; I overlooked it. I'm inclined to solving it using a, "session-level property attribute that applies to conference as a whole" [from 2327]. It could be something like "a=playoutmix." This attribute needs to be defined. When "a=playoutmix" is present, it indicates that an end system supports session-level mixing for play out and if absent, it is not supported. Hence, to support full-mesh conferencing, both offer and answer must have "a=playoutmix" attribute. When inviting a new entity into the conference, the offerer carries session-level "a=playoutmix." The answer must contain "a=playoutmix" to establish a dialog. Otherwise, it's ACKed and BYE is sent to terminate the dialog (as usual). In the case of new ones joining the conference, if the incoming request didn't have "a=playoutmix", a member can choose to discard it, silently. 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 Sat May 31 01: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 BAA12520 for ; Sat, 31 May 2003 01:45:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4V5jNw07382 for sipping-archive@odin.ietf.org; Sat, 31 May 2003 01:45: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 h4V5jNB07379 for ; Sat, 31 May 2003 01: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 BAA12517 for ; Sat, 31 May 2003 01:45:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Lz9V-0005Ad-00 for sipping-web-archive@ietf.org; Sat, 31 May 2003 01:43:37 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Lz9V-0005Aa-00 for sipping-web-archive@ietf.org; Sat, 31 May 2003 01:43: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 h4V5iUB07351; Sat, 31 May 2003 01:44: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 h4V5hcB07328 for ; Sat, 31 May 2003 01:43: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 BAA12505 for ; Sat, 31 May 2003 01:43:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Lz7o-0005AI-00 for sipping@ietf.org; Sat, 31 May 2003 01:41:52 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19Lz7o-0005AE-00 for sipping@ietf.org; Sat, 31 May 2003 01:41:52 -0400 Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h4V5h0ZE005158; Sat, 31 May 2003 01:43:01 -0400 (EDT) Message-ID: <3ED840E0.5000704@dynamicsoft.com> Date: Sat, 31 May 2003 01:42:56 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Audet CC: "'Elwell, John'" , "'sipping@ietf.org'" , "'Henning Schulzrinne'" Subject: Re: [Sipping] I-D ACTION:draft-elwell-sipping-identity-interworki ng-00.txt References: <2F1FC1DEA077D5119FAD00508BCFD6D208BD27D0@zsc3c030.us.nortel.com> In-Reply-To: <2F1FC1DEA077D5119FAD00508BCFD6D208BD27D0@zsc3c030.us.nortel.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 Francois Audet wrote: > Hi John, > > In the SIP BNF description in RFC3261, on page 223, it is stated > that if the userinfo in the SIP-URI is a telephone-subscriber > (as opposed to a user), then the telephone-subscriber BNF is > defined in RFC2806. (Although not explicitely stated, I assume > it also means that the "user=phone" user-param needs to be > included). Perhaps Henning can confirm? Yes. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sat May 31 01: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 BAA12660 for ; Sat, 31 May 2003 01:58:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4V5w4507671 for sipping-archive@odin.ietf.org; Sat, 31 May 2003 01:58: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 h4V5w4B07668 for ; Sat, 31 May 2003 01: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 BAA12656 for ; Sat, 31 May 2003 01:58:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LzLn-0005D5-00 for sipping-web-archive@ietf.org; Sat, 31 May 2003 01:56:19 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LzLm-0005D2-00 for sipping-web-archive@ietf.org; Sat, 31 May 2003 01:56: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 h4V5vCB07630; Sat, 31 May 2003 01:57: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 h4V5uuB07597 for ; Sat, 31 May 2003 01:56: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 BAA12639 for ; Sat, 31 May 2003 01:56:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LzKg-0005Cd-00 for sipping@ietf.org; Sat, 31 May 2003 01:55:10 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19LzKg-0005Ca-00 for sipping@ietf.org; Sat, 31 May 2003 01:55:10 -0400 Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h4V5trZE005165; Sat, 31 May 2003 01:55:53 -0400 (EDT) Message-ID: <3ED843E4.1000408@dynamicsoft.com> Date: Sat, 31 May 2003 01:55:48 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Sarkar, Uttam" CC: "'sipping@ietf.org'" Subject: Re: [Sipping] SIP and TCP transport.... 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 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. Genreally there is a separate connection used for requests in each direction. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sat May 31 07:52: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 HAA29725 for ; Sat, 31 May 2003 07:52:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4VBq4708113 for sipping-archive@odin.ietf.org; Sat, 31 May 2003 07:52: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 h4VBq4B08110 for ; Sat, 31 May 2003 07: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 HAA29721 for ; Sat, 31 May 2003 07:52:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19M4sO-0006ma-00 for sipping-web-archive@ietf.org; Sat, 31 May 2003 07:50:20 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19M4sO-0006mX-00 for sipping-web-archive@ietf.org; Sat, 31 May 2003 07:50: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 h4VBpEB08084; Sat, 31 May 2003 07:51: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 h4VBneB08037 for ; Sat, 31 May 2003 07: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 HAA29705 for ; Sat, 31 May 2003 07:49:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19M4q5-0006m2-00 for sipping@ietf.org; Sat, 31 May 2003 07:47:57 -0400 Received: from law11-f110.law11.hotmail.com ([64.4.17.110] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19M4q4-0006la-00 for sipping@ietf.org; Sat, 31 May 2003 07:47:56 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 31 May 2003 04:49:07 -0700 Received: from 195.69.162.130 by lw11fd.law11.hotmail.msn.com with HTTP; Sat, 31 May 2003 11:49:07 GMT X-Originating-IP: [195.69.162.130] X-Originating-Email: [simon_issa79@hotmail.com] From: "simon issa" To: sipping@ietf.org Date: Sat, 31 May 2003 11:49:07 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 31 May 2003 11:49:07.0927 (UTC) FILETIME=[A4AC2E70:01C3276A] Subject: [Sipping] Simple Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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