From sipping-bounces@ietf.org Wed Jun 01 04:45:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdOqw-0000VQ-SN; Wed, 01 Jun 2005 04:45:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdOqu-0000Um-4d for sipping@megatron.ietf.org; Wed, 01 Jun 2005 04:45:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05992 for ; Wed, 1 Jun 2005 04:45:25 -0400 (EDT) Received: from smtp8.clb.oleane.net ([213.56.31.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdPAh-0005l0-30 for sipping@ietf.org; Wed, 01 Jun 2005 05:05:55 -0400 Received: from Pavillonquatre (upperside.rain.fr [194.206.151.59] (may be forged)) (authenticated) by smtp8.clb.oleane.net with ESMTP id j518ipVg023574 for ; Wed, 1 Jun 2005 10:44:58 +0200 Message-Id: <200506010844.j518ipVg023574@smtp8.clb.oleane.net> From: "Chantal Ladouce" To: Date: Wed, 1 Jun 2005 10:45:16 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVmhjtqoB+bOEOgS2ukHKPzfnsi3Q== X-Spam-Score: 0.1 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Subject: [Sipping] International SIP conference/exhibition - Call for proposals X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0702309352==" Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============0702309352== Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01C56696.FF3D9280" This is a multi-part message in MIME format. ------=_NextPart_000_004D_01C56696.FF3D9280 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The International SIP conference/exhibition will stand in Paris next February 2006, 21-24. The call for proposals dead line has been extended to June 17. Get all details at: http://www.upperside.fr/sip2006/sip2006intro.htm ------=_NextPart_000_004D_01C56696.FF3D9280 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The International SIP conference/exhibition = will stand in Paris next February 2006, 21-24.

 The call for = proposals dead line has been extended to June  17.

 

Get all details at:

http://www.upperside.fr/sip2006/sip2006intro.htm<= /span>

 

------=_NextPart_000_004D_01C56696.FF3D9280-- --===============0702309352== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============0702309352==-- From sipping-bounces@ietf.org Wed Jun 01 16:07:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdZUq-0007hL-TQ; Wed, 01 Jun 2005 16:07:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdZUn-0007gP-Rn; Wed, 01 Jun 2005 16:07:21 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25881; Wed, 1 Jun 2005 16:07:19 -0400 (EDT) Message-Id: <200506012007.QAA25881@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 01 Jun 2005 16:07:19 -0400 Cc: sipping@ietf.org Subject: [Sipping] I-D ACTION:draft-ietf-sipping-transc-framework-02.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org --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 : Framework for Transcoding with the Session Initiation Protocol (SIP) Author(s) : G. Camarillo Filename : draft-ietf-sipping-transc-framework-02.txt Pages : 10 Date : 2005-6-1 This document defines a framework for transcoding with SIP. This framework includes how to discover the need of transcoding services in a session and how to invoke those transcoding services. Two models for transcoding services invocation are discussed: the conference bridge model and the third party call control model. Both models meet the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing, and speech-impaired individuals. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-transc-framework-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-transc-framework-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sipping-transc-framework-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-6-1154740.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-transc-framework-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-transc-framework-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-1154740.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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-- From sipping-bounces@ietf.org Wed Jun 01 19:36:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdclG-00047S-B6; Wed, 01 Jun 2005 19:36:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdclE-00047I-ME for sipping@megatron.ietf.org; Wed, 01 Jun 2005 19:36:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20577 for ; Wed, 1 Jun 2005 19:36:29 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ddd59-0005tJ-KH for sipping@ietf.org; Wed, 01 Jun 2005 19:57:07 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j51NaSrN020668 for ; Wed, 1 Jun 2005 18:36:29 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 2 Jun 2005 00:36:28 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00FC60326@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'sipping@ietf.org'" Subject: RE: [Sipping] I-D ACTION:draft-ietf-sipping-toip-00.txt Date: Thu, 2 Jun 2005 00:36:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Can someone tell me whether this is the same as the document that appears previously in the i-d index as "Framework of requirements for real-time text conversation using SIP.", Arnoud Van Wijk, 20-Oct-04, This document provides the framework of requirements for text conversation with real time character-by-character interactive flow over the IP network using the Session Initiation Protocol. The requirements for general real-time text-over-IP telephony, point-to point and conference calls, transcoding, relay services, user mobility, interworking between text-over-IP telephony and existing text-telephony, and some special features including instant messaging have been described. Note date for apparently identical filename. Or am I missing some great secret of the IETF universe here? regards Keith > -----Original Message----- > From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org]On > Behalf Of Internet-Drafts@ietf.org > Sent: 27 May 2005 20:46 > To: i-d-announce@ietf.org > Cc: sipping@ietf.org > Subject: [Sipping] I-D ACTION:draft-ietf-sipping-toip-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Session Initiation Proposal > Investigation Working Group of the IETF. > > Title : Framework of requirements for > real-time text conversation using SIP. > Author(s) : A. Van Wijk > Filename : draft-ietf-sipping-toip-00.txt > Pages : 37 > Date : 2005-5-27 > > This document provides the framework of requirements for text > conversation with real time character-by-character interactive > flow over the IP network using the Session Initiation Protocol. > The requirements for general real-time text-over-IP telephony, > point-to point and conference calls, transcoding, relay services, > user mobility, interworking between text-over-IP telephony and > existing text-telephony, and some special features including > instant messaging have been described. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipping-toip-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in > the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-toip-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-toip-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 sipping-bounces@ietf.org Thu Jun 02 05:43:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdmEs-00035p-Ra; Thu, 02 Jun 2005 05:43:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdmEr-00035k-TH for sipping@megatron.ietf.org; Thu, 02 Jun 2005 05:43:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24352 for ; Thu, 2 Jun 2005 05:43:43 -0400 (EDT) Message-Id: <200506020943.FAA24352@ietf.org> Received: from mx1.cambrium.nl ([217.19.16.130] helo=gollum.cambrium.nl ident=[CyfrjsHoMrYKkFuphEy3tnRkRr+AQ8lo]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DdmYr-00026x-RG for sipping@ietf.org; Thu, 02 Jun 2005 06:04:26 -0400 Received: (qmail 23797 invoked from network); 2 Jun 2005 09:43:35 -0000 Received: from 82-197-192-189.dsl.cambrium.nl (HELO solstice) (82.197.192.189) by gollum.cambrium.nl with SMTP; 2 Jun 2005 09:43:35 -0000 From: "Arnoud van Wijk" To: "'Drage, Keith \(Keith\)'" , Subject: RE: [Sipping] I-D ACTION:draft-ietf-sipping-toip-00.txt Date: Thu, 2 Jun 2005 11:43:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <475FF955A05DD411980D00508B6D5FB00FC60326@en0033exch001u.uk.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVnA1ipNn5GUNBXQj64XL+6SUkjYgAVCI3w X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Hi Keith, Yes this is the same draft resurrected. We are right now working on the next version of this draft. So expect to see a -01 version before the Paris IETF. And since this draft is resurrected and everybody can read it, if you have comments, questions, ideas, things we need to include... Please let me know! Thanks in advance.. And aaah yes the IETF move in mysterious ways.. :-) Greetz Arnoud Arnoud A. T. van Wijk Viataal Research & Development Theerestraat 42 5271 GD Sint-Michielsgestel The Netherlands. Mobile: +31651921948 International text telephone: +31735588408 -----Original Message----- From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf Of Drage, Keith (Keith) Sent: donderdag 2 juni 2005 1:36 To: 'sipping@ietf.org' Subject: RE: [Sipping] I-D ACTION:draft-ietf-sipping-toip-00.txt Can someone tell me whether this is the same as the document that appears previously in the i-d index as "Framework of requirements for real-time text conversation using SIP.", Arnoud Van Wijk, 20-Oct-04, This document provides the framework of requirements for text conversation with real time character-by-character interactive flow over the IP network using the Session Initiation Protocol. The requirements for general real-time text-over-IP telephony, point-to point and conference calls, transcoding, relay services, user mobility, interworking between text-over-IP telephony and existing text-telephony, and some special features including instant messaging have been described. Note date for apparently identical filename. Or am I missing some great secret of the IETF universe here? regards Keith > -----Original Message----- > From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org]On > Behalf Of Internet-Drafts@ietf.org > Sent: 27 May 2005 20:46 > To: i-d-announce@ietf.org > Cc: sipping@ietf.org > Subject: [Sipping] I-D ACTION:draft-ietf-sipping-toip-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Session Initiation Proposal > Investigation Working Group of the IETF. > > Title : Framework of requirements for > real-time text conversation using SIP. > Author(s) : A. Van Wijk > Filename : draft-ietf-sipping-toip-00.txt > Pages : 37 > Date : 2005-5-27 > > This document provides the framework of requirements for text > conversation with real time character-by-character interactive > flow over the IP network using the Session Initiation Protocol. > The requirements for general real-time text-over-IP telephony, > point-to point and conference calls, transcoding, relay services, > user mobility, interworking between text-over-IP telephony and > existing text-telephony, and some special features including > instant messaging have been described. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipping-toip-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in > the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-toip-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-toip-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 sipping-bounces@ietf.org Thu Jun 02 09:48:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddq3R-0003Dt-2c; Thu, 02 Jun 2005 09:48:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddq3O-0003BR-PH; Thu, 02 Jun 2005 09:48:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14475; Thu, 2 Jun 2005 09:48:08 -0400 (EDT) From: Mpierce1@aol.com Received: from imo-m15.mx.aol.com ([64.12.138.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdqNR-00064U-3S; Thu, 02 Jun 2005 10:08:53 -0400 Received: from Mpierce1@aol.com by imo-m15.mx.aol.com (mail_out_v38_r1.7.) id c.e6.6afbda60 (17377); Thu, 2 Jun 2005 09:46:57 -0400 (EDT) Message-ID: Date: Thu, 2 Jun 2005 09:46:57 EDT To: jmpolk@cisco.com, iesg@ietf.org, sip@ietf.org, sipping@ietf.org MIME-Version: 1.0 X-Mailer: 7.0 for Windows sub 10689 X-Spam-Score: 0.7 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: Subject: [Sipping] Re: [Sip] Comments on Last Call of "Extending Reason-header for Preemption Ev... X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1865723006==" Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org --===============1865723006== Content-Type: multipart/alternative; boundary="part1_e6.6afbda60.2fd067d1_boundary" --part1_e6.6afbda60.2fd067d1_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 5/29/2005 6:17:03 PM Eastern Daylight Time, jmpolk@cisco.com writes: > >Section 7 IANA Considerations > >As noted above, this section contains an erroneous statement about what > >"syntax shall be used". At the same time, it is unclear what the IANA > >registration requirements are. For example, this part implies that IANA > >needs to register the text strings, when there is clearly no need for that. > You didn't respond to the above comment I submitted. I suspect it requires a little better explanation on my part. Since this draft defines a new reason value, it must be assumed that it is based on, and follows everything in, RFC 3326. However, it doesn't make a clear statement that the syntax follows what is defined in RFC 3326. As I read the syntax in Section 2 of RFC 3326, the reason header may contain multiple reason-values (e.g., both SIP and Q.850) and for each protocol may specify multiple reason-parameters (e.g., cause value and text), and each is optional. The syntax defined in Section 2 allows the use of a cause value without the accompanying text string, although the examples don't ever show that. (However, the final paragraph of Section 2 of RFC 3326 implies that multiple protocols are indicated by the use on multiple headers - "multiple Reason lines" - not by putting multiple protocols into one header.) This draft, on the other hand, contains statements like: the following syntax shall be used: Reason: preemption ;cause=1 ;text="UA Preemption" This implies that the text part is mandatory. It seems that part of the problem is the way that the syntax was defined in RFC 3326. While it implied that the text part is always used, the formal definition shows it as optional. Concerning IANA registration, RFC 3326 only required the registration of the protocols (SIP and Q.950) since all cause values and text strings were defined elsewhere. This draft extends that model by requiring the registration of more than the new protocol ("preemption"). It implies that both cause values and text strings need to be registered, but this is not clear. Rather than containing more description of the procedures for use of these parameters, Section 7 needs explicit statements about IANA registration requirements. Mike Pierce --part1_e6.6afbda60.2fd067d1_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a me= ssage dated 5/29/2005 6:17:03 PM Eastern Daylight Time, jmpolk@cisco.com wri= tes:


>Section 7 IANA Consideratio= ns
>As noted above, this section contains an erroneous statement about what=20=
>"syntax shall be used". At the same time, it is unclear what the IANA >registration requirements are. For example, this part implies that IANA=20=
>needs to register the text strings, when there is clearly no need for th= at.


You didn't respond to the above comment I submitted. I suspect it requires a= little better explanation on my part.

Since this draft defines a new reason value, it must be assumed that it is b= ased on, and follows everything in, RFC 3326. However, it doesn't make a cle= ar statement that the syntax follows what is defined in RFC 3326.

As I read the syntax in Section 2 of RFC 3326, the reason header may contain= multiple reason-values (e.g., both SIP and Q.850) and for each protocol may= specify multiple reason-parameters (e.g., cause value and text), and each i= s optional. The syntax defined in Section 2 allows the use of a cause value=20= without the accompanying text string, although the examples don't ever show=20= that.

(However, the final paragraph of Section 2 of RFC 3326 implies that multiple= protocols are indicated by the use on multiple headers - "multiple Reason l= ines" - not by putting multiple protocols into one header.)

This draft, on the other hand, contains statements like:

the following syntax shall be used:

         Reason: preemption ;cause= =3D1 ;text=3D"UA Preemption"

This implies that the text part is mandatory.

It seems that part of the problem is the way that the syntax was defined in=20= RFC 3326. While it implied that the text part is always used, the formal def= inition shows it as optional.

Concerning IANA registration, RFC 3326 only required the registration of the= protocols (SIP and Q.950) since all cause values and text strings were defi= ned elsewhere. This draft extends that model by requiring the registration o= f more than the new protocol ("preemption"). It implies that both cause valu= es and text strings need to be registered, but this is not clear. Rather tha= n containing more description of the procedures for use of these parameters,= Section 7 needs explicit statements about IANA registration requirements.
Mike Pierce

 --part1_e6.6afbda60.2fd067d1_boundary-- --===============1865723006== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============1865723006==-- From sipping-bounces@ietf.org Thu Jun 02 13:35:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddtbg-0006bC-Av; Thu, 02 Jun 2005 13:35:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddtbf-0006b0-9X for sipping@megatron.ietf.org; Thu, 02 Jun 2005 13:35:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10225 for ; Thu, 2 Jun 2005 13:35:43 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ddtvf-0002qA-Q2 for sipping@ietf.org; Thu, 02 Jun 2005 13:56:31 -0400 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j52HYgl24960; Thu, 2 Jun 2005 13:34:43 -0400 (EDT) Received: from [127.0.0.1] (acart18v.ca.nortel.com [47.130.24.194]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 29WL6CFR; Thu, 2 Jun 2005 13:35:29 -0400 Message-ID: <429F435E.7020303@nortel.com> Date: Thu, 02 Jun 2005 13:35:26 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: John Atkinson , Marvin Bienn , Gonzalo.Camarillo@ericsson.com Subject: [Sipping] Response ambiguity in RFC 3398 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org RFC 3398 has the following advice for generation of a response when an ACM with 'Subscriber Free' is received: 7.2.6 ACM received Most commonly, on receipt of an ACM a provisional response (in the 18x class) SHOULD be sent to the SIP network. If the INVITE that initiated this session contained legitimate and comprehensible encapsulated ISUP, then the ACM received by the gateway SHOULD be encapsulated in the provisional response. If the ACM contains a Backward Call Indicators parameter with a value of 'subscriber free', the gateway SHOULD send a '180 Ringing' response. When a 180 is sent, it is assumed, in the absence of any early media extension, that any necessary ringback tones will be generated locally by the SIP user agent to which the gateway is responding (which may in turn be a gateway). The very next paragraph talks about cases where the ACM indicates in-band media. It concludes with the following: After early media transmission has been initiated, the gateway SHOULD send a 183 Session Progress response code. Did the authors intend that a 180 be sent first, followed by the 183, or did they intend that 183 is sent instead of 180? Note that particularly if the latter is the case, Study Group 11 has an action to amend Q.1912.5 to align it with RFC 3398 on this point. Tom Taylor _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Thu Jun 02 18:09:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddxsw-00011q-OB; Thu, 02 Jun 2005 18:09:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddxst-000119-AW; Thu, 02 Jun 2005 18:09:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05475; Thu, 2 Jun 2005 18:09:48 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdyD0-0002kh-0R; Thu, 02 Jun 2005 18:30:38 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 02 Jun 2005 15:09:42 -0700 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j52M9abw003229; Thu, 2 Jun 2005 15:09:37 -0700 (PDT) Received: from jmpolk-wxp.cisco.com (sjc-vpn1-488.cisco.com [10.21.97.232]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA02261; Thu, 2 Jun 2005 15:09:37 -0700 (PDT) Message-Id: <4.3.2.7.2.20050602170857.033486d8@diablo.cisco.com> X-Sender: jmpolk@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 02 Jun 2005 17:09:36 -0500 To: Mpierce1@aol.com, iesg@ietf.org, sip@ietf.org, sipping@ietf.org From: "James M. Polk" Subject: Re: [Sipping] Re: [Sip] Comments on Last Call of "Extending Reason-header for Preemption Ev... In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org At 09:46 AM 6/2/2005 -0400, Mpierce1@aol.com wrote: >In a message dated 5/29/2005 6:17:03 PM Eastern Daylight Time, >jmpolk@cisco.com writes: > > >> >Section 7 IANA Considerations >> >As noted above, this section contains an erroneous statement about what >> >"syntax shall be used". At the same time, it is unclear what the IANA >> >registration requirements are. For example, this part implies that IANA >> >needs to register the text strings, when there is clearly no need for that. > > >You didn't respond to the above comment I submitted. Because SIP and Q.850 have clearly defined meanings for their cause numbers, and this extension does not, I believe the text string should be maintained through IANA. From an IANA point of view, at http://www.iana.org/assignments/sip-parameters you can see the text string for each 1XX, 2XX, 3XX, 4XX, 5XX and 6XX response code that would be used if the SIP protocol were used in a 3326 Reason header. As IANA is where to first look up these things, I'm not sure why you have an issue with IANA having the same text string explaining what each cause is in the Preemption protocol of the Reason header. If the text string were removed in the IANA registration, there would be no clue there what each cause number meant. This is not the case right now at http://www.iana.org/assignments/sip-parameters for all other SIP parameters. I believe one of your concerns is the user learning/reading the reason in the Reason header within your domain, and I believe that is a local configuration decision. In the document, I do not believe I ever made it a MUST, SHOULD, RECOMMENDED or even a MAY be presented to the user of the UA who is being preempted. I believe this is up to the implementation and local policy to show, or not to show. >I suspect it requires a little better explanation on my part. > >Since this draft defines a new reason value, it must be assumed that it is >based on, and follows everything in, RFC 3326. However, it doesn't make a >clear statement that the syntax follows what is defined in RFC 3326. > >As I read the syntax in Section 2 of RFC 3326, the reason header may >contain multiple reason-values (e.g., both SIP and Q.850) and for each >protocol may specify multiple reason-parameters (e.g., cause value and >text), and each is optional. The syntax defined in Section 2 allows the >use of a cause value without the accompanying text string, although the >examples don't ever show that. > >(However, the final paragraph of Section 2 of RFC 3326 implies that >multiple protocols are indicated by the use on multiple headers - >"multiple Reason lines" - not by putting multiple protocols into one header.) > >This draft, on the other hand, contains statements like: > >the following syntax shall be used: > > Reason: preemption ;cause=1 ;text="UA Preemption" > >This implies that the text part is mandatory. > >It seems that part of the problem is the way that the syntax was defined >in RFC 3326. While it implied that the text part is always used, the >formal definition shows it as optional. > >Concerning IANA registration, RFC 3326 only required the registration of >the protocols (SIP and Q.950) since all cause values and text strings were >defined elsewhere. This draft extends that model by requiring the >registration of more than the new protocol ("preemption"). It implies that >both cause values and text strings need to be registered, but this is not >clear. Rather than containing more description of the procedures for use >of these parameters, Section 7 needs explicit statements about IANA >registration requirements. > >Mike Pierce > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Fri Jun 03 15:56:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeIHC-0001Ld-FG; Fri, 03 Jun 2005 15:56:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeIH8-0001Kw-IB; Fri, 03 Jun 2005 15:56:14 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29365; Fri, 3 Jun 2005 15:56:12 -0400 (EDT) Message-Id: <200506031956.PAA29365@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 03 Jun 2005 15:56:12 -0400 Cc: sipping@ietf.org Subject: [Sipping] I-D ACTION:draft-ietf-sipping-transc-conf-00.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org --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 : The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model Author(s) : G. Camarillo Filename : draft-ietf-sipping-transc-conf-00.txt Pages : 10 Date : 2005-6-3 This document describes how to invoke transcoding services using the conference bridge model. This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing and speech-impaired individuals. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-transc-conf-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-transc-conf-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-transc-conf-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: <2005-6-3162900.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-transc-conf-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-transc-conf-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-3162900.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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-- From sipping-bounces@ietf.org Sat Jun 04 02:23:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeS4J-0004KI-0M; Sat, 04 Jun 2005 02:23:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeS4F-0004K3-AX for sipping@megatron.ietf.org; Sat, 04 Jun 2005 02:23:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08084 for ; Sat, 4 Jun 2005 02:23:34 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeSOc-0003vd-7a for sipping@ietf.org; Sat, 04 Jun 2005 02:44:39 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 04 Jun 2005 02:23:25 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j546NM4u024876; Sat, 4 Jun 2005 02:23:22 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 4 Jun 2005 02:23:21 -0400 Received: from [192.168.1.100] ([10.86.240.139]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 4 Jun 2005 02:23:21 -0400 Message-ID: <42A148D8.6020308@cisco.com> Date: Sat, 04 Jun 2005 02:23:20 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [Sipping] TISPAN References: <004f01c5614b$2a4d2ef0$6a01010a@keywest> <4295B117.40905@nokia.com> In-Reply-To: <4295B117.40905@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Jun 2005 06:23:21.0532 (UTC) FILETIME=[E7BB3FC0:01C568CD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: "Sipping \(E-mail\)" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org inline. Miguel Garcia wrote: >> You may want to clarify the context in which you expect these services >> to be >> used. Section 4 contains the sentence "The requirements in this document >> are intended to result in a mechanism with general applicability for >> the NGN >> TISPAN and NOT on the Internet.", which suggests that you are not >> expecting >> these services to be used anywhere SIP is now used. If that is so, >> why are >> you floating this proposal in front of the IETF? > > > Well, ETSI is defining those services for usage in the context of Next > Generation Networks that are built on top of the IP Multimedia Subsystem > (IMS). ETSI has strong requirements in terms of compability with the > PSTN and interoperability with IMS. I believe ETSI does not have any > problem if the Internet adopts the realization of these services, I > would actually be very happy if that situation arises. But you must be > aware that we are following an architectural model (the IMS) that > perhaps the general Internet does not want to exactly follow. > > All these factors make us think that the general Internet might not have > interest in this work.... but if it has, welcome, we are not precluding > usage. I think it is essential that we allow interoperability between "vanilla" SIP clients and ones on an IMS network. I don't see any reason why any call feature would be applicable only to IMS or NGN or TISPAN or whatever network. We have, to date, considered certain extensions not applicable to the Internet because they made assumptions about network topologies and provider relationships that were not generally applicable. Those are applicability limitations of a much different sort. As such, though I don't think the objective in IETF would be to standardize the way a service or feature has to work, if folks want to provide a feature and they think it requires an extension, we should go through the normal process of figuring out, here in sipping, whether or not that is a reasonable thing to do with SIP and how one might go about doing it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Sat Jun 04 05:24:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeUtT-0006KK-Fn; Sat, 04 Jun 2005 05:24:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeUtS-0006KF-04 for sipping@megatron.ietf.org; Sat, 04 Jun 2005 05:24:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18092 for ; Sat, 4 Jun 2005 05:24:35 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DeVDq-0007NO-1S for sipping@ietf.org; Sat, 04 Jun 2005 05:45:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Sipping] TISPAN Date: Sat, 4 Jun 2005 11:27:34 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BF0E@oefeg-s04.oefeg.loc> Thread-Topic: [Sipping] TISPAN Thread-Index: AcVozqNQmQx93Qa2TnWNy4EtKp5yRQAGEIKV From: "Stastny Richard" To: "Jonathan Rosenberg" , "Miguel Garcia" X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable Cc: "Sipping \(E-mail\)" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Well said, Jonathan! =20 > I think it is essential that we allow interoperability between = "vanilla" >SIP clients and ones on an IMS network. >I don't see any reason why any >call feature would be applicable only to IMS or NGN or TISPAN or >whatever network. =20 They do. The basic idea of TISPAN and 3GPP NGN IMS is to be in a walled garden and not in central park, becauae this is insecure and to be sure = of this=20 they want to be non-intereoperable. =20 regards Richard =20 ________________________________ Von: sipping-bounces@ietf.org im Auftrag von Jonathan Rosenberg Gesendet: Sa 04.06.2005 08:23 An: Miguel Garcia Cc: Sipping (E-mail) Betreff: Re: [Sipping] TISPAN inline. Miguel Garcia wrote: >> You may want to clarify the context in which you expect these = services >> to be >> used. Section 4 contains the sentence "The requirements in this = document >> are intended to result in a mechanism with general applicability for >> the NGN >> TISPAN and NOT on the Internet.", which suggests that you are not >> expecting >> these services to be used anywhere SIP is now used. If that is so, >> why are >> you floating this proposal in front of the IETF? > > > Well, ETSI is defining those services for usage in the context of Next > Generation Networks that are built on top of the IP Multimedia = Subsystem > (IMS). ETSI has strong requirements in terms of compability with the > PSTN and interoperability with IMS. I believe ETSI does not have any > problem if the Internet adopts the realization of these services, I > would actually be very happy if that situation arises. But you must be > aware that we are following an architectural model (the IMS) that > perhaps the general Internet does not want to exactly follow. > > All these factors make us think that the general Internet might not = have > interest in this work.... but if it has, welcome, we are not = precluding > usage. I think it is essential that we allow interoperability between "vanilla" SIP clients and ones on an IMS network. I don't see any reason why any call feature would be applicable only to IMS or NGN or TISPAN or whatever network. We have, to date, considered certain extensions not applicable to the Internet because they made assumptions about network topologies and provider relationships that were not generally applicable. Those are applicability limitations of a much different = sort. As such, though I don't think the objective in IETF would be to standardize the way a service or feature has to work, if folks want to provide a feature and they think it requires an extension, we should go through the normal process of figuring out, here in sipping, whether or not that is a reasonable thing to do with SIP and how one might go about doing it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Sat Jun 04 19:22:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dehy4-0002u4-SK; Sat, 04 Jun 2005 19:22:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dehy2-0002sd-MZ for sipping@megatron.ietf.org; Sat, 04 Jun 2005 19:22:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07464 for ; Sat, 4 Jun 2005 19:22:11 -0400 (EDT) Received: from 213-152-49-126.dsl.eclipse.net.uk ([213.152.49.126] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeiIY-00065V-V9 for sipping@ietf.org; Sat, 04 Jun 2005 19:43:27 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id 92AD86A615; Sun, 5 Jun 2005 00:21:14 +0100 (BST) In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613BF0E@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D4613BF0E@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3797f05c168d2a10b5dcf1d10712a0a4@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: AW: [Sipping] TISPAN Date: Sun, 5 Jun 2005 00:21:58 +0100 To: "Stastny Richard" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Content-Transfer-Encoding: 7bit Cc: Miguel Garcia , "Sipping \(E-mail\)" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Folks, Now now, Richard. With the tone of all of these reactions, why do I get a feeling of Deja Vu from 1996? The doc from ETSI TISPAN reflects their model of providing services, and their model of network interconnection. I share many folks discomfort at the overall idea of a mesh of walled gardens with tunnels between them. However ... if these fine folk want to use this model (and pay us all to build the fine Rococo kit it entails), then it is probably better that the stuff they do behind these closed walls is at least able to be decoded, if not fit for decent open (Internet) society. As they have been thinking this through for a while, it should come as no surprise to ETSI members that this mindset informs the text. You could argue that the same is true for docs written from an "IETF" perspective. Despite indications to the contrary, they *are* trying to get some specs out the door this side of the next millennium. It's hardly a shock that they have NOT spent their time developing a grand unified theory that is applicable anywhere, any time, by any box, using every possible conceptual frameworks on what things are and how they connect. (That's the job of "the SIP community" :) As Keith said, there may well be a need for intermediate nodes to ensure that "plain" SIP phones can engage in these services. This is why, I guess, they always talk about Session Border Controllers - as well as curing World Hunger, they act as the glue between the real world and the nether world. [It is left as an exercise for the student to decide which is which]. Jonathon is (as usual) precise in pointing out that this is going to require a set of detailed work items to be processed in SIPPING, before a set of work items can begin in SIP to deal with this. This is going to take a LONG time, and it is honest to spell this out at the start - there is zero chance of hitting the 2005 timeframe for a solution for all of these items through the IETF, IESG, RFC-ED, and IANA (for the realisation of these requirements). It did appear to many curmudgeons that 3GPP/3GPP2 "bounced" a lot of items into the IETF process with short deadlines "or the world would end". I, for one, appreciate the attempt by TISPAN folk to do the right thing and start the process early, rather than come out with a set of fully formed requirements set in stone that require blessing. Been there, seen it, done it - didn't like it. You may be correct in the comment that these strange places will end up being non-interoperable with the rest of the known universe - given the scope of the required work and the difference in mindsets, this many not be feasible in anything LIKE ETSI/ITU's planned timeframes. So what? We will end up with unspeakable acts going on, but it will go on behind closed walls, with closed pipes carrying the *** between them. However, that is going to make any attempt to provide an eventual solution/migration that permits interworking between the (some might say, sane) way of doing things on this side of the wall and the "country practices" that go on over there really ugly. Do we REALLY want that? all the best, Lawrence On 4 Jun 2005, at 10:27, Stastny Richard wrote: > Well said, Jonathan! > >> I think it is essential that we allow interoperability between >> "vanilla" >> SIP clients and ones on an IMS network. >> I don't see any reason why any >> call feature would be applicable only to IMS or NGN or TISPAN or >> whatever network. > > They do. The basic idea of TISPAN and 3GPP NGN IMS is to be in a walled > garden and not in central park, becauae this is insecure and to be > sure of this > they want to be non-intereoperable. > > regards > Richard > > > ________________________________ > > Von: sipping-bounces@ietf.org im Auftrag von Jonathan Rosenberg > Gesendet: Sa 04.06.2005 08:23 > An: Miguel Garcia > Cc: Sipping (E-mail) > Betreff: Re: [Sipping] TISPAN > > > > inline. > > Miguel Garcia wrote: > > >>> You may want to clarify the context in which you expect these >>> services >>> to be >>> used. Section 4 contains the sentence "The requirements in this >>> document >>> are intended to result in a mechanism with general applicability for >>> the NGN >>> TISPAN and NOT on the Internet.", which suggests that you are not >>> expecting >>> these services to be used anywhere SIP is now used. If that is so, >>> why are >>> you floating this proposal in front of the IETF? >> >> >> Well, ETSI is defining those services for usage in the context of Next >> Generation Networks that are built on top of the IP Multimedia >> Subsystem >> (IMS). ETSI has strong requirements in terms of compability with the >> PSTN and interoperability with IMS. I believe ETSI does not have any >> problem if the Internet adopts the realization of these services, I >> would actually be very happy if that situation arises. But you must be >> aware that we are following an architectural model (the IMS) that >> perhaps the general Internet does not want to exactly follow. >> >> All these factors make us think that the general Internet might not >> have >> interest in this work.... but if it has, welcome, we are not >> precluding >> usage. > > I think it is essential that we allow interoperability between > "vanilla" > SIP clients and ones on an IMS network. I don't see any reason why any > call feature would be applicable only to IMS or NGN or TISPAN or > whatever network. We have, to date, considered certain extensions not > applicable to the Internet because they made assumptions about network > topologies and provider relationships that were not generally > applicable. Those are applicability limitations of a much different > sort. > > As such, though I don't think the objective in IETF would be to > standardize the way a service or feature has to work, if folks want to > provide a feature and they think it requires an extension, we should go > through the normal process of figuring out, here in sipping, whether or > not that is a reasonable thing to do with SIP and how one might go > about > doing it. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > > --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Sun Jun 05 04:57:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeqwZ-00031z-Mi; Sun, 05 Jun 2005 04:57:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeqwY-00031t-Jp for sipping@megatron.ietf.org; Sun, 05 Jun 2005 04:57:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22669 for ; Sun, 5 Jun 2005 04:57:16 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DerH9-0002w1-Mi for sipping@ietf.org; Sun, 05 Jun 2005 05:18:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: AW: [Sipping] TISPAN Date: Sun, 5 Jun 2005 10:57:32 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BF18@oefeg-s04.oefeg.loc> Thread-Topic: AW: [Sipping] TISPAN Thread-Index: AcVpXKlkQ7AjyvCIRPGLA9SSIjIeLgAT/MHu From: "Stastny Richard" To: "lconroy" X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Content-Transfer-Encoding: quoted-printable Cc: Miguel Garcia , "Sipping \(E-mail\)" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Lawcence, of course I overdid it as usual, but incompatiblity does not mean you cannot interwork, you just need to have another box :-) a socalled IWU or GW or SBC+IWU eg SIP-Skype, or SIP SIP to IMS -SIP =20 Richard ________________________________ Von: lconroy [mailto:lconroy@insensate.co.uk] Gesendet: So 05.06.2005 01:21 An: Stastny Richard Cc: Jonathan Rosenberg; Sipping (E-mail); Miguel Garcia Betreff: Re: AW: [Sipping] TISPAN Folks, Now now, Richard. With the tone of all of these reactions, why do I get a feeling of Deja Vu from 1996? The doc from ETSI TISPAN reflects their model of providing services, and their model of network interconnection. I share many folks discomfort at the overall idea of a mesh of walled gardens with tunnels between them. However ... if these fine folk want to use this model (and pay us all to build the fine Rococo kit it entails), then it is probably better that the stuff they do behind these closed walls is at least able to be decoded, if not fit for decent open (Internet) society. As they have been thinking this through for a while, it should come as no surprise to ETSI members that this mindset informs the text. You could argue that the same is true for docs written from an "IETF" perspective. Despite indications to the contrary, they *are* trying to get some specs out the door this side of the next millennium. It's hardly a shock that they have NOT spent their time developing a grand unified theory that is applicable anywhere, any time, by any box, using every possible conceptual frameworks on what things are and how they connect. (That's the job of "the SIP community" :) As Keith said, there may well be a need for intermediate nodes to ensure that "plain" SIP phones can engage in these services. This is why, I guess, they always talk about Session Border Controllers - as well as curing World Hunger, they act as the glue between the real world and the nether world. [It is left as an exercise for the student to decide which is which]. Jonathon is (as usual) precise in pointing out that this is going to require a set of detailed work items to be processed in SIPPING, before a set of work items can begin in SIP to deal with this. This is going to take a LONG time, and it is honest to spell this out at the start - there is zero chance of hitting the 2005 timeframe for a solution for all of these items through the IETF, IESG, RFC-ED, and IANA (for the realisation of these requirements). It did appear to many curmudgeons that 3GPP/3GPP2 "bounced" a lot of items into the IETF process with short deadlines "or the world would end". I, for one, appreciate the attempt by TISPAN folk to do the right thing and start the process early, rather than come out with a set of fully formed requirements set in stone that require blessing. Been there, seen it, done it - didn't like it. You may be correct in the comment that these strange places will end up being non-interoperable with the rest of the known universe - given the scope of the required work and the difference in mindsets, this many not be feasible in anything LIKE ETSI/ITU's planned timeframes. So what? We will end up with unspeakable acts going on, but it will go on behind closed walls, with closed pipes carrying the *** between them. However, that is going to make any attempt to provide an eventual solution/migration that permits interworking between the (some might say, sane) way of doing things on this side of the wall and the "country practices" that go on over there really ugly. Do we REALLY want that? all the best, Lawrence On 4 Jun 2005, at 10:27, Stastny Richard wrote: > Well said, Jonathan! > >> I think it is essential that we allow interoperability between >> "vanilla" >> SIP clients and ones on an IMS network. >> I don't see any reason why any >> call feature would be applicable only to IMS or NGN or TISPAN or >> whatever network. > > They do. The basic idea of TISPAN and 3GPP NGN IMS is to be in a = walled > garden and not in central park, becauae this is insecure and to be > sure of this > they want to be non-intereoperable. > > regards > Richard > > > ________________________________ > > Von: sipping-bounces@ietf.org im Auftrag von Jonathan Rosenberg > Gesendet: Sa 04.06.2005 08:23 > An: Miguel Garcia > Cc: Sipping (E-mail) > Betreff: Re: [Sipping] TISPAN > > > > inline. > > Miguel Garcia wrote: > > >>> You may want to clarify the context in which you expect these >>> services >>> to be >>> used. Section 4 contains the sentence "The requirements in this >>> document >>> are intended to result in a mechanism with general applicability for >>> the NGN >>> TISPAN and NOT on the Internet.", which suggests that you are not >>> expecting >>> these services to be used anywhere SIP is now used. If that is so, >>> why are >>> you floating this proposal in front of the IETF? >> >> >> Well, ETSI is defining those services for usage in the context of = Next >> Generation Networks that are built on top of the IP Multimedia >> Subsystem >> (IMS). ETSI has strong requirements in terms of compability with the >> PSTN and interoperability with IMS. I believe ETSI does not have any >> problem if the Internet adopts the realization of these services, I >> would actually be very happy if that situation arises. But you must = be >> aware that we are following an architectural model (the IMS) that >> perhaps the general Internet does not want to exactly follow. >> >> All these factors make us think that the general Internet might not >> have >> interest in this work.... but if it has, welcome, we are not >> precluding >> usage. > > I think it is essential that we allow interoperability between > "vanilla" > SIP clients and ones on an IMS network. I don't see any reason why any > call feature would be applicable only to IMS or NGN or TISPAN or > whatever network. We have, to date, considered certain extensions not > applicable to the Internet because they made assumptions about network > topologies and provider relationships that were not generally > applicable. Those are applicability limitations of a much different > sort. > > As such, though I don't think the objective in IETF would be to > standardize the way a service or feature has to work, if folks want to > provide a feature and they think it requires an extension, we should = go > through the normal process of figuring out, here in sipping, whether = or > not that is a reasonable thing to do with SIP and how one might go > about > doing it. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > > --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Sun Jun 05 12:20:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dexqz-00071E-Ua; Sun, 05 Jun 2005 12:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dexqy-000715-O4 for sipping@megatron.ietf.org; Sun, 05 Jun 2005 12:20:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16434 for ; Sun, 5 Jun 2005 12:19:58 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeyBe-0002Hu-N3 for sipping@ietf.org; Sun, 05 Jun 2005 12:41:22 -0400 Received: by wproxy.gmail.com with SMTP id 58so2366390wri for ; Sun, 05 Jun 2005 09:19:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Bmm9PyJ9rhF7IV60Ui2+Bhfrdcsoy4ebYF/g2U0cOtdY3L/+ErQ7pswFTRtX33pQQE54z4A9HsuSaStd0TOehkGtBwR52nrBEAYGOtDuaQZbk8SJdOZSeutNn5YGQHVQbmbJ8QlP9EjXvRUhN2R2E2H/pG851rjpnJhkpTN9pEM= Received: by 10.54.79.13 with SMTP id c13mr2687664wrb; Sun, 05 Jun 2005 09:19:51 -0700 (PDT) Received: by 10.54.79.1 with HTTP; Sun, 5 Jun 2005 09:19:51 -0700 (PDT) Message-ID: <953beacc05060509191b81a0a0@mail.gmail.com> Date: Sun, 5 Jun 2005 09:19:51 -0700 From: Rohan Mahy To: Brett Tate Subject: Re: [Sipping] identity within draft-ietf-sipping-dialog-package-06 In-Reply-To: <005e01c56611$7fd638b0$2c28a8c0@brett1> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <000501c562cc$f65ae690$2c28a8c0@brett1> <005e01c56611$7fd638b0$2c28a8c0@brett1> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: rohan@ekabal.com, schulzrinne@cs.columbia.edu, sipping-ietf X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rohan Mahy List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Brett, I can address this during AUTH 48. thx, -r On 5/31/05, Brett Tate wrote: > Hello Jonathan, Henning, and Rohan, >=20 > Concerning the dialog package, are multiple > identities allowed for a participant? >=20 > If I correctly understand the xml schema > presented within section 4.4 > of draft-ietf-sipping-dialog-package-06, it > does not allow for multiple identities for > a participant. >=20 > This contradicts section 4.1.6.1: > " Note that multiple identities (for example > a sip: URI and a tel: URI) could be included > if they all correspond to the participant." >=20 > I assume that the xml should be changed > to match section 4.1.6.1. This would more > accurately correspond to RFC 3325. >=20 >=20 > Thanks for a response, > Brett Tate >=20 >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Sun Jun 05 12:38:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dey8q-0000QI-84; Sun, 05 Jun 2005 12:38:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dey8o-0000QD-ST for sipping@megatron.ietf.org; Sun, 05 Jun 2005 12:38:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17447 for ; Sun, 5 Jun 2005 12:38:24 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.207]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeyTT-0002ef-W1 for sipping@ietf.org; Sun, 05 Jun 2005 12:59:49 -0400 Received: by wproxy.gmail.com with SMTP id 58so2369961wri for ; Sun, 05 Jun 2005 09:38:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rJVj7jEJEP10MSKnkG+sPAWP23e2jUmhK9LG8YhBV4FNRdOzZAIPtZpAlXEmp/Biaeu2Rc/lNhWRfxYU+SVYtDVgF/ULWoO0YLuAEqB3rdIkJdh9nZNdo/leGC/E+giLMCZB4F0xNvo3e0oQNqoUt8mmz9mTsFIyyzrltbTStWk= Received: by 10.54.45.7 with SMTP id s7mr2153818wrs; Sun, 05 Jun 2005 09:38:16 -0700 (PDT) Received: by 10.54.79.1 with HTTP; Sun, 5 Jun 2005 09:38:16 -0700 (PDT) Message-ID: <953beacc050605093814f28cd@mail.gmail.com> Date: Sun, 5 Jun 2005 09:38:16 -0700 From: Rohan Mahy To: Aki Niemi Subject: Re: [Sipping] Question and comments on sipping-certs In-Reply-To: <427F6D6E.5010503@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <427F6D6E.5010503@nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rohan Mahy List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Hi Aki, I was actually responsible for the ETag addition, so I will respond to that point. As a certificate is about to expire, there is a race condition where two instances could generate a new certificate and PUBLISH them at roughly the same time. Since a potentially large number of folks could be subscribed to the cert package, many of them would get two notifications in rapid succession with the "first" and then the "second" certificate. This is undesirable for traffic engineering reasons, but the biggest problem is that this makes it harder for all my instances to get teh same credentials and all of my peers to get the corresponding (same) certificate. (It significantly increases the chance that one of my UAs will get a request encrypted with the wrong certificate.) This problem is easily prevented if the credential publication relies on a specific ETag. The "second" publication will fail, and the second instance will wait to get the new credential in a NOTIFY (which has probably been sent already). Subscribers to the cert package get only one notification with the "first" new certificate. Life is good. This is explained is Section 5. Would it help to add a new subsection to Section 8 on subscriber publication? btw: subscription and publication expirations are orthogonal to the lifetime/validity of the certificate. I think there is some text to that effect, but it sounds like that point could be called out more. thanks, -rohan On 5/9/05, Aki Niemi wrote: > Hi, >=20 > Reading sipping-certs-01, I wasn't quite sure how the publication of > credentials is supposed to work. More specifically, the usage of etags > to make sure UAs for the same AOR don't end up publishing conflicting > credentials seems unnecessary. >=20 > Since there is only one set of credentials for an AoR, and each new > publication automatically overwrites any existing credentials (and an > empty body deletes them), then this can happen regardless of whether the > etag is shared among the wathcers or not. So why does the NOTIFY carry > the etag value? >=20 > Also, is the expiration of a publish in any way related to the lifetime > of the certificate? >=20 > For what purpose is the Content-Disposition set to "signal" in > credential publication? Where is "signal" defined? >=20 > Third paragraph in chapter 8.5, 3rd sentence should be removed. >=20 > That's all for now! >=20 > Cheers, > Aki >=20 >=20 >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Mon Jun 06 01:31:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfACe-0000ob-8P; Mon, 06 Jun 2005 01:31:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddsx5-0007Z4-ET for sipping@megatron.ietf.org; Thu, 02 Jun 2005 12:53:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06614 for ; Thu, 2 Jun 2005 12:53:48 -0400 (EDT) Received: from [69.30.42.70] (helo=smtp.elevennetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdtH8-0000V1-4k for sipping@ietf.org; Thu, 02 Jun 2005 13:14:35 -0400 Received: from [66.147.188.214] (helo=Yariv) by smtp.elevennetworks.com with esmtp (Exim 4.44) id 1Ddswr-0006F0-DW; Thu, 02 Jun 2005 09:53:39 -0700 From: "David Schwartz" To: Date: Thu, 2 Jun 2005 16:55:22 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 06 Jun 2005 01:31:10 -0400 Cc: Subject: [Sipping] SPIT Security initiative X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: david@kayote.com List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org I wanted to bring to the attention of the SIP community an initiative Kayote has been working on to combat the ever-growing threat of SPIT. Essentially, we have adopted Jon Peterson's idea of embedding security information into the SIP message via SAML . This will give upstream elements the ability to make available to downstream elements what they know about the SPIT threat potential on a call-by-call basis and let the downstream elements decide what to do with that information. The data sent downstream takes the form of name=value pairs and each parameter highlights a specific "red flag" in terms of potential for SPIT. For example, is the user calling from a free service, or is he a paying customer. Does his ITSP authorize as well as assert identity? Is there some other reason to suspect the call to be SPIT (from information regarding his calling patterns)? And finally, an overall score that we subjectively assign, called the AssertionStrength. This work is very preliminary and we expect the list of security attributes to evolve, but the key is the method of communicating the information on a call by call basis. As we describe in the open issues section, there are still a lot of SIP related things that need to get ironed out. We are making a public server available for developers to start playing with. SIP messages can be bounced off the server and they will be returned with the embedded SAML containing the security attributes of the caller. On the web site, developers can configure their variables and other options. Our hope is that we can create a dynamic ongoing discussion that will engage the firewall and SBC vendors, the IP-PBX and Proxy builders, and even the CPE people, to get them to key off this information and reject/allow/filter/divert calls accordingly. We put up a small client to show the basic functionality. The technical details are provided in an accompanying document. The client and document can both be found at www.spitprevention.net Once you sign in, you can download the client and the doc (http://www.spitprevention.net/downloads/SPITPrevention.pdf). Depending on feedback from the community, future direction may include a standardization track. Kayote welcomes any comments that you have and looks forward to working on this project with the developer community. Best regards, David Schwartz Kayote Networks david.Schwartz@kayote.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 sipping-bounces@ietf.org Mon Jun 06 08:02:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfGJB-0000jG-HY; Mon, 06 Jun 2005 08:02:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfGJ7-0000iV-MD for sipping@megatron.ietf.org; Mon, 06 Jun 2005 08:02:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23012 for ; Mon, 6 Jun 2005 08:02:16 -0400 (EDT) Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfGdw-0007QG-Ti for sipping@ietf.org; Mon, 06 Jun 2005 08:23:50 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j56BxwpT021264; Mon, 6 Jun 2005 15:00:00 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Jun 2005 15:02:10 +0300 Received: from [127.0.0.1] ([10.162.19.90]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 6 Jun 2005 14:55:11 +0300 Message-ID: <42A3F9C4.4090403@nokia.com> Date: Mon, 06 Jun 2005 10:22:44 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Stastny Richard Subject: Re: AW: [Sipping] TISPAN References: <32755D354E6B65498C3BD9FD496C7D4613BF0E@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613BF0E@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jun 2005 11:55:11.0274 (UTC) FILETIME=[97B048A0:01C56A8E] X-Spam-Score: 0.7 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: "Sipping \(E-mail\)" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Inline comments. Stastny Richard wrote: > Well said, Jonathan! > > >>I think it is essential that we allow interoperability between "vanilla" >>SIP clients and ones on an IMS network. >>I don't see any reason why any >>call feature would be applicable only to IMS or NGN or TISPAN or >>whatever network. > > > They do. The basic idea of TISPAN and 3GPP NGN IMS is to be in a walled > garden and not in central park, becauae this is insecure and to be sure of this > they want to be non-intereoperable. > Richard: I cannot disagree more with your words. I am trying to recall from my memory one single point where a vanilla SIP client couldn't interoperate with a SIP client connected to the IMS or to an NGN network, and honestly speaking, I can't recall any. The only thing that comes to my memory was that, at some point in time, 3GPP required all the sessions to use preconditions, so interoperability with those vanilla SIP clients that did not implement preconditions wasn't possible. This limitation was relaxed in the Release 6 of the 3GPP specifications, so once more, I don't recall any point of non interoperability. /Miguel > regards > Richard > > -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Mon Jun 06 08:02:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfGJS-0000lM-75; Mon, 06 Jun 2005 08:02:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfGJQ-0000lE-Ng for sipping@megatron.ietf.org; Mon, 06 Jun 2005 08:02:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23045 for ; Mon, 6 Jun 2005 08:02:35 -0400 (EDT) Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfGeG-0007RA-ST for sipping@ietf.org; Mon, 06 Jun 2005 08:24:09 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j56C2Ppp017738; Mon, 6 Jun 2005 15:02:33 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Jun 2005 15:02:26 +0300 Received: from [172.21.38.162] ([172.21.38.162]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 6 Jun 2005 14:57:28 +0300 Message-ID: <42A43A26.70007@nokia.com> Date: Mon, 06 Jun 2005 14:57:26 +0300 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Sipping] Question and comments on sipping-certs References: <427F6D6E.5010503@nokia.com> <953beacc050605093814f28cd@mail.gmail.com> In-Reply-To: <953beacc050605093814f28cd@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jun 2005 11:57:28.0110 (UTC) FILETIME=[E93FCCE0:01C56A8E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Hi Rohan, Thanks for the reply. Inline. ext Rohan Mahy wrote: > Hi Aki, > > I was actually responsible for the ETag addition, so I will respond to > that point. > > As a certificate is about to expire, there is a race condition where > two instances could generate a new certificate and PUBLISH them at > roughly the same time. Since a potentially large number of folks > could be subscribed to the cert package, many of them would get two > notifications in rapid succession with the "first" and then the > "second" certificate. This is undesirable for traffic engineering > reasons, but the biggest problem is that this makes it harder for all > my instances to get teh same credentials and all of my peers to get > the corresponding (same) certificate. (It significantly increases the > chance that one of my UAs will get a request encrypted with the wrong > certificate.) > > This problem is easily prevented if the credential publication relies > on a specific ETag. The "second" publication will fail, and the > second instance will wait to get the new credential in a NOTIFY (which > has probably been sent already). Subscribers to the cert package get > only one notification with the "first" new certificate. Life is good. You'd be able to prevent this race condition simply by specifying that when a client decides to generate fresh credentials, it wouldn't simply do at n minutes before expiration, but rather n + random minutes before the cert expires. The reason I was asking is that without having to carry etags out to the subscribers, you could both manually install credentials (e.g., scp them to your $HOME/.cert or equivalent) and even when using the PUBLISH method, write to disk without having to keep any metadata whatsoever around for the credentials. > This is explained is Section 5. Would it help to add a new subsection > to Section 8 on subscriber publication? > > btw: subscription and publication expirations are orthogonal to the > lifetime/validity of the certificate. I think there is some text to > that effect, but it sounds like that point could be called out more. That point was clear for the subscriptions (and well understood), but for publications it wasn't very clear. And the implication of course is that effectively the publication is hard state. And that's fine by me (again less metadata to keep around), just making sure. Cheers, Aki > thanks, > -rohan > > > > > On 5/9/05, Aki Niemi wrote: > >>Hi, >> >>Reading sipping-certs-01, I wasn't quite sure how the publication of >>credentials is supposed to work. More specifically, the usage of etags >>to make sure UAs for the same AOR don't end up publishing conflicting >>credentials seems unnecessary. >> >>Since there is only one set of credentials for an AoR, and each new >>publication automatically overwrites any existing credentials (and an >>empty body deletes them), then this can happen regardless of whether the >>etag is shared among the wathcers or not. So why does the NOTIFY carry >>the etag value? >> >>Also, is the expiration of a publish in any way related to the lifetime >>of the certificate? >> >>For what purpose is the Content-Disposition set to "signal" in >>credential publication? Where is "signal" defined? >> >>Third paragraph in chapter 8.5, 3rd sentence should be removed. >> >>That's all for now! >> >>Cheers, >>Aki >> >> >> >> >>_______________________________________________ >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>This list is for NEW development of the application of SIP >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sip@ietf.org for new developments of core SIP >> > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Mon Jun 06 08:55:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfH8l-0005wQ-QZ; Mon, 06 Jun 2005 08:55:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfH8h-0005vQ-2W for sipping@megatron.ietf.org; Mon, 06 Jun 2005 08:55:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27308 for ; Mon, 6 Jun 2005 08:55:33 -0400 (EDT) Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfHTW-0000Bx-K4 for sipping@ietf.org; Mon, 06 Jun 2005 09:17:08 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id j56CtJ5h106154 for ; Mon, 6 Jun 2005 12:55:19 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j56CtIDB178770 for ; Mon, 6 Jun 2005 14:55:19 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j56CtHSi025332 for ; Mon, 6 Jun 2005 14:55:17 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j56CtEqx025309 for ; Mon, 6 Jun 2005 14:55:14 +0200 To: sipping@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04112005NP April 11, 2005 Message-ID: From: Avshalom Houri Date: Mon, 6 Jun 2005 15:55:14 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(V70_M4_01112005 Sidepack 2802|March 1, 2005) at 06/06/2005 15:55:14, Serialize complete at 06/06/2005 15:55:14 X-Spam-Score: 2.0 (++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [Sipping] Modifying subscribed URI list X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1477470719==" Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org --===============1477470719== Content-Type: text/html; charset="US-ASCII"
Draft draft-ietf-sipping-uri-list-subscribe-03.txt enables subscribing to a list of users.
In many cases the list of users changes quite fast and sending the whole modified list again may be quite heavy.

I think that it will be quite helpful to add very simple add/remove operators to the URI list of subscribe in order to
enable fast change of the URI list.

For example if the initial body of the subscribe was:


   <?xml version="1.0" encoding="UTF-8"?>
   <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
                  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
     <list>
       <entry uri="sip:bill@example.com" />
       <entry uri="sip:joe@example.org" />
       <entry uri="sip:ted@example.net" />
     </list>
   </resource-lists>

If we want to add Alice and remove Bill the resubscribe will look like (more or less):

   <?xml version="1.0" encoding="UTF-8"?>
   <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
                  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
     <list>
       <<REM> entry uri="sip:bill@example.com" />
       <<ADD> entry uri="sip:alice@example.org" />
     </list>
   </resource-lists>

Avshalom
--===============1477470719== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============1477470719==-- From sipping-bounces@ietf.org Mon Jun 06 09:54:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfI3V-0003cl-Nj; Mon, 06 Jun 2005 09:54:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfI3T-0003cg-77 for sipping@megatron.ietf.org; Mon, 06 Jun 2005 09:54:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01432 for ; Mon, 6 Jun 2005 09:54:13 -0400 (EDT) Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfIOK-0001Kj-D5 for sipping@ietf.org; Mon, 06 Jun 2005 10:15:48 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j56DsAG2013380; Mon, 6 Jun 2005 16:54:11 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Jun 2005 16:54:11 +0300 Received: from [127.0.0.1] ([10.162.19.90]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 6 Jun 2005 14:55:10 +0300 Message-ID: <42A3F859.9080307@nokia.com> Date: Mon, 06 Jun 2005 10:16:41 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sipping] TISPAN References: <004f01c5614b$2a4d2ef0$6a01010a@keywest> <4295B117.40905@nokia.com> <42A148D8.6020308@cisco.com> In-Reply-To: <42A148D8.6020308@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jun 2005 11:55:10.0321 (UTC) FILETIME=[971EDE10:01C56A8E] X-Spam-Score: 0.7 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: "Sipping \(E-mail\)" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Jonathan Rosenberg wrote: > I think it is essential that we allow interoperability between "vanilla" > SIP clients and ones on an IMS network. This is provided. The SIP, SDP and RTP that you can see hitting a vanilla SIP client is standard SIP, SDP, and RTP that is defined in a number of standard track RFCs. So I don't see there is an issue here. > I don't see any reason why any > call feature would be applicable only to IMS or NGN or TISPAN or > whatever network. Well, there are some extensions that assume an underlying architecture or even a business model. Sometimes the architecture of business model is not applicable to the Internet as a general. Take for example the Advice of Charge service. This service assumes that an operator is charging users on a service by service basis (and here by service I mean a general service, such as the establishment of a multimedia session). Well, you may agree or not with the business model, which I would prefer not comment here, but there is a bunch of people who want to apply it. And when applying that business model, the Advice of Charge service makes sense. I believe our responsibility in the IETF is to provide the toolkit for those who want to apply those architectures and business models. On doing so we may find that one or more ideas might be generally applicable to the Internet (such as the case of the OMA PoC Answer Mode), in which case we should do the same sort of things as we did with the P-Answer-Mode header (I mean, make it a standard track header). >We have, to date, considered certain extensions not > applicable to the Internet because they made assumptions about network > topologies and provider relationships that were not generally > applicable. Those are applicability limitations of a much different sort. > > As such, though I don't think the objective in IETF would be to > standardize the way a service or feature has to work, if folks want to > provide a feature and they think it requires an extension, we should go > through the normal process of figuring out, here in sipping, whether or > not that is a reasonable thing to do with SIP and how one might go about > doing it. I agree with you, as far as I know it has never been the goal of the IETF to standardize servivces, but features that enable services. We need to preserve this goal, and I will take it into account for further work. > > -Jonathan R. > /Miguel -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Mon Jun 06 10:03:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfIC7-0004lK-3H; Mon, 06 Jun 2005 10:03:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfIC5-0004k8-I0 for sipping@megatron.ietf.org; Mon, 06 Jun 2005 10:03:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02158 for ; Mon, 6 Jun 2005 10:03:07 -0400 (EDT) Received: from broadsoft.com ([204.200.197.133]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfIWv-0001XJ-Pl for sipping@ietf.org; Mon, 06 Jun 2005 10:24:43 -0400 Received: from brett1 (66.239.146.130.ptr.us.xo.net [66.239.146.130]) (authenticated bits=0) by broadsoft.com (8.13.1/8.12.11) with ESMTP id j56E2rZf084386; Mon, 6 Jun 2005 10:02:58 -0400 (EDT) From: "Brett Tate" To: "'Rohan Mahy'" Subject: RE: [Sipping] identity within draft-ietf-sipping-dialog-package-06 Date: Mon, 6 Jun 2005 10:05:43 -0400 Message-ID: <000501c56aa0$d6252f80$2c28a8c0@brett1> 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.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <953beacc05060509191b81a0a0@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: rohan@ekabal.com, 'sipping-ietf' X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Rohan, Thanks for the response. Unfortunately I need more clarity about the intended resolution. Within the dialog package, are multiple identities allowed for a participant? -brett > -----Original Message----- > From: sipping-bounces@ietf.org > [mailto:sipping-bounces@ietf.org] On Behalf Of Rohan Mahy > Sent: Sunday, June 05, 2005 12:20 PM > To: Brett Tate > Cc: rohan@ekabal.com; schulzrinne@cs.columbia.edu; sipping-ietf > Subject: Re: [Sipping] identity within > draft-ietf-sipping-dialog-package-06 > > > Brett, > > I can address this during AUTH 48. > > thx, > -r > > On 5/31/05, Brett Tate wrote: > > Hello Jonathan, Henning, and Rohan, > > > > Concerning the dialog package, are multiple > > identities allowed for a participant? > > > > If I correctly understand the xml schema > > presented within section 4.4 > > of draft-ietf-sipping-dialog-package-06, it > > does not allow for multiple identities for > > a participant. > > > > This contradicts section 4.1.6.1: > > " Note that multiple identities (for example > > a sip: URI and a tel: URI) could be included > > if they all correspond to the participant." > > > > I assume that the xml should be changed > > to match section 4.1.6.1. This would more > > accurately correspond to RFC 3325. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Mon Jun 06 10:13:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfILH-0006P9-Qk; Mon, 06 Jun 2005 10:12:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfILF-0006OU-As; Mon, 06 Jun 2005 10:12:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03709; Mon, 6 Jun 2005 10:12:34 -0400 (EDT) From: Mpierce1@aol.com Received: from imo-m27.mx.aol.com ([64.12.137.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfIg4-0001of-Kt; Mon, 06 Jun 2005 10:34:10 -0400 Received: from Mpierce1@aol.com by imo-m27.mx.aol.com (mail_out_v38_r1.7.) id c.7a.74d87318 (4214); Mon, 6 Jun 2005 10:12:17 -0400 (EDT) Message-ID: <7a.74d87318.2fd5b3c1@aol.com> Date: Mon, 6 Jun 2005 10:12:17 EDT Subject: Re: [Sipping] Re: [Sip] Comments on Last Call of "Extending Reason-header for... To: jmpolk@cisco.com, iesg@ietf.org, sip@ietf.org, sipping@ietf.org MIME-Version: 1.0 X-Mailer: 7.0 for Windows sub 10689 X-Spam-Score: 0.7 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0238429857==" Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org --===============0238429857== Content-Type: multipart/alternative; boundary="part1_7a.74d87318.2fd5b3c1_boundary" --part1_7a.74d87318.2fd5b3c1_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 6/2/2005 6:10:09 PM Eastern Daylight Time, jmpolk@cisco.com writes: > Because SIP and Q.850 have clearly defined meanings for their cause > numbers, and this extension does not, I believe the text string should be > maintained through IANA. > > From an IANA point of view, at > http://www.iana.org/assignments/sip-parameters you can see the text string > for each 1XX, 2XX, 3XX, 4XX, 5XX and 6XX response code that would be used > if the SIP protocol were used in a 3326 Reason header. As IANA is where to > first look up these things, I'm not sure why you have an issue with IANA > having the same text string explaining what each cause is in the Preemption > protocol of the Reason header. If the text string were removed in the IANA > registration, there would be no clue there what each cause number meant. > > This is not the case right now at > http://www.iana.org/assignments/sip-parameters for all other SIP parameters. > > I believe one of your concerns is the user learning/reading the reason in > the Reason header within your domain, and I believe that is a local > configuration decision. > > In the document, I do not believe I ever made it a MUST, SHOULD, > RECOMMENDED or even a MAY be presented to the user of the UA who is being > preempted. I believe this is up to the implementation and local policy to > show, or not to show. > I guess I didn't explain my concern well enough. It isn't the issue of notifying the user of something they shouldn't know in our domain. The "Generic Preemption" was added to deal with this. I have no problem with the (default) text string being registered with IANA for each defined preemption cause as was done for each SIP response code. The concern is that the IANA considerations section does not make it clear that this is what IANA is expected to do. I don't understand why this is called the "default" text. It would seem that any device could put in any text string it wanted, for example, the same thing in another langauage. I believe RFC 3261 is rather vague on this issue. While the ABNF requires that a Reason-phrase be included in every message and it provides "default" text for each and includes it in the IANA registration, I don't believe it requires that this exact text string be used. My comment is mostly that there appears to be a conflict between the text in this draft and the formal syntax definition in RFC 3326. I don't know which is correct. It would seem to me that, if this new preemption cause is used, that the numeric cause value is mandatory and the text string is optional. Neither RFC 3326 nor this draft says that. The formal definition in RFC 3326 says both are optional. This draft indicates that both are required. Mike Pierce --part1_7a.74d87318.2fd5b3c1_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a me= ssage dated 6/2/2005 6:10:09 PM Eastern Daylight Time, jmpolk@cisco.com writ= es:


Because SIP and Q.850 have clea= rly defined meanings for their cause
numbers, and this extension does not, I believe the text string should be maintained through IANA.

>From an IANA point of view, at
http://www.iana.org/assignments/sip-parameters you can see the text string <= BR> for each 1XX, 2XX, 3XX, 4XX, 5XX and 6XX response code that would be used if the SIP protocol were used in a 3326 Reason header. As IANA is where to <= BR> first look up these things, I'm not sure why you have an issue with IANA having the same text string explaining what each cause is in the Preemption=20=
protocol of the Reason header. If the text string were removed in the IANA <= BR> registration, there would be no clue there what each cause number meant.

This is not the case right now at
http://www.iana.org/assignments/sip-parameters for all other SIP parameters.=

I believe one of your concerns is the user learning/reading the reason in the Reason header within your domain, and I believe that is a local
configuration decision.

In the document, I do not believe I ever made it a MUST, SHOULD,
RECOMMENDED or even a MAY be presented to the user of the UA who is being preempted. I believe this is up to the implementation and local policy to show, or not to show.



I guess I didn't explain my concern well enough. It isn't the issue of notif= ying the user of something they shouldn't know in our domain. The "Generic P= reemption" was added to deal with this.

I have no problem with the (default) text string being registered with IANA=20= for each defined preemption cause as was done for each SIP response code. Th= e concern is that the IANA considerations section does not make it clear tha= t this is what IANA is expected to do.

I don't understand why this is called the "default" text. It would seem that= any device could put in any text string it wanted, for example, the same th= ing in another langauage. I believe RFC 3261 is rather vague on this issue.=20= While the ABNF requires that a Reason-phrase be included in every message an= d it provides "default" text for each and includes it in the IANA registrati= on, I don't believe it requires that this exact text string be used.

My comment is mostly that there appears to be a conflict between the text in= this draft and the formal syntax definition in RFC 3326. I don't know which= is correct. It would seem to me that, if this new preemption cause is used,= that the numeric cause value is mandatory and the text string is optional.=20= Neither RFC 3326 nor this draft says that. The formal definition in RFC 3326= says both are optional. This draft indicates that both are required.


Mike Pierce
 --part1_7a.74d87318.2fd5b3c1_boundary-- --===============0238429857== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============0238429857==-- From sipping-bounces@ietf.org Mon Jun 06 11:45:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfJnU-00034K-1f; Mon, 06 Jun 2005 11:45:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfJnS-00034F-EX for sipping@megatron.ietf.org; Mon, 06 Jun 2005 11:45:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11831 for ; Mon, 6 Jun 2005 11:45:48 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DfK8I-0003y8-Jm for sipping@ietf.org; Mon, 06 Jun 2005 12:07:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Sipping] TISPAN Date: Mon, 6 Jun 2005 17:48:44 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BF23@oefeg-s04.oefeg.loc> Thread-Topic: [Sipping] TISPAN Thread-Index: AcVqkAp/t8rz0Ko/R7i3YZms7k8digAHm53K From: "Stastny Richard" To: "Miguel Garcia" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Cc: "Sipping \(E-mail\)" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org >so once more, I >don't recall any point of non interoperability. Nice to hear. I just wonder for what reason GSM-A required for their ENUM = implementation in GRX e164.3gppnetwork.org (or whatever it will be) to have an = additional special enumservice (either SIP+IMS or SIP:IMS) to distingiush between IMS SIP and vanilla SIP? If what you said is true, they do not need this regards Richard ________________________________ Von: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] Gesendet: Mo 06.06.2005 09:22 An: Stastny Richard Cc: Jonathan Rosenberg; Sipping (E-mail) Betreff: Re: AW: [Sipping] TISPAN Inline comments. Stastny Richard wrote: > Well said, Jonathan! >=20 > >>I think it is essential that we allow interoperability between = "vanilla" >>SIP clients and ones on an IMS network. >>I don't see any reason why any >>call feature would be applicable only to IMS or NGN or TISPAN or >>whatever network. > >=20 > They do. The basic idea of TISPAN and 3GPP NGN IMS is to be in a = walled > garden and not in central park, becauae this is insecure and to be = sure of this > they want to be non-intereoperable. >=20 Richard: I cannot disagree more with your words. I am trying to recall from my memory one single point where a vanilla SIP client couldn't interoperate with a SIP client connected to the IMS or to an NGN network, and honestly speaking, I can't recall any. The only thing that comes to my memory was that, at some point in time, 3GPP required all the sessions to use preconditions, so interoperability with those vanilla SIP clients that did not implement preconditions wasn't possible. This limitation was relaxed in the Release 6 of the 3GPP specifications, so once more, I don't recall any point of non interoperability. /Miguel > regards > Richard >=20 > -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Mon Jun 06 12:36:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfKa9-0000vE-UK; Mon, 06 Jun 2005 12:36:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfKa8-0000ux-AN; Mon, 06 Jun 2005 12:36:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15365; Mon, 6 Jun 2005 12:36:03 -0400 (EDT) Received: from mail1.audiocodes.com ([212.25.125.19] helo=imss.audiocodes.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfKuy-00051s-51; Mon, 06 Jun 2005 12:57:41 -0400 Received: from aclmsg.corp.audiocodes.com ([10.1.0.8]) by imss with InterScan Messaging Security Suite; Mon, 06 Jun 2005 19:37:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] I-D ACTION:draft-ietf-sipping-transc-conf-00.txt Date: Mon, 6 Jun 2005 19:36:29 +0300 Message-ID: <79B4F738DDD4EF4F85A4641A0FE5EFD6FD9A08@aclmsg.corp.audiocodes.com> Thread-Topic: [Sipping] I-D ACTION:draft-ietf-sipping-transc-conf-00.txt Thread-Index: AcVoePlPulD7jtWuTfWvo2dfM82kCwCONikQ From: "Nachum Frid" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org I suggest to mention in the draft that there are several ways to make the two party conference, and not only according to "draft-ietf-sipping-uri-list-conferencing-02" . The basic two party conference (that can be used to invoke transcoding service) can be established by sending two INVITEs to conference server with same conference URI as described in "draft-ietf-sipping-conferencing-framework-05", "draft-burger-sipping-netann-11" and in "draft-ietf-sipping-cc-conferencing-06" par 4.1 (Dial in conference). =20 Nachum AudioCodes -----Original Message----- From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Friday, June 03, 2005 10:56 PM To: i-d-announce@ietf.org Cc: sipping@ietf.org Subject: [Sipping] I-D ACTION:draft-ietf-sipping-transc-conf-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : The Session Initiation Protocol (SIP) Conference=20 Bridge Transcoding Model Author(s) : G. Camarillo Filename : draft-ietf-sipping-transc-conf-00.txt Pages : 10 Date : 2005-6-3 =09 This document describes how to invoke transcoding services using the conference bridge model. This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing and speech-impaired individuals. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-transc-conf-00.tx t _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Mon Jun 06 13:27:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfLNc-0006mB-HF; Mon, 06 Jun 2005 13:27:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfLNa-0006m6-HU for sipping@megatron.ietf.org; Mon, 06 Jun 2005 13:27:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19742 for ; Mon, 6 Jun 2005 13:27:11 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfLiS-0006HX-NI for sipping@ietf.org; Mon, 06 Jun 2005 13:48:49 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id 31FD26C017 for ; Mon, 6 Jun 2005 13:27:12 -0400 (EDT) From: "Dale Worley" To: "'Sipping (E-mail)'" Subject: RE: [Sipping] TISPAN Date: Mon, 6 Jun 2005 13:26:15 -0400 Message-ID: <009e01c56abc$d878abb0$6a01010a@keywest> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613BF23@oefeg-s04.oefeg.loc> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org I'm starting to lose my grip on what we're trying to accomplish here. As far as I can tell, ETSI is going ahead with defining extensions to SIP to support features that network operators want. At least initially, these would be used entirely within their proprietary networks. And they want to get them defined quickly. But it would nonetheless be good for them if they got some input from the IETF, both for good system design, and to improve interoperability over the long term, if not the short term. Obviously, ETSI is less interested in commentary on their requirements than on their mechanisms. But without fairly detailed information about their requirements, it's hard to make intelligent comments on the mechanisms. To that end, I thing it would be a big improvment to revise their document to include discussion of the feature requirements. Currently, they only refer to various telco documents, but I've only been able to find pointers to paper copies at significant prices (200+ euros). It isn't going to generate much commentary if one has to pay over 1000 euros to discover what the *requirements* are. Dale _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Mon Jun 06 13:39:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfLZt-0008AD-69; Mon, 06 Jun 2005 13:39:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfLZs-0008A8-2y for sipping@megatron.ietf.org; Mon, 06 Jun 2005 13:39:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20864 for ; Mon, 6 Jun 2005 13:39:55 -0400 (EDT) Received: from isozyme58.gprs.dnafinland.fi ([62.78.107.58] helo=rautu.tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfLug-0006dN-DR for sipping@ietf.org; Mon, 06 Jun 2005 14:01:31 -0400 Received: from rautu.tutpro.com (jh@localhost [127.0.0.1]) by rautu.tutpro.com (8.13.4/8.13.4/Debian-1) with ESMTP id j56Hdkae013640; Mon, 6 Jun 2005 20:39:46 +0300 Received: (from jh@localhost) by rautu.tutpro.com (8.13.4/8.13.4/Submit) id j56Hdk2U013637; Mon, 6 Jun 2005 20:39:46 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17060.35426.794874.260020@rautu.tutpro.com> Date: Mon, 6 Jun 2005 20:39:46 +0300 From: Juha Heinanen To: "Dale Worley" Subject: RE: [Sipping] TISPAN In-Reply-To: <009e01c56abc$d878abb0$6a01010a@keywest> References: <32755D354E6B65498C3BD9FD496C7D4613BF23@oefeg-s04.oefeg.loc> <009e01c56abc$d878abb0$6a01010a@keywest> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: "'Sipping \(E-mail\)'" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Dale Worley writes: > As far as I can tell, ETSI is going ahead with defining extensions to SIP to > support features that network operators want. At least initially, these > would be used entirely within their proprietary networks. And they want to > get them defined quickly. i don't understand what ietf would have to do with such walled garden building blocks. I in ietf spells Internet (or at least it used to). unless those telcos pushing the specs in etsi get legal help from totalitarian governments, there is no chance that walled gardens for voice communication could survive. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Mon Jun 06 13:44:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfLef-0000nS-Ee; Mon, 06 Jun 2005 13:44:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfLed-0000nN-JT for sipping@megatron.ietf.org; Mon, 06 Jun 2005 13:44:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21407 for ; Mon, 6 Jun 2005 13:44:50 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfLzU-0006nN-Sj for sipping@ietf.org; Mon, 06 Jun 2005 14:06:27 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j56Hij9Q003612; Mon, 6 Jun 2005 12:44:46 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 6 Jun 2005 18:44:45 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00FC60793@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Dale Worley , "'Sipping (E-mail)'" Subject: RE: [Sipping] TISPAN Date: Mon, 6 Jun 2005 18:44:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org The current requirements document is in revision based on the feedback received so far. ETSI made a decision a long time ago that all its published deliverables would be available free of charge from its web site. All the references made in the current draft are published deliverables. These will all be in PDF format, so if you are a real IETF purist, you will not be able to read them, but most of the rest of the world seem to manage. If you go here: http://www.etsi.org/services_products/freestandard/home.htm you will have to register, but registration merely requires identifying yourself so ETSI can maintain usage statistics. If you wish to have all ETSI published deliverables on a media like DVD, then this will cost you - details at http://www.etsi.org/services_products/e-shop/home.htm, but for the purposes of the small number of references in this draft, the free route should be entirely possible. regards Keith > -----Original Message----- > From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org]On > Behalf Of Dale Worley > Sent: 06 June 2005 18:26 > To: 'Sipping (E-mail)' > Subject: RE: [Sipping] TISPAN > > > I'm starting to lose my grip on what we're trying to accomplish here. > > As far as I can tell, ETSI is going ahead with defining > extensions to SIP to > support features that network operators want. At least > initially, these > would be used entirely within their proprietary networks. > And they want to > get them defined quickly. > > But it would nonetheless be good for them if they got some > input from the > IETF, both for good system design, and to improve > interoperability over the > long term, if not the short term. > > Obviously, ETSI is less interested in commentary on their > requirements than > on their mechanisms. But without fairly detailed information > about their > requirements, it's hard to make intelligent comments on the > mechanisms. To > that end, I thing it would be a big improvment to revise > their document to > include discussion of the feature requirements. Currently, > they only refer > to various telco documents, but I've only been able to find > pointers to > paper copies at significant prices (200+ euros). It isn't > going to generate > much commentary if one has to pay over 1000 euros to discover what the > *requirements* are. > > Dale > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Mon Jun 06 13:47:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfLh0-0001Fp-B1; Mon, 06 Jun 2005 13:47:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfLgx-0001ER-U6 for sipping@megatron.ietf.org; Mon, 06 Jun 2005 13:47:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21645 for ; Mon, 6 Jun 2005 13:47:14 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfM1q-0006rL-9j for sipping@ietf.org; Mon, 06 Jun 2005 14:08:51 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id 2608C6C017 for ; Mon, 6 Jun 2005 13:47:13 -0400 (EDT) From: "Dale Worley" To: "'Sipping (E-mail)'" Subject: RE: [Sipping] TISPAN Date: Mon, 6 Jun 2005 13:46:16 -0400 Message-ID: <00a101c56abf$a44f37c0$6a01010a@keywest> 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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <17060.35426.794874.260020@rautu.tutpro.com> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org > From: Juha Heinanen [mailto:jh@tutpro.com] > > i don't understand what ietf would have to do with such walled garden > building blocks. I in ietf spells Internet (or at least it used to). > unless those telcos pushing the specs in etsi get legal help from > totalitarian governments, there is no chance that walled gardens for > voice communication could survive. There might be market developments that for one reason or another cause such systems to survive. But assuming that the walled gardens do not remain totally isolated forever, there will come a day when their mechanisms and those on the greater Internet start to interact. And if we can give them advice now that will make that interaction better rather than worse, it is an improvement. Dale _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Mon Jun 06 13:54:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfLoD-0002Kh-LY; Mon, 06 Jun 2005 13:54:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfLoC-0002Kc-8Y for sipping@megatron.ietf.org; Mon, 06 Jun 2005 13:54:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22210 for ; Mon, 6 Jun 2005 13:54:43 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfM95-000736-Kp for sipping@ietf.org; Mon, 06 Jun 2005 14:16:20 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j56HsdFL013786; Mon, 6 Jun 2005 12:54:40 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 6 Jun 2005 18:54:39 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00FC60796@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Juha Heinanen Subject: RE: [Sipping] TISPAN Date: Mon, 6 Jun 2005 18:54:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: "'Sipping \(E-mail\)'" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org The implementation of these requirements need be no more walled garden than 3GPP IMS, because that is what it is residing in. Just because I can use IPv4 to build a private internet which cannot be connected to the outside world, does not mean that the current IPv4 specification is a bad thing. Most RFCs can be used in such a walled garden sense - even RFC 1149. None of these services depend on anything more than outbound proxies, inbound proxies, and servers that are routed to using those proxies. These have all been accepted part of the SIP architecture with standards track documents. If you choose to implement that in a walled garden then well and good, but there is nothing that prevents their deployment on the general internet. regards Keith > -----Original Message----- > From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org]On > Behalf Of Juha Heinanen > Sent: 06 June 2005 18:40 > To: Dale Worley > Cc: 'Sipping (E-mail)' > Subject: RE: [Sipping] TISPAN > > > Dale Worley writes: > > > As far as I can tell, ETSI is going ahead with defining > extensions to SIP to > > support features that network operators want. At least > initially, these > > would be used entirely within their proprietary networks. > And they want to > > get them defined quickly. > > i don't understand what ietf would have to do with such walled garden > building blocks. I in ietf spells Internet (or at least it used to). > unless those telcos pushing the specs in etsi get legal help from > totalitarian governments, there is no chance that walled gardens for > voice communication could survive. > > -- juha > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Mon Jun 06 13:57:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfLqX-0002Zc-SH; Mon, 06 Jun 2005 13:57:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfLqV-0002X8-U8 for sipping@megatron.ietf.org; Mon, 06 Jun 2005 13:57:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22347 for ; Mon, 6 Jun 2005 13:57:06 -0400 (EDT) Received: from isozyme58.gprs.dnafinland.fi ([62.78.107.58] helo=rautu.tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfMBM-00076E-EE for sipping@ietf.org; Mon, 06 Jun 2005 14:18:43 -0400 Received: from rautu.tutpro.com (jh@localhost [127.0.0.1]) by rautu.tutpro.com (8.13.4/8.13.4/Debian-1) with ESMTP id j56HvABH013770; Mon, 6 Jun 2005 20:57:10 +0300 Received: (from jh@localhost) by rautu.tutpro.com (8.13.4/8.13.4/Submit) id j56Hv3Fs013767; Mon, 6 Jun 2005 20:57:03 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17060.36463.147597.133175@rautu.tutpro.com> Date: Mon, 6 Jun 2005 20:57:03 +0300 From: Juha Heinanen To: "Dale Worley" Subject: RE: [Sipping] TISPAN In-Reply-To: <00a101c56abf$a44f37c0$6a01010a@keywest> References: <17060.35426.794874.260020@rautu.tutpro.com> <00a101c56abf$a44f37c0$6a01010a@keywest> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: "'Sipping \(E-mail\)'" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Dale Worley writes: > There might be market developments that for one reason or another cause such > systems to survive. their only chance is that we loose freedom of speech, i.e., we are allowed only to speak with each other though their walled gardens (which may very well happen on both sides of atlantic, china, russia, etc.). -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Mon Jun 06 15:47:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfNYy-0007wb-9x; Mon, 06 Jun 2005 15:47:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfNYu-0007vu-JC; Mon, 06 Jun 2005 15:47:04 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03524; Mon, 6 Jun 2005 15:47:02 -0400 (EDT) Message-Id: <200506061947.PAA03524@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 06 Jun 2005 15:47:02 -0400 Cc: sipping@ietf.org Subject: [Sipping] I-D ACTION:draft-ietf-sipping-conference-package-11.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : A Session Initiation Protocol (SIP) Event Package for Conference State Author(s) : J. Rosenberg, et al. Filename : draft-ietf-sipping-conference-package-11.txt Pages : 48 Date : 2005-6-6 This document defines a conference event package for the Session Initiation Protocol (SIP) Events framework, along with a data format used in notifications for this package. The conference package allows users to subscribe to a conference URI. Notifications are sent about changes in the membership of this conference and optionally about changes in the state of additional conference components. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-conference-package-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sipping-conference-package-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sipping-conference-package-11.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: <2005-6-6161926.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-conference-package-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-conference-package-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-6161926.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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-- From sipping-bounces@ietf.org Mon Jun 06 15:47:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfNZD-0007yh-J6; Mon, 06 Jun 2005 15:47:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfNZ9-0007xV-G5; Mon, 06 Jun 2005 15:47:19 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03548; Mon, 6 Jun 2005 15:47:17 -0400 (EDT) Message-Id: <200506061947.PAA03548@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 06 Jun 2005 15:47:17 -0400 Cc: sipping@ietf.org Subject: [Sipping] I-D ACTION:draft-ietf-sipping-cc-conferencing-07.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : Session Initiation Protocol Call Control - Conferencing for User Agents Author(s) : A. Johnston, O. Levin Filename : draft-ietf-sipping-cc-conferencing-07.txt Pages : 42 Date : 2005-6-6 This specification defines conferencing call control features for the Session Initiation Protocol (SIP). This document builds on the Conferencing Requirements and Framework documents to define how a tightly coupled SIP conference works. The approach is explored from different user agent (UA) types perspective: conference-unaware, conference-aware and focus UAs. The use of URIs in conferencing, OPTIONS for capabilities discovery, and call control using REFER are covered in detail with example call flow diagrams. The usage of the isfocus feature tag is defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-conferencing-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sipping-cc-conferencing-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sipping-cc-conferencing-07.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: <2005-6-6161934.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-cc-conferencing-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-cc-conferencing-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-6161934.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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-- From sipping-bounces@ietf.org Mon Jun 06 16:42:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfOQo-0000fV-Mq; Mon, 06 Jun 2005 16:42:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfOQl-0000fQ-Vw for sipping@megatron.ietf.org; Mon, 06 Jun 2005 16:42:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16890 for ; Mon, 6 Jun 2005 16:42:41 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.207]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfOlg-0006Cs-Te for sipping@ietf.org; Mon, 06 Jun 2005 17:04:21 -0400 Received: by wproxy.gmail.com with SMTP id 40so471174wri for ; Mon, 06 Jun 2005 13:42:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EesJ10V7eZDENqkm7liMQBzKBaVIKWW0dkxsY3Sbw+ofw++UsjQN3p3HK7amZugmv/DaE9/MXQYrOaMFFnjv1NegQbSj1L1HxEzJW98OO5/0BHNO5Ez24L6mv/gW21mHmM++83OvvNnLROFRMZ6t7YjInQ30ETdwESr41XpBFg8= Received: by 10.54.55.69 with SMTP id d69mr165578wra; Mon, 06 Jun 2005 13:42:32 -0700 (PDT) Received: by 10.54.17.77 with HTTP; Mon, 6 Jun 2005 13:42:32 -0700 (PDT) Message-ID: Date: Mon, 6 Jun 2005 16:42:32 -0400 From: Arjun Roychowdhury To: Stastny Richard Subject: Re: [Sipping] TISPAN In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613BF23@oefeg-s04.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <32755D354E6B65498C3BD9FD496C7D4613BF23@oefeg-s04.oefeg.loc> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: quoted-printable Cc: "Sipping \(E-mail\)" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Arjun Roychowdhury List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Richard, Has this now become a hard requirement ? Last I checked it was more of a question - i.e. whether SIP+IMS or SIP:IMS is required or will plain ENUM do the trick. It was my understanding that GSM-A was open to discussion on this topic. Is this not correct ? regds arjun On 6/6/05, Stastny Richard wrote: > >so once more, I > >don't recall any point of non interoperability. >=20 > Nice to hear. >=20 > I just wonder for what reason GSM-A required for their ENUM implementatio= n > in GRX e164.3gppnetwork.org (or whatever it will be) to have an additiona= l > special enumservice (either SIP+IMS or SIP:IMS) to distingiush between > IMS SIP and vanilla SIP? >=20 > If what you said is true, they do not need this >=20 > regards >=20 > Richard >=20 > ________________________________ >=20 > Von: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] > Gesendet: Mo 06.06.2005 09:22 > An: Stastny Richard > Cc: Jonathan Rosenberg; Sipping (E-mail) > Betreff: Re: AW: [Sipping] TISPAN >=20 >=20 >=20 > Inline comments. >=20 > Stastny Richard wrote: >=20 > > Well said, Jonathan! > > > > > >>I think it is essential that we allow interoperability between "vanilla= " > >>SIP clients and ones on an IMS network. > >>I don't see any reason why any > >>call feature would be applicable only to IMS or NGN or TISPAN or > >>whatever network. > > > > > > They do. The basic idea of TISPAN and 3GPP NGN IMS is to be in a walled > > garden and not in central park, becauae this is insecure and to be sure= of this > > they want to be non-intereoperable. > > >=20 > Richard: >=20 > I cannot disagree more with your words. I am trying to recall from my > memory one single point where a vanilla SIP client couldn't interoperate > with a SIP client connected to the IMS or to an NGN network, and > honestly speaking, I can't recall any. The only thing that comes to my > memory was that, at some point in time, 3GPP required all the sessions > to use preconditions, so interoperability with those vanilla SIP clients > that did not implement preconditions wasn't possible. This limitation > was relaxed in the Release 6 of the 3GPP specifications, so once more, I > don't recall any point of non interoperability. >=20 > /Miguel >=20 >=20 > > regards > > Richard > > > > >=20 > -- > Miguel A. Garcia tel:+358-50-4804586 > sip:miguel.an.garcia@openlaboratory.net > Nokia Research Center Helsinki, Finland >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP >=20 --=20 Arjun Roychowdhury _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Mon Jun 06 18:13:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfPpD-0006Xm-RQ; Mon, 06 Jun 2005 18:12:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfPpB-0006Xb-ID for sipping@megatron.ietf.org; Mon, 06 Jun 2005 18:12:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23048 for ; Mon, 6 Jun 2005 18:11:58 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfQA7-0007tl-8O for sipping@ietf.org; Mon, 06 Jun 2005 18:33:39 -0400 Received: from [64.101.149.222] ([64.101.149.222]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j56MFHav019354 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 6 Jun 2005 17:15:18 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9d8a2b7764560858ae33d92e17077942@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sipping] Modifying subscribed URI list Date: Mon, 6 Jun 2005 17:12:06 -0500 To: Avshalom Houri X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org On Jun 6, 2005, at 7:55 AM, Avshalom Houri wrote: > I think that it will be quite helpful to add very simple add/remove > operators to the URI list of subscribe in order to > enable fast change of the URI list. > Sounds like valid requirements. We should see if there's a reasonable way to unify this with the other partial-notification work. -- 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 sipping-bounces@ietf.org Mon Jun 06 18:31:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfQ7q-0001hg-Re; Mon, 06 Jun 2005 18:31:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfQ7p-0001gW-02 for sipping@megatron.ietf.org; Mon, 06 Jun 2005 18:31:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25545 for ; Mon, 6 Jun 2005 18:31:14 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfQSk-0008Ng-SA for sipping@ietf.org; Mon, 06 Jun 2005 18:52:55 -0400 Received: from [64.101.149.222] ([64.101.149.222]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j56MYXFx019446 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 6 Jun 2005 17:34:34 -0500 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: References: <32755D354E6B65498C3BD9FD496C7D4613BF23@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Date: Mon, 6 Jun 2005 17:31:20 -0500 To: Sipping ((E-mail)) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: Subject: [Sipping] TISPAN and its impact X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org TISPAN has ideas about how they want to use SIP. They're perfectly welcome to share those ideas with us, and we're likely to talk about them if they do. That's just basic IETF process. Anybody can contribute ideas, even if they're rampantly silly, but we try not to let them disrupt our work. Where those ideas indicate to us an alternative means of accomplishing the apparent goal, we'll probably suggest that means, and the TISPAN folks can take that home and think about it. This happened a lot with 3GPP, and I predict it will happen for TISPAN. Where those ideas convince us of the need for SIP extensions, I expect that we'll define consensus positions on the requirements for those extensions, and work with the SIP working group on defining the extensions. We had several good ideas come in this way from 3GPP like the Path and ServiceRoute extensions, and we're getting good ideas from OMA like the extensions for answering and alerting mode negotiations that I'm currently editing. I expect we'll get a few good ideas from TISPAN. Where it looks like a SIP extension is probably needed to achieve a TISPAN goal, but the goal is not sufficiently general to justify a full blown SIP extension, we might do a P-header or something of that sort. I wouldn't be surprised if we run into a few of these. And where the ideas coming in are repugnant, offensive, or generally retrograde to Internet principles, I expect we'll politely pinch shut our nostrils, explain the offense as appropriate, and thereafter ignore it with the dignity one would accord an unwashed passenger seated nearby on the subway. So, don't panic! The sky is NOT falling, and we're not about to be overrun by a horde of telecom barbarians. -- 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 sipping-bounces@ietf.org Mon Jun 06 19:19:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfQsu-0001CB-DP; Mon, 06 Jun 2005 19:19:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfQss-0001C6-DK for sipping@megatron.ietf.org; Mon, 06 Jun 2005 19:19:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29217 for ; Mon, 6 Jun 2005 19:19:50 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DfRDn-000127-04 for sipping@ietf.org; Mon, 06 Jun 2005 19:41:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Sipping] TISPAN Date: Tue, 7 Jun 2005 01:19:42 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BF25@oefeg-s04.oefeg.loc> Thread-Topic: [Sipping] TISPAN Thread-Index: AcVq2LixMRQyYMmgTiatlhCOcfajNQAFX8v/ From: "Stastny Richard" To: "Arjun Roychowdhury" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: quoted-printable Cc: "Sipping \(E-mail\)" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Correct, this was a a topic for discussion and I tried to convince some of the proponents that it is not necessary. =20 But since GSM-A is a private and top-secret club, I have currently no idea of the outcome. Maybe I get more info next week at TISPAN WG4 =20 Richard ________________________________ Von: Arjun Roychowdhury [mailto:arjunrc@gmail.com] Gesendet: Mo 06.06.2005 22:42 An: Stastny Richard Cc: Sipping (E-mail) Betreff: Re: [Sipping] TISPAN Richard, Has this now become a hard requirement ? Last I checked it was more of a question - i.e. whether SIP+IMS or SIP:IMS is required or will plain ENUM do the trick. It was my understanding that GSM-A was open to discussion on this topic. Is this not correct ? regds arjun On 6/6/05, Stastny Richard wrote: > >so once more, I > >don't recall any point of non interoperability. > > Nice to hear. > > I just wonder for what reason GSM-A required for their ENUM = implementation > in GRX e164.3gppnetwork.org (or whatever it will be) to have an = additional > special enumservice (either SIP+IMS or SIP:IMS) to distingiush between > IMS SIP and vanilla SIP? > > If what you said is true, they do not need this > > regards > > Richard > > ________________________________ > > Von: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] > Gesendet: Mo 06.06.2005 09:22 > An: Stastny Richard > Cc: Jonathan Rosenberg; Sipping (E-mail) > Betreff: Re: AW: [Sipping] TISPAN > > > > Inline comments. > > Stastny Richard wrote: > > > Well said, Jonathan! > > > > > >>I think it is essential that we allow interoperability between = "vanilla" > >>SIP clients and ones on an IMS network. > >>I don't see any reason why any > >>call feature would be applicable only to IMS or NGN or TISPAN or > >>whatever network. > > > > > > They do. The basic idea of TISPAN and 3GPP NGN IMS is to be in a = walled > > garden and not in central park, becauae this is insecure and to be = sure of this > > they want to be non-intereoperable. > > > > Richard: > > I cannot disagree more with your words. I am trying to recall from my > memory one single point where a vanilla SIP client couldn't = interoperate > with a SIP client connected to the IMS or to an NGN network, and > honestly speaking, I can't recall any. The only thing that comes to my > memory was that, at some point in time, 3GPP required all the sessions > to use preconditions, so interoperability with those vanilla SIP = clients > that did not implement preconditions wasn't possible. This limitation > was relaxed in the Release 6 of the 3GPP specifications, so once more, = I > don't recall any point of non interoperability. > > /Miguel > > > > regards > > Richard > > > > > > -- > Miguel A. Garcia tel:+358-50-4804586 > sip:miguel.an.garcia@openlaboratory.net > Nokia Research Center Helsinki, Finland > > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > -- Arjun Roychowdhury _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Mon Jun 06 19:53:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfRP5-0006x6-Vk; Mon, 06 Jun 2005 19:53:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfRP2-0006w0-T5; Mon, 06 Jun 2005 19:53:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02506; Mon, 6 Jun 2005 19:53:07 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfRjx-00021n-7O; Mon, 06 Jun 2005 20:14:47 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 06 Jun 2005 16:53:05 -0700 X-IronPort-AV: i="3.93,175,1115017200"; d="scan'208"; a="275098655:sNHT64106602" Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j56Nr0lw020867; Mon, 6 Jun 2005 16:53:00 -0700 (PDT) Received: from jmpolk-wxp.cisco.com (rcdn-vpn-cluster-1-14.cisco.com [10.89.16.14]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA07093; Mon, 6 Jun 2005 16:53:00 -0700 (PDT) Message-Id: <4.3.2.7.2.20050606183828.033fd790@diablo.cisco.com> X-Sender: jmpolk@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 06 Jun 2005 18:52:47 -0500 To: Mpierce1@aol.com, iesg@ietf.org, sip@ietf.org, sipping@ietf.org From: "James M. Polk" Subject: Re: [Sipping] Re: [Sip] Comments on Last Call of "Extending Reason-header for... In-Reply-To: <7a.74d87318.2fd5b3c1@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org comments lower in the message At 10:12 AM 6/6/2005 -0400, Mpierce1@aol.com wrote: >In a message dated 6/2/2005 6:10:09 PM Eastern Daylight Time, >jmpolk@cisco.com writes: > > >>Because SIP and Q.850 have clearly defined meanings for their cause >>numbers, and this extension does not, I believe the text string should be >>maintained through IANA. >> >> >From an IANA point of view, at >>http://www.iana.org/assignments/sip-parameters you can see the text string >>for each 1XX, 2XX, 3XX, 4XX, 5XX and 6XX response code that would be used >>if the SIP protocol were used in a 3326 Reason header. As IANA is where to >>first look up these things, I'm not sure why you have an issue with IANA >>having the same text string explaining what each cause is in the Preemption >>protocol of the Reason header. If the text string were removed in the IANA >>registration, there would be no clue there what each cause number meant. >> >>This is not the case right now at >>http://www.iana.org/assignments/sip-parameters for all other SIP parameters. >> >>I believe one of your concerns is the user learning/reading the reason in >>the Reason header within your domain, and I believe that is a local >>configuration decision. >> >>In the document, I do not believe I ever made it a MUST, SHOULD, >>RECOMMENDED or even a MAY be presented to the user of the UA who is being >>preempted. I believe this is up to the implementation and local policy to >>show, or not to show. > >I guess I didn't explain my concern well enough. I think I now understand your original comment differently >It isn't the issue of notifying the user of something they shouldn't know >in our domain. The "Generic Preemption" was added to deal with this. yes >I have no problem with the (default) text string being registered with >IANA for each defined preemption cause as was done for each SIP response >code. The concern is that the IANA considerations section does not make it >clear that this is what IANA is expected to do. fair point - and one I have asked our chair to clarify for the revision of this document. >I don't understand why this is called the "default" text. well... because the text string is optional, and the text can be something other than the exact string listed as the default in this document. >It would seem that any device could put in any text string it wanted, for >example, the same thing in another langauage. yes, but this is guidance - ala "if you use a text string, we recommend this one for consistency" >I believe RFC 3261 is rather vague on this issue. While the ABNF requires >that a Reason-phrase be included in every message and it provides >"default" text for each and includes it in the IANA registration, I don't >believe it requires that this exact text string be used. nope it doesn't, you're right, and that is why the word "default" is used for guidance reasons. The doc specifies the exact reason for each code, but the string can be some variant. I can give more explanation in that part of the document to this affect. >My comment is mostly that there appears to be a conflict between the text >in this draft and the formal syntax definition in RFC 3326. I don't know >which is correct. I attempted to take the 3326 text a bit further without overstepping the gist of the RFC. >It would seem to me that, if this new preemption cause is used, that the >numeric cause value is mandatory and the text string is optional. yes, as long as the new cause code act exactly as is specified in that extension RFC, and there is a default text string to give *some* guidance (which can be omitted or changed per domain). >Neither RFC 3326 nor this draft says that. The formal definition in RFC >3326 says both are optional. This draft indicates that both are required. I didn't mean to imply the text string is required - I would have used SHALL if I meant that. I apologize for the mixed meaning there. I will clarify that the text string is optional in the document, but a guidance/default string is needed for IANA registration. I will add that this string can be something other than the exact string given in the doc per cause value. Is this agreeable? >Mike Pierce >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Tue Jun 07 00:01:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfVH7-0000AQ-Px; Tue, 07 Jun 2005 00:01:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfVH5-00007t-W4 for sipping@megatron.ietf.org; Tue, 07 Jun 2005 00:01:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20607 for ; Tue, 7 Jun 2005 00:01:07 -0400 (EDT) Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfVc0-000886-Jh for sipping@ietf.org; Tue, 07 Jun 2005 00:22:50 -0400 Received: from harvest.india.hp.com (harvest.india.hp.com [15.76.216.203]) by palrel10.hp.com (Postfix) with ESMTP id 8E9A72312; Mon, 6 Jun 2005 21:01:01 -0700 (PDT) Received: from obbani ([15.76.119.97]) by harvest.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id JAA22071; Tue, 7 Jun 2005 09:42:55 +0530 (IST) Message-Id: <200506070412.JAA22071@harvest.india.hp.com> From: "Banibrata Dutta" To: "'Drage, Keith (Keith)'" , "'Dale Worley'" , "'Sipping (E-mail)'" Subject: RE: [Sipping] TISPAN Date: Tue, 7 Jun 2005 09:30:56 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVqwS8EeCJRQ8h+SPe0WeBKiWLgHgAU8opQ In-Reply-To: <475FF955A05DD411980D00508B6D5FB00FC60793@en0033exch001u.uk.lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org We need to be careful when we say that all the reference material (ETSI documents) shall suffice in understanding the requirements completely, because ETSI documents many a times refere to ITU-T documents, which are not "as-free-as" ETSI documents. For personal use (AFAIK) you can download upto 3 ITU-T documents for free from their website, again -- all PDF's (after registering yourself -- again for free). As far as IMS is concerned, I don't think there's any need to refer to any ITU-T doc for understanding requirements, though if you start digging really deep, you may need to! Just for information! cheers, banibrata dutta. -----Original Message----- From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf Of Drage, Keith (Keith) Sent: Monday, June 06, 2005 11:15 PM To: Dale Worley; 'Sipping (E-mail)' Subject: RE: [Sipping] TISPAN The current requirements document is in revision based on the feedback received so far. ETSI made a decision a long time ago that all its published deliverables would be available free of charge from its web site. All the references made in the current draft are published deliverables. These will all be in PDF format, so if you are a real IETF purist, you will not be able to read them, but most of the rest of the world seem to manage. If you go here: http://www.etsi.org/services_products/freestandard/home.htm you will have to register, but registration merely requires identifying yourself so ETSI can maintain usage statistics. If you wish to have all ETSI published deliverables on a media like DVD, then this will cost you - details at http://www.etsi.org/services_products/e-shop/home.htm, but for the purposes of the small number of references in this draft, the free route should be entirely possible. regards Keith > -----Original Message----- > From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org]On > Behalf Of Dale Worley > Sent: 06 June 2005 18:26 > To: 'Sipping (E-mail)' > Subject: RE: [Sipping] TISPAN > > > I'm starting to lose my grip on what we're trying to accomplish here. > > As far as I can tell, ETSI is going ahead with defining extensions to > SIP to support features that network operators want. At least > initially, these would be used entirely within their proprietary > networks. > And they want to > get them defined quickly. > > But it would nonetheless be good for them if they got some input from > the IETF, both for good system design, and to improve interoperability > over the long term, if not the short term. > > Obviously, ETSI is less interested in commentary on their requirements > than on their mechanisms. But without fairly detailed information > about their requirements, it's hard to make intelligent comments on > the mechanisms. To that end, I thing it would be a big improvment to > revise their document to include discussion of the feature > requirements. Currently, they only refer to various telco documents, > but I've only been able to find pointers to paper copies at > significant prices (200+ euros). It isn't going to generate much > commentary if one has to pay over 1000 euros to discover what the > *requirements* are. > > Dale > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Tue Jun 07 03:26:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfYTO-0002Ev-GP; Tue, 07 Jun 2005 03:26:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfYTM-0002EX-3u for sipping@megatron.ietf.org; Tue, 07 Jun 2005 03:26:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23298 for ; Tue, 7 Jun 2005 03:26:02 -0400 (EDT) Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfYoK-0003Ik-IJ for sipping@ietf.org; Tue, 07 Jun 2005 03:47:47 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j577LO1s027475; Tue, 7 Jun 2005 10:21:24 +0300 Received: from esebh003.NOE.Nokia.com ([172.21.138.82]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Jun 2005 10:24:52 +0300 Received: from [127.0.0.1] ([10.162.27.167]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 7 Jun 2005 10:24:52 +0300 Message-ID: <42A54BC2.6000105@nokia.com> Date: Tue, 07 Jun 2005 10:24:50 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Sipping] TISPAN References: <32755D354E6B65498C3BD9FD496C7D4613BF23@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613BF23@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2005 07:24:52.0973 (UTC) FILETIME=[FF3DB1D0:01C56B31] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Cc: "Sipping \(E-mail\)" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Richard: First time I hear about such ENUM service. I am not following what the GSM-A is doing, so I can't really comment. /Miguel Stastny Richard wrote: >>so once more, I >>don't recall any point of non interoperability. > > > Nice to hear. > > I just wonder for what reason GSM-A required for their ENUM implementation > in GRX e164.3gppnetwork.org (or whatever it will be) to have an additional > special enumservice (either SIP+IMS or SIP:IMS) to distingiush between > IMS SIP and vanilla SIP? > > If what you said is true, they do not need this > > regards > > Richard > > ________________________________ > > Von: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] > Gesendet: Mo 06.06.2005 09:22 > An: Stastny Richard > Cc: Jonathan Rosenberg; Sipping (E-mail) > Betreff: Re: AW: [Sipping] TISPAN > > > > Inline comments. > > Stastny Richard wrote: > > >>Well said, Jonathan! >> >> >> >>>I think it is essential that we allow interoperability between "vanilla" >>>SIP clients and ones on an IMS network. >>>I don't see any reason why any >>>call feature would be applicable only to IMS or NGN or TISPAN or >>>whatever network. >> >> >>They do. The basic idea of TISPAN and 3GPP NGN IMS is to be in a walled >>garden and not in central park, becauae this is insecure and to be sure of this >>they want to be non-intereoperable. >> > > > Richard: > > I cannot disagree more with your words. I am trying to recall from my > memory one single point where a vanilla SIP client couldn't interoperate > with a SIP client connected to the IMS or to an NGN network, and > honestly speaking, I can't recall any. The only thing that comes to my > memory was that, at some point in time, 3GPP required all the sessions > to use preconditions, so interoperability with those vanilla SIP clients > that did not implement preconditions wasn't possible. This limitation > was relaxed in the Release 6 of the 3GPP specifications, so once more, I > don't recall any point of non interoperability. > > /Miguel > > > >>regards >>Richard >> >> > > > -- > Miguel A. Garcia tel:+358-50-4804586 > sip:miguel.an.garcia@openlaboratory.net > Nokia Research Center Helsinki, Finland > > > > -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Tue Jun 07 04:35:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfZYS-0004bh-T7; Tue, 07 Jun 2005 04:35:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfZYP-0004bc-If for sipping@megatron.ietf.org; Tue, 07 Jun 2005 04:35:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00152 for ; Tue, 7 Jun 2005 04:35:18 -0400 (EDT) Received: from mailgate1.vodafone.co.uk ([194.62.232.133] helo=hlmail01.vfl.vodafone) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfZtP-00050O-D1 for sipping@ietf.org; Tue, 07 Jun 2005 04:57:04 -0400 Received: from ukwcs03.vf-uk.internal.vodafone.com (ukwcs03 [10.33.127.10]) by hlmail01.vfl.vodafone (8.11.6/8.11.6) with ESMTP id j578Yls07634 for ; Tue, 7 Jun 2005 09:34:47 +0100 Received: from ukwmxc01.vf-uk.internal.vodafone.com (ukwmxc01 [10.33.126.160]) by ukwcs03.vf-uk.internal.vodafone.com (4.9.7.3) with ESMTP id 7H201AAQ for ; Tue, 07 Jun 2005 09:34:43 +0100 Received: from ukwmxc04.vf-uk.internal.vodafone.com ([10.33.126.173]) by ukwmxc01.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.6797); Tue, 7 Jun 2005 09:34:42 +0100 Received: from ukwmxm11.vf-uk.internal.vodafone.com ([10.33.113.32]) by ukwmxc04.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.6797); Tue, 7 Jun 2005 09:34:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Jun 2005 09:34:42 +0100 Message-ID: Thread-Topic: [Sipping] TISPAN thread-index: AcVqwS8EeCJRQ8h+SPe0WeBKiWLgHgAU8opQAAdmC4A= From: "Warren, Dan, VF UK - Technology \(TS\)" To: "Sipping \(E-mail\)" X-OriginalArrivalTime: 07 Jun 2005 08:34:42.0312 (UTC) FILETIME=[C0481880:01C56B3B] X-Spam-Score: 0.0 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 Content-Transfer-Encoding: quoted-printable Subject: [Sipping] How to work with TISPAN... X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Perhaps a little history is required from the 'telecom barbarians' side = of the fence, although not too much as I wouldn't want to bore you = all... When 3GPP started defining IMS, SIP was selected as the session control = protocol and a lot of things were proposed by 3GPP in isolation from the = IETF community. When the IETF community got wind of these = abominations/developments (I am trying to stay neutral as to which side = of the fence I now reside on here), they were rightly upset, and after = much wailing, hammering of fists and gnashing of teeth, 3GPP brought = their requirements to IETF and (IMHO) lots of good and useful work = ensued. Some of this, as has been pointed out, is for the good of the = entire community; some of it is very sepcific to the requirements of = 3GPP. However, the overriding principle behind all of it was in line = with IETF principles that none of this should break anything, and no = walled garden should be erected as a direct result of the technical = implementation (even if that implementation might end up behind a wall = anyway). This should not be news to many of you as you were there and = helped make it happen. TISPAN is now defining it's Next generation network (NGN) and one = fundamental element of that is IMS. Because it is IMS, then 3GPP have = taken a close interest and one of the stated aims of 3GPP's work to make = IMS access independent and of TISPAN in adopting IMS is to allow for the = possibility of fixed/mobile convergence (and that isn't just about = voice). As such, the ultimate target here is for 3GPP to take TISPAN = requirements and incorporate them into the technical solutions, = specifications and protocols that are defined as part of IMS to provide = a single, common architecture and protocol set. There was recently a = joint 3GPP and TISPAN meeting where TISPAN discussed what they wanted to = do to the 3GPP IMS SIP profile in 24.229. 3GPP's reaction to some of = the proposals was along the lines of 'this is where we were 5 years ago. = Learn from our mistakes. Go to the IETF and work with them as we did'. = So, now you have a new set of requirements, but you can use the same = working method - define extensions as you see fit, P-headers when you = need to pinch your nose a bit and explain the best way to get these = things done. Some of the requirements are even more 'barbaric' than = those that 3GPP came up with because they relate directly to voice call = supplementary services which are regulatory requirements in many = networks and so have to be supported to allow IMS to serve a voice = service that at least looks and feels like that which is available now, = even if it is VoIP. =20 As for comments such as 'The basic idea of TISPAN and 3GPP NGN IMS is to = be in a walled garden... they want to be non-interoperable', if that were the case, = TISPAN and 3GPP would not have ever gone along the path of bringing = anything to IETF. The reason 3GPP provided their requirements to you = was because IETF told 3GPP that they were going the wrong way. 3GPP has = seen the light(!) and is now trying to help TISPAN see the light too. = Whilst the bells and whistles that are being added to solve these = requirements might not be to everyones taste, they are being added in = such a way that if they aren't to your taste, you don't need to use them = and the basic principles of interoperability should still apply as a = result - fall back to vanilla SIP will (should) work and so the basic = functionality to establish and maintain a session should work too. 3GPP = and TISPAN are being guided by you, so if it becomes broken, you are = party to the breakage as well. There is sufficient SIP based voice = deployments today for interoperability to be a real and significant (and = wholly unspoken) requirement. And 'since GSM-A is a private and top-secret club...' - well all I can = say is go to their website and see what you can actually access. If you = really feel the need to read the very long, complex and entirely = commercial and legal framework interconnect agreements that are hidden = from public gaze, I pity you sincerely. However, much of the technical = work is public and GSM-A is very good at seeking the expert advice it = needs on subjects that it is not entirely conversent with. I'll tell = you what is going on with the specific example in the relevant thread. Ultimately TISPAN and 3GPP are trying to achieve something that for = barbarians is pretty revolutionary - a call/session control mechanism = and service implementation environment that is as far as it can possibly = be, non discriminatory based on access technology. Roland Jesske's = draft is a first step in the direction of getting your help so that the = garden is also as unwalled as it can be whilst also maintaining the = service requirements that regulators impose on voice calls. It is a = collision of concepts and ethos, but the work that has been achieved = with 3GPP shows it can be done. I am sure that TISPAN are redrafting = the requirements frantically to get them into a position where they are = entirely understood so that the work on the related solutions can begin. = There are timescales involved, but ultimately what is important is a = solution that meets the requirements. If it was really about timescales = and walled gardens, and not about trying to get something that can work = with vanilla SIP, we wouldn't be on the path that the requirements draft = sets us on. Cheers Dan Warren Half barbarian half purist > -----Original Message----- > From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org]On > Behalf Of Banibrata Dutta > Sent: 07 June 2005 05:01 > To: 'Drage, Keith (Keith)'; 'Dale Worley'; 'Sipping (E-mail)' > Subject: RE: [Sipping] TISPAN >=20 >=20 > We need to be careful when we say that all the reference=20 > material (ETSI > documents) shall suffice in understanding the requirements completely, > because ETSI documents many a times refere to ITU-T=20 > documents, which are not > "as-free-as" ETSI documents. For personal use (AFAIK) you can=20 > download upto > 3 ITU-T documents for free from their website, again -- all=20 > PDF's (after > registering yourself -- again for free). >=20 > As far as IMS is concerned, I don't think there's any need to=20 > refer to any > ITU-T doc for understanding requirements, though if you start=20 > digging really > deep, you may need to! >=20 > Just for information! >=20 > cheers, > banibrata dutta.=20 >=20 > -----Original Message----- > From: sipping-bounces@ietf.org=20 > [mailto:sipping-bounces@ietf.org] On Behalf > Of Drage, Keith (Keith) > Sent: Monday, June 06, 2005 11:15 PM > To: Dale Worley; 'Sipping (E-mail)' > Subject: RE: [Sipping] TISPAN >=20 > The current requirements document is in revision based on the feedback > received so far. >=20 > ETSI made a decision a long time ago that all its published=20 > deliverables > would be available free of charge from its web site. All the=20 > references made > in the current draft are published deliverables. These will=20 > all be in PDF > format, so if you are a real IETF purist, you will not be=20 > able to read them, > but most of the rest of the world seem to manage. >=20 > If you go here:=20 > http://www.etsi.org/services_products/freestandard/home.htm > you will have to register, but registration merely requires=20 > identifying > yourself so ETSI can maintain usage statistics. >=20 > If you wish to have all ETSI published deliverables on a=20 > media like DVD, > then this will cost you - details at > http://www.etsi.org/services_products/e-shop/home.htm, but=20 > for the purposes > of the small number of references in this draft, the free=20 > route should be > entirely possible. >=20 > regards >=20 > Keith >=20 >=20 >=20 > > -----Original Message----- > > From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org]On > > Behalf Of Dale Worley > > Sent: 06 June 2005 18:26 > > To: 'Sipping (E-mail)' > > Subject: RE: [Sipping] TISPAN > >=20 > >=20 > > I'm starting to lose my grip on what we're trying to=20 > accomplish here. > >=20 > > As far as I can tell, ETSI is going ahead with defining=20 > extensions to=20 > > SIP to support features that network operators want. At least=20 > > initially, these would be used entirely within their proprietary=20 > > networks. > > And they want to > > get them defined quickly. > >=20 > > But it would nonetheless be good for them if they got some=20 > input from=20 > > the IETF, both for good system design, and to improve=20 > interoperability=20 > > over the long term, if not the short term. > >=20 > > Obviously, ETSI is less interested in commentary on their=20 > requirements=20 > > than on their mechanisms. But without fairly detailed information=20 > > about their requirements, it's hard to make intelligent comments on=20 > > the mechanisms. To that end, I thing it would be a big=20 > improvment to=20 > > revise their document to include discussion of the feature=20 > > requirements. Currently, they only refer to various telco=20 > documents,=20 > > but I've only been able to find pointers to paper copies at=20 > > significant prices (200+ euros). It isn't going to generate much=20 > > commentary if one has to pay over 1000 euros to discover what the > > *requirements* are. > >=20 > > Dale > >=20 > >=20 > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sip@ietf.org for new developments of core SIP > >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sip@ietf.org for new developments of core SIP >=20 >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP >=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Tue Jun 07 04:40:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfZdY-00058n-VM; Tue, 07 Jun 2005 04:40:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfZdY-00058i-4g for sipping@megatron.ietf.org; Tue, 07 Jun 2005 04:40:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00551 for ; Tue, 7 Jun 2005 04:40:38 -0400 (EDT) Received: from mailgate2.vodafone.co.uk ([194.62.232.134] helo=hlmail02.vfl.vodafone) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfZyZ-000581-83 for sipping@ietf.org; Tue, 07 Jun 2005 05:02:23 -0400 Received: from ukwcs06.vf-uk.internal.vodafone.com (ukwcs06 [10.33.112.206]) by hlmail02.vfl.vodafone (8.11.6/8.11.6) with ESMTP id j578e4a30292; Tue, 7 Jun 2005 09:40:29 +0100 Received: from ukwmxc02.vf-uk.internal.vodafone.com (ukwmxc02 [10.33.126.170]) by ukwcs06.vf-uk.internal.vodafone.com (4.9.7.3) with ESMTP id 0U286AAL; Tue, 07 Jun 2005 09:40:00 +0100 Received: from ukwmxc03.vf-uk.internal.vodafone.com ([10.33.126.155]) by ukwmxc02.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.6797); Tue, 7 Jun 2005 09:39:59 +0100 Received: from ukwmxm11.vf-uk.internal.vodafone.com ([10.33.113.32]) by ukwmxc03.vf-uk.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.6797); Tue, 7 Jun 2005 09:39:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] TISPAN Date: Tue, 7 Jun 2005 09:39:58 +0100 Message-ID: Thread-Topic: [Sipping] TISPAN thread-index: AcVrMnHaGNX72yHeShm2t/k+EsLlbgACU91g From: "Warren, Dan, VF UK - Technology \(TS\)" To: "Miguel Garcia" , "Stastny Richard" X-OriginalArrivalTime: 07 Jun 2005 08:39:58.0640 (UTC) FILETIME=[7CD3EB00:01C56B3C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: quoted-printable Cc: "Sipping \(E-mail\)" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Miguel, Richard The ENUM service described was proposed to GSM-A by one specific = company, and is still under discussion. It is being fought strongly by = Vodafone for a number of reasons, not least that which you describe = below, and also because of the potential impacts the discrimination = between addresses based on the presence of the IMS specific = identification would have on session handling. It is NOT an agreed = GSM-A requirements and as such is not agreed to be in the GRX, although = there is still some work to be done to chase the proposal away = completely. If either or both of you would like to provide further ammunition, = please feel free to mail me back away from the list. Cheers Dan=20 > -----Original Message----- > From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org]On > Behalf Of Miguel Garcia > Sent: 07 June 2005 08:25 > To: Stastny Richard > Cc: Sipping (E-mail) > Subject: Re: [Sipping] TISPAN >=20 >=20 > Richard: >=20 > First time I hear about such ENUM service. I am not following=20 > what the=20 > GSM-A is doing, so I can't really comment. >=20 > /Miguel >=20 > Stastny Richard wrote: >=20 > >>so once more, I > >>don't recall any point of non interoperability. > >=20 > >=20 > > Nice to hear. > >=20 > > I just wonder for what reason GSM-A required for their ENUM=20 > implementation > > in GRX e164.3gppnetwork.org (or whatever it will be) to=20 > have an additional > > special enumservice (either SIP+IMS or SIP:IMS) to=20 > distingiush between > > IMS SIP and vanilla SIP? > >=20 > > If what you said is true, they do not need this > >=20 > > regards > >=20 > > Richard > >=20 > > ________________________________ > >=20 > > Von: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] > > Gesendet: Mo 06.06.2005 09:22 > > An: Stastny Richard > > Cc: Jonathan Rosenberg; Sipping (E-mail) > > Betreff: Re: AW: [Sipping] TISPAN > >=20 > >=20 > >=20 > > Inline comments. > >=20 > > Stastny Richard wrote: > >=20 > >=20 > >>Well said, Jonathan! > >> > >> > >> > >>>I think it is essential that we allow interoperability=20 > between "vanilla" > >>>SIP clients and ones on an IMS network. > >>>I don't see any reason why any > >>>call feature would be applicable only to IMS or NGN or TISPAN or > >>>whatever network. > >> > >> > >>They do. The basic idea of TISPAN and 3GPP NGN IMS is to be=20 > in a walled > >>garden and not in central park, becauae this is insecure=20 > and to be sure of this > >>they want to be non-intereoperable. > >> > >=20 > >=20 > > Richard: > >=20 > > I cannot disagree more with your words. I am trying to=20 > recall from my > > memory one single point where a vanilla SIP client couldn't=20 > interoperate > > with a SIP client connected to the IMS or to an NGN network, and > > honestly speaking, I can't recall any. The only thing that=20 > comes to my > > memory was that, at some point in time, 3GPP required all=20 > the sessions > > to use preconditions, so interoperability with those=20 > vanilla SIP clients > > that did not implement preconditions wasn't possible.=20 > This limitation > > was relaxed in the Release 6 of the 3GPP specifications, so=20 > once more, I > > don't recall any point of non interoperability. > >=20 > > /Miguel > >=20 > >=20 > >=20 > >>regards > >>Richard > >> > >> > >=20 > >=20 > > -- > > Miguel A. Garcia tel:+358-50-4804586 > > sip:miguel.an.garcia@openlaboratory.net > > Nokia Research Center Helsinki, Finland > >=20 > >=20 > >=20 > >=20 >=20 > --=20 > Miguel A. Garcia tel:+358-50-4804586 > sip:miguel.an.garcia@openlaboratory.net > Nokia Research Center Helsinki, Finland >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP >=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Tue Jun 07 04:41:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfZdt-00059Z-Pi; Tue, 07 Jun 2005 04:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfZdr-00059T-EI for sipping@megatron.ietf.org; Tue, 07 Jun 2005 04:40:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00568 for ; Tue, 7 Jun 2005 04:40:57 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfZys-00058Q-Mr for sipping@ietf.org; Tue, 07 Jun 2005 05:02:43 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j578etSI020182; Tue, 7 Jun 2005 03:40:56 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 7 Jun 2005 09:40:55 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00FC607D0@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Banibrata Dutta , "'Sipping (E-mail)'" Subject: RE: [Sipping] TISPAN Date: Tue, 7 Jun 2005 09:40:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org I don't think I, or any of the other people involved in this draft, have claimed that all reference material shall suffice for understanding. What we have indicated is that we wish to describe the services, as seen by the end user, by reference, and to not repeat that material in the requirements draft. If readers consider that there are issues that need clarification, that are not provided by those referenced service definitions, then we will revise to add material, or provide additional references, as appropriate. Obviously we would appreciate identification of those areas where there is still lack of understanding of the scenarios even with the reading of the related service definition. regards Keith > -----Original Message----- > From: Banibrata Dutta [mailto:dutta@india.hp.com] > Sent: 07 June 2005 05:01 > To: 'Drage, Keith (Keith)'; 'Dale Worley'; 'Sipping (E-mail)' > Subject: RE: [Sipping] TISPAN > > > We need to be careful when we say that all the reference > material (ETSI > documents) shall suffice in understanding the requirements completely, > because ETSI documents many a times refere to ITU-T > documents, which are not > "as-free-as" ETSI documents. For personal use (AFAIK) you can > download upto > 3 ITU-T documents for free from their website, again -- all > PDF's (after > registering yourself -- again for free). > > As far as IMS is concerned, I don't think there's any need to > refer to any > ITU-T doc for understanding requirements, though if you start > digging really > deep, you may need to! > > Just for information! > > cheers, > banibrata dutta. > > -----Original Message----- > From: sipping-bounces@ietf.org > [mailto:sipping-bounces@ietf.org] On Behalf > Of Drage, Keith (Keith) > Sent: Monday, June 06, 2005 11:15 PM > To: Dale Worley; 'Sipping (E-mail)' > Subject: RE: [Sipping] TISPAN > > The current requirements document is in revision based on the feedback > received so far. > > ETSI made a decision a long time ago that all its published > deliverables > would be available free of charge from its web site. All the > references made > in the current draft are published deliverables. These will > all be in PDF > format, so if you are a real IETF purist, you will not be > able to read them, > but most of the rest of the world seem to manage. > > If you go here: > http://www.etsi.org/services_products/freestandard/home.htm > you will have to register, but registration merely requires > identifying > yourself so ETSI can maintain usage statistics. > > If you wish to have all ETSI published deliverables on a > media like DVD, > then this will cost you - details at > http://www.etsi.org/services_products/e-shop/home.htm, but > for the purposes > of the small number of references in this draft, the free > route should be > entirely possible. > > regards > > Keith > > > > > -----Original Message----- > > From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org]On > > Behalf Of Dale Worley > > Sent: 06 June 2005 18:26 > > To: 'Sipping (E-mail)' > > Subject: RE: [Sipping] TISPAN > > > > > > I'm starting to lose my grip on what we're trying to > accomplish here. > > > > As far as I can tell, ETSI is going ahead with defining > extensions to > > SIP to support features that network operators want. At least > > initially, these would be used entirely within their proprietary > > networks. > > And they want to > > get them defined quickly. > > > > But it would nonetheless be good for them if they got some > input from > > the IETF, both for good system design, and to improve > interoperability > > over the long term, if not the short term. > > > > Obviously, ETSI is less interested in commentary on their > requirements > > than on their mechanisms. But without fairly detailed information > > about their requirements, it's hard to make intelligent comments on > > the mechanisms. To that end, I thing it would be a big > improvment to > > revise their document to include discussion of the feature > > requirements. Currently, they only refer to various telco > documents, > > but I've only been able to find pointers to paper copies at > > significant prices (200+ euros). It isn't going to generate much > > commentary if one has to pay over 1000 euros to discover what the > > *requirements* are. > > > > Dale > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sip@ietf.org for new developments of core SIP > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sip@ietf.org for new developments of core SIP > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Tue Jun 07 06:50:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfben-0007o5-9w; Tue, 07 Jun 2005 06:50:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfbel-0007nL-4c for sipping@megatron.ietf.org; Tue, 07 Jun 2005 06:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09706 for ; Tue, 7 Jun 2005 06:50:00 -0400 (EDT) Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dfbzk-0007jN-GJ for sipping@ietf.org; Tue, 07 Jun 2005 07:11:47 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IHP00001NB6NJ@siemenscomms.co.uk> for sipping@ietf.org; Tue, 07 Jun 2005 11:47:30 +0100 (BST) Received: from ntht206e.siemenscomms.co.uk ([137.223.247.52]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IHP00NDCNB40S@siemenscomms.co.uk> for sipping@ietf.org; Tue, 07 Jun 2005 11:47:28 +0100 (BST) Received: by ntht206e.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 07 Jun 2005 11:49:43 +0100 Content-return: allowed Date: Tue, 07 Jun 2005 11:49:33 +0100 From: "Elwell, John" To: sipping@ietf.org Message-id: <50B1CBA96870A34799A506B2313F2667059ECA46@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.6 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [Sipping] draft-elwell-sipping-redirection-reason-02.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1902669150==" Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org 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. --===============1902669150== Content-return: allowed Content-type: multipart/alternative; boundary="Boundary_(ID_xJ6yJLdOpGdVM69n6LHOBw)" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_xJ6yJLdOpGdVM69n6LHOBw) Content-type: text/plain Content-Transfer-Encoding: 7BIT This draft has been posted: http://www.ietf.org/internet-drafts/draft-elwell-sipping-redirection-reason- 02.txt Discussions in Minneapolis revealed confusion about the two different problems the draft was trying to solve: PSTN interworking and the so-called 3xx ambiguity problem. I therefore followed advice to separate the two problems, and this new draft just deals with PSTN interworking. Note that it is also referenced from draft-jesske-sipping-tispan-requirements. I also tried to write down requirements for solving the 3xx ambiguity problem, but this just led to further confusion as to what the problem really is, so I have given up on that one. If the present solution happens to help, then fine. John --Boundary_(ID_xJ6yJLdOpGdVM69n6LHOBw) Content-type: text/html Content-Transfer-Encoding: 7BIT draft-elwell-sipping-redirection-reason-02.txt

This draft has been posted:

http://www.ietf.org/internet-drafts/draft-elwell-sipping-redirection-reason-02.txt

Discussions in Minneapolis revealed confusion about the two different problems the draft was trying to solve: PSTN interworking and the so-called 3xx ambiguity problem. I therefore followed advice to separate the two problems, and this new draft just deals with PSTN interworking. Note that it is also referenced from draft-jesske-sipping-tispan-requirements.

I also tried to write down requirements for solving the 3xx ambiguity problem, but this just led to further confusion as to what the problem really is, so I have given up on that one. If the present solution happens to help, then fine.

John

--Boundary_(ID_xJ6yJLdOpGdVM69n6LHOBw)-- --===============1902669150== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============1902669150==-- From sipping-bounces@ietf.org Tue Jun 07 07:49:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfcaf-0002Gb-U0; Tue, 07 Jun 2005 07:49:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfcad-0002GW-Jf for sipping@megatron.ietf.org; Tue, 07 Jun 2005 07:49:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14349 for ; Tue, 7 Jun 2005 07:49:50 -0400 (EDT) Received: from [202.54.64.17] (helo=hclnpd.hclt-ntl.co.in) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dfcvg-0000dr-8W for sipping@ietf.org; Tue, 07 Jun 2005 08:11:36 -0400 Received: from npd-mail1.hclt-ntl.co.in ([10.105.1.106]) by hclnpd.hclt-ntl.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id K82658FZ; Tue, 7 Jun 2005 17:19:40 +0530 X-MessageTextProcessor: DisclaimIt (2.50.252) [HCL Technologies Ltd., Chennai, India] Content-Class: urn:content-classes:message Received: from npd-mail.hclt-ntl.co.in ([10.105.1.104]) by npd-mail1.hclt-ntl.co.in with Microsoft SMTPSVC(5.0.2195.6713); Tue, 7 Jun 2005 17:19:39 +0530 Received: by npd-mail.hclt-ntl.co.in with Internet Mail Service (5.5.2657.72) id ; Tue, 7 Jun 2005 17:19:39 +0530 Message-ID: <4B1D6623CCBD79489DE28D1CA062A47EF524D3@npd-mail.hclt-ntl.co.in> From: "Prakash Maria susai - NPD, Chennai" To: , Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Jun 2005 17:19:38 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-OriginalArrivalTime: 07 Jun 2005 11:49:39.0842 (UTC) FILETIME=[FC8D8620:01C56B56] X-Spam-Score: 0.3 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Sipping] Clarifications sought on STUN X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Hi All, I have made some assumptions on the STUN client protocol. I would like to clarify if they are correct. Below are the assumptions: 1) On Shared Secret Request(SSR): The username, password from the Response got for ONE shared secret request, can be used for ANY number of subsequent Binding Requests(BR). = This credential can be used till a 430 response is got for a BR. In other words, a single SSR transaction is enough for sending many BRs, = if the credential at the STUN server has not expired. 2) When 430 response for a BR is got, then a new SSR had to be sent, and = a username-password got from that, can be used for further BRs. 3) A single STUN client can be used by multiple applications, and the identifier that STUN provides for matching the responses to different applications is the Transaction-ID. 4) Multiple BRs can be sent simultaneously from a STUN client, and the = STUN client must be able to demultiplex the responses got for the different = BRs from the STUN server. 5) On Binding response handling: Acc. to "ietf-behave-rfc3489bis-01", a STUN client, even after it = receives a 200 Response, has to wait for 10 seconds for any additional responses, = and then terminate the transaction. If so, then will it take ATLEAST 10 secs,if STUN is used, before an = INVITE is sent? Quote from Section 9.4 of "ietf-behave-rfc3489bis-01": "Reception of a response to a Binding Request will terminate retransmissions of that request. However, clients MUST continue to = listen for responses to a Binding Request for 10 seconds after the first = response. If it receives any responses in this interval with different message types, different MAPPED-ADDRESSes, or different XOR-MAPPED-ADDRESSes, it = is an indication of a possible attack. The client MUST NOT use the MAPPED-ADDRESS or XOR-MAPPED-ADDRESS from any of the responses it = received (either the first or the additional ones), and SHOULD alert the user." If would be very helpful ,if anyone can clarify these. Please excuse me sending to both sipping and sip-implementors, since I = was not sure to which list to send. Thanks, Prakash. Disclaimer: This message and any attachment(s) contained here are information that = is confidential, proprietary to HCL Technologies and its customers, = privileged or otherwise protected by law. The information is solely = intended for the individual or the entity it is addressed to. If you are = not the intended recipient of this message, you are not authorized to = read, forward, print, retain, copy or disseminate this message or any = part of it. If you have received this e-mail in error, please notify the = sender immediately by return e-mail and delete it from your computer. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Tue Jun 07 10:31:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dff7Q-0007Cr-3i; Tue, 07 Jun 2005 10:31:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dff7M-0007BU-PF for sipping@megatron.ietf.org; Tue, 07 Jun 2005 10:31:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28419 for ; Tue, 7 Jun 2005 10:31:44 -0400 (EDT) Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DffSL-0004Lt-JA for sipping@ietf.org; Tue, 07 Jun 2005 10:53:32 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IHP00D01XKG5N@siemenscomms.co.uk> for sipping@ietf.org; Tue, 07 Jun 2005 15:29:04 +0100 (BST) Received: from ntht206e.siemenscomms.co.uk ([137.223.247.52]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IHP00C1UXK2IL@siemenscomms.co.uk> for sipping@ietf.org; Tue, 07 Jun 2005 15:28:50 +0100 (BST) Received: by ntht206e.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 07 Jun 2005 15:31:05 +0100 Content-return: allowed Date: Tue, 07 Jun 2005 15:30:56 +0100 From: "Elwell, John" To: sipping@ietf.org Message-id: <50B1CBA96870A34799A506B2313F2667059ECF47@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.6 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [Sipping] draft-elwell-sip-session-retention-00.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1517071606==" Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org 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. --===============1517071606== Content-return: allowed Content-type: multipart/alternative; boundary="Boundary_(ID_MgERPTEPMqZ3SjFdSUbjHQ)" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_MgERPTEPMqZ3SjFdSUbjHQ) Content-type: text/plain Content-Transfer-Encoding: 7BIT http://www.ietf.org/internet-drafts/draft-elwell-sip-session-retention-00.tx t This draft was posted back in February, but probably got submerged in the rush leading to IETF61. I would appreciate any feedback as to whether this would be an interesting subject to pursue. Abstract: This document proposes a method or retaining a session when a SIP dialog between two UAs is replaced by another dialog between those same two UAs in order to update dialog-related information such as identity. John --Boundary_(ID_MgERPTEPMqZ3SjFdSUbjHQ) Content-type: text/html Content-Transfer-Encoding: 7BIT draft-elwell-sip-session-retention-00.txt

http://www.ietf.org/internet-drafts/draft-elwell-sip-session-retention-00.txt

This draft was posted back in February, but probably got submerged in the rush leading to IETF61. I would appreciate any feedback as to whether this would be an interesting subject to pursue.

Abstract:
This document proposes a method or retaining a session when a SIP dialog between two UAs is replaced by another dialog between those same two UAs in order to update dialog-related information such as identity.

John

--Boundary_(ID_MgERPTEPMqZ3SjFdSUbjHQ)-- --===============1517071606== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============1517071606==-- From sipping-bounces@ietf.org Tue Jun 07 10:48:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DffN7-0001mP-RD; Tue, 07 Jun 2005 10:48:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DffN5-0001if-Fw for sipping@megatron.ietf.org; Tue, 07 Jun 2005 10:48:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29989 for ; Tue, 7 Jun 2005 10:48:01 -0400 (EDT) Received: from furball.foretec.com ([132.151.15.110] helo=foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DffiA-0004my-5w for sipping@ietf.org; Tue, 07 Jun 2005 11:09:50 -0400 Received: from localhost ([127.0.0.1] helo=furball.foretec.com) by foretec.com with esmtp (Exim 4.30) id 1DffN3-0001p9-V0; Tue, 07 Jun 2005 10:48:01 -0400 Received: from 10.27.16.5 (SquirrelMail authenticated user ids) by furball.foretec.com with HTTP; Tue, 7 Jun 2005 10:48:01 -0400 (EDT) Message-ID: <1974.10.27.16.5.1118155681.squirrel@furball.foretec.com> In-Reply-To: <79B4F738DDD4EF4F85A4641A0FE5EFD6FD9A08@aclmsg.corp.audiocodes.com> References: <79B4F738DDD4EF4F85A4641A0FE5EFD6FD9A08@aclmsg.corp.audiocodes.com> Date: Tue, 7 Jun 2005 10:48:01 -0400 (EDT) Subject: RE: [Sipping] I-D ACTION:draft-ietf-sipping-transc-conf-00.txt From: internet-drafts@ietf.org To: "Nachum Frid" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 1.1 (+) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 8bit Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org This has to be approved by the wg chairs. Thanks. > > I suggest to mention in the draft that there are several ways to make > the two party conference, and not only according to > "draft-ietf-sipping-uri-list-conferencing-02" . > The basic two party conference (that can be used to invoke transcoding > service) can be established by sending two INVITEs to conference server > with same conference URI as described in > "draft-ietf-sipping-conferencing-framework-05", > "draft-burger-sipping-netann-11" and in > "draft-ietf-sipping-cc-conferencing-06" par 4.1 (Dial in conference). > > Nachum > AudioCodes > > > > -----Original Message----- > From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On > Behalf Of Internet-Drafts@ietf.org > Sent: Friday, June 03, 2005 10:56 PM > To: i-d-announce@ietf.org > Cc: sipping@ietf.org > Subject: [Sipping] I-D ACTION:draft-ietf-sipping-transc-conf-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Session Initiation Proposal > Investigation Working Group of the IETF. > > Title : The Session Initiation Protocol (SIP) > Conference > Bridge Transcoding Model > Author(s) : G. Camarillo > Filename : draft-ietf-sipping-transc-conf-00.txt > Pages : 10 > Date : 2005-6-3 > > This document describes how to invoke transcoding services using the > conference bridge model. This way of invocation meets the > requirements for SIP regarding transcoding services invocation to > support deaf, hard of hearing and speech-impaired individuals. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipping-transc-conf-00.tx > t > > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Tue Jun 07 11:03:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DffcL-0004zt-CO; Tue, 07 Jun 2005 11:03:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DffcI-0004zk-VJ for sipping@megatron.ietf.org; Tue, 07 Jun 2005 11:03:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00937 for ; Tue, 7 Jun 2005 11:03:44 -0400 (EDT) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DffxM-00056H-8e for sipping@ietf.org; Tue, 07 Jun 2005 11:25:33 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by delivery_mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1B897390023; Tue, 7 Jun 2005 17:03:42 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by outbound_mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EAC284F0001; Tue, 7 Jun 2005 17:03:41 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 7 Jun 2005 17:03:41 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 7 Jun 2005 17:03:40 +0200 Received: from [131.160.37.196] (EFO9N000L5C7100.lmf.ericsson.se [131.160.37.196]) by mail.lmf.ericsson.se (Postfix) with ESMTP id A37DC2528; Tue, 7 Jun 2005 18:03:40 +0300 (EEST) Message-ID: <42A5B74C.9040005@ericsson.com> Date: Tue, 07 Jun 2005 18:03:40 +0300 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nachum Frid Subject: Re: [Sipping] I-D ACTION:draft-ietf-sipping-transc-conf-00.txt References: <79B4F738DDD4EF4F85A4641A0FE5EFD6FD9A08@aclmsg.corp.audiocodes.com> In-Reply-To: <79B4F738DDD4EF4F85A4641A0FE5EFD6FD9A08@aclmsg.corp.audiocodes.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2005 15:03:40.0998 (UTC) FILETIME=[1738F660:01C56B72] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Nachum, note that comments on the drafts should be sent only to the SIPPING mailing list (and to the authors), not to the Internet-Drafts email address. That's why they responded saying that they cannot edit documents directly. Anyway, I will make sure to clarify this point in the next revision of the draft. Thanks for your comments, Gonzalo Nachum Frid wrote: > I suggest to mention in the draft that there are several ways to make > the two party conference, and not only according to > "draft-ietf-sipping-uri-list-conferencing-02" . > The basic two party conference (that can be used to invoke transcoding > service) can be established by sending two INVITEs to conference server > with same conference URI as described in > "draft-ietf-sipping-conferencing-framework-05", > "draft-burger-sipping-netann-11" and in > "draft-ietf-sipping-cc-conferencing-06" par 4.1 (Dial in conference). > > Nachum > AudioCodes > > > > -----Original Message----- > From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On > Behalf Of Internet-Drafts@ietf.org > Sent: Friday, June 03, 2005 10:56 PM > To: i-d-announce@ietf.org > Cc: sipping@ietf.org > Subject: [Sipping] I-D ACTION:draft-ietf-sipping-transc-conf-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Session Initiation Proposal > Investigation Working Group of the IETF. > > Title : The Session Initiation Protocol (SIP) > Conference > Bridge Transcoding Model > Author(s) : G. Camarillo > Filename : draft-ietf-sipping-transc-conf-00.txt > Pages : 10 > Date : 2005-6-3 > > This document describes how to invoke transcoding services using the > conference bridge model. This way of invocation meets the > requirements for SIP regarding transcoding services invocation to > support deaf, hard of hearing and speech-impaired individuals. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipping-transc-conf-00.tx > t > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Wed Jun 08 09:44:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg0r0-0006rR-V8; Wed, 08 Jun 2005 09:44:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg0qw-0006r0-F8 for sipping@megatron.ietf.org; Wed, 08 Jun 2005 09:44:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28573 for ; Wed, 8 Jun 2005 09:44:16 -0400 (EDT) Received: from p04.nexlink.net ([80.86.195.80]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dg1C9-0004Lr-TP for sipping@ietf.org; Wed, 08 Jun 2005 10:06:17 -0400 Received: (qmail 7253 invoked from network); 8 Jun 2005 13:40:38 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 8 Jun 2005 13:40:38 -0000 Received: from d80-170-48-195.cust.tele2.fr (d80-170-48-195.cust.tele2.fr [80.170.48.195]) by webmail.tech-invite.com (IMP) with HTTP for ; Wed, 8 Jun 2005 15:40:38 +0200 Message-ID: <1118238038.42a6f556251f8@webmail.tech-invite.com> Date: Wed, 8 Jun 2005 15:40:38 +0200 From: =?iso-8859-1?b?Sm/rbA==?= Repiquet To: sipping@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 80.170.48.195 X-Spam-Score: 0.4 (/) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA28573 Cc: alan.johnston@mci.com, sdonovan@dynamicsoft.com, ccunningham@dynamicsoft.com, rsparks@dynamicsoft.com, kevin.summers@sonusnet.com Subject: [Sipping] Questions and remarks on service-examples-08 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Hi, In the perspective of service-examples-09, here is a recollection in this quite long message, example by example, of a number of mismatches (related to tags, URIs...) that I have noticed for all the cases in service-examples-08. Prior to this, I have two questions: 1) The "Allow" and "Supported" fields are not applicable to ACK requests (tables 2 and 3 of RFC3261) but this occur so many times in the examples that I am wondering whether I am right. Do you confirm? 2) All 200 OK responses (but one) to CANCEL requests do not contain a tag (the Request's one) in the From field. This is an omission, BUT: none of these 200 OK responses have a tag in the To field. However, at the end of RFC3261 =A79.2, it is mentioned that: "This response is constructed following the procedures described in Section 8.2.6 noting that the To tag of the response to the CANCEL and the To tag in the response to the original request SHOULD be the same." As a result, the To tag in the 200 OK response to a CANCEL should be the To tag of the 180 Ringing / 200 OK responses to the request that is cancelled. I have checked the examples in RFC3665 and RFC3666 and responses to CANCEL requests do not have a To tag either! Have I missed something? Here are the corrections I have noticed in each example: 2.1 Call Hold -------------- Allow and Supported fields to be removed in F8/F9, F14/F15, F20/F21 2.2 Consultation Hold ---------------------- Allow and Supported fields to be removed in F8/F9, F14, F23/F24, F33/F34 2.3 Music On Hold ----------------- Allow and Supported fields to be removed in F4, F9/F10, F15 p.34: "with hold SDP" duplicated p.37, F6: "Carol -> Bob" to be replaced by "Music Server -> Bob" F7: "atlanta" to be replaced by "biloxi" in "o=3D" SDP field p.38, F8: "bob" to be replaced by "alice" in Contact field p.40, F14: "bob" to be replaced by "alice" in Contact field 2.4 Transfer - Unattended ------------------------- Allow and Supported fields to be removed in F4 p.42, in the time-diagram: F15 and F16 for the two last messages instead of F14 and F15 and in the text below: F14 to be replaced by F15 (twice) p.44: "Alice peforms" -> "Alice performs" F5: "1 REFER" instead of "2 REFER" (very likely) p.45, F6: "1 REFER" instead of "2 REFER" F9: "2 BYE" instead of "3 BYE" p.46, F10: "2 BYE" instead of "3 BYE" 2.5 Transfer - Attended ------------------------- Allow and Supported fields to be removed in F4, F21 p.56, F16: "tag=3D1234567" to be replaced by "tag=3D23431" in From field "tag=3D23431" to be replaced by "tag=3D1234567" in To field p.57, F17: Alice should be mentioned in the Contact field, instead of Bob p.57, F18: "Bob -> Alice" instead of "Bob -> Carol" The following fields: To: Bob ;tag=3D1234567 From: Carol ;tag=3D5f35a3 to be replaced by: To: Bob ;tag=3D23431 From: Alice ;tag=3D1234567 p.58, F20: "carol" instead of "alice" in "o=3D" SDP field p.58, F21: "1 ACK" instead of "1 INVITE" in CSeq field p.59, F24: the message body is an excerpt of F20 (I believe) and as a result, the To, From, Call-ID and Contact fields should be: To: Carol ;tag=3Dff3a From: Alice ;tag=3D3461 Call-ID: 9435674543@atlanta.example.com Contact: instead of: From: Carol ;tag=3Dff3a To: Alice ;tag=3D3461 Call-ID: 9435674543@chicago.example.com Contact: p.60, F25: "Bob -> Alice" instead of "Bob -> Carol" and the To and From fields should be: From: Alice ;tag=3D1234567 To: Bob ;tag=3D23431 instead of: From: Carol ;tag=3D5f35a3 To: Bob ;tag=3D1234567 2.6 Transfer - Instant Messaging -------------------------------- Allow and Supported fields to be removed in F4 p.62, F1: in the Request-URI and the To field: "bob@biloxi.example.com" instead of "bob@client.biloxi.example.com" p.63, F5: the line 12345600@atlanta.example.com%3Bfrom-tag%3D314159%3Bto-tag%3D12345= 67"> to be repaced by: 12345600@atlanta.example.com%3Bfrom-tag%3D1234567%3Bto-tag%3D3145= 678"> p.64, F7, in the Replaces field: "to-tag=3D314578" to be replaced by "to-tag=3D3145678" p.64, F7, in the SDP "o=3D": "Carol" instead of "Bob" Q: in F7, the tag field in the From field (8675309) is the same as in F6. is there a relationship? p.65, F10: the line: BYE sips:carol@client.example.com SIP/2.0 to be replaced by: BYE sips:bob@client.biloxi.example.com SIP/2.0 p.65, F10 and p.66, F11: the lines: To: Bob ;tag=3D8675309 From: Alice ;tag=3D131256 Call-ID: 563456212@b2.biloxi.example.com to be replaced by: From: Alice ;tag=3D1234567 To: Bob ;tag=3D3145678 Call-ID: 12345600@atlanta.example.com 2.7 Call Forwarding Unconditional --------------------------------- p.71, F11: The Route field should be: Route: i.e. the same as in F9 p.70,71, F11 to F14: "Proxy" instead of "Proxy 1" 2.8 Call Forwarding - Busy -------------------------- p.77, F12: add the fields CSeq: 1 ACK Content-Length: 0 2.9 Call Forwarding - No Answer -------------------------------- p.82, F7: add ";tag=3D1234567" to From field add ";tag=3D3145678" to To field 2.10 3-way Conference - Third Party is Added --------------------------------------------- p.89, F5: I believe the "a=3Dsendonly" is irrelevant (otherwise the diagram on p.87 is to be updated). Maybe the fact that the port is modified should be commented. p.90, F6: Accordingly, the "a=3Drecvonly" is irrelevant and the version number should not be incremented 2.11 3-way Conference - Third Party Joins ------------------------------------------ Allow and Supported fields to be removed in F11 p.98, F11: "Carol -> Bob" instead of "Bob -> Carol" 2.12 Single Line Extension --------------------------- p.106, F15: add ";tag=3D1234567" to From field add ";tag=3D765432" to To field p.110, F27: "F27 482 Loop Detected" instead of "F27 200 OK" p.111-113, F28-F31: in the Join field: "to-tag=3D7137136" instead of "765432" p.115, F38: "Proxy -> User B2" instead of "User B3 -> Proxy" 2.13 Find-Me ------------- p.119, F7: add ";tag=3D1234567" to From field add ";tag=3D765432" to To field p.123, F18: "Proxy -> Alice" instead of "B4 -> Proxy" 2.14 Call Management (Incoming Call Screening) ----------------------------------------------- p.131-133: "announcement" instead of "annoucement" p.132-133: F12 and F13: in Contact field: "" instead of: p.133, F15: in the BYE command line: "alice@client.atlanta.example.com" instead of "alice@client.Atlanta.com" 2.15 Call Management (Outgoing Call Screening) ----------------------------------------------- p.136, F5: in the Error-Info field: "announcement" instead of "annoucement" 2.16 Call Park --------------- Allow and Supported fields to be removed in F4 p.142, F10 and F11 in the To field, "Alice " to be removed p.143, F14 in the CSeq field: "2 NOTIFY" instead of "1 NOTIFY" in the Content: "Alice " to be removed from the To field "1 INVITE" instead of "2 INVITE" in the CSeq field 2.17 Call Pickup ----------------- p.149, F6 and F7: the "To" tag in F6 and the "From" tag in F7 is the same (8675309). This may be ambiguous since there is no correlation. p.150, F7: in the "o=3D" field maybe it is "Bill" instead of "Bob" p.119, F10: add ";tag=3D3145678" to To field p.153, F16: "Alice -> Bill" instead of "Alice -> Bob" in the BYE command line: "sips:carol@biloxi.example.com" to be replaced by: "sips:bill@pc.biloxi.example.com" "1 BYE" instead of "2 BYE" p.153, F17: "Bill -> Alice" instead of "Bob -> Alice" "1 BYE" instead of "2 BYE" 2.18 Automatic Redial ---------------------- p.155, F3: "ACK" instead of "INVITE" in the command line p.156, F5: ";tag=3D341123" missing in the To field, in the Contact field: "bob" instead of "alice" 2.19 Click to Dial ------------------- p.161, F3: "Bob -> PC" instead of "Bob -> Alice" in the NOTIFY command line "pc" instead of "alice" p.161, F4: "PC -> Bob" instead of "Alice -> Bob" p.161, F5: in the Referred-By field: "pc.biloxi.example.com" instead of "alice@atlanta.example.com" Best Regards Jo=EBl Repiquet ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Thu Jun 09 07:31:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgLFq-00035H-Oh; Thu, 09 Jun 2005 07:31:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgLFo-000357-T1 for sipping@megatron.ietf.org; Thu, 09 Jun 2005 07:31:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14792 for ; Thu, 9 Jun 2005 07:31:19 -0400 (EDT) Received: from usaga01-in.huawei.com ([63.250.163.245] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgLae-0004wI-5d for sipping@ietf.org; Thu, 09 Jun 2005 07:53:00 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IHT00J76EGQY4@usaga01-in.huawei.com> for sipping@ietf.org; Thu, 09 Jun 2005 04:26:50 -0700 (PDT) Received: from huawei.com ([172.17.1.188]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IHT00HXNEGPJ6@usaga01-in.huawei.com> for sipping@ietf.org; Thu, 09 Jun 2005 04:26:50 -0700 (PDT) Received: from [172.24.1.3] (Forwarded-For: [10.18.3.138]) by szxmc01-in.huawei.com (mshttpd); Thu, 09 Jun 2005 16:30:55 +0500 Date: Thu, 09 Jun 2005 16:30:55 +0500 From: DarshanBildikar 70559 To: sipping@ietf.org Message-id: <15725c1156fe0b.156fe0b15725c1@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7BIT Subject: [Sipping] Expires header in INVITE X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Is there any way for a stateful proxy (e.g. a soft switch) to determine the end of a session. This could be useful in certain prepaid applications wherein a call can go on for only a specified amount of time or in the case of error scenarios where the connection between the B2BUA and switch is broken. Could the Expires Header be applied to an INVITE dialog as it is to REGISTER and SUBSCRIBE? Header field where proxy ACK BYE CAN INV OPT REG Expires - - - o - o According to the RFC the Expires header can be used with the INVITE and 200 OK messages. Is there a problem with this? Darshan There was a draft draft-ietf-sip-session-timer-00.txt (Oct 99) that addressed the above problem. ****************************************************************************************** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ***************************************************************************************** _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Thu Jun 09 07:58:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgLgK-0001Y3-E1; Thu, 09 Jun 2005 07:58:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgLg9-0001Wy-5B for sipping@megatron.ietf.org; Thu, 09 Jun 2005 07:58:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18528 for ; Thu, 9 Jun 2005 07:58:32 -0400 (EDT) Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgM1a-0006Xe-Iv for sipping@ietf.org; Thu, 09 Jun 2005 08:20:43 -0400 Received: from sonustxmail01.sonusnet.com (sonustxmail01.sonusnet.com [10.10.100.52]) by sonussf1.sonusnet.com (8.13.1/8.13.1) with ESMTP id j59BwAON026929; Thu, 9 Jun 2005 07:58:10 -0400 Received: from SONUSINMAIL01.sonusnet.com ([10.128.254.7]) by sonustxmail01.sonusnet.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 9 Jun 2005 06:58:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message Subject: RE: [Sipping] Expires header in INVITE MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Jun 2005 17:28:04 +0530 Message-ID: <70798CF421F00F4DA018059E5B7EEB8C021CAE@sonusinmail01.sonusnet.com> Thread-Topic: [Sipping] Expires header in INVITE Thread-Index: AcVs5+wvLBcz7JiMS8+CalW52fuRtgAAm4bQ From: "Nayak, Subhash" To: "DarshanBildikar 70559" , X-OriginalArrivalTime: 09 Jun 2005 11:58:10.0196 (UTC) FILETIME=[8192DD40:01C56CEA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Session Timer is the mechanism you're looking for. It's now RFC 4028. Subhash Nayak Sonus Networks Inc. http://www.sonusnet.com -----Original Message----- From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf Of DarshanBildikar 70559 Sent: Thursday, June 09, 2005 5:01 PM To: sipping@ietf.org Subject: [Sipping] Expires header in INVITE Is there any way for a stateful proxy (e.g. a soft switch) to determine the end of a session. This could be useful in certain prepaid applications wherein a call can go on for only a specified amount of time or in the case of error scenarios where the connection between the B2BUA and switch is broken. Could the Expires Header be applied to an INVITE dialog as it is to REGISTER and SUBSCRIBE?=20 Header field where proxy ACK BYE CAN INV OPT REG Expires - - - o - o According to the RFC the Expires header can be used with the INVITE and 200 OK messages. Is there a problem with this?=20 Darshan There was a draft draft-ietf-sip-session-timer-00.txt (Oct 99) that addressed the above problem.=20 ************************************************************************ ****************** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! =20 ************************************************************************ ***************** _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Thu Jun 09 08:18:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgLzk-000846-0z; Thu, 09 Jun 2005 08:18:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgLzh-000841-VP for sipping@megatron.ietf.org; Thu, 09 Jun 2005 08:18:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21120 for ; Thu, 9 Jun 2005 08:18:44 -0400 (EDT) Received: from mailgate2.nl.thalesgroup.com ([193.67.31.101] helo=mailgate2.signaal.nl) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgML5-0007hB-4F for sipping@ietf.org; Thu, 09 Jun 2005 08:40:56 -0400 Received: from mta1.nl.thales (mta1.signaal.local [193.67.31.130]) by mailgate2.signaal.nl (4.8.1.149) with ESMTP id for ; Thu, 9 Jun 2005 14:17:12 +0200 (MEST) Received: from suna900.sc.signaal.nl (suna900.sc.signaal.nl [192.7.99.164]) by mta1.nl.thales (4.9.7.3) with ESMTP id tibb0AAK for ; Thu, 9 Jun 2005 14:16:55 +0200 (MEST) Received: from scms1.sc.signaal.nl ([192.7.99.212]) by suna900.sc.signaal.nl (Netscape Messaging Server 3.6) with ESMTP id AAA263C for ; Thu, 9 Jun 2005 14:16:50 +0200 Received: from scd01-MTA by scms1.sc.signaal.nl with Novell_GroupWise; Thu, 09 Jun 2005 14:15:47 +0200 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.4 Date: Thu, 09 Jun 2005 14:15:15 +0200 From: "Samuel Osorio Calvo" To: , Subject: Re: [Sipping] Expires header in INVITE MIME-Version: 1.0 (Generated by Clearswift ES version 4.8.1.149) Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.2 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org >From what I understand, there are two scenarios you want to cover: a) pre-paid b)connection error The first scenario requires the presence of a B2BUA which will set up an = internal timer and close the connection if no extra credit is provided. = Since B2BUA implementation is left up to the programmer, the way you set = up the timer is up to you.=20 For the second scenario, might be better to use session timers instead of = Expires header. There's a recent RFC called "Session Timers in the Session = Initiation Protocol (SIP)"(I'm sorry but I don't have the number right = here) which covers the error scenario for proxies. Hope it helps, Samuel. Unclassified. >>> DarshanBildikar 70559 06/09/05 01:30PM >>> Is there any way for a stateful proxy (e.g. a soft switch) to determine = the end of a session. This could be useful in certain prepaid applications = wherein a call can go on for only a specified amount of time or in the = case of error scenarios where the connection between the B2BUA and switch = is broken. Could the Expires Header be applied to an INVITE dialog as it is to = REGISTER and SUBSCRIBE?=20 Header field where proxy ACK BYE CAN INV OPT REG Expires - - - o - o According to the RFC the Expires header can be used with the INVITE and = 200 OK messages. Is there a problem with this?=20 Darshan There was a draft draft-ietf-sip-session-timer-00.txt (Oct 99) that = addressed the above problem.=20 ***************************************************************************= *************** This email and its attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is = listed above. Any use of the information contained herein in any way = (including, but not limited to, total or partial disclosure, reproduction, = or dissemination) by persons other than the intended recipient(s) is = prohibited. If you receive this e-mail in error, please notify the sender = by phone or email immediately and delete it! **************************************************************************= *************** _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping=20 This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Thu Jun 09 09:00:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgMdl-00006r-0u; Thu, 09 Jun 2005 09:00:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgMdh-000067-S3 for sipping@megatron.ietf.org; Thu, 09 Jun 2005 09:00:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25387 for ; Thu, 9 Jun 2005 09:00:04 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgMz7-0001CC-Q4 for sipping@ietf.org; Thu, 09 Jun 2005 09:22:17 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 09 Jun 2005 08:59:54 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j59CuCNU001815; Thu, 9 Jun 2005 08:59:40 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Jun 2005 08:58:54 -0400 Received: from [192.168.1.100] ([10.86.242.4]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Jun 2005 08:58:54 -0400 Message-ID: <42A83D0D.6040701@cisco.com> Date: Thu, 09 Jun 2005 08:58:53 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: DarshanBildikar 70559 Subject: Re: [Sipping] Expires header in INVITE References: <15725c1156fe0b.156fe0b15725c1@huawei.com> In-Reply-To: <15725c1156fe0b.156fe0b15725c1@huawei.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jun 2005 12:58:54.0433 (UTC) FILETIME=[FDB54D10:01C56CF2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org The Expires header in an INVITE refers to how long the *invitation* is good for, not how long the *session* is good for. -Jonathan R. DarshanBildikar 70559 wrote: > Is there any way for a stateful proxy (e.g. a soft switch) to > determine the end of a session. This could be useful in certain > prepaid applications wherein a call can go on for only a specified > amount of time or in the case of error scenarios where the connection > between the B2BUA and switch is broken. > > Could the Expires Header be applied to an INVITE dialog as it is to > REGISTER and SUBSCRIBE? > > Header field where proxy ACK BYE CAN INV OPT REG Expires > - - - o - o > > According to the RFC the Expires header can be used with the INVITE > and 200 OK messages. Is there a problem with this? > > Darshan > > There was a draft draft-ietf-sip-session-timer-00.txt (Oct 99) that > addressed the above problem. > > > > ****************************************************************************************** > This email and its attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose address > is listed above. Any use of the information contained herein in any > way (including, but not limited to, total or partial disclosure, > reproduction, or dissemination) by persons other than the intended > recipient(s) is prohibited. If you receive this e-mail in error, > please notify the sender by phone or email immediately and delete it! > > ***************************************************************************************** > > > > _______________________________________________ Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW > development of the application of SIP Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sip@ietf.org for new developments of core SIP > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Thu Jun 09 10:09:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgNjC-00082h-Kx; Thu, 09 Jun 2005 10:09:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgNjB-00082Z-Aj for sipping@megatron.ietf.org; Thu, 09 Jun 2005 10:09:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03925 for ; Thu, 9 Jun 2005 10:09:47 -0400 (EDT) Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgO4c-00053n-FX for sipping@ietf.org; Thu, 09 Jun 2005 10:32:01 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j59E9g9x015198 for ; Thu, 9 Jun 2005 17:09:44 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Jun 2005 17:09:37 +0300 Received: from kusti.research.nokia.com ([172.21.56.13]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 9 Jun 2005 17:02:20 +0300 Received: from xitami.research.nokia.com (xitami.research.nokia.com [172.21.50.105]) by kusti.research.nokia.com (Postfix) with ESMTP id 54A8D93B6A for ; Thu, 9 Jun 2005 17:02:20 +0300 (EEST) Received: from hed034-145.research.nokia.com (hed034-145.research.nokia.com [172.21.34.145]) by xitami.research.nokia.com (Postfix) with ESMTP id 8C73F124 for ; Tue, 7 Jun 2005 13:09:38 +0300 (EEST) Subject: Re: [Sipping] I-D ACTION:draft-ietf-sipping-conference-package-11.txt From: Jari Urpalainen To: sipping@ietf.org In-Reply-To: <200506061947.PAA03524@ietf.org> References: <200506061947.PAA03524@ietf.org> Content-Type: text/plain Date: Tue, 07 Jun 2005 13:09:38 +0300 Message-Id: <1118138978.7620.8.camel@hed034-145.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jun 2005 14:02:20.0452 (UTC) FILETIME=[DA45B640:01C56CFB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org On Mon, 2005-06-06 at 15:47 -0400, ext Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. > > Title : A Session Initiation Protocol (SIP) Event Package > for Conference State > Author(s) : J. Rosenberg, et al. > Filename : draft-ietf-sipping-conference-package-11.txt > Pages : 48 > Date : 2005-6-6 > > This document defines a conference event package for the Session > Initiation Protocol (SIP) Events framework, along with a data format > used in notifications for this package. The conference package > allows users to subscribe to a conference URI. Notifications are > sent about changes in the membership of this conference and > optionally about changes in the state of additional conference > components. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipping-conference-package-11.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-sipping-conference-package-11.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 > Some minor comments concerning examples and XML schemas, There's not any xml-prolog declaration in examples (. Considering the fact that attributes are unqualified in the schema this declaration seems somewhat odd (or unusual). Also default value for processContents is strict. Therefore, changing these to would imo be more reasonable. Thanks, 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 sipping-bounces@ietf.org Thu Jun 09 15:29:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgSix-0002iZ-CS; Thu, 09 Jun 2005 15:29:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgSiw-0002iU-1h for sipping@megatron.ietf.org; Thu, 09 Jun 2005 15:29:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08038 for ; Thu, 9 Jun 2005 15:29:52 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgT4S-0004iJ-D7 for sipping@ietf.org; Thu, 09 Jun 2005 15:52:08 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Jun 2005 12:29:43 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Jun 2005 12:29:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] I-D ACTION:draft-ietf-sipping-conference-package-11.txt Date: Thu, 9 Jun 2005 12:29:43 -0700 Message-ID: Thread-Topic: [Sipping] I-D ACTION:draft-ietf-sipping-conference-package-11.txt Thread-Index: AcVs/WRmm/ceR9HlQZS8zxSP8rPuWgAK8O2g From: "Orit Levin" To: "Jari Urpalainen" , X-OriginalArrivalTime: 09 Jun 2005 19:29:43.0401 (UTC) FILETIME=[9661DD90:01C56D29] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Thanks a lot, Jari. I will fix these in the authors' 48 hours if the rest goes OK. Orit.=20 > -----Original Message----- > From: sipping-bounces@ietf.org=20 > [mailto:sipping-bounces@ietf.org] On Behalf Of Jari Urpalainen > Sent: Tuesday, June 07, 2005 3:10 AM > To: sipping@ietf.org > Subject: Re: [Sipping] I-D=20 > ACTION:draft-ietf-sipping-conference-package-11.txt >=20 > On Mon, 2005-06-06 at 15:47 -0400, ext=20 > Internet-Drafts@ietf.org wrote:=20 > > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > > This draft is a work item of the Session Initiation=20 > Proposal Investigation Working Group of the IETF. > >=20 > > Title : A Session Initiation Protocol (SIP)=20 > Event Package=20 > > for Conference State > > Author(s) : J. Rosenberg, et al. > > Filename : draft-ietf-sipping-conference-package-11.txt > > Pages : 48 > > Date : 2005-6-6 > > =09 > > This document defines a conference event package for the Session > > Initiation Protocol (SIP) Events framework, along with a=20 > data format > > used in notifications for this package. The conference package > > allows users to subscribe to a conference URI. Notifications are > > sent about changes in the membership of this conference and > > optionally about changes in the state of additional conference > > components. > >=20 > > A URL for this Internet-Draft is: > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-sipping-conference-pack > > age-11.txt > >=20 > > To remove yourself from the I-D Announcement list, send a=20 > message to=20 > > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of the message. > > You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > >=20 > >=20 > > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-ietf-sipping-conference-package-11.txt". > >=20 > > 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 > >=20 >=20 > Some minor comments concerning examples and XML schemas, > There's not any xml-prolog declaration in examples ( ..). Secondly > namespace declarations are missing from example instance documents > (xmlns=3D"urn:ietf:params:xml:ns:conference-info") and thus=20 > instance docs > don't validate. >=20 > In XML schemas there are attribute extensions namespace=3D"##other"/>. Considering the fact that attributes are > unqualified in the schema this declaration seems somewhat odd (or > unusual). Also default value for processContents is strict. Therefore, > changing these to =20 > would imo be > more reasonable. >=20 > Thanks, > Jari >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP >=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Fri Jun 10 14:55:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgoeu-0001wK-42; Fri, 10 Jun 2005 14:55:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgoes-0001vu-RC for sipping@megatron.ietf.org; Fri, 10 Jun 2005 14:55:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19955 for ; Fri, 10 Jun 2005 14:55:08 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgp0a-0006SC-J8 for sipping@ietf.org; Fri, 10 Jun 2005 15:17:37 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id 52A336C019 for ; Fri, 10 Jun 2005 14:55:03 -0400 (EDT) From: "Dale Worley" To: "Sipping (E-mail)" Date: Fri, 10 Jun 2005 14:53:51 -0400 Message-ID: <006701c56ded$bed27ef0$6a01010a@keywest> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: [Sipping] Inserting a B2BUA into an existing dialog X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org We are considering conference bridging applications, and it would be convenient to be able to insert the conference bridge (a B2BUA) into an existing dialog. It turns out that it's simple to *remove* the bridge from between two UAs, as it can send a REFER for an INVITE with Replaces to one of the UAs to get it to talk directly to the other UA. But I've not been able to figure out how to *insert* the bridge into an existing dialog. Has there been any work on this sort of thing? Thanks, Dale _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Fri Jun 10 15:08:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgory-0006Ba-MS; Fri, 10 Jun 2005 15:08:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgorw-00069K-Ow for sipping@megatron.ietf.org; Fri, 10 Jun 2005 15:08:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21391 for ; Fri, 10 Jun 2005 15:08:37 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgpDe-0001KE-1U for sipping@ietf.org; Fri, 10 Jun 2005 15:31:06 -0400 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j5AJ7PI23905; Fri, 10 Jun 2005 15:07:25 -0400 (EDT) Received: from [127.0.0.1] (acart23w.ca.nortel.com [47.130.25.60]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MRAFN1NB; Fri, 10 Jun 2005 15:08:18 -0400 Message-ID: <42A9E511.7050402@nortel.com> Date: Fri, 10 Jun 2005 15:08:01 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale Worley Subject: Re: [Sipping] Inserting a B2BUA into an existing dialog References: <006701c56ded$bed27ef0$6a01010a@keywest> In-Reply-To: <006701c56ded$bed27ef0$6a01010a@keywest> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: "Sipping \(E-mail\)" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org One method is for the conference initiator to use REFERs to get the bridge to dial out to all the participants. In the simplest case, if A is talking to B and wants to set up a conference, A sends an INVITE to the server C, then sends a REFER/Replaces->B to C to pick up the A-B dialogue. Dale Worley wrote: > We are considering conference bridging applications, and it would be > convenient to be able to insert the conference bridge (a B2BUA) into an > existing dialog. It turns out that it's simple to *remove* the bridge from > between two UAs, as it can send a REFER for an INVITE with Replaces to one > of the UAs to get it to talk directly to the other UA. But I've not been > able to figure out how to *insert* the bridge into an existing dialog. Has > there been any work on this sort of thing? > > Thanks, > > Dale > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Fri Jun 10 15:11:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgov9-0006cs-7T; Fri, 10 Jun 2005 15:11:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgov6-0006ch-1P for sipping@megatron.ietf.org; Fri, 10 Jun 2005 15:11:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21757 for ; Fri, 10 Jun 2005 15:11:54 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgpGn-00028F-TV for sipping@ietf.org; Fri, 10 Jun 2005 15:34:23 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id A9E6D6C019 for ; Fri, 10 Jun 2005 15:11:49 -0400 (EDT) From: "Dale Worley" To: "Sipping (E-mail)" Date: Fri, 10 Jun 2005 15:10:38 -0400 Message-ID: <006a01c56df0$169f3b80$6a01010a@keywest> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: 7bit Subject: [Sipping] Dialog event packages X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org We've started implementing call-control features that depend on the dialog event package, and it looks like some clarification and amendments are needed to the current I-D. I'm circulating a draft of my observations to see if anyone has any comments on them. Thanks, Dale ---------------------------------------------------------------------------- ---- Further clarifications needed regarding dialog event packages draft-ietf-sipping-dialog-package This is a discussion of some practical problems we have had implementing call control features in the sipX SIP PBX system, and improvements in the specification of dialog event packages that would help. 1. Local and remote elements Section 4.1.6 specifies that the event package shall contain "local" and "remote" elements containing identification of the endpoints of the dialog. E.g., sip:alice@example.com sip:bob@example.org A little though shows that the sensible way to populate these fields is: Field Value when Value when direction=initiator direction=recipient local identity From: value To: value in INVITE in INVITE local target Contact: value Contact: value in INVITE in 200 remote identity To: value From: value in INVITE in INVITE remote target Contact: value Contact: value in 200 in INVITE However, of the phone models we have tested, none provide all four of these values. One or more fields is either missing or duplicates another field. In order to make the dialog event package a useful source of information for call control processing, we need to standardize the use of these fields. 2. Meaning of request URI, or "resource", of SUBSCRIBE. The theory is that the request URI of the SUBSCRIBE request describes the "resource" to which the subscription applies. RFC 3265 discusses this in very general terms, but draft-ietf-sipping-dialog-package gives very little additional information. It seems intuitive that a subscription provides dialog event packages for dialogs to/from the same user as the request URI of the SUBSCRIBE. But the situation is probably more complicated than it seems -- what URI, exactly, is a dialog "to"? It seems in practice that phones pay attention to the user part of the resource URI, and match it with the user part of an incoming dialog's request URI, or with the an outgoing dialog's line identification. (And since most phones accept any incoming INVITE regardless of the user part, there is another case when the user part doesn't match any known line identification in the phone -- Most phones report those dialogs for any SUBSCRIBE.) (And should a SUBSCRIBE with no user part in its URI get information on all dialogs at that device? Does this really matter, since such a SUBSCRIBE cannot have been routed via a registration? OTOH, it could have been made using a contact URI from a dialog the phone participated in.) 3. The element. Section 4.1.6.2 defines the element of the element. It specifies that field-parameters from the target URIs should be split out and represented using elements separate from the URI: It can contain a list of Contact header parameters in param sub-elements (such as those defined in [10]). The param element contains two required attributes, pname and pval. Boolean parameters are represented by the explicit pval values "true" and "false" (for example when a feature parameter is explicitly negated). This method seems to me to be less desirable than an alternative scheme: It can contain a list of Contact header parameters in param sub-elements (such as those defined in [10]). The param element contains required attributes, pname, which gives the parameter name. If the parameter is present and has a value given, the pval attribute gives that value. If the parameter is present but has no "=value" part, the pval attribute is absent. For example, Contact: ;isfocus;class=personal;+sip.newparam would be represented: The advantage of this convention is that the UA that generates the dialog event package does not need to be aware of which parameters have Boolean type. And the list of parameters is extensible, so the UA cannot know that. We also need a clear statement of whether and how escaping is removed from the parameters. The only escaping mechanism available is if the parameter value (a "gen-value" in the grammar of RFC 3261) is a "quoted-string", which allows most characters to be escaped with "\". I would suggest that the pval attribute contains the un-escaped, un-quoted parameter value. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Fri Jun 10 15:16:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgozB-0008Ba-OQ; Fri, 10 Jun 2005 15:16:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgozA-0008BV-LO for sipping@megatron.ietf.org; Fri, 10 Jun 2005 15:16:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22305 for ; Fri, 10 Jun 2005 15:16:06 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.192]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgpKq-0003Tf-JO for sipping@ietf.org; Fri, 10 Jun 2005 15:38:35 -0400 Received: by wproxy.gmail.com with SMTP id 40so129054wri for ; Fri, 10 Jun 2005 12:15:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZghgJCtoIgQ/N9Fcsf0DUKRL5yV/oEuOlA7oVY3Qvsa1fW1H6TzOu0mDd3EPp18WmLNGYv/ruyFJ5rEQ8rvivvHxYg92QQhkKdwsUgCd3uSSx0lh/cYNPXOdAX/c5bhCHSnevS0vI4yqtM4pidYHUhrJdvWv3bOosI4cpGJjnls= Received: by 10.54.20.40 with SMTP id 40mr104294wrt; Fri, 10 Jun 2005 12:15:56 -0700 (PDT) Received: by 10.54.17.77 with HTTP; Fri, 10 Jun 2005 12:15:56 -0700 (PDT) Message-ID: Date: Fri, 10 Jun 2005 15:15:56 -0400 From: Arjun Roychowdhury To: Dale Worley Subject: Re: [Sipping] Inserting a B2BUA into an existing dialog In-Reply-To: <006701c56ded$bed27ef0$6a01010a@keywest> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <006701c56ded$bed27ef0$6a01010a@keywest> X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: "Sipping \(E-mail\)" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Arjun Roychowdhury List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Dale, depending on how you want your conference to begin, one of the several scenarios listed in draft-ietf-sipping-cc-conferencing-06.txt may help. For example, section 4.10 is one mechanism=20 regds arjun On 6/10/05, Dale Worley wrote: > We are considering conference bridging applications, and it would be > convenient to be able to insert the conference bridge (a B2BUA) into an > existing dialog. It turns out that it's simple to *remove* the bridge fr= om > between two UAs, as it can send a REFER for an INVITE with Replaces to on= e > of the UAs to get it to talk directly to the other UA. But I've not been > able to figure out how to *insert* the bridge into an existing dialog. H= as > there been any work on this sort of thing? >=20 > Thanks, >=20 > Dale >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP >=20 --=20 Arjun Roychowdhury _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Fri Jun 10 16:09:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgpp8-00063m-1U; Fri, 10 Jun 2005 16:09:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgpp5-00062Q-Bf for sipping@megatron.ietf.org; Fri, 10 Jun 2005 16:09:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07098 for ; Fri, 10 Jun 2005 16:09:44 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgqAm-0000ZM-J1 for sipping@ietf.org; Fri, 10 Jun 2005 16:32:15 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 10 Jun 2005 13:09:32 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5AK8XNe017623; Fri, 10 Jun 2005 16:09:29 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Jun 2005 16:09:27 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Jun 2005 16:09:27 -0400 Message-ID: <42A9F377.5070600@cisco.com> Date: Fri, 10 Jun 2005 16:09:27 -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: Dale Worley Subject: Re: [Sipping] Inserting a B2BUA into an existing dialog References: <006701c56ded$bed27ef0$6a01010a@keywest> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jun 2005 20:09:27.0451 (UTC) FILETIME=[4DCCC6B0:01C56DF8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: "Sipping \(E-mail\)" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Dale Worley wrote: > We are considering conference bridging applications, and it would be > convenient to be able to insert the conference bridge (a B2BUA) into an > existing dialog. It turns out that it's simple to *remove* the bridge from > between two UAs, as it can send a REFER for an INVITE with Replaces to one > of the UAs to get it to talk directly to the other UA. But I've not been > able to figure out how to *insert* the bridge into an existing dialog. Has > there been any work on this sort of thing? Who is doing the inserting? If A is talking to B but would like to use a bridge, it just creates a focus F, establishes its own dialog and media stream between A and F, and then sends a REFER/Replacing to F referring to its dialog with B. Of course A must also locally manage the way it manages its media to coordinate the handoff from the old media stream with B to the new one with F. Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Fri Jun 10 19:39:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgt5c-0001jp-5E; Fri, 10 Jun 2005 19:39:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgt5a-0001jc-4E for sipping@megatron.ietf.org; Fri, 10 Jun 2005 19:39:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25009 for ; Fri, 10 Jun 2005 19:38:58 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgtRL-00035p-9T for sipping@ietf.org; Fri, 10 Jun 2005 20:01:31 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 10 Jun 2005 19:38:53 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5ANapNY006914; Fri, 10 Jun 2005 19:37:17 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Jun 2005 19:32:51 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Jun 2005 19:32:50 -0400 Message-ID: <42AA2320.6090507@cisco.com> Date: Fri, 10 Jun 2005 19:32:48 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale Worley Subject: Re: [Sipping] Dialog event packages References: <006a01c56df0$169f3b80$6a01010a@keywest> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jun 2005 23:32:50.0931 (UTC) FILETIME=[B7A40C30:01C56E14] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Cc: "Sipping \(E-mail\)" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Dale Worley wrote: > We've started implementing call-control features that depend on the dialog > event package, and it looks like some clarification and amendments are > needed to the current I-D. I'm circulating a draft of my observations to > see if anyone has any comments on them. [snip] > 2. Meaning of request URI, or "resource", of SUBSCRIBE. > > The theory is that the request URI of the SUBSCRIBE request describes > the "resource" to which the subscription applies. RFC 3265 discusses > this in very general terms, but draft-ietf-sipping-dialog-package > gives very little additional information. > > It seems intuitive that a subscription provides dialog event packages > for dialogs to/from the same user as the request URI of the SUBSCRIBE. > But the situation is probably more complicated than it seems -- what > URI, exactly, is a dialog "to"? > > It seems in practice that phones pay attention to the user part of the > resource URI, and match it with the user part of an incoming dialog's > request URI, or with the an outgoing dialog's line identification. > (And since most phones accept any incoming INVITE regardless of the > user part, there is another case when the user part doesn't match any > known line identification in the phone -- Most phones report those > dialogs for any SUBSCRIBE.) I think there are two separate issues being mixed here: - what do deployed devices currently do. This is important if you want to get something working right now with existing stuff - how *should* this work - how was it intended to work. Ideally the answers would be the same, but the world is rarely ideal. I think on sipping we should be concerned with how it *should* work. IMO UAs should only accept requests addressed to URIs that the UA has explicitly advertised for use. This includes contact addresses placed in REGISTER messages, in published PIDF documents, in 3xx responses, and in the contact headers of dialog establishing requests and their responses. (I am sure there are others as well, but in all cases the address originates with the UA in question and is explicitly distributed to others. When an INVITE is sent to an AoR and then forwarded to the UA, the UA perceives (from the R-URI) this as having been addressed to the contact that had been registered for that AoR. That is the target of the dialog that is established. When a subscription for the dialog event is addressed to the AoR, it too is forwarded to the corresponding registered contact address and the UA perceives this as the resource to which the subscription is addressed. It is then easy to associate to that resource the dialogs that had been established via incoming requests. For dialogs that were initiated in the outgoing direction, the obvious resource to associate with is the contact that was included in the outgoing INVITE. If the goal is that both incoming and outgoing calls be associated with AoRs (a reasonable expectation), then outgoing calls should carry the same contact that was used to register with an AoR. This will then work for watchers that subscribe to the AoR, and to those who are in a call and subscribe within the dialog to track what the peer is doing. I'm not sure I fully understood what you were suggesting. But it sounded like you were proposing that if phone.foo.com registers with AoR sip:abc@acme.com then it should consider all references to sip:abc@* to be for the same resource. This can be made to work in certain cases, but there are lots of counterexamples, so it is a really bad general recommendation. > (And should a SUBSCRIBE with no user part in its URI get information > on all dialogs at that device? Does this really matter, since such a > SUBSCRIBE cannot have been routed via a registration? OTOH, it could > have been made using a contact URI from a dialog the phone > participated in.) *If* the UA advertised a contact with no user part then subscriptions to that should get info on precisely those dialogs associated with that, per the above. If it didn't advertise that address then it should reject the subscription. Note that just recently requirements for sip devices were being discussed. One of the requirements was around devices being selective about the addresses on which they receive requests. I believe the purpose was to reduce the exposure to being attacked by hackers guessing addresses. Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Sat Jun 11 01:39:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgyie-0000sR-Ix; Sat, 11 Jun 2005 01:39:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgyic-0000sK-SK for sipping@megatron.ietf.org; Sat, 11 Jun 2005 01:39:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15297 for ; Sat, 11 Jun 2005 01:39:42 -0400 (EDT) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgz4P-00018z-NV for sipping@ietf.org; Sat, 11 Jun 2005 02:02:15 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IHW00CMENY7NA@szxga02-in.huawei.com> for sipping@ietf.org; Sat, 11 Jun 2005 13:44:31 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IHW00DTGNY75D@szxga02-in.huawei.com> for sipping@ietf.org; Sat, 11 Jun 2005 13:44:31 +0800 (CST) Received: from l39073 ([10.70.110.113]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IHW00MDDNY2MC@szxml02-in.huawei.com>; Sat, 11 Jun 2005 13:44:26 +0800 (CST) Date: Sat, 11 Jun 2005 13:39:39 +0800 From: =?gb2312?B?wO7Bog==?= Subject: Re: [Sipping] Inserting a B2BUA into an existing dialog In-reply-to: <006701c56ded$bed27ef0$6a01010a@keywest> To: "'Dale Worley'" Message-id: <000001c56e47$f5fba410$716e460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7BIT Cc: "'Sipping \(E-mail\)'" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org I think Dale's problem has been resolved in draft-ietf-sipping-cc-conferencing-06.But there's a more complex scenario. if A is talking to B,and they are in a session with an intermediate 3pcc controller which is referred to in rfc3725.when A want to initiate a conference with B,then how he work to do that? Dale Worley wrote: We are considering conference bridging applications, and it would be convenient to be able to insert the conference bridge (a B2BUA) into an existing dialog. It turns out that it's simple to *remove* the bridge from between two UAs, as it can send a REFER for an INVITE with Replaces to one of the UAs to get it to talk directly to the other UA. But I've not been able to figure out how to *insert* the bridge into an existing dialog. Has there been any work on this sort of thing? Thanks, Dale _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Mon Jun 13 16:55:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhvy9-0001FJ-8N; Mon, 13 Jun 2005 16:55:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhvy3-0001Ax-14 for sipping@megatron.ietf.org; Mon, 13 Jun 2005 16:55:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05655 for ; Mon, 13 Jun 2005 16:55:32 -0400 (EDT) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhwKM-0005Z9-Np for sipping@ietf.org; Mon, 13 Jun 2005 17:18:41 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j5DKtOVc015436; Mon, 13 Jun 2005 15:55:24 -0500 (CDT) Received: from [135.180.240.186] (volker-hopc.dnrc.bell-labs.com [135.180.240.186]) by homail.ho.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j5DKtOl24736; Mon, 13 Jun 2005 16:55:24 -0400 (EDT) Message-ID: <42ADF26F.4010500@bell-labs.com> Date: Mon, 13 Jun 2005 16:54:07 -0400 From: Volker Hilt User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping Content-Type: multipart/mixed; boundary="------------000707000807030402000804" X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: Gonzalo Camarillo Subject: [Sipping] [Fwd: I-D ACTION:draft-hilt-sipping-policy-usecases-00.txt] X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --------------000707000807030402000804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This is a new draft that describes use cases for session-specific policies. The goal of this draft is to provide a foundation for the discussion of the session-specific policy protocol. Feedback and comments are highly appreciated. In particular, I would like to solicit comments on the applicability of these use cases. Is there anything that we missed or shouldn't be there? Thanks, Volker --------------000707000807030402000804 Content-Type: message/rfc822; name="I-D ACTION:draft-hilt-sipping-policy-usecases-00.txt" Content-Disposition: inline; filename="I-D ACTION:draft-hilt-sipping-policy-usecases-00.txt" Return-Path: Received: from hoemail1.lucent.com (hoemail1.lucent.com [192.11.226.161]) by homail.ho.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j5DJjUl29324; Mon, 13 Jun 2005 15:45:30 -0400 (EDT) Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j5DJjLq3007960; Mon, 13 Jun 2005 14:45:24 -0500 (CDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhums-0005Hh-7q; Mon, 13 Jun 2005 15:39:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhump-0005HS-Sq for i-d-announce@megatron.ietf.org; Mon, 13 Jun 2005 15:39:55 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15810 for ; Mon, 13 Jun 2005 15:39:54 -0400 (EDT) Message-Id: <200506131939.PAA15810@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 13 Jun 2005 15:39:54 -0400 Subject: I-D ACTION:draft-hilt-sipping-policy-usecases-00.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Use Cases for Session-Specific Session Initiation Protocol (SIP) Session Policies Author(s) : V. Hilt, G. Camarillo Filename : draft-hilt-sipping-policy-usecases-00.txt Pages : 14 Date : 2005-6-13 This draft describes use cases for session-specific Session Initiation Protocol (SIP) sessions policies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hilt-sipping-policy-usecases-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-hilt-sipping-policy-usecases-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-hilt-sipping-policy-usecases-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-6-13160805.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hilt-sipping-policy-usecases-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-hilt-sipping-policy-usecases-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-13160805.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- --------------000707000807030402000804 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --------------000707000807030402000804-- From sipping-bounces@ietf.org Mon Jun 13 17:21:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhwNZ-0007x7-GC; Mon, 13 Jun 2005 17:21:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhwNX-0007wk-5R for sipping@megatron.ietf.org; Mon, 13 Jun 2005 17:21:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07193 for ; Mon, 13 Jun 2005 17:21:52 -0400 (EDT) Received: from mx01.pi.se ([195.7.64.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dhwjo-0006gc-0a for sipping@ietf.org; Mon, 13 Jun 2005 17:45:01 -0400 Received: from localhost (mx01.pi.se [127.0.0.1]) by mx01.pi.se (Postfix) with ESMTP id 2F572DF934; Mon, 13 Jun 2005 23:21:04 +0200 (CEST) Received: from mx01.pi.se ([127.0.0.1]) by localhost (mx01.pi.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 24631-01-37; Mon, 13 Jun 2005 23:21:03 +0200 (CEST) Received: from vit (h47n1fls33o265.telia.com [213.64.230.47]) by mx01.pi.se (Postfix) with ESMTP id 4AA36DF923; Mon, 13 Jun 2005 23:21:03 +0200 (CEST) From: "Gunnar Hellstrom" To: "Henry Sinnreich" Date: Mon, 13 Jun 2005 23:21:16 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <200506131939.PAA15476@ietf.org> X-Virus-Scanned: amavisd-new at pi.se X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 7bit Cc: "'Sipping@Ietf. Org'" Subject: [Sipping] RE: I-D ACTION:draft-sinnreich-sipdev-req-07.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Henry, This is a good specification. I would like to make you aware of that the revision of RFC 2793 RTP Payload for text conversation, now is ready and published as RFC 4103 RTP Payload for text conversation. It has made RFC 2793 obsolete. During the work it was called draft-ietf-avt-rfc2793bis This publication influences the issued sip device requirements draft and any other specification being specific about codecs for general SIP conversational sessions. It influences draft-sinnreich-sipdev-req-07.txt in the following way: 1. In references, delete reference [70] 2. In reference 56, change "draft-ietf-avt-rfc2793bis-09.txt, IETF, August 2004, work in progress." To "RFC 4103, IETF, June 2005." 3. In REQ-52, delete reference [70] 4. In Req 55, Req 56, Req 57, change "2793" to "4103" Regards Gunnar ------------------------------------------- Gunnar Hellstrom Omnitor AB Renathvagen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- >-----Original Message----- >From: i-d-announce-bounces@ietf.org >[mailto:i-d-announce-bounces@ietf.org]On Behalf Of >Internet-Drafts@ietf.org >Sent: Monday, June 13, 2005 9:39 PM >To: i-d-announce@ietf.org >Subject: I-D ACTION:draft-sinnreich-sipdev-req-07.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : SIP Telephony Device Requirements and Configuration > Author(s) : H. Sinnreich, et al. > Filename : draft-sinnreich-sipdev-req-07.txt > Pages : 37 > Date : 2005-6-13 > >This document describes the requirements for SIP telephony devices, > based on the deployment experience of large numbers of SIP phones and > PC clients using different implementations in various networks. The > objectives of the requirements are a well defined set of > interoperability and multi-vendor supported core features, so as to > enable similar ease of purchase, installation and operation as found > for PCs, PDAs analog feature phones or mobile phones. > > We present a glossary of the most common settings and some of the > more widely used values for some settings. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-07.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >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-sinnreich-sipdev-req-07.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-sinnreich-sipdev-req-07.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 sipping-bounces@ietf.org Tue Jun 14 09:36:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiBah-0000ry-70; Tue, 14 Jun 2005 09:36:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiBae-0000ro-QS for sipping@megatron.ietf.org; Tue, 14 Jun 2005 09:36:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18187 for ; Tue, 14 Jun 2005 09:36:27 -0400 (EDT) Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly02b.srv.mailcontrol.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiBx9-0001G5-Gq for sipping@ietf.org; Tue, 14 Jun 2005 09:59:44 -0400 Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly02b.srv.mailcontrol.com (MailControl) with ESMTP id j5EDYMNL003362; Tue, 14 Jun 2005 14:34:25 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 14 Jun 2005 14:34:22 +0100 Message-ID: <45730E094814E44488F789C1CDED27AE02BDFD1F@gbnewp0758m.eu.ubiquity.net> Thread-Topic: Best Current Practices for NAT Traversal for SIP Thread-Index: AcVw5ZoP7GtmEhSRR9SBcF3QW0ZA+wABVR1wAAFfyOA= From: "Chris Boulton" To: , X-Scanned-By: MailControl A-05-01-01 (www.mailcontrol.com) X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable Cc: Barry Andrews , Michael Doyle , sipping@ietf.org, Gonzalo Camarillo Subject: [Sipping] FW: Best Current Practices for NAT Traversal for SIP X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org [resent due to incorrect SIPPING address]=20 Hi Henry, et al, Some comments in-line. Best Regards, Chris. -----Original Message----- From: henry@sinnreich.net [mailto:henry@sinnreich.net]=20 Sent: 14 June 2005 14:36 To: jdrosen@cisco.com; Chris Boulton Cc: 'Barry Andrews'; Michael Doyle; 'Robert Sparks'; sipping-request@ietf.org Subject: Best Current Practices for NAT Traversal for SIP Several colleagues and I would like to urge you on behalf of many in our industry to finish the critical Internet Draft for the SIP community: "Best Current Practices for NAT Traversal for SIP". This is an excellent document, but as yet not finished. The "Best Current Practices for NAT Traversal for SIP" is without doubt in our minds the most critical of all the SIP work done at present in the various related IETF working groups, since without a NAT traversal standard, SIP based communications simply cannot be guaranteed to happen in the first place. Needless to say that two ICE enabled UAs need to be interoperable in a standard and auditable way, so as to be tested for example in SIPit. [Chris Boulton] Agreed. A response to a previous enquiry was that ICE is just being fixed, after which this I-D will be finished as well. Can you share what the status of both I-Ds is at present and what we will have at the 63 IETF? [Chris Boulton] Current status is that Gonzalo currently has the editors token as he is inserting some text in the document which deals with IPV6 inter-working. I believe he will be returning this back to me soon - although there were issues with the current TURN draft. Gonzalo?=20=20 Once I have received the draft - I intend updating based on the latest ICE specification. This again will depend on the production of the latest version of ICE in time for me to complete my updates. I'm not sure what plans Jonathan has for the next release of ICE? So in conclusion, the current plan is for a new version of the draft to be submitted in time for IETF 63. Regards, Chris. Sorry for this note, but looking at the 70+ RFCs on SIP and the several hundreds of I-D in the pipeline, I thought it is a good idea to share the priorities with the SIPPING WG and see what other think as well. Thanks, Henry=20=20 Henry Sinnreich CTO pulver.com 115 Broadhollow Rd Suite 225 Melville, NY 11747 USA =20 Information contained in this e-mail and any attachments are intended for t= he use of the addressee only, and may contain confidential information of U= biquity Software Corporation. All unauthorized use, disclosure or distribu= tion is strictly prohibited. If you are not the addressee, please notify t= he sender immediately and destroy all copies of this email. Unless otherwi= se expressly agreed in writing signed by an officer of Ubiquity Software Co= rporation, nothing in this communication shall be deemed to be legally bind= ing. Thank you. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Tue Jun 14 11:08:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiD1f-0007dR-3t; Tue, 14 Jun 2005 11:08:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiD1d-0007dE-1S for sipping@megatron.ietf.org; Tue, 14 Jun 2005 11:08:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24655 for ; Tue, 14 Jun 2005 11:08:23 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiDO7-0006hU-M0 for sipping@ietf.org; Tue, 14 Jun 2005 11:31:41 -0400 Received: by wproxy.gmail.com with SMTP id 40so343903wri for ; Tue, 14 Jun 2005 08:08:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Z0pvVJe7iloO+5b5lqaw4l7VWLeoAEvDzqRtFnKAx2SsePBWr1Z9dT8hYGERFwCzteY2RP41DfV4oSFazJ2LbwAaxpBp8eFl1iRHoOIDcgaW12XTTFrTvmHKxEzZGGlqQ+ZO4QdixhOHjP9xFEVZlUTonnUke5jbJdGxY8y5dco= Received: by 10.54.1.39 with SMTP id 39mr174462wra; Tue, 14 Jun 2005 08:08:14 -0700 (PDT) Received: by 10.54.17.77 with HTTP; Tue, 14 Jun 2005 08:08:14 -0700 (PDT) Message-ID: Date: Tue, 14 Jun 2005 11:08:14 -0400 From: Arjun Roychowdhury To: sipping@ietf.org Subject: Re: [Sipping] FW: Best Current Practices for NAT Traversal for SIP In-Reply-To: <45730E094814E44488F789C1CDED27AE02BDFD1F@gbnewp0758m.eu.ubiquity.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <45730E094814E44488F789C1CDED27AE02BDFD1F@gbnewp0758m.eu.ubiquity.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: quoted-printable X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Arjun Roychowdhury List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Just curious - a couple of weeks ago, Jonathan posted a question in the MMUSIC list about feedback on ICE (and the fact that the draft may need to add a statutory warning of 'Intense Headaches possible') Is there any work going on now to re-look at ICE and possibly simplify it ? And if so, will this draft wait for such changes ? I agree completing this draft would be very critical. regds arjun On 6/14/05, Chris Boulton wrote: >=20 > [resent due to incorrect SIPPING address] >=20 > Hi Henry, et al, >=20 > Some comments in-line. >=20 > Best Regards, >=20 > Chris. >=20 >=20 > -----Original Message----- > From: henry@sinnreich.net [mailto:henry@sinnreich.net] > Sent: 14 June 2005 14:36 > To: jdrosen@cisco.com; Chris Boulton > Cc: 'Barry Andrews'; Michael Doyle; 'Robert Sparks'; > sipping-request@ietf.org > Subject: Best Current Practices for NAT Traversal for SIP >=20 > Several colleagues and I would like to urge you on behalf of many in our > industry to finish the critical Internet Draft for the SIP community: > "Best > Current Practices for NAT Traversal for SIP". >=20 > This is an excellent document, but as yet not finished. >=20 > The "Best Current Practices for NAT Traversal for SIP" is without doubt > in > our minds the most critical of all the SIP work done at present in the > various related IETF working groups, since without a NAT traversal > standard, > SIP based communications simply cannot be guaranteed to happen in the > first > place. Needless to say that two ICE enabled UAs need to be interoperable > in > a standard and auditable way, so as to be tested for example in SIPit. >=20 > [Chris Boulton] Agreed. >=20 > A response to a previous enquiry was that ICE is just being fixed, after > which this I-D will be finished as well. Can you share what the status > of > both I-Ds is at present and what we will have at the 63 IETF? >=20 > [Chris Boulton] Current status is that Gonzalo currently has the editors > token as he is inserting some text in the document which deals with IPV6 > inter-working. I believe he will be returning this back to me soon - > although there were issues with the current TURN draft. Gonzalo? >=20 > Once I have received the draft - I intend updating based on the latest > ICE specification. This again will depend on the production of the > latest version of ICE in time for me to complete my updates. I'm not > sure what plans Jonathan has for the next release of ICE? >=20 > So in conclusion, the current plan is for a new version of the draft to > be submitted in time for IETF 63. >=20 > Regards, >=20 > Chris. >=20 >=20 >=20 > Sorry for this note, but looking at the 70+ RFCs on SIP and the several > hundreds of I-D in the pipeline, I thought it is a good idea to share > the > priorities with the SIPPING WG and see what other think as well. >=20 > Thanks, Henry >=20 > Henry Sinnreich > CTO > pulver.com > 115 Broadhollow Rd > Suite 225 > Melville, NY 11747 > USA >=20 >=20 >=20 >=20 >=20 >=20 > Information contained in this e-mail and any attachments are intended for= the use of the addressee only, and may contain confidential information of= Ubiquity Software Corporation. All unauthorized use, disclosure or distri= bution is strictly prohibited. If you are not the addressee, please notify= the sender immediately and destroy all copies of this email. Unless other= wise expressly agreed in writing signed by an officer of Ubiquity Software = Corporation, nothing in this communication shall be deemed to be legally bi= nding. Thank you. >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP >=20 --=20 Arjun Roychowdhury _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Tue Jun 14 18:19:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiJl1-0005GA-S8; Tue, 14 Jun 2005 18:19:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiJl0-0005FO-S1 for sipping@megatron.ietf.org; Tue, 14 Jun 2005 18:19:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12549 for ; Tue, 14 Jun 2005 18:19:39 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiK7Y-0006hc-Vv for sipping@ietf.org; Tue, 14 Jun 2005 18:43:02 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id EEFAD6C01F for ; Tue, 14 Jun 2005 18:19:35 -0400 (EDT) From: "Dale Worley" To: "Sipping (E-mail)" Date: Tue, 14 Jun 2005 18:18:07 -0400 Message-ID: <01f601c5712e$f1c522b0$6a01010a@keywest> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Subject: [Sipping] Inserting a B2BUA into an existing dialog X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org All of these suggestions work, but they don't quite cover the case I'm interested in. Certainly, one endpoint can managed it, by sending a REFER to the other endpoint to divert its call to the B2BUA, and then transferring its own call. But that's a fairly complex sequence of operations that requires specific support in the UA. And especially if one wants a third UA to be able to trigger the action "remotely". I was hoping that there was some combination of existing SIP features that could be used to perform the action remotely. (In contrast, using REFER and INVITE/Replaces, a UA can do significant call transferring. Unfortunately, there seems to be no way to transfer a call without causing one endpoint to be dropped permanently from the conversation.) Dale _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Tue Jun 14 18:25:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiJqB-0005cO-LB; Tue, 14 Jun 2005 18:25:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiJqA-0005c0-LE for sipping@megatron.ietf.org; Tue, 14 Jun 2005 18:25:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12928 for ; Tue, 14 Jun 2005 18:25:00 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiKCk-00072w-66 for sipping@ietf.org; Tue, 14 Jun 2005 18:48:22 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id E5AA56C01F for ; Tue, 14 Jun 2005 18:25:00 -0400 (EDT) From: "Dale Worley" To: "'Sipping (E-mail)'" Subject: RE: [Sipping] Dialog event packages Date: Tue, 14 Jun 2005 18:23:28 -0400 Message-ID: <01f701c5712f$b3741ce0$6a01010a@keywest> 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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <42AA2320.6090507@cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > I'm not sure I fully understood what you were suggesting. But it sounded > like you were proposing that if phone.foo.com registers with AoR > sip:abc@acme.com then it should consider all references to sip:abc@* to > be for the same resource. This can be made to work in certain cases, but > there are lots of counterexamples, so it is a really bad general recommendation. At the least, we have to take note that all phones I've seen, when a connection is made to AoR "abc@acme.com" will use a Contact address like "abc@10.1.1.254". And it probably has to. Of course, that is an address that it advertises. But at the least, let's be aware that phones ubiquitously use addresses that aren't AoRs, and will have to accept subscriptions for them. Dale _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Tue Jun 14 18:59:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiKNa-0005ch-CB; Tue, 14 Jun 2005 18:59:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiKNY-0005cU-NI for sipping@megatron.ietf.org; Tue, 14 Jun 2005 18:59:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16188 for ; Tue, 14 Jun 2005 18:59:30 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiKk7-0000pq-HY for sipping@ietf.org; Tue, 14 Jun 2005 19:22:52 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 14 Jun 2005 18:59:23 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5EMuWNU026501; Tue, 14 Jun 2005 18:59:20 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Jun 2005 18:58:52 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Jun 2005 18:58:51 -0400 Message-ID: <42AF612B.1060704@cisco.com> Date: Tue, 14 Jun 2005 18:58:51 -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: Dale Worley Subject: Re: [Sipping] Inserting a B2BUA into an existing dialog References: <01f601c5712e$f1c522b0$6a01010a@keywest> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jun 2005 22:58:51.0753 (UTC) FILETIME=[A1D92D90:01C57134] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: "Sipping \(E-mail\)" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Dale, Then can you be more explicit about - the starting state of all participants - the desired end state - what set of restrictions you want to operate under Paul Dale Worley wrote: > All of these suggestions work, but they don't quite cover the case I'm > interested in. Certainly, one endpoint can managed it, by sending a REFER > to the other endpoint to divert its call to the B2BUA, and then transferring > its own call. But that's a fairly complex sequence of operations that > requires specific support in the UA. And especially if one wants a third UA > to be able to trigger the action "remotely". I was hoping that there was > some combination of existing SIP features that could be used to perform the > action remotely. > > (In contrast, using REFER and INVITE/Replaces, a UA can do significant call > transferring. Unfortunately, there seems to be no way to transfer a call > without causing one endpoint to be dropped permanently from the > conversation.) > > Dale > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Tue Jun 14 19:14:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiKbo-0001Cd-AH; Tue, 14 Jun 2005 19:14:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiKbm-0001CT-SC for sipping@megatron.ietf.org; Tue, 14 Jun 2005 19:14:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17282 for ; Tue, 14 Jun 2005 19:14:12 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiKyL-0001nb-Of for sipping@ietf.org; Tue, 14 Jun 2005 19:37:35 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 14 Jun 2005 19:14:05 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5EN7R5S017677; Tue, 14 Jun 2005 19:10:29 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Jun 2005 19:10:10 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Jun 2005 19:10:10 -0400 Message-ID: <42AF63D1.2090605@cisco.com> Date: Tue, 14 Jun 2005 19:10:09 -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: Dale Worley Subject: Re: [Sipping] Dialog event packages References: <01f701c5712f$b3741ce0$6a01010a@keywest> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jun 2005 23:10:10.0298 (UTC) FILETIME=[364AEDA0:01C57136] X-Spam-Score: 1.3 (+) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: "'Sipping \(E-mail\)'" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Dale Worley wrote: >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> >>I'm not sure I fully understood what you were suggesting. But it sounded >>like you were proposing that if phone.foo.com registers with AoR >>sip:abc@acme.com then it should consider all references to sip:abc@* to >>be for the same resource. This can be made to work in certain cases, but >>there are lots of counterexamples, so it is a really bad general >>recommendation. > > At the least, we have to take note that all phones I've seen, when a > connection is made to AoR "abc@acme.com" will use a Contact address like > "abc@10.1.1.254". They are free to do so if they wish, but are under no obligation to do so. I have been on a campaign for a long time to abolish examples like that precisely because such examples encourage implementors to believe it must be that way. Consider the plight of a phone that is supposed to support two "lines", with AoRs sip:abc@acme.com and sip:abc@foobar.com. If it uses abc@10.1.1.254 as the contact for both it won't be able to tell which line was called. > And it probably has to. Why would it have to? Because the phone is implemented that way, or because the registrar requires it? For the time being it is conforming for the phone to be built with such a constraint, though that will impose limitations such as I just mentioned. It may however not be able to conform to the kind of requirements Henry is putting together for endpoints, which might require the ability to do exactly that. It is definitely incorrect for a registrar to require such behavior. > Of course, that is an address > that it advertises. But at the least, let's be aware that phones > ubiquitously use addresses that aren't AoRs, and will have to accept > subscriptions for them. Yup. Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Wed Jun 15 01:17:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiQHN-00018L-5O; Wed, 15 Jun 2005 01:17:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiQHI-00018D-Si for sipping@megatron.ietf.org; Wed, 15 Jun 2005 01:17:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07271 for ; Wed, 15 Jun 2005 01:17:28 -0400 (EDT) Received: from usaga01-in.huawei.com ([63.250.163.245] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiQdv-0005MI-Lj for sipping@ietf.org; Wed, 15 Jun 2005 01:40:52 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0II400GXA17APH@usaga01-in.huawei.com> for sipping@ietf.org; Tue, 14 Jun 2005 22:13:58 -0700 (PDT) Received: from huawei.com ([172.17.1.188]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0II400MN4179BI@usaga01-in.huawei.com> for sipping@ietf.org; Tue, 14 Jun 2005 22:13:58 -0700 (PDT) Received: from [172.24.1.6] (Forwarded-For: [10.18.3.138]) by szxmc01-in.huawei.com (mshttpd); Wed, 15 Jun 2005 10:18:05 +0500 Date: Wed, 15 Jun 2005 10:18:05 +0500 From: DarshanBildikar 70559 To: sipping@ietf.org Message-id: <17441f417424c0.17424c017441f4@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7BIT Subject: [Sipping] Question regarding reliable provisional response retransmission X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org The SIP RFC says that "A proxy has the option of canceling a transaction when there is a gap of 3 minutes between responses in a transaction. To prevent cancellation, the UAS MUST send a non-100 provisional response at every minute, to handle the possibility of lost provisional responses" Assume a B2BUA has generated a request on behalf of a caller. When the callee responds with a 180 Ringing message (with SDP) the B2BUA negotiates the callee to the caller (who might be connected to a media server, for example) so that a Ring back tone can be played or an IVR session ensues. My queries are as follows 1) RFC 3262 states that reliable provisional responses are to be retransmitted every two and a half minutes. Why is this really required since the response is after all "reliable" ! 2) Should the retransmitted provisional response always contain the same SDP? i.e. Should I only consider the first SDP and ignore SDP's in subsequent messages? Any help is appreciated. ****************************************************************************************** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ***************************************************************************************** _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Wed Jun 15 01:17:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiQHX-00018w-UB; Wed, 15 Jun 2005 01:17:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiQHV-00018r-OA for sipping@megatron.ietf.org; Wed, 15 Jun 2005 01:17:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07276 for ; Wed, 15 Jun 2005 01:17:41 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiQe8-0005TX-Ps for sipping@ietf.org; Wed, 15 Jun 2005 01:41:05 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 15 Jun 2005 01:17:32 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5F5Cw5M001980; Wed, 15 Jun 2005 01:17:30 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Jun 2005 01:17:07 -0400 Received: from [192.168.1.100] ([10.86.242.15]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Jun 2005 01:17:07 -0400 Message-ID: <42AFB9D2.5060301@cisco.com> Date: Wed, 15 Jun 2005 01:17:06 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arjun Roychowdhury Subject: Re: [Sipping] FW: Best Current Practices for NAT Traversal for SIP References: <45730E094814E44488F789C1CDED27AE02BDFD1F@gbnewp0758m.eu.ubiquity.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jun 2005 05:17:07.0140 (UTC) FILETIME=[795A6840:01C57169] X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: 7bit Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org I am planning to issue a revised ICE draft that is in fact simplified, including removal of the meta-protocol aspects of this. In as much as the nat-scenarios document is a use cases document, if it has any ICE details it needs to wait for ICE. -Jonathan R. Arjun Roychowdhury wrote: > Just curious - a couple of weeks ago, Jonathan posted a question in > the MMUSIC list about feedback on ICE (and the fact that the draft may > need to add a statutory warning of 'Intense Headaches possible') > > Is there any work going on now to re-look at ICE and possibly simplify > it ? And if so, will this draft wait for such changes ? > > I agree completing this draft would be very critical. > > regds > arjun > > > On 6/14/05, Chris Boulton wrote: > >>[resent due to incorrect SIPPING address] >> >>Hi Henry, et al, >> >>Some comments in-line. >> >>Best Regards, >> >>Chris. >> >> >>-----Original Message----- >>From: henry@sinnreich.net [mailto:henry@sinnreich.net] >>Sent: 14 June 2005 14:36 >>To: jdrosen@cisco.com; Chris Boulton >>Cc: 'Barry Andrews'; Michael Doyle; 'Robert Sparks'; >>sipping-request@ietf.org >>Subject: Best Current Practices for NAT Traversal for SIP >> >>Several colleagues and I would like to urge you on behalf of many in our >>industry to finish the critical Internet Draft for the SIP community: >>"Best >>Current Practices for NAT Traversal for SIP". >> >>This is an excellent document, but as yet not finished. >> >>The "Best Current Practices for NAT Traversal for SIP" is without doubt >>in >>our minds the most critical of all the SIP work done at present in the >>various related IETF working groups, since without a NAT traversal >>standard, >>SIP based communications simply cannot be guaranteed to happen in the >>first >>place. Needless to say that two ICE enabled UAs need to be interoperable >>in >>a standard and auditable way, so as to be tested for example in SIPit. >> >>[Chris Boulton] Agreed. >> >>A response to a previous enquiry was that ICE is just being fixed, after >>which this I-D will be finished as well. Can you share what the status >>of >>both I-Ds is at present and what we will have at the 63 IETF? >> >>[Chris Boulton] Current status is that Gonzalo currently has the editors >>token as he is inserting some text in the document which deals with IPV6 >>inter-working. I believe he will be returning this back to me soon - >>although there were issues with the current TURN draft. Gonzalo? >> >>Once I have received the draft - I intend updating based on the latest >>ICE specification. This again will depend on the production of the >>latest version of ICE in time for me to complete my updates. I'm not >>sure what plans Jonathan has for the next release of ICE? >> >>So in conclusion, the current plan is for a new version of the draft to >>be submitted in time for IETF 63. >> >>Regards, >> >>Chris. >> >> >> >>Sorry for this note, but looking at the 70+ RFCs on SIP and the several >>hundreds of I-D in the pipeline, I thought it is a good idea to share >>the >>priorities with the SIPPING WG and see what other think as well. >> >>Thanks, Henry >> >>Henry Sinnreich >>CTO >>pulver.com >>115 Broadhollow Rd >>Suite 225 >>Melville, NY 11747 >>USA >> >> >> >> >> >> >>Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited. If you are not the addressee, please notify the sender immediately and destroy all copies of this email. Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding. Thank you. >> >> >>_______________________________________________ >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>This list is for NEW development of the 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 Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Wed Jun 15 02:17:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiRDB-0004vl-U7; Wed, 15 Jun 2005 02:17:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiRDA-0004vg-98 for sipping@megatron.ietf.org; Wed, 15 Jun 2005 02:17:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27125 for ; Wed, 15 Jun 2005 02:17:15 -0400 (EDT) Received: from [202.54.64.17] (helo=hclnpd.hclt-ntl.co.in) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiRZn-0000Cr-5J for sipping@ietf.org; Wed, 15 Jun 2005 02:40:40 -0400 Received: from npd-mail1.hclt-ntl.co.in ([10.105.1.106]) by hclnpd.hclt-ntl.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id MW0M9RK0; Wed, 15 Jun 2005 11:47:04 +0530 X-MessageTextProcessor: DisclaimIt (2.50.252) [HCL Technologies Ltd., Chennai, India] Content-Class: urn:content-classes:message Received: from npd-mail.hclt-ntl.co.in ([10.105.1.104]) by npd-mail1.hclt-ntl.co.in with Microsoft SMTPSVC(5.0.2195.6713); Wed, 15 Jun 2005 11:47:04 +0530 Received: by npd-mail.hclt-ntl.co.in with Internet Mail Service (5.5.2657.72) id ; Wed, 15 Jun 2005 11:47:03 +0530 Message-ID: <4B1D6623CCBD79489DE28D1CA062A47EF9F38C@npd-mail.hclt-ntl.co.in> From: "Prakash Maria susai - NPD, Chennai" To: Content-Transfer-Encoding: 7bit Date: Wed, 15 Jun 2005 11:47:03 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 15 Jun 2005 06:17:04.0005 (UTC) FILETIME=[D9407350:01C57171] X-Spam-Score: 0.3 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Subject: [Sipping] FW: Clarifications sought on STUN X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org re-posting, as I have not got replies so far for the previous post. -----Original Message----- From: Prakash Maria susai - NPD, Chennai [mailto:prakashm@hcltech.com] Sent: Tuesday, June 07, 2005 5:20 PM To: sipping@ietf.org; sip-implementors@cs.columbia.edu Subject: Clarifications sought on STUN Hi All, I have made some assumptions on the STUN client protocol. I would like to clarify if they are correct. Below are the assumptions: 1) On Shared Secret Request(SSR): The username, password from the Response got for ONE shared secret request, can be used for ANY number of subsequent Binding Requests(BR). This credential can be used till a 430 response is got for a BR. In other words, a single SSR transaction is enough for sending many BRs, if the credential at the STUN server has not expired. 2) When 430 response for a BR is got, then a new SSR had to be sent, and a username-password got from that, can be used for further BRs. 3) A single STUN client can be used by multiple applications, and the identifier that STUN provides for matching the responses to different applications is the Transaction-ID. 4) Multiple BRs can be sent simultaneously from a STUN client, and the STUN client must be able to demultiplex the responses got for the different BRs from the STUN server. 5) On Binding response handling: Acc. to "ietf-behave-rfc3489bis-01", a STUN client, even after it receives a 200 Response, has to wait for 10 seconds for any additional responses, and then terminate the transaction. If so, then will it take ATLEAST 10 secs,if STUN is used, before an INVITE is sent? Quote from Section 9.4 of "ietf-behave-rfc3489bis-01": "Reception of a response to a Binding Request will terminate retransmissions of that request. However, clients MUST continue to listen for responses to a Binding Request for 10 seconds after the first response. If it receives any responses in this interval with different message types, different MAPPED-ADDRESSes, or different XOR-MAPPED-ADDRESSes, it is an indication of a possible attack. The client MUST NOT use the MAPPED-ADDRESS or XOR-MAPPED-ADDRESS from any of the responses it received (either the first or the additional ones), and SHOULD alert the user." If would be very helpful ,if anyone can clarify these. Please excuse me sending to both sipping and sip-implementors, since I was not sure to which list to send. Thanks, Prakash. Disclaimer: This message and any attachment(s) contained here are information that is confidential, proprietary to HCL Technologies and its customers, privileged or otherwise protected by law. The information is solely intended for the individual or the entity it is addressed to. If you are not the intended recipient of this message, you are not authorized to read, forward, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer. _______________________________________________ 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 sipping-bounces@ietf.org Wed Jun 15 02:35:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiRUq-00085v-QR; Wed, 15 Jun 2005 02:35:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiRUp-00085q-3j for sipping@megatron.ietf.org; Wed, 15 Jun 2005 02:35:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16161 for ; Wed, 15 Jun 2005 02:35:29 -0400 (EDT) Received: from web208.biz.mail.re2.yahoo.com ([68.142.224.170]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DiRrP-0001Ax-Np for sipping@ietf.org; Wed, 15 Jun 2005 02:58:55 -0400 Message-ID: <20050615063514.34257.qmail@web208.biz.mail.re2.yahoo.com> Received: from [81.218.112.229] by web208.biz.mail.re2.yahoo.com via HTTP; Tue, 14 Jun 2005 23:35:14 PDT Date: Tue, 14 Jun 2005 23:35:14 -0700 (PDT) From: David Schwartz To: sipping@ietf.org MIME-Version: 1.0 X-Spam-Score: 2.9 (++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Sipping] SIP Cert X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0681512051==" Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org --===============0681512051== Content-Type: multipart/alternative; boundary="0-1098954418-1118817314=:33727" --0-1098954418-1118817314=:33727 Content-Type: text/plain; charset=us-ascii Can anyone point me please to the latest draft or RFC on this? Thanks, David --0-1098954418-1118817314=:33727 Content-Type: text/html; charset=us-ascii
Can anyone point me please to the latest draft or RFC on this?
 
Thanks,
 
David
--0-1098954418-1118817314=:33727-- --===============0681512051== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============0681512051==-- From sipping-bounces@ietf.org Wed Jun 15 05:33:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiUHV-0007a5-5N; Wed, 15 Jun 2005 05:33:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiUHT-0007Za-3i for sipping@megatron.ietf.org; Wed, 15 Jun 2005 05:33:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26061 for ; Wed, 15 Jun 2005 05:33:52 -0400 (EDT) Received: from web26202.mail.ukl.yahoo.com ([217.12.10.239]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DiUe7-0002e1-Ik for sipping@ietf.org; Wed, 15 Jun 2005 05:57:20 -0400 Received: (qmail 19004 invoked by uid 60001); 15 Jun 2005 09:33:44 -0000 Message-ID: <20050615093344.19002.qmail@web26202.mail.ukl.yahoo.com> Received: from [194.237.142.13] by web26202.mail.ukl.yahoo.com via HTTP; Wed, 15 Jun 2005 11:33:44 CEST Date: Wed, 15 Jun 2005 11:33:44 +0200 (CEST) From: Salvatore Loreto To: simple@ietf.org, sipping@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Sipping] simple and TV X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: salvatore.loreto@ieee.org List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Hi, I'm researching about possible interaction between TV boxer decoder and SIP / Presence services, for interactive services. What do you think about the above scenario? Do you know if there are some studio/researches about? thank you in advance /sal ___________________________________ Yahoo! Messenger: chiamate gratuite in tutto il mondo http://it.beta.messenger.yahoo.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Wed Jun 15 05:38:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiUM7-000802-NR; Wed, 15 Jun 2005 05:38:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiUM6-0007zx-Od for sipping@megatron.ietf.org; Wed, 15 Jun 2005 05:38:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26392 for ; Wed, 15 Jun 2005 05:38:40 -0400 (EDT) Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiUij-0002x8-KV for sipping@ietf.org; Wed, 15 Jun 2005 06:02:08 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0II4001RFDJXRZ@szxga03-in.huawei.com> for sipping@ietf.org; Wed, 15 Jun 2005 17:40:46 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0II400204DJXDI@szxga03-in.huawei.com> for sipping@ietf.org; Wed, 15 Jun 2005 17:40:45 +0800 (CST) Received: from GUEST ([10.76.176.165]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0II4007I8DTKD2@szxml01-in.huawei.com> for sipping@ietf.org; Wed, 15 Jun 2005 17:46:32 +0800 (CST) Date: Wed, 15 Jun 2005 17:38:49 +0800 From: xupeili Subject: RE: [Sipping] Question regarding reliable provisional responseretransmission In-reply-to: <17441f417424c0.17424c017441f4@huawei.com> To: "'DarshanBildikar 70559'" , sipping@ietf.org Message-id: <000001c5718e$08c2b540$a5b04c0a@huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7BIT Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Hi: In my understanding, (1) retransmission of provisional response is to extent the Uac`s time out for the transaction. (2) the SDP in different reliable 1xx is logically independent, furthermore it is not necessary to provide SDP in each reliable 1xx. -----Original Message----- From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf Of DarshanBildikar 70559 Sent: Wednesday, June 15, 2005 1:18 PM To: sipping@ietf.org Subject: [Sipping] Question regarding reliable provisional responseretransmission The SIP RFC says that "A proxy has the option of canceling a transaction when there is a gap of 3 minutes between responses in a transaction. To prevent cancellation, the UAS MUST send a non-100 provisional response at every minute, to handle the possibility of lost provisional responses" Assume a B2BUA has generated a request on behalf of a caller. When the callee responds with a 180 Ringing message (with SDP) the B2BUA negotiates the callee to the caller (who might be connected to a media server, for example) so that a Ring back tone can be played or an IVR session ensues. My queries are as follows 1) RFC 3262 states that reliable provisional responses are to be retransmitted every two and a half minutes. Why is this really required since the response is after all "reliable" ! 2) Should the retransmitted provisional response always contain the same SDP? i.e. Should I only consider the first SDP and ignore SDP's in subsequent messages? Any help is appreciated. ************************************************************************ ****************** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ************************************************************************ ***************** _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Wed Jun 15 08:26:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiWyj-0000r1-IC; Wed, 15 Jun 2005 08:26:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiWyh-0000qw-R7 for sipping@megatron.ietf.org; Wed, 15 Jun 2005 08:26:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09155 for ; Wed, 15 Jun 2005 08:26:42 -0400 (EDT) Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiXLM-0004Wo-Ld for sipping@ietf.org; Wed, 15 Jun 2005 08:50:11 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j5FCO5XU008629 for ; Wed, 15 Jun 2005 15:24:10 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Jun 2005 15:26:24 +0300 Received: from [127.0.0.1] ([172.21.34.171]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 15 Jun 2005 15:16:56 +0300 Message-ID: <42B01C39.9010606@nokia.com> Date: Wed, 15 Jun 2005 15:16:57 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: sipping Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jun 2005 12:16:56.0411 (UTC) FILETIME=[1F5422B0:01C571A4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: [Sipping] BENOTIFY and SERVICE X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org I see that Microsoft LCS implements SERVICE and BENOTIFY methods. Does anybody know where these are documented? It claims that SERVICE is a standard SIP method. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/lcs2005/rtc/standardmethod.asp /Miguel -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Wed Jun 15 08:39:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiXAm-0003VH-2E; Wed, 15 Jun 2005 08:39:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiXAj-0003Uz-Op for sipping@megatron.ietf.org; Wed, 15 Jun 2005 08:39:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10187 for ; Wed, 15 Jun 2005 08:39:08 -0400 (EDT) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiXXP-0005Er-K3 for sipping@ietf.org; Wed, 15 Jun 2005 09:02:37 -0400 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0II400L6SLO8NG@dns1.cselt.it> for sipping@ietf.org; Wed, 15 Jun 2005 14:36:08 +0200 (MEST) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Jun 2005 14:42:11 +0200 Date: Wed, 15 Jun 2005 14:38:48 +0200 From: Cuda Alberto Subject: RE: [Sipping] BENOTIFY and SERVICE To: Miguel Garcia , sipping Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Sipping] BENOTIFY and SERVICE Thread-Index: AcVxpgeLnl3c1YiJQcqGJBzwqoJ3MgAASCbQ content-class: urn:content-classes:message X-OriginalArrivalTime: 15 Jun 2005 12:42:11.0843 (UTC) FILETIME=[A698B530:01C571A7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org It has been defined in a (long time expired) draft defining a way to put SOAP over SIP: http://www.softarmor.com/wgdb/docs/draft-deason-sip-soap-00.txt Cheers. Alberto. -----Original Message----- From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf Of Miguel Garcia Sent: Wednesday, June 15, 2005 2:17 PM To: sipping Subject: [Sipping] BENOTIFY and SERVICE I see that Microsoft LCS implements SERVICE and BENOTIFY methods. Does=20 anybody know where these are documented? It claims that SERVICE is a=20 standard SIP method. http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/lcs200= 5 /rtc/standardmethod.asp /Miguel --=20 Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to=20 MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Wed Jun 15 08:44:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiXFY-00054n-49; Wed, 15 Jun 2005 08:44:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiXFW-00054R-30 for sipping@megatron.ietf.org; Wed, 15 Jun 2005 08:44:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10538 for ; Wed, 15 Jun 2005 08:44:04 -0400 (EDT) Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiXcC-0005T0-U1 for sipping@ietf.org; Wed, 15 Jun 2005 09:07:33 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j5FCfWnP027464; Wed, 15 Jun 2005 15:41:35 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Jun 2005 15:44:01 +0300 Received: from [127.0.0.1] ([172.21.34.171]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 15 Jun 2005 15:44:02 +0300 Message-ID: <42B02292.30203@nokia.com> Date: Wed, 15 Jun 2005 15:44:02 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Cuda Alberto Subject: Re: [Sipping] BENOTIFY and SERVICE References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jun 2005 12:44:02.0998 (UTC) FILETIME=[E8D99D60:01C571A7] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Ahhhh, that 5 years old expired draft.... well, I guess that does not elevate that method to the category of a standard. Standard is what is registered by IANA in the Methods and Response Codes subregistry of SIP: http://www.iana.org/assignments/sip-parameters /Miguel Cuda Alberto wrote: > It has been defined in a (long time expired) draft defining a way > to put SOAP over SIP: > > http://www.softarmor.com/wgdb/docs/draft-deason-sip-soap-00.txt > > > Cheers. > Alberto. > > > -----Original Message----- > From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On > Behalf Of Miguel Garcia > Sent: Wednesday, June 15, 2005 2:17 PM > To: sipping > Subject: [Sipping] BENOTIFY and SERVICE > > > I see that Microsoft LCS implements SERVICE and BENOTIFY methods. Does > anybody know where these are documented? It claims that SERVICE is a > standard SIP method. > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/lcs2005 > /rtc/standardmethod.asp > > /Miguel -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Wed Jun 15 08:58:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiXT2-0007zv-Ry; Wed, 15 Jun 2005 08:58:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiXT0-0007ys-4Q for sipping@megatron.ietf.org; Wed, 15 Jun 2005 08:58:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12022 for ; Wed, 15 Jun 2005 08:58:00 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiXpg-0006QN-C0 for sipping@ietf.org; Wed, 15 Jun 2005 09:21:29 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 15 Jun 2005 05:57:51 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5FCvD5S014215; Wed, 15 Jun 2005 08:57:48 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Jun 2005 08:57:47 -0400 Received: from [192.168.1.100] ([10.86.242.15]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Jun 2005 08:57:46 -0400 Message-ID: <42B025CA.30107@cisco.com> Date: Wed, 15 Jun 2005 08:57:46 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Schwartz Subject: Re: [Sipping] SIP Cert References: <20050615063514.34257.qmail@web208.biz.mail.re2.yahoo.com> In-Reply-To: <20050615063514.34257.qmail@web208.biz.mail.re2.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jun 2005 12:57:46.0807 (UTC) FILETIME=[D3E0E470:01C571A9] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org http://www.ietf.org/internet-drafts/draft-ietf-sipping-certs-01.txt David Schwartz wrote: > Can anyone point me please to the latest draft or RFC on this? > > Thanks, > > David > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Wed Jun 15 14:39:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DicnI-0000yl-PB; Wed, 15 Jun 2005 14:39:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DicnH-0000yg-GH for sipping@megatron.ietf.org; Wed, 15 Jun 2005 14:39:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13342 for ; Wed, 15 Jun 2005 14:39:18 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DidA0-0002CM-LQ for sipping@ietf.org; Wed, 15 Jun 2005 15:02:50 -0400 Received: from [10.10.2.230] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j5FIgUH0017905 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 15 Jun 2005 13:42:31 -0500 In-Reply-To: <17441f417424c0.17424c017441f4@huawei.com> References: <17441f417424c0.17424c017441f4@huawei.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sipping] Question regarding reliable provisional response retransmission Date: Wed, 15 Jun 2005 13:39:19 -0500 To: DarshanBildikar 70559 X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org On Jun 15, 2005, at 12:18 AM, DarshanBildikar 70559 wrote: > 1) RFC 3262 states that reliable provisional responses are to be > retransmitted every two and a half minutes. Why is this really > required since the response is after all "reliable" ! > Because in addition to being reliable, they're still "provisional", and we need a state recovery mechanism to deal with state recovery in the cases where a transaction fails after a reliable provisional is exchanged. > 2) Should the retransmitted provisional response always contain the > same SDP? i.e. Should I only consider the first SDP and ignore SDP's > in subsequent messages? > Well, it would be terribly rude to change your offer in midstream, as there is a race conditional where an answer might be "in flight" as the new offer is being transmitted, so if the repsonse in question contained SDP, repeats should contain the same. It's not clear to me that one actually has to repeat the SAME reliable-provisional response sequence in order to maintain the transaction in the final-pending state. It would seem to suffice to send another reliable provisional (perhaps a 180) without SDP. Others may think differently. Question: Shouldn't this really be on the sip-implementors list? -- 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 sipping-bounces@ietf.org Wed Jun 15 14:55:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Did3A-0004Qz-Ld; Wed, 15 Jun 2005 14:55:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Did38-0004Ps-OC for sipping@megatron.ietf.org; Wed, 15 Jun 2005 14:55:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15055 for ; Wed, 15 Jun 2005 14:55:41 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DidPs-0003Gd-1R for sipping@ietf.org; Wed, 15 Jun 2005 15:19:13 -0400 Received: from [10.10.2.230] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j5FIx38d018003 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 15 Jun 2005 13:59:05 -0500 In-Reply-To: <42B01C39.9010606@nokia.com> References: <42B01C39.9010606@nokia.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sipping] BENOTIFY and SERVICE Date: Wed, 15 Jun 2005 13:55:52 -0500 To: Miguel Garcia X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org On Jun 15, 2005, at 7:16 AM, Miguel Garcia wrote: > I see that Microsoft LCS implements SERVICE and BENOTIFY methods. Does > anybody know where these are documented? It claims that SERVICE is a > standard SIP method. > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ > lcs2005/rtc/standardmethod.asp > > The SERVICE and BENOTIFY methods do not appear to be registered with IANA, so they would not be "standard" in my view of the common usage here at IETF. Perhaps you could open a bug report with Microsoft, who appears to have either an error in their software or in their documentation. Of course, it could be that they're claiming these to be "Microsoft Standard (TM)" methods, which might have been the intent. Or perhaps what's really meant is that the "standard methods" are the ones that come in the base model LCS, and that you can potentially get all sorts of nifty "upgrade methods" by upgrading to a premium version of LCS. This is sort of like "standard features" in automobiles. You know, things like brakes, engines, and a steering wheel. But of course automobiles are often purchased with critical "upgrade features", such as roofs, radios, and air conditioners. I hesitate to speculate what other "upgrade methods" might become available for LCS, but personally I'd like to see the "DOWHATIMEANANDNOTWHATISAY" method, the "WORKSWITHOUTCRASHING" method, and the very important "DROPTHEIVRANDGETMEAHUMANOPERATOR" method. -- 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 sipping-bounces@ietf.org Wed Jun 15 15:05:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DidCm-00070f-Gr; Wed, 15 Jun 2005 15:05:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DidCl-00070a-QY for sipping@megatron.ietf.org; Wed, 15 Jun 2005 15:05:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16403 for ; Wed, 15 Jun 2005 15:05:38 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DidZV-00043z-4d for sipping@ietf.org; Wed, 15 Jun 2005 15:29:10 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id B2B3F6C02A for ; Wed, 15 Jun 2005 15:05:32 -0400 (EDT) From: "Dale Worley" To: "'Sipping (E-mail)'" Subject: RE: [Sipping] Dialog event packages Date: Wed, 15 Jun 2005 15:04:01 -0400 Message-ID: <00a501c571dc$fe6e1c20$6a01010a@keywest> 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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <42AF63D1.2090605@cisco.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > At the least, we have to take note that all phones I've seen, when a > > connection is made to AoR "abc@acme.com" will use a Contact > address like > > "abc@10.1.1.254". > > They are free to do so if they wish, but are under no > obligation to do > so. I have been on a campaign for a long time to abolish > examples like > that precisely because such examples encourage implementors > to believe > it must be that way. I'm new here -- What have you been proposing as an alternative? Dale _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Wed Jun 15 15:13:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DidJw-0000gh-Pz; Wed, 15 Jun 2005 15:13:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DidJv-0000gU-7w for sipping@megatron.ietf.org; Wed, 15 Jun 2005 15:13:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17666 for ; Wed, 15 Jun 2005 15:13:01 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Didgf-0004Wt-OM for sipping@ietf.org; Wed, 15 Jun 2005 15:36:34 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id 14E336C02A for ; Wed, 15 Jun 2005 15:13:02 -0400 (EDT) From: "Dale Worley" To: "'Sipping (E-mail)'" Subject: RE: [Sipping] Inserting a B2BUA into an existing dialog Date: Wed, 15 Jun 2005 15:11:26 -0400 Message-ID: <00a601c571de$0a4d8ca0$6a01010a@keywest> 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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <42AF612B.1060704@cisco.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Then can you be more explicit about > - the starting state of all participants > - the desired end state > - what set of restrictions you want to operate under What I was hoping for was that this topic had been well-discussed and a good solution was already known... What I'd like to see runs along these lines: Usage scenario: 1) Dialog between UAs A and B. Ideally, A and B need no features other than those already defined in SIP. 2) UA C decides to insert istelf "between" A and B. (In general, C could be the same as A or B, but in that case, it's clear how to implement it.) 3) C sends appropriate messages to A and B. After they are executed: at UA A, the dialog A-C has replaced dialog A-B, and at UA B, dialog B-C has replaced dialog A-B. C provides a media path between dialog A-C and B-C. Trivially, we could assume that UA A knows how to implement the appopriate messages to B, etc., and that this facility in A can be triggered by a message from C. But that is really ugly. I'd like to assume that A and B provide no more facilities than are already defined in SIP (e.g., REFER, INVITE/Replaces, dialog events, etc.), and that C can use these operations to effect this transformation. (Oddly, if one is already in situation (3), it is straightforward for C to transform it to (1).) I hope that makes it clearer. Dale _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Wed Jun 15 18:40:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DigYO-000272-4H; Wed, 15 Jun 2005 18:40:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DigYM-00026x-7w for sipping@megatron.ietf.org; Wed, 15 Jun 2005 18:40:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13074 for ; Wed, 15 Jun 2005 18:40:07 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Digv6-0003Dd-MO for sipping@ietf.org; Wed, 15 Jun 2005 19:03:42 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 15 Jun 2005 15:39:58 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5FMdOcK019073 for ; Wed, 15 Jun 2005 15:39:56 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Jun 2005 18:39:52 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Jun 2005 18:39:52 -0400 Message-ID: <42B0AE37.9020508@cisco.com> Date: Wed, 15 Jun 2005 18:39:51 -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 (E-mail)'" References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jun 2005 22:39:52.0105 (UTC) FILETIME=[24FA7190:01C571FB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: I-D ACTION:draft-jesske-sipping-tispan-requirements-01.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Thank you - this version is much more to the point than the prior one! I still find some context lacking for interpretting what is being requested. Primarily I don't understand who these requirements are intended to apply to. It seems that you are seeking mechanisms that can be used to carry out the simulation requirments. But these mechanisms will have to be deployed in some operating environment to be effective. And what your assumptions are about that will influence the kinds of mechanisms that are suitable. Pretty much all of these requirements involve the cooperation of multiple parties - either a caller and a callee, caller and some network component, or callee and some network component. Are you satisfied to have these features work only when all parties in the call cooperate? For instance, consider [REQ-CDIV-1] and [REQ-CDIV-3]. If the callee does not cooperate and diverts the call without the proper indications then it will be impossible to meet the requirements. Are you seeking something that is intended to apply to all sip implementation in order to make your service work? Or are you willing to have it only work with cooperative callees. (Note that it is generally impossible to guarantee that all callees will cooperate unless you have physical control of all components including the endpoints. So it would be helpful to have some indication of the kinds of restrictions you are prepared to impose on the system for these features to be fully operable. And if you would like to allow different classes of restrictions, and corresponding differences in features, then that would also be useful to know. Thanks, Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Wed Jun 15 18:51:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Digji-0004s4-KA; Wed, 15 Jun 2005 18:51:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Digjf-0004rr-UK for sipping@megatron.ietf.org; Wed, 15 Jun 2005 18:51:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14003 for ; Wed, 15 Jun 2005 18:51:48 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dih6S-0003sZ-6R for sipping@ietf.org; Wed, 15 Jun 2005 19:15:24 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 15 Jun 2005 15:51:43 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5FMpLc6027059; Wed, 15 Jun 2005 15:51:37 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Jun 2005 18:51:36 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Jun 2005 18:51:36 -0400 Message-ID: <42B0B0F8.3010103@cisco.com> Date: Wed, 15 Jun 2005 18:51:36 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale Worley Subject: Re: [Sipping] Dialog event packages References: <00a501c571dc$fe6e1c20$6a01010a@keywest> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jun 2005 22:51:36.0339 (UTC) FILETIME=[C8BC0630:01C571FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: "'Sipping \(E-mail\)'" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Dale - comments inline. Paul Dale Worley wrote: >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> >> >>>At the least, we have to take note that all phones I've seen, when a >>>connection is made to AoR "abc@acme.com" will use a Contact >> >>address like >> >>>"abc@10.1.1.254". >> >>They are free to do so if they wish, but are under no >>obligation to do >>so. I have been on a campaign for a long time to abolish >>examples like >>that precisely because such examples encourage implementors >>to believe >>it must be that way. > > > I'm new here Yeah, I thought you were a new name, but then I though maybe my memory was just bad. :-) You know an awful lot for a newbie. How is that? > -- What have you been proposing as an alternative? That the endpoint put whatever they want. For example purposes I am inclined to use something pseudo-random like sip:xyzzy@@10.1.1.254 or something that correlates differently, such as: sip:line1@10.1.1.254 sip:line2@10.1.1.254 E.g. REGISTER sip:atlanta.com To: sip:abc@atlanta.com From: sip:abc@atlanta.com Contact: sip:line1@10.1.1.254 REGISTER sip:biloxi.com To: sip:abc@biloxi.com From: sip:abc@biloxi.com Contact: sip:line2@10.1.1.254 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Wed Jun 15 19:07:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DigyV-0007wo-3C; Wed, 15 Jun 2005 19:07:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DigyT-0007wj-9x for sipping@megatron.ietf.org; Wed, 15 Jun 2005 19:07:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14963 for ; Wed, 15 Jun 2005 19:07:06 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DihLF-0004Zz-O4 for sipping@ietf.org; Wed, 15 Jun 2005 19:30:42 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 15 Jun 2005 16:06:59 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5FN6iNM029096; Wed, 15 Jun 2005 19:06:56 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Jun 2005 19:06:35 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Jun 2005 19:06:34 -0400 Message-ID: <42B0B47A.6000200@cisco.com> Date: Wed, 15 Jun 2005 19:06:34 -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: Dale Worley Subject: Re: [Sipping] Inserting a B2BUA into an existing dialog References: <00a601c571de$0a4d8ca0$6a01010a@keywest> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jun 2005 23:06:34.0984 (UTC) FILETIME=[E05E5E80:01C571FE] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: "'Sipping \(E-mail\)'" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org inline. Paul Dale Worley wrote: >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> >>Then can you be more explicit about >>- the starting state of all participants >>- the desired end state >>- what set of restrictions you want to operate under > > What I was hoping for was that this topic had been well-discussed and a good > solution was already known... Not the spin you have in mind. > What I'd like to see runs along these lines: > > Usage scenario: > > 1) Dialog between UAs A and B. Ideally, A and B need no features other than > those already defined in SIP. > > 2) UA C decides to insert istelf "between" A and B. (In general, C could be > the same as A or B, but in that case, it's clear how to implement it.) The obvious question is: How would C know to do that? Either C is already in cooperation with A or B, or else C is operated by the user of A or B. The other obvious reaction is that you are trying to institutionalize wire tapping. That won't make you popular. (Well, maybe with the FBI, but not with people here.) > 3) C sends appropriate messages to A and B. After they are executed: at UA > A, the dialog A-C has replaced dialog A-B, and at UA B, dialog B-C has > replaced dialog A-B. C provides a media path between dialog A-C and B-C. How about: - C subscribes to dialog event package for both A and B (probably already did to know it wants to do this) - C sends an INVITE/Replaces to A with no offer. - A responds to the invite with offer SDP1 - C then sends INVITE/Replaces to B with SDP1 - ... That gets you a call with C in the signaling path but not the media path. You can work out how to intercept the media too if you insist. > Trivially, we could assume that UA A knows how to implement the appopriate > messages to B, etc., and that this facility in A can be triggered by a > message from C. But that is really ugly. I'd like to assume that A and B > provide no more facilities than are already defined in SIP (e.g., REFER, > INVITE/Replaces, dialog events, etc.), and that C can use these operations > to effect this transformation. > > (Oddly, if one is already in situation (3), it is straightforward for C to > transform it to (1).) > > I hope that makes it clearer. > > Dale > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Wed Jun 15 20:27:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiiEH-0000Xp-Sb; Wed, 15 Jun 2005 20:27:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiiEH-0000Xk-2F for sipping@megatron.ietf.org; Wed, 15 Jun 2005 20:27:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20834 for ; Wed, 15 Jun 2005 20:27:31 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.194]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Diib1-0000vY-B6 for sipping@ietf.org; Wed, 15 Jun 2005 20:51:03 -0400 Received: by wproxy.gmail.com with SMTP id 49so40893wri for ; Wed, 15 Jun 2005 17:27:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=txtp2fjMbgvaC3DhbBxc+biraKYs7p7MMXeYrb7W6lYTN7uAoAStMlEwK0Li7tj4Ln6lGrbrxG5MtD2JW2tuDwN2xgdTGW9ohchmPMysiDDnAHkxVMTW36tvHb3NKNMKF8B50Vjgq1KeLqAA3aIH0qE+wLdFPRbaw0/H/gK/oUE= Received: by 10.54.17.22 with SMTP id 22mr4311wrq; Wed, 15 Jun 2005 17:27:18 -0700 (PDT) Received: by 10.54.17.77 with HTTP; Wed, 15 Jun 2005 17:27:18 -0700 (PDT) Message-ID: Date: Wed, 15 Jun 2005 20:27:18 -0400 From: Arjun Roychowdhury To: Dale Worley Subject: Re: [Sipping] Inserting a B2BUA into an existing dialog In-Reply-To: <00a601c571de$0a4d8ca0$6a01010a@keywest> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <42AF612B.1060704@cisco.com> <00a601c571de$0a4d8ca0$6a01010a@keywest> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Cc: "Sipping \(E-mail\)" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Arjun Roychowdhury List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Not sure I followed your thought below. If A and B already implement the standards required (REFER/INVITE/Replaces/dialog events etc) then these are all that are needed to effect this change. However, if C wants to break into a call between A & B when it was not in the path to begin with, it _must_ happen with the consent of the participants. If not, imagine how simple it would be for me to break into someone's private conversation and start a recording process. Let's assume a practical case (mix of local policy and SIP) 1. A wants to make a call to B. The call passes through some local policy servers where it is 'marked' that A is now speaking with B - the call gets connected directly with no B2B in between. 2. A little while later, into the conversation, some local policy gets triggered which now requires the existing A-B conversation to 'migrate' to a 'centrally hosted conference' (non SIP policy trigger) 3. As as result of this, "C" could just send a regular INVITE to both A and B with and isFocus contact asking A and B to join its conference. It cannot, however, force them into joining the conference - it must be co-operative, since C was not in the path in the first place (and if it could, refer to security concerns above) If you want C to indicate to A & B that its a dialog replacement, then C can send invites with the replaces header - the dialog ID could have been recovered using the dialog event pkg (or even 'picked up' from local 'state' if A and B don't support the event package - but then the 'discover of the dialog ID' becomes a backend provisioning issue and not of SIP) regds arjun On 6/15/05, Dale Worley wrote: > Trivially, we could assume that UA A knows how to implement the appopriat= e > messages to B, etc., and that this facility in A can be triggered by a > message from C. But that is really ugly. I'd like to assume that A and = B > provide no more facilities than are already defined in SIP (e.g., REFER, > INVITE/Replaces, dialog events, etc.), and that C can use these operation= s > to effect this transformation. > Dale >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP >=20 --=20 Arjun Roychowdhury _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Thu Jun 16 06:16:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DirQM-0001OD-C2; Thu, 16 Jun 2005 06:16:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DirQK-0001O8-La for sipping@megatron.ietf.org; Thu, 16 Jun 2005 06:16:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03438 for ; Thu, 16 Jun 2005 06:16:30 -0400 (EDT) Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dirn9-0001dI-RG for sipping@ietf.org; Thu, 16 Jun 2005 06:40:15 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j5GADuA0003748 for ; Thu, 16 Jun 2005 13:13:59 +0300 Received: from esebh003.NOE.Nokia.com ([172.21.138.82]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Jun 2005 13:16:28 +0300 Received: from [127.0.0.1] ([172.21.34.171]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 16 Jun 2005 13:16:17 +0300 Message-ID: <42B15172.6080604@nokia.com> Date: Thu, 16 Jun 2005 13:16:18 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: sipping Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jun 2005 10:16:17.0344 (UTC) FILETIME=[6EEBEC00:01C5725C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Subject: [Sipping] PoC-settings event package X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Hi: I have just submitted a new version of the poc-settings event package draft. Until it is available, you can download a copy from: http://people.nokia.net/~miguel/drafts/draft-garcia-sipping-poc-isb-am-02.txt or http://people.nokia.net/~miguel/drafts/draft-garcia-sipping-poc-isb-am-02.html This contains the mostly editorial comments that I got in the mailing list and in the exper review. Regards, Miguel -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Thu Jun 16 09:02:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Diu0T-0007pU-3c; Thu, 16 Jun 2005 09:02:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Diu0R-0007oZ-1x for sipping@megatron.ietf.org; Thu, 16 Jun 2005 09:02:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17254 for ; Thu, 16 Jun 2005 09:01:58 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiuNJ-00068d-Ox for sipping@ietf.org; Thu, 16 Jun 2005 09:25:43 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id 67E3B6C019 for ; Thu, 16 Jun 2005 09:01:54 -0400 (EDT) From: "Dale Worley" To: "'Sipping (E-mail)'" Subject: RE: [Sipping] Inserting a B2BUA into an existing dialog Date: Thu, 16 Jun 2005 09:00:18 -0400 Message-ID: <002d01c57273$5a50fdf0$6a01010a@keywest> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org > From: Arjun Roychowdhury [mailto:arjunrc@gmail.com] > > However, if C wants to break into a call between A & B when it was not > in the path to begin with, it _must_ happen with the consent of the > participants. If not, imagine how simple it would be for me to break > into someone's private conversation and start a recording process. In any case, I would expect that it would require C to know the dialog-info (Call-Id, to-tag, from-tag) for the A-B dialog. But we have already agreed that the dialog-info is sensitive and should only be known by UAs that have the right to intervene in the dialog -- If C knows the the dialog-info, it can use existing mechanisms to hijack the dialog in various ways. There are no *new* security/privacy concerns here. > Not sure I followed your thought below. If A and B already implement > the standards required (REFER/INVITE/Replaces/dialog events etc) then > these are all that are needed to effect this change. I have yet to see how to implement this operation with existing mechanisms. > If you want C to indicate to A & B that its a dialog replacement, then > C can send invites with the replaces header It could, but consider what happens when A processes the INVITE/Replaces -- It sends a BYE on the A-B dialog. If B receives the BYE and processes it before its INVITE/Replaces arrives from C, the user at B perceives that the call was dropped. Dale _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Thu Jun 16 09:07:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Diu5N-0000sn-Sg; Thu, 16 Jun 2005 09:07:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Diu5L-0000se-O9 for sipping@megatron.ietf.org; Thu, 16 Jun 2005 09:07:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17687 for ; Thu, 16 Jun 2005 09:07:02 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiuSF-0006SO-Qg for sipping@ietf.org; Thu, 16 Jun 2005 09:30:48 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id 5A61D6C019 for ; Thu, 16 Jun 2005 09:07:06 -0400 (EDT) From: "Dale Worley" To: "'Sipping (E-mail)'" Subject: RE: [Sipping] Inserting a B2BUA into an existing dialog Date: Thu, 16 Jun 2005 09:05:32 -0400 Message-ID: <003201c57274$1443af00$6a01010a@keywest> 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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <42B0B47A.6000200@cisco.com> x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > The obvious question is: How would C know to do that? Either C is > already in cooperation with A or B, or else C is operated by > the user of > A or B. > > The other obvious reaction is that you are trying to institutionalize > wire tapping. That won't make you popular. (Well, maybe with the FBI, > but not with people here.) One possibility is that C is the attendant console in an office PBX, and e.g. the attendant is setting up a conference call. Another possibility is that A's UA does not have a conference bridge capability, but by hitting some keys, a second call can be placed from the UA to a conference bridge device to activate it. The conference bridge device then needs to direct (dumb) UAs A and B to finish the conference set-up. > How about: > > - C subscribes to dialog event package for both A and B > (probably already did to know it wants to do this) > - C sends an INVITE/Replaces to A with no offer. > - A responds to the invite with offer SDP1 A sends BYE to B. > - C then sends INVITE/Replaces to B with SDP1 B responds "No such dialog". Dale _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Thu Jun 16 09:10:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Diu8T-00017s-5B; Thu, 16 Jun 2005 09:10:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Diu8Q-00017i-LM for sipping@megatron.ietf.org; Thu, 16 Jun 2005 09:10:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18025 for ; Thu, 16 Jun 2005 09:10:13 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiuVK-0006Zw-Om for sipping@ietf.org; Thu, 16 Jun 2005 09:33:58 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id D97DB6C019 for ; Thu, 16 Jun 2005 09:10:17 -0400 (EDT) From: "Dale Worley" To: "'Sipping (E-mail)'" Subject: RE: [Sipping] Dialog event packages Date: Thu, 16 Jun 2005 09:08:43 -0400 Message-ID: <003301c57274$86690710$6a01010a@keywest> 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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <42B0B0F8.3010103@cisco.com> x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Yeah, I thought you were a new name, but then I though maybe > my memory was just bad. :-) > > You know an awful lot for a newbie. How is that? I like to hear myself talk, so I have to learn stuff to have something to talk about. ;-) But seriously, my employer has me working on SIP, so I have to learn it. > That the endpoint put whatever they want. For example purposes I am > inclined to use something pseudo-random like > > sip:xyzzy@@10.1.1.254 > > or something that correlates differently, such as: > > sip:line1@10.1.1.254 > sip:line2@10.1.1.254 A lot of SIP phones seem to use URIs like "sip:name@10.1.1.1;line=xuoslslk". Dale _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Thu Jun 16 10:32:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DivQ9-0004iq-2J; Thu, 16 Jun 2005 10:32:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DivQ7-0004ia-Sf for sipping@megatron.ietf.org; Thu, 16 Jun 2005 10:32:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26582 for ; Thu, 16 Jun 2005 10:32:34 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Divn1-0003bo-0m for sipping@ietf.org; Thu, 16 Jun 2005 10:56:20 -0400 Received: by wproxy.gmail.com with SMTP id 49so78041wri for ; Thu, 16 Jun 2005 07:32:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lsThV9NO69l/ovTRMi3LIM8t6YaL9Ex6qbs6C4FzRBUB4JMLDhsjUqEgvadozS1EhbRAZw+ZvpjAIodBS9EkyUwHlfTzujQfRrAY51OOa6i9nzOZ1pehCmoZstSXfGD8NtuwDr9CaFh3yhad/RaBw+FtlNibCTj3x+Ugt+Bg6eA= Received: by 10.54.17.22 with SMTP id 22mr17569wrq; Thu, 16 Jun 2005 07:32:28 -0700 (PDT) Received: by 10.54.17.77 with HTTP; Thu, 16 Jun 2005 07:32:28 -0700 (PDT) Message-ID: Date: Thu, 16 Jun 2005 10:32:28 -0400 From: Arjun Roychowdhury To: Dale Worley Subject: Re: [Sipping] Inserting a B2BUA into an existing dialog In-Reply-To: <002d01c57273$5a50fdf0$6a01010a@keywest> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <002d01c57273$5a50fdf0$6a01010a@keywest> X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Cc: "Sipping \(E-mail\)" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Arjun Roychowdhury List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org On 6/16/05, Dale Worley wrote: > > From: Arjun Roychowdhury [mailto:arjunrc@gmail.com] >=20 > In any case, I would expect that it would require C to know the dialog-in= fo > (Call-Id, to-tag, from-tag) for the A-B dialog. But we have already agre= ed > that the dialog-info is sensitive and should only be known by UAs that ha= ve > the right to intervene in the dialog -- If C knows the the dialog-info, i= t > can use existing mechanisms to hijack the dialog in various ways. There = are > no *new* security/privacy concerns here. Discovering dialog-identifier is not the security concern - I assume that will already be covered by the authentication required for C to subscribe to A/B's dialog-state in the first place. Being able to hijack an existing session between A&B without their consent is the security concern. If you don't require that C 'takes over without A and B knowing and possibly rejecting' then this point is moot. > > If you want C to indicate to A & B that its a dialog replacement, then > > C can send invites with the replaces header >=20 > It could, but consider what happens when A processes the INVITE/Replaces = -- > It sends a BYE on the A-B dialog. If B receives the BYE and processes it > before its INVITE/Replaces arrives from C, the user at B perceives that t= he > call was dropped. No - If B receives a Replaces header with an INVITE (either from C or A), that is an indication to B that the existing dialog is being replaced by another - that is not the same as dropping call. The latter would imply that B is unaware that the new call C-B is 'related' to the previous A-B. If you are concerned that the BYE will result in an 'audio restart' or break, well, that depends on how B manages its media streams. If you look at the suggested callflow in 4.10 of the conferencing-scenario draft, you would notice that on receiving the INVITE with replaces, B switches RTP media streams to the replaced call and _then_ sends BYE out. From a behaviour perspective, if a UA receives an INVITE replaces, it should know that it needs to switch the media stream (if it accepts this redirection) as opposed to shutting it down/clearing local microphone interfaces/releasing media resources etc and restarting all over again (to reduce the infamous crackle-and-pop effect of audio) There could be a possible sync issue if C were to send INV(replaces) to A and B. For some reason one of them don't get it before the other sends them a BYE for A-B or B-A. To avoid this, the only thing I can think of is the C does not invite both A & B instead it just invites one party and the other invites his peer - this is again within the parameters of the conferencing extensions for SIP - just that I am not sure if in your scenario, you are willing to put the intelligence into the UA to be able to send a replaces to its peer if it is switching a dialog . regds arjun --=20 Arjun Roychowdhury _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Thu Jun 16 10:56:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Divmt-0000pP-5Z; Thu, 16 Jun 2005 10:56:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Divmn-0000pF-3N for sipping@megatron.ietf.org; Thu, 16 Jun 2005 10:56:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28686 for ; Thu, 16 Jun 2005 10:55:59 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Diw9d-0004yf-2t for sipping@ietf.org; Thu, 16 Jun 2005 11:19:42 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id 5DF356C019 for ; Thu, 16 Jun 2005 10:55:51 -0400 (EDT) From: "Dale Worley" To: "'Sipping (E-mail)'" Subject: RE: [Sipping] Inserting a B2BUA into an existing dialog Date: Thu, 16 Jun 2005 10:54:16 -0400 Message-ID: <004a01c57283$45504d60$6a01010a@keywest> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org > From: Arjun Roychowdhury [mailto:arjunrc@gmail.com] > > > > If you want C to indicate to A & B that its a dialog > replacement, then > > > C can send invites with the replaces header > > > > It could, but consider what happens when A processes the > INVITE/Replaces -- > > It sends a BYE on the A-B dialog. If B receives the BYE > and processes it > > before its INVITE/Replaces arrives from C, the user at B > perceives that the > > call was dropped. > > No - If B receives a Replaces header with an INVITE (either from C or > A), that is an indication to B that the existing dialog is being > replaced by another - that is not the same as dropping call. That's true, but only if the dialog that the Replaces refers to exists at that moment. But if C sends an INVITE/Replaces to A, A may manage to get a BYE sent to B before C sends an INVITE/Replaces to B. Thus, B terminates the A-B dialog *before* it receives the INVITE/Replaces from C. > To avoid this, the only thing I can > think of is the C does not invite both A & B instead it just invites > one party and the other invites his peer - this is again within the > parameters of the conferencing extensions for SIP - just that I am not > sure if in your scenario, you are willing to put the intelligence into > the UA to be able to send a replaces to its peer if it is switching a > dialog . The problem with this idea is that there is no currently defined way to instruct a UA to do this. Dale _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Thu Jun 16 11:46:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiwZo-0005WF-Ee; Thu, 16 Jun 2005 11:46:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiwZm-0005W7-JJ for sipping@megatron.ietf.org; Thu, 16 Jun 2005 11:46:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03684 for ; Thu, 16 Jun 2005 11:46:36 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Diwwh-0008BF-Ps for sipping@ietf.org; Thu, 16 Jun 2005 12:10:24 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 16 Jun 2005 08:46:32 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5GFkPi9026097; Thu, 16 Jun 2005 11:46:30 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 11:46:29 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 11:46:29 -0400 Message-ID: <42B19ED4.2010600@cisco.com> Date: Thu, 16 Jun 2005 11:46:28 -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: Dale Worley Subject: Re: [Sipping] Inserting a B2BUA into an existing dialog References: <003201c57274$1443af00$6a01010a@keywest> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jun 2005 15:46:29.0414 (UTC) FILETIME=[8FD5E460:01C5728A] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: "'Sipping \(E-mail\)'" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Dale Worley wrote: >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> >>The obvious question is: How would C know to do that? Either C is >>already in cooperation with A or B, or else C is operated by >>the user of >>A or B. >> >>The other obvious reaction is that you are trying to institutionalize >>wire tapping. That won't make you popular. (Well, maybe with the FBI, >>but not with people here.) > > > One possibility is that C is the attendant console in an office PBX, and > e.g. the attendant is setting up a conference call. possible > Another possibility is that A's UA does not have a conference bridge > capability, but by hitting some keys, a second call can be placed from the > UA to a conference bridge device to activate it. The conference bridge > device then needs to direct (dumb) UAs A and B to finish the conference > set-up. Might work in some cases. But is also likely that other things will go amiss in this case. A-B call is on hold while calling the bridge device. Depending on how it does hold, bridge may not be able to figure out the dialog. Or, since this requires multiple calls from A, maybe there is more than one call on hold and the bridge is confused about which one to conference. Nevertheless, will just assume there are plausible cases. >>How about: >> >>- C subscribes to dialog event package for both A and B >> (probably already did to know it wants to do this) >>- C sends an INVITE/Replaces to A with no offer. >>- A responds to the invite with offer SDP1 > > A sends BYE to B. It would be very unwise of B to send the BYE at this time, since the invite/replaces hasn't yet succeeded and could still fail. In most transfer scenarios the BYE is done quite late. >>- C then sends INVITE/Replaces to B with SDP1 > > > B responds "No such dialog". If A waited, as it should, before doing the BYE, then this won't happen. Paul > Dale > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Thu Jun 16 11:49:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiwcZ-0005tJ-Gn; Thu, 16 Jun 2005 11:49:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiwcX-0005tE-Op for sipping@megatron.ietf.org; Thu, 16 Jun 2005 11:49:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04021 for ; Thu, 16 Jun 2005 11:49:27 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiwzS-0008N2-4I for sipping@ietf.org; Thu, 16 Jun 2005 12:13:15 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 16 Jun 2005 11:49:24 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5GFn2VH016706; Thu, 16 Jun 2005 11:49:21 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 11:49:15 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 11:49:15 -0400 Message-ID: <42B19F79.2090701@cisco.com> Date: Thu, 16 Jun 2005 11:49:13 -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: Dale Worley Subject: Re: [Sipping] Dialog event packages References: <003301c57274$86690710$6a01010a@keywest> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jun 2005 15:49:15.0333 (UTC) FILETIME=[F2BB1F50:01C5728A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: "'Sipping \(E-mail\)'" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Dale Worley wrote: >>That the endpoint put whatever they want. For example purposes I am >>inclined to use something pseudo-random like >> >> sip:xyzzy@@10.1.1.254 >> >>or something that correlates differently, such as: >> >> sip:line1@10.1.1.254 >> sip:line2@10.1.1.254 > > > A lot of SIP phones seem to use URIs like "sip:name@10.1.1.1;line=xuoslslk". And that too is fine. The point is that they can indeed put whatever they want. Nobody else should make any assumptions about how an endpoint names its contacts. Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Thu Jun 16 11:55:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Diwik-0000My-0u; Thu, 16 Jun 2005 11:55:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Diwii-0000MH-IW for sipping@megatron.ietf.org; Thu, 16 Jun 2005 11:55:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04995 for ; Thu, 16 Jun 2005 11:55:50 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dix5e-0000RI-4w for sipping@ietf.org; Thu, 16 Jun 2005 12:19:38 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id 7F13B6C02B for ; Thu, 16 Jun 2005 11:55:51 -0400 (EDT) From: "Dale Worley" To: "'Sipping (E-mail)'" Subject: RE: [Sipping] Inserting a B2BUA into an existing dialog Date: Thu, 16 Jun 2005 11:54:58 -0400 Message-ID: <000101c5728b$c02afaf0$6a01010a@keywest> 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 CWS, Build 9.0.2416 (9.0.2910.0) In-reply-to: <42B19ED4.2010600@cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > A sends BYE to B. > > It would be very unwise of B to send the BYE at this time, since the > invite/replaces hasn't yet succeeded and could still fail. In most > transfer scenarios the BYE is done quite late. Well, once A has received the INVITE/Replaces and sent the 200, I see no specification requirement that it cannot send the BYE on the replaced dialog immediately. Dale _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Thu Jun 16 13:02:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dixkn-00017h-8l; Thu, 16 Jun 2005 13:02:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dixkl-00017X-7X for sipping@megatron.ietf.org; Thu, 16 Jun 2005 13:02:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11048 for ; Thu, 16 Jun 2005 13:02:01 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Diy7g-0004eG-89 for sipping@ietf.org; Thu, 16 Jun 2005 13:25:49 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 16 Jun 2005 10:01:56 -0700 X-IronPort-AV: i="3.93,204,1115017200"; d="scan'208"; a="644061113:sNHT28046988" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5GH1m7n026837; Thu, 16 Jun 2005 10:01:51 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 13:01:37 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 13:01:36 -0400 Message-ID: <42B1B06F.8070403@cisco.com> Date: Thu, 16 Jun 2005 13:01:35 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dale Worley Subject: Re: [Sipping] Inserting a B2BUA into an existing dialog References: <000101c5728b$c02afaf0$6a01010a@keywest> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jun 2005 17:01:37.0001 (UTC) FILETIME=[0E911590:01C57295] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: "'Sipping \(E-mail\)'" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Dale Worley wrote: >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> >> >>>A sends BYE to B. >> >>It would be very unwise of B to send the BYE at this time, since the >>invite/replaces hasn't yet succeeded and could still fail. In most >>transfer scenarios the BYE is done quite late. > > > Well, once A has received the INVITE/Replaces and sent the 200, I see no > specification requirement that it cannot send the BYE on the replaced dialog > immediately. I don't believe there is any specification *requirement* that it send a BYE at all, although that is the implication. There isn't any indication of when. In this case the UA can't switch media over to the new dialog until it gets an answer to its offer. Until then, while it MAY send a bye on the old dialog it would be unwise to do so, because it then will have no place to send media. Of course, some devices may be unwise. And in that case the call flow I suggested won't work. Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Fri Jun 17 00:40:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj8eS-0003Y8-Lf; Fri, 17 Jun 2005 00:40:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj8eM-0003Y3-Be for sipping@megatron.ietf.org; Fri, 17 Jun 2005 00:40:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19495 for ; Fri, 17 Jun 2005 00:40:08 -0400 (EDT) Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj91N-0000ti-3a for sipping@ietf.org; Fri, 17 Jun 2005 01:04:02 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Fri, 17 Jun 2005 06:40:06 +0200 Received: by S4DE8PSAANQ.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Jun 2005 06:39:22 +0200 Message-Id: From: "Jesske, R" To: pkyzivat@cisco.com, sipping@ietf.org Subject: AW: [Sipping] Re: I-D ACTION:draft-jesske-sipping-tispan-requirem ents-01.txt Date: Fri, 17 Jun 2005 06:39:21 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Tank you for your comments > -----Urspr=FCngliche Nachricht----- > Von: sipping-bounces@ietf.org=20 > [mailto:sipping-bounces@ietf.org] Im Auftrag von Paul Kyzivat > Gesendet: Donnerstag, 16. Juni 2005 00:40 > An: 'Sipping (E-mail)' > Betreff: [Sipping] Re: I-D=20 > ACTION:draft-jesske-sipping-tispan-requirements-01.txt >=20 >=20 > Thank you - this version is much more to the point than the prior = one! >=20 > I still find some context lacking for interpretting what is being=20 > requested. Primarily I don't understand who these requirements are=20 > intended to apply to. It seems that you are seeking=20 > mechanisms that can=20 > be used to carry out the simulation requirments. But these mechanisms = > will have to be deployed in some operating environment to be=20 > effective.=20 The operating environment is the TISPAN IMS Architecture that is based = on the Architecture of 3GPP. The Services are processed within an = Application Server. > And what your assumptions are about that will influence the kinds of=20 > mechanisms that are suitable. We tried to express what is needed from a UA's and AS. E.g CCBS = (Communication Completion on Busy Subscriber) needs additional = mechanisms from UA's and AS.=20 Would it be useful to have such kind of Architecture within the = requirements draft? >=20 > Pretty much all of these requirements involve the cooperation of=20 > multiple parties - either a caller and a callee, caller and=20 > some network=20 > component, or callee and some network component. Are you satisfied to = > have these features work only when all parties in the call cooperate? At least we want to have such features to interoperate proper with the = PSTN/ISDN where it is needed.=20 >=20 > For instance, consider [REQ-CDIV-1] and [REQ-CDIV-3]. If the=20 > callee does=20 > not cooperate and diverts the call without the proper=20 > indications then=20 > it will be impossible to meet the requirements.=20 We know of course that there are several possibilities to divert a = communication like 302 or divert it directly by a UA. Our Services will = run on an Application Server that reacts on behalf of the UA. For CDIV we are using the History Draft. Of course if a UA diverts = directly without including a History the Caller will never informed = about the diversion. But if the network does it then the caller will be = informed. Within the PSTN/ISDN we have the same possibilities. The simulation services we are defining in TISPAN are network based = services. For that we are looking for new or existing SIP mechanisms to = fulfil our requirements. >Are you seeking=20 > something that is intended to apply to all sip implementation=20 > in order=20 > to make your service work? Or are you willing to have it only=20 > work with=20 > cooperative callees. (Note that it is generally impossible to=20 > guarantee=20 > that all callees will cooperate unless you have physical=20 > control of all=20 > components including the endpoints. As you said we never will have the full control of callees and callers. = Neither in the PSTN/ISDN nor in the NGN. But we (Operators) want to = have the ability to provide services to our customers as we do it = within the PSTN/ISDN network.=20 >=20 > So it would be helpful to have some indication of the kinds of=20 > restrictions you are prepared to impose on the system for=20 > these features=20 > to be fully operable. And if you would like to allow=20 > different classes=20 > of restrictions, and corresponding differences in features, then that = > would also be useful to know. That depend on the operator what kind of restrictions he want to set on = the customers. E.g allowing 302 for redirection or creating a Reason = Header including a Cause Value.=20 More important is that the operator has the ability to set restrictions = or not. In some cases we need restrictions or correct handling like regulatory = services like ACR (Anonymous Communication Rejection) or MCID = (Malicious Communication Identification). In other cases we have the = choice (Operator depended) to allow different possibilities like CDIV. I hope this helps a little. We hope that we can come up within the next week with a analysis draft = of the services and the thoughts we have about possible mechanisme to = fulfill the requirements. We try to describe and include all coments we = get.=20 =20 Thank you=20 Roland >=20 > Thanks, > Paul >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP >=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Fri Jun 17 11:29:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjImZ-0002Y9-Bv; Fri, 17 Jun 2005 11:29:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjImW-0002Y1-Df for sipping@megatron.ietf.org; Fri, 17 Jun 2005 11:29:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27279 for ; Fri, 17 Jun 2005 11:29:17 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjJ9c-0004iE-Ud for sipping@ietf.org; Fri, 17 Jun 2005 11:53:14 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 17 Jun 2005 08:29:09 -0700 X-IronPort-AV: i="3.93,208,1115017200"; d="scan'208"; a="280016376:sNHT32157476" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5HFSKU2004232; Fri, 17 Jun 2005 08:29:05 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Jun 2005 11:28:58 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Jun 2005 11:28:57 -0400 Message-ID: <42B2EC39.3060402@cisco.com> Date: Fri, 17 Jun 2005 11:28:57 -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: "Jesske, R" Subject: Re: AW: [Sipping] Re: I-D ACTION:draft-jesske-sipping-tispan-requirem ents-01.txt References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 17 Jun 2005 15:28:57.0959 (UTC) FILETIME=[47885770:01C57351] X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA27279 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org More inline. Paul Jesske, R wrote: > Tank you for your comments >=20 >=20 >>-----Urspr=FCngliche Nachricht----- >>Von: sipping-bounces@ietf.org=20 >>[mailto:sipping-bounces@ietf.org] Im Auftrag von Paul Kyzivat >>Gesendet: Donnerstag, 16. Juni 2005 00:40 >>An: 'Sipping (E-mail)' >>Betreff: [Sipping] Re: I-D=20 >>ACTION:draft-jesske-sipping-tispan-requirements-01.txt >> >> >>Thank you - this version is much more to the point than the prior one! >> >>I still find some context lacking for interpretting what is being=20 >>requested. Primarily I don't understand who these requirements are=20 >>intended to apply to. It seems that you are seeking=20 >>mechanisms that can=20 >>be used to carry out the simulation requirments. But these mechanisms=20 >>will have to be deployed in some operating environment to be=20 >>effective.=20 >=20 > The operating environment is the TISPAN IMS Architecture that is based = on the Architecture of 3GPP. The Services are processed within an Applica= tion Server. >=20 >=20 >>And what your assumptions are about that will influence the kinds of=20 >>mechanisms that are suitable. >=20 >=20 > We tried to express what is needed from a UA's and AS. E.g CCBS (Commun= ication Completion on Busy Subscriber) needs additional mechanisms from U= A's and AS.=20 >=20 > Would it be useful to have such kind of Architecture within the require= ments draft? I think it would be helpful to have something to set the context within=20 which the requirements and their solutions are expected to apply. The=20 value will be best if this can be expressed concisely. It doesn't have=20 to be exactly the environment you intend - it ideally will be an=20 abstraction of that. >>Pretty much all of these requirements involve the cooperation of=20 >>multiple parties - either a caller and a callee, caller and=20 >>some network=20 >>component, or callee and some network component. Are you satisfied to=20 >>have these features work only when all parties in the call cooperate? >=20 > At least we want to have such features to interoperate proper with the = PSTN/ISDN where it is needed.=20 Well, I suppose you might assume that the gateways to the PSTN/ISDN will=20 be cooperative. But that often will only be one of the parties in the=20 call. E.g. suppose the gateway is the callee and the caller is an=20 uncooperative sip UA. You might not be able to accurately simulate all=20 the features that the PSTN end wants. Is that OK? Or would you require=20 that uncooperative callers not be allowed to use the gateway? >>For instance, consider [REQ-CDIV-1] and [REQ-CDIV-3]. If the=20 >>callee does=20 >>not cooperate and diverts the call without the proper=20 >>indications then=20 >>it will be impossible to meet the requirements.=20 >=20 >=20 > We know of course that there are several possibilities to divert a comm= unication like 302 or divert it directly by a UA. Our Services will run o= n an Application Server that reacts on behalf of the UA. > For CDIV we are using the History Draft. Of course if a UA diverts dire= ctly without including a History the Caller will never informed about the= diversion. But if the network does it then the caller will be informed. = Within the PSTN/ISDN we have the same possibilities. So you are willing to accept that diversion information may not always=20 be provided if the called party is not cooperative? > The simulation services we are defining in TISPAN are network based ser= vices. For that we are looking for new or existing SIP mechanisms to fulf= il our requirements. >=20 >>Are you seeking=20 >>something that is intended to apply to all sip implementation=20 >>in order=20 >>to make your service work? Or are you willing to have it only=20 >>work with=20 >>cooperative callees. (Note that it is generally impossible to=20 >>guarantee=20 >>that all callees will cooperate unless you have physical=20 >>control of all=20 >>components including the endpoints. >=20 >=20 > As you said we never will have the full control of callees and callers.= Neither in the PSTN/ISDN nor in the NGN. But we (Operators) want to have= the ability to provide services to our customers as we do it within the = PSTN/ISDN network.=20 >=20 >=20 >>So it would be helpful to have some indication of the kinds of=20 >>restrictions you are prepared to impose on the system for=20 >>these features=20 >>to be fully operable. And if you would like to allow=20 >>different classes=20 >>of restrictions, and corresponding differences in features, then that=20 >>would also be useful to know. >=20 >=20 > That depend on the operator what kind of restrictions he want to set on= the customers. E.g allowing 302 for redirection or creating a Reason Hea= der including a Cause Value.=20 > More important is that the operator has the ability to set restrictions= or not. Well, the operator has the ability to *try* to set restrictions. Unless all the equipment is managed by the operator and is tamper proof=20 there is the possibility that user equipment may violate the restrictions. The only other sure way is to implement all the required aspects of the=20 services in the network, in components that cannot be bypassed. > In some cases we need restrictions or correct handling like regulatory = services like ACR (Anonymous Communication Rejection) or MCID (Malicious = Communication Identification). In other cases we have the choice (Operato= r depended) to allow different possibilities like CDIV. > I hope this helps a little. >=20 > We hope that we can come up within the next week with a analysis draft = of the services and the thoughts we have about possible mechanisme to ful= fill the requirements. We try to describe and include all coments we get.= =20 > =20 > Thank you=20 > Roland >=20 >=20 >=20 >=20 >=20 >> Thanks, >> 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 >> >=20 >=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Fri Jun 17 13:36:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjKlD-0001Gf-Gl; Fri, 17 Jun 2005 13:36:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjKlC-0001Ga-Fl for sipping@megatron.ietf.org; Fri, 17 Jun 2005 13:36:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07119 for ; Fri, 17 Jun 2005 13:36:05 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjL8K-0005Id-GD for sipping@ietf.org; Fri, 17 Jun 2005 14:00:01 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id A71646C017 for ; Fri, 17 Jun 2005 13:35:59 -0400 (EDT) From: "Dale Worley" To: "'Sipping (E-mail)'" Subject: RE: [Sipping] Inserting a B2BUA into an existing dialog Date: Fri, 17 Jun 2005 13:35:05 -0400 Message-ID: <004b01c57362$e6a5ec30$6a01010a@keywest> 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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: <42A9F377.5070600@cisco.com> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org So it would seem that the minimal feature a UA needs to allow this operation is: Define a new "hold" parameter for the Replaces: header. If it is present, the UAS that receives it, when accepting the INVITE, should not immediately terminate the dialog being replaced, but "put it on hold". If that dialog is not terminated by the other end after (say) 30 seconds, the UA may terminate it. That's satisfyingly simple, at least. Dale _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Fri Jun 17 15:09:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjMDq-0008Od-GR; Fri, 17 Jun 2005 15:09:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjMDo-0008Lt-PV for sipping@megatron.ietf.org; Fri, 17 Jun 2005 15:09:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14460 for ; Fri, 17 Jun 2005 15:09:42 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjMax-0003ad-Jq for sipping@ietf.org; Fri, 17 Jun 2005 15:33:40 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-4.cisco.com with ESMTP; 17 Jun 2005 12:09:30 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5HJ92o2023884; Fri, 17 Jun 2005 15:09:27 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Jun 2005 15:09:21 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Jun 2005 15:09:20 -0400 Message-ID: <42B31FE0.909@cisco.com> Date: Fri, 17 Jun 2005 15:09:20 -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: Dale Worley Subject: Re: [Sipping] Inserting a B2BUA into an existing dialog References: <004b01c57362$e6a5ec30$6a01010a@keywest> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jun 2005 19:09:20.0924 (UTC) FILETIME=[1108ADC0:01C57370] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: "'Sipping \(E-mail\)'" X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org I don't think you even need that much. What is needed is a clarification that when receiving an INVITE/Replaces, you should not terminate the replaced dialog until you have at least completed the offer/answer seqeuence for the replacement dialog. Paul Dale Worley wrote: > So it would seem that the minimal feature a UA needs to allow this operation > is: > > Define a new "hold" parameter for the Replaces: header. If it is present, > the UAS that receives it, when accepting the INVITE, should not immediately > terminate the dialog being replaced, but "put it on hold". If that dialog > is not terminated by the other end after (say) 30 seconds, the UA may > terminate it. > > That's satisfyingly simple, at least. > > Dale > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Fri Jun 17 15:33:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjMac-0003sE-MD; Fri, 17 Jun 2005 15:33:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjMab-0003s9-PV for sipping@megatron.ietf.org; Fri, 17 Jun 2005 15:33:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16575 for ; Fri, 17 Jun 2005 15:33:15 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjMxk-00057Z-Q1 for sipping@ietf.org; Fri, 17 Jun 2005 15:57:14 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id 4659F6C02C for ; Fri, 17 Jun 2005 15:33:11 -0400 (EDT) From: "Dale Worley" To: "'Sipping (E-mail)'" Subject: RE: [Sipping] Inserting a B2BUA into an existing dialog Date: Fri, 17 Jun 2005 15:32:16 -0400 Message-ID: <005b01c57373$4582a3f0$6a01010a@keywest> 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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: <42B31FE0.909@cisco.com> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > I don't think you even need that much. > What is needed is a clarification that when receiving an > INVITE/Replaces, you should not terminate the replaced dialog > until you > have at least completed the offer/answer seqeuence for the > replacement > dialog. That would suffice, if the B2BUA could control the timing of its answers relative to the INVITEs it was sending out. But that might be hard to do in a layered architecture, where each INVITE transaction might be proceeding independently. Dale _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Sat Jun 18 01:30:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjVuT-0008Fh-C0; Sat, 18 Jun 2005 01:30:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjVuR-0008FW-0V for sipping@megatron.ietf.org; Sat, 18 Jun 2005 01:30:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21932 for ; Sat, 18 Jun 2005 01:30:21 -0400 (EDT) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjWHf-0000Ez-8c for sipping@ietf.org; Sat, 18 Jun 2005 01:54:24 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 18EDDAC1 for ; Sat, 18 Jun 2005 07:30:06 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sat, 18 Jun 2005 07:30:04 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sat, 18 Jun 2005 07:30:04 +0200 Received: from [131.160.126.70] (rvi2-126-70.lmf.ericsson.se [131.160.126.70]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 7BF5A2546 for ; Sat, 18 Jun 2005 08:30:04 +0300 (EEST) Message-ID: <42B3B15B.80305@ericsson.com> Date: Sat, 18 Jun 2005 08:30:03 +0300 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jun 2005 05:30:04.0877 (UTC) FILETIME=[C828E7D0:01C573C6] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Content-Transfer-Encoding: 7bit Subject: [Sipping] 63rd IETF in Paris - Important Meeting Dates X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org FYI: http://www.ietf.org/meetings/cutoff_dates_63.html 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 sipping-bounces@ietf.org Sat Jun 18 03:00:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjXJZ-0004uw-EY; Sat, 18 Jun 2005 03:00:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjXJV-0004ul-GW for sipping@megatron.ietf.org; Sat, 18 Jun 2005 03:00:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19037 for ; Sat, 18 Jun 2005 03:00:19 -0400 (EDT) Received: from web26201.mail.ukl.yahoo.com ([217.12.10.238]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DjXgi-0004jq-Ay for sipping@ietf.org; Sat, 18 Jun 2005 03:24:23 -0400 Received: (qmail 83523 invoked by uid 60001); 18 Jun 2005 07:00:02 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.it; h=Message-ID:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=K7grF6iCkUGxI4tBcDOE0YOc5ZCAiHd7OBCQt+KbQBbbdpKKqfS92iRByhvJkS6UaW+cTMyYJGdhLw2T4PUq99OX3Ul2m/RvGJ2435mkeZO9zMxmtZYo51vLGgsbYcwAFawcTMww0AK2JJeJmQW9n+jSgdUWuKycaG219pdrZq8= ; Message-ID: <20050618070002.83521.qmail@web26201.mail.ukl.yahoo.com> Received: from [82.53.94.239] by web26201.mail.ukl.yahoo.com via HTTP; Sat, 18 Jun 2005 09:00:02 CEST Date: Sat, 18 Jun 2005 09:00:02 +0200 (CEST) From: Salvatore Loreto To: sipping@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.6 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [Sipping] sipping session mobility X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: salvatore.loreto@ieee.org List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0762805874==" Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org --===============0762805874== Content-Type: multipart/alternative; boundary="0-672187435-1119078002=:83269" --0-672187435-1119078002=:83269 Content-Type: text/plain; charset=iso-8859-1 Hi all, I've a question about the simultaneous mobility, of course it is a special case of a singol host mobility: when a SIP UA changes his subnetwork and it obtains a new IP address, it send a re-INVITE message, but my question is: the REGISTER message (inorder to uptodate it location information) must be sent before or after the re-INVITE. In the case of simultaneous mobility it should be sent before. what do you think about? best regards /sal --------------------------------- Yahoo! Mail: gratis 1GB per i messaggi, antispam, antivirus, POP3 --0-672187435-1119078002=:83269 Content-Type: text/html; charset=iso-8859-1
Hi all,
 
I've a question about the simultaneous mobility, of course it is a special case of a singol host mobility:
 
when a SIP UA changes his subnetwork and it obtains a new IP address,
it send a re-INVITE message, but my question is:
 
the REGISTER message (inorder to uptodate it location information) must be sent before or after the re-INVITE.
In the case of simultaneous mobility it should be sent before.
 
what do you think about?
 
best regards
/sal

Yahoo! Mail: gratis 1GB per i messaggi, antispam, antivirus, POP3 --0-672187435-1119078002=:83269-- --===============0762805874== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============0762805874==-- From sipping-bounces@ietf.org Sat Jun 18 12:52:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjgYs-0001Ot-Ce; Sat, 18 Jun 2005 12:52:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjgYr-0001On-1J for sipping@megatron.ietf.org; Sat, 18 Jun 2005 12:52:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25698 for ; Sat, 18 Jun 2005 12:52:45 -0400 (EDT) Received: from mxout4.netvision.net.il ([194.90.9.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Djgw1-0000FZ-Iv for sipping@ietf.org; Sat, 18 Jun 2005 13:16:56 -0400 Received: from [127.0.0.1] ([212.143.127.193]) by mxout4.netvision.net.il (Sun Java System Messaging Server 6.1 HotFix 0.11 (built Jan 28 2005)) with ESMTPA id <0IIA00MRPHJAM5E0@mxout4.netvision.net.il> for sipping@ietf.org; Sat, 18 Jun 2005 19:52:23 +0300 (IDT) Date: Sat, 18 Jun 2005 18:53:13 +0200 From: Diego B Subject: Re: [Sipping] sipping session mobility In-reply-to: <20050618070002.83521.qmail@web26201.mail.ukl.yahoo.com> To: salvatore.loreto@ieee.org Message-id: <42B45179.4010006@mailvision.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <20050618070002.83521.qmail@web26201.mail.ukl.yahoo.com> User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7BIT Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Hi; If the REGISTER response change anything in the UA route information ( like Service-Route ) it may be sent before the re-INVITE. If the REGISTRAR does not change anything in the current dialog, I think the two ( REGISTRAR and re-INVITE ) may be sent in parallel. My question is now, if the REGISTER brings a new changed Service-Route, the UA may use the new route to send the re-invite ( changing in dialog routing ) or keep using the route it initially use when the dialog was created. Regards Diego B Salvatore Loreto wrote: > Hi all, > > I've a question about the simultaneous mobility, of course it is a > special case of a singol host mobility: > > when a SIP UA changes his subnetwork and it obtains a new IP address, > it send a re-INVITE message, but my question is: > > the REGISTER message (inorder to uptodate it location information) > must be sent before or after the re-INVITE. > In the case of simultaneous mobility it should be sent before. > > what do you think about? > > best regards > /sal > > ------------------------------------------------------------------------ > *Yahoo! Mail* > : > gratis 1GB per i messaggi, antispam, antivirus, POP3 > >------------------------------------------------------------------------ > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Sat Jun 18 17:05:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjkVe-0008Qe-C1; Sat, 18 Jun 2005 17:05:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjkVc-0008QW-Av for sipping@megatron.ietf.org; Sat, 18 Jun 2005 17:05:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13781 for ; Sat, 18 Jun 2005 17:05:41 -0400 (EDT) Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Djkst-000128-H4 for sipping@ietf.org; Sat, 18 Jun 2005 17:29:54 -0400 Received: (qmail 3113 invoked by uid 10); 18 Jun 2005 21:05:10 -0000 Received: (vexira-qq 03097-F0223004 invoked from network) 18 Jun 2005 23:05:10 +0200 Received: from unknown (HELO BEMBUSTER) ([81.59.101.130]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 18 Jun 2005 21:05:10 -0000 Message-ID: <001401c57449$690be8f0$6502a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: References: <20050618070002.83521.qmail@web26201.mail.ukl.yahoo.com> <42B45179.4010006@mailvision.com> Date: Sat, 18 Jun 2005 23:05:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode01.zonnet.nl) X-Spam-Score: 1.2 (+) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Subject: [Sipping] XCAP server discovery X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Hi, Suppose one would make a useragent that uses SIP for presence and XCAP for manipulation of buddy lists etc. , what would be the best way to provision the client with the URL of its XCAP server? Regards, Jeroen _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Sun Jun 19 09:36:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjzyS-0007KM-9r; Sun, 19 Jun 2005 09:36:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjzyP-0007Hn-Kv for sipping@megatron.ietf.org; Sun, 19 Jun 2005 09:36:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04436 for ; Sun, 19 Jun 2005 09:36:27 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.207]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dk0Lu-0004xX-W2 for sipping@ietf.org; Sun, 19 Jun 2005 10:00:48 -0400 Received: by wproxy.gmail.com with SMTP id 36so36079wri for ; Sun, 19 Jun 2005 06:36:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YY6oNcaZdyvESDVCPduzzwCXL34OLSoazrmCjF/3F9s6voH+2CtBb6zG1PNo3kV+l1tTlUxoKn/obvMBZsYVHADYy3c8OhKtvKHo+3xGpH3MsZ3yOSjXCDFva7Cf8/I+6r7kU6ZHycrUrXjRPfMjXQCyx8wGzjsusu4PHlkUTWY= Received: by 10.54.59.36 with SMTP id h36mr591wra; Sun, 19 Jun 2005 06:36:16 -0700 (PDT) Received: by 10.54.17.77 with HTTP; Sun, 19 Jun 2005 06:36:16 -0700 (PDT) Message-ID: Date: Sun, 19 Jun 2005 09:36:16 -0400 From: Arjun Roychowdhury To: Jeroen van Bemmel Subject: Re: [Sipping] XCAP server discovery In-Reply-To: <001401c57449$690be8f0$6502a8c0@BEMBUSTER> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050618070002.83521.qmail@web26201.mail.ukl.yahoo.com> <42B45179.4010006@mailvision.com> <001401c57449$690be8f0$6502a8c0@BEMBUSTER> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Arjun Roychowdhury List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Hi, most implementations I know of today provision the UA with the XCAP services root URI. Once the root URI is known, since XCAP mandates that documents are organized according to a defined hierarchy, the UA can then navigate to the exact service that is required. I am personally not aware of any best practices to dynamically identify the XCAP URI but I guess something like ${domain}/services may not be a bad idea where ${domain} is the domain that is servicing the User Agent. regds arjun On 6/18/05, Jeroen van Bemmel wrote: > Hi, >=20 > Suppose one would make a useragent that uses SIP for presence and XCAP fo= r > manipulation of buddy lists etc. , what would be the best way to provisio= n > the client with the URL of its XCAP server? >=20 > Regards, >=20 > Jeroen >=20 >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP >=20 --=20 Arjun Roychowdhury _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Sun Jun 19 12:40:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dk2qW-0005in-4t; Sun, 19 Jun 2005 12:40:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dk2qT-0005fG-No for sipping@megatron.ietf.org; Sun, 19 Jun 2005 12:40:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17955 for ; Sun, 19 Jun 2005 12:40:24 -0400 (EDT) Received: from web26204.mail.ukl.yahoo.com ([217.12.10.241]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dk3Dv-0000Dq-QU for sipping@ietf.org; Sun, 19 Jun 2005 13:04:47 -0400 Received: (qmail 52113 invoked by uid 60001); 19 Jun 2005 16:40:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.it; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=dEg0WMyGtpAdcaHKz8U+PZdbB5PTy+L+4/2HzILkZSr3Fhliv8VbsKoHWVceCfj1NoH8xbOI2Bi+alchumXB3Lh9oIxryuzGDJn/9L2+kUTKhUR6F5L/F3i9pr8meWh5GJ7ifJ4PffskYj7XVfOiihK4lAnT7MOHT5XDQqurT54= ; Message-ID: <20050619164014.52111.qmail@web26204.mail.ukl.yahoo.com> Received: from [82.49.199.248] by web26204.mail.ukl.yahoo.com via HTTP; Sun, 19 Jun 2005 18:40:13 CEST Date: Sun, 19 Jun 2005 18:40:13 +0200 (CEST) From: Salvatore Loreto Subject: Re: [Sipping] sipping session mobility To: Diego B In-Reply-To: <42B45179.4010006@mailvision.com> MIME-Version: 1.0 X-Spam-Score: 2.9 (++) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: salvatore.loreto@ieee.org List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1124133175==" Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org --===============1124133175== Content-Type: multipart/alternative; boundary="0-1543723965-1119199213=:48719" --0-1543723965-1119199213=:48719 Content-Type: text/plain; charset=iso-8859-1 Hi Diego, your underline a problem I didn't think about. My scenario is both the UA involved in the session move in the same time in two different network and both bring a new IP address. In this scenario if each UA try to send a re-Invite before a new Register message with the new location information the new re-Invite fails. So maybe in this situation a new Register must be sent before an new re-INVITE... and I think send both messages in parallel is not a good idea. Anyway, about the case the new IP address involve a new Service Route , maybe you think the case a new Sip Server is added to the signaling Route, i think a possibile solution could be the new Sip Server forward the signaling the old one. What do you think about? regards /Sal Diego B ha scritto: Hi; If the REGISTER response change anything in the UA route information ( like Service-Route ) it may be sent before the re-INVITE. If the REGISTRAR does not change anything in the current dialog, I think the two ( REGISTRAR and re-INVITE ) may be sent in parallel. My question is now, if the REGISTER brings a new changed Service-Route, the UA may use the new route to send the re-invite ( changing in dialog routing ) or keep using the route it initially use when the dialog was created. Regards Diego B Salvatore Loreto wrote: > Hi all, > > I've a question about the simultaneous mobility, of course it is a > special case of a singol host mobility: > > when a SIP UA changes his subnetwork and it obtains a new IP address, > it send a re-INVITE message, but my question is: > > the REGISTER message (inorder to uptodate it location information) > must be sent before or after the re-INVITE. > In the case of simultaneous mobility it should be sent before. > > what do you think about? > > best regards > /sal > > ------------------------------------------------------------------------ > *Yahoo! Mail* > : > gratis 1GB per i messaggi, antispam, antivirus, POP3 > >------------------------------------------------------------------------ > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --------------------------------- Yahoo! Mail: gratis 1GB per i messaggi, antispam, antivirus, POP3 --0-1543723965-1119199213=:48719 Content-Type: text/html; charset=iso-8859-1
Hi Diego,
 
your underline a problem I didn't think about.
My scenario is both the UA involved in the session move in the same time in two different network and both bring a new IP address.
 
In this scenario if each UA try to send a re-Invite before a new Register message with the new location information the new re-Invite fails.
So maybe in this situation a new Register must be sent before an new re-INVITE... and I think send both messages in parallel is not a good idea.
 
Anyway, about the case the new IP address involve a new Service Route , maybe you think the case a new Sip Server is added to the signaling Route,
i think a possibile solution could be the new Sip Server forward the signaling the old one.
What do you think about?
 
regards
/Sal


Diego B <diegob@mailvision.com> ha scritto:
Hi;
If the REGISTER response change anything in the UA route information (
like Service-Route ) it may be sent before the re-INVITE.

If the REGISTRAR does not change anything in the current dialog, I think
the two ( REGISTRAR and re-INVITE ) may be sent in parallel.

My question is now, if the REGISTER brings a new changed Service-Route,
the UA may use the new route to send
the re-invite ( changing in dialog routing ) or keep using the route it
initially use when the dialog was created.



Regards
Diego B


Salvatore Loreto wrote:

> Hi all,
>
> I've a question about the simultaneous mobility, of course it is a
> special case of a singol host mobility:
>
> when a SIP UA changes his subnetwork and it obtains a new IP address,
> it send a re-INVITE message, but my question is:
>
> the REGISTER message (inorder to uptodate it location information)
> must be sent before or after the re-INVITE.
> In the case of simultaneous mobility it should be sent before.
>
> what do you think about?
>
> best regards
> /sal
>
> ------------------------------------------------------------------------
> *Yahoo! Mail*
> :
> gratis 1GB per i messaggi, antispam, antivirus, POP3
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
>This list is for NEW development of the application of SIP
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sip@ietf.org for new developments of core SIP
>
>



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

Yahoo! Mail: gratis 1GB per i messaggi, antispam, antivirus, POP3 --0-1543723965-1119199213=:48719-- --===============1124133175== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============1124133175==-- From sipping-bounces@ietf.org Sun Jun 19 14:42:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dk4kA-00037M-Ug; Sun, 19 Jun 2005 14:42:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dk4k7-000372-2l for sipping@megatron.ietf.org; Sun, 19 Jun 2005 14:42:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25972 for ; Sun, 19 Jun 2005 14:42:01 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dk57c-0002wN-R2 for sipping@ietf.org; Sun, 19 Jun 2005 15:06:24 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3519CA4D; Sun, 19 Jun 2005 20:41:29 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sun, 19 Jun 2005 20:41:28 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sun, 19 Jun 2005 20:41:28 +0200 Received: from [131.160.126.14] (rvi2-126-14.lmf.ericsson.se [131.160.126.14]) by mail.lmf.ericsson.se (Postfix) with ESMTP id AB825254F; Sun, 19 Jun 2005 21:41:27 +0300 (EEST) Message-ID: <42B5BC55.80607@ericsson.com> Date: Sun, 19 Jun 2005 21:41:25 +0300 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jun 2005 18:41:28.0464 (UTC) FILETIME=[80FF0900:01C574FE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , Jon Peterson , "James M. Polk" , Dean Willis Subject: [Sipping] WGLC: draft-ietf-sipping-trait-authz-01.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Folks, we would like to working group last call the following draft: http://www.ietf.org/internet-drafts/draft-ietf-sipping-trait-authz-01.txt This WGLC will finish on July 8th. Please, send your comments to the authors and to the list. Thanks, Gonzalo SIPPING co-chair _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Sun Jun 19 15:59:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dk5wc-0004Rh-Ip; Sun, 19 Jun 2005 15:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dk5wb-0004RT-42 for sipping@megatron.ietf.org; Sun, 19 Jun 2005 15:59:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02527 for ; Sun, 19 Jun 2005 15:58:59 -0400 (EDT) Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dk6K8-0004rz-My for sipping@ietf.org; Sun, 19 Jun 2005 16:23:23 -0400 Received: (qmail 11133 invoked by uid 10); 19 Jun 2005 19:58:48 -0000 Received: (vexira-qq 11109-FBB0A4DD invoked from network) 19 Jun 2005 21:58:48 +0200 Received: from unknown (HELO BEMBUSTER) ([81.59.101.130]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 19 Jun 2005 19:58:48 -0000 Message-ID: <003901c57509$4cf33590$6502a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "sipping" References: <42B5BC55.80607@ericsson.com> Subject: Re: [Sipping] WGLC: draft-ietf-sipping-trait-authz-01.txt Date: Sun, 19 Jun 2005 21:58:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode02.zonnet.nl) X-Spam-Score: 1.2 (+) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Hi, I am posting an open question as a comment: how do you see interaction between this and session policies (http://www.ietf.org/internet-drafts/draft-ietf-sipping-session-indep-policy-02.txt) Here's one example of how it could work: using the session policies framework a proxy can direct a UA to a policy server to obtain a session policy. The UA retrieves the policy, should adjust its INVITE SDP and re-submits the request, this time adding a header to indicate that it visited the policy server. That presents an open issue: how does the proxy determine that the UAC now indeed conforms to the policy? In the current draft, policy enforcement is considered out-of-scope. However, I think that a trait-based authorization token could solve this, i.e. the policy server could return the policy as a signed token (or return a separate token along with the policy), and the client would have to send this token along to the proxy. The proxy would inspect the token, confirm that it comes from a trusted source and use it as a basis to enforce the policy We have been experimenting with this in the context of Web services. One of the things we found is that communicating policies following the current standards (i.e. signed SAML assertions) leads to very verbose, large documents. You may want to consider this in your requirements (and it gets even worse with multiple assertions), I expect that adding such an assertion to a SIP request easily makes it larger than the magic 1300 bytes size for UDP transports. Regards, Jeroen van Bemmel, Lucent Technologies ----- Original Message ----- From: "Gonzalo Camarillo" To: "sipping" Cc: "Rohan Mahy" ; "Jon Peterson" ; "James M. Polk" ; "Dean Willis" Sent: Sunday, June 19, 2005 8:41 PM Subject: [Sipping] WGLC: draft-ietf-sipping-trait-authz-01.txt > Folks, > > we would like to working group last call the following draft: > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-trait-authz-01.txt > > This WGLC will finish on July 8th. Please, send your comments to the > authors and to the list. > > Thanks, > > Gonzalo > SIPPING co-chair > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Mon Jun 20 03:20:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkGaI-0000cz-7o; Mon, 20 Jun 2005 03:20:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkGaG-0000cu-Dp for sipping@megatron.ietf.org; Mon, 20 Jun 2005 03:20:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01493 for ; Mon, 20 Jun 2005 03:20:38 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkGxv-00012t-Jt for sipping@ietf.org; Mon, 20 Jun 2005 03:45:08 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j5K7KJdX020173; Mon, 20 Jun 2005 09:20:19 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j5K7KJ18022555; Mon, 20 Jun 2005 09:20:19 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 20 Jun 2005 09:20:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Sipping] WGLC: draft-ietf-sipping-trait-authz-01.txt Date: Mon, 20 Jun 2005 09:18:02 +0200 Message-ID: Thread-Topic: [Sipping] WGLC: draft-ietf-sipping-trait-authz-01.txt Thread-Index: AcV1CXJOu9SLWSOnQP+Kgbn7slDUkAAXg09w From: "Tschofenig, Hannes" To: "Jeroen van Bemmel" , "sipping" X-OriginalArrivalTime: 20 Jun 2005 07:20:09.0805 (UTC) FILETIME=[7DD46FD0:01C57568] X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org hi jeroen,=20 please find a comment below:=20 > -----Urspr=FCngliche Nachricht----- > Von: sipping-bounces@ietf.org=20 > [mailto:sipping-bounces@ietf.org] Im Auftrag von Jeroen van Bemmel > Gesendet: Sonntag, 19. Juni 2005 21:59 > An: sipping > Betreff: Re: [Sipping] WGLC: draft-ietf-sipping-trait-authz-01.txt >=20 >=20 > Hi, >=20 > I am posting an open question as a comment: how do you see=20 > interaction=20 > between this and session policies=20 > (http://www.ietf.org/internet-drafts/draft-ietf-sipping-sessio > n-indep-policy-02.txt) >=20 > Here's one example of how it could work: using the session policies=20 > framework a proxy can direct a UA to a policy server to=20 > obtain a session=20 > policy. The UA retrieves the policy, should adjust its INVITE SDP and=20 > re-submits the request, this time adding a header to indicate that it=20 > visited the policy server. That presents an open issue: how=20 > does the proxy=20 > determine that the UAC now indeed conforms to the policy? >=20 > In the current draft, policy enforcement is considered out-of-scope.=20 > However, I think that a trait-based authorization token could=20 > solve this,=20 > i.e. the policy server could return the policy as a signed=20 > token (or return=20 > a separate token along with the policy), and the client would=20 > have to send=20 > this token along to the proxy. The proxy would inspect the=20 > token, confirm=20 > that it comes from a trusted source and use it as a basis to=20 > enforce the=20 > policy this seems to be right. >=20 > We have been experimenting with this in the context of Web=20 > services. > One of=20 > the things we found is that communicating policies following=20 > the current=20 > standards (i.e. signed SAML assertions) leads to very verbose, large=20 > documents. it depends on the content of the assertion (and whether you use = assertions at all).=20 if you use xml document then everything tends to grow in size. if you use an artifact then the size of the "token" is very small, in = fact it is only a pointer to the assertions itself.=20 > You may want to consider this in your requirements=20 > (and it gets=20 > even worse with multiple assertions), I expect that adding=20 > such an assertion=20 > to a SIP request easily makes it larger than the magic 1300=20 > bytes size for=20 > UDP transports. udp transport and the usage of xml does not nicely play together. the = artifact would offer a nice tradeoff. =20 ciao hannes >=20 > Regards, >=20 > Jeroen van Bemmel, Lucent Technologies >=20 > ----- Original Message -----=20 > From: "Gonzalo Camarillo" > To: "sipping" > Cc: "Rohan Mahy" ; "Jon Peterson"=20 > ; "James M. Polk" ; "Dean=20 > Willis" > Sent: Sunday, June 19, 2005 8:41 PM > Subject: [Sipping] WGLC: draft-ietf-sipping-trait-authz-01.txt >=20 >=20 > > Folks, > > > > we would like to working group last call the following draft: > > > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-sipping-trait-a uthz-01.txt > > This WGLC will finish on July 8th. Please, send your comments to the > authors and to the list. > > Thanks, > > Gonzalo > SIPPING co-chair > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Mon Jun 20 06:31:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkJZ7-0005Ah-Md; Mon, 20 Jun 2005 06:31:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkJZ5-0005Ac-MR for sipping@megatron.ietf.org; Mon, 20 Jun 2005 06:31:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12596 for ; Mon, 20 Jun 2005 06:31:37 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkJwl-00054b-Rs for sipping@ietf.org; Mon, 20 Jun 2005 06:56:09 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 20 Jun 2005 03:31:28 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5KAVNng004251; Mon, 20 Jun 2005 06:31:26 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Jun 2005 06:31:25 -0400 Received: from [192.168.1.100] ([10.86.240.36]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Jun 2005 06:31:25 -0400 Message-ID: <42B69AFD.4030001@cisco.com> Date: Mon, 20 Jun 2005 06:31:25 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arjun Roychowdhury Subject: Re: [Sipping] XCAP server discovery References: <20050618070002.83521.qmail@web26201.mail.ukl.yahoo.com> <42B45179.4010006@mailvision.com> <001401c57449$690be8f0$6502a8c0@BEMBUSTER> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2005 10:31:25.0309 (UTC) FILETIME=[35C362D0:01C57583] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org The xcap root services URI should be one of many parameters passed to the client through the configuration framework: http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework-06.txt -Jonathan R. Arjun Roychowdhury wrote: > Hi, > most implementations I know of today provision the UA with the XCAP > services root URI. Once the root URI is known, since XCAP mandates > that documents are organized according to a defined hierarchy, the UA > can then navigate to the exact service that is required. > > I am personally not aware of any best practices to dynamically > identify the XCAP URI but I guess something like ${domain}/services > may not be a bad idea where ${domain} is the domain that is servicing > the User Agent. > > regds > arjun > > > On 6/18/05, Jeroen van Bemmel wrote: > >>Hi, >> >>Suppose one would make a useragent that uses SIP for presence and XCAP for >>manipulation of buddy lists etc. , what would be the best way to provision >>the client with the URL of its XCAP server? >> >>Regards, >> >>Jeroen >> >> >> >>_______________________________________________ >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>This list is for NEW development of the 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 Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Mon Jun 20 10:57:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkNij-00028R-39; Mon, 20 Jun 2005 10:57:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkNih-00028M-P9 for sipping@megatron.ietf.org; Mon, 20 Jun 2005 10:57:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07029 for ; Mon, 20 Jun 2005 10:57:49 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkO6O-0003bL-Js for sipping@ietf.org; Mon, 20 Jun 2005 11:22:22 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id 614AD6C01C for ; Mon, 20 Jun 2005 10:57:41 -0400 (EDT) From: "Dale Worley" To: Subject: RE: [Sipping] sipping session mobility Date: Mon, 20 Jun 2005 10:56:36 -0400 Message-ID: <007a01c575a8$42055b50$6a01010a@keywest> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20050618070002.83521.qmail@web26201.mail.ukl.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Spam-Score: 0.9 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0194114733==" Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============0194114733== Content-Type: multipart/alternative; boundary="----=_NextPart_000_007B_01C57586.BAF3BB50" This is a multi-part message in MIME format. ------=_NextPart_000_007B_01C57586.BAF3BB50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit The updated registration has nothing to do with revising the routing for an existing dialog, so both operations can be done in parallel. The biggest problem with mobility is that a re-INVITE is only allowed to change the contact addresses at each end of the dialog, not any of the components of the "route set", that is, the Record-Route'ed addresses. This may limit the changes in network attachment that can be accomodated. It may be possible to do more complex re-routing by using an INVITE with Replaces header to establish a new dialog with new route set that functionally continues the original dialog. Dale -----Original Message----- From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org]On Behalf Of Salvatore Loreto Sent: Saturday, June 18, 2005 3:00 AM To: sipping@ietf.org Subject: [Sipping] sipping session mobility Hi all, I've a question about the simultaneous mobility, of course it is a special case of a singol host mobility: when a SIP UA changes his subnetwork and it obtains a new IP address, it send a re-INVITE message, but my question is: the REGISTER message (inorder to uptodate it location information) must be sent before or after the re-INVITE. In the case of simultaneous mobility it should be sent before. what do you think about? best regards /sal ---------------------------------------------------------------------------- -- Yahoo! Mail: gratis 1GB per i messaggi, antispam, antivirus, POP3 ------=_NextPart_000_007B_01C57586.BAF3BB50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The=20 updated registration has nothing to do with revising the routing for an = existing=20 dialog, so both operations can be done in parallel.
 
The=20 biggest problem with mobility is that a re-INVITE is only allowed to = change the=20 contact addresses at each end of the dialog, not any of the components = of the=20 "route set", that is, the Record-Route'ed addresses.  This may = limit the=20 changes in network attachment that can be = accomodated.
 
It may=20 be possible to do more complex re-routing by using an INVITE with = Replaces=20 header to establish a new dialog with new route set that = functionally=20 continues the original dialog.
 
Dale
-----Original Message-----
From: = sipping-bounces@ietf.org=20 [mailto:sipping-bounces@ietf.org]On Behalf Of Salvatore=20 Loreto
Sent: Saturday, June 18, 2005 3:00 AM
To:=20 sipping@ietf.org
Subject: [Sipping] sipping session=20 mobility

Hi all,
 
I've a question about the simultaneous mobility, of course it is = a=20 special case of a singol host mobility:
 
when a SIP UA changes his subnetwork and it obtains a new IP=20 address,
it send a re-INVITE message, but my question is:
 
the REGISTER message (inorder to uptodate it location = information) must=20 be sent before or after the re-INVITE.
In the case of simultaneous mobility it should be sent = before.
 
what do you think about?
 
best regards
/sal

Yahoo!=20 Mail: gratis 1GB per i messaggi, antispam, antivirus,=20 POP3 ------=_NextPart_000_007B_01C57586.BAF3BB50-- --===============0194114733== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============0194114733==-- From sipping-bounces@ietf.org Mon Jun 20 12:35:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkPF5-000867-V4; Mon, 20 Jun 2005 12:35:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkPF4-00085m-8X for sipping@megatron.ietf.org; Mon, 20 Jun 2005 12:35:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16243 for ; Mon, 20 Jun 2005 12:35:19 -0400 (EDT) Received: from mxout1.netvision.net.il ([194.90.9.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkPcl-0006MC-9h for sipping@ietf.org; Mon, 20 Jun 2005 12:59:54 -0400 Received: from [127.0.0.1] ([212.143.127.195]) by mxout1.netvision.net.il (Sun Java System Messaging Server 6.1 HotFix 0.11 (built Jan 28 2005)) with ESMTPA id <0IIE007TF62CSX70@mxout1.netvision.net.il> for sipping@ietf.org; Mon, 20 Jun 2005 19:35:01 +0300 (IDT) Date: Mon, 20 Jun 2005 18:35:52 +0200 From: Diego B Subject: Re: [Sipping] sipping session mobility In-reply-to: <007a01c575a8$42055b50$6a01010a@keywest> To: Dale Worley Message-id: <42B6F068.2090806@mailvision.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <007a01c575a8$42055b50$6a01010a@keywest> User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7BIT Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Hi; Service-Route is added in responce to REGISTER. My question was if the Service-Route change, what is the effect in current dialogs. And I also think both actions can be done in parallel. Best Regards Diego B Dale Worley wrote: > The updated registration has nothing to do with revising the routing > for an existing dialog, so both operations can be done in parallel. > > The biggest problem with mobility is that a re-INVITE is only allowed > to change the contact addresses at each end of the dialog, not any of > the components of the "route set", that is, the Record-Route'ed > addresses. This may limit the changes in network attachment that can > be accomodated. > > It may be possible to do more complex re-routing by using an INVITE > with Replaces header to establish a new dialog with new route set that > functionally continues the original dialog. > > Dale > > -----Original Message----- > *From:* sipping-bounces@ietf.org > [mailto:sipping-bounces@ietf.org]*On Behalf Of *Salvatore Loreto > *Sent:* Saturday, June 18, 2005 3:00 AM > *To:* sipping@ietf.org > *Subject:* [Sipping] sipping session mobility > > Hi all, > > I've a question about the simultaneous mobility, of course it is a > special case of a singol host mobility: > > when a SIP UA changes his subnetwork and it obtains a new IP address, > it send a re-INVITE message, but my question is: > > the REGISTER message (inorder to uptodate it location information) > must be sent before or after the re-INVITE. > In the case of simultaneous mobility it should be sent before. > > what do you think about? > > best regards > /sal > > ------------------------------------------------------------------------ > *Yahoo! Mail* > : > gratis 1GB per i messaggi, antispam, antivirus, POP3 > >------------------------------------------------------------------------ > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Mon Jun 20 14:06:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkQfZ-0002g2-Ic; Mon, 20 Jun 2005 14:06:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkQfX-0002fx-Ry for sipping@megatron.ietf.org; Mon, 20 Jun 2005 14:06:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24634 for ; Mon, 20 Jun 2005 14:06:46 -0400 (EDT) Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkR3J-0000Lf-4Q for sipping@ietf.org; Mon, 20 Jun 2005 14:31:21 -0400 Received: (qmail 1090 invoked by uid 10); 20 Jun 2005 18:06:24 -0000 Received: (vexira-qq 01080-4FF577BD invoked from network) 20 Jun 2005 20:06:24 +0200 Received: from unknown (HELO BEMBUSTER) ([81.59.101.130]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 20 Jun 2005 18:06:24 -0000 Message-ID: <000f01c575c2$c2c4cdb0$6502a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Jonathan Rosenberg" , "Arjun Roychowdhury" References: <20050618070002.83521.qmail@web26201.mail.ukl.yahoo.com> <42B45179.4010006@mailvision.com> <001401c57449$690be8f0$6502a8c0@BEMBUSTER> <42B69AFD.4030001@cisco.com> Subject: Re: [Sipping] XCAP server discovery Date: Mon, 20 Jun 2005 20:06:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode02.zonnet.nl) X-Spam-Score: 1.2 (+) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Hi Jonathan, OK, thanks for the update. Perhaps this could be mentioned in the XCAP draft? Regards, Jeroen ----- Original Message ----- From: "Jonathan Rosenberg" To: "Arjun Roychowdhury" Cc: "Jeroen van Bemmel" ; Sent: Monday, June 20, 2005 12:31 PM Subject: Re: [Sipping] XCAP server discovery > The xcap root services URI should be one of many parameters passed to the > client through the configuration framework: > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework-06.txt > > -Jonathan R. > > Arjun Roychowdhury wrote: > >> Hi, >> most implementations I know of today provision the UA with the XCAP >> services root URI. Once the root URI is known, since XCAP mandates >> that documents are organized according to a defined hierarchy, the UA >> can then navigate to the exact service that is required. >> >> I am personally not aware of any best practices to dynamically >> identify the XCAP URI but I guess something like ${domain}/services >> may not be a bad idea where ${domain} is the domain that is servicing >> the User Agent. >> >> regds >> arjun >> >> >> On 6/18/05, Jeroen van Bemmel wrote: >> >>>Hi, >>> >>>Suppose one would make a useragent that uses SIP for presence and XCAP >>>for >>>manipulation of buddy lists etc. , what would be the best way to >>>provision >>>the client with the URL of its XCAP server? >>> >>>Regards, >>> >>>Jeroen >>> >>> >>> >>>_______________________________________________ >>>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>>This list is for NEW development of the 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 > Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Mon Jun 20 14:22:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkQup-0004oD-5X; Mon, 20 Jun 2005 14:22:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkQun-0004nj-HJ for sipping@megatron.ietf.org; Mon, 20 Jun 2005 14:22:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25924 for ; Mon, 20 Jun 2005 14:22:32 -0400 (EDT) Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkRIX-0000nD-Tk for sipping@ietf.org; Mon, 20 Jun 2005 14:47:07 -0400 Received: (qmail 13226 invoked by uid 10); 20 Jun 2005 18:22:20 -0000 Received: (vexira-qq 13208-56180FBA invoked from network) 20 Jun 2005 20:22:20 +0200 Received: from unknown (HELO BEMBUSTER) ([81.59.101.130]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 20 Jun 2005 18:22:20 -0000 Message-ID: <001601c575c4$fc9218c0$6502a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "sipping" References: Subject: Re: [Sipping] WGLC: draft-ietf-sipping-trait-authz-01.txt Date: Mon, 20 Jun 2005 20:22:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode01.zonnet.nl) X-Spam-Score: 1.2 (+) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Hi Hannes, > > We have been experimenting with this in the context of Web > services. One of the things we found is that communicating policies > following > the current standards (i.e. signed SAML assertions) leads to very verbose, > large > documents. | it depends on the content of the assertion (and whether you use assertions at all). | if you use xml document then everything tends to grow in size. | if you use an artifact then the size of the "token" is very small, in fact it is only a pointer to the assertions itself. You are right that using pass-by-reference rather than pass-by-value could alleviate the size issue, however what do you do then about policy rules that are to be interpreted by the client (as in the session policies draft)? It seems a bit double to direct the client to a policy server, which then directs it to some other server for resolving the artifact. I would suggest a hybrid approach: use a policy that contains some parameters to be interpreted by the client, and possibly an opaque artifact that is to be passed in each request. Some requirements for this artifact would be: - it should contain a timestamp for replay protection - it should contain the identity of the client to which it was given - it should be signed - it MAY include an indication of the source that issued it (e.g. id of its certificate), this could also be implicit I'm thinking of something like an MD5-converted encrypted URL with some parameters Depending on the trust model the complete token could optionally be signed too for verification by the client, but it may also rely on other layers (e.g. using https) I would personally choose to have the proxy return such a policy instead of a reference to some policy server ( i.e. it sends an error reply with the policy as body, and maybe the artifact in some header). The client should indicate support for this in its Accept header. Benefit of this is that it does not burden the client with yet another protocol to implement for talking to a policy server. And for SDP related policies, why not have the proxy return an SDP description of what it allows (since the client already knows how to parse SDP) instead of adding a new XML format? Regards, Jeroen _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Mon Jun 20 17:25:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkTm5-0006eC-1y; Mon, 20 Jun 2005 17:25:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkTm2-0006e4-SN for sipping@megatron.ietf.org; Mon, 20 Jun 2005 17:25:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11616 for ; Mon, 20 Jun 2005 17:25:40 -0400 (EDT) Message-Id: <200506202125.RAA11616@ietf.org> Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkU9m-00065w-8w for sipping@ietf.org; Mon, 20 Jun 2005 17:50:17 -0400 Received: (qmail 9031 invoked by uid 510); 20 Jun 2005 18:07:52 -0400 Received: from henry@pulver.com by mail.pulver.com by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.72. spamassassin: 2.63. Clear:RC:1(67.187.105.166):. Processed in 0.838368 secs); 20 Jun 2005 22:07:52 -0000 X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(67.187.105.166):. Processed in 0.838368 secs Process 9026) Received: from c-67-187-105-166.hsd1.wa.comcast.net (HELO 1AB764895C324D3) (henry@pulver.com@67.187.105.166) by 192.246.69.184 with SMTP; Mon, 20 Jun 2005 22:07:51 +0000 From: "Henry Sinnreich" To: , "'Gonzalo Camarillo'" , "'Dean Willis'" , "'Rohan Mahy'" Date: Mon, 20 Jun 2005 16:25:20 -0500 Organization: pulver.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVw+RC+V2stZHNcRfqBUBV5eeQtFgE5B+Ig In-Reply-To: X-Antivirus-MYDOMAIN-Message-ID: <11193052718359026@mail.pulver.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: fluffy@cisco.com, alan@jasomi.com Subject: [Sipping] draft-jennings-sipping-outbound-01 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: henry@pulver.com List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org In order to do a complete job, besides ICE, http://www.ietf.org/internet-drafts/draft-jennings-sipping-outbound-01.txt needs also to get finished. Can the authors share the status of this work? Should ICE and SIP Conventions for UAs with Outbound Only Connections be an agenda item for the SIPPING WG session? Thanks, Henry _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Tue Jun 21 13:51:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkmty-00080P-2k; Tue, 21 Jun 2005 13:51:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkmts-00080D-0X for sipping@megatron.ietf.org; Tue, 21 Jun 2005 13:51:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11849 for ; Tue, 21 Jun 2005 13:51:03 -0400 (EDT) Received: from mx01.net.com ([134.56.3.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DknHn-0003vh-8S for sipping@ietf.org; Tue, 21 Jun 2005 14:15:50 -0400 Received: from mx01-int.net.com (mx01-int.net.com [134.56.112.13]) by mx01.net.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id j5LHtP7O012311 for ; Tue, 21 Jun 2005 10:55:25 -0700 (PDT) Received: from fmt-ex01.net.com (fmt-exchange.net.com [134.56.112.251]) by mx01-int.net.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id j5LHl8OO026142 for ; Tue, 21 Jun 2005 10:47:09 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Jun 2005 10:49:59 -0700 Message-ID: Thread-Topic: Diversion header Thread-Index: AcV2iaS7bwrOX6AOStOEvPot4jUy2w== From: "Sreedhar Pampati" To: X-Spam-Status: No, hits=-0.2 required=8.0 tests=AWL,HTML_MESSAGE autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on fmt-spam02.net.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Subject: [Sipping] Diversion header X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1054138305==" Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============1054138305== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C57689.A535458E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C57689.A535458E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Does anyone know why this draft "draft-levy-sip-diversion-09.txt" that describes the use of Diversion header to convey the call forward reason and number is not continued anymore? I tried to reach the authors, but there is no response. Thanks Sreedhar ------_=_NextPart_001_01C57689.A535458E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Does anyone know why this draft = “draft-levy-sip-diversion-09.txt” that describes the use of Diversion header to convey the call forward = reason and number is not continued anymore? I tried to reach the authors, but = there is no response.

Thanks

Sreedhar

------_=_NextPart_001_01C57689.A535458E-- --===============1054138305== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============1054138305==-- From sipping-bounces@ietf.org Tue Jun 21 13:54:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkmx1-0008Ol-7C; Tue, 21 Jun 2005 13:54:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkmwz-0008Of-9W for sipping@megatron.ietf.org; Tue, 21 Jun 2005 13:54:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12012 for ; Tue, 21 Jun 2005 13:54:16 -0400 (EDT) Received: from mailhost.iperia.com ([204.57.52.4] helo=iperia.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DknKv-0003zl-9A for sipping@ietf.org; Tue, 21 Jun 2005 14:19:03 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Subject: RE: [Sipping] Diversion header Date: Tue, 21 Jun 2005 13:53:52 -0400 Message-ID: <8019F8581B5FC14DBD94BAF86844868E6F9F6E@viridis.IPeria.local> Thread-Topic: [Sipping] Diversion header thread-index: AcV2iaS7bwrOX6AOStOEvPot4jUy2wAAH70Q From: "Gordon Ledgard" To: "Sreedhar Pampati" , X-Spam-Score: 0.2 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0936247749==" Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============0936247749== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5768A.2FA27F27" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5768A.2FA27F27 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable =20 It has been replaced by the HISTORY header. =20 =20 ________________________________ From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf Of Sreedhar Pampati Sent: Tuesday, June 21, 2005 1:50 PM To: sipping@ietf.org Subject: [Sipping] Diversion header =20 Does anyone know why this draft "draft-levy-sip-diversion-09.txt" that describes the use of Diversion header to convey the call forward reason and number is not continued anymore? I tried to reach the authors, but there is no response. Thanks Sreedhar ------_=_NextPart_001_01C5768A.2FA27F27 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

 

It has been replaced by the HISTORY header.

 

 

From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf Of Sreedhar Pampati
Sent: Tuesday, June 21, = 2005 1:50 PM
To: sipping@ietf.org
Subject: [Sipping] = Diversion header

 

Does anyone know why this draft “draft-levy-sip-diversion-09.txt” that describes the use of Diversion header to convey the call forward reason and number is not = continued anymore? I tried to reach the authors, but there is no = response.

Thanks

Sreedhar

------_=_NextPart_001_01C5768A.2FA27F27-- --===============0936247749== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============0936247749==-- From sipping-bounces@ietf.org Tue Jun 21 14:41:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkngC-0000vk-B2; Tue, 21 Jun 2005 14:41:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkngB-0000vY-6V for sipping@megatron.ietf.org; Tue, 21 Jun 2005 14:40:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16359 for ; Tue, 21 Jun 2005 14:40:57 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dko49-0005Gf-FI for sipping@ietf.org; Tue, 21 Jun 2005 15:05:45 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j5LIepja014789; Tue, 21 Jun 2005 13:40:53 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 21 Jun 2005 19:40:46 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C29051F@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Sreedhar Pampati , sipping@ietf.org Subject: RE: [Sipping] Diversion header Date: Tue, 21 Jun 2005 19:40:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1999742340==" Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org 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. --===============1999742340== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C57690.A11FB98A" 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_01C57690.A11FB98A Content-Type: text/plain More specifically, it is covered in http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-06.txt which is IESG approved and in the RFC editor's queue. regards Keith -----Original Message----- From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org]On Behalf Of Gordon Ledgard Sent: 21 June 2005 18:54 To: Sreedhar Pampati; sipping@ietf.org Subject: RE: [Sipping] Diversion header It has been replaced by the HISTORY header. _____ From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf Of Sreedhar Pampati Sent: Tuesday, June 21, 2005 1:50 PM To: sipping@ietf.org Subject: [Sipping] Diversion header Does anyone know why this draft "draft-levy-sip-diversion-09.txt" that describes the use of Diversion header to convey the call forward reason and number is not continued anymore? I tried to reach the authors, but there is no response. Thanks Sreedhar ------_=_NextPart_001_01C57690.A11FB98A Content-Type: text/html Content-Transfer-Encoding: quoted-printable
More=20 specifically, it is covered in http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-= 06.txt which=20 is IESG approved and in the RFC editor's queue.
 
regards
 
Keith
-----Original Message-----
From: = sipping-bounces@ietf.org=20 [mailto:sipping-bounces@ietf.org]On Behalf Of Gordon=20 Ledgard
Sent: 21 June 2005 18:54
To: Sreedhar = Pampati;=20 sipping@ietf.org
Subject: RE: [Sipping] Diversion=20 header

 

It has = been replaced=20 by the HISTORY header.

 

 

From:=20 sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf Of Sreedhar = Pampati
Sent: Tuesday, June 21, 2005 = 1:50=20 PM
To:=20 sipping@ietf.org
Subject:=20 [Sipping] Diversion header

 

Does anyone know why = this draft=20 “draft-levy-sip-diversion-09.txt” that describes the use = of Diversion header=20 to convey the call forward reason and number is not continued = anymore? I tried=20 to reach the authors, but there is no = response.

Thanks

Sreedhar

------_=_NextPart_001_01C57690.A11FB98A-- --===============1999742340== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============1999742340==-- From sipping-bounces@ietf.org Tue Jun 21 15:03:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dko20-00052l-Re; Tue, 21 Jun 2005 15:03:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dko1z-00052g-KY for sipping@megatron.ietf.org; Tue, 21 Jun 2005 15:03:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18548 for ; Tue, 21 Jun 2005 15:03:30 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkoPx-0005sw-0H for sipping@ietf.org; Tue, 21 Jun 2005 15:28:18 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8B91AAC7; Tue, 21 Jun 2005 21:03:28 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Jun 2005 21:03:27 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Jun 2005 21:03:27 +0200 Received: from [131.160.126.5] (rvi2-126-5.lmf.ericsson.se [131.160.126.5]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 99E6D2558; Tue, 21 Jun 2005 22:03:26 +0300 (EEST) Message-ID: <42B8647C.7080500@ericsson.com> Date: Tue, 21 Jun 2005 22:03:24 +0300 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jun 2005 19:03:27.0377 (UTC) FILETIME=[E7F4B010:01C57693] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , Allison Mankin , Dean Willis Subject: [Sipping] Ad-hoc on TISPAN NGN requirements during the IETF in Paris X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Folks, we will be organizing an ad-hoc meeting during the IETF in Paris to discuss the requirements of ETSI TISPAN NGN on SIP. We would like to get a common understanding on what NGN needs from SIP and identify requirements that would be better met by a general solution rather than an NGN-specific solution. We will get back to you when we have more information about the schedulling and the location of this event. Regards, Gonzalo SIPPING co-chair _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Tue Jun 21 15:09:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dko7j-0006LN-OQ; Tue, 21 Jun 2005 15:09:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dko7i-0006LI-3J for sipping@megatron.ietf.org; Tue, 21 Jun 2005 15:09:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19718 for ; Tue, 21 Jun 2005 15:09:24 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkoVe-000662-59 for sipping@ietf.org; Tue, 21 Jun 2005 15:34:12 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 044FE78; Tue, 21 Jun 2005 21:09:22 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Jun 2005 21:09:21 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Jun 2005 21:09:20 +0200 Received: from [131.160.126.5] (rvi2-126-5.lmf.ericsson.se [131.160.126.5]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 28A242558; Tue, 21 Jun 2005 22:09:20 +0300 (EEST) Message-ID: <42B865DF.4040104@ericsson.com> Date: Tue, 21 Jun 2005 22:09:19 +0300 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: henry@pulver.com Subject: Re: [Sipping] draft-jennings-sipping-outbound-01 References: <200506202125.RAA11616@ietf.org> In-Reply-To: <200506202125.RAA11616@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jun 2005 19:09:20.0808 (UTC) FILETIME=[BA9DFA80:01C57694] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.2 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: fluffy@cisco.com, 'Dean Willis' , alan@jasomi.com, sipping@ietf.org, 'Rohan Mahy' X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Hi Henry, regarding the SIPPING agenda, we can discuss SIPPING stuff... but ICE is an MMUSIC draft which will be discussed in MMUSIC... and given how busy SIPPING meetings usually are, I would say this is a good thing. Thanks, Gonzalo Henry Sinnreich wrote: > In order to do a complete job, besides ICE, > > http://www.ietf.org/internet-drafts/draft-jennings-sipping-outbound-01.txt > > needs also to get finished. Can the authors share the status of this work? > > Should ICE and SIP Conventions for UAs with Outbound Only Connections be an > agenda item for the SIPPING WG session? > > Thanks, Henry > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Tue Jun 21 21:06:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dktgm-0003Rs-Lj; Tue, 21 Jun 2005 21:06:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dktgk-0003Rn-Ox for sipping@megatron.ietf.org; Tue, 21 Jun 2005 21:05:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03514 for ; Tue, 21 Jun 2005 21:05:57 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dku4m-00050M-Eb for sipping@ietf.org; Tue, 21 Jun 2005 21:30:48 -0400 Received: from [64.101.100.88] ([64.101.100.88]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j5M19PNt005983 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 21 Jun 2005 20:09:26 -0500 In-Reply-To: <42B6F068.2090806@mailvision.com> References: <007a01c575a8$42055b50$6a01010a@keywest> <42B6F068.2090806@mailvision.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sipping] sipping session mobility Date: Tue, 21 Jun 2005 20:06:06 -0500 To: Diego B X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org On Jun 20, 2005, at 11:35 AM, Diego B wrote: > Hi; > > Service-Route is added in responce to REGISTER. > My question was if the Service-Route change, what is the effect in > current dialogs. > No effect on existing dialogs. The Service-Route is only used in requests sent outside of a dialog. Consequently, an existing dialog would continue to observe the Record-Route and Via chains associated with that dialog. -- Dean Willis editor, Service-Route 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 sipping-bounces@ietf.org Wed Jun 22 02:45:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkyz6-0005NX-9D; Wed, 22 Jun 2005 02:45:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkyz3-0005NS-W0 for sipping@megatron.ietf.org; Wed, 22 Jun 2005 02:45:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04372 for ; Wed, 22 Jun 2005 02:45:12 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkzN7-0004w1-FK for sipping@ietf.org; Wed, 22 Jun 2005 03:10:07 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 21 Jun 2005 23:45:02 -0700 X-IronPort-AV: i="3.93,220,1115017200"; d="scan'208"; a="281677515:sNHT30359416" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5M6ipqo010229; Tue, 21 Jun 2005 23:44:59 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Jun 2005 02:32:18 -0400 Received: from [192.168.1.100] ([10.86.242.143]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Jun 2005 02:32:17 -0400 Message-ID: <42B905F1.3090709@cisco.com> Date: Wed, 22 Jun 2005 02:32:17 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sipping] XCAP server discovery References: <20050618070002.83521.qmail@web26201.mail.ukl.yahoo.com> <42B45179.4010006@mailvision.com> <001401c57449$690be8f0$6502a8c0@BEMBUSTER> <42B69AFD.4030001@cisco.com> <000f01c575c2$c2c4cdb0$6502a8c0@BEMBUSTER> In-Reply-To: <000f01c575c2$c2c4cdb0$6502a8c0@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jun 2005 06:32:17.0898 (UTC) FILETIME=[22DDB4A0:01C576F4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org This is out of scope for XCAP itself. Something like this belongs in the data profile document that goes with the sipping configuration framework. -Jonathan R. Jeroen van Bemmel wrote: > Hi Jonathan, > > OK, thanks for the update. Perhaps this could be mentioned in the XCAP > draft? > > Regards, > > Jeroen > > ----- Original Message ----- From: "Jonathan Rosenberg" > To: "Arjun Roychowdhury" > Cc: "Jeroen van Bemmel" ; > Sent: Monday, June 20, 2005 12:31 PM > Subject: Re: [Sipping] XCAP server discovery > > >> The xcap root services URI should be one of many parameters passed to >> the client through the configuration framework: >> >> http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework-06.txt >> >> >> -Jonathan R. >> >> Arjun Roychowdhury wrote: >> >>> Hi, >>> most implementations I know of today provision the UA with the XCAP >>> services root URI. Once the root URI is known, since XCAP mandates >>> that documents are organized according to a defined hierarchy, the UA >>> can then navigate to the exact service that is required. >>> >>> I am personally not aware of any best practices to dynamically >>> identify the XCAP URI but I guess something like ${domain}/services >>> may not be a bad idea where ${domain} is the domain that is servicing >>> the User Agent. >>> >>> regds >>> arjun >>> >>> >>> On 6/18/05, Jeroen van Bemmel wrote: >>> >>>> Hi, >>>> >>>> Suppose one would make a useragent that uses SIP for presence and >>>> XCAP for >>>> manipulation of buddy lists etc. , what would be the best way to >>>> provision >>>> the client with the URL of its XCAP server? >>>> >>>> Regards, >>>> >>>> Jeroen >>>> >>>> >>>> >>>> _______________________________________________ >>>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>>> This list is for NEW development of the 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 >> Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 >> Cisco Systems >> jdrosen@cisco.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.cisco.com > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Wed Jun 22 03:21:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkzXs-0001Rx-Cn; Wed, 22 Jun 2005 03:21:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkzXq-0001PJ-KO for sipping@megatron.ietf.org; Wed, 22 Jun 2005 03:21:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07099 for ; Wed, 22 Jun 2005 03:21:08 -0400 (EDT) Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dkzvs-0005pE-Gx for sipping@ietf.org; Wed, 22 Jun 2005 03:46:04 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j5M7IK5V000477; Wed, 22 Jun 2005 10:18:21 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Jun 2005 10:20:59 +0300 Received: from [127.0.0.1] ([172.21.35.209]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 22 Jun 2005 10:08:12 +0300 Message-ID: <42B90E5D.7050308@nokia.com> Date: Wed, 22 Jun 2005 10:08:13 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Gonzalo Camarillo Subject: Re: [Sipping] Ad-hoc on TISPAN NGN requirements during the IETF in Paris References: <42B8647C.7080500@ericsson.com> In-Reply-To: <42B8647C.7080500@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jun 2005 07:08:12.0643 (UTC) FILETIME=[2731B330:01C576F9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: "Jesske, R" , Rohan Mahy , Dean Willis , sipping , Allison Mankin X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Gonzalo: Having in mind the stringent deadlines that ETSI TISPAN has, I would like to propose to discuss the requirements in the mailing list and focus on possible solutions that implement these requirements. We need solutions, not discussing the requirements in the ad-hoc meeting. I want to point out that the newest version of the TISPAN requirements draft has been available for a few days: ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-jesske-sipping-tispan-requirements-01.txt and we are working on another document that analyses those requirements in search for solutions. This other document will be submitted shortly, perhaps today. Best regards, Miguel Gonzalo Camarillo wrote: > Folks, > > we will be organizing an ad-hoc meeting during the IETF in Paris to > discuss the requirements of ETSI TISPAN NGN on SIP. We would like to get > a common understanding on what NGN needs from SIP and identify > requirements that would be better met by a general solution rather than > an NGN-specific solution. > > We will get back to you when we have more information about the > schedulling and the location of this event. > > Regards, > > Gonzalo > SIPPING co-chair > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Wed Jun 22 06:37:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl2c9-0007HW-4U; Wed, 22 Jun 2005 06:37:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl2c7-0007Gu-2T for sipping@megatron.ietf.org; Wed, 22 Jun 2005 06:37:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22820 for ; Wed, 22 Jun 2005 06:37:43 -0400 (EDT) Received: from cluster-d.mailcontrol.com ([217.69.20.190] helo=rly03d.srv.mailcontrol.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl30D-0002Ok-Oq for sipping@ietf.org; Wed, 22 Jun 2005 07:02:42 -0400 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly03d.srv.mailcontrol.com (MailControl) with SMTP id j5MAbbdt023070 for ; Wed, 22 Jun 2005 11:37:37 +0100 Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via smtp id 0b40_80de64ec_e309_11d9_9e33_0030482aac25; Wed, 22 Jun 2005 12:36:33 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.2) with ESMTP id 2005062212373335-112918 ; Wed, 22 Jun 2005 12:37:33 +0200 Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de for sipping@ietf.org; Wed, 22 Jun 2005 12:39:05 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 22 Jun 2005 12:35:54 +0200 Message-ID: <4D2F935F08D41A4C8866693F4F0D7C4F224CA3@lan-ex-01.panasonic.de> Thread-Topic: Question wrt transcoding Thread-Index: AcVxCwuSCbbN8iiLRcO/L752gCyc6QFLat+g To: From: "Jose Rey" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Scanned-By: MailControl A-05-01-01 (www.mailcontrol.com) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Subject: [Sipping] Question wrt transcoding X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org [I am new to the list, sorry if question is already answered] Hi, I have a (basic) question regarding O/A in the transcoding scenario; it = refers to = http://www.ietf.org/internet-drafts/draft-ietf-sipping-transc-3pcc-02.txt= If an answerer B can receive audio but cannot understand any of the = codecs that the offerer A includes in the INVITE, it usually sets the = port=3D0 in the corresponding m line in the answer. This is understood. = But how does the SIP UA acting as controller know that this means "No, = I don't want that m line" OR "I want it but I cannot support it"?? Is it by including an additional m line with the proposed formats in the = answer as mentioned in RFC 3264: "Rosenberg & Schulzrinne Standards Track [Page = 9] =0C RFC 3264 An Offer/Answer Model Session Description Protocol June 2002 For streams marked as recvonly in the answer, the "m=3D" line MUST contain at least one media format the answerer is willing to receive --> with from amongst those listed in the offer. The stream MAY = indicate --> additional media formats, not listed in the corresponding stream = in --> the offer, that the answerer is willing to receive. For streams marked as sendonly in the answer, the "m=3D" line MUST contain at = least one media format the answerer is willing to send from amongst those listed in the offer. For streams marked as sendrecv in the answer, the "m=3D" line MUST contain at least one codec the answerer is = willing to both send and receive, from amongst those listed in the offer. The stream MAY indicate additional media formats, not listed in the corresponding stream in the offer, that the answerer is willing to send or receive (of course, it will not be able to send them at this time, since it was not listed in the offer). " Is this how it is usually detected and what every SIP client does? Thanks, Jos=E9 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Wed Jun 22 18:42:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlDvG-00014C-DC; Wed, 22 Jun 2005 18:42:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlDvF-000147-1x for sipping@megatron.ietf.org; Wed, 22 Jun 2005 18:42:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14187 for ; Wed, 22 Jun 2005 18:42:13 -0400 (EDT) Received: from mx02.net.com ([134.56.3.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlEJQ-0006mJ-QF for sipping@ietf.org; Wed, 22 Jun 2005 19:07:18 -0400 Received: from mx02-int.net.com (mx02-int.net.com [134.56.112.14]) by mx02.net.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id j5MMkqTM009155 for ; Wed, 22 Jun 2005 15:46:53 -0700 (PDT) Received: from fmt-ex01.net.com (fmt-ex01.net.com [134.56.112.251]) by mx02-int.net.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id j5MMkods014066 for ; Wed, 22 Jun 2005 15:46:50 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 22 Jun 2005 15:41:32 -0700 Message-ID: Thread-Topic: REGISTER vs SUBSCRIBE timing Thread-Index: AcV3e4dYzTLZ8cxLQEy89DFYZGghtA== From: "Sreedhar Pampati" To: X-Spam-Status: No, hits=-0.2 required=8.0 tests=AWL,HTML_MESSAGE autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on fmt-spam02.net.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Subject: [Sipping] REGISTER vs SUBSCRIBE timing X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1612535714==" Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============1612535714== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5777B.8A1B5A18" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5777B.8A1B5A18 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Are there any guidelines on whether a UA should send REGISTER first or SUBSCRIBE? Does it matter how long it waits between sending these two requests? Will there by any difference, if both the requests are sent to the same SIP Serer?=20 Thanks Sreedhar =20 ------_=_NextPart_001_01C5777B.8A1B5A18 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Are there any guidelines on whether a UA should send REGISTER first or SUBSCRIBE? Does it matter how long it waits between = sending these two requests? Will there by any difference, if both the requests = are sent to the same SIP Serer?

Thanks

Sreedhar

 

------_=_NextPart_001_01C5777B.8A1B5A18-- --===============1612535714== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============1612535714==-- From sipping-bounces@ietf.org Fri Jun 24 08:33:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlnMz-0005gU-Lt; Fri, 24 Jun 2005 08:33:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlnMx-0005gA-Su for sipping@megatron.ietf.org; Fri, 24 Jun 2005 08:33:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04827 for ; Fri, 24 Jun 2005 08:33:14 -0400 (EDT) Received: from web25502.mail.ukl.yahoo.com ([217.12.10.148]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DlnlT-0007Gg-VR for Sipping@ietf.org; Fri, 24 Jun 2005 08:58:37 -0400 Received: (qmail 4625 invoked by uid 60001); 24 Jun 2005 12:32:39 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=b3sez8MbgdorGyWBBZK+GMTlst+DhNz48XWQwMtAl2sQSfSVyafgGT7DJXn5CI1WuYzzTHxw6kJZkp1Ao4b1YUZpR5/IHZ8NQVZH9iOUT0qDTdJbWamlAyir9ndSEALSKNzwTeyK0gonNxXm3c4PA/YySuzQmPzeLYCMQBEvbsU= ; Message-ID: <20050624123239.4623.qmail@web25502.mail.ukl.yahoo.com> Received: from [80.119.4.244] by web25502.mail.ukl.yahoo.com via HTTP; Fri, 24 Jun 2005 14:32:39 CEST Date: Fri, 24 Jun 2005 14:32:39 +0200 (CEST) From: harry gaillac To: Sipping@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 2.9 (++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA04827 Cc: Subject: [Sipping] music on hold X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Hi all, I wish to provide MOH. I configured SER server and asterisk as music server However I can't configure the HOLD key of my polycom ip300 to contact the music server according to http://www.tech-invite.com/Ti-sip-service-3.html=20 Polycom told me those phones work with 3cpp server ? What are the solutions to provide MOH? Does sip phones have to acts as B2BUA? =20 What do you advise me ? Regards harry =09 =09 =09 _________________________________________________________________________= __=20 Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenge= r=20 T=E9l=E9chargez cette version sur http://fr.messenger.yahoo.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Fri Jun 24 09:58:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dloh2-0001wb-Kd; Fri, 24 Jun 2005 09:58:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dloh0-0001wW-Vo for sipping@megatron.ietf.org; Fri, 24 Jun 2005 09:58:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10196 for ; Fri, 24 Jun 2005 09:58:01 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dlp5V-0002Fk-RH for sipping@ietf.org; Fri, 24 Jun 2005 10:23:25 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 24 Jun 2005 06:57:50 -0700 X-IronPort-AV: i="3.93,227,1115017200"; d="scan'208"; a="282644875:sNHT44860580" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5ODvgon029213; Fri, 24 Jun 2005 06:57:45 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Jun 2005 09:58:00 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Jun 2005 09:57:41 -0400 Message-ID: <42BC1155.8000306@cisco.com> Date: Fri, 24 Jun 2005 09:57:41 -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: Miguel Garcia Subject: Re: [Sipping] PoC-settings event package References: <42B15172.6080604@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jun 2005 13:57:42.0034 (UTC) FILETIME=[B084BF20:01C578C4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org I have one question on this document: 5.16 Multiple Sources for Event State RFC 3903 [8] requires event packages to specify whether multiple sources can contribute to the event state view at the ESC. This event package allows different EPAs to publish the PoC settings for a particular user. For a given user the ESC will consider the last received PoC settings documents segment as the valid updated event state. I don't follow this. If two phones are registered and publishing then you take the most recent publication as applying to the AoR as a whole? That doesn't make sense to me. One might be in auto answer mode and the other in manual mode. When a call comes in, the proper treatment is a function of which the call is directed to. There is a problem in that there is no good way for the ESC to correlate the published settings with a particular registration, but that seems to be what is needed. As described, the two phones will both be registered and will both periodically update their POC settings in an uncoordinated way. Just doesn't work. Paul Miguel Garcia wrote: > Hi: > > I have just submitted a new version of the poc-settings event package > draft. Until it is available, you can download a copy from: > > http://people.nokia.net/~miguel/drafts/draft-garcia-sipping-poc-isb-am-02.txt > > or > http://people.nokia.net/~miguel/drafts/draft-garcia-sipping-poc-isb-am-02.html > > > This contains the mostly editorial comments that I got in the mailing > list and in the exper review. > > Regards, > > Miguel _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Fri Jun 24 13:01:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlrYv-0000W6-ED; Fri, 24 Jun 2005 13:01:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlrYu-0000W1-02 for sipping@megatron.ietf.org; Fri, 24 Jun 2005 13:01:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25084 for ; Fri, 24 Jun 2005 13:01:49 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlrxQ-0001bW-BD for Sipping@ietf.org; Fri, 24 Jun 2005 13:27:15 -0400 Received: from [128.107.138.215] (dhcp-128-107-138-215.cisco.com [128.107.138.215]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j5OH5BaN018708 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 24 Jun 2005 12:05:12 -0500 In-Reply-To: <20050624123239.4623.qmail@web25502.mail.ukl.yahoo.com> References: <20050624123239.4623.qmail@web25502.mail.ukl.yahoo.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <58a31dc0f91c4e002d79846daaf10c8a@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sipping] music on hold Date: Fri, 24 Jun 2005 12:01:40 -0500 To: harry gaillac X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: Sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org On Jun 24, 2005, at 7:32 AM, harry gaillac wrote: > > What do you advise me ? > I advise you ask on the sip-implementors list, the asterisk list, or just possibly a polycom list (assuming there is one), as this is pretty much off-topic for the SIPPING list. Good luck, it sounds like a cool application. On second thought, no, I actually hate music-on-hold, as it makes waiting on a speaker-phone difficult. -- Dean SIPPING co-chair. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Fri Jun 24 16:52:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlvA2-0001bF-Qi; Fri, 24 Jun 2005 16:52:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlv9y-0001ao-Nx for sipping@megatron.ietf.org; Fri, 24 Jun 2005 16:52:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23991 for ; Fri, 24 Jun 2005 16:52:20 -0400 (EDT) Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlvYY-00050b-Ar for Sipping@ietf.org; Fri, 24 Jun 2005 17:17:48 -0400 Received: (qmail 25061 invoked by uid 10); 24 Jun 2005 20:52:04 -0000 Received: (vexira-qq 25055-4464573B invoked from network) 24 Jun 2005 22:52:04 +0200 Received: from unknown (HELO BEMBUSTER) ([81.59.101.130]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 24 Jun 2005 20:52:04 -0000 Message-ID: <005301c578fe$93ba65e0$6502a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: References: <20050624123239.4623.qmail@web25502.mail.ukl.yahoo.com> Date: Fri, 24 Jun 2005 22:52:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode02.zonnet.nl) X-Spam-Score: 1.2 (+) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: Subject: [Sipping] Missed calls event package X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Hi, Is there an event package defined for notification / retrieval of missed calls (in particular the ones that occur when you have no SIP UA online, which requires network support) Regards, jeroen _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Mon Jun 27 03:58:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmoVL-0004JX-FN; Mon, 27 Jun 2005 03:58:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmoVI-0004JP-5i for sipping@megatron.ietf.org; Mon, 27 Jun 2005 03:58:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21144 for ; Mon, 27 Jun 2005 03:58:01 -0400 (EDT) Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmouO-0006gL-KE for sipping@ietf.org; Mon, 27 Jun 2005 04:24:01 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j5R7vpq3028004; Mon, 27 Jun 2005 10:58:00 +0300 Received: from esebh003.NOE.Nokia.com ([172.21.138.82]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Jun 2005 10:57:55 +0300 Received: from [127.0.0.1] ([172.21.34.196]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 27 Jun 2005 10:57:55 +0300 Message-ID: <42BFB183.4040301@nokia.com> Date: Mon, 27 Jun 2005 10:57:55 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sipping] PoC-settings event package References: <42B15172.6080604@nokia.com> <42BC1155.8000306@cisco.com> In-Reply-To: <42BC1155.8000306@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jun 2005 07:57:55.0830 (UTC) FILETIME=[ED60A960:01C57AED] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Cc: sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Hi Paul: I acknowledge the problem, which hasn't been a problem for the OMA folks since they assume a single terminal for a given identity. Of course, this does not solve anything, and I agree this issue should be fixed. I am thinking of possible solutions to this problem. Linking the poc-settings to the device-id or contact address does not seem to solve anything, because the PoC server does not have any registration information. So I will start some discussion with the OMA folks as for what is an acceptable solution for this... Perhaps we should have been using hard state publication instead... sigh. /Miguel Paul Kyzivat wrote: > I have one question on this document: > > 5.16 Multiple Sources for Event State > > RFC 3903 [8] requires event packages to specify whether multiple > sources can contribute to the event state view at the ESC. > > This event package allows different EPAs to publish the PoC settings > for a particular user. For a given user the ESC will consider the > last received PoC settings documents segment as the valid updated > event state. > > I don't follow this. If two phones are registered and publishing then > you take the most recent publication as applying to the AoR as a whole? > > That doesn't make sense to me. One might be in auto answer mode and the > other in manual mode. When a call comes in, the proper treatment is a > function of which the call is directed to. > > There is a problem in that there is no good way for the ESC to correlate > the published settings with a particular registration, but that seems to > be what is needed. > > As described, the two phones will both be registered and will both > periodically update their POC settings in an uncoordinated way. Just > doesn't work. > > Paul > > > > Miguel Garcia wrote: > >> Hi: >> >> I have just submitted a new version of the poc-settings event package >> draft. Until it is available, you can download a copy from: >> >> http://people.nokia.net/~miguel/drafts/draft-garcia-sipping-poc-isb-am-02.txt >> >> or >> http://people.nokia.net/~miguel/drafts/draft-garcia-sipping-poc-isb-am-02.html >> >> >> This contains the mostly editorial comments that I got in the mailing >> list and in the exper review. >> >> Regards, >> >> Miguel > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Mon Jun 27 10:16:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmuK3-0002k5-Md; Mon, 27 Jun 2005 10:10:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmuK1-0002js-PM for sipping@megatron.ietf.org; Mon, 27 Jun 2005 10:10:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24335 for ; Mon, 27 Jun 2005 10:10:47 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmujB-0004qk-3W for sipping@ietf.org; Mon, 27 Jun 2005 10:36:50 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 27 Jun 2005 07:10:39 -0700 X-IronPort-AV: i="3.93,235,1115017200"; d="scan'208"; a="283409497:sNHT131705802" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5REAVoh003255; Mon, 27 Jun 2005 07:10:33 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Jun 2005 10:10:34 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Jun 2005 10:10:34 -0400 Message-ID: <42C008D8.8060800@cisco.com> Date: Mon, 27 Jun 2005 10:10:32 -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: Miguel Garcia Subject: Re: [Sipping] PoC-settings event package References: <42B15172.6080604@nokia.com> <42BC1155.8000306@cisco.com> <42BFB183.4040301@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jun 2005 14:10:34.0198 (UTC) FILETIME=[FC00DF60:01C57B21] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Cc: sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Miguel Garcia wrote: > Hi Paul: > > I acknowledge the problem, which hasn't been a problem for the OMA folks > since they assume a single terminal for a given identity. Of course, > this does not solve anything, and I agree this issue should be fixed. > > I am thinking of possible solutions to this problem. Linking the > poc-settings to the device-id or contact address does not seem to solve > anything, because the PoC server does not have any registration > information. > > So I will start some discussion with the OMA folks as for what is an > acceptable solution for this... Perhaps we should have been using hard > state publication instead... sigh. Why isn't this another attribute of presence state? The POC client then needs to be a presence client and see individual tuples. It can then decide how to handle on a per-tuple basis. Paul > /Miguel > > Paul Kyzivat wrote: > >> I have one question on this document: >> >> 5.16 Multiple Sources for Event State >> >> RFC 3903 [8] requires event packages to specify whether multiple >> sources can contribute to the event state view at the ESC. >> >> This event package allows different EPAs to publish the PoC settings >> for a particular user. For a given user the ESC will consider the >> last received PoC settings documents segment as the valid updated >> event state. >> >> I don't follow this. If two phones are registered and publishing then >> you take the most recent publication as applying to the AoR as a whole? >> >> That doesn't make sense to me. One might be in auto answer mode and >> the other in manual mode. When a call comes in, the proper treatment >> is a function of which the call is directed to. >> >> There is a problem in that there is no good way for the ESC to >> correlate the published settings with a particular registration, but >> that seems to be what is needed. >> >> As described, the two phones will both be registered and will both >> periodically update their POC settings in an uncoordinated way. Just >> doesn't work. >> >> Paul >> >> >> >> Miguel Garcia wrote: >> >>> Hi: >>> >>> I have just submitted a new version of the poc-settings event package >>> draft. Until it is available, you can download a copy from: >>> >>> http://people.nokia.net/~miguel/drafts/draft-garcia-sipping-poc-isb-am-02.txt >>> >>> or >>> http://people.nokia.net/~miguel/drafts/draft-garcia-sipping-poc-isb-am-02.html >>> >>> >>> This contains the mostly editorial comments that I got in the mailing >>> list and in the exper review. >>> >>> Regards, >>> >>> Miguel >> >> >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Mon Jun 27 15:38:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmzRC-0003oy-20; Mon, 27 Jun 2005 15:38:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmzR8-0003oE-1J; Mon, 27 Jun 2005 15:38:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28508; Mon, 27 Jun 2005 15:38:27 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmzqL-0007tM-3d; Mon, 27 Jun 2005 16:04:33 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DmzR6-0004pT-54; Mon, 27 Jun 2005 15:38:28 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 27 Jun 2005 15:38:28 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: sipping chair , Internet Architecture Board , sipping chair , sipping mailing list , sipping chair , RFC Editor Subject: [Sipping] Protocol Action: 'Session Initiation Protocol Call Control - Conferencing for User Agents' to BCP X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org The IESG has approved the following document: - 'Session Initiation Protocol Call Control - Conferencing for User Agents ' as a BCP This document is the product of the Session Initiation Proposal Investigation Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-conferencing-07.txt Technical Summary This specification defines conferencing call control features for the Session Initiation Protocol (SIP). This document builds on the Conferencing Requirements and Framework documents to define how a tightly coupled SIP conference works. The approach is explored from different user agent (UA) types perspective: conference-unaware, conference-aware and focus UAs. The use of URIs in conferencing, OPTIONS for capabilities discovery, and call control using REFER are covered in detail with example call flow diagrams. The usage of the isfocus feature tag is defined. This specification uses the concepts and definitions from the WG's "High Level Requirements for Tightly Coupled SIP Conferencing," and "A Framework for Conferencing with the Session Initiation Protocol," approved earlier. In the tightly coupled architecture, a UA, known as participant, establishes a SIP dialog with another UA, known as focus. The focus is the central point of control, authentication and authorization. This specification defines the operations of a focus and participant UAs. Not that only the signaling (SIP) needs to be centralized in this model - the media can be centrally mixed, distributed, or even multicast (by the nature of the media descriptions that the model establishes). For a full discussion of this architecture, see the SIP conferencing Framework mentioned already. already. This document presents the basic call control (dial-in and dial-out) conferencing building blocks from the UA perspective. Possible applications include ad-hoc conferences and scheduled conferences. Working Group Summary The working group strongly supported advancing this document. 3GPP and OMA have notified the IETF that this specification is a critical dependency. Protocol Quality Allison Mankin reviewed the specification for the IESG. It was revised to add specific security considerations. Due to a General Area Directorate Review, it was revised to add some additional context and introduction. Gonzalo Camarillo is the working group shepherd. Notes to the RFC Editor Section 3.1 Remove the sentence: "A focus SHOULD utilize a GRUU as discussed in Section 4.2." Section 4.2 OLD: The Conference URI MUST have the GRUU (Globally Routable User Agent URI) properties as detailed in [16]. NEW: By their nature, the conferences supported by this specification are centralized. Therefore, typically a conferencing system needs to allocate a SIP Conference URI such that SIP requests to this URI are not forked and are routed to a dedicated conference focus. For example, for a globally accessible SIP conference could be well constructed with a Conference URI using a Globally Routable User Agent URI (GRUU) (defined in [16]), because of its ability to support the non-forking and global routability requirements. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Mon Jun 27 17:52:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn1WQ-0007GO-09; Mon, 27 Jun 2005 17:52:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn1WO-0007G0-G0 for sipping@megatron.ietf.org; Mon, 27 Jun 2005 17:52:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26161 for ; Mon, 27 Jun 2005 17:52:01 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dn1vc-0007Eq-Mu for Sipping@ietf.org; Mon, 27 Jun 2005 18:18:09 -0400 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j5RLtZsB018144 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 27 Jun 2005 16:55:36 -0500 In-Reply-To: <005301c578fe$93ba65e0$6502a8c0@BEMBUSTER> References: <20050624123239.4623.qmail@web25502.mail.ukl.yahoo.com> <005301c578fe$93ba65e0$6502a8c0@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sipping] Missed calls event package Date: Mon, 27 Jun 2005 16:52:08 -0500 To: "Jeroen van Bemmel" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: Sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org On Jun 24, 2005, at 3:52 PM, Jeroen van Bemmel wrote: > Hi, > > Is there an event package defined for notification / retrieval of > missed calls (in particular the ones that occur when you have no SIP > UA online, which requires network support) > I'm not aware of a standard event package here. There is a product listing such a feature at: http://www.dynamicsoft.com/prod_sol/MissedCallSummary/ missedcallsummary.php But I think it might be feasible to use Message Waiting Indicator, RFC 3842, to do something similar. -- 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 sipping-bounces@ietf.org Mon Jun 27 18:43:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn2KC-00021R-0f; Mon, 27 Jun 2005 18:43:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn2KA-00021M-07 for sipping@megatron.ietf.org; Mon, 27 Jun 2005 18:43:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05096 for ; Mon, 27 Jun 2005 18:43:26 -0400 (EDT) Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dn2jJ-00032c-5J for Sipping@ietf.org; Mon, 27 Jun 2005 19:09:34 -0400 Received: (qmail 7494 invoked by uid 10); 27 Jun 2005 22:43:05 -0000 Received: (vexira-qq 07488-84553A57 invoked from network) 28 Jun 2005 00:43:05 +0200 Received: from unknown (HELO BEMBUSTER) ([81.59.101.130]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 27 Jun 2005 22:43:05 -0000 Message-ID: <003a01c57b69$92b16910$6502a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Dean Willis" References: <20050624123239.4623.qmail@web25502.mail.ukl.yahoo.com> <005301c578fe$93ba65e0$6502a8c0@BEMBUSTER> Subject: Re: [Sipping] Missed calls event package Date: Tue, 28 Jun 2005 00:43:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode01.zonnet.nl) X-Spam-Score: 1.2 (+) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: Sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Hi Dean, Arif, Thank you for your pointers, indeed I think that RFC3842 could solve my problem I do feel people could benefit from having a standards based solution, I also did find some products that support similar features (although more often client side than server side, i.e. a different feature). One issue that I think would still need to be standardized is the manner in which a UA would recognise a message as representing a missed call. You could of course simply scan for all 'From' headers you can find, but they may not all represent headers from a previous INVITE (could also be e.g. MESSAGE, or a received SMS). To me none of the message context values from RFC3458 can accurately represent this (see http://www.faqs.org/rfcs/rfc3458.html) Perhaps something like: Message-Context : sip-inviteRegards, jeroen ----- Original Message ----- From: "Dean Willis" To: "Jeroen van Bemmel" Cc: Sent: Monday, June 27, 2005 11:52 PM Subject: Re: [Sipping] Missed calls event package > > On Jun 24, 2005, at 3:52 PM, Jeroen van Bemmel wrote: > >> Hi, >> >> Is there an event package defined for notification / retrieval of missed >> calls (in particular the ones that occur when you have no SIP UA online, >> which requires network support) >> > > I'm not aware of a standard event package here. There is a product > listing such a feature at: > > http://www.dynamicsoft.com/prod_sol/MissedCallSummary/ > missedcallsummary.php > > But I think it might be feasible to use Message Waiting Indicator, RFC > 3842, to do something similar. > > -- > 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 sipping-bounces@ietf.org Mon Jun 27 20:34:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn442-0000Am-8x; Mon, 27 Jun 2005 20:34:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn440-0000AR-0t for sipping@megatron.ietf.org; Mon, 27 Jun 2005 20:34:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16956 for ; Mon, 27 Jun 2005 20:34:54 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dn4TD-0004OH-HO for sipping@ietf.org; Mon, 27 Jun 2005 21:01:01 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by sj-iport-4.cisco.com with ESMTP; 27 Jun 2005 17:34:44 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5S0YhZu024057; Mon, 27 Jun 2005 20:34:43 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Jun 2005 20:34:42 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Jun 2005 20:34:42 -0400 Message-ID: <42C09B22.5000204@cisco.com> Date: Mon, 27 Jun 2005 20:34:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sipping] Missed calls event package References: <20050624123239.4623.qmail@web25502.mail.ukl.yahoo.com> <005301c578fe$93ba65e0$6502a8c0@BEMBUSTER> <003a01c57b69$92b16910$6502a8c0@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jun 2005 00:34:42.0541 (UTC) FILETIME=[2CF489D0:01C57B79] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Cc: Sipping@ietf.org, Dean Willis X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Jeroen van Bemmel wrote: > Hi Dean, Arif, > > Thank you for your pointers, indeed I think that RFC3842 could solve my > problem Well, it might help with reporting about missed calls. It doesn't help with capturing the record of missed calls so that it may be reported. > I do feel people could benefit from having a standards based solution, I > also did find some products that support similar features (although more > often client side than server side, i.e. a different feature). My (non-sip) phone displays lists of missed, received, and placed calls. I can see MWI being extended to support missed calls - I see little difference from a zero length voicemail message. But I find it harder to see it being extended to support the others. > One issue that I think would still need to be standardized is the manner > in which a UA would recognise a message as representing a missed call. Well, that is the rub isn't it. For the typical kind of sip system, where there is a proxy responsible for an AOR, and one or more UAs registered for that AOR, there is no guarantee that a UA will even see all the calls that are missed. The proxy may have been set to Do Not Disturb mode and refuse them without offering to a UA, or the call may be serial forked and one UA may return a 6xx response, preventing the call from being offered to the others, etc. Even for the proxy there need to be some definitions. Sometimes (e.g. voicemail) if the call is picked up by an automaton then it was missed. But in the case of an IVR that is not so. > You could of course simply scan for all 'From' headers you can find, but Scan *what*? This could be an area for new work, starting with trying to define the requirements. You would have to see if there is sufficient interest to pursue it at this time. Paul > they may not all represent headers from a previous INVITE (could also be > e.g. MESSAGE, or a received SMS). To me none of the message context > values from RFC3458 can accurately represent this (see > http://www.faqs.org/rfcs/rfc3458.html) > > Perhaps something like: > Message-Context : sip-inviteRegards, > jeroen > > > ----- Original Message ----- From: "Dean Willis" > > To: "Jeroen van Bemmel" > Cc: > Sent: Monday, June 27, 2005 11:52 PM > Subject: Re: [Sipping] Missed calls event package > > >> >> On Jun 24, 2005, at 3:52 PM, Jeroen van Bemmel wrote: >> >>> Hi, >>> >>> Is there an event package defined for notification / retrieval of >>> missed calls (in particular the ones that occur when you have no SIP >>> UA online, which requires network support) >>> >> >> I'm not aware of a standard event package here. There is a product >> listing such a feature at: >> >> http://www.dynamicsoft.com/prod_sol/MissedCallSummary/ >> missedcallsummary.php >> >> But I think it might be feasible to use Message Waiting Indicator, RFC >> 3842, to do something similar. >> >> -- >> 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 > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Tue Jun 28 02:21:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn9St-0000QP-VU; Tue, 28 Jun 2005 02:20:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn9Sq-0000Pq-4K for sipping@megatron.ietf.org; Tue, 28 Jun 2005 02:20:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01005 for ; Tue, 28 Jun 2005 02:20:54 -0400 (EDT) Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dn9s7-0006jG-5d for Sipping@ietf.org; Tue, 28 Jun 2005 02:47:04 -0400 Received: (qmail 27560 invoked by uid 10); 28 Jun 2005 06:20:44 -0000 Received: (vexira-qq 27554-107498E0 invoked from network) 28 Jun 2005 08:20:44 +0200 Received: from unknown (HELO BEMBUSTER) ([81.59.101.130]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 28 Jun 2005 06:20:44 -0000 Message-ID: <000801c57ba9$81e7aaa0$6502a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Paul Kyzivat" References: <20050624123239.4623.qmail@web25502.mail.ukl.yahoo.com> <005301c578fe$93ba65e0$6502a8c0@BEMBUSTER> <003a01c57b69$92b16910$6502a8c0@BEMBUSTER> <42C09B22.5000204@cisco.com> Subject: Re: [Sipping] Missed calls event package Date: Tue, 28 Jun 2005 08:20:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode01.zonnet.nl) X-Spam-Score: 1.2 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: Sipping@ietf.org, Dean Willis X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org >> You could of course simply scan for all 'From' headers you can find, but > > Scan *what*? > The body of the NOTIFY you get from MWI. But I think you agree with me here that it is not that simple > This could be an area for new work, starting with trying to define the > requirements. You would have to see if there is sufficient interest to > pursue it at this time. > Right. So this is a call for interest: I am hereby asking people to respond to the mailinglist with comments and/or indication of interest in this topic Thanks and regards, Jeroen _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Tue Jun 28 03:55:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnAw2-0002vh-LR; Tue, 28 Jun 2005 03:55:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnAvz-0002vR-Ud for sipping@megatron.ietf.org; Tue, 28 Jun 2005 03:55:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11004 for ; Tue, 28 Jun 2005 03:55:06 -0400 (EDT) Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnBLJ-0008QE-0b for sipping@ietf.org; Tue, 28 Jun 2005 04:21:17 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j5S7q42K030975; Tue, 28 Jun 2005 10:52:08 +0300 Received: from esebh003.NOE.Nokia.com ([172.21.138.82]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Jun 2005 10:54:48 +0300 Received: from [127.0.0.1] ([10.162.17.16]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 28 Jun 2005 10:54:48 +0300 Message-ID: <42C10247.7050100@nokia.com> Date: Tue, 28 Jun 2005 10:54:47 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sipping] PoC-settings event package References: <42B15172.6080604@nokia.com> <42BC1155.8000306@cisco.com> <42BFB183.4040301@nokia.com> <42C008D8.8060800@cisco.com> In-Reply-To: <42C008D8.8060800@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jun 2005 07:54:48.0206 (UTC) FILETIME=[A7F542E0:01C57BB6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Cc: sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Hi Paul: Yes, this could have been combined with presence. Unfortunately the data model wasn't still that developped when OMA analyze presence as an option. In fact, presence is an optional function in PoC. So a bit of historical reasons. /Miguel Paul Kyzivat wrote: > > > Miguel Garcia wrote: > >> Hi Paul: >> >> I acknowledge the problem, which hasn't been a problem for the OMA >> folks since they assume a single terminal for a given identity. Of >> course, this does not solve anything, and I agree this issue should be >> fixed. >> >> I am thinking of possible solutions to this problem. Linking the >> poc-settings to the device-id or contact address does not seem to >> solve anything, because the PoC server does not have any registration >> information. >> >> So I will start some discussion with the OMA folks as for what is an >> acceptable solution for this... Perhaps we should have been using hard >> state publication instead... sigh. > > > Why isn't this another attribute of presence state? The POC client then > needs to be a presence client and see individual tuples. It can then > decide how to handle on a per-tuple basis. > > Paul > >> /Miguel >> >> Paul Kyzivat wrote: >> >>> I have one question on this document: >>> >>> 5.16 Multiple Sources for Event State >>> >>> RFC 3903 [8] requires event packages to specify whether multiple >>> sources can contribute to the event state view at the ESC. >>> >>> This event package allows different EPAs to publish the PoC settings >>> for a particular user. For a given user the ESC will consider the >>> last received PoC settings documents segment as the valid updated >>> event state. >>> >>> I don't follow this. If two phones are registered and publishing then >>> you take the most recent publication as applying to the AoR as a whole? >>> >>> That doesn't make sense to me. One might be in auto answer mode and >>> the other in manual mode. When a call comes in, the proper treatment >>> is a function of which the call is directed to. >>> >>> There is a problem in that there is no good way for the ESC to >>> correlate the published settings with a particular registration, but >>> that seems to be what is needed. >>> >>> As described, the two phones will both be registered and will both >>> periodically update their POC settings in an uncoordinated way. Just >>> doesn't work. >>> >>> Paul >>> >>> >>> >>> Miguel Garcia wrote: >>> >>>> Hi: >>>> >>>> I have just submitted a new version of the poc-settings event >>>> package draft. Until it is available, you can download a copy from: >>>> >>>> http://people.nokia.net/~miguel/drafts/draft-garcia-sipping-poc-isb-am-02.txt >>>> >>>> or >>>> http://people.nokia.net/~miguel/drafts/draft-garcia-sipping-poc-isb-am-02.html >>>> >>>> >>>> This contains the mostly editorial comments that I got in the >>>> mailing list and in the exper review. >>>> >>>> Regards, >>>> >>>> Miguel >>> >>> >>> >>> >>> _______________________________________________ >>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>> This list is for NEW development of the application of SIP >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sip@ietf.org for new developments of core SIP >> >> >> -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Tue Jun 28 05:00:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnBxe-0007zK-1F; Tue, 28 Jun 2005 05:00:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnBxb-0007zA-NB for sipping@megatron.ietf.org; Tue, 28 Jun 2005 05:00:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14594 for ; Tue, 28 Jun 2005 05:00:49 -0400 (EDT) Received: from smtp2.dataconnection.com ([192.91.191.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnCMu-0006XX-Q6 for sipping@ietf.org; Tue, 28 Jun 2005 05:27:02 -0400 Received: from enfimail1.datcon.co.uk ([172.19.14.253]) by smtp2.dataconnection.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Jun 2005 10:00:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Jun 2005 10:00:33 +0100 Message-ID: <630E1C9EE3D38E44A9E1410DE88197960BA539@enfimail1.datcon.co.uk> Thread-Topic: draft-smith-sipping-auth-examples-01 updated Thread-Index: AcV7v9c+FtSCuwoaTbycnk/8Nt6JXg== From: "Paul D.Smith" To: "SIPPING WG" X-OriginalArrivalTime: 28 Jun 2005 09:00:35.0592 (UTC) FILETIME=[D8C89080:01C57BBF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Subject: [Sipping] draft-smith-sipping-auth-examples-01 updated X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org All, draft-smith-sipping-auth-examples-01 has been updated and is now = available via the IETF website. The changes made were to correct a = couple of typos. identified by various readers and to update the = boilerplate statements required by the IETF. The abstract of this draft = is given below. Abstract: RFC3261 [2] recommends that SIP requests be authenticated using HTTP = Digest authentication as defined in RFC2617 [3], and many vendors have = successfully added this function to their products. However = implementation bugs are still being observed both at interoperability = events and in the field. This document provides worked examples of = Digest authentication usage in SIP. It is intended to help new SIP = implementers, and to provide a common set of test authentication = examples against which an implementation may be checked.=20 Paul D Smith Network Protocols Group=20 Data Connection Ltd (DCL) Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com=20 Fax: +44 20 8363 1039 Web: http://www.dataconnection.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 sipping-bounces@ietf.org Tue Jun 28 05:00:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnBxg-0007zk-9K; Tue, 28 Jun 2005 05:00:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnBxc-0007zF-DG for sipping@megatron.ietf.org; Tue, 28 Jun 2005 05:00:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14597 for ; Tue, 28 Jun 2005 05:00:50 -0400 (EDT) Received: from smtp2.dataconnection.com ([192.91.191.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnCMw-0006XX-G9 for sipping@ietf.org; Tue, 28 Jun 2005 05:27:02 -0400 Received: from enfimail1.datcon.co.uk ([172.19.14.253]) by smtp2.dataconnection.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Jun 2005 10:00:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Jun 2005 10:00:41 +0100 Message-ID: <630E1C9EE3D38E44A9E1410DE88197960BA53A@enfimail1.datcon.co.uk> Thread-Topic: Should WG adopt draft-smith-sipping-auth-examples-01? Thread-Index: AcV7v9wC1so4bpY6SfGItBf5gNAbkA== From: "Paul D.Smith" To: "SIPPING WG" X-OriginalArrivalTime: 28 Jun 2005 09:00:43.0419 (UTC) FILETIME=[DD72DEB0:01C57BBF] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Cc: Ian Clarkson , "Paul D.Smith" Subject: [Sipping] Should WG adopt draft-smith-sipping-auth-examples-01? X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org All, Various development teams have contacted Ian and myself directly to = point out errors in previous versions of this draft, and also to let us = know that they have found the draft useful. This suggests to us that = this draft is of benefit to the SIP community and we would therefore = like to solicit feedback from the WG as to whether the WG should adopt = this draft. We would very much like to get feedback from anyone who has read the = draft indicating whether it was useful, or not, easy to use, or not, and = whether you believe the draft is worthy of adoption by the WG. Ian and = I will not be forwarding e-mails that we have received directly to the = mailing list so if you have contacted us already and are willing to make = your usage of the draft known, then please post directly to the mailing = list. We look forward to reading any feedback that this e-mail generates. Regards, Paul D Smith & Ian Clarkson Network Protocols Group=20 Data Connection Ltd (DCL) Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com Email: ian.clarkson@dataconnection.com Fax: +44 20 8363 1039 Web: http://www.dataconnection.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 sipping-bounces@ietf.org Tue Jun 28 07:42:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnEUL-0005XT-UL; Tue, 28 Jun 2005 07:42:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnEUJ-0005WO-S6 for sipping@megatron.ietf.org; Tue, 28 Jun 2005 07:42:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25849 for ; Tue, 28 Jun 2005 07:42:46 -0400 (EDT) Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnEtd-0008O6-Vw for Sipping@ietf.org; Tue, 28 Jun 2005 08:08:59 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id j5SBgTG5028537 for ; Tue, 28 Jun 2005 04:42:29 -0700 (MST) Received: from zin24exm02.corp.mot.com (zin24exm02.ap.mot.com [10.232.26.1]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id j5SBjxIZ008817 for ; Tue, 28 Jun 2005 06:46:00 -0500 (CDT) Received: by zin24exm02.ap.mot.com with Internet Mail Service (5.5.2657.72) id ; Tue, 28 Jun 2005 17:12:25 +0530 Message-ID: <19B94C8C331A7546A88C88502083353B014B27D3@zin24exm02.ap.mot.com> From: Avasarala Ranjit-A20990 To: Jeroen van Bemmel , Paul Kyzivat Subject: RE: [Sipping] Missed calls event package Date: Tue, 28 Jun 2005 17:12:19 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Sipping@ietf.org, Dean Willis X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Hi The call history is anyway maintained in the UA, like recent calls. So I am not sure how useful the event package will be. Also the event package will be stored on server. If we have this event package, that package could have a mechanism where the user will subscribe for call history and server will send the call history at periodic intervals. or everytime there is a change in the call history data. Is this what we are speaking about? Regards Ranjit -----Original Message----- From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf Of Jeroen van Bemmel Sent: Tuesday, June 28, 2005 11:51 AM To: Paul Kyzivat Cc: Sipping@ietf.org; Dean Willis Subject: Re: [Sipping] Missed calls event package >> You could of course simply scan for all 'From' headers you can find, >> but > > Scan *what*? > The body of the NOTIFY you get from MWI. But I think you agree with me here that it is not that simple > This could be an area for new work, starting with trying to define the > requirements. You would have to see if there is sufficient interest to > pursue it at this time. > Right. So this is a call for interest: I am hereby asking people to respond to the mailinglist with comments and/or indication of interest in this topic Thanks and regards, Jeroen _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Tue Jun 28 08:40:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnFOD-0003VR-K2; Tue, 28 Jun 2005 08:40:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnFO9-0003SW-Qg for sipping@megatron.ietf.org; Tue, 28 Jun 2005 08:40:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02527 for ; Tue, 28 Jun 2005 08:40:28 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnFnV-0005wE-LI for sipping@ietf.org; Tue, 28 Jun 2005 09:06:42 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 28 Jun 2005 05:40:20 -0700 X-IronPort-AV: i="3.93,239,1115017200"; d="scan'208"; a="194842064:sNHT29576292" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5SCeFaC003420; Tue, 28 Jun 2005 08:40:19 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Jun 2005 08:40:15 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Jun 2005 08:40:15 -0400 Message-ID: <42C1452E.2040908@cisco.com> Date: Tue, 28 Jun 2005 08:40:14 -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: Avasarala Ranjit-A20990 Subject: Re: [Sipping] Missed calls event package References: <19B94C8C331A7546A88C88502083353B014B27D3@zin24exm02.ap.mot.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jun 2005 12:40:15.0310 (UTC) FILETIME=[8881EEE0:01C57BDE] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Cc: Dean Willis , Sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Avasarala Ranjit-A20990 wrote: > Hi > The call history is anyway maintained in the UA, like recent calls. So > I am not sure how useful the event package will be. Also the event package > will be stored on server. > If we have this event package, that package could have a mechanism where > the user will subscribe for call history and server will send the call > history at periodic intervals. or everytime there is a change in the call > history data. A UA can only maintain the history that it is aware of. If there can be multiple UAs servicing the same AOR, or if a proxy intervenes on some calls to the AOR, then a UA does not have a complete history of calls - missed, received, or placed. Do you want your livingroom phone to think there was a missed call, when in fact it was answered in the bedroom? Paul > Is this what we are speaking about? > > > > Regards > Ranjit > > > > > > -----Original Message----- > From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf > Of Jeroen van Bemmel > Sent: Tuesday, June 28, 2005 11:51 AM > To: Paul Kyzivat > Cc: Sipping@ietf.org; Dean Willis > Subject: Re: [Sipping] Missed calls event package > > > >>>You could of course simply scan for all 'From' headers you can find, >>>but >> >>Scan *what*? >> > > > The body of the NOTIFY you get from MWI. But I think you agree with me here > that it is not that simple > > >>This could be an area for new work, starting with trying to define the >>requirements. You would have to see if there is sufficient interest to >>pursue it at this time. >> > > > Right. So this is a call for interest: I am hereby asking people to respond > to the mailinglist with comments and/or indication of interest in this topic > > Thanks and regards, > > Jeroen > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Tue Jun 28 09:51:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnGVB-0006In-J5; Tue, 28 Jun 2005 09:51:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnGV7-0006Ia-Tx for sipping@megatron.ietf.org; Tue, 28 Jun 2005 09:51:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09362 for ; Tue, 28 Jun 2005 09:51:44 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnGuS-0005K1-AT for sipping@ietf.org; Tue, 28 Jun 2005 10:17:58 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 28 Jun 2005 06:51:34 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5SDpUVX014186; Tue, 28 Jun 2005 06:51:31 -0700 (PDT) Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j5SDp4b6017315; Tue, 28 Jun 2005 06:51:05 -0700 In-Reply-To: <42C1452E.2040908@cisco.com> References: <19B94C8C331A7546A88C88502083353B014B27D3@zin24exm02.ap.mot.com> <42C1452E.2040908@cisco.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <419E5B50-5C3F-4FFC-9842-6E6370A84686@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [Sipping] Missed calls event package Date: Tue, 28 Jun 2005 09:51:27 -0400 To: Paul Kyzivat X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1119966666.56724"; x:"432200"; a:"rsa-sha1"; b:"nofws:2989"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"Y4K3MkO1YnJCO1LHXSQwrmElw2suRHF4LIchdmzPp1mYUo2Wzp2wBBuXrMQewyHwxx23xwG5" "zoUMtZvHdEzp9bqPRNq4VB89Sqgq9EzJjKHwnFT0kche9QQvq0HDrRLH3x93dZm0ysYku1dFnU/" "7ZWEsSbSjbncV9Ail6wH2ArU="; c:"From: David R Oran "; c:"Subject: Re: [Sipping] Missed calls event package"; c:"Date: Tue, 28 Jun 2005 09:51:27 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit Cc: Sipping@ietf.org, Dean Willis X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org On Jun 28, 2005, at 8:40 AM, Paul Kyzivat wrote: > > > Avasarala Ranjit-A20990 wrote: > >> Hi >> The call history is anyway maintained in the UA, like recent >> calls. So >> I am not sure how useful the event package will be. Also the event >> package >> will be stored on server. If we have this event package, that >> package could have a mechanism where >> the user will subscribe for call history and server will send the >> call >> history at periodic intervals. or everytime there is a change in >> the call >> history data. >> > > A UA can only maintain the history that it is aware of. If there > can be multiple UAs servicing the same AOR, or if a proxy > intervenes on some calls to the AOR, then a UA does not have a > complete history of calls - missed, received, or placed. > > Do you want your livingroom phone to think there was a missed call, > when in fact it was answered in the bedroom? > This was in fact one of the motivating cases for the reason header on CANCEL - the UA receiving the CANCEL could tell the difference between an abandoned call and one that was picked up at a different UA. That of course does not allow a UA to learn about calls to the AOR that were missed while the UA was offline, or calls whose caller prefs caused the UA to be bypassed and not contacted, or calls that got screened out, etc. I think a standardized way to obtain a call log for an AoR with the appropriate dispositions for each call would be a very nice thing. Not clear the right way to do it is an event package though. In any event, an common "call log" XML schema seems to be a prerequisite to making any particular fetch or notification machinery work in an interoperable fashion. Could we start there? Dave. > Paul > > >> Is this what we are speaking about? >> Regards >> Ranjit >> -----Original Message----- >> From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] >> On Behalf >> Of Jeroen van Bemmel >> Sent: Tuesday, June 28, 2005 11:51 AM >> To: Paul Kyzivat >> Cc: Sipping@ietf.org; Dean Willis >> Subject: Re: [Sipping] Missed calls event package >> >>>> You could of course simply scan for all 'From' headers you can >>>> find, but >>>> >>> >>> Scan *what*? >>> >>> >> The body of the NOTIFY you get from MWI. But I think you agree >> with me here that it is not that simple >> >>> This could be an area for new work, starting with trying to >>> define the >>> requirements. You would have to see if there is sufficient >>> interest to pursue it at this time. >>> >>> >> Right. So this is a call for interest: I am hereby asking people >> to respond to the mailinglist with comments and/or indication of >> interest in this topic >> Thanks and regards, >> Jeroen >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP >> > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Tue Jun 28 10:24:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnH0r-0006ur-2t; Tue, 28 Jun 2005 10:24:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnH0p-0006ug-4w for sipping@megatron.ietf.org; Tue, 28 Jun 2005 10:24:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13674 for ; Tue, 28 Jun 2005 10:24:28 -0400 (EDT) From: Udit_Goyal@3com.com Received: from plmler1.mail.eds.com ([199.228.142.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnHQ9-0000TD-0l for Sipping@ietf.org; Tue, 28 Jun 2005 10:50:43 -0400 Received: from plmlir4.mail.eds.com (plmlir4-2.mail.eds.com [199.228.142.134]) by plmler1.mail.eds.com (8.13.2/8.12.10) with ESMTP id j5SEOEbI015194; Tue, 28 Jun 2005 14:24:17 GMT Received: from plmlir4.mail.eds.com (localhost [127.0.0.1]) by plmlir4.mail.eds.com (8.13.2/8.12.10) with ESMTP id j5SENcj7023255; Tue, 28 Jun 2005 09:23:39 -0500 Received: from usut001.3com.com ([205.142.126.149]) by plmlir4.mail.eds.com (8.13.2/8.12.10) with ESMTP id j5SENciI023250; Tue, 28 Jun 2005 09:23:38 -0500 In-Reply-To: <419E5B50-5C3F-4FFC-9842-6E6370A84686@cisco.com> To: David R Oran Subject: Re: [Sipping] Missed calls event package MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: Date: Tue, 28 Jun 2005 10:29:52 -0400 X-MIMETrack: Serialize by Router on USUT001/US/3Com(Release 6.0.3|September 26, 2003) at 06/28/2005 07:23:38 AM, Serialize complete at 06/28/2005 07:23:38 AM X-Spam-Score: 0.3 (/) X-Scan-Signature: 65215b440f7ab00ca9514de4a7a89926 Cc: Paul Kyzivat , Sipping@ietf.org, Dean Willis X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0294238488==" Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org This is a multipart message in MIME format. --===============0294238488== Content-Type: multipart/alternative; boundary="=_alternative 004EFB388525702E_=" This is a multipart message in MIME format. --=_alternative 004EFB388525702E_= Content-Type: text/plain; charset="US-ASCII" Hi, I totally agree with what David said. We should have a generic mechanism for call logs which will suffice for this requirement too. It is more like data retreival from the server. We can have a similar mechanism for providing directory services using SIP. I havent seen any SIP thread for directory services. Regards, Udit David R Oran Sent by: sipping-bounces@ietf.org 06/28/2005 09:51 AM To Paul Kyzivat cc Sipping@ietf.org, Dean Willis Subject Re: [Sipping] Missed calls event package On Jun 28, 2005, at 8:40 AM, Paul Kyzivat wrote: > > > Avasarala Ranjit-A20990 wrote: > >> Hi >> The call history is anyway maintained in the UA, like recent >> calls. So >> I am not sure how useful the event package will be. Also the event >> package >> will be stored on server. If we have this event package, that >> package could have a mechanism where >> the user will subscribe for call history and server will send the >> call >> history at periodic intervals. or everytime there is a change in >> the call >> history data. >> > > A UA can only maintain the history that it is aware of. If there > can be multiple UAs servicing the same AOR, or if a proxy > intervenes on some calls to the AOR, then a UA does not have a > complete history of calls - missed, received, or placed. > > Do you want your livingroom phone to think there was a missed call, > when in fact it was answered in the bedroom? > This was in fact one of the motivating cases for the reason header on CANCEL - the UA receiving the CANCEL could tell the difference between an abandoned call and one that was picked up at a different UA. That of course does not allow a UA to learn about calls to the AOR that were missed while the UA was offline, or calls whose caller prefs caused the UA to be bypassed and not contacted, or calls that got screened out, etc. I think a standardized way to obtain a call log for an AoR with the appropriate dispositions for each call would be a very nice thing. Not clear the right way to do it is an event package though. In any event, an common "call log" XML schema seems to be a prerequisite to making any particular fetch or notification machinery work in an interoperable fashion. Could we start there? Dave. > Paul > > >> Is this what we are speaking about? >> Regards >> Ranjit >> -----Original Message----- >> From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] >> On Behalf >> Of Jeroen van Bemmel >> Sent: Tuesday, June 28, 2005 11:51 AM >> To: Paul Kyzivat >> Cc: Sipping@ietf.org; Dean Willis >> Subject: Re: [Sipping] Missed calls event package >> >>>> You could of course simply scan for all 'From' headers you can >>>> find, but >>>> >>> >>> Scan *what*? >>> >>> >> The body of the NOTIFY you get from MWI. But I think you agree >> with me here that it is not that simple >> >>> This could be an area for new work, starting with trying to >>> define the >>> requirements. You would have to see if there is sufficient >>> interest to pursue it at this time. >>> >>> >> Right. So this is a call for interest: I am hereby asking people >> to respond to the mailinglist with comments and/or indication of >> interest in this topic >> Thanks and regards, >> Jeroen >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP >> > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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 004EFB388525702E_= Content-Type: text/html; charset="US-ASCII"
Hi,

I totally agree with what David said.
We should have a generic mechanism for call logs which will suffice for this requirement too.
It is more like data retreival from the server.

We can have a similar mechanism for providing directory services using SIP. I havent seen any SIP thread for directory services.

Regards,
Udit




David R Oran <oran@cisco.com>
Sent by: sipping-bounces@ietf.org

06/28/2005 09:51 AM

To
Paul Kyzivat <pkyzivat@cisco.com>
cc
Sipping@ietf.org, Dean Willis <dean.willis@softarmor.com>
Subject
Re: [Sipping] Missed calls event package






On Jun 28, 2005, at 8:40 AM, Paul Kyzivat wrote:
>
>
> Avasarala Ranjit-A20990 wrote:
>
>> Hi
>>      The call history is anyway maintained in the UA, like recent
>> calls. So
>> I am not sure how useful the event package will be. Also the event
>> package
>> will be stored on server.  If we have this event package, that
>> package could have a mechanism where
>> the user will subscribe for call history and server will send the
>> call
>> history at periodic intervals. or everytime there is a change in
>> the call
>> history data.
>>
>
> A UA can only maintain the history that it is aware of. If there
> can be multiple UAs servicing the same AOR, or if a proxy
> intervenes on some calls to the AOR, then a UA does not have a
> complete history of calls - missed, received, or placed.
>
> Do you want your livingroom phone to think there was a missed call,
> when in fact it was answered in the bedroom?
>
This was in fact one of the motivating cases for the reason header on
CANCEL - the UA receiving the CANCEL could tell the difference
between an abandoned call and one that was picked up at a different UA.
That of course does not allow a UA to learn about calls to the AOR
that were missed while the UA was offline, or calls whose caller
prefs caused the UA to be bypassed and not contacted, or calls that
got screened out, etc.
I think a standardized way to obtain a call log for an AoR with the
appropriate dispositions for each call would be a very nice thing.
Not clear the right way to do it is an event package though. In any
event, an common "call log" XML schema seems to be a prerequisite to
making any particular fetch or notification machinery work in an
interoperable fashion.
Could we start there?
Dave.
>     Paul
>
>
>>  Is this what we are speaking about?
>>   Regards
>> Ranjit
>> -----Original Message-----
>> From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org]
>> On Behalf
>> Of Jeroen van Bemmel
>> Sent: Tuesday, June 28, 2005 11:51 AM
>> To: Paul Kyzivat
>> Cc: Sipping@ietf.org; Dean Willis
>> Subject: Re: [Sipping] Missed calls event package
>>
>>>> You could of course simply scan for all 'From' headers you can
>>>> find, but
>>>>
>>>
>>> Scan *what*?
>>>
>>>
>> The body of the NOTIFY you get from MWI. But I think you agree
>> with me here that it is not that simple
>>
>>> This could be an area for new work, starting with trying to
>>> define the
>>> requirements. You would have to see if there is sufficient
>>> interest to pursue it at this time.
>>>
>>>
>> Right. So this is a call for interest: I am hereby asking people
>> to respond to the mailinglist with comments and/or indication of
>> interest in this topic
>> Thanks and regards,
>> Jeroen
>> _______________________________________________
>> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>> This list is for NEW development of the application of SIP
>> Use sip-implementors@cs.columbia.edu for questions on current sip
>> Use sip@ietf.org for new developments of core SIP
>> _______________________________________________
>> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>> This list is for NEW development of the application of SIP
>> Use sip-implementors@cs.columbia.edu for questions on current sip
>> Use sip@ietf.org for new developments of core SIP
>>
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
>
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the 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 004EFB388525702E_=-- --===============0294238488== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============0294238488==-- From sipping-bounces@ietf.org Tue Jun 28 10:41:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnHHP-00048U-6T; Tue, 28 Jun 2005 10:41:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnHHM-00047k-GO for sipping@megatron.ietf.org; Tue, 28 Jun 2005 10:41:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15617 for ; Tue, 28 Jun 2005 10:41:34 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnHgj-000269-8x for sipping@ietf.org; Tue, 28 Jun 2005 11:07:49 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 28 Jun 2005 07:41:27 -0700 X-IronPort-AV: i="3.93,239,1115017200"; d="scan'208"; a="646072075:sNHT35071820" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5SEfNod024186; Tue, 28 Jun 2005 07:41:23 -0700 (PDT) Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j5SEexRa017574; Tue, 28 Jun 2005 07:41:00 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: David R Oran Subject: Re: [Sipping] Missed calls event package Date: Tue, 28 Jun 2005 10:41:19 -0400 To: Udit_Goyal@3com.com X-Mailer: Apple Mail (2.730) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1119969661.700283"; x:"432200"; a:"rsa-sha1"; b:"nofws:4464"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"XSfuOYa2CpxDp0qaJPDhBmUdVJ0quO1qVB/tb23nEDM8mHuaFV/vM2w5vLa2+uuLj6gMkUFj" "YqQ3Q9z5ArP2pROJa0KLJN79klfMvlbO+GqqNURERls9+ACvSTFd5LfP5AtM9uto5EJdVXqHw2I" "SprBr+PhSHkPpYcITxeS+xMY="; c:"From: David R Oran "; c:"Subject: Re: [Sipping] Missed calls event package"; c:"Date: Tue, 28 Jun 2005 10:41:19 -0400" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 3.1 (+++) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: quoted-printable Cc: Paul Kyzivat , Sipping@ietf.org, Dean Willis X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org On Jun 28, 2005, at 10:29 AM, Udit_Goyal@3com.com wrote: > > Hi, > > I totally agree with what David said. > We should have a generic mechanism for call logs which will suffice =20= > for this requirement too. > It is more like data retreival from the server. > I agree, which is why I think the first step is a schema and we can =20 then provide one or more access mechanisms. If we choose http: as one =20= of them, it might also be nice to have a uri convention for accessing =20= the log, e.g. http://user@example.com/call-log/?start=3D1-june-2005:08:00.= > We can have a similar mechanism for providing directory services =20 > using SIP. I havent seen any SIP thread for directory services. > LDAP? ENUM? Let's not turn SIP into some =FCber-protocol that has to do =20= everything. So while I agree about call logs, I disagree about =20 directories, especially whn one considers that buddy lists are going =20 to have complex interactions with directories that make this less-=20 than straightforward to map into SIP or Presence. > Regards, > Udit > > > > > David R Oran > Sent by: sipping-bounces@ietf.org > 06/28/2005 09:51 AM > > To > Paul Kyzivat > cc > Sipping@ietf.org, Dean Willis > Subject > Re: [Sipping] Missed calls event package > > > > > > > On Jun 28, 2005, at 8:40 AM, Paul Kyzivat wrote: > > > > > > > Avasarala Ranjit-A20990 wrote: > > > >> Hi > >> The call history is anyway maintained in the UA, like recent > >> calls. So > >> I am not sure how useful the event package will be. Also the event > >> package > >> will be stored on server. If we have this event package, that > >> package could have a mechanism where > >> the user will subscribe for call history and server will send the > >> call > >> history at periodic intervals. or everytime there is a change in > >> the call > >> history data. > >> > > > > A UA can only maintain the history that it is aware of. If there > > can be multiple UAs servicing the same AOR, or if a proxy > > intervenes on some calls to the AOR, then a UA does not have a > > complete history of calls - missed, received, or placed. > > > > Do you want your livingroom phone to think there was a missed call, > > when in fact it was answered in the bedroom? > > > This was in fact one of the motivating cases for the reason header on > CANCEL - the UA receiving the CANCEL could tell the difference > between an abandoned call and one that was picked up at a different =20= > UA. > > That of course does not allow a UA to learn about calls to the AOR > that were missed while the UA was offline, or calls whose caller > prefs caused the UA to be bypassed and not contacted, or calls that > got screened out, etc. > > I think a standardized way to obtain a call log for an AoR with the > appropriate dispositions for each call would be a very nice thing. > Not clear the right way to do it is an event package though. In any > event, an common "call log" XML schema seems to be a prerequisite to > making any particular fetch or notification machinery work in an > interoperable fashion. > > Could we start there? > > Dave. > > > Paul > > > > > >> Is this what we are speaking about? > >> Regards > >> Ranjit > >> -----Original Message----- > >> From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] > >> On Behalf > >> Of Jeroen van Bemmel > >> Sent: Tuesday, June 28, 2005 11:51 AM > >> To: Paul Kyzivat > >> Cc: Sipping@ietf.org; Dean Willis > >> Subject: Re: [Sipping] Missed calls event package > >> > >>>> You could of course simply scan for all 'From' headers you can > >>>> find, but > >>>> > >>> > >>> Scan *what*? > >>> > >>> > >> The body of the NOTIFY you get from MWI. But I think you agree > >> with me here that it is not that simple > >> > >>> This could be an area for new work, starting with trying to > >>> define the > >>> requirements. You would have to see if there is sufficient > >>> interest to pursue it at this time. > >>> > >>> > >> Right. So this is a call for interest: I am hereby asking people > >> to respond to the mailinglist with comments and/or indication of > >> interest in this topic > >> Thanks and regards, > >> Jeroen > >> _______________________________________________ > >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/=20 > sipping > >> This list is for NEW development of the application of SIP > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sip@ietf.org for new developments of core SIP > >> _______________________________________________ > >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/=20 > sipping > >> This list is for NEW development of the application of SIP > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sip@ietf.org for new developments of core SIP > >> > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Tue Jun 28 10:51:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnHQr-0006rG-Pf; Tue, 28 Jun 2005 10:51:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnHQq-0006rB-C2 for sipping@megatron.ietf.org; Tue, 28 Jun 2005 10:51:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16418 for ; Tue, 28 Jun 2005 10:51:21 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnHqC-0003NI-8E for Sipping@ietf.org; Tue, 28 Jun 2005 11:17:37 -0400 Received: from [10.59.1.4] (h-67-103-241-182.lsanca54.covad.net [67.103.241.182]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j5SEpD7a016483 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Tue, 28 Jun 2005 10:51:14 -0400 (EDT) In-Reply-To: <419E5B50-5C3F-4FFC-9842-6E6370A84686@cisco.com> References: <19B94C8C331A7546A88C88502083353B014B27D3@zin24exm02.ap.mot.com> <42C1452E.2040908@cisco.com> <419E5B50-5C3F-4FFC-9842-6E6370A84686@cisco.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Sipping] Missed calls event package Date: Tue, 28 Jun 2005 10:51:15 -0400 To: David R Oran X-Mailer: Apple Mail (2.730) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat , Sipping@ietf.org, Dean Willis X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org > I think a standardized way to obtain a call log for an AoR with the > appropriate dispositions for each call would be a very nice thing. > Not clear the right way to do it is an event package though. In any > event, an common "call log" XML schema seems to be a prerequisite > to making any particular fetch or notification machinery work in an > interoperable fashion. If we take the web as an example, there are semi-standardized web log formats that are then processed by a plethora of tools to yield statistics as well as to debug server behavior. Having such formats for SIP would be very useful as well. I don't see events as particularly applicable; in most cases, one would want to look at a filtered version of a larger number of records, e.g., to sort by caller, callee, or to compute statistics. (There are exceptions; for example, it would be useful to be able to easily show on an end system all calls missed since the last call was placed.) Unlike HTTP, there are however at least two types of such logs: request logs and call logs. One can derive the latter from the former. Also, call logs wouldn't necessarily capture MESSAGE and NOTIFY and other non-INVITE transactions. Given the timelines involved in SIPPING work and its non-protocol nature, maybe the SIP Forum would be an appropriate venue for such a call or request log agreement. Henning _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Tue Jun 28 11:12:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnHlb-0004Y4-RG; Tue, 28 Jun 2005 11:12:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnHlZ-0004Xs-Tb for sipping@megatron.ietf.org; Tue, 28 Jun 2005 11:12:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17936 for ; Tue, 28 Jun 2005 11:12:47 -0400 (EDT) Received: from mailhost.iperia.com ([204.57.52.4] helo=iperia.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnIAx-0005RR-4b for Sipping@ietf.org; Tue, 28 Jun 2005 11:39:03 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Subject: RE: [Sipping] Missed calls event package Date: Tue, 28 Jun 2005 11:12:34 -0400 Message-ID: <8019F8581B5FC14DBD94BAF86844868E6FA2DF@viridis.IPeria.local> Thread-Topic: [Sipping] Missed calls event package thread-index: AcV78AJLWBHnnGIxSN+h4eDFpEBXKQAAUFuA From: "Gordon Ledgard" To: "David R Oran" , X-Spam-Score: 3.1 (+++) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Content-Transfer-Encoding: quoted-printable Cc: Paul Kyzivat , Sipping@ietf.org, Dean Willis X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org I agree with David on a few points: First, a general call logging method should not be dependant on an Event package. While its not = inappropriate for agents and/or the network to share selected log information using events, its not really an appropriate for generic logging. Its far too cumbersome an approach for a function that is fundamentally simple. = Second, rather that focusing on specific mechanisms for storing and retrieving logs, which is highly dependant on implementation architectures and = third party subsystems outside the scope and control of SIP, the focus should = be simply on a schema to represent the data, XML being an excellent choice. = Perhaps a definition of an API to retrieve that data, short of calling = out a particular storage implementation, might also be appropriate. Finally, directory services are also much too application/implementation specific to warrant a standardization, I think. In order to satisfy everybody the recordkeeping for the directory entries would need to be enormous, and in the end, would satisfy no one. Regards, Gordon Ledgard IPeria, Inc. > -----Original Message----- > From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On = Behalf > Of David R Oran > Sent: Tuesday, June 28, 2005 10:41 AM > To: Udit_Goyal@3com.com > Cc: Paul Kyzivat; Sipping@ietf.org; Dean Willis > Subject: Re: [Sipping] Missed calls event package >=20 >=20 > On Jun 28, 2005, at 10:29 AM, Udit_Goyal@3com.com wrote: >=20 > > > > Hi, > > > > I totally agree with what David said. > > We should have a generic mechanism for call logs which will suffice > > for this requirement too. > > It is more like data retreival from the server. > > > I agree, which is why I think the first step is a schema and we can > then provide one or more access mechanisms. If we choose http: as one > of them, it might also be nice to have a uri convention for accessing > the log, e.g. = http://user@example.com/call-log/?start=3D1-june-2005:08:00. >=20 > > We can have a similar mechanism for providing directory services > > using SIP. I havent seen any SIP thread for directory services. > > > LDAP? ENUM? Let's not turn SIP into some =FCber-protocol that has to = do > everything. So while I agree about call logs, I disagree about > directories, especially whn one considers that buddy lists are going > to have complex interactions with directories that make this less- > than straightforward to map into SIP or Presence. >=20 >=20 > > Regards, > > Udit > > > > > > > > > > David R Oran > > Sent by: sipping-bounces@ietf.org > > 06/28/2005 09:51 AM > > > > To > > Paul Kyzivat > > cc > > Sipping@ietf.org, Dean Willis > > Subject > > Re: [Sipping] Missed calls event package > > > > > > > > > > > > > > On Jun 28, 2005, at 8:40 AM, Paul Kyzivat wrote: > > > > > > > > > > > Avasarala Ranjit-A20990 wrote: > > > > > >> Hi > > >> The call history is anyway maintained in the UA, like recent > > >> calls. So > > >> I am not sure how useful the event package will be. Also the = event > > >> package > > >> will be stored on server. If we have this event package, that > > >> package could have a mechanism where > > >> the user will subscribe for call history and server will send the > > >> call > > >> history at periodic intervals. or everytime there is a change in > > >> the call > > >> history data. > > >> > > > > > > A UA can only maintain the history that it is aware of. If there > > > can be multiple UAs servicing the same AOR, or if a proxy > > > intervenes on some calls to the AOR, then a UA does not have a > > > complete history of calls - missed, received, or placed. > > > > > > Do you want your livingroom phone to think there was a missed = call, > > > when in fact it was answered in the bedroom? > > > > > This was in fact one of the motivating cases for the reason header = on > > CANCEL - the UA receiving the CANCEL could tell the difference > > between an abandoned call and one that was picked up at a different > > UA. > > > > That of course does not allow a UA to learn about calls to the AOR > > that were missed while the UA was offline, or calls whose caller > > prefs caused the UA to be bypassed and not contacted, or calls that > > got screened out, etc. > > > > I think a standardized way to obtain a call log for an AoR with the > > appropriate dispositions for each call would be a very nice thing. > > Not clear the right way to do it is an event package though. In any > > event, an common "call log" XML schema seems to be a prerequisite to > > making any particular fetch or notification machinery work in an > > interoperable fashion. > > > > Could we start there? > > > > Dave. > > > > > Paul > > > > > > > > >> Is this what we are speaking about? > > >> Regards > > >> Ranjit > > >> -----Original Message----- > > >> From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] > > >> On Behalf > > >> Of Jeroen van Bemmel > > >> Sent: Tuesday, June 28, 2005 11:51 AM > > >> To: Paul Kyzivat > > >> Cc: Sipping@ietf.org; Dean Willis > > >> Subject: Re: [Sipping] Missed calls event package > > >> > > >>>> You could of course simply scan for all 'From' headers you can > > >>>> find, but > > >>>> > > >>> > > >>> Scan *what*? > > >>> > > >>> > > >> The body of the NOTIFY you get from MWI. But I think you agree > > >> with me here that it is not that simple > > >> > > >>> This could be an area for new work, starting with trying to > > >>> define the > > >>> requirements. You would have to see if there is sufficient > > >>> interest to pursue it at this time. > > >>> > > >>> > > >> Right. So this is a call for interest: I am hereby asking people > > >> to respond to the mailinglist with comments and/or indication of > > >> interest in this topic > > >> Thanks and regards, > > >> Jeroen > > >> _______________________________________________ > > >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/ > > sipping > > >> This list is for NEW development of the application of SIP > > >> Use sip-implementors@cs.columbia.edu for questions on current sip > > >> Use sip@ietf.org for new developments of core SIP > > >> _______________________________________________ > > >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/ > > sipping > > >> This list is for NEW development of the application of SIP > > >> Use sip-implementors@cs.columbia.edu for questions on current sip > > >> Use sip@ietf.org for new developments of core SIP > > >> > > > > > > _______________________________________________ > > > Sipping mailing list = https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sip@ietf.org for new developments of core SIP > > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Tue Jun 28 11:33:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnI5j-0001es-7B; Tue, 28 Jun 2005 11:33:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnI5h-0001e7-9y for sipping@megatron.ietf.org; Tue, 28 Jun 2005 11:33:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19883 for ; Tue, 28 Jun 2005 11:33:34 -0400 (EDT) From: Udit_Goyal@3com.com Received: from plmler2.mail.eds.com ([199.228.142.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnIV4-0007X5-3g for Sipping@ietf.org; Tue, 28 Jun 2005 11:59:50 -0400 Received: from plmlir5.mail.eds.com (plmlir5-2.mail.eds.com [199.228.142.135]) by plmler2.mail.eds.com (8.13.2/8.12.10) with ESMTP id j5SFX4VE014762; Tue, 28 Jun 2005 10:33:10 -0500 Received: from plmlir5.mail.eds.com (localhost [127.0.0.1]) by plmlir5.mail.eds.com (8.13.2/8.12.10) with ESMTP id j5SFWdgo015944; Tue, 28 Jun 2005 10:32:39 -0500 Received: from usut001.3com.com ([205.142.126.149]) by plmlir5.mail.eds.com (8.13.2/8.12.10) with ESMTP id j5SFWc6M015934; Tue, 28 Jun 2005 10:32:38 -0500 In-Reply-To: To: Henning Schulzrinne Subject: Re: [Sipping] Missed calls event package MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: Date: Tue, 28 Jun 2005 11:38:52 -0400 X-MIMETrack: Serialize by Router on USUT001/US/3Com(Release 6.0.3|September 26, 2003) at 06/28/2005 08:32:38 AM, Serialize complete at 06/28/2005 08:32:38 AM X-Spam-Score: 0.3 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: Sipping@ietf.org, Paul Kyzivat , David R Oran , Dean Willis X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1906732883==" Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org This is a multipart message in MIME format. --===============1906732883== Content-Type: multipart/alternative; boundary="=_alternative 00554CB18525702E_=" This is a multipart message in MIME format. --=_alternative 00554CB18525702E_= Content-Type: text/plain; charset="US-ASCII" Henning Schulzrinne Sent by: sipping-bounces@ietf.org 06/28/2005 10:51 AM To David R Oran cc Paul Kyzivat , Sipping@ietf.org, Dean Willis Subject Re: [Sipping] Missed calls event package > I think a standardized way to obtain a call log for an AoR with the > appropriate dispositions for each call would be a very nice thing. > Not clear the right way to do it is an event package though. In any > event, an common "call log" XML schema seems to be a prerequisite > to making any particular fetch or notification machinery work in an > interoperable fashion. >If we take the web as an example, there are semi-standardized web log >formats that are then processed by a plethora of tools to yield >statistics as well as to debug server behavior. Having such formats >or SIP would be very useful as well. I don't see events as >particularly applicable; in most cases, one would want to look at a >filtered version of a larger number of records, e.g., to sort by >caller, callee, or to compute statistics. (There are exceptions; for >example, it would be useful to be able to easily show on an end >system all calls missed since the last call was placed.) I agree with that. Mostly, users want to have look at filtered records. This will require concensus on whether we only want to give the information to the agent, or provide mechanism also to filter that data. Because agents can also filter that data itself. We should also consider the fact that if agents are using this approach, then they are not going to have call logs implemented on the UA itself, because then it may have synchronization issues. >Unlike HTTP, there are however at least two types of such logs: >request logs and call logs. One can derive the latter from the >former. Also, call logs wouldn't necessarily capture MESSAGE and >NOTIFY and other non-INVITE transactions. Does it really help UA to know SIP request logs. I feel call logs is of main interest to the user. However, request logs are helpful when you are interested in performance data and other statistics. >Given the timelines involved in SIPPING work and its non-protocol >nature, maybe the SIP Forum would be an appropriate venue for such a >call or request log agreement. Henning _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --=_alternative 00554CB18525702E_= Content-Type: text/html; charset="US-ASCII"


Henning Schulzrinne <hgs@cs.columbia.edu>
Sent by: sipping-bounces@ietf.org

06/28/2005 10:51 AM

To
David R Oran <oran@cisco.com>
cc
Paul Kyzivat <pkyzivat@cisco.com>, Sipping@ietf.org, Dean Willis <dean.willis@softarmor.com>
Subject
Re: [Sipping] Missed calls event package





> I think a standardized way to obtain a call log for an AoR with the
> appropriate dispositions for each call would be a very nice thing.
> Not clear the right way to do it is an event package though. In any
> event, an common "call log" XML schema seems to be a prerequisite
> to making any particular fetch or notification machinery work in an
> interoperable fashion.
>If we take the web as an example, there are semi-standardized web log
>formats that are then processed by a plethora of tools to yield
>statistics as well as to debug server behavior. Having such formats
>or SIP would be very useful as well. I don't see events as
>particularly applicable; in most cases, one would want to look at a
>filtered version of a larger number of records, e.g., to sort by
>caller, callee, or to compute statistics. (There are exceptions; for
>example, it would be useful to be able to easily show on an end
>system all calls missed since the last call was placed.)
I agree with that. Mostly, users want to have look at filtered records.
This will require concensus on whether we only want to give the information to the agent, or provide mechanism also to filter that data. Because agents can also filter that data itself.

We should also consider the fact that if agents are using this approach, then they are not going to have call logs implemented on the UA itself, because then it may have synchronization issues.


>Unlike HTTP, there are however at least two types of such logs:
>request logs and call logs. One can derive the latter from the
>former. Also, call logs wouldn't necessarily capture MESSAGE and
>NOTIFY and other non-INVITE transactions.
Does it really help UA to know SIP request logs. I feel call logs is of main interest to the user.
However, request logs are helpful when you are interested in performance data and other statistics.


>Given the timelines involved in SIPPING work and its non-protocol
>nature, maybe the SIP Forum would be an appropriate venue for such a
>call or request log agreement.

Henning


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP
--=_alternative 00554CB18525702E_=-- --===============1906732883== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============1906732883==-- From sipping-bounces@ietf.org Tue Jun 28 11:51:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnIN0-0006kt-2b; Tue, 28 Jun 2005 11:51:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnIMw-0006kd-Tr for sipping@megatron.ietf.org; Tue, 28 Jun 2005 11:51:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21425 for ; Tue, 28 Jun 2005 11:51:23 -0400 (EDT) Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnImG-0008MJ-9d for Sipping@ietf.org; Tue, 28 Jun 2005 12:17:39 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IIS00B01X97Q2@siemenscomms.co.uk> for Sipping@ietf.org; Tue, 28 Jun 2005 16:48:43 +0100 (BST) Received: from ntht206e.siemenscomms.co.uk ([137.223.247.52]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IIS00B02X97PW@siemenscomms.co.uk>; Tue, 28 Jun 2005 16:48:43 +0100 (BST) Received: by ntht206e.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 28 Jun 2005 16:51:00 +0100 Content-return: allowed Date: Tue, 28 Jun 2005 16:50:58 +0100 From: "Elwell, John" Subject: RE: [Sipping] Missed calls event package To: Jeroen van Bemmel , Paul Kyzivat Message-id: <50B1CBA96870A34799A506B2313F266705C2DEDB@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7BIT Cc: Sipping@ietf.org, Dean Willis X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: 28 June 2005 07:21 > To: Paul Kyzivat > Cc: Sipping@ietf.org; Dean Willis > Subject: Re: [Sipping] Missed calls event package > > >> You could of course simply scan for all 'From' headers you > can find, but > > > > Scan *what*? > > > > The body of the NOTIFY you get from MWI. But I think you > agree with me here > that it is not that simple > > > This could be an area for new work, starting with trying to > define the > > requirements. You would have to see if there is sufficient > interest to > > pursue it at this time. > > > > Right. So this is a call for interest: I am hereby asking > people to respond > to the mailinglist with comments and/or indication of > interest in this topic [JRE] Yes, I am interested, both in a schema and in a SIP event package to notify a UA that more records are available. Whether these records are supplied using the event package or whether they are retrieved separately is an open question. John > > Thanks and regards, > > Jeroen > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Tue Jun 28 13:58:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnKLn-00071b-VU; Tue, 28 Jun 2005 13:58:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnKLm-00071W-2d for sipping@megatron.ietf.org; Tue, 28 Jun 2005 13:58:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05740 for ; Tue, 28 Jun 2005 13:58:20 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnKl8-0003u8-RJ for sipping@ietf.org; Tue, 28 Jun 2005 14:24:37 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Jun 2005 10:58:09 -0700 Received: from RED-MSG-41.redmond.corp.microsoft.com ([157.54.12.201]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Jun 2005 10:58:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 28 Jun 2005 10:58:08 -0700 Message-ID: Thread-Topic: Sip URI and case sensitivity question Thread-Index: AcV8CpU1qkHq3eHERWW1jcma7zV2VQAAE6/Q From: "Adarsh Khare" To: X-OriginalArrivalTime: 28 Jun 2005 17:58:09.0103 (UTC) FILETIME=[F15FC5F0:01C57C0A] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Subject: [Sipping] Sip URI and case sensitivity question X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0039294116==" Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============0039294116== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C57C0A.F109077A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C57C0A.F109077A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, According to RFC 3261, section 19.1.4, userInfo part of Sip URI should be treated as case sensitive. Does anyone know the background behind it, what I am really wondering is why we have to treat the the user name part as case sensitive, where almost all application consider username as case insensitve. =20 Thanks adarsh =20 ------_=_NextPart_001_01C57C0A.F109077A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

According to RFC 3261, section 19.1.4, userInfo part = of Sip URI should be treated as case sensitive. Does anyone know the background = behind it, what I am really wondering is why we have to treat the the user name = part as case sensitive, where almost all application consider username as case insensitve.

 

Thanks

adarsh

 

------_=_NextPart_001_01C57C0A.F109077A-- --===============0039294116== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============0039294116==-- From sipping-bounces@ietf.org Tue Jun 28 17:49:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnNxE-0007Bb-Dt; Tue, 28 Jun 2005 17:49:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnNxA-0007BT-EB for sipping@megatron.ietf.org; Tue, 28 Jun 2005 17:49:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00302 for ; Tue, 28 Jun 2005 17:49:09 -0400 (EDT) Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnOMa-0003mT-J2 for Sipping@ietf.org; Tue, 28 Jun 2005 18:15:29 -0400 Received: (qmail 24207 invoked by uid 10); 28 Jun 2005 21:48:53 -0000 Received: (vexira-qq 24197-D22F89E5 invoked from network) 28 Jun 2005 23:48:52 +0200 Received: from unknown (HELO BEMBUSTER) ([81.59.101.130]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 28 Jun 2005 21:48:52 -0000 Message-ID: <009a01c57c2b$2a5a5c10$6502a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: , "Henning Schulzrinne" References: Subject: Re: [Sipping] Missed calls event package Date: Tue, 28 Jun 2005 23:48:44 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode01.zonnet.nl) X-Spam-Score: 1.8 (+) X-Scan-Signature: 1094b1c84fa6e846d476f39271f5074f Cc: David R Oran , Paul Kyzivat , Sipping@ietf.org, Dean Willis X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0609608590==" Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --===============0609608590== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0097_01C57C3B.EB4799A0" This is a multi-part message in MIME format. ------=_NextPart_000_0097_01C57C3B.EB4799A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ----- Original Message -----=20 From: Udit_Goyal@3com.com=20 To: Henning Schulzrinne=20 Cc: Sipping@ietf.org ; Paul Kyzivat ; David R Oran ; Dean Willis=20 Sent: Tuesday, June 28, 2005 5:38 PM Subject: Re: [Sipping] Missed calls event package Henning Schulzrinne =20 Sent by: sipping-bounces@ietf.org=20 06/28/2005 10:51 AM=20 To David R Oran =20 cc Paul Kyzivat , Sipping@ietf.org, = Dean Willis =20 Subject Re: [Sipping] Missed calls event package=20 =20 =20 > I think a standardized way to obtain a call log for an AoR with the > appropriate dispositions for each call would be a very nice thing. > Not clear the right way to do it is an event package though. In any > event, an common "call log" XML schema seems to be a prerequisite > to making any particular fetch or notification machinery work in an > interoperable fashion. >If we take the web as an example, there are semi-standardized web log >formats that are then processed by a plethora of tools to yield >statistics as well as to debug server behavior. Having such formats >or SIP would be very useful as well. I don't see events as >particularly applicable; in most cases, one would want to look at a >filtered version of a larger number of records, e.g., to sort by >caller, callee, or to compute statistics. (There are exceptions; for >example, it would be useful to be able to easily show on an end >system all calls missed since the last call was placed.) Or perhaps all calls missed since the last time you were REGISTERed = through some device. This is a scenario I've been thinking of, perhaps = the REGISTER reply could contain information for the UA about missed = calls (e.g. the URL to where the missed call log may be found, and/or an = indication of the number of calls missed) I agree with that. Mostly, users want to have look at filtered = records.=20 This will require concensus on whether we only want to give the = information to the agent, or provide mechanism also to filter that data. = Because agents can also filter that data itself.=20 We should also consider the fact that if agents are using this = approach, then they are not going to have call logs implemented on the = UA itself, because then it may have synchronization issues.=20 I would say both features will occur and have to interoperate somehow, = especially since there are already many devices out there that support a = local call log. Instead of banning that, we should consider the = requirements for making sure that the device can properly synchronize = its state. I.e. how to correlate logs ( call-id ? but then what about = forked sessions? ) and things like time synchronization or lack thereof >Unlike HTTP, there are however at least two types of such logs: >request logs and call logs. One can derive the latter from the >former. Also, call logs wouldn't necessarily capture MESSAGE and >NOTIFY and other non-INVITE transactions. Does it really help UA to know SIP request logs. I feel call logs is = of main interest to the user.=20 However, request logs are helpful when you are interested in = performance data and other statistics.=20 >Given the timelines involved in SIPPING work and its non-protocol >nature, maybe the SIP Forum would be an appropriate venue for such a >call or request log agreement. Henning _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip=20 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 ------=_NextPart_000_0097_01C57C3B.EB4799A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
----- Original Message -----
From:=20 Udit_Goyal@3com.com
Cc: Sipping@ietf.org ; Paul = Kyzivat ;=20 David R = Oran ; Dean=20 Willis
Sent: Tuesday, June 28, 2005 = 5:38=20 PM
Subject: Re: [Sipping] Missed = calls event=20 package




Henning = Schulzrinne=20 <hgs@cs.columbia.edu>=20
Sent by: sipping-bounces@ietf.org=20

06/28/2005 10:51 AM =

To
David R = Oran <oran@cisco.com>=20
cc
Paul = Kyzivat <pkyzivat@cisco.com>, Sipping@ietf.org, = Dean Willis=20 <dean.willis@softarmor.com&g= t;=20
Subject
Re: = [Sipping] Missed=20 calls event package





> I think a standardized way to = obtain a=20 call log for an AoR with the
> appropriate dispositions for each = call=20 would be a very nice thing.
> Not clear the right way to do it = is an=20 event package though. In any
> event, an common "call log" XML = schema=20 seems to be a prerequisite
> to making any particular fetch or=20 notification machinery work in an
> interoperable=20 fashion.

>If we take the web = as an=20 example, there are semi-standardized web log
>formats that are = then=20 processed by a plethora of tools to yield
>statistics as well as = to=20 debug server behavior. Having such formats
>or SIP would be very = useful=20 as well. I don't see events as
>particularly applicable; in most = cases,=20 one would want to look at a
>filtered version of a larger number = of=20 records, e.g., to sort by
>caller, callee, or to compute = statistics.=20 (There are exceptions; for
>example, it would be useful to be = able to=20 easily show on an end
>system all calls missed since the last = call was=20 placed.)
 
Or perhaps all calls missed = since the=20 last time you were REGISTERed through some device. This is a scenario = I've been=20 thinking of, perhaps the REGISTER reply could contain information for = the UA=20 about missed calls (e.g. the URL to where the missed call log may be = found,=20 and/or an indication of the number of calls = missed)

I agree with that. Mostly, users want to = have look=20 at filtered records.
This will = require=20 concensus on whether we only want to give the information to the = agent, or=20 provide mechanism also to filter that data. Because agents can also = filter=20 that data itself.

We should = also consider=20 the fact that if agents are using this approach, then they are not = going to=20 have call logs implemented on the UA itself, because then it may have=20 synchronization issues.
I would say both features will occur = and have to=20 interoperate somehow, especially since there are already many devices = out there=20 that support a local call log. Instead of banning that, we should = consider the=20 requirements for making sure that the device can properly synchronize = its state.=20 I.e. how to correlate logs ( call-id ? but then what = about forked=20 sessions? ) and things like time synchronization or lack=20 thereof
 


>Unlike HTTP,=20 there are however at least two types of such logs:
>request logs = and=20 call logs. One can derive the latter from the
>former. Also, = call logs=20 wouldn't necessarily capture MESSAGE and
>NOTIFY and other = non-INVITE=20 transactions.

Does it really = help UA to=20 know SIP request logs. I feel call logs is of main interest to the=20 user.
However, request logs are = helpful when=20 you are interested in performance data and other = statistics.=20


>Given the timelines involved in = SIPPING work=20 and its non-protocol
>nature, maybe the SIP Forum would be an=20 appropriate venue for such a
>call or request log=20 agreement.


Henning



_______________________________________________
Sipping = mailing=20 list  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=20
Use sip@ietf.org for new developments of core=20 SIP

_______________________________________________
Sipping = mailing=20 list  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 ------=_NextPart_000_0097_01C57C3B.EB4799A0-- --===============0609608590== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --===============0609608590==-- From sipping-bounces@ietf.org Tue Jun 28 18:17:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnOIe-0007fh-Cp; Tue, 28 Jun 2005 18:11:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnOIb-0007dB-Th for sipping@megatron.ietf.org; Tue, 28 Jun 2005 18:11:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02950 for ; Tue, 28 Jun 2005 18:11:19 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnOi1-0004Xs-Lh for sipping@ietf.org; Tue, 28 Jun 2005 18:37:39 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 28 Jun 2005 15:11:11 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5SMB5od029752; Tue, 28 Jun 2005 15:11:05 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Jun 2005 18:11:09 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Jun 2005 18:11:09 -0400 Message-ID: <42C1CAFC.70706@cisco.com> Date: Tue, 28 Jun 2005 18:11:08 -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: Ron Shacham References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jun 2005 22:11:09.0360 (UTC) FILETIME=[49832B00:01C57C2E] X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Content-Transfer-Encoding: 7bit Cc: sipping Subject: [Sipping] Re: I-D ACTION:draft-shacham-sip-media-privacy-00.txt X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Ron, This is pretty interesting. I see a few things that need a bit of work: Did you intend this for the sip wg (based on title)? I think this would normally start in sipping. So I'm addressing comments there. Your use of callerprefs isn't quite in line with the RFCs: ... The caller may include this parameter in the "Reject-Contact" header to disallow the call being routed to any device with a privacy level lower than or equal to that specified. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ For example, including the following header would keep the request from being routed to any device which would allow others to see or hear the output: Reject-Contact: *;privacy="organization" What you have written would only reject based on an exact match with "organization". Range-based matches can only be done on numeric features. You can look at how priority was done. Regarding use of offer/answer to "negotiate" privacy: We specify an extension to SDP to allow a session to be negotiated based on privacy requirements. Two attributes are defined, "provided-privacy" and "required-privacy", each a value attribute which may take any of the values specified in Section 2. An SDP description may include either or both of the attributes. ... Here, the sender notifies the other party that he is able to provide user-level privacy, and requires the same level from the other device in order to establish a session. This attribute is treated as any other in the offer/answer exchange, in that the recipient must be able to provide privacy at least at the specified level in order to establish the session. ... Since caller preferences are only defined for the initiator of a session, the callee must use, in its response, the SDP extensions described in order to require that the caller use a device that is sufficiently private. I think you at least need some additional specification. From the answerer's perspective this isn't much of a negotiation and seems to provide no promises of privacy. All the answerer can do is hope that the offerer will honor the request. To be more certain, the answerer could simply refrain from transmitting media initially, while sending a reinvite to negotiate the privacy it requires. But this might not provide a very good user experience. More likely is that the answerer be informed that the call is not private and simply refrain from sending *private* information until the desired level of privacy can be established. Paul Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Specifying Media Privacy Requirements in the > Session Initiation Protocol (SIP) > Author(s) : R. Shacham, et al. > Filename : draft-shacham-sip-media-privacy-00.txt > Pages : 9 > Date : 2005-6-28 > > Participants in a normal phone conversation can assume that, given > the appropriate measures are taken against network eavesdropping, > what they say is only heard by the other participant. The use of > speakerphones or visual output devices displaying video or messaging > removes this assumption. In the Session Initiation Protocol (SIP), a > call may also be transfered to another device, suddenly compromising > the other participant's privacy. Therefore, this document proposes > SDP and SIP protocol extensions that allow participants to specify > their privacy requirements for the other party's device, and > discusses how they may be used in different session scenarios. It > also defines an SDP extension for allowing or disallowing the > recording of the session. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-shacham-sip-media-privacy-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > 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-shacham-sip-media-privacy-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-shacham-sip-media-privacy-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. > ------------------------------------------------------------------------- > CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY > ------------------------------------------------------------------------- > In order to maintain computing infrastructure integrity, Cisco Systems > Enterprise Messaging Services and InfoSec teams have set a mail policy > disallowing executable attachments in email. > > This message contained an executable attachment type that is prohibited > by this policy. The attachment has been removed from this message and > copied to quarantine by our systems. It will be held in quarantine for > seven days in the event that the content needs to be retrieved. > > Please be aware many viruses attempt to look like legitimate email or > notifications from anti-virus systems. We will clearly mark a seperation > between our notifications and the original email as follows: > > "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY" > > For further reference information about viruses and email antivirus > efforts within Cisco, please visit: > > http://wwwin.cisco.com/it/ems/services/antiviral > > If your concern isn't addressed by the information in this notification > or the above web page, you may open a support request: > > http://wwwin.cisco.com/support/ > > Select "Messaging", "Email-Related", "Mail Routing" > > Please include in the text of your case the following information: > > * Full headers of the message. Documentation on displaying the full > headers is available at this URL: > > http://wwwin.cisco.com/support/library/faqs/solution002471.html > > * This unique quarantine identifier: j5SKXFCC001912 > > If the matter is urgent, you may follow up by calling one of the below > referenced numbers. Please make every effort to provide the above > requested information via the support web tool prior to calling as it > will greatly aid the resolution of your issue. > > Americas: > 1 408 526 8888 > > Asiapac > +61 2 8446 8888 > > EMEA > +31 20 485 4888 > > Japan > +81 3 5549 6888 > > US (Toll Free) > 1| 800| 888| 8187| (ext.68888) > > Thank you for your cooperation, > > Enterprise Messaging Services > Cisco Systems, Inc > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Tue Jun 28 21:59:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnRr7-0000lT-UE; Tue, 28 Jun 2005 21:59:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnRr5-0000lO-Lf for sipping@megatron.ietf.org; Tue, 28 Jun 2005 21:59:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22158 for ; Tue, 28 Jun 2005 21:59:09 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.201]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnSGX-0006qg-Mi for sipping@ietf.org; Tue, 28 Jun 2005 22:25:30 -0400 Received: by wproxy.gmail.com with SMTP id 36so16496wri for ; Tue, 28 Jun 2005 18:58:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=grpPMi1R+YDA3+UU1wcGtCBqRQrtafIwIihrM2Gk1PqwpsqLGfnNEHIZYNRdDmHB5exjixgqRWX9w69MUOAKsb0OJwrSqXXoAfRllvdkipsgG2tkS/IJ8+4FAjS6o8/EBU9A7qLrayAyJZY1u6l1Jphji536fqAVgqrss6E6H68= Received: by 10.54.17.22 with SMTP id 22mr2071wrq; Tue, 28 Jun 2005 18:58:59 -0700 (PDT) Received: by 10.54.17.77 with HTTP; Tue, 28 Jun 2005 18:58:59 -0700 (PDT) Message-ID: Date: Tue, 28 Jun 2005 21:58:59 -0400 From: Arjun Roychowdhury To: Paul Kyzivat Subject: Re: [Sipping] Re: I-D ACTION:draft-shacham-sip-media-privacy-00.txt In-Reply-To: <42C1CAFC.70706@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <42C1CAFC.70706@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Cc: sipping , Ron Shacham X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Arjun Roychowdhury List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Does it also make sense to specify some guidelines for B2Bs that will act as 'call servers' between two parties ? for example a-->b2b-->c a requires all the privacy extensions, b2b complies, but nothing guides the b2b to request the same from c - so in effect, "a" believes all his privacy is intact where as c is happily recording its conversation, or transferring itself out. The same applies to conference servers - if a is dialing into a bridge and requests privacy, for example, should the conference server allow this only if it is sure all its participants can honour this request of privacy ? regds arjun >=20 > Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > > > > > > Title : Specifying Media Privacy Requirements in the > > Session Initiation Protocol (SIP) > > Author(s) : R. Shacham, et al. > > Filename : draft-shacham-sip-media-privacy-00.txt > > Pages : 9 > > Date : 2005-6-28 > > > > Participants in a normal phone conversation can assume that, given > > the appropriate measures are taken against network eavesdropping, > > what they say is only heard by the other participant. The use of > > speakerphones or visual output devices displaying video or messaging > > removes this assumption. In the Session Initiation Protocol (SIP), = a > > call may also be transfered to another device, suddenly compromising > > the other participant's privacy. Therefore, this document proposes > > SDP and SIP protocol extensions that allow participants to specify > > their privacy requirements for the other party's device, and > > discusses how they may be used in different session scenarios. It > > also defines an SDP extension for allowing or disallowing the > > recording of the session. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-shacham-sip-media-privacy-00.= txt > > > > To remove yourself from the I-D Announcement list, send a message to > > i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > --=20 Arjun Roychowdhury _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Wed Jun 29 03:10:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnWi0-0004lc-6v; Wed, 29 Jun 2005 03:10:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnWhx-0004lQ-Gu for sipping@megatron.ietf.org; Wed, 29 Jun 2005 03:10:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17465 for ; Wed, 29 Jun 2005 03:10:04 -0400 (EDT) Received: from oak.research.panasonic.com ([150.169.1.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnX7S-00083K-6W for sipping@ietf.org; Wed, 29 Jun 2005 03:36:27 -0400 Received: from redwood.research.panasonic.com (www.research.panasonic.com [150.169.3.2]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j5T78Hmi026634; Wed, 29 Jun 2005 03:08:17 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id D28151E81F9; Wed, 29 Jun 2005 02:59:29 -0400 (EDT) Received: from [150.169.17.5] (unknown [150.169.17.5])by redwood.research.panasonic.com (Postfix) with ESMTP id A19061E81F1; Wed, 29 Jun 2005 02:59:28 -0400 (EDT) Message-ID: <42C248DF.5020704@research.panasonic.com> Date: Wed, 29 Jun 2005 03:08:15 -0400 From: Eunsoo Shim User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arjun Roychowdhury Subject: Re: [Sipping] Re: I-D ACTION:draft-shacham-sip-media-privacy-00.txt References: <42C1CAFC.70706@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:59.02657 C:19 M:0 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat , sipping , Ron Shacham X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Currently there is no speficiation about the behavior of B2BUAs as far as I know. Because of that, the B2BUA is an issue not only in this context. Regards, Eunsoo Arjun Roychowdhury wrote: >Does it also make sense to specify some guidelines for B2Bs that will >act as 'call servers' between two parties ? > >for example a-->b2b-->c > >a requires all the privacy extensions, b2b complies, but nothing >guides the b2b to request the same from c - so in effect, "a" believes >all his privacy is intact where as c is happily recording its >conversation, or transferring itself out. > >The same applies to conference servers - if a is dialing into a bridge >and requests privacy, for example, should the conference server allow >this only if it is sure all its participants can honour this request >of privacy ? > >regds >arjun > > > >>Internet-Drafts@ietf.org wrote: >> >> >>>A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> >>> >>> Title : Specifying Media Privacy Requirements in the >>> Session Initiation Protocol (SIP) >>> Author(s) : R. Shacham, et al. >>> Filename : draft-shacham-sip-media-privacy-00.txt >>> Pages : 9 >>> Date : 2005-6-28 >>> >>> Participants in a normal phone conversation can assume that, given >>> the appropriate measures are taken against network eavesdropping, >>> what they say is only heard by the other participant. The use of >>> speakerphones or visual output devices displaying video or messaging >>> removes this assumption. In the Session Initiation Protocol (SIP), a >>> call may also be transfered to another device, suddenly compromising >>> the other participant's privacy. Therefore, this document proposes >>> SDP and SIP protocol extensions that allow participants to specify >>> their privacy requirements for the other party's device, and >>> discusses how they may be used in different session scenarios. It >>> also defines an SDP extension for allowing or disallowing the >>> recording of the session. >>> >>>A URL for this Internet-Draft is: >>>http://www.ietf.org/internet-drafts/draft-shacham-sip-media-privacy-00.txt >>> >>>To remove yourself from the I-D Announcement list, send a message to >>>i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >>>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >>>to change your subscription settings. >>> >>> >>> >>> > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Wed Jun 29 10:22:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DndSS-0007kO-7f; Wed, 29 Jun 2005 10:22:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DndSQ-0007kD-Vz for sipping@megatron.ietf.org; Wed, 29 Jun 2005 10:22:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24854 for ; Wed, 29 Jun 2005 10:22:25 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.202]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dndrv-0008Ia-Er for sipping@ietf.org; Wed, 29 Jun 2005 10:48:52 -0400 Received: by wproxy.gmail.com with SMTP id 36so47280wri for ; Wed, 29 Jun 2005 07:22:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=D7NKbg31Q1w3JcgIAfId0vTeVTGhe9Uz42sg8v2t1clnJ9GolRnU7e9IA8VXzZhftvq2eNn0aX2aFe4yLukbeGzfTH7DNfSWImbxBHcKBwkcyX7acfWB8h4Kf7AhHxAlitP/0ovk1P0UCnM01kM6JUpWutXrTLf2vZHI+guOcWc= Received: by 10.54.17.40 with SMTP id 40mr14770wrq; Wed, 29 Jun 2005 07:22:15 -0700 (PDT) Received: by 10.54.17.77 with HTTP; Wed, 29 Jun 2005 07:22:15 -0700 (PDT) Message-ID: Date: Wed, 29 Jun 2005 10:22:15 -0400 From: Arjun Roychowdhury To: Eunsoo Shim Subject: Re: [Sipping] Re: I-D ACTION:draft-shacham-sip-media-privacy-00.txt In-Reply-To: <42C248DF.5020704@research.panasonic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <42C1CAFC.70706@cisco.com> <42C248DF.5020704@research.panasonic.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable Cc: Paul Kyzivat , sipping , Ron Shacham X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Arjun Roychowdhury List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Yes, I know there is none -but you just need to be concerned with the external appearance - a concatenation of of a UAC and UAS- and that is defined in section 6 of RFC3261. Since these privacy requirements are critical to the requestor (otherwise it is of no use to send it), it might be useful to specify such a guideline, at the least (especially since almost all of the 'call servers' in todays market are actually b2bs) regds arjun On 6/29/05, Eunsoo Shim wrote: > Currently there is no speficiation about the behavior of B2BUAs as far > as I know. > Because of that, the B2BUA is an issue not only in this context. > Regards, >=20 > Eunsoo >=20 >=20 > Arjun Roychowdhury wrote: >=20 > >Does it also make sense to specify some guidelines for B2Bs that will > >act as 'call servers' between two parties ? > > > >for example a-->b2b-->c > > > >a requires all the privacy extensions, b2b complies, but nothing > >guides the b2b to request the same from c - so in effect, "a" believes > >all his privacy is intact where as c is happily recording its > >conversation, or transferring itself out. > > > >The same applies to conference servers - if a is dialing into a bridge > >and requests privacy, for example, should the conference server allow > >this only if it is sure all its participants can honour this request > >of privacy ? > > > >regds > >arjun > > > > > > > >>Internet-Drafts@ietf.org wrote: > >> > >> > >>>A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. > >>> > >>> > >>> Title : Specifying Media Privacy Requirements in the > >>> Session Initiation Protocol (SIP) > >>> Author(s) : R. Shacham, et al. > >>> Filename : draft-shacham-sip-media-privacy-00.txt > >>> Pages : 9 > >>> Date : 2005-6-28 > >>> > >>> Participants in a normal phone conversation can assume that, given > >>> the appropriate measures are taken against network eavesdropping, > >>> what they say is only heard by the other participant. The use of > >>> speakerphones or visual output devices displaying video or messagin= g > >>> removes this assumption. In the Session Initiation Protocol (SIP),= a > >>> call may also be transfered to another device, suddenly compromisin= g > >>> the other participant's privacy. Therefore, this document proposes > >>> SDP and SIP protocol extensions that allow participants to specify > >>> their privacy requirements for the other party's device, and > >>> discusses how they may be used in different session scenarios. It > >>> also defines an SDP extension for allowing or disallowing the > >>> recording of the session. > >>> > >>>A URL for this Internet-Draft is: > >>>http://www.ietf.org/internet-drafts/draft-shacham-sip-media-privacy-00= .txt > >>> > >>>To remove yourself from the I-D Announcement list, send a message to > >>>i-d-announce-request@ietf.org with the word unsubscribe in the body of= the message. > >>>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > >>>to change your subscription settings. > >>> > >>> > >>> > >>> > > > > > > >=20 >=20 --=20 Arjun Roychowdhury _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Wed Jun 29 11:13:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DneFP-0002gt-Ab; Wed, 29 Jun 2005 11:13:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DneFN-0002go-RB for sipping@megatron.ietf.org; Wed, 29 Jun 2005 11:13:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00656 for ; Wed, 29 Jun 2005 11:13:03 -0400 (EDT) Received: from oak.research.panasonic.com ([150.169.1.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dneex-0001pt-I5 for sipping@ietf.org; Wed, 29 Jun 2005 11:39:32 -0400 Received: from redwood.research.panasonic.com (ftp.research.panasonic.com [150.169.3.2] (may be forged)) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j5TFCO3P010147; Wed, 29 Jun 2005 11:12:24 -0400 Received: from redwood.research.panasonic.com (birch.research.pansonic.com [150.169.3.2]) by testing.research.panasonic.com (Postfix) with ESMTP id 33E181E8198; Wed, 29 Jun 2005 11:03:36 -0400 (EDT) Received: from Brijesh2K (dhcp251.Research.Panasonic.COM [150.169.1.251])by redwood.research.panasonic.com (Postfix) with SMTP id 278171E817C; Wed, 29 Jun 2005 11:03:36 -0400 (EDT) Message-ID: <004701c57cbd$d34f4d20$01000001@Brijesh2K> From: "Brijesh Kumar" To: "Ron Shacham" References: <42C1CAFC.70706@cisco.com> Subject: Re: [Sipping] Re: I-D ACTION:draft-shacham-sip-media-privacy-00.txt Date: Wed, 29 Jun 2005 11:18:37 -0400 Organization: Panasonic MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:18 M:0 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: sipping X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Hi Ron: It is an interesting draft, and I think specifying SDP parameters to specify privacy requirements is technically fine. However, I am curious as to how does specifying media privacy during SIP session setup really get enforced. Even FCC has not been able to control the use of broadcast media since once you have analog audio or video stream - you can do whatever you like with it including recording, forwarding or playing back to your neighbors. The only way FCC is able to do that is by forcing settop box and A/V manufacturers to totally eliminate analog outputs from the next gen A/V devices, and getting all other ports encrypted by the key supplied by the cable manufacturers. So, it is not the mechanism of conveying privacy parameters to other end, but whether it can be effectively enforced automatically is what I am pointing to. You can as well say over the phone that please don't record, or play my conversation on speakers. If some one wants to do opposite of that, he/she can do it any way. cheers, -brijesh > Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > > > Title : Specifying Media Privacy Requirements in the > > Session Initiation Protocol (SIP) > > Author(s) : R. Shacham, et al. > > Filename : draft-shacham-sip-media-privacy-00.txt > > Pages : 9 > > Date : 2005-6-28 > > > > Participants in a normal phone conversation can assume that, given > > the appropriate measures are taken against network eavesdropping, > > what they say is only heard by the other participant. The use of > > speakerphones or visual output devices displaying video or messaging > > removes this assumption. In the Session Initiation Protocol (SIP), a > > call may also be transfered to another device, suddenly compromising > > the other participant's privacy. Therefore, this document proposes > > SDP and SIP protocol extensions that allow participants to specify > > their privacy requirements for the other party's device, and > > discusses how they may be used in different session scenarios. It > > also defines an SDP extension for allowing or disallowing the > > recording of the session. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-shacham-sip-media-privacy-00.txt > > > > To remove yourself from the I-D Announcement list, send a message to > > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > -- Arjun Roychowdhury _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Wed Jun 29 20:31:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnmxK-0000sv-9f; Wed, 29 Jun 2005 20:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnmxH-0000sn-MB; Wed, 29 Jun 2005 20:30:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14845; Wed, 29 Jun 2005 20:30:58 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnnMw-0000pE-FZ; Wed, 29 Jun 2005 20:57:30 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j5U0Uat23347; Wed, 29 Jun 2005 17:30:36 -0700 (PDT) Message-Id: <200506300030.j5U0Uat23347@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 29 Jun 2005 17:30:36 -0700 X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: sipping@ietf.org, rfc-editor@rfc-editor.org Subject: [Sipping] RFC 4117 on Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc) X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4117 Title: Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc) Author(s): G. Camarillo, E. Burger, H. Schulzrinne, A. van Wijk Status: Informational Date: June 2005 Mailbox: Gonzalo.Camarillo@ericsson.com, eburger@brooktrout.com, schulzrinne@cs.columbia.edu, a.vwijk@viataal.nl Pages: 19 Characters: 37951 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sipping-transc-3pcc-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4117.txt This document describes how to invoke transcoding services using Session Initiation Protocol (SIP) and third party call control. This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing and speech-impaired individuals. This document is a product of the Session Initiation Proposal Investigation Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <050629172900.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4117 --OtherAccess Content-Type: Message/External-body; name="rfc4117.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050629172900.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the 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-- From sipping-bounces@ietf.org Thu Jun 30 10:16:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnzkC-0007Vd-G6; Thu, 30 Jun 2005 10:10:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnzkA-0007VX-T4 for sipping@megatron.ietf.org; Thu, 30 Jun 2005 10:10:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15227 for ; Thu, 30 Jun 2005 10:10:16 -0400 (EDT) Received: from bay15-f22.bay15.hotmail.com ([65.54.185.22] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do09q-0006m9-Ez for sipping@ietf.org; Thu, 30 Jun 2005 10:36:56 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 30 Jun 2005 07:09:59 -0700 Message-ID: Received: from 130.159.254.2 by by15fd.bay15.hotmail.msn.com with HTTP; Thu, 30 Jun 2005 14:09:59 GMT X-Originating-IP: [130.159.254.2] X-Originating-Email: [ali_cam@hotmail.co.uk] X-Sender: ali_cam@hotmail.co.uk From: "Ali Cameron" To: sipping@ietf.org Date: Thu, 30 Jun 2005 15:09:59 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 30 Jun 2005 14:09:59.0952 (UTC) FILETIME=[66D49900:01C57D7D] X-Spam-Score: 0.8 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Sipping] Multiple Third Party Registrations? X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org I'm looking at the issue of third party registrations with SIP. My understanding is that it is supported in the standard, but is it widely implemented? Related to this, and in some ways the next step, is the issue of multiple third party registrations - could anyone please advise if they know of implementations that support this? Thanks, Ali _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger 7.0 today! http://messenger.msn.co.uk _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Thu Jun 30 10:18:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnzsI-00021X-Aj; Thu, 30 Jun 2005 10:18:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnzsG-000212-R7 for sipping@megatron.ietf.org; Thu, 30 Jun 2005 10:18:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16992 for ; Thu, 30 Jun 2005 10:18:38 -0400 (EDT) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do0I1-0002MN-Dw for sipping@ietf.org; Thu, 30 Jun 2005 10:45:19 -0400 Received: from keywest (hide.pingtel.com [65.220.123.2]) by mail.pingtel.com (Postfix) with SMTP id 7AC7B6C019 for ; Thu, 30 Jun 2005 10:18:32 -0400 (EDT) From: "Dale Worley" To: Subject: RE: [Sipping] Multiple Third Party Registrations? Date: Thu, 30 Jun 2005 10:17:24 -0400 Message-ID: <004901c57d7e$7077fc30$6a01010a@keywest> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org > From: Ali Cameron > > I'm looking at the issue of third party registrations with SIP. My > understanding is that it is supported in the standard, but is > it widely > implemented? Related to this, and in some ways the next step, > is the issue > of multiple third party registrations - could anyone please > advise if they > know of implementations that support this? The only way to distinguish third-party registrations is by examining the From: field, which is otherwise of no interest. I expect that most SIP registrars accept any third-party registration as long as it can be authenticated. Dale _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Thu Jun 30 12:16:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do1eu-0001hL-N8; Thu, 30 Jun 2005 12:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do1es-0001dB-Aa for sipping@megatron.ietf.org; Thu, 30 Jun 2005 12:12:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28762 for ; Thu, 30 Jun 2005 12:12:55 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.200]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do24d-0006WV-IL for sipping@ietf.org; Thu, 30 Jun 2005 12:39:37 -0400 Received: by wproxy.gmail.com with SMTP id 36so48391wri for ; Thu, 30 Jun 2005 09:12:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dJRBQ97iKH2+0RnkqyuV1Jqm5VpbnfUAu3kPqTDex4iVG55nAFgD+cYRVAPkA5TscjcVqIOzm1vAeA/sgt9INMgM/kSKAUUel/aWN8HCw7BMUZ894ihscF2LOj0GtOB1QwqkM623mPOYFBARQeqMpJUEcKwAzKzROvEW8qD05uE= Received: by 10.54.59.37 with SMTP id h37mr39277wra; Thu, 30 Jun 2005 09:12:47 -0700 (PDT) Received: by 10.54.17.77 with HTTP; Thu, 30 Jun 2005 09:12:47 -0700 (PDT) Message-ID: Date: Thu, 30 Jun 2005 12:12:47 -0400 From: Arjun Roychowdhury To: Ali Cameron Subject: Re: [Sipping] Multiple Third Party Registrations? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Arjun Roychowdhury List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Not sure what network you have in mind -=20 I have not seen it used very often in the SIP implementations today but it is being used in various IMS network/trials where the S-CSCF acts as a 3rd party registrar on behalf of the UE (user equipment) - you may want to refer to TS 24.229 for the procedures are guidelines. regds arjun On 6/30/05, Ali Cameron wrote: >=20 > I'm looking at the issue of third party registrations with SIP. My > understanding is that it is supported in the standard, but is it widely > implemented? Related to this, and in some ways the next step, is the issu= e > of multiple third party registrations - could anyone please advise if the= y > know of implementations that support this? >=20 > Thanks, > Ali >=20 > _________________________________________________________________ > It's fast, it's easy and it's free. Get MSN Messenger 7.0 today! > http://messenger.msn.co.uk >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP >=20 --=20 Arjun Roychowdhury _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Thu Jun 30 19:07:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do88J-0000Ss-98; Thu, 30 Jun 2005 19:07:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do88H-0000SH-9A for sipping@megatron.ietf.org; Thu, 30 Jun 2005 19:07:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07300 for ; Thu, 30 Jun 2005 19:07:41 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do8Y7-0000iS-23 for sipping@ietf.org; Thu, 30 Jun 2005 19:34:27 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 30 Jun 2005 16:07:34 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5UN7Vod003684; Thu, 30 Jun 2005 16:07:32 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 30 Jun 2005 19:07:33 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 30 Jun 2005 19:07:33 -0400 Message-ID: <42C47B33.30100@cisco.com> Date: Thu, 30 Jun 2005 19:07:31 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arjun Roychowdhury Subject: Re: [Sipping] Multiple Third Party Registrations? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jun 2005 23:07:33.0440 (UTC) FILETIME=[7F684C00:01C57DC8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: Ali Cameron , sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Arjun Roychowdhury wrote: > Not sure what network you have in mind - > I have not seen it used very often in the SIP implementations today > but it is being used in various IMS network/trials where the S-CSCF > acts as a 3rd party registrar > on behalf of the UE (user equipment) - you may want to refer to TS > 24.229 for the procedures are guidelines. What IMS calls 3rd party registration bears only passing resemblance to what is usually called 3rd party registration in ietf. The REGISTER message the S-CSCF generates has a Contact identifying itself, not the UE. So if it is anything, it is more like a 1st party registration. But the target is not in any real sense a registrar, so who knows what this is in reality. In any case, I don't think that has any bearing on 3rd party registrations in SIP. Its unfortunate that the same name was used for both. Paul > regds > arjun > > On 6/30/05, Ali Cameron wrote: > >>I'm looking at the issue of third party registrations with SIP. My >>understanding is that it is supported in the standard, but is it widely >>implemented? Related to this, and in some ways the next step, is the issue >>of multiple third party registrations - could anyone please advise if they >>know of implementations that support this? >> >>Thanks, >>Ali >> >>_________________________________________________________________ >>It's fast, it's easy and it's free. Get MSN Messenger 7.0 today! >>http://messenger.msn.co.uk >> >> >>_______________________________________________ >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>This list is for NEW development of the application of SIP >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sip@ietf.org for new developments of core SIP >> > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From sipping-bounces@ietf.org Thu Jun 30 23:48:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoCVj-00028P-5z; Thu, 30 Jun 2005 23:48:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoCVh-00028K-AK for sipping@megatron.ietf.org; Thu, 30 Jun 2005 23:48:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06996 for ; Thu, 30 Jun 2005 23:48:10 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoCvX-0001A0-KB for sipping@ietf.org; Fri, 01 Jul 2005 00:14:58 -0400 Received: by wproxy.gmail.com with SMTP id 36so116268wri for ; Thu, 30 Jun 2005 20:48:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ksa9AuKXW7T+pTqN5rvp2FiYFwBfhPFmOyg9MFLJaInJHl1g21PBwUJkmdStKAQyAJutMzsYsXFKlYGPR9cQm/8t8qwS82VoyJ+8fOGN8UPC7sQcgWOC35S5ih81clP9ywMTfx1sqpFlfKjMw+rXDAQ9gHvH2O1afNEDC2ybegw= Received: by 10.54.59.9 with SMTP id h9mr368197wra; Thu, 30 Jun 2005 20:48:01 -0700 (PDT) Received: by 10.54.17.77 with HTTP; Thu, 30 Jun 2005 20:48:01 -0700 (PDT) Message-ID: Date: Thu, 30 Jun 2005 23:48:01 -0400 From: Arjun Roychowdhury To: Paul Kyzivat Subject: Re: [Sipping] Multiple Third Party Registrations? In-Reply-To: <42C47B33.30100@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <42C47B33.30100@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Cc: Ali Cameron , sipping@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Arjun Roychowdhury List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org Well, even though it provides a contact of the S-CSCF, the To header is that of the public user identity of the UE and not itself. Per 3261 "The To header field contains the address of record whose=20 registration is to be created, queried, or modified. " where as the role of the Contact header is to create an address binding. My interpretation of this text is that the To header idenfies whether its a 3rd party registration or not and not whatever you put into contact. therefore, this is more in line with the 'theoretical' definition of 3261's third party registration, which is only classified by the contents of the to header. On 6/30/05, Paul Kyzivat wrote: >=20 >=20 > Arjun Roychowdhury wrote: > > Not sure what network you have in mind - > > I have not seen it used very often in the SIP implementations today > > but it is being used in various IMS network/trials where the S-CSCF > > acts as a 3rd party registrar > > on behalf of the UE (user equipment) - you may want to refer to TS > > 24.229 for the procedures are guidelines. >=20 > What IMS calls 3rd party registration bears only passing resemblance to > what is usually called 3rd party registration in ietf. >=20 > The REGISTER message the S-CSCF generates has a Contact identifying > itself, not the UE. So if it is anything, it is more like a 1st party > registration. But the target is not in any real sense a registrar, so > who knows what this is in reality. >=20 > In any case, I don't think that has any bearing on 3rd party > registrations in SIP. Its unfortunate that the same name was used for bot= h. >=20 > Paul >=20 > > regds > > arjun > > > > On 6/30/05, Ali Cameron wrote: > > > >>I'm looking at the issue of third party registrations with SIP. My > >>understanding is that it is supported in the standard, but is it widely > >>implemented? Related to this, and in some ways the next step, is the is= sue > >>of multiple third party registrations - could anyone please advise if t= hey > >>know of implementations that support this? > >> > >>Thanks, > >>Ali > >> > >>_________________________________________________________________ > >>It's fast, it's easy and it's free. Get MSN Messenger 7.0 today! > >>http://messenger.msn.co.uk > >> > >> > >>_______________________________________________ > >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > >>This list is for NEW development of the 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 Arjun Roychowdhury _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP