From mailnull@www1.ietf.org Sat Feb 1 18:09:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17308 for ; Sat, 1 Feb 2003 18:09:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h11NDEY11604 for sip-archive@odin.ietf.org; Sat, 1 Feb 2003 18:13:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h11NCfJ11589; Sat, 1 Feb 2003 18:12:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h11N5sJ10805 for ; Sat, 1 Feb 2003 18:05:54 -0500 Received: from smtp017.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17197 for ; Sat, 1 Feb 2003 18:01:11 -0500 (EST) Received: from 12-235-146-159.client.attbi.com (HELO cranberry) (seancolson@12.235.146.159 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 1 Feb 2003 23:04:46 -0000 Reply-To: From: "Sean Olson" To: "'Jean-Francois Mule'" , Cc: "'Kevin'" , "'Kavitha'" Subject: RE: [Sip] RequestUri to Host Matching and proxy servers Date: Sat, 1 Feb 2003 15:04:46 -0800 Message-ID: <006501c2ca46$50b44c70$6501a8c0@cranberry> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit There are several applications that fit this description. An outbound proxy is just one of them. I think the text you propose for this setting is fine. I would also be fine with making this a UA only setting. my two cents, sean -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Jean-Francois Mule Sent: Thursday, January 30, 2003 8:08 PM To: sip@ietf.org Cc: Kevin; Jean-Francois Mule; Kavitha Subject: [Sip] RequestUri to Host Matching and proxy servers Updating the sip mib ID with Kevin & Kavitha, we have a quick question re: Request-URI and host matching for proxy servers. Is there any application where not requiring request-uri host matching makes sense for a proxy? We thought about the outbound proxy case where requests are usually targetted for external proxies, therefore request-uri to host matching may potentially not be the default action. We have a sipRequestUriHostMatching mib object (true/false value) that is currently applicable to UAs and proxies and we're wondering whether to keep it as a common configuration object or move it to the UA config section of the mib. Additionally, if request-URI to host matching is enforced, is it ok for the object description to state something like: "If the value of this object is 'true', then the server requires a match, and if the RequestURI doesn't match the server's host name, a Location Service may be used to obtain information about a callee's possible location(s) or a 404 Not Found status code is returned by the server." Thanks, Jean-Francois. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Sun Feb 2 20:07:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14407 for ; Sun, 2 Feb 2003 20:07:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h131BmF02034 for sip-archive@odin.ietf.org; Sun, 2 Feb 2003 20:11:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h131A9J02003; Sun, 2 Feb 2003 20:10:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1314nJ01208 for ; Sun, 2 Feb 2003 20:04:49 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14344 for ; Sun, 2 Feb 2003 19:59:34 -0500 (EST) Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h13133B6015117; Sun, 2 Feb 2003 17:03:03 -0800 (PST) Received: from CSCOAMERA10607 (dhcp-171-71-35-161.cisco.com [171.71.35.161]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ADY07842; Sun, 2 Feb 2003 16:50:28 -0800 (PST) From: "samisriv" To: "'margaretmary'" , Subject: RE: [Sip] query on redirect server Date: Sun, 2 Feb 2003 17:03:08 -0800 Message-ID: <024401c2cb20$041d0d40$a12347ab@amer.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0245_01C2CADC.F5F9CD40" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <000a01c2c92e$4c548000$dd9a83ca@DOMAIN.dexceldesigns.com> Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0245_01C2CADC.F5F9CD40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ACK doesn't have a response associated with it. For other methods INVITE, BYE, REGISTER, OPTIONS, it can send 3xx based on the alternative locations or refuse it. Thx Samir -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of margaretmary Sent: Friday, January 31, 2003 5:40 AM To: sip@ietf.org Subject: [Sip] query on redirect server Hello sir, With respect to draft-ietf-sip-rfc2543bis-09.ps for Redirect server " A redirect server does not issue any SIP requests or its own. Ater receiving a request other than CANCEL, the server either refuses the request or gathers the list of alternative locations from the location service and returns a final response of class 3xx". This statement tells for all methods of (INVITE, ACK, BYE, REGISTER, OPTIONS) other then CANCEL or only for INVITE. Its quite confusing. Please try to provide a solution for this. Regards, Margaret, -------------------------------------------------------------- Dexcel Electronics Designs (P) Ltd., Bangalore, India ------=_NextPart_000_0245_01C2CADC.F5F9CD40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
ACK=20 doesn't have a response associated with it. For other methods INVITE, = BYE,=20 REGISTER, OPTIONS, it
can send 3xx based on the alternative locations or refuse = it.=20
 
Thx
Samir
 

-----Original=20 Message-----
From: sip-admin@ietf.org = [mailto:sip-admin@ietf.org]=20 On Behalf Of margaretmary
Sent: Friday, January 31, = 2003 5:40=20 AM
To: sip@ietf.org
Subject: [Sip] query on redirect = server

Hello  sir,
 
With respect to = draft-ietf-sip-rfc2543bis-09.ps=20 for Redirect server " A redirect server does not issue any SIP = requests or its=20 own. Ater receiving a request other than CANCEL, the server = either=20 refuses the request or gathers the list of alternative locations from = the=20 location service and returns a final response of class=20 3xx".
This statement  tells for all = methods of=20 (INVITE, ACK, BYE, REGISTER, OPTIONS) other then CANCEL or only for=20 INVITE.
 
Its quite confusing.
Please try to provide a solution for=20 this.
 
 
Regards,
Margaret,

----------------------= ----------------------------------------
Dexcel=20 Electronics Designs (P) Ltd., Bangalore, = India
------=_NextPart_000_0245_01C2CADC.F5F9CD40-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Feb 3 00:47:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19171 for ; Mon, 3 Feb 2003 00:47:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h135qEX15181 for sip-archive@odin.ietf.org; Mon, 3 Feb 2003 00:52:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h135piJ15159; Mon, 3 Feb 2003 00:51:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h135nWJ15097 for ; Mon, 3 Feb 2003 00:49:32 -0500 Received: from proxy-blr.primus-india.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19168 for ; Mon, 3 Feb 2003 00:44:10 -0500 (EST) Received: from dexceldesigns.com (ptil-67-160-ind.primus-india.net [203.196.160.67] (may be forged)) by proxy-blr.primus-india.com (8.11.2/8.11.2) with ESMTP id h13BGTo21846 for ; Mon, 3 Feb 2003 16:46:29 +0530 Message-ID: <000a01c2cb46$bf16b1c0$dd9a83ca@DOMAIN.dexceldesigns.com> From: margaretmary To: Date: Mon, 3 Feb 2003 11:10:23 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C2CB74.D8BC9E40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailserver: Sent using PostMaster (v4.1.13) Subject: [Sip] query on OPTIONS call flow Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C2CB74.D8BC9E40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hello sir, Where can i find the call flow for OPTIONS method. please try to send the link or in which draft can i find that? Regards, Margaret ------=_NextPart_000_0007_01C2CB74.D8BC9E40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hello sir,
 
Where can i find the call flow for = OPTIONS=20 method.
please try to send the link or in which = draft can i=20 find that?
 
 
Regards,
Margaret

--------------------------------------------------------------
Dexcel Electronics Designs (P) Ltd., Bangalore, India
------=_NextPart_000_0007_01C2CB74.D8BC9E40-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Feb 3 07:53:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06654 for ; Mon, 3 Feb 2003 07:53:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13CwB719132 for sip-archive@odin.ietf.org; Mon, 3 Feb 2003 07:58:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13CvhJ19065; Mon, 3 Feb 2003 07:57:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SCKCJ14443 for ; Tue, 28 Jan 2003 07:20:12 -0500 Received: from mailhub.fokus.gmd.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22318 for ; Tue, 28 Jan 2003 06:58:45 -0500 (EST) From: sisalem@fokus.fraunhofer.de Received: from saturn.fokus.gmd.de (saturn [195.37.77.163]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id h0SC2Ei17154; Tue, 28 Jan 2003 13:02:14 +0100 (MET) Received: (from nobody@localhost) by saturn.fokus.gmd.de (8.8.8+Sun/8.8.8) id NAA27078; Tue, 28 Jan 2003 13:02:13 +0100 (MET) X-Authentication-Warning: saturn.fokus.gmd.de: nobody set sender to dor@fokus.fhg.de using -f To: Carl.A.Wickbom@telia.se Subject: Re: [Sip] SIP-units in a IPv4/IPv6 dual-stack world Message-ID: <1043755333.3e3671458fedf@www.fokus.gmd.de> Date: Tue, 28 Jan 2003 13:02:13 +0100 (MET) Cc: sip@ietf.org References: <57EFD03667AB294D8161FDB1A46B4093F5E31C@TMS041MB.tcad.telia.se> In-Reply-To: <57EFD03667AB294D8161FDB1A46B4093F5E31C@TMS041MB.tcad.telia.se> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.7 Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, while there are surely different ways for solving this problem, we have choses a solution based on the NATPT concept and implemented a small gateway for the translation of SIP messages between IPv6 only and IPv4 only networks. In case you are interested, please contact me for more information cheers Zitiere Carl.A.Wickbom@telia.se: > Hi, > > The behavior or a SIP client and server in IPv4 is quite clear and > analogous in IPv6. > However, the behavior of SIP clients and servers in an environment with > both IPv4 and IPv6 is to me unclear (dual-stack). Do anyone know if > there has been any work done about this, and in that case what the > result of that work was? > > Best regards, > Carl > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Feb 3 07:53:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06667 for ; Mon, 3 Feb 2003 07:53:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13CwGl19145 for sip-archive@odin.ietf.org; Mon, 3 Feb 2003 07:58:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13CvuJ19087; Mon, 3 Feb 2003 07:57:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13AbXJ09953 for ; Mon, 3 Feb 2003 05:37:33 -0500 Received: from proxy-blr.primus-india.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02211 for ; Mon, 3 Feb 2003 05:32:05 -0500 (EST) Received: from dexceldesigns.com (ptil-67-160-ind.primus-india.net [203.196.160.67] (may be forged)) by proxy-blr.primus-india.com (8.11.2/8.11.2) with ESMTP id h13G4Eo23962 for ; Mon, 3 Feb 2003 21:34:17 +0530 Message-ID: <008001c2cb6d$80f2e130$1b010a64@DOMAIN.dexceldesigns.com> From: Jayasree Palapati To: Date: Mon, 3 Feb 2003 15:47:49 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007D_01C2CB9B.9A865720" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailserver: Sent using PostMaster (v4.1.13) Subject: [Sip] Regd OPTIONS Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_007D_01C2CB9B.9A865720 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sir, How do proxies handle OPTIONS request when it is forked?and on what = conditions it'll be forked? Kindly, clarify. Regards, Jayasree ------=_NextPart_000_007D_01C2CB9B.9A865720 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Sir,
 
    How do proxies = handle OPTIONS=20 request when it is forked?and on what conditions it'll be forked? = Kindly,=20 clarify.
 
 
Regards,
Jayasree
 
 
 

--------------------------------------------------------------
Dexcel Electronics Designs (P) Ltd., Bangalore, India
------=_NextPart_000_007D_01C2CB9B.9A865720-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Feb 4 02:54:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13256 for ; Tue, 4 Feb 2003 02:54:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1480GD05963 for sip-archive@odin.ietf.org; Tue, 4 Feb 2003 03:00:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h147xkJ05907; Tue, 4 Feb 2003 02:59:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h147vcJ05855 for ; Tue, 4 Feb 2003 02:57:38 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13234 for ; Tue, 4 Feb 2003 02:51:46 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 3 Feb 2003 23:45:07 -0800 Received: from 212.143.185.30 by lw15fd.law15.hotmail.msn.com with HTTP; Tue, 04 Feb 2003 07:45:07 GMT X-Originating-IP: [212.143.185.30] From: "James Ford" To: sip@ietf.org Date: Tue, 04 Feb 2003 07:45:07 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Feb 2003 07:45:07.0784 (UTC) FILETIME=[568CA480:01C2CC21] Subject: [Sip] Impossible to use real persistent connection with sip Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, The SIP standard does not specify who is responsible for closing TCP connections. This means that both client and server transaction can close the connection. A reasonable implementation for a transaction will be to close any open connection (incoming or outgoing) before termination in order to free unused resources. This behavior actually makes it impossible to count on a persistent connection. For example, A UA that is always talking to the same destination using TLS will want to use one connection per day. This is impossible since the server might close the connection as soon as the first transaction terminates. I can see several ways to solve this problem: 1. Specify that the UA that opened the connection will be responsible for closing it. 2. Add a header to sip requests that asks the server not to close the connection by itself. What do you think? James S Ford. _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Feb 4 04:02:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14174 for ; Tue, 4 Feb 2003 04:02:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1497ZQ10536 for sip-archive@odin.ietf.org; Tue, 4 Feb 2003 04:07:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14975J10042; Tue, 4 Feb 2003 04:07:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1495oJ09867 for ; Tue, 4 Feb 2003 04:05:50 -0500 Received: from gsp05-c21d3.vodafone.it (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14136 for ; Tue, 4 Feb 2003 03:59:55 -0500 (EST) From: loretosa@vodafone.it Received: from vodafone.it (127.0.0.1) by gsp05-c21d3.vodafone.it (NPlex 5.1.046) id 3E390D3F0000051D; Tue, 4 Feb 2003 10:03:18 +0100 X-CNS-Auth: Date: Tue, 04 Feb 2003 10:03:17 +0100 Message-Id: Subject: RE: [Sip] Extension to Assure Congestion Safety MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" To: dean.willis@softarmor.com To: eburger@snowshore.com Cc: sip@ietf.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1495pJ09868 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I agree wid Dean, I think the use of TCP doesn't introduce any lose!!! Furthermore I think also SCTP is a good chance, especially in the Instant Messaging transmission. Dean, where are you found datas and information on 3G network delay? Sal > Eric chewed on: > > I'll bite :-) > > > > How long will it take to setup a call in a > > far-from-the-antenna 3G scenario using TCP? That is, at > > 14.4kb/s, I'm looking at least 3RTT's just to say "INVITE". > > Well, consider that you should be using a long-lived TCP session established > back when you turned your phone on. Consequently, there's little further > overhead for TCP -- just some ack fields in the TCP headers on the INVITE, > 200OK, and ACK. There's probably a final null-ack TCP packet on the ACK > message, but that's after call setup has completed. > > Given this, the constraint is still the three-way handshake of SIP, which > means you have at least 3 RTTs whether you use UDP or TCP. > > So, let's say each request, using compression, is 400 bytes (that's 3200 > bits). At 14.4, that makes a total serialization delay of 222 ms per each > mobile link. Two mobile links give us 444ms. Add 150ms of core network > delays (50ms each hop), and we're at 372ms. Not too shabby so far. > > Now, add aother 50 ms each for the P-CSCF, I-CSCF, S-CSCF, I-CSCF, S-CSCF, > P-CSCF processing and we get another 300 ms for each hop, or 900ms. Add a > little more for topology hiding gateways and the like, and we're at around > 1800 ms. > > So much for the math. The problem is, current 3G systems have a lot more > transmission latency than one would think based on the bandwidth. Assuming > there's an active connection, it still tends to be a couple of hundred ms > before a mobile can actually send anything. Consequently, real world > performance with today's system adds another 2 seconds or so to the call > setup. We're working on that from the network side. On the other hand, > that's still not any worse than the 10-15 second call setup dealys I always > have on my TDMA phone . . . > > Now, lets think about the specific impact of TCP vs UDP here. The BIG delays > in SIP setup happen if a request or response gets lost and we use the SIP > backoff timers to resend. TCP, giving us a smoother-running network, is less > likely to give us a network in which packets get lost. Furthermore, its > recovery timers (especially in the wireless-tuned TCP) are likely to give > smoother, quicker recovery than does SIP in the event of a loss-burst. So, > all in all, I don't think we lose anything by using TCP to the mobile, and > we potentially gain quite a bit. Server-to-server operations have to think > about head-of-line blocking issues, and that's wehre SCTP comes in as a > better alternative. > > -- > Dean > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > Per registrarti gratuitamente a Vodafone Mail vai su www.190.it _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Feb 4 05:20:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15160 for ; Tue, 4 Feb 2003 05:20:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14AQOK14416 for sip-archive@odin.ietf.org; Tue, 4 Feb 2003 05:26:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14APwJ14405; Tue, 4 Feb 2003 05:25:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14AOxJ14327 for ; Tue, 4 Feb 2003 05:24:59 -0500 Received: from mail-server.comgates.co.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15137 for ; Tue, 4 Feb 2003 05:19:01 -0500 (EST) Received: by MAIL-SERVER with Internet Mail Service (5.5.2653.19) id <11J09WJ5>; Tue, 4 Feb 2003 12:24:19 +0200 Message-ID: <6FEF757325DBD411B7DA000629A8A61ED6A4A1@MAIL-SERVER> From: Alex Agranov To: "'sip@ietf.org'" Date: Tue, 4 Feb 2003 12:24:10 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2CC37.8E3C9DC0" Subject: [Sip] Silence Suppression in SDP for VoIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2CC37.8E3C9DC0 Content-Type: text/plain; charset="WINDOWS-1255" Hi, I tried to ask this question in sip-implementors maillist but nobody could answer it there... What is the proper way to indicate Silence Suppression and Echo Cancelation coder parameters in SDP? In MGCP these parameters are passed in LCO element, but for SIP Offer/Answer model these parameters should be passed in SDP. Right? There is RFC3108 that defines "ecan" and "silenceSupp" attributes, but it applies to VoATM. Is it applicable to VoIP too? Some late drafts, e.g. draft-ietf-sipping-realtimefax-00.txt, seem to assume RFC3108 attributes are valid for VoIP. Is this correct? Best regards, Alex Agranov --- Senior Software Engineer COMGATES Ltd. 15 Hagalim Avenue Herzliya, 46725 Israel Tel. +972.9.950.0404, Ext: 228 Fax. +972.9.950.0385 Mobile. +972.54.928435 ------_=_NextPart_001_01C2CC37.8E3C9DC0 Content-Type: text/html; charset="WINDOWS-1255" Silence Suppression in SDP for VoIP

Hi,

I tried to ask this question in sip-implementors maillist but nobody
could answer it there...

What is the proper way to indicate Silence Suppression and Echo
Cancelation coder parameters in SDP? In MGCP these parameters are
passed in LCO element, but for SIP Offer/Answer model these parameters
should be passed in SDP. Right?

There is RFC3108 that defines "ecan" and "silenceSupp" attributes, but it
applies to VoATM. Is it applicable to VoIP too?

Some late drafts, e.g. draft-ietf-sipping-realtimefax-00.txt, seem to assume
RFC3108 attributes are valid for VoIP. Is this correct?

Best regards,
                Alex Agranov
---
Senior Software Engineer
COMGATES Ltd.
15 Hagalim Avenue
Herzliya, 46725
Israel
Tel. +972.9.950.0404,  Ext: 228
Fax. +972.9.950.0385
Mobile. +972.54.928435


------_=_NextPart_001_01C2CC37.8E3C9DC0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Feb 4 07:18:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19620 for ; Tue, 4 Feb 2003 07:18:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14CO5e22627 for sip-archive@odin.ietf.org; Tue, 4 Feb 2003 07:24:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14CNfJ22599; Tue, 4 Feb 2003 07:23:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14CMsJ22560 for ; Tue, 4 Feb 2003 07:22:54 -0500 Received: from auemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19579 for ; Tue, 4 Feb 2003 07:16:56 -0500 (EST) Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h14CKWJ04173 for ; Tue, 4 Feb 2003 07:20:32 -0500 (EST) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id <1HW9C8AZ>; Tue, 4 Feb 2003 07:20:31 -0500 Message-ID: From: "Jain, Rajnish (Rajnish)" To: "'James Ford'" , sip@ietf.org Cc: "Colasanto, Eric (Eric)" , "Gurbani, Vijay K (Vijay)" Subject: RE: [Sip] Impossible to use real persistent connection with sip Date: Tue, 4 Feb 2003 07:20:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , James, The option of adding a SIP header field seems to be more flexible. That way, when that header field is not present, the persistent connection is jointly owned by both UAs. And at their discretion they can close it. This allows us to be backward compatible while enabling a new capability. Thanks, Rajnish -----Original Message----- From: James Ford [mailto:james_s_ford@hotmail.com] Sent: Tuesday, February 04, 2003 2:45 AM To: sip@ietf.org Subject: [Sip] Impossible to use real persistent connection with sip Hi, The SIP standard does not specify who is responsible for closing TCP connections. This means that both client and server transaction can close the connection. A reasonable implementation for a transaction will be to close any open connection (incoming or outgoing) before termination in order to free unused resources. This behavior actually makes it impossible to count on a persistent connection. For example, A UA that is always talking to the same destination using TLS will want to use one connection per day. This is impossible since the server might close the connection as soon as the first transaction terminates. I can see several ways to solve this problem: 1. Specify that the UA that opened the connection will be responsible for closing it. 2. Add a header to sip requests that asks the server not to close the connection by itself. What do you think? James S Ford. _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Feb 4 10:52:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25902 for ; Tue, 4 Feb 2003 10:52:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14Fvkg03348 for sip-archive@odin.ietf.org; Tue, 4 Feb 2003 10:57:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14FvCJ03326; Tue, 4 Feb 2003 10:57:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14FtIJ03250 for ; Tue, 4 Feb 2003 10:55:18 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25831 for ; Tue, 4 Feb 2003 10:49:15 -0500 (EST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h14Fqdap001419; Tue, 4 Feb 2003 07:52:40 -0800 (PST) Received: from [10.32.254.183] (stealth-10-32-254-183.cisco.com [10.32.254.183]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id ABC08617; Tue, 4 Feb 2003 07:52:39 -0800 (PST) Date: Tue, 04 Feb 2003 10:52:33 -0500 From: "David R. Oran" To: Alex Agranov , "'sip@ietf.org'" Subject: Re: [Sip] Silence Suppression in SDP for VoIP Message-ID: <169558061.1044355953@[10.32.254.183]> In-Reply-To: <6FEF757325DBD411B7DA000629A8A61ED6A4A1@MAIL-SERVER> References: <6FEF757325DBD411B7DA000629A8A61ED6A4A1@MAIL-SERVER> X-Mailer: Mulberry/3.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit There are no such parameters in SDP nor SIP because both of these are algorithm options for one end of a media stream. The source of the stream does these by itself and therefore they have no end-to-end significance. As a consequence there is no need for the receiver to know anything about Vad or ecan parameters of the transmitter, or vice versa. The reason these exist in MGCP and Megaco is because those are device control protocols intended for comand and control of an endpoint, as opposed to peer signaling protocols like SIP. --On Tuesday, February 04, 2003 12:24 PM +0200 Alex Agranov wrote: > > Hi, > > I tried to ask this question in sip-implementors maillist but nobody > could answer it there... > > What is the proper way to indicate Silence Suppression and Echo > Cancelation coder parameters in SDP? In MGCP these parameters are > passed in LCO element, but for SIP Offer/Answer model these parameters > should be passed in SDP. Right? > > There is RFC3108 that defines "ecan" and "silenceSupp" attributes, but it > applies to VoATM. Is it applicable to VoIP too? > > Some late drafts, e.g. draft-ietf-sipping-realtimefax-00.txt, seem to > assume RFC3108 attributes are valid for VoIP. Is this correct? > > Best regards, > Alex Agranov > --- > Senior Software Engineer > COMGATES Ltd. > 15 Hagalim Avenue > Herzliya, 46725 > Israel > Tel. +972.9.950.0404, Ext: 228 > Fax. +972.9.950.0385 > Mobile. +972.54.928435 ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Feb 4 12:27:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29202 for ; Tue, 4 Feb 2003 12:27:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14HWil10882 for sip-archive@odin.ietf.org; Tue, 4 Feb 2003 12:32:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14HWAJ10867; Tue, 4 Feb 2003 12:32:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14HUXJ10806 for ; Tue, 4 Feb 2003 12:30:33 -0500 Received: from mail-server.comgates.co.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29145 for ; Tue, 4 Feb 2003 12:24:24 -0500 (EST) Received: by MAIL-SERVER with Internet Mail Service (5.5.2653.19) id <11J09WZ5>; Tue, 4 Feb 2003 19:29:43 +0200 Message-ID: <6FEF757325DBD411B7DA000629A8A61ED6A4A9@MAIL-SERVER> From: Alex Agranov To: "'David R. Oran'" , "'sip@ietf.org'" Subject: RE: [Sip] Silence Suppression in SDP for VoIP Date: Tue, 4 Feb 2003 19:29:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2CC72.FFB400C0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2CC72.FFB400C0 Content-Type: text/plain; charset="iso-8859-1" Hi, I see your point. But if this is right, then why does H323 protocol support silence suppression and echo cancellation parameters? On the other hand, in case of fax fallback to G711 coder (if T38 is not supported), there is a need to specify to remote device that "echo cancelation is ON, and silence suppression is OFF". AFAIK fax will not be properly passed if silence suppression is not turned off. And this, I beleive, is the reason why draft-ietf-sipping-realtimefax-00.txt makes use of "ecan" and "silenceSupp" SDP attributes. Also there is a following sentence in H323-SIP interworking draft : "A fmtp SDP attribute for silence suppression SHOULD be defined if silence suppression is on." Is it not valid any more? Best regards, Alex Agranov > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Tuesday, February 04, 2003 5:53 PM > To: Alex Agranov; 'sip@ietf.org' > Subject: Re: [Sip] Silence Suppression in SDP for VoIP > > > There are no such parameters in SDP nor SIP because both of these are > algorithm options for one end of a media stream. The source > of the stream > does these by itself and therefore they have no end-to-end > significance. As > a consequence there is no need for the receiver to know > anything about Vad > or ecan parameters of the transmitter, or vice versa. > > The reason these exist in MGCP and Megaco is because those are device > control protocols intended for comand and control of an endpoint, as > opposed to peer signaling protocols like SIP. > > --On Tuesday, February 04, 2003 12:24 PM +0200 Alex Agranov > wrote: > > > > > Hi, > > > > I tried to ask this question in sip-implementors maillist but nobody > > could answer it there... > > > > What is the proper way to indicate Silence Suppression and Echo > > Cancelation coder parameters in SDP? In MGCP these parameters are > > passed in LCO element, but for SIP Offer/Answer model these > parameters > > should be passed in SDP. Right? > > > > There is RFC3108 that defines "ecan" and "silenceSupp" > attributes, but it > > applies to VoATM. Is it applicable to VoIP too? > > > > Some late drafts, e.g. > draft-ietf-sipping-realtimefax-00.txt, seem to > > assume RFC3108 attributes are valid for VoIP. Is this correct? > > > > Best regards, > > Alex Agranov > > --- > > Senior Software Engineer > > COMGATES Ltd. > > 15 Hagalim Avenue > > Herzliya, 46725 > > Israel > > Tel. +972.9.950.0404, Ext: 228 > > Fax. +972.9.950.0385 > > Mobile. +972.54.928435 > > ------------------------ > David R. Oran > Cisco Systems > 7 Ladyslipper Lane > Acton, MA 01720 > Office: +1 978 264 2048 > VoIP: +1 408 571 4576 > Email: oran@cisco.com > ------_=_NextPart_001_01C2CC72.FFB400C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Silence Suppression in SDP for VoIP

Hi,

I see your point.
But if this is right, then why does H323 protocol = support silence suppression and echo
cancellation parameters?

On the other hand, in case of fax fallback to G711 = coder (if T38 is not supported), there is a
need to specify to remote device that "echo = cancelation is ON, and silence suppression is OFF".
AFAIK fax will not be properly passed if silence = suppression is not turned off.
And this, I beleive, is the reason why = draft-ietf-sipping-realtimefax-00.txt makes use of
"ecan" and "silenceSupp" SDP = attributes.

Also there is a following sentence in H323-SIP = interworking draft :
        "A = fmtp SDP attribute for silence suppression SHOULD be defined if
        silence = suppression is on."
Is it not valid any more?

Best regards,
          &nb= sp;  Alex Agranov

> -----Original Message-----
> From: David R. Oran [mailto:oran@cisco.com]
> Sent: Tuesday, February 04, 2003 5:53 PM
> To: Alex Agranov; 'sip@ietf.org'
> Subject: Re: [Sip] Silence Suppression in SDP = for VoIP
>
>
> There are no such parameters in SDP nor SIP = because both of these are
> algorithm options for one end of a media = stream. The source
> of the stream
> does these by itself and therefore they have no = end-to-end
> significance. As
> a consequence there is no need for the receiver = to know
> anything about Vad
> or ecan parameters of the transmitter, or vice = versa.
>
> The reason these exist in MGCP and Megaco is = because those are device
> control protocols intended for comand and = control of an endpoint, as
> opposed to peer signaling protocols like = SIP.
>
> --On Tuesday, February 04, 2003 12:24 PM +0200 = Alex Agranov
> <sagranov@COMGATES.co.il> wrote:
>
> >
> > Hi,
> >
> > I tried to ask this question in = sip-implementors maillist but nobody
> > could answer it there...
> >
> > What is the proper way to indicate Silence = Suppression and Echo
> > Cancelation coder parameters in SDP? In = MGCP these parameters are
> > passed in LCO element, but for SIP = Offer/Answer model these
> parameters
> > should be passed in SDP. Right?
> >
> > There is RFC3108 that defines = "ecan" and "silenceSupp"
> attributes, but it
> > applies to VoATM. Is it applicable to VoIP = too?
> >
> > Some late drafts, e.g.
> draft-ietf-sipping-realtimefax-00.txt, seem = to
> > assume  RFC3108 attributes are valid = for VoIP. Is this correct?
> >
> > Best regards,
> = >           &n= bsp;     Alex Agranov
> > ---
> > Senior Software Engineer
> > COMGATES Ltd.
> > 15 Hagalim Avenue
> > Herzliya, 46725
> > Israel
> > Tel. +972.9.950.0404,  Ext: = 228
> > Fax. +972.9.950.0385
> > Mobile. +972.54.928435
>
> ------------------------
> David R. Oran
> Cisco Systems
> 7 Ladyslipper Lane
> Acton, MA 01720
> Office: +1 978 264 2048
> VoIP: +1 408 571 4576
> Email: oran@cisco.com
>

------_=_NextPart_001_01C2CC72.FFB400C0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Feb 4 12:59:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29918 for ; Tue, 4 Feb 2003 12:59:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14I55b12511 for sip-archive@odin.ietf.org; Tue, 4 Feb 2003 13:05:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14I4cJ12479; Tue, 4 Feb 2003 13:04:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14I3mJ12448 for ; Tue, 4 Feb 2003 13:03:48 -0500 Received: from seahorse.shentel.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29896 for ; Tue, 4 Feb 2003 12:57:42 -0500 (EST) Received: from Steve (ha30s481.d.shentel.net [204.111.30.225]) by seahorse.shentel.net (8.11.6/8.11.6) with SMTP id h14I0t113723; Tue, 4 Feb 2003 13:00:55 -0500 From: "Steve Silverman" To: "Alex Agranov" , "'David R. Oran'" , Subject: RE: [Sip] Silence Suppression in SDP for VoIP Date: Tue, 4 Feb 2003 13:01:28 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C2CC4D.882A5920" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <6FEF757325DBD411B7DA000629A8A61ED6A4A9@MAIL-SERVER> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C2CC4D.882A5920 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: [Sip] Silence Suppression in SDP for VoIPI would have thought that if one side is using silence suppression, the other side needs to understand this. If true, how is the use of this communicated? Steve Silverman -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Alex Agranov Sent: Tuesday, February 04, 2003 12:30 PM To: 'David R. Oran'; 'sip@ietf.org' Subject: RE: [Sip] Silence Suppression in SDP for VoIP Hi, I see your point. But if this is right, then why does H323 protocol support silence suppression and echo cancellation parameters? On the other hand, in case of fax fallback to G711 coder (if T38 is not supported), there is a need to specify to remote device that "echo cancelation is ON, and silence suppression is OFF". AFAIK fax will not be properly passed if silence suppression is not turned off. And this, I beleive, is the reason why draft-ietf-sipping-realtimefax-00.txt makes use of "ecan" and "silenceSupp" SDP attributes. Also there is a following sentence in H323-SIP interworking draft : "A fmtp SDP attribute for silence suppression SHOULD be defined if silence suppression is on." Is it not valid any more? Best regards, Alex Agranov > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Tuesday, February 04, 2003 5:53 PM > To: Alex Agranov; 'sip@ietf.org' > Subject: Re: [Sip] Silence Suppression in SDP for VoIP > > > There are no such parameters in SDP nor SIP because both of these are > algorithm options for one end of a media stream. The source > of the stream > does these by itself and therefore they have no end-to-end > significance. As > a consequence there is no need for the receiver to know > anything about Vad > or ecan parameters of the transmitter, or vice versa. > > The reason these exist in MGCP and Megaco is because those are device > control protocols intended for comand and control of an endpoint, as > opposed to peer signaling protocols like SIP. > > --On Tuesday, February 04, 2003 12:24 PM +0200 Alex Agranov > wrote: > > > > > Hi, > > > > I tried to ask this question in sip-implementors maillist but nobody > > could answer it there... > > > > What is the proper way to indicate Silence Suppression and Echo > > Cancelation coder parameters in SDP? In MGCP these parameters are > > passed in LCO element, but for SIP Offer/Answer model these > parameters > > should be passed in SDP. Right? > > > > There is RFC3108 that defines "ecan" and "silenceSupp" > attributes, but it > > applies to VoATM. Is it applicable to VoIP too? > > > > Some late drafts, e.g. > draft-ietf-sipping-realtimefax-00.txt, seem to > > assume RFC3108 attributes are valid for VoIP. Is this correct? > > > > Best regards, > > Alex Agranov > > --- > > Senior Software Engineer > > COMGATES Ltd. > > 15 Hagalim Avenue > > Herzliya, 46725 > > Israel > > Tel. +972.9.950.0404, Ext: 228 > > Fax. +972.9.950.0385 > > Mobile. +972.54.928435 > > ------------------------ > David R. Oran > Cisco Systems > 7 Ladyslipper Lane > Acton, MA 01720 > Office: +1 978 264 2048 > VoIP: +1 408 571 4576 > Email: oran@cisco.com > ------=_NextPart_000_0004_01C2CC4D.882A5920 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Silence Suppression in SDP for VoIP
I=20 would have thought that if one side is using silence suppression, the = other side=20 needs to understand this.
If=20 true, how is the use of this communicated? 
 
Steve=20 Silverman
-----Original Message-----
From: sip-admin@ietf.org = [mailto:sip-admin@ietf.org]On Behalf Of Alex = Agranov
Sent:=20 Tuesday, February 04, 2003 12:30 PM
To: 'David R. Oran';=20 'sip@ietf.org'
Subject: RE: [Sip] Silence Suppression in SDP = for=20 VoIP

Hi,

I see your point.
But if = this is=20 right, then why does H323 protocol support silence suppression and = echo=20
cancellation parameters?

On the other hand, in case of fax fallback to G711 = coder (if=20 T38 is not supported), there is a
need to = specify to=20 remote device that "echo cancelation is ON, and silence suppression is = OFF".=20
AFAIK fax will not be properly passed if = silence=20 suppression is not turned off.
And this, I = beleive, is=20 the reason why draft-ietf-sipping-realtimefax-00.txt makes use = of=20
"ecan" and "silenceSupp" SDP attributes. =

Also there is a following sentence in H323-SIP = interworking=20 draft :
        "A=20 fmtp SDP attribute for silence suppression SHOULD be defined if=20
        silence=20 suppression is on."
Is it not valid any = more?=20

Best regards,
          &nbs= p; =20 Alex Agranov

> -----Original Message-----
>=20 From: David R. Oran [mailto:oran@cisco.com] =
> Sent: Tuesday, February 04, 2003 5:53 PM =
> To: Alex Agranov; 'sip@ietf.org'
>=20 Subject: Re: [Sip] Silence Suppression in SDP for VoIP =
>
>
> There=20 are no such parameters in SDP nor SIP because both of these are=20
> algorithm options for one end of a = media stream.=20 The source
> of the stream =
> does these by itself and therefore they have no = end-to-end=20
> significance. As
> a=20 consequence there is no need for the receiver to know
> anything about Vad
> or = ecan parameters=20 of the transmitter, or vice versa.
>=20
> The reason these exist in MGCP and = Megaco is=20 because those are device
> control = protocols=20 intended for comand and control of an endpoint, as
> opposed to peer signaling protocols like SIP. =
>
> --On Tuesday, February = 04, 2003 12:24=20 PM +0200 Alex Agranov
>=20 <sagranov@COMGATES.co.il> wrote:
>=20
> >
> = > Hi,=20
> >
> > I = tried to ask=20 this question in sip-implementors maillist but nobody
> > could answer it there...
>=20 >
> > What is the proper way to = indicate=20 Silence Suppression and Echo
> > = Cancelation=20 coder parameters in SDP? In MGCP these parameters are
> > passed in LCO element, but for SIP Offer/Answer = model these=20
> parameters
> >=20 should be passed in SDP. Right?
> = >=20
> > There is RFC3108 that defines "ecan" and=20 "silenceSupp"
> attributes, but it =
> > applies to VoATM. Is it applicable to VoIP = too?=20
> >
> > Some = late drafts,=20 e.g.
> = draft-ietf-sipping-realtimefax-00.txt, seem=20 to
> > assume  RFC3108 attributes = are valid=20 for VoIP. Is this correct?
> > =
> > Best regards,
>=20 = >           &nb= sp;    =20 Alex Agranov
> > ---
> > Senior Software Engineer
> >=20 COMGATES Ltd.
> > 15 Hagalim = Avenue=20
> > Herzliya, 46725
> >=20 Israel
> > Tel. +972.9.950.0404,  = Ext:=20 228
> > Fax. +972.9.950.0385 =
> > Mobile. +972.54.928435
>=20
> ------------------------ =
> David R. Oran
> Cisco = Systems=20
> 7 Ladyslipper Lane
> Acton,=20 MA 01720
> Office: +1 978 264 2048 =
> VoIP: +1 408 571 4576
> = Email:=20 oran@cisco.com
>=20

------=_NextPart_000_0004_01C2CC4D.882A5920-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Feb 4 18:31:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07981 for ; Tue, 4 Feb 2003 18:31:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14NbQ101413 for sip-archive@odin.ietf.org; Tue, 4 Feb 2003 18:37:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14Nb1J00843; Tue, 4 Feb 2003 18:37:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14NZ2J00746 for ; Tue, 4 Feb 2003 18:35:02 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07901 for ; Tue, 4 Feb 2003 18:28:49 -0500 (EST) Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h14NWTYH016073; Tue, 4 Feb 2003 18:32:30 -0500 (EST) Message-ID: <3E404D89.7030403@dynamicsoft.com> Date: Tue, 04 Feb 2003 18:32:25 -0500 From: Jonathan Rosenberg Organization: dynamicsoft 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: Steve Silverman CC: Alex Agranov , "'David R. Oran'" , sip@ietf.org Subject: Re: [Sip] Silence Suppression in SDP for VoIP References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit In some cases, the codec itself contains specific silence packets, and so their usage would be negotiated using the codec specific parameters. You can also use the specific payload format for comfort noise, and so support of that is negotiated using the SDP codec negotiation methodology in offer/answer. However, when silence suppression is done generally, by sending nothing, no signaling support is needed since all RTP receivers need to be prepared to receive nothing and treat it as silence. That is why there are both RTP timestamps and sequence numbers. In the case of fax, I still do not see the issue. The sending side would know that it is sending g.711 encoded fax, and therefore never detect silence. -Jonathan R. Steve Silverman wrote: > I would have thought that if one side is using silence suppression, the > other side needs to understand this. > If true, how is the use of this communicated? > > Steve Silverman > > -----Original Message----- > *From:* sip-admin@ietf.org [mailto:sip-admin@ietf.org]*On Behalf Of > *Alex Agranov > *Sent:* Tuesday, February 04, 2003 12:30 PM > *To:* 'David R. Oran'; 'sip@ietf.org' > *Subject:* RE: [Sip] Silence Suppression in SDP for VoIP > > Hi, > > I see your point. > But if this is right, then why does H323 protocol support silence > suppression and echo > cancellation parameters? > > On the other hand, in case of fax fallback to G711 coder (if T38 is > not supported), there is a > need to specify to remote device that "echo cancelation is ON, and > silence suppression is OFF". > AFAIK fax will not be properly passed if silence suppression is not > turned off. > And this, I beleive, is the reason why > draft-ietf-sipping-realtimefax-00.txt makes use of > "ecan" and "silenceSupp" SDP attributes. > > Also there is a following sentence in H323-SIP interworking draft : > "A fmtp SDP attribute for silence suppression SHOULD be > defined if > silence suppression is on." > Is it not valid any more? > > Best regards, > Alex Agranov > > > -----Original Message----- > > From: David R. Oran [mailto:oran@cisco.com] > > Sent: Tuesday, February 04, 2003 5:53 PM > > To: Alex Agranov; 'sip@ietf.org' > > Subject: Re: [Sip] Silence Suppression in SDP for VoIP > > > > > > There are no such parameters in SDP nor SIP because both of these > are > > algorithm options for one end of a media stream. The source > > of the stream > > does these by itself and therefore they have no end-to-end > > significance. As > > a consequence there is no need for the receiver to know > > anything about Vad > > or ecan parameters of the transmitter, or vice versa. > > > > The reason these exist in MGCP and Megaco is because those are > device > > control protocols intended for comand and control of an endpoint, as > > opposed to peer signaling protocols like SIP. > > > > --On Tuesday, February 04, 2003 12:24 PM +0200 Alex Agranov > > wrote: > > > > > > > > Hi, > > > > > > I tried to ask this question in sip-implementors maillist but > nobody > > > could answer it there... > > > > > > What is the proper way to indicate Silence Suppression and Echo > > > Cancelation coder parameters in SDP? In MGCP these parameters are > > > passed in LCO element, but for SIP Offer/Answer model these > > parameters > > > should be passed in SDP. Right? > > > > > > There is RFC3108 that defines "ecan" and "silenceSupp" > > attributes, but it > > > applies to VoATM. Is it applicable to VoIP too? > > > > > > Some late drafts, e.g. > > draft-ietf-sipping-realtimefax-00.txt, seem to > > > assume RFC3108 attributes are valid for VoIP. Is this correct? > > > > > > Best regards, > > > Alex Agranov > > > --- > > > Senior Software Engineer > > > COMGATES Ltd. > > > 15 Hagalim Avenue > > > Herzliya, 46725 > > > Israel > > > Tel. +972.9.950.0404, Ext: 228 > > > Fax. +972.9.950.0385 > > > Mobile. +972.54.928435 > > > > ------------------------ > > David R. Oran > > Cisco Systems > > 7 Ladyslipper Lane > > Acton, MA 01720 > > Office: +1 978 264 2048 > > VoIP: +1 408 571 4576 > > Email: oran@cisco.com > > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Feb 4 19:00:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08339 for ; Tue, 4 Feb 2003 19:00:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1506eu02394 for sip-archive@odin.ietf.org; Tue, 4 Feb 2003 19:06:40 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1506IJ02381; Tue, 4 Feb 2003 19:06:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1505AJ02320 for ; Tue, 4 Feb 2003 19:05:10 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08301 for ; Tue, 4 Feb 2003 18:58:57 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h1500txQ010807 for ; Tue, 4 Feb 2003 19:00:55 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Feb 2003 18:02:34 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64465@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'sip@ietf.org'" Date: Tue, 4 Feb 2003 18:02:33 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Bug (editorial nit) in 3261 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Just posting here to request a new bug to be opened against RFC 3261. 21 Response Codes The response codes are consistent with, and extend, HTTP/1.1 response codes. Not all HTTP/1.1 response codes are appropriate, and only those that are appropriate are given here. Other HTTP/1.1 response codes SHOULD NOT be used. Strictly speaking, this is no longer true -- and I suspect time will make it less and less so. Compare, for example, SIP "416 Unsupported URI Scheme" with HTTP "416 Requested Range Not Satisfiable". We should open up a bug against the spec to revise this language when we open it for revisions again. If complete consistency is required, we need to renumber SIP 416, and develop some sort of joint IANA registry (in conjunction with and with the buy-in of the HTTP community) to prevent these types of collisions in the future. Given how disruptive such a change would be, I suspect we should just let the number spaces diverge. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Feb 5 04:11:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14984 for ; Wed, 5 Feb 2003 04:11:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h159HWN08946 for sip-archive@odin.ietf.org; Wed, 5 Feb 2003 04:17:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h159GpJ08923; Wed, 5 Feb 2003 04:16:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h159D7J08834 for ; Wed, 5 Feb 2003 04:13:07 -0500 Received: from hss.hns.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14899 for ; Wed, 5 Feb 2003 04:06:40 -0500 (EST) From: stoshniwal@hss.hns.com Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hss.hns.com (8.11.6/8.11.2) with SMTP id h158dva02170; Wed, 5 Feb 2003 14:09:58 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256CC4.0031CF5E ; Wed, 5 Feb 2003 14:34:03 +0530 X-Lotus-FromDomain: HSSBLR To: Jonathan Rosenberg cc: Steve Silverman , Alex Agranov , "'David R. Oran'" , sip@ietf.org Message-ID: <65256CC4.0031CEE2.00@sampark.hss.hns.com> Date: Wed, 5 Feb 2003 14:34:02 +0530 Subject: Re: [Sip] Silence Suppression in SDP for VoIP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi folks, The same issue was discussed on the MMUSIC and AVT lists earlier last year. Thought it would be good to pick up from where we left that time since there were opinions that time too that these parameters (ecan and silenceSupp) be moved to VoIP in general rather than keeping them to VoATM. The following are URL references to the same: [Original mail - Subject: Silence suppression attribute] http://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg00408.ht ml [Thread indices] http://www1.ietf.org/mail-archive/working-groups/mmusic/current/thrd29.html http://www1.ietf.org/mail-archive/working-groups/avt/current/mail42.html [Need for signalling silence suppression] http://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg00425.ht ml Even then, necessity for signalling silence suppression was debated, but the list seemed to be agreeing on the need for a media level parameter describing echo cancellation at the end of this thread. What is the opinion on that now? Cheers, Siddharth. -------------------------------------------------------- Siddharth Toshniwal Hughes Software Systems Prestige Opal http://www.hssworld.com 146, Infantry Road Ph (O): +91-80-2286390 (7094) Bangalore-560001, India Mobile: +91-9845154068 -------------------------------------------------------- Jonathan Rosenberg on 02/05/2003 05:02:25 AM To: Steve Silverman cc: Alex Agranov , "'David R. Oran'" , sip@ietf.org (bcc: Siddharth J Toshniwal/HSSBLR) Subject: Re: [Sip] Silence Suppression in SDP for VoIP In some cases, the codec itself contains specific silence packets, and so their usage would be negotiated using the codec specific parameters. You can also use the specific payload format for comfort noise, and so support of that is negotiated using the SDP codec negotiation methodology in offer/answer. However, when silence suppression is done generally, by sending nothing, no signaling support is needed since all RTP receivers need to be prepared to receive nothing and treat it as silence. That is why there are both RTP timestamps and sequence numbers. In the case of fax, I still do not see the issue. The sending side would know that it is sending g.711 encoded fax, and therefore never detect silence. -Jonathan R. Steve Silverman wrote: > I would have thought that if one side is using silence suppression, the > other side needs to understand this. > If true, how is the use of this communicated? > > Steve Silverman > > -----Original Message----- > *From:* sip-admin@ietf.org [mailto:sip-admin@ietf.org]*On Behalf Of > *Alex Agranov > *Sent:* Tuesday, February 04, 2003 12:30 PM > *To:* 'David R. Oran'; 'sip@ietf.org' > *Subject:* RE: [Sip] Silence Suppression in SDP for VoIP > > Hi, > > I see your point. > But if this is right, then why does H323 protocol support silence > suppression and echo > cancellation parameters? > > On the other hand, in case of fax fallback to G711 coder (if T38 is > not supported), there is a > need to specify to remote device that "echo cancelation is ON, and > silence suppression is OFF". > AFAIK fax will not be properly passed if silence suppression is not > turned off. > And this, I beleive, is the reason why > draft-ietf-sipping-realtimefax-00.txt makes use of > "ecan" and "silenceSupp" SDP attributes. > > Also there is a following sentence in H323-SIP interworking draft : > "A fmtp SDP attribute for silence suppression SHOULD be > defined if > silence suppression is on." > Is it not valid any more? > > Best regards, > Alex Agranov > > > -----Original Message----- > > From: David R. Oran [mailto:oran@cisco.com] > > Sent: Tuesday, February 04, 2003 5:53 PM > > To: Alex Agranov; 'sip@ietf.org' > > Subject: Re: [Sip] Silence Suppression in SDP for VoIP > > > > > > There are no such parameters in SDP nor SIP because both of these > are > > algorithm options for one end of a media stream. The source > > of the stream > > does these by itself and therefore they have no end-to-end > > significance. As > > a consequence there is no need for the receiver to know > > anything about Vad > > or ecan parameters of the transmitter, or vice versa. > > > > The reason these exist in MGCP and Megaco is because those are > device > > control protocols intended for comand and control of an endpoint, as > > opposed to peer signaling protocols like SIP. > > > > --On Tuesday, February 04, 2003 12:24 PM +0200 Alex Agranov > > wrote: > > > > > > > > Hi, > > > > > > I tried to ask this question in sip-implementors maillist but > nobody > > > could answer it there... > > > > > > What is the proper way to indicate Silence Suppression and Echo > > > Cancelation coder parameters in SDP? In MGCP these parameters are > > > passed in LCO element, but for SIP Offer/Answer model these > > parameters > > > should be passed in SDP. Right? > > > > > > There is RFC3108 that defines "ecan" and "silenceSupp" > > attributes, but it > > > applies to VoATM. Is it applicable to VoIP too? > > > > > > Some late drafts, e.g. > > draft-ietf-sipping-realtimefax-00.txt, seem to > > > assume RFC3108 attributes are valid for VoIP. Is this correct? > > > > > > Best regards, > > > Alex Agranov > > > --- > > > Senior Software Engineer > > > COMGATES Ltd. > > > 15 Hagalim Avenue > > > Herzliya, 46725 > > > Israel > > > Tel. +972.9.950.0404, Ext: 228 > > > Fax. +972.9.950.0385 > > > Mobile. +972.54.928435 > > > > ------------------------ > > David R. Oran > > Cisco Systems > > 7 Ladyslipper Lane > > Acton, MA 01720 > > Office: +1 978 264 2048 > > VoIP: +1 408 571 4576 > > Email: oran@cisco.com > > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Feb 5 05:55:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16948 for ; Wed, 5 Feb 2003 05:55:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h15B1R213914 for sip-archive@odin.ietf.org; Wed, 5 Feb 2003 06:01:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15B0tJ13851; Wed, 5 Feb 2003 06:00:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15AxwJ13767 for ; Wed, 5 Feb 2003 05:59:58 -0500 Received: from gsp01-c07d1.vodafone.it (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16902 for ; Wed, 5 Feb 2003 05:53:31 -0500 (EST) From: loretosa@vodafone.it Received: from vodafone.it (127.0.0.1) by gsp01-c07d1.vodafone.it (NPlex 5.1.046) id 3E405A7F00000092; Wed, 5 Feb 2003 11:56:51 +0100 X-CNS-Auth: Date: Wed, 05 Feb 2003 11:56:50 +0100 Message-Id: MIME-Version: 1.0 X-Priority: 1 Priority: urgent X-Importance: 1 Importance: High Content-Type: text/plain;charset="iso-8859-1" To: dean.willis@softarmor.com To: eburger@snowshore.com Cc: sip@ietf.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h15AxwJ13768 Subject: [Sip] call setup Time and TCP/SCTP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I agree with Dean, I think the use of TCP doesn't introduce any significant lose!!! Furthermore I think also SCTP is a good chance, especially in the Instant Messaging transmission. Dean, where did you found datas and information on 3G network delay? are there some publication (article or technical report)? I'd like read them. Sal Per registrarti gratuitamente a Vodafone Mail vai su www.190.it _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Feb 5 06:48:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19313 for ; Wed, 5 Feb 2003 06:48:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h15Bskh18037 for sip-archive@odin.ietf.org; Wed, 5 Feb 2003 06:54:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15BsRJ17991; Wed, 5 Feb 2003 06:54:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15BpPJ17765 for ; Wed, 5 Feb 2003 06:51:25 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19104; Wed, 5 Feb 2003 06:44:57 -0500 (EST) Message-Id: <200302051144.GAA19104@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org, sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 05 Feb 2003 06:44:57 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-scvrtdisco-03.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Session Initiation Protocol Extension Header Field for Service Route Discovery During Registration Author(s) : D. Willis, B. Hoeneisen Filename : draft-ietf-sip-scvrtdisco-03.txt Pages : 18 Date : 2003-2-4 This document defines a SIP extension header field used in conjunction with responses to REGISTER requests to provide a mechanism by which a registrar may inform a registering UA of a service route that the UA may use to request outbound services from the registrar's domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-scvrtdisco-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-scvrtdisco-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-scvrtdisco-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-4134059.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-scvrtdisco-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-scvrtdisco-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-4134059.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Feb 5 09:30:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26554 for ; Wed, 5 Feb 2003 09:30:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h15Ea5X28604 for sip-archive@odin.ietf.org; Wed, 5 Feb 2003 09:36:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15EZbJ28577; Wed, 5 Feb 2003 09:35:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15EXVJ28455 for ; Wed, 5 Feb 2003 09:33:31 -0500 Received: from mirlo.dit.upm.es (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26447 for ; Wed, 5 Feb 2003 09:26:56 -0500 (EST) Received: from faisan (faisan [138.4.50.4]) by mirlo.dit.upm.es (8.8.5/8.7.3) with SMTP id OAA05733 for ; Wed, 5 Feb 2003 14:31:09 GMT Reply-To: From: "Manuel Moreno" To: Date: Wed, 5 Feb 2003 15:30:53 +0100 Message-ID: <000d01c2cd23$31f22f20$0432048a@cipres.upm.es> 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 V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] How close one dialog?? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Please: How close one specific dialog inside one session with multiple dialogs? Is possible with the BYE method, with the specific "tags" values in the FROM and TO headers?? Thank you Manuel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Feb 5 10:08:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27747 for ; Wed, 5 Feb 2003 10:08:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h15FEq031566 for sip-archive@odin.ietf.org; Wed, 5 Feb 2003 10:14:52 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15FETJ31524; Wed, 5 Feb 2003 10:14:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15FDmJ31477 for ; Wed, 5 Feb 2003 10:13:48 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27657 for ; Wed, 5 Feb 2003 10:07:18 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h15FAtKV023361; Wed, 5 Feb 2003 16:10:55 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id DW0DGJDL; Wed, 5 Feb 2003 16:10:54 +0100 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.137]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h15FAtH7023128; Wed, 5 Feb 2003 17:10:55 +0200 (EET) Message-ID: <3E41297E.BE861F2@lmf.ericsson.se> Date: Wed, 05 Feb 2003 17:10:54 +0200 X-Sybari-Trust: 879bba24 9ffcebbb 22f6c2a2 00000138 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mmoreno@cipres.upm.es CC: sip@ietf.org Subject: Re: [Sip] How close one dialog?? References: <000d01c2cd23$31f22f20$0432048a@cipres.upm.es> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, > Please: > > How close one specific dialog inside one session with multiple dialogs? > > Is possible with the BYE method, with the specific "tags" values in the > FROM and TO headers?? Yes. In fact, you shall always include the tags in BYE, no matter how many dialogs you have. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Feb 5 10:13:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27905 for ; Wed, 5 Feb 2003 10:13:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h15FJdf31818 for sip-archive@odin.ietf.org; Wed, 5 Feb 2003 10:19:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15FJDJ31792; Wed, 5 Feb 2003 10:19:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15FIWJ31756 for ; Wed, 5 Feb 2003 10:18:32 -0500 Received: from mail-server.comgates.co.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27859 for ; Wed, 5 Feb 2003 10:11:52 -0500 (EST) Received: by MAIL-SERVER with Internet Mail Service (5.5.2653.19) id <11J09X4W>; Wed, 5 Feb 2003 17:17:13 +0200 Message-ID: <6FEF757325DBD411B7DA000629A8A61ED6A4B3@MAIL-SERVER> From: Alex Agranov To: "'Jonathan Rosenberg'" , Steve Silverman Cc: "'David R. Oran'" , sip@ietf.org Subject: RE: [Sip] Silence Suppression in SDP for VoIP Date: Wed, 5 Feb 2003 17:17:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2CD29.A286ED60" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2CD29.A286ED60 Content-Type: text/plain; charset="iso-8859-1" Hi, Talking about G711 fax fallback - I agree that for the direct call between 2 SIP UA's silence suppression may be detected by each SIP UA when it recognizes the fax tone. However let's look at the following scenario: (SIP UA) ----SIP---- (PSTN GW) ----SS7---- (PSTN GW) ----SIP---- (SIP UA) There is a need to pass information about silence mode between PSTN GW's, so that they make proper connections in the corresponding MGW's. For the regular SS7 call this information is included in SS7 message. But if we have regular SIP UA's (not SIP-T GW's), there is no indication of silence suppression mode in the SIP message. Hence there will be no indication of silence mode in SS7 message too. Best regards, Alex Agranov --- Senior Software Engineer COMGATES Ltd. 15 Hagalim Avenue Herzliya, 46725 Israel Tel. +972.9.950.0404, Ext: 228 Fax. +972.9.950.0385 Mobile. +972.54.928435 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, February 05, 2003 1:32 AM > To: Steve Silverman > Cc: Alex Agranov; 'David R. Oran'; sip@ietf.org > Subject: Re: [Sip] Silence Suppression in SDP for VoIP > > > In some cases, the codec itself contains specific silence > packets, and > so their usage would be negotiated using the codec specific > parameters. > You can also use the specific payload format for comfort > noise, and so > support of that is negotiated using the SDP codec negotiation > methodology in offer/answer. However, when silence > suppression is done > generally, by sending nothing, no signaling support is needed > since all > RTP receivers need to be prepared to receive nothing and treat it as > silence. That is why there are both RTP timestamps and > sequence numbers. > > In the case of fax, I still do not see the issue. The sending > side would > know that it is sending g.711 encoded fax, and therefore never detect > silence. > > -Jonathan R. > > Steve Silverman wrote: > > I would have thought that if one side is using silence > suppression, the > > other side needs to understand this. > > If true, how is the use of this communicated? > > > > Steve Silverman > > > > -----Original Message----- > > *From:* sip-admin@ietf.org > [mailto:sip-admin@ietf.org]*On Behalf Of > > *Alex Agranov > > *Sent:* Tuesday, February 04, 2003 12:30 PM > > *To:* 'David R. Oran'; 'sip@ietf.org' > > *Subject:* RE: [Sip] Silence Suppression in SDP for VoIP > > > > Hi, > > > > I see your point. > > But if this is right, then why does H323 protocol > support silence > > suppression and echo > > cancellation parameters? > > > > On the other hand, in case of fax fallback to G711 > coder (if T38 is > > not supported), there is a > > need to specify to remote device that "echo cancelation > is ON, and > > silence suppression is OFF". > > AFAIK fax will not be properly passed if silence > suppression is not > > turned off. > > And this, I beleive, is the reason why > > draft-ietf-sipping-realtimefax-00.txt makes use of > > "ecan" and "silenceSupp" SDP attributes. > > > > Also there is a following sentence in H323-SIP > interworking draft : > > "A fmtp SDP attribute for silence suppression SHOULD be > > defined if > > silence suppression is on." > > Is it not valid any more? > > > > Best regards, > > Alex Agranov > > > > > -----Original Message----- > > > From: David R. Oran [mailto:oran@cisco.com] > > > Sent: Tuesday, February 04, 2003 5:53 PM > > > To: Alex Agranov; 'sip@ietf.org' > > > Subject: Re: [Sip] Silence Suppression in SDP for VoIP > > > > > > > > > There are no such parameters in SDP nor SIP because > both of these > > are > > > algorithm options for one end of a media stream. The source > > > of the stream > > > does these by itself and therefore they have no end-to-end > > > significance. As > > > a consequence there is no need for the receiver to know > > > anything about Vad > > > or ecan parameters of the transmitter, or vice versa. > > > > > > The reason these exist in MGCP and Megaco is because > those are > > device > > > control protocols intended for comand and control of > an endpoint, as > > > opposed to peer signaling protocols like SIP. > > > > > > --On Tuesday, February 04, 2003 12:24 PM +0200 Alex Agranov > > > wrote: > > > > > > > > > > > Hi, > > > > > > > > I tried to ask this question in sip-implementors > maillist but > > nobody > > > > could answer it there... > > > > > > > > What is the proper way to indicate Silence > Suppression and Echo > > > > Cancelation coder parameters in SDP? In MGCP these > parameters are > > > > passed in LCO element, but for SIP Offer/Answer model these > > > parameters > > > > should be passed in SDP. Right? > > > > > > > > There is RFC3108 that defines "ecan" and "silenceSupp" > > > attributes, but it > > > > applies to VoATM. Is it applicable to VoIP too? > > > > > > > > Some late drafts, e.g. > > > draft-ietf-sipping-realtimefax-00.txt, seem to > > > > assume RFC3108 attributes are valid for VoIP. Is > this correct? > > > > > > > > Best regards, > > > > Alex Agranov > > > > --- > > > > Senior Software Engineer > > > > COMGATES Ltd. > > > > 15 Hagalim Avenue > > > > Herzliya, 46725 > > > > Israel > > > > Tel. +972.9.950.0404, Ext: 228 > > > > Fax. +972.9.950.0385 > > > > Mobile. +972.54.928435 > > > > > > ------------------------ > > > David R. Oran > > > Cisco Systems > > > 7 Ladyslipper Lane > > > Acton, MA 01720 > > > Office: +1 978 264 2048 > > > VoIP: +1 408 571 4576 > > > Email: oran@cisco.com > > > > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > ------_=_NextPart_001_01C2CD29.A286ED60 Content-Type: text/html; charset="iso-8859-1" RE: [Sip] Silence Suppression in SDP for VoIP

Hi,

Talking about G711 fax fallback - I agree that for the direct call between 2 SIP UA's silence
suppression may be detected by each SIP UA when it recognizes the fax tone.

However let's look at the following scenario:

(SIP UA) ----SIP---- (PSTN GW) ----SS7---- (PSTN GW) ----SIP---- (SIP UA)

There is a need to pass information about silence mode between PSTN GW's,
so that they make proper connections in the corresponding MGW's.

For the regular SS7 call this information is included in SS7 message. But if we
have regular SIP UA's (not SIP-T GW's), there is no indication of silence suppression mode
in the SIP message. Hence there will be no indication of silence mode in SS7 message too.

Best regards,
                Alex Agranov
---
Senior Software Engineer
COMGATES Ltd.
15 Hagalim Avenue
Herzliya, 46725
Israel
Tel. +972.9.950.0404,  Ext: 228
Fax. +972.9.950.0385
Mobile. +972.54.928435


> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Wednesday, February 05, 2003 1:32 AM
> To: Steve Silverman
> Cc: Alex Agranov; 'David R. Oran'; sip@ietf.org
> Subject: Re: [Sip] Silence Suppression in SDP for VoIP
>
>
> In some cases, the codec itself contains specific silence
> packets, and
> so their usage would be negotiated using the codec specific
> parameters.
> You can also use the specific payload format for comfort
> noise, and so
> support of that is negotiated using the SDP codec negotiation
> methodology in offer/answer. However, when silence
> suppression is done
> generally, by sending nothing, no signaling support is needed
> since all
> RTP receivers need to be prepared to receive nothing and treat it as
> silence. That is why there are both RTP timestamps and
> sequence numbers.
>
> In the case of fax, I still do not see the issue. The sending
> side would
> know that it is sending g.711 encoded fax, and therefore never detect
> silence.
>
> -Jonathan R.
>
> Steve Silverman wrote:
> > I would have thought that if one side is using silence
> suppression, the
> > other side needs to understand this.
> > If true, how is the use of this communicated?
> > 
> > Steve Silverman
> >
> >     -----Original Message-----
> >     *From:* sip-admin@ietf.org
> [mailto:sip-admin@ietf.org]*On Behalf Of
> >     *Alex Agranov
> >     *Sent:* Tuesday, February 04, 2003 12:30 PM
> >     *To:* 'David R. Oran'; 'sip@ietf.org'
> >     *Subject:* RE: [Sip] Silence Suppression in SDP for VoIP
> >
> >     Hi,
> >
> >     I see your point.
> >     But if this is right, then why does H323 protocol
> support silence
> >     suppression and echo
> >     cancellation parameters?
> >
> >     On the other hand, in case of fax fallback to G711
> coder (if T38 is
> >     not supported), there is a
> >     need to specify to remote device that "echo cancelation
> is ON, and
> >     silence suppression is OFF".
> >     AFAIK fax will not be properly passed if silence
> suppression is not
> >     turned off.
> >     And this, I beleive, is the reason why
> >     draft-ietf-sipping-realtimefax-00.txt makes use of
> >     "ecan" and "silenceSupp" SDP attributes.
> >
> >     Also there is a following sentence in H323-SIP
> interworking draft :
> >             "A fmtp SDP attribute for silence suppression SHOULD be
> >     defined if
> >             silence suppression is on."
> >     Is it not valid any more?
> >
> >     Best regards,
> >                  Alex Agranov
> >
> >      > -----Original Message-----
> >      > From: David R. Oran [mailto:oran@cisco.com]
> >      > Sent: Tuesday, February 04, 2003 5:53 PM
> >      > To: Alex Agranov; 'sip@ietf.org'
> >      > Subject: Re: [Sip] Silence Suppression in SDP for VoIP
> >      >
> >      >
> >      > There are no such parameters in SDP nor SIP because
> both of these
> >     are
> >      > algorithm options for one end of a media stream. The source
> >      > of the stream
> >      > does these by itself and therefore they have no end-to-end
> >      > significance. As
> >      > a consequence there is no need for the receiver to know
> >      > anything about Vad
> >      > or ecan parameters of the transmitter, or vice versa.
> >      >
> >      > The reason these exist in MGCP and Megaco is because
> those are
> >     device
> >      > control protocols intended for comand and control of
> an endpoint, as
> >      > opposed to peer signaling protocols like SIP.
> >      >
> >      > --On Tuesday, February 04, 2003 12:24 PM +0200 Alex Agranov
> >      > <sagranov@COMGATES.co.il> wrote:
> >      >
> >      > >
> >      > > Hi,
> >      > >
> >      > > I tried to ask this question in sip-implementors
> maillist but
> >     nobody
> >      > > could answer it there...
> >      > >
> >      > > What is the proper way to indicate Silence
> Suppression and Echo
> >      > > Cancelation coder parameters in SDP? In MGCP these
> parameters are
> >      > > passed in LCO element, but for SIP Offer/Answer model these
> >      > parameters
> >      > > should be passed in SDP. Right?
> >      > >
> >      > > There is RFC3108 that defines "ecan" and "silenceSupp"
> >      > attributes, but it
> >      > > applies to VoATM. Is it applicable to VoIP too?
> >      > >
> >      > > Some late drafts, e.g.
> >      > draft-ietf-sipping-realtimefax-00.txt, seem to
> >      > > assume  RFC3108 attributes are valid for VoIP. Is
> this correct?
> >      > >
> >      > > Best regards,
> >      > >                 Alex Agranov
> >      > > ---
> >      > > Senior Software Engineer
> >      > > COMGATES Ltd.
> >      > > 15 Hagalim Avenue
> >      > > Herzliya, 46725
> >      > > Israel
> >      > > Tel. +972.9.950.0404,  Ext: 228
> >      > > Fax. +972.9.950.0385
> >      > > Mobile. +972.54.928435
> >      >
> >      > ------------------------
> >      > David R. Oran
> >      > Cisco Systems
> >      > 7 Ladyslipper Lane
> >      > Acton, MA 01720
> >      > Office: +1 978 264 2048
> >      > VoIP: +1 408 571 4576
> >      > Email: oran@cisco.com
> >      >
> >
>
> --
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>

------_=_NextPart_001_01C2CD29.A286ED60-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Feb 5 15:32:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09705 for ; Wed, 5 Feb 2003 15:32:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h15KcLK21602 for sip-archive@odin.ietf.org; Wed, 5 Feb 2003 15:38:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15KbsJ21549; Wed, 5 Feb 2003 15:37:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15KaSJ20854 for ; Wed, 5 Feb 2003 15:36:28 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09641 for ; Wed, 5 Feb 2003 15:29:51 -0500 (EST) Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h15KXWYH016941 for ; Wed, 5 Feb 2003 15:33:33 -0500 (EST) Message-ID: <3E417518.3030405@dynamicsoft.com> Date: Wed, 05 Feb 2003 15:33:28 -0500 From: Jonathan Rosenberg Organization: dynamicsoft 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: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] More woes with implicit caller preferences Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, Well, I *thought* I was done with the caller preferences revision. However, I began the process of validating the spec against our use cases, and found that one of them broke, once more due to implicit preferences. I'll spare people the gory details, and summarize the problem thusly. When a caller makes explicit preferences in the request (by including Accept and Reject contact header fields), it is very hard for a proxy to properly determine how to ADD implicit preferences (for the method and events). The reason is that there are many ways in which the explicit and implicit preferences can be combined (add a new predicate, add a term to all existing predicates, add a term to some existing predicates, change the q-values after such additions, etc.). I do not think there is one right way. Indeed, one of the use cases failed with the current mechanism (add a new predicate), whereas others worked. The right way depends on the desired service, but the proxy doesnt know what it is. So, I have a simple solution. The solution is that the proxy NEVER adds implicit preferences if there are any explicit preferences at all. That is, if there is an Accept or Reject Contact header field, the proxy does not try to add implicit preferences. Only in the case where there are no headers, will the proxy compute an implicit preference. In this way, we eliminate the combination problem I point out above. This change also simplifies the proxy processing in the case where an implicit preference eliminates all contacts in the target set. Currently, this will require the proxy to run the entire algorithm again. With this change, it won't. If implicit preferences is used, and all targets are eliminated, the proxy simply uses the original target set without caller preferences processing. I will need to add words that encourage a caller who uses callerprefs to include preferences for the method and event packages. The use case document will elaborate on the various ways in which one might express those preferences, and show how they affect routing. I doubt there will be complaints, so I am going to go ahead and change the text to reflect this. However, if you do have issues with this solution, please speak now. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Feb 5 15:52:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10275 for ; Wed, 5 Feb 2003 15:52:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h15Kwg522473 for sip-archive@odin.ietf.org; Wed, 5 Feb 2003 15:58:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15KwJJ22451; Wed, 5 Feb 2003 15:58:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15KvvJ22413 for ; Wed, 5 Feb 2003 15:57:57 -0500 Received: from mail.bredband.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10196 for ; Wed, 5 Feb 2003 15:51:18 -0500 (EST) Received: from b2mail01.bredband.local ([192.168.46.46]) by mail.bredband.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 5 Feb 2003 21:54:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2CD58.D6095B72" Date: Wed, 5 Feb 2003 21:54:55 +0100 Message-ID: Thread-Topic: INVITE, CANCEL and BYE, re-transitions Thread-Index: AcLNWLoj7Hshrot9RqadIxLmIdP7vQ== From: "Thomas Vasen" To: X-OriginalArrivalTime: 05 Feb 2003 20:54:55.0701 (UTC) FILETIME=[D65CB050:01C2CD58] Subject: [Sip] INVITE, CANCEL and BYE, re-transitions Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C2CD58.D6095B72 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would just like to verify my understanding regarding 'Backup Routes' with SIP.=20 =20 Suppose one UA has 2 routes, one primary to PROXY1, and one secondary to PROXY2.=20 =20 Suppose PROXY1 is down.=20 When the UA sets up a session, it will Send INVITE to Proxy 1 Timeout Eventually send INVITE to Proxy 2, and setup the session.=20 =20 Suppose now Proxy 1 and 2 are UP.=20 UA send INVITE to Proxy 1 Proxy sends trying and sets up session.=20 Proxy 1 dies. UA sends BYE to Proxy 1, though does not receive any response.=20 =20 Shouldn't at this point the UA try to send the BYE to the Proxy 2 as well? =20 E.g. I think that each INVITE, BYE and CANCEL transaction shall be treated separately from a routing perspective. =20 Am I thinking right? Regards,=20 //Thomas.=20 =20 =20 Thomas Vasen B2 Bredband AB =20 E-mail: thomas.vasen@bredband.com =20 ------_=_NextPart_001_01C2CD58.D6095B72 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would just like to verify my understanding = regarding ‘Backup Routes’ with SIP.

 

Suppose one UA has 2 routes, one primary to = PROXY1, and one secondary to PROXY2.

 

Suppose PROXY1 is down.

When the UA sets up a session, it = will

Send INVITE to Proxy = 1

Timeout

=

Eventually send INVITE = to Proxy 2, and setup the session.

 

Suppose now Proxy 1 and 2 are UP. =

UA send INVITE to Proxy = 1

Proxy sends trying and = sets up session.

Proxy 1 = dies.

UA sends BYE to Proxy 1, = though does not receive any response.

 

Shouldn’t at this point the UA try to send = the BYE to the Proxy 2 as well?

 

E.g. I think that each INVITE, BYE and CANCEL = transaction shall be treated separately from a routing = perspective.

 

Am I thinking right?

Regards,

//Thomas.

 

 

Thomas = Vasen

B2 = Bredband AB

 

E-mail: thomas.vasen@bredband.com

 

------_=_NextPart_001_01C2CD58.D6095B72-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Feb 5 17:52:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14454 for ; Wed, 5 Feb 2003 17:52:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h15Mwmn04057 for sip-archive@odin.ietf.org; Wed, 5 Feb 2003 17:58:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15Mw7p04034; Wed, 5 Feb 2003 17:58:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15Mrpp03912 for ; Wed, 5 Feb 2003 17:53:51 -0500 Received: from broadsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14335 for ; Wed, 5 Feb 2003 17:47:11 -0500 (EST) Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.12.6) id h15Monfl071440; Wed, 5 Feb 2003 17:50:49 -0500 (EST) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] INVITE, CANCEL and BYE, re-transitions Date: Wed, 5 Feb 2003 17:52:57 -0500 Message-ID: <000201c2cd69$5474b4f0$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit "This list is for NEW development of the core SIP Protocol. Use sip-implementors@cs.columbia.edu for questions on current sip. Use sipping@ietf.org for new developments on the application of sip." > I would just like to verify my understanding > regarding ‘Backup Routes’ with SIP. > > Suppose one UA has 2 routes, one primary to > PROXY1, and one secondary to PROXY2. > > Suppose PROXY1 is down. > When the UA sets up a session, it will > Send INVITE to Proxy 1 > Timeout > Eventually send INVITE to Proxy 2, and setup the session. When advancing to proxy 2, one or more of the following should change within INVITE to denote forking: 1) From tag 2) Call-ID 3) Via branch > Suppose now Proxy 1 and 2 are UP. > UA send INVITE to Proxy 1 > Proxy sends trying and sets up session. > Proxy 1 dies. > UA sends BYE to Proxy 1, though does not receive any response. The 100 Trying response does not create an early dialog. Thus CANCEL must be sent instead of a BYE. > Shouldn’t at this point the UA try to send the > BYE to the Proxy 2 as well? The CANCEL should only be sent where the INVITE was sent. (This is mainly because the top via entry is used to help identify the cancelled request.) If a 101-2xx response was received and the proxy's Record-Route entry included a hostname representing both proxies, the BYE could target advance to proxy 2 when proxy 1 is not responding. Please see RFC 3261 sections 9, 12, and 13 for a more complete description. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Feb 5 20:25:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17757 for ; Wed, 5 Feb 2003 20:25:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h161Vfa11614 for sip-archive@odin.ietf.org; Wed, 5 Feb 2003 20:31:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h161VHp11597; Wed, 5 Feb 2003 20:31:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h161TUp11485 for ; Wed, 5 Feb 2003 20:29:30 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17693 for ; Wed, 5 Feb 2003 20:22:45 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h161QNLd018119; Wed, 5 Feb 2003 19:26:24 -0600 From: "Dean Willis" To: , Cc: Subject: RE: [Sip] Extension to Assure Congestion Safety Date: Wed, 5 Feb 2003 19:26:05 -0600 Message-ID: <00ef01c2cd7e$b8fa9b00$43084080@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h161TVp11486 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > > Dean, where are you found datas and information on 3G network delay? > Primarily from presentations to the 3GPP-IETF joint meeting last week in San Francisco, plus my own experience with a couple of CDMA 2000 1XRTT networks, as well was with GRPS over GSM TDMA (which, despite some marketing programs, isn't really 3G). Don't get me wrong -- there are plenty of potential sources of delay here. But properly used TCP really isn't a major contributor. There's a large body of work out there. I suggest starting with RFC 2757 ftp://ftp.rfc-editor.org/in-notes/rfc2757.txt And I'd like to point out ongoing work (just a tiny subset of what's going on). http://www.ietf.org/internet-drafts/draft-ietf-pilc-2.5g3g-12.txt http://www.ietf.org/internet-drafts/draft-sarolahti-tsvwg-tcp-frto-03.txt http://www.ietf.org/internet-drafts/draft-amit-quick-start-02.txt http://www.ietf.org/internet-drafts/draft-ludwig-tsvwg-tcp-fast-timeouts-00. txt http://www.ietf.org/internet-drafts/draft-gurtov-tsvwg-tcp-delay-spikes-01.t xt http://www.ietf.org/internet-drafts/draft-ietf-rohc-tcp-03.txt The basic point is that there is a tremendous amount of effort going into understanding and improving TCP's behaviour over wireless networks, and trying to re-invent all of that here for SIP/UDP is sheer folly. Sure, UDP is potentially useful, especially for lightweight mobile-to-first-hop-server links, but probably just dangerous and pointless for server-server links. I propose that we DO NOT need to "fix" this in SIP -- we just need to limit the usage so that UDP is only used in the non-dangerous cases. This shouldn't be all that hard to do. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Feb 6 02:16:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06373 for ; Thu, 6 Feb 2003 02:16:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h167NFU07157 for sip-archive@odin.ietf.org; Thu, 6 Feb 2003 02:23:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h167Mmp07118; Thu, 6 Feb 2003 02:22:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h167KXp07055 for ; Thu, 6 Feb 2003 02:20:33 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06313 for ; Thu, 6 Feb 2003 02:13:41 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 5 Feb 2003 23:16:49 -0800 Received: from 212.143.185.30 by lw15fd.law15.hotmail.msn.com with HTTP; Thu, 06 Feb 2003 07:16:49 GMT X-Originating-IP: [212.143.185.30] From: "James Ford" To: rajnishjain@lucent.com, sip@ietf.org Cc: ecolasanto@lucent.com, vkg@ih2mail.ih.lucent.com Subject: RE: [Sip] Impossible to use real persistent connection with sip Date: Thu, 06 Feb 2003 07:16:49 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Feb 2003 07:16:49.0625 (UTC) FILETIME=[B731A490:01C2CDAF] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , An even simpler solution will be to add a parameter to the Via header such as pc; (or pc=1 so that we will not have troubles with Microsoft). Pc stands for persistent connection. Guys, what do I need to do to move on this thing so that we will have a new draft to solve the problem? I think many implementations will be interested in using a real persistent connection especially when TLS will be more deployed. Thanks, James S. Ford >From: "Jain, Rajnish (Rajnish)" >To: "'James Ford'" , sip@ietf.org >CC: "Colasanto, Eric (Eric)" , "Gurbani, Vijay K >(Vijay)" >Subject: RE: [Sip] Impossible to use real persistent connection with sip >Date: Tue, 4 Feb 2003 07:20:22 -0500 > >James, > >The option of adding a SIP header field seems to be more flexible. That >way, >when that header field is not present, the persistent connection is jointly >owned by both UAs. And at their discretion they can close it. This allows >us >to be backward compatible while enabling a new capability. > >Thanks, >Rajnish > >-----Original Message----- >From: James Ford [mailto:james_s_ford@hotmail.com] >Sent: Tuesday, February 04, 2003 2:45 AM >To: sip@ietf.org >Subject: [Sip] Impossible to use real persistent connection with sip > > >Hi, >The SIP standard does not specify who is responsible for closing TCP >connections. This means that both client and server transaction can close >the connection. A reasonable implementation for a transaction will be to >close any open connection (incoming or outgoing) before termination in >order >to free unused resources. >This behavior actually makes it impossible to count on a persistent >connection. >For example, A UA that is always talking to the same destination using TLS >will want to use one connection per day. This is impossible since the >server >might close the connection as soon as the first transaction terminates. > >I can see several ways to solve this problem: >1. Specify that the UA that opened the connection will be responsible for >closing it. >2. Add a header to sip requests that asks the server not to close the >connection by itself. > >What do you think? >James S Ford. > > > > > > >_________________________________________________________________ >Add photos to your e-mail with MSN 8. Get 2 months FREE*. >http://join.msn.com/?page=features/featuredemail > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Feb 6 05:05:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10918 for ; Thu, 6 Feb 2003 05:05:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16AC7x18566 for sip-archive@odin.ietf.org; Thu, 6 Feb 2003 05:12:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16ABhp18545; Thu, 6 Feb 2003 05:11:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16AAdp18480 for ; Thu, 6 Feb 2003 05:10:39 -0500 Received: from gsp05-c21d3.vodafone.it (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10818 for ; Thu, 6 Feb 2003 05:03:44 -0500 (EST) From: loretosa@vodafone.it Received: from vodafone.it (127.0.0.1) by gsp05-c21d3.vodafone.it (NPlex 5.1.046) id 3E390D3F00000713; Thu, 6 Feb 2003 11:06:57 +0100 X-CNS-Auth: Date: Thu, 06 Feb 2003 11:06:57 +0100 Message-Id: Subject: Ri: RE: [Sip] Extension to Assure Congestion Safety MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" To: dean.willis@softarmor.com To: eburger@snowshore.com Cc: sip@ietf.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h16AAdp18481 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit thanks for informations. but i'd like some papers/articles about latency in the internal nodes of IP Multimedia Subsystem like CSCF... and the others servers... where have you found the following informations? "Now, add aother 50 ms each for the P-CSCF, I-CSCF, S-CSCF, I-CSCF, S-CSCF, P-CSCF processing and we get another 300 ms for each hop, or 900ms. Add a little more for topology hiding gateways and the like, and we're at around 1800 ms." best regards Sal > > > > Dean, where are you found datas and information on 3G network delay? > > > > Primarily from presentations to the 3GPP-IETF joint meeting last week in San > Francisco, plus my own experience with a couple of CDMA 2000 1XRTT networks, > as well was with GRPS over GSM TDMA (which, despite some marketing > programs, isn't really 3G). > > Don't get me wrong -- there are plenty of potential sources of delay here. > But properly used TCP really isn't a major contributor. > > There's a large body of work out there. I suggest starting with RFC 2757 > > ftp://ftp.rfc-editor.org/in-notes/rfc2757.txt > > > And I'd like to point out ongoing work (just a tiny subset of what's going > on). > > http://www.ietf.org/internet-drafts/draft-ietf-pilc-2.5g3g-12.txt > > http://www.ietf.org/internet-drafts/draft-sarolahti-tsvwg-tcp-frto-03.txt > > http://www.ietf.org/internet-drafts/draft-amit-quick-start-02.txt > > http://www.ietf.org/internet-drafts/draft-ludwig-tsvwg-tcp-fast-timeouts-00. > txt > > http://www.ietf.org/internet-drafts/draft-gurtov-tsvwg-tcp-delay-spikes-01.t > xt > > http://www.ietf.org/internet-drafts/draft-ietf-rohc-tcp-03.txt > > The basic point is that there is a tremendous amount of effort going into > understanding and improving TCP's behaviour over wireless networks, and > trying to re-invent all of that here for SIP/UDP is sheer folly. Sure, UDP > is potentially useful, especially for lightweight mobile-to-first-hop-server > links, but probably just dangerous and pointless for server-server links. I > propose that we DO NOT need to "fix" this in SIP -- we just need to limit > the usage so that UDP is only used in the non-dangerous cases. This > shouldn't be all that hard to do. > > -- > Dean > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > Per registrarti gratuitamente a Vodafone Mail vai su www.190.it _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Feb 6 05:33:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11645 for ; Thu, 6 Feb 2003 05:33:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16AdmS20663 for sip-archive@odin.ietf.org; Thu, 6 Feb 2003 05:39:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16AdUp20628; Thu, 6 Feb 2003 05:39:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16AcJp20560 for ; Thu, 6 Feb 2003 05:38:19 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11613; Thu, 6 Feb 2003 05:31:24 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h16AYuKV020200; Thu, 6 Feb 2003 11:34:56 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id DY5TVRQT; Thu, 6 Feb 2003 11:34:56 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h16AYuH7021218; Thu, 6 Feb 2003 12:34:56 +0200 (EET) Message-ID: <3E423A4E.3C404641@lmf.ericsson.se> Date: Thu, 06 Feb 2003 12:34:54 +0200 X-Sybari-Trust: 0c6564b1 9ffcebbb 22f6c2a2 00000138 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip , sipping CC: Dean Willis , Jon Peterson , Rohan Mahy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Design teams Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, I am updating the design team web pages for SIPPING and SIP. http://www.softarmor.com/sipwg/teams http://www.softarmor.com/sipping/teams/ I intend to consider the following design teams terminated: SIP MIB SIP Security PacketCable DCS Convergence Call Control SIP-T Call Flow SIP-H.323 If somebody believes that any of these design teams is alive and, therefore, it should not be considered terminated, let me know. Otherwise, I will "execute" all of them. Thanks, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Feb 6 12:07:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26079 for ; Thu, 6 Feb 2003 12:07:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16HE9W16344 for sip-archive@odin.ietf.org; Thu, 6 Feb 2003 12:14:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16HDhp16319; Thu, 6 Feb 2003 12:13:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16HCGp16252 for ; Thu, 6 Feb 2003 12:12:16 -0500 Received: from auemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26036 for ; Thu, 6 Feb 2003 12:05:13 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h16H8pp27846; Thu, 6 Feb 2003 12:08:51 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA27148; Thu, 6 Feb 2003 11:08:49 -0600 (CST) Message-ID: <3E429686.5030505@lucent.com> Date: Thu, 06 Feb 2003 11:08:22 -0600 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories 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: James Ford CC: rajnishjain@lucent.com, sip@ietf.org, ecolasanto@lucent.com Subject: Re: [Sip] Impossible to use real persistent connection with sip References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit James Ford wrote: > An even simpler solution will be to add a parameter to the Via header > such as pc; (or pc=1 so that we will not have troubles with > Microsoft). Pc stands for persistent connection. We have debated this internally and arrived at the same preliminary conclusion to use the parameter extensions of the Via header. In this manner, no special header is needed. It also struck me while thinking about this problem that Rohan Mahy has an I-D on connection reuse in SIP (see: http://www.ietf.org/internet-drafts/draft-ietf-sipping-connect-reuse-reqs-00.txt) While it does not explicitly talk about persistent connections and peering relationships between proxies, it does discuss reusing an open connection for requests in either direction. > Guys, what do I need to do to move on this thing so that we will have > a new draft to solve the problem? I think we first need to identify if persistent connections falls in the category of problems solved by Rohan's I-D. If so, we pursue it in that I-D. If not, we can start a new I-D. > I think many implementations will be interested in using a real > persistent connection especially when TLS will be more deployed. I think the issue will be more about peering relationships between trusted entities where the trusted entities open and leave open for a long time the TLS socket. I don't think Rohan's I-D talks about those scenarios, but I have not read it in a long while and plan to do so in the next couple of days... Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Feb 6 12:42:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27515 for ; Thu, 6 Feb 2003 12:42:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16Hn0s18835 for sip-archive@odin.ietf.org; Thu, 6 Feb 2003 12:49:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16HmRp18797; Thu, 6 Feb 2003 12:48:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16Hl0p18749 for ; Thu, 6 Feb 2003 12:47:00 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27453; Thu, 6 Feb 2003 12:39:56 -0500 (EST) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h16HiPuA020272; Thu, 6 Feb 2003 12:44:25 -0500 (EST) Received: from cisco.com (klingle-ultra.cisco.com [64.102.93.47]) by dingdong.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABJ37277; Thu, 6 Feb 2003 12:43:30 -0500 (EST) Message-ID: <3E429EC3.C7FFDFB5@cisco.com> Date: Thu, 06 Feb 2003 12:43:31 -0500 From: Kevin Lingle X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: sip , sipping , Dean Willis , Jon Peterson , Rohan Mahy , Jean-Francois Mule , "Kavitha P." Subject: Re: [Sip] Design teams References: <3E423A4E.3C404641@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit gonzalo, please don't terminate the SIP MIB team. we are still here, but have been having a hard time devoting time to a new revision (-05) of the I-D. we are working on it and we are targetting the end of the month to publish. the previous version of the draft (-04) has expired. that version had passed last call in sip wg. we took a moment to consider updating the mib to comply with rfc3261 - as it was riddled with references to 2543 at that time - before forwarding to iesg. we decided it prudent and thus the need for -05. however, other project priorities and some personal issues with the team have made it difficult to devote time/resources to -05 of the draft, but i hope that we are moving forward at this point. kevin Gonzalo Camarillo wrote: > > Folks, > > I am updating the design team web pages for SIPPING and SIP. > http://www.softarmor.com/sipwg/teams > http://www.softarmor.com/sipping/teams/ > > I intend to consider the following design teams terminated: > > SIP MIB > SIP Security > PacketCable DCS Convergence > Call Control > SIP-T > Call Flow > SIP-H.323 > > If somebody believes that any of these design teams is alive and, > therefore, it should not be considered terminated, let me know. > Otherwise, I will "execute" all of them. > > Thanks, > > Gonzalo > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kevin R. Lingle 919.392.2029 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Feb 6 16:45:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05514 for ; Thu, 6 Feb 2003 16:45:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16Lq6v01642 for sip-archive@odin.ietf.org; Thu, 6 Feb 2003 16:52:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16LpOp01616; Thu, 6 Feb 2003 16:51:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16Lntp01561 for ; Thu, 6 Feb 2003 16:49:55 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05382 for ; Thu, 6 Feb 2003 16:42:47 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h16LjvJ15033; Thu, 6 Feb 2003 21:45:58 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Feb 2003 16:46:13 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214D9F@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Kevin Lingle'" , Gonzalo Camarillo Cc: sip , Dean Willis , Rohan Mahy , Jean-Francois Mule , "Kavitha P." Subject: RE: [Sip] Design teams Date: Thu, 6 Feb 2003 16:46:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , We recognize that there are authors still moving forward on this document, but I think it is a separate question whether or not we should consider this effort to be a design team. There are numerous groups of authors working on documents in this group, but design team status represents something a little different. Considering the maturity of this document, I hope we past the design team stage (as far as I understand the concept of a design team in RFC2418). Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Kevin Lingle [mailto:klingle@cisco.com] > Sent: Thursday, February 06, 2003 9:44 AM > To: Gonzalo Camarillo > Cc: sip; sipping; Dean Willis; Jon Peterson; Rohan Mahy; Jean-Francois > Mule; Kavitha P. > Subject: Re: [Sip] Design teams > > > gonzalo, > > please don't terminate the SIP MIB team. > we are still here, but have been having > a hard time devoting time to a new revision (-05) > of the I-D. we are working on it and > we are targetting the end of the month to publish. > > the previous version of the draft (-04) has > expired. that version had passed last call in sip wg. > we took a moment to consider updating the mib to > comply with rfc3261 - as it was riddled with references > to 2543 at that time - before forwarding to iesg. > we decided it prudent and thus the need for -05. > however, other project priorities and some personal > issues with the team have made it difficult to devote > time/resources to -05 of the draft, but i hope that > we are moving forward at this point. > > kevin > Gonzalo Camarillo wrote: > > > > Folks, > > > > I am updating the design team web pages for SIPPING and SIP. > > http://www.softarmor.com/sipwg/teams > > http://www.softarmor.com/sipping/teams/ > > > > I intend to consider the following design teams terminated: > > > > SIP MIB > > SIP Security > > PacketCable DCS Convergence > > Call Control > > SIP-T > > Call Flow > > SIP-H.323 > > > > If somebody believes that any of these design teams is alive and, > > therefore, it should not be considered terminated, let me know. > > Otherwise, I will "execute" all of them. > > > > Thanks, > > > > Gonzalo > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > -- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-=-=-=-= > Kevin R. Lingle 919.392.2029 > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-=-=-=-= > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Feb 6 22:35:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14743 for ; Thu, 6 Feb 2003 22:35:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h173gdf22026 for sip-archive@odin.ietf.org; Thu, 6 Feb 2003 22:42:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h173g2p22004; Thu, 6 Feb 2003 22:42:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h173aKp21145 for ; Thu, 6 Feb 2003 22:36:20 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14252 for ; Thu, 6 Feb 2003 22:29:05 -0500 (EST) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h173XXjO029784; Thu, 6 Feb 2003 22:33:33 -0500 (EST) Received: from cisco.com (klingle-ultra.cisco.com [64.102.93.47]) by dingdong.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABJ53260; Thu, 6 Feb 2003 22:32:37 -0500 (EST) Message-ID: <3E4328D5.F4B0A336@cisco.com> Date: Thu, 06 Feb 2003 22:32:37 -0500 From: Kevin Lingle X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Peterson, Jon" CC: Gonzalo Camarillo , sip , Dean Willis , Rohan Mahy , Jean-Francois Mule , "Kavitha P." Subject: Re: [Sip] Design teams References: <15A2739B7DAA624D8091C65981D7DA8101214D9F@stntexch2.va.neustar.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit jon, ok. as long as termination of the team doesn't imply stoppage of any work underway by the team. kevin "Peterson, Jon" wrote: > > We recognize that there are authors still moving forward on this document, > but I think it is a separate question whether or not we should consider this > effort to be a design team. There are numerous groups of authors working on > documents in this group, but design team status represents something a > little different. Considering the maturity of this document, I hope we past > the design team stage (as far as I understand the concept of a design team > in RFC2418). > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Kevin Lingle [mailto:klingle@cisco.com] > > Sent: Thursday, February 06, 2003 9:44 AM > > To: Gonzalo Camarillo > > Cc: sip; sipping; Dean Willis; Jon Peterson; Rohan Mahy; Jean-Francois > > Mule; Kavitha P. > > Subject: Re: [Sip] Design teams > > > > > > gonzalo, > > > > please don't terminate the SIP MIB team. > > we are still here, but have been having > > a hard time devoting time to a new revision (-05) > > of the I-D. we are working on it and > > we are targetting the end of the month to publish. > > > > the previous version of the draft (-04) has > > expired. that version had passed last call in sip wg. > > we took a moment to consider updating the mib to > > comply with rfc3261 - as it was riddled with references > > to 2543 at that time - before forwarding to iesg. > > we decided it prudent and thus the need for -05. > > however, other project priorities and some personal > > issues with the team have made it difficult to devote > > time/resources to -05 of the draft, but i hope that > > we are moving forward at this point. > > > > kevin > > Gonzalo Camarillo wrote: > > > > > > Folks, > > > > > > I am updating the design team web pages for SIPPING and SIP. > > > http://www.softarmor.com/sipwg/teams > > > http://www.softarmor.com/sipping/teams/ > > > > > > I intend to consider the following design teams terminated: > > > > > > SIP MIB > > > SIP Security > > > PacketCable DCS Convergence > > > Call Control > > > SIP-T > > > Call Flow > > > SIP-H.323 > > > > > > If somebody believes that any of these design teams is alive and, > > > therefore, it should not be considered terminated, let me know. > > > Otherwise, I will "execute" all of them. > > > > > > Thanks, > > > > > > Gonzalo > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > -- > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > =-=-=-=-= > > Kevin R. Lingle 919.392.2029 > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > =-=-=-=-= > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kevin R. Lingle 919.392.2029 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Feb 7 08:29:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10145 for ; Fri, 7 Feb 2003 08:29:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17Dal703020 for sip-archive@odin.ietf.org; Fri, 7 Feb 2003 08:36:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17DaMp03010; Fri, 7 Feb 2003 08:36:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14LwoJ26648 for ; Tue, 4 Feb 2003 16:58:50 -0500 Received: from crufty.research.bell-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05495 for ; Tue, 4 Feb 2003 16:52:40 -0500 (EST) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id h14LtmLI090889; Tue, 4 Feb 2003 16:55:48 -0500 (EST) Received: from mcs.research.bell-labs.com (mcs.research.bell-labs.com [135.104.32.15]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id h14LteI76270; Tue, 4 Feb 2003 16:55:40 -0500 (EST) Received: from lucent.com (bass.research.bell-labs.com [135.104.32.232]) by mcs.research.bell-labs.com (8.9.3/8.8.8) with ESMTP id QAA2329187; Tue, 4 Feb 2003 16:55:39 -0500 (EST) Message-ID: <3E4036DB.1CEC2558@lucent.com> Date: Tue, 04 Feb 2003 16:55:39 -0500 From: Qiru Zhou Reply-To: qzhou@research.bell-labs.com Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,zh-CN,zh-TW MIME-Version: 1.0 To: Steve Silverman CC: Alex Agranov , "'David R. Oran'" , sip@ietf.org Subject: Re: [Sip] Silence Suppression in SDP for VoIP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit In the following cases, there are needs to to understand the far end device attributes: 1. A device connect to a non human device, such as a speech recognition receiver. In this case, the non human device may not work since it may less tolerant than human. The current automatic detection algorithms may not be reliable enough to cover all situations. 2. The channel is used to pass non voice signals (such as fax) and in-band control signals. In this case, the non human device may not work due to the adaptation algorithm signal distortion. 3. A device connect to a gateway with network (far end) echo canceller/noise suppresser. In this case, the communication still work but may have degraded performance due to the incorrect estimation of the echo canceller/noise suppresser parameters. It will be desirable to exchange device attribute information such as echo canceller/noise suppresser at the session setup time than guess them remotely. It looks natural to me to use SDP "ecan" and "silenceSupp" defined in RFC 3108 in VoIP and converged networks. -- Qiru Zhou Subject: RE: [Sip] Silence Suppression in SDP for VoIP Date: Tue, 4 Feb 2003 13:01:28 -0500 From: "Steve Silverman" To: "Alex Agranov" , "'David R. Oran'" , I would have thought that if one side is using silence suppression, the other side needs to understand this. If true, how is the use of this communicated? Steve Silverman -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Alex Agranov Sent: Tuesday, February 04, 2003 12:30 PM To: 'David R. Oran'; 'sip@ietf.org' Subject: RE: [Sip] Silence Suppression in SDP for VoIP Hi, I see your point. But if this is right, then why does H323 protocol support silence suppression and echo cancellation parameters? On the other hand, in case of fax fallback to G711 coder (if T38 is not supported), there is a need to specify to remote device that "echo cancelation is ON, and silence suppression is OFF". AFAIK fax will not be properly passed if silence suppression is not turned off. And this, I beleive, is the reason why draft-ietf-sipping-realtimefax-00.txt makes use of "ecan" and "silenceSupp" SDP attributes. Also there is a following sentence in H323-SIP interworking draft : "A fmtp SDP attribute for silence suppression SHOULD be defined if silence suppression is on." Is it not valid any more? Best regards, Alex Agranov > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Tuesday, February 04, 2003 5:53 PM > To: Alex Agranov; 'sip@ietf.org' > Subject: Re: [Sip] Silence Suppression in SDP for VoIP > > > There are no such parameters in SDP nor SIP because both of these are > algorithm options for one end of a media stream. The source > of the stream > does these by itself and therefore they have no end-to-end > significance. As > a consequence there is no need for the receiver to know > anything about Vad > or ecan parameters of the transmitter, or vice versa. > > The reason these exist in MGCP and Megaco is because those are device > control protocols intended for comand and control of an endpoint, as > opposed to peer signaling protocols like SIP. > > --On Tuesday, February 04, 2003 12:24 PM +0200 Alex Agranov > wrote: > > > > > Hi, > > > > I tried to ask this question in sip-implementors maillist but nobody > > could answer it there... > > > > What is the proper way to indicate Silence Suppression and Echo > > Cancelation coder parameters in SDP? In MGCP these parameters are > > passed in LCO element, but for SIP Offer/Answer model these > parameters > > should be passed in SDP. Right? > > > > There is RFC3108 that defines "ecan" and "silenceSupp" > attributes, but it > > applies to VoATM. Is it applicable to VoIP too? > > > > Some late drafts, e.g. > draft-ietf-sipping-realtimefax-00.txt, seem to > > assume RFC3108 attributes are valid for VoIP. Is this correct? > > > > Best regards, > > Alex Agranov > > --- > > Senior Software Engineer > > COMGATES Ltd. > > 15 Hagalim Avenue > > Herzliya, 46725 > > Israel > > Tel. +972.9.950.0404, Ext: 228 > > Fax. +972.9.950.0385 > > Mobile. +972.54.928435 > > ------------------------ > David R. Oran > Cisco Systems > 7 Ladyslipper Lane > Acton, MA 01720 > Office: +1 978 264 2048 > VoIP: +1 408 571 4576 > Email: oran@cisco.com > ============================================================================== Qiru Zhou (http://www.bell-labs.com/org/1133/) Converged Network and Service Research Bell Laboratories, Lucent Technologies 600 Mountain Avenue, 2D428, Murray Hill, NJ 07974, USA tel +1 908 582 4562 | fax +1 908 582 7308 | qzhou@research.bell-labs.com ============================================================================== _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Feb 7 08:32:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10381 for ; Fri, 7 Feb 2003 08:32:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17Dddv03794 for sip-archive@odin.ietf.org; Fri, 7 Feb 2003 08:39:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17DdKp03783; Fri, 7 Feb 2003 08:39:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16DsIp00909 for ; Thu, 6 Feb 2003 08:54:18 -0500 Received: from hoemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17728 for ; Thu, 6 Feb 2003 08:47:18 -0500 (EST) Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h16DovX03058 for ; Thu, 6 Feb 2003 08:50:57 -0500 (EST) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Feb 2003 08:50:57 -0500 Message-ID: From: "Colasanto, Eric (Eric)" To: "'James Ford'" , "Jain, Rajnish (Rajnish)" , sip@ietf.org Cc: "Colasanto, Eric (Eric)" , "Gurbani, Vijay K (Vijay)" Subject: RE: [Sip] Impossible to use real persistent connection with sip Date: Thu, 6 Feb 2003 08:50:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I think a new parameter will work well to specify the creation of a persistent socket. ;pc=0 when the socket is NOT persistent, or don't include this parameter. ;pc=1 when the socket is persistent. After setting up this socket will all subsequent SIP messages be required to have the pc=1 to utilize the persistent socket. Or will any SIP message destined for an endpoint supported by a persistent socket utilize the socket, reguardless of the presence of the pc parameter? Then there is the issue of when/how does one destroy the persistent connection(s). Should this be left to the application/user which is controlling the generation/consumption of the SIP messages? Eric J. Colasanto (508) 862-3386 -----Original Message----- From: James Ford [mailto:james_s_ford@hotmail.com] Sent: Thursday, February 06, 2003 2:17 AM To: rajnishjain@lucent.com; sip@ietf.org Cc: ecolasanto@lucent.com; vkg@ih2mail.ih.lucent.com Subject: RE: [Sip] Impossible to use real persistent connection with sip An even simpler solution will be to add a parameter to the Via header such as pc; (or pc=1 so that we will not have troubles with Microsoft). Pc stands for persistent connection. Guys, what do I need to do to move on this thing so that we will have a new draft to solve the problem? I think many implementations will be interested in using a real persistent connection especially when TLS will be more deployed. Thanks, James S. Ford >From: "Jain, Rajnish (Rajnish)" >To: "'James Ford'" , sip@ietf.org >CC: "Colasanto, Eric (Eric)" , "Gurbani, Vijay K >(Vijay)" >Subject: RE: [Sip] Impossible to use real persistent connection with sip >Date: Tue, 4 Feb 2003 07:20:22 -0500 > >James, > >The option of adding a SIP header field seems to be more flexible. That >way, >when that header field is not present, the persistent connection is jointly >owned by both UAs. And at their discretion they can close it. This allows >us >to be backward compatible while enabling a new capability. > >Thanks, >Rajnish > >-----Original Message----- >From: James Ford [mailto:james_s_ford@hotmail.com] >Sent: Tuesday, February 04, 2003 2:45 AM >To: sip@ietf.org >Subject: [Sip] Impossible to use real persistent connection with sip > > >Hi, >The SIP standard does not specify who is responsible for closing TCP >connections. This means that both client and server transaction can close >the connection. A reasonable implementation for a transaction will be to >close any open connection (incoming or outgoing) before termination in >order >to free unused resources. >This behavior actually makes it impossible to count on a persistent >connection. >For example, A UA that is always talking to the same destination using TLS >will want to use one connection per day. This is impossible since the >server >might close the connection as soon as the first transaction terminates. > >I can see several ways to solve this problem: >1. Specify that the UA that opened the connection will be responsible for >closing it. >2. Add a header to sip requests that asks the server not to close the >connection by itself. > >What do you think? >James S Ford. > > > > > > >_________________________________________________________________ >Add photos to your e-mail with MSN 8. Get 2 months FREE*. >http://join.msn.com/?page=features/featuredemail > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Feb 7 11:04:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14235 for ; Fri, 7 Feb 2003 11:04:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17GB7012821 for sip-archive@odin.ietf.org; Fri, 7 Feb 2003 11:11:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17GAgp12797; Fri, 7 Feb 2003 11:10:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17G9Rp12736 for ; Fri, 7 Feb 2003 11:09:27 -0500 Received: from web41415.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14190 for ; Fri, 7 Feb 2003 11:01:57 -0500 (EST) Message-ID: <20030207160535.67486.qmail@web41415.mail.yahoo.com> Received: from [216.36.69.17] by web41415.mail.yahoo.com via HTTP; Fri, 07 Feb 2003 08:05:35 PST Date: Fri, 7 Feb 2003 08:05:35 -0800 (PST) From: Sophia Scoggins To: SIP MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Sip] Seek for SIP free or cheap stack or experienced SIP SE Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , If this is not the right list to ask this question, please forgive me. Can any one point me where to find SIP free stack or a SIP stack that is less than $50K? If you have experience in writing SIP stack from scratch and is living in the Bay area and is looking for Software Engineer contractor job for about 6 months, the small startup company that I am with has the opportunity. It is VoIP/DSL with SIP. Strong C language is required. Please send your reply to me directly sc_scoggins@yahoo.com, rather than to the list. Thanks in advance. Regards, Sophia __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Feb 7 11:09:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14397 for ; Fri, 7 Feb 2003 11:09:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17GGaJ13068 for sip-archive@odin.ietf.org; Fri, 7 Feb 2003 11:16:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17GGBp13056; Fri, 7 Feb 2003 11:16:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17GFrp13024 for ; Fri, 7 Feb 2003 11:15:53 -0500 Received: from cbibipnt05.hc.bt.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14377 for ; Fri, 7 Feb 2003 11:08:23 -0500 (EST) From: maria.a.cuevas@bt.com Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Fri, 7 Feb 2003 16:12:19 -0000 Message-ID: <7497DCA1C240C042B28F6657ADFD8E095383F7@i2km11-ukbr.domain1.systemhost.net> To: sip@ietf.org Date: Fri, 7 Feb 2003 16:11:49 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Question about Q-SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Dear all, I have a couple of questions regarding the internet draft: "SIP extensions for QoS support" (draft-veltri-sip-qsip-01.txt) and I was wondering if somebody in the mailing list could answer them. Question 1: I am trying to understand the requirements for a UA to implement the Q-SIP "QoS assured" mode of operation. I know that the draft explicitly says that no enhancements/modifications are needed in the SIP UA applications to implement these mechanisms. But it also mentions (Appendix A) that, a UA must be "preconfigured" to rely on the Q-SIP proxy for QoS handling. I would like to understand what that "pre-configuration" means in terms of the UA's SIP behaviour. Is there any difference in the way that an UA interprets the precondition parameters for the Q-SIP QoS-assured mode and the mechanisms described in RFC 3312 ? In the Q-SIP example A.1.1, the UA seems to interpret the curr:qos e2e sendrecv in the 183 message (SDP 4) as the result of the reservation for its own side of the network (UA(A)) (because it is assuming that the Q-SIP server reserved it on its behalf) and it responds with an UPDATE to confirm to the other end that the reservation in UA(A)'s send direction was successful (confirmation was requested by the UA(B) in SDP 2, 3 and 4 : conf:recv). But according to RFC 3312, any curr: header in a message recevied should be interpreted as the current QoS reserved by the other end of the network. It seems to me that the two interpretations of SDP preconditions at the UA are different. I would appreciate if somebody could comment on this, maybe I am wrong, the two interpretations are exactly the same and I just can't see it. Question 2. My second question is much shorter: Is the QoS-Info header needed in the scenario described in A.1.1 ? It seems to me that the information carried in the SDP is enough to convey the QoS mechanisms required when using preconditions and unidirectional QoS reservation (using RSVP end-to-end for example) for e2e bidirectional reservation. Thank you very much in advance Regards Maria Maria Cuevas BTexact Technologies i a trademark of British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. Activity and use of the British Telecommunications plc E-mail system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Feb 7 17:15:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23224 for ; Fri, 7 Feb 2003 17:15:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17MMlN02501 for sip-archive@odin.ietf.org; Fri, 7 Feb 2003 17:22:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17MMLp02488; Fri, 7 Feb 2003 17:22:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17MKqp02447 for ; Fri, 7 Feb 2003 17:20:52 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23168 for ; Fri, 7 Feb 2003 17:13:14 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h17MGpK05649 for ; Fri, 7 Feb 2003 16:16:51 -0600 From: Robert Sparks To: sip@ietf.org Content-Type: text/plain Message-Id: <1044656013.915.42.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 07 Feb 2003 16:13:34 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] non-INVITE draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I've just submitted a draft that explores some of the non-INVITE transaction issues we've discovered over time (relating to such things as provisional responses, timeout behavior, and even CANCEL). Until it appears in the archives, you can retrieve it from http://www.nostrum.com/~rjsparks/draft-sparks-sip-noninvite-00.txt RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Feb 10 02:22:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27980 for ; Mon, 10 Feb 2003 02:22:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1A7UgL26845 for sip-archive@odin.ietf.org; Mon, 10 Feb 2003 02:30:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1A7U5p26824; Mon, 10 Feb 2003 02:30:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1A7Qhp26733 for ; Mon, 10 Feb 2003 02:26:43 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27877 for ; Mon, 10 Feb 2003 02:17:54 -0500 (EST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h1A7LZap009545; Sun, 9 Feb 2003 23:21:35 -0800 (PST) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id ABG64134; Sun, 9 Feb 2003 23:21:34 -0800 (PST) From: "Cullen Jennings" To: "Colasanto, Eric \(Eric\)" , "'James Ford'" , "Jain, Rajnish \(Rajnish\)" , Cc: "Gurbani, Vijay K \(Vijay\)" Subject: RE: [Sip] Impossible to use real persistent connection with sip Date: Sun, 9 Feb 2003 23:27:41 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Just to get a little more precise about this ... what does persistence mean? For the length of the transaction? For the dialog? As long as the registration is valid? Until some box crashes? Until the world moves to IPv6. I think this persistent connection question is intertwined with the ideas of how SIP will do reliability. It's all fine and dandy to add a parameter allows box A to tell box B that it is not allowed to crash but it is a little harder for B to make sure it correctly implements this. Even if B is capable of this sort of HA, it might want to close the connection for administrative reasons such as getting new keying material on a TLS connection. I would be very happy to see some good thought on when devices should close a TCP socket - I think that figuring out a good algorithm and understanding the large scale consequences is going to be surprisingly complicated. Cullen > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > Colasanto, Eric (Eric) > Sent: Thursday, February 06, 2003 5:51 AM > To: 'James Ford'; Jain, Rajnish (Rajnish); sip@ietf.org > Cc: Colasanto, Eric (Eric); Gurbani, Vijay K (Vijay) > Subject: RE: [Sip] Impossible to use real persistent connection with sip > > > I think a new parameter will work well to specify the creation of > a persistent socket. > ;pc=0 when the socket is NOT persistent, or don't include this parameter. > ;pc=1 when the socket is persistent. > > After setting up this socket will all subsequent SIP messages be > required to have the pc=1 > to utilize the persistent socket. Or will any SIP message > destined for an endpoint supported by a > persistent socket utilize the socket, reguardless of the presence > of the pc parameter? > > Then there is the issue of when/how does one destroy the > persistent connection(s). > Should this be left to the application/user which is controlling > the generation/consumption of > the SIP messages? > > > Eric J. Colasanto > (508) 862-3386 > > > > -----Original Message----- > From: James Ford [mailto:james_s_ford@hotmail.com] > Sent: Thursday, February 06, 2003 2:17 AM > To: rajnishjain@lucent.com; sip@ietf.org > Cc: ecolasanto@lucent.com; vkg@ih2mail.ih.lucent.com > Subject: RE: [Sip] Impossible to use real persistent connection with sip > > > An even simpler solution will be to add a parameter to the Via > header such > as > pc; (or pc=1 so that we will not have troubles with Microsoft). Pc stands > for persistent connection. > > Guys, what do I need to do to move on this thing so that we will > have a new > draft to solve the problem? > I think many implementations will be interested in using a real > persistent > connection especially when TLS will be more deployed. > > Thanks, > James S. Ford > > > >From: "Jain, Rajnish (Rajnish)" > >To: "'James Ford'" , sip@ietf.org > >CC: "Colasanto, Eric (Eric)" , > "Gurbani, Vijay K > >(Vijay)" > >Subject: RE: [Sip] Impossible to use real persistent connection with sip > >Date: Tue, 4 Feb 2003 07:20:22 -0500 > > > >James, > > > >The option of adding a SIP header field seems to be more flexible. That > >way, > >when that header field is not present, the persistent connection > is jointly > >owned by both UAs. And at their discretion they can close it. > This allows > >us > >to be backward compatible while enabling a new capability. > > > >Thanks, > >Rajnish > > > >-----Original Message----- > >From: James Ford [mailto:james_s_ford@hotmail.com] > >Sent: Tuesday, February 04, 2003 2:45 AM > >To: sip@ietf.org > >Subject: [Sip] Impossible to use real persistent connection with sip > > > > > >Hi, > >The SIP standard does not specify who is responsible for closing TCP > >connections. This means that both client and server transaction can close > >the connection. A reasonable implementation for a transaction will be to > >close any open connection (incoming or outgoing) before termination in > >order > >to free unused resources. > >This behavior actually makes it impossible to count on a persistent > >connection. > >For example, A UA that is always talking to the same destination > using TLS > >will want to use one connection per day. This is impossible since the > >server > >might close the connection as soon as the first transaction terminates. > > > >I can see several ways to solve this problem: > >1. Specify that the UA that opened the connection will be > responsible for > >closing it. > >2. Add a header to sip requests that asks the server not to close the > >connection by itself. > > > >What do you think? > >James S Ford. > > > > > > > > > > > > > >_________________________________________________________________ > >Add photos to your e-mail with MSN 8. Get 2 months FREE*. > >http://join.msn.com/?page=features/featuredemail > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol > >Use sip-implementors@cs.columbia.edu for questions on current sip > >Use sipping@ietf.org for new developments on the application of sip > > > _________________________________________________________________ > Protect your PC - get McAfee.com VirusScan Online > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Feb 10 03:21:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29870 for ; Mon, 10 Feb 2003 03:21:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1A8U2b30826 for sip-archive@odin.ietf.org; Mon, 10 Feb 2003 03:30:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1A8Tgp30806; Mon, 10 Feb 2003 03:29:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1A8Sdp30778 for ; Mon, 10 Feb 2003 03:28:39 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29771 for ; Mon, 10 Feb 2003 03:19:49 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1A8NJAv013363; Mon, 10 Feb 2003 09:23:20 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id DY54K581; Mon, 10 Feb 2003 09:23:19 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h1A8NJH7018259; Mon, 10 Feb 2003 10:23:19 +0200 (EET) Message-ID: <3E476176.A07B1BED@lmf.ericsson.se> Date: Mon, 10 Feb 2003 10:23:18 +0200 X-Sybari-Trust: 0c2501d4 9ffcebbb 7a95d2f4 00000138 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Kevin Lingle CC: "Peterson, Jon" , sip , Dean Willis , Rohan Mahy , Jean-Francois Mule , "Kavitha P." Subject: Re: [Sip] Design teams References: <15A2739B7DAA624D8091C65981D7DA8101214D9F@stntexch2.va.neustar.com> <3E4328D5.F4B0A336@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kevin, as Jon pointed out, the termination of the SIP-MIB design team will *not* imply that you have to stop working. It is only an administrative issue. I will remove the web page of the SIP-MIB team now. Thanks for the update, Gonzalo Kevin Lingle wrote: > > jon, > > ok. as long as termination of the team doesn't imply stoppage > of any work underway by the team. > > kevin > "Peterson, Jon" wrote: > > > > We recognize that there are authors still moving forward on this document, > > but I think it is a separate question whether or not we should consider this > > effort to be a design team. There are numerous groups of authors working on > > documents in this group, but design team status represents something a > > little different. Considering the maturity of this document, I hope we past > > the design team stage (as far as I understand the concept of a design team > > in RFC2418). > > > > Jon Peterson > > NeuStar, Inc. > > > > > -----Original Message----- > > > From: Kevin Lingle [mailto:klingle@cisco.com] > > > Sent: Thursday, February 06, 2003 9:44 AM > > > To: Gonzalo Camarillo > > > Cc: sip; sipping; Dean Willis; Jon Peterson; Rohan Mahy; Jean-Francois > > > Mule; Kavitha P. > > > Subject: Re: [Sip] Design teams > > > > > > > > > gonzalo, > > > > > > please don't terminate the SIP MIB team. > > > we are still here, but have been having > > > a hard time devoting time to a new revision (-05) > > > of the I-D. we are working on it and > > > we are targetting the end of the month to publish. > > > > > > the previous version of the draft (-04) has > > > expired. that version had passed last call in sip wg. > > > we took a moment to consider updating the mib to > > > comply with rfc3261 - as it was riddled with references > > > to 2543 at that time - before forwarding to iesg. > > > we decided it prudent and thus the need for -05. > > > however, other project priorities and some personal > > > issues with the team have made it difficult to devote > > > time/resources to -05 of the draft, but i hope that > > > we are moving forward at this point. > > > > > > kevin > > > Gonzalo Camarillo wrote: > > > > > > > > Folks, > > > > > > > > I am updating the design team web pages for SIPPING and SIP. > > > > http://www.softarmor.com/sipwg/teams > > > > http://www.softarmor.com/sipping/teams/ > > > > > > > > I intend to consider the following design teams terminated: > > > > > > > > SIP MIB > > > > SIP Security > > > > PacketCable DCS Convergence > > > > Call Control > > > > SIP-T > > > > Call Flow > > > > SIP-H.323 > > > > > > > > If somebody believes that any of these design teams is alive and, > > > > therefore, it should not be considered terminated, let me know. > > > > Otherwise, I will "execute" all of them. > > > > > > > > Thanks, > > > > > > > > Gonzalo > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > -- > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > > =-=-=-=-= > > > Kevin R. Lingle 919.392.2029 > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > > =-=-=-=-= > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > -- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Kevin R. Lingle 919.392.2029 > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -- 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Feb 10 04:34:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01724 for ; Mon, 10 Feb 2003 04:34:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1A9gjI02795 for sip-archive@odin.ietf.org; Mon, 10 Feb 2003 04:42:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1A9gGp02766; Mon, 10 Feb 2003 04:42:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1A9bYp02625 for ; Mon, 10 Feb 2003 04:37:34 -0500 Received: from nt-mail.RADVISION.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01569 for ; Mon, 10 Feb 2003 04:28:42 -0500 (EST) Received: by nt-mail.tlv.radvision.com with Internet Mail Service (5.5.2653.19) id <1B8SDHPG>; Mon, 10 Feb 2003 11:31:18 +0200 Message-ID: From: Sarit Galanos Mekler To: "'Cullen Jennings'" , "Colasanto, Eric (Eric)" , "'James Ford'" , "Jain, Rajnish (Rajnish)" , sip@ietf.org Cc: "Gurbani, Vijay K (Vijay)" Subject: RE: [Sip] Impossible to use real persistent connection with sip Date: Mon, 10 Feb 2003 11:31:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , First I would like to say that I think that the pc=1 is a good choice. To my opinion adding the pc=1 to the via header is only a recommendation to the server to keep the connection open. Servers that don't understand pc or don't want to keep the connection open are more then welcome to close it. A server can also decide that it wishes to keep the connection open only if it is actually being used. An implementation can for example, set a timer on server connections. When ever a message is received/sent on the connection the timer is reset. when the timer expires the server closes the connection. The persistency level (dialog / transaction) if for the specific application to decide. For dialog persistency the application will have to keep the connection open for the duration of the call. Using the pc=1 parameter will give a good chance for using connections for more then one transaction. An option that today (almost) does not exist. Regards, Sarit Galanos. -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Monday, February 10, 2003 9:28 AM To: Colasanto, Eric (Eric); 'James Ford'; Jain, Rajnish (Rajnish); sip@ietf.org Cc: Gurbani, Vijay K (Vijay) Subject: RE: [Sip] Impossible to use real persistent connection with sip Just to get a little more precise about this ... what does persistence mean? For the length of the transaction? For the dialog? As long as the registration is valid? Until some box crashes? Until the world moves to IPv6. I think this persistent connection question is intertwined with the ideas of how SIP will do reliability. It's all fine and dandy to add a parameter allows box A to tell box B that it is not allowed to crash but it is a little harder for B to make sure it correctly implements this. Even if B is capable of this sort of HA, it might want to close the connection for administrative reasons such as getting new keying material on a TLS connection. I would be very happy to see some good thought on when devices should close a TCP socket - I think that figuring out a good algorithm and understanding the large scale consequences is going to be surprisingly complicated. Cullen > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > Colasanto, Eric (Eric) > Sent: Thursday, February 06, 2003 5:51 AM > To: 'James Ford'; Jain, Rajnish (Rajnish); sip@ietf.org > Cc: Colasanto, Eric (Eric); Gurbani, Vijay K (Vijay) > Subject: RE: [Sip] Impossible to use real persistent connection with sip > > > I think a new parameter will work well to specify the creation of > a persistent socket. > ;pc=0 when the socket is NOT persistent, or don't include this parameter. > ;pc=1 when the socket is persistent. > > After setting up this socket will all subsequent SIP messages be > required to have the pc=1 > to utilize the persistent socket. Or will any SIP message > destined for an endpoint supported by a > persistent socket utilize the socket, reguardless of the presence > of the pc parameter? > > Then there is the issue of when/how does one destroy the > persistent connection(s). > Should this be left to the application/user which is controlling > the generation/consumption of > the SIP messages? > > > Eric J. Colasanto > (508) 862-3386 > > > > -----Original Message----- > From: James Ford [mailto:james_s_ford@hotmail.com] > Sent: Thursday, February 06, 2003 2:17 AM > To: rajnishjain@lucent.com; sip@ietf.org > Cc: ecolasanto@lucent.com; vkg@ih2mail.ih.lucent.com > Subject: RE: [Sip] Impossible to use real persistent connection with sip > > > An even simpler solution will be to add a parameter to the Via > header such > as > pc; (or pc=1 so that we will not have troubles with Microsoft). Pc stands > for persistent connection. > > Guys, what do I need to do to move on this thing so that we will > have a new > draft to solve the problem? > I think many implementations will be interested in using a real > persistent > connection especially when TLS will be more deployed. > > Thanks, > James S. Ford > > > >From: "Jain, Rajnish (Rajnish)" > >To: "'James Ford'" , sip@ietf.org > >CC: "Colasanto, Eric (Eric)" , > "Gurbani, Vijay K > >(Vijay)" > >Subject: RE: [Sip] Impossible to use real persistent connection with sip > >Date: Tue, 4 Feb 2003 07:20:22 -0500 > > > >James, > > > >The option of adding a SIP header field seems to be more flexible. That > >way, > >when that header field is not present, the persistent connection > is jointly > >owned by both UAs. And at their discretion they can close it. > This allows > >us > >to be backward compatible while enabling a new capability. > > > >Thanks, > >Rajnish > > > >-----Original Message----- > >From: James Ford [mailto:james_s_ford@hotmail.com] > >Sent: Tuesday, February 04, 2003 2:45 AM > >To: sip@ietf.org > >Subject: [Sip] Impossible to use real persistent connection with sip > > > > > >Hi, > >The SIP standard does not specify who is responsible for closing TCP > >connections. This means that both client and server transaction can close > >the connection. A reasonable implementation for a transaction will be to > >close any open connection (incoming or outgoing) before termination in > >order > >to free unused resources. > >This behavior actually makes it impossible to count on a persistent > >connection. > >For example, A UA that is always talking to the same destination > using TLS > >will want to use one connection per day. This is impossible since the > >server > >might close the connection as soon as the first transaction terminates. > > > >I can see several ways to solve this problem: > >1. Specify that the UA that opened the connection will be > responsible for > >closing it. > >2. Add a header to sip requests that asks the server not to close the > >connection by itself. > > > >What do you think? > >James S Ford. > > > > > > > > > > > > > >_________________________________________________________________ > >Add photos to your e-mail with MSN 8. Get 2 months FREE*. > >http://join.msn.com/?page=features/featuredemail > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol > >Use sip-implementors@cs.columbia.edu for questions on current sip > >Use sipping@ietf.org for new developments on the application of sip > > > _________________________________________________________________ > Protect your PC - get McAfee.com VirusScan Online > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Feb 10 10:30:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12279 for ; Mon, 10 Feb 2003 10:30:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1AFcdm22864 for sip-archive@odin.ietf.org; Mon, 10 Feb 2003 10:38:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AFc4p22836; Mon, 10 Feb 2003 10:38:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AFacp22131 for ; Mon, 10 Feb 2003 10:36:38 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12157 for ; Mon, 10 Feb 2003 10:27:40 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1AFY7m27523 for ; Mon, 10 Feb 2003 17:34:07 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 10 Feb 2003 17:31:21 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Feb 2003 17:31:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 10 Feb 2003 17:31:19 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE725B@esebe019.ntc.nokia.com> Thread-Topic: Proxy inserting Record-Route Thread-Index: AcLRGXEw8F9tlOnDQwWuOzHNf+Ysuw== To: X-OriginalArrivalTime: 10 Feb 2003 15:31:21.0145 (UTC) FILETIME=[76734A90:01C2D119] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1AFacp22132 Subject: [Sip] Proxy inserting Record-Route Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit RFC3261 says: "If this proxy wishes to remain on the path of future requests in a dialog created by this request (assuming the request creates a dialog), it MUST insert a Record-Route header field value into the copy before any existing Record-Route header field values, even if a Route header field is already present." It fails to mention where the proxy should adds that record-route header. On top or bottom of the existing record-route headers. I deduce that it should add it on top since a UAS must copy record-route headers to a response reserving the order. Also a UAC creating a route-set uses these record-route headers taking them in reverse order. Did I miss it in the spec? Regards, Hisham _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Feb 10 11:20:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14188 for ; Mon, 10 Feb 2003 11:20:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1AGT2I25629 for sip-archive@odin.ietf.org; Mon, 10 Feb 2003 11:29:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AGSXp25596; Mon, 10 Feb 2003 11:28:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AGROp25556 for ; Mon, 10 Feb 2003 11:27:24 -0500 Received: from auemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14124 for ; Mon, 10 Feb 2003 11:18:24 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1AGLu525588; Mon, 10 Feb 2003 11:21:56 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA00123; Mon, 10 Feb 2003 10:21:55 -0600 (CST) Message-ID: <3E47D17F.8010904@lucent.com> Date: Mon, 10 Feb 2003 10:21:19 -0600 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: "Colasanto, Eric \(Eric\)" , "'James Ford'" , "Jain, Rajnish \(Rajnish\)" , sip@ietf.org, Sarit Galanos Mekler Subject: Re: [Sip] Impossible to use real persistent connection with sip References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > Just to get a little more precise about this ... what does persistence > mean? For the length of the transaction? For the dialog? As long as > the registration is valid? Until some box crashes? Until the world moves > to IPv6. Hi Cullen: Yes, we've grappled with that as well. Clearly, to get most bang for the buck, the persistent connection lives beyond the dialog that established it; i.e. it spans transactions. One place where such persistent connections may be used is between a UAC and its default outbound proxy, or between two proxies that may have a trusted peering relationship between them for traffic between their domains. Exactly how to quantify this length of time is tricky. As you point out, sometime a peer may go down for administrative reasons, other times it may simply crash. Depending on how we specify and implement it, there may be an expiry time for this connection -- I don't know what the correct answer is right now. > I would be very happy to see some good thought on when devices should > close a TCP socket - I think that figuring out a good algorithm and > understanding the large scale consequences is going to be surprisingly > complicated. We're working on an I-D that extends the connect-reuse ID to outline some of these issues. I will post it to the list as soon as I can. It contains a lot of what Sarit also outlines below: Sarit Galanos Mekler (Sarit@radvision.com) writes: > First I would like to say that I think that the pc=1 is a good choice. > To my opinion adding the pc=1 to the via header is only a recommendation > to the server to keep the connection open. Unfortunately, this is just a hint to the server, and as you point out below: > Servers that don't understand pc or don't want to keep the connection > open are more then welcome to close it. But that may be all we need to do. I don't yet know if it is worthwhile to go through some negotiation mechanism (i.e. register Require and Proxy-Require tokens with IANA). Even it we do go the "pc=1" parameter route, we should register the "pc" token with IANA. > A server can also decide that it wishes to keep the connection open only > if it is actually being used. An implementation can for example, set a > timer on server connections. When ever a message is received/sent on > the connection the timer is reset. when the timer expires the server > closes the connection. All this presumes that clients and servers are well-behaved. In the extreme case, I think that we may rely on I/O failing on a now unconnected socket because one of the peers crashed or got brought down for adminstrative reasons. That is, we proscribe behavior for well- behaved peers, taking in account extreme cases where one of them suddenly disappears. > The persistency level (dialog / transaction) if for the specific > application to decide. For dialog persistency the application will have > to keep the connection open for the duration of the call. Using the > pc=1 parameter will give a good chance for using connections for more > then one transaction. An option that today (almost) does not exist. Right. Cheers, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Feb 10 12:10:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16016 for ; Mon, 10 Feb 2003 12:10:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1AHIZV29206 for sip-archive@odin.ietf.org; Mon, 10 Feb 2003 12:18:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AHHup29160; Mon, 10 Feb 2003 12:17:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AHBMp28939 for ; Mon, 10 Feb 2003 12:11:22 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15784 for ; Mon, 10 Feb 2003 12:02:20 -0500 (EST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-msg-core-2.cisco.com (8.12.2/8.12.6) with ESMTP id h1AH5psv024060; Mon, 10 Feb 2003 09:05:51 -0800 (PST) Received: from fluffyw2k (skoehler-w2k1.cisco.com [128.107.142.109]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABG84895; Mon, 10 Feb 2003 09:06:01 -0800 (PST) From: "Cullen Jennings" To: "'Sarit Galanos Mekler'" , "'Colasanto, Eric \(Eric\)'" , "'James Ford'" , "'Jain, Rajnish \(Rajnish\)'" , Cc: "'Gurbani, Vijay K \(Vijay\)'" Subject: RE: [Sip] Impossible to use real persistent connection with sip Date: Mon, 10 Feb 2003 09:06:01 -0800 Message-ID: <007901c2d126$b014c9b0$6d8e6b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I just assumed that all reasonable proxies treated the TCP close as a classic garbage collection problem. So they would leave it open until they were low on resources then run some sort of least used or least recently used algorithm to select the connections to close. Why would any proxy default to close the connection after every transaction? I don't see why the hint is needed. Cullen > -----Original Message----- > From: Sarit Galanos Mekler [mailto:Sarit@radvision.com] > Sent: Monday, February 10, 2003 1:31 AM > To: 'Cullen Jennings'; Colasanto, Eric (Eric); 'James Ford'; > Jain, Rajnish (Rajnish); sip@ietf.org > Cc: Gurbani, Vijay K (Vijay) > Subject: RE: [Sip] Impossible to use real persistent > connection with sip > > > First I would like to say that I think that the pc=1 is a > good choice. To my opinion adding the pc=1 to the via header > is only a recommendation to the server to keep the connection > open. Servers that don't understand pc or don't want to keep > the connection open > are more then welcome to close it. > A server can also decide that it wishes to keep the > connection open only if it is actually being used. An > implementation can for example, set a timer on server > connections. When ever a message is received/sent on the > connection the timer is reset. when the timer expires the > server closes the connection. > > The persistency level (dialog / transaction) if for the > specific application to decide. For dialog persistency the application > will have to keep the connection open for the duration of > the call. Using the pc=1 parameter will give a good chance > for using connections for more then one transaction. An > option that today > (almost) does not exist. > > Regards, > Sarit Galanos. > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Monday, February 10, 2003 9:28 AM > To: Colasanto, Eric (Eric); 'James Ford'; Jain, Rajnish > (Rajnish); sip@ietf.org > Cc: Gurbani, Vijay K (Vijay) > Subject: RE: [Sip] Impossible to use real persistent > connection with sip > > > > Just to get a little more precise about this ... what does > persistence mean? For the length of the transaction? For the > dialog? As long as the registration is valid? Until some box > crashes? Until the world moves to IPv6. > > I think this persistent connection question is intertwined > with the ideas of how SIP will do reliability. It's all fine > and dandy to add a parameter allows box A to tell box B that > it is not allowed to crash but it is a little harder for B to > make sure it correctly implements this. Even if B is capable > of this sort of HA, it might want to close the connection for > administrative reasons such as getting new keying material on > a TLS connection. > > I would be very happy to see some good thought on when > devices should close a TCP socket - I think that figuring out > a good algorithm and understanding the large scale > consequences is going to be surprisingly complicated. > > Cullen > > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > > Colasanto, Eric (Eric) > > Sent: Thursday, February 06, 2003 5:51 AM > > To: 'James Ford'; Jain, Rajnish (Rajnish); sip@ietf.org > > Cc: Colasanto, Eric (Eric); Gurbani, Vijay K (Vijay) > > Subject: RE: [Sip] Impossible to use real persistent > connection with > > sip > > > > > > I think a new parameter will work well to specify the creation of a > > persistent socket. ;pc=0 when the socket is NOT persistent, > or don't > > include this parameter. ;pc=1 when the socket is persistent. > > > > After setting up this socket will all subsequent SIP messages be > > required to have the pc=1 to utilize the persistent socket. Or will > > any SIP message destined for an endpoint supported by a > > persistent socket utilize the socket, reguardless of the presence > > of the pc parameter? > > > > Then there is the issue of when/how does one destroy the persistent > > connection(s). Should this be left to the application/user which is > > controlling the generation/consumption of > > the SIP messages? > > > > > > Eric J. Colasanto > > (508) 862-3386 > > > > > > > > -----Original Message----- > > From: James Ford [mailto:james_s_ford@hotmail.com] > > Sent: Thursday, February 06, 2003 2:17 AM > > To: rajnishjain@lucent.com; sip@ietf.org > > Cc: ecolasanto@lucent.com; vkg@ih2mail.ih.lucent.com > > Subject: RE: [Sip] Impossible to use real persistent > connection with > > sip > > > > > > An even simpler solution will be to add a parameter to the > Via header > > such as > > pc; (or pc=1 so that we will not have troubles with > Microsoft). Pc stands > > for persistent connection. > > > > Guys, what do I need to do to move on this thing so that we > will have > > a new draft to solve the problem? > > I think many implementations will be interested in using a real > > persistent > > connection especially when TLS will be more deployed. > > > > Thanks, > > James S. Ford > > > > > > >From: "Jain, Rajnish (Rajnish)" > > >To: "'James Ford'" , sip@ietf.org > > >CC: "Colasanto, Eric (Eric)" , > > "Gurbani, Vijay K > > >(Vijay)" > > >Subject: RE: [Sip] Impossible to use real persistent > connection with > > >sip > > >Date: Tue, 4 Feb 2003 07:20:22 -0500 > > > > > >James, > > > > > >The option of adding a SIP header field seems to be more flexible. > > >That way, when that header field is not present, the persistent > > >connection > > is jointly > > >owned by both UAs. And at their discretion they can close it. > > This allows > > >us > > >to be backward compatible while enabling a new capability. > > > > > >Thanks, > > >Rajnish > > > > > >-----Original Message----- > > >From: James Ford [mailto:james_s_ford@hotmail.com] > > >Sent: Tuesday, February 04, 2003 2:45 AM > > >To: sip@ietf.org > > >Subject: [Sip] Impossible to use real persistent > connection with sip > > > > > > > > >Hi, > > >The SIP standard does not specify who is responsible for > closing TCP > > >connections. This means that both client and server > transaction can > > >close the connection. A reasonable implementation for a > transaction > > >will be to close any open connection (incoming or outgoing) before > > >termination in order to free unused resources. > > >This behavior actually makes it impossible to count on a persistent > > >connection. > > >For example, A UA that is always talking to the same destination > > using TLS > > >will want to use one connection per day. This is > impossible since the > > >server might close the connection as soon as the first transaction > > >terminates. > > > > > >I can see several ways to solve this problem: > > >1. Specify that the UA that opened the connection will be > > responsible for > > >closing it. > > >2. Add a header to sip requests that asks the server not > to close the > > >connection by itself. > > > > > >What do you think? > > >James S Ford. > > > > > > > > > > > > > > > > > > > > >_________________________________________________________________ > > >Add photos to your e-mail with MSN 8. Get 2 months FREE*. > > >http://join.msn.com/?page=features/featuredemail > > > > > >_______________________________________________ > > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > >This list is for NEW development of the core SIP Protocol Use > > >sip-implementors@cs.columbia.edu for questions on current sip Use > > >sipping@ietf.org for new developments on the application of sip > > > > > > _________________________________________________________________ > > Protect your PC - get McAfee.com VirusScan Online > > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on > current sip Use > > sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Feb 10 13:01:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18354 for ; Mon, 10 Feb 2003 13:01:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1AIAIw00558 for sip-archive@odin.ietf.org; Mon, 10 Feb 2003 13:10:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AI9np00528; Mon, 10 Feb 2003 13:09:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AI8qp00467 for ; Mon, 10 Feb 2003 13:08:52 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18267 for ; Mon, 10 Feb 2003 12:59:49 -0500 (EST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h1AI3VSS028265; Mon, 10 Feb 2003 10:03:32 -0800 (PST) Received: from fluffyw2k (skoehler-w2k1.cisco.com [128.107.142.109]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABG90841; Mon, 10 Feb 2003 10:03:31 -0800 (PST) From: "Cullen Jennings" To: "'Vijay K. Gurbani'" Cc: "'Colasanto, Eric \(Eric\)'" , "'James Ford'" , "'Jain, Rajnish \(Rajnish\)'" , , "'Sarit Galanos Mekler'" Subject: RE: [Sip] Impossible to use real persistent connection with sip Date: Mon, 10 Feb 2003 10:03:31 -0800 Message-ID: <007b01c2d12e$b878a3d0$6d8e6b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <3E47D17F.8010904@lucent.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I look forward to reading the draft. I have been hoping someone would write some advice to implementers on when to close connection. I initially did not understand that pc was meant to be a hint - I'm way more comfortable with a hint than with anything that assumes a reliability model beyond what SIP already has specified. Cullen > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Vijay K. Gurbani > Sent: Monday, February 10, 2003 8:21 AM > To: Cullen Jennings > Cc: Colasanto, Eric (Eric); 'James Ford'; Jain, Rajnish > (Rajnish); sip@ietf.org; Sarit Galanos Mekler > Subject: Re: [Sip] Impossible to use real persistent > connection with sip > > > Cullen Jennings wrote: > > Just to get a little more precise about this ... what does > persistence > > mean? For the length of the transaction? For the dialog? As long as > > the registration is valid? Until some box crashes? Until > the world moves > > to IPv6. > > Hi Cullen: > > Yes, we've grappled with that as well. Clearly, to get most > bang for the buck, the persistent connection lives beyond the > dialog that established it; i.e. it spans transactions. One > place where such persistent connections may be used is > between a UAC and its default outbound proxy, or between two > proxies that may have a trusted peering relationship between > them for traffic between their domains. > > Exactly how to quantify this length of time is tricky. As > you point out, sometime a peer may go down for administrative > reasons, other times it may simply crash. Depending on how > we specify and implement it, there may be an expiry time for > this connection -- I don't know what the correct answer is right now. > > > I would be very happy to see some good thought on when > devices should > > close a TCP socket - I think that figuring out a good algorithm and > > understanding the large scale consequences is going to be > surprisingly > > complicated. > > We're working on an I-D that extends the connect-reuse ID to > outline some of these issues. I will post it to the list as > soon as I can. It contains a lot of what Sarit also outlines below: > > Sarit Galanos Mekler (Sarit@radvision.com) writes: > > First I would like to say that I think that the pc=1 is a > good choice. > > To my opinion adding the pc=1 to the via header is only a > > recommendation to the server to keep the connection open. > > Unfortunately, this is just a hint to the server, and as you point out > below: > > > Servers that don't understand pc or don't want to keep the > connection > > open are more then welcome to close it. > > But that may be all we need to do. I don't yet know if it is > worthwhile to go through some negotiation mechanism (i.e. > register Require and Proxy-Require tokens with IANA). Even > it we do go the "pc=1" parameter route, we should register > the "pc" token with IANA. > > > A server can also decide that it wishes to keep the connection open > > only > > if it is actually being used. An implementation can for > example, set a > > timer on server connections. When ever a message is > received/sent on > > the connection the timer is reset. when the timer expires > the server > > closes the connection. > > All this presumes that clients and servers are well-behaved. > In the extreme case, I think that we may rely on I/O failing > on a now unconnected socket because one of the peers crashed > or got brought down for adminstrative reasons. That is, we > proscribe behavior for well- behaved peers, taking in account > extreme cases where one of them suddenly disappears. > > > The persistency level (dialog / transaction) if for the specific > > application to decide. For dialog persistency the > application will have > > to keep the connection open for the duration of the call. > Using the > > pc=1 parameter will give a good chance for using > connections for more > > then one transaction. An option that today (almost) does not exist. > > Right. > > Cheers, > > - vijay > -- > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > Wireless Networks Group/Internet Software and Services > Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 > Naperville, Illinois 60566 Voice: +1 630 224 0216 > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Feb 11 06:52:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29034 for ; Tue, 11 Feb 2003 06:52:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BC1lC08013 for sip-archive@odin.ietf.org; Tue, 11 Feb 2003 07:01:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BC16p07997; Tue, 11 Feb 2003 07:01:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BBrup07738 for ; Tue, 11 Feb 2003 06:53:56 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28328; Tue, 11 Feb 2003 06:44:33 -0500 (EST) Message-Id: <200302111144.GAA28328@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 11 Feb 2003 06:44:33 -0500 Subject: [Sip] I-D ACTION:draft-sparks-sip-noninvite-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Considerations for the Session Initiation Protocol's non-INVITE Transaction Author(s) : R. Sparks Filename : draft-sparks-sip-noninvite-00.txt Pages : 14 Date : 2003-2-10 This draft explores several issues with the Session Initiation Protocol's non-INVITE transaction. It focuses on the use of provisional responses and on problems related to transaction timeouts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sparks-sip-noninvite-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-sparks-sip-noninvite-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-sparks-sip-noninvite-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-10132738.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-sparks-sip-noninvite-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-sparks-sip-noninvite-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-10132738.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Feb 11 10:49:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08861 for ; Tue, 11 Feb 2003 10:49:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BFw0l23672 for sip-archive@odin.ietf.org; Tue, 11 Feb 2003 10:58:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BFvQp23637; Tue, 11 Feb 2003 10:57:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BFplp23452 for ; Tue, 11 Feb 2003 10:51:47 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08713 for ; Tue, 11 Feb 2003 10:42:19 -0500 (EST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h1BFk1ap002028; Tue, 11 Feb 2003 07:46:01 -0800 (PST) Received: from [10.32.254.183] (stealth-10-32-254-183.cisco.com [10.32.254.183]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id ABH75773; Tue, 11 Feb 2003 07:46:00 -0800 (PST) Date: Tue, 11 Feb 2003 10:45:56 -0500 From: "David R. Oran" To: Sophia Scoggins , SIP Subject: Re: [Sip] Seek for SIP free or cheap stack or experienced SIP SE Message-ID: <428125441.1044960356@[10.32.254.183]> In-Reply-To: <20030207160535.67486.qmail@web41415.mail.yahoo.com> References: <20030207160535.67486.qmail@web41415.mail.yahoo.com> X-Mailer: Mulberry/3.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit www.vovida.org --On Friday, February 07, 2003 8:05 AM -0800 Sophia Scoggins wrote: > If this is not the right list to ask this question, > please forgive me. > > Can any one point me where to find SIP free stack or a > SIP stack that is less than $50K? > > If you have experience in writing SIP stack from > scratch and is living in the Bay area and is looking > for Software Engineer contractor job for about 6 > months, the small startup company that I am with has > the opportunity. It is VoIP/DSL with SIP. Strong C > language is required. > > Please send your reply to me directly > sc_scoggins@yahoo.com, rather than to the list. > > Thanks in advance. > > > Regards, > Sophia > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Feb 11 11:18:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09848 for ; Tue, 11 Feb 2003 11:18:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BGRqJ25569 for sip-archive@odin.ietf.org; Tue, 11 Feb 2003 11:27:52 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BGRGp25525; Tue, 11 Feb 2003 11:27:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BGN4p25389 for ; Tue, 11 Feb 2003 11:23:04 -0500 Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09581 for ; Tue, 11 Feb 2003 11:13:33 -0500 (EST) Received: from znsgy0k8.europe.nortel.com (europem01.nt.com [47.165.24.67]) by znsgs01r.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h1BGGdV09133; Tue, 11 Feb 2003 16:16:39 GMT Received: from zwcwc012.europe.nortel.com ([47.160.46.124]) by znsgy0k8.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1NZ73G0H; Tue, 11 Feb 2003 16:16:39 -0000 Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1LVB5B70>; Tue, 11 Feb 2003 16:16:16 -0000 Message-ID: X-Sybari-Space: 00000000 00000000 00000000 From: "Mark Watson" To: "'Cullen Jennings'" , "'Vijay K. Gurbani'" Cc: "'Colasanto, Eric (Eric)'" , "'James Ford'" , "'Jain, Rajnish (Rajnish)'" , sip@ietf.org, "'Sarit Galanos Mekler'" Subject: RE: [Sip] Impossible to use real persistent connection with sip Date: Tue, 11 Feb 2003 16:16:14 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D1E8.E5EE29A6" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D1E8.E5EE29A6 Content-Type: text/plain; charset="iso-8859-1" I fail to see the problem. Servers can close the connection whenever they like. pc=1 tells the server to keep the connection for longer. Longer than what ? Longer than it would have done otherwise ?? If the server closes the connection, it presumably had a good reason. Asking it nicely to ignore its own good reasons does not seem very useful to me. Perhaps we should recommend that servers do not close connections without a good reason ? Should we recommend that they do not initiate connections without a good reason ? or that they should not reject connections without a good reason ? Why should we believe there are servers which will arbitrarily close connections for no reason, servers that are so stupid they need a new parameter to tell them not to do this ? ...Mark > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: 10 February 2003 18:04 > To: 'Vijay K. Gurbani' > Cc: 'Colasanto, Eric (Eric)'; 'James Ford'; 'Jain, Rajnish (Rajnish)'; > sip@ietf.org; 'Sarit Galanos Mekler' > Subject: RE: [Sip] Impossible to use real persistent > connection with sip > > > > I look forward to reading the draft. I have been hoping someone would > write some advice to implementers on when to close connection. > > I initially did not understand that pc was meant to be a hint > - I'm way > more comfortable with a hint than with anything that assumes a > reliability model beyond what SIP already has specified. > > Cullen > > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > > Behalf Of Vijay K. Gurbani > > Sent: Monday, February 10, 2003 8:21 AM > > To: Cullen Jennings > > Cc: Colasanto, Eric (Eric); 'James Ford'; Jain, Rajnish > > (Rajnish); sip@ietf.org; Sarit Galanos Mekler > > Subject: Re: [Sip] Impossible to use real persistent > > connection with sip > > > > > > Cullen Jennings wrote: > > > Just to get a little more precise about this ... what does > > persistence > > > mean? For the length of the transaction? For the dialog? > As long as > > > the registration is valid? Until some box crashes? Until > > the world moves > > > to IPv6. > > > > Hi Cullen: > > > > Yes, we've grappled with that as well. Clearly, to get most > > bang for the buck, the persistent connection lives beyond the > > dialog that established it; i.e. it spans transactions. One > > place where such persistent connections may be used is > > between a UAC and its default outbound proxy, or between two > > proxies that may have a trusted peering relationship between > > them for traffic between their domains. > > > > Exactly how to quantify this length of time is tricky. As > > you point out, sometime a peer may go down for administrative > > reasons, other times it may simply crash. Depending on how > > we specify and implement it, there may be an expiry time for > > this connection -- I don't know what the correct answer is > right now. > > > > > I would be very happy to see some good thought on when > > devices should > > > close a TCP socket - I think that figuring out a good > algorithm and > > > understanding the large scale consequences is going to be > > surprisingly > > > complicated. > > > > We're working on an I-D that extends the connect-reuse ID to > > outline some of these issues. I will post it to the list as > > soon as I can. It contains a lot of what Sarit also outlines below: > > > > Sarit Galanos Mekler (Sarit@radvision.com) writes: > > > First I would like to say that I think that the pc=1 is a > > good choice. > > > To my opinion adding the pc=1 to the via header is only a > > > recommendation to the server to keep the connection open. > > > > Unfortunately, this is just a hint to the server, and as > you point out > > below: > > > > > Servers that don't understand pc or don't want to keep the > > connection > > > open are more then welcome to close it. > > > > But that may be all we need to do. I don't yet know if it is > > worthwhile to go through some negotiation mechanism (i.e. > > register Require and Proxy-Require tokens with IANA). Even > > it we do go the "pc=1" parameter route, we should register > > the "pc" token with IANA. > > > > > A server can also decide that it wishes to keep the > connection open > > > only > > > if it is actually being used. An implementation can for > > example, set a > > > timer on server connections. When ever a message is > > received/sent on > > > the connection the timer is reset. when the timer expires > > the server > > > closes the connection. > > > > All this presumes that clients and servers are well-behaved. > > In the extreme case, I think that we may rely on I/O failing > > on a now unconnected socket because one of the peers crashed > > or got brought down for adminstrative reasons. That is, we > > proscribe behavior for well- behaved peers, taking in account > > extreme cases where one of them suddenly disappears. > > > > > The persistency level (dialog / transaction) if for the specific > > > application to decide. For dialog persistency the > > application will have > > > to keep the connection open for the duration of the call. > > Using the > > > pc=1 parameter will give a good chance for using > > connections for more > > > then one transaction. An option that today (almost) does > not exist. > > > > Right. > > > > Cheers, > > > > - vijay > > -- > > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > > Wireless Networks Group/Internet Software and Services > > Lucent Technologies/Bell Labs Innovations, 2000 Lucent > Lane, Rm 6G-440 > > Naperville, Illinois 60566 Voice: +1 630 224 0216 > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current > > sip Use sipping@ietf.org for new developments on the > > application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------_=_NextPart_001_01C2D1E8.E5EE29A6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Impossible to use real persistent connection with = sip

I fail to see the problem.

Servers can close the connection whenever they like. = pc=3D1 tells the server to keep the connection for longer. Longer than = what ? Longer than it would have done otherwise ??

If the server closes the connection, it presumably = had a good reason. Asking it nicely to ignore its own good reasons does = not seem very useful to me.

Perhaps we should recommend that servers do not close = connections without a good reason ? Should we recommend that they do = not initiate connections without a good reason ? or that they should = not reject connections without a good reason ? Why should we believe = there are servers which will arbitrarily close connections for no = reason, servers that are so stupid they need a new parameter to tell = them not to do this ?

...Mark

> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@cisco.com]
> Sent: 10 February 2003 18:04
> To: 'Vijay K. Gurbani'
> Cc: 'Colasanto, Eric (Eric)'; 'James Ford'; = 'Jain, Rajnish (Rajnish)';
> sip@ietf.org; 'Sarit Galanos Mekler'
> Subject: RE: [Sip] Impossible to use real = persistent
> connection with sip
>
>
>
> I look forward to reading the draft. I have = been hoping someone would
> write some advice to implementers on when to = close connection.
>
> I initially did not understand that pc was = meant to be a hint
> - I'm way
> more comfortable with a hint than with anything = that assumes a
> reliability model beyond what SIP already has = specified.
>
> Cullen
> 
>
> > -----Original Message-----
> > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On =
> > Behalf Of Vijay K. Gurbani
> > Sent: Monday, February 10, 2003 8:21 = AM
> > To: Cullen Jennings
> > Cc: Colasanto, Eric (Eric); 'James Ford'; = Jain, Rajnish
> > (Rajnish); sip@ietf.org; Sarit Galanos = Mekler
> > Subject: Re: [Sip] Impossible to use real = persistent
> > connection with sip
> >
> >
> > Cullen Jennings wrote:
> > > Just to get a little more precise = about this ... what does
> > persistence
> > > mean?  For the length of the = transaction? For the dialog?
> As long as
> > > the registration is valid? Until some = box crashes? Until
> > the world moves
> > > to IPv6.
> >
> > Hi Cullen:
> >
> > Yes, we've grappled with that as = well.  Clearly, to get most
> > bang for the buck, the persistent = connection lives beyond the
> > dialog that established it; i.e. it spans = transactions.  One
> > place where such persistent connections = may be used is
> > between a UAC and its default outbound = proxy, or between two
> > proxies that may have a trusted peering = relationship between
> > them for traffic between their = domains.
> >
> > Exactly how to quantify this length of = time is tricky.  As
> > you point out, sometime a peer may go down = for administrative
> > reasons, other times it may simply = crash.  Depending on how
> > we specify and implement it, there may be = an expiry time for
> > this connection -- I don't know what the = correct answer is
> right now.
> >
> > > I would be very happy to see some = good thought on when
> > devices should
> > > close a TCP socket - I think that = figuring out a good
> algorithm and
> > > understanding the large scale = consequences is going to be
> > surprisingly
> > > complicated.
> >
> > We're working on an I-D that extends the = connect-reuse ID to
> > outline some of these issues.  I will = post it to the list as
> > soon as I can.  It contains a lot of = what Sarit also outlines below:
> >
> > Sarit Galanos Mekler (Sarit@radvision.com) = writes:
> > > First I would like to say that I = think that the pc=3D1 is a
> > good choice.
> > > To my opinion adding the pc=3D1 to = the via header is only a
> > > recommendation to the server to keep = the connection open.
> >
> > Unfortunately, this is just a hint to the = server, and as
> you point out
> > below:
> >
> > > Servers that don't understand pc or = don't want to keep the
> > connection
> > > open are more then welcome to close = it.
> >
> > But that may be all we need to do.  I = don't yet know if it is
> > worthwhile to go through some negotiation = mechanism (i.e.
> > register Require and Proxy-Require tokens = with IANA).  Even
> > it we do go the "pc=3D1" = parameter route, we should register
> > the "pc" token with IANA.
> >
> > > A server can also decide that it = wishes to keep the
> connection open
> > > only
> > > if it is actually being used.  = An implementation can for
> > example, set a
> > > timer on server = connections.   When ever a message is
> > received/sent on
> > > the connection the timer is reset. = when the timer expires
> > the server
> > > closes  the connection.
> >
> > All this presumes that clients and servers = are well-behaved. 
> > In the extreme case, I think that we may = rely on I/O failing
> > on a now unconnected socket because one of = the peers crashed
> > or got brought down for adminstrative = reasons.  That is, we
> > proscribe behavior for well- behaved = peers, taking in account
> > extreme cases where one of them suddenly = disappears.
> >
> > > The persistency level (dialog / = transaction) if for the specific
> > > application to decide. For dialog = persistency the
> > application will have
> > > to keep the connection open for the = duration of the call. 
> > Using the
> > > pc=3D1 parameter will give a good = chance for using
> > connections for more
> > > then one transaction. An option that = today (almost) does
> not exist.
> >
> > Right.
> >
> > Cheers,
> >
> > - vijay
> > --
> > Vijay K. Gurbani  = vkg@{lucent.com,research.bell-labs.com,acm.org}
> > Wireless Networks Group/Internet Software = and Services
> > Lucent Technologies/Bell Labs Innovations, = 2000 Lucent
> Lane, Rm 6G-440
> > Naperville, Illinois = 60566     Voice: +1 630 224 0216
> >
> > = _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the = core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for = questions on current
> > sip Use sipping@ietf.org for new = developments on the
> > application of sip
> >
>
> = _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP Protocol
> Use sip-implementors@cs.columbia.edu for = questions on current sip
> Use sipping@ietf.org for new developments on = the application of sip
>

------_=_NextPart_001_01C2D1E8.E5EE29A6-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Feb 11 19:21:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22838 for ; Tue, 11 Feb 2003 19:21:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1C0V1124080 for sip-archive@odin.ietf.org; Tue, 11 Feb 2003 19:31:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C0UGp24055; Tue, 11 Feb 2003 19:30:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C0Sxp23995 for ; Tue, 11 Feb 2003 19:28:59 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22822 for ; Tue, 11 Feb 2003 19:19:20 -0500 (EST) Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h1C0N3Lc014948; Tue, 11 Feb 2003 18:23:03 -0600 Received: (from dwillis@localhost) by bdsl.greycouncil.com (8.12.5/8.12.5/Submit) id h1C0N2Gd014946; Tue, 11 Feb 2003 18:23:02 -0600 X-Authentication-Warning: bdsl.greycouncil.com: dwillis set sender to dean.willis@softarmor.com using -f Subject: Re: Ri: RE: [Sip] Extension to Assure Congestion Safety From: Dean Willis To: loretosa@vodafone.it Cc: eburger@snowshore.com, sip@ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045009381.14502.47.camel@bdsl.greycouncil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 11 Feb 2003 18:23:01 -0600 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thu, 2003-02-06 at 04:06, loretosa@vodafone.it wrote: > thanks for informations. > > but i'd like some papers/articles about latency in the > internal nodes of IP Multimedia Subsystem like CSCF... > and the others servers... > where have you found the following informations? > > "Now, add aother 50 ms each for the P-CSCF, I-CSCF, S-CSCF, I-CSCF, S-CSCF, P-CSCF processing and we get another 300 ms for each hop, or 900ms. Add a little more for topology hiding gateways and the like, and we're at around 1800 ms." > > best regards > Sal Well, there aren't a lot of "real" P-, S-, or C- CSCFs out there in the wild, so my best suggestion would be to work from the performance of SIP proxies used in wireline environments. These tend to have proxy transaction times ranging from just a few ms (say, 8-10ms) for simple stateless "pure proxy" operations, up to around 250ms for complex operations such as topology hiding. Of course, if external operations, such as database lookups, firewall behavior modification, or Java garbage collection happen to occur, the times can become much longer. Also relevant are things like "just exactly what are you measuring", which can include things like serialization delay and OS-level context changing. I would typically be inclined to measure the time from when an incoming message is presented "on the wire" to a proxy (fully serialized in), to when the outgoing message starts to appear "on the wire" coming out. Of course, it's easier to measure times between ingoing and outgoing as they cross an external monitoring point on a shared ethernet hub, which isn't quite the same thing. Since the functionality differs between CSCF types, and differs further within a type based on design, configuration, and the hosting processor, using 50ms is, at best, a horrible oversimplification. However, I believe the number to be of the right order of magnitude for use in assessing the performance differences between UDP and TCP. I would certainly suggest more precise estimation if one were trying to do real-world capacity planning. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Feb 12 00:49:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29570 for ; Wed, 12 Feb 2003 00:49:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1C5wh509364 for sip-archive@odin.ietf.org; Wed, 12 Feb 2003 00:58:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C5wNp09350; Wed, 12 Feb 2003 00:58:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C5tip09254 for ; Wed, 12 Feb 2003 00:55:44 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29511 for ; Wed, 12 Feb 2003 00:45:59 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.152]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h1C5nkYH023510; Wed, 12 Feb 2003 00:49:46 -0500 (EST) Message-ID: <3E49E076.8040306@dynamicsoft.com> Date: Wed, 12 Feb 2003 00:49:42 -0500 From: Jonathan Rosenberg Organization: dynamicsoft 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: hisham.khartabil@nokia.com CC: sip@ietf.org Subject: Re: [Sip] Proxy inserting Record-Route References: <2038BCC78B1AD641891A0D1AE133DBB7FE725B@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. hisham.khartabil@nokia.com wrote: > RFC3261 says: > > "If this proxy wishes to remain on the path of future requests in a > dialog created by this request (assuming the request creates a > dialog), it MUST insert a Record-Route header field value into the > copy before any existing Record-Route header field values, even if a > Route header field is already present." > > It fails to mention where the proxy should adds that record-route > header. Of course it does. It says "before". Seems clear enough to me. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Feb 12 09:47:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04546 for ; Wed, 12 Feb 2003 09:47:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CEuts21336 for sip-archive@odin.ietf.org; Wed, 12 Feb 2003 09:56:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CEu4p21309; Wed, 12 Feb 2003 09:56:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CEr4p20969 for ; Wed, 12 Feb 2003 09:53:04 -0500 Received: from auemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04359 for ; Wed, 12 Feb 2003 09:43:04 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1CEkeh12810; Wed, 12 Feb 2003 09:46:40 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id IAA03829; Wed, 12 Feb 2003 08:46:37 -0600 (CST) Message-ID: <3E4A5E26.40405@lucent.com> Date: Wed, 12 Feb 2003 08:45:58 -0600 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories 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: Mark Watson CC: "'Cullen Jennings'" , "'Colasanto, Eric (Eric)'" , "'James Ford'" , "'Jain, Rajnish (Rajnish)'" , sip@ietf.org, "'Sarit Galanos Mekler'" Subject: Re: [Sip] Impossible to use real persistent connection with sip References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mark Watson wrote: > I fail to see the problem. > > Servers can close the connection whenever they like. pc=1 tells the > server to keep the connection for longer. Longer than what ? Longer than > it would have done otherwise ?? > > If the server closes the connection, it presumably had a good reason. > Asking it nicely to ignore its own good reasons does not seem very > useful to me. > > Perhaps we should recommend that servers do not close connections > without a good reason ? Should we recommend that they do not initiate > connections without a good reason ? or that they should not reject > connections without a good reason ? Why should we believe there are > servers which will arbitrarily close connections for no reason, servers > that are so stupid they need a new parameter to tell them not to do this ? Mark: I don't think anyone is suggesting that every connection a server opens actively to a downstream entity or accepts passively from an upstream client remain open forever. The essence of the problem simply is that two high-signaling traffic proxies (or a UAC and its default outbound proxy) would like to keep a TCP (or TLS) connection open for traffic between them. This alleviates negotiating TLS security keys or TCP 3-way handshake for each transaction going between them. Admittedly, this was not too much a problem when UDP was the preferred mode of transport for SIP signaling. However, for good reasons, TCP is becoming the preferred transport. So I don't see why we can't have some thought put into investigating this problem. Section 18 of rfc3261 correctly instructs implementors to close connections after a certain time (64*T1). It also recognizes that two proxies in a peering relationship will actually have two connections open towards each other (which can be avoided). And it also rightly defines "persistence" to mean a transaction duration. rfc3261 must ensure that the transactional integrity of SIP is preserved, and it does. All that is being done now is an attempt to investigate an extension that will enable "persistence" to mean some duration longer than a transaction's lifetime. Exactly how long, how to negotiate it (or not) is what comes next. Cheers. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Feb 12 11:49:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08256 for ; Wed, 12 Feb 2003 11:49:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CGx6n04653 for sip-archive@odin.ietf.org; Wed, 12 Feb 2003 11:59:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CGwdp04642; Wed, 12 Feb 2003 11:58:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CGvip04603 for ; Wed, 12 Feb 2003 11:57:44 -0500 Received: from hotsip.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08230 for ; Wed, 12 Feb 2003 11:47:46 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Sip] Impossible to use real persistent connection with sip Date: Wed, 12 Feb 2003 17:51:28 +0100 Message-ID: Thread-Topic: [Sip] Impossible to use real persistent connection with sip Thread-Index: AcLSp23HR49vbPrhRWuWLAAr7eSsrAADL6dg From: "Christian Jansson" To: "Vijay K. Gurbani" , "Mark Watson" Cc: "Cullen Jennings" , "Colasanto, Eric (Eric)" , "James Ford" , "Jain, Rajnish (Rajnish)" , , "Sarit Galanos Mekler" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1CGvjp04604 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Vijay K. Gurbani wrote: > Section 18 of rfc3261 correctly instructs implementors to > close connections after a certain time (64*T1). No, it does not. Section 18 does not say when to close sockets, but rather that you should not close the socket to soon. So if you feel like it, you could leave the connection open forever. > It also > recognizes that two proxies in a peering relationship will > actually have two connections open towards each other (which > can be avoided). And it also rightly defines "persistence" > to mean a transaction duration. rfc3261 must ensure that the > transactional integrity of SIP is preserved, and it does. It says that it is good to keep the connection open during a transaction, but it does not say that connections should be closed when the transaction is terminated. > > All that is being done now is an attempt to investigate an > extension that will enable "persistence" to mean some > duration longer than a transaction's lifetime. Exactly how > long, how to negotiate it (or > not) is what comes next. Not needed. Close the socket when you have to, and probably it will be more effective to keep it open for a while in case you need it again (as Cullen Jennings wrote). Christian Jansson Hotsip > > Cheers. > > - vijay > -- > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > Wireless Networks Group/Internet Software and Services > Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 > Naperville, Illinois 60566 Voice: +1 630 224 0216 > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Feb 12 12:09:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09008 for ; Wed, 12 Feb 2003 12:09:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CHJ6P06935 for sip-archive@odin.ietf.org; Wed, 12 Feb 2003 12:19:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CHIJp06868; Wed, 12 Feb 2003 12:18:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CHH8p06812 for ; Wed, 12 Feb 2003 12:17:08 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08980 for ; Wed, 12 Feb 2003 12:07:09 -0500 (EST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1CHAgB6028255; Wed, 12 Feb 2003 09:10:42 -0800 (PST) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id ABI81405; Wed, 12 Feb 2003 09:10:48 -0800 (PST) From: "Cullen Jennings" To: "Vijay K. Gurbani" , "Mark Watson" Cc: "'Colasanto, Eric \(Eric\)'" , "'James Ford'" , "'Jain, Rajnish \(Rajnish\)'" , , "'Sarit Galanos Mekler'" Subject: RE: [Sip] Impossible to use real persistent connection with sip Date: Wed, 12 Feb 2003 09:16:59 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3E4A5E26.40405@lucent.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hmm - I did not read 3261 quite that way. I thought it was more along the lines of what you want to get too where it is up to the proxy and UA to make intelligent decision about when to close a connection. I think it would be good to provide some information level advice about schemes UA and Proxies might want to use to do a good job of this. If this required more information to be passed between them to do a good job of it that would be interesting but without seeing the scheme it is hard to see that they need any more information than they have today. Cullen > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@lucent.com] > Sent: Wednesday, February 12, 2003 6:46 AM > To: Mark Watson > Cc: 'Cullen Jennings'; 'Colasanto, Eric (Eric)'; 'James Ford'; 'Jain, > Rajnish (Rajnish)'; sip@ietf.org; 'Sarit Galanos Mekler' > Subject: Re: [Sip] Impossible to use real persistent connection with sip > > > Mark Watson wrote: > > I fail to see the problem. > > > > Servers can close the connection whenever they like. pc=1 tells the > > server to keep the connection for longer. Longer than what ? > Longer than > > it would have done otherwise ?? > > > > If the server closes the connection, it presumably had a good reason. > > Asking it nicely to ignore its own good reasons does not seem very > > useful to me. > > > > Perhaps we should recommend that servers do not close connections > > without a good reason ? Should we recommend that they do not initiate > > connections without a good reason ? or that they should not reject > > connections without a good reason ? Why should we believe there are > > servers which will arbitrarily close connections for no reason, servers > > that are so stupid they need a new parameter to tell them not > to do this ? > > Mark: > > I don't think anyone is suggesting that every connection a server > opens actively to a downstream entity or accepts passively from an > upstream client remain open forever. > > The essence of the problem simply is that two high-signaling traffic > proxies (or a UAC and its default outbound proxy) would like to keep > a TCP (or TLS) connection open for traffic between them. This > alleviates negotiating TLS security keys or TCP 3-way handshake for > each transaction going between them. > > Admittedly, this was not too much a problem when UDP was the preferred > mode of transport for SIP signaling. However, for good reasons, TCP is > becoming the preferred transport. So I don't see why we can't have some > thought put into investigating this problem. > > Section 18 of rfc3261 correctly instructs implementors to close > connections after a certain time (64*T1). It also recognizes that > two proxies in a peering relationship will actually have two > connections open towards each other (which can be avoided). And it > also rightly defines "persistence" to mean a transaction duration. > rfc3261 must ensure that the transactional integrity of SIP is > preserved, and it does. > > All that is being done now is an attempt to investigate an extension > that will enable "persistence" to mean some duration longer than > a transaction's lifetime. Exactly how long, how to negotiate it (or > not) is what comes next. > > Cheers. > > - vijay > -- > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > Wireless Networks Group/Internet Software and Services > Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 > Naperville, Illinois 60566 Voice: +1 630 224 0216 > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Feb 12 12:43:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09863 for ; Wed, 12 Feb 2003 12:43:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CHqpa09258 for sip-archive@odin.ietf.org; Wed, 12 Feb 2003 12:52:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CHqHp09238; Wed, 12 Feb 2003 12:52:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CHpep09208 for ; Wed, 12 Feb 2003 12:51:40 -0500 Received: from hoemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09836 for ; Wed, 12 Feb 2003 12:41:40 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1CHjFv27384; Wed, 12 Feb 2003 12:45:15 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA06774; Wed, 12 Feb 2003 11:45:14 -0600 (CST) Message-ID: <3E4A8802.4070104@lucent.com> Date: Wed, 12 Feb 2003 11:44:34 -0600 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories 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: Christian Jansson , Cullen Jennings CC: "Colasanto, Eric (Eric)" , James Ford , "Jain, Rajnish (Rajnish)" , sip@ietf.org, Sarit Galanos Mekler Subject: Re: [Sip] Impossible to use real persistent connection with sip References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Christian Jansson wrote: >>Section 18 of rfc3261 correctly instructs implementors to >>close connections after a certain time (64*T1). > > No, it does not. Section 18 does not say when to close sockets, That's your interpretation. When I read the following sentence from section 18: "It is RECOMMENDED that connections be kept open for some implementation-defined duration..." It implies to me that after the duration has passed, the entity is free to close the socket. > but > rather that you should not close the socket to soon. So if you feel like > it, you could leave the connection open forever. I am afraid I don't read it that way; i.e. leave the connection open forever. > Not needed. Close the socket when you have to, and probably it will be > more effective to keep it open for a while in case you need it again (as > Cullen Jennings wrote). Exactly how long is the question. For some peering arrangements between service providers and for UACs always using a default outbound proxy, does it make sense to leave TCP/TLS sockets open for a longer time than a transaction. That is the crux of the problem. Cullen Jennings writes: > Hmm - I did not read 3261 quite that way. > > I thought it was more along the lines of what you want to get too where > it is up to the proxy and UA to make intelligent decision about when to > close a connection. I think it would be good to provide some information > level advice about schemes UA and Proxies might want to use to do a good > job of this. Right; or schemes between proxies. > If this required more information to be passed between them to do a > good job of it that would be interesting but without seeing the > scheme it is hard to see that they need any more information than > they have today. Fair enough. Folks on the CC list (except sip@ietf.org :-)) are working on an I-D and it'll be available as soon as they are done. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Feb 12 20:49:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21112 for ; Wed, 12 Feb 2003 20:49:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1D1xNA04532 for sip-archive@odin.ietf.org; Wed, 12 Feb 2003 20:59:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D1wnp04509; Wed, 12 Feb 2003 20:58:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D1uKp04432 for ; Wed, 12 Feb 2003 20:56:20 -0500 Received: from web41501.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21078 for ; Wed, 12 Feb 2003 20:46:09 -0500 (EST) Message-ID: <20030213014953.41163.qmail@web41501.mail.yahoo.com> Received: from [131.107.3.70] by web41501.mail.yahoo.com via HTTP; Wed, 12 Feb 2003 17:49:53 PST Date: Wed, 12 Feb 2003 17:49:53 -0800 (PST) From: Sean Olson Subject: Re: [Sip] Impossible to use real persistent connection with sip To: "Vijay K. Gurbani" , Christian Jansson , Cullen Jennings Cc: "Colasanto, Eric \(Eric\)" , James Ford , "Jain, Rajnish \(Rajnish\)" , sip@ietf.org, Sarit Galanos Mekler In-Reply-To: <3E4A8802.4070104@lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I'm looking forward to reading the draft. I think this is a common problem that deserves greater scrutiny. I don't think there is any lack of potential solutions. I would like to see some clean (informational) recommendations on how this should be done. In addition to connection persistence, I think connection re-use is an interesting problem that could potentially be solved with a common design. This is similar to recommendations on how best to use SCTP in a SIP environment. Regards, Sean Olson Microsoft --- "Vijay K. Gurbani" wrote: > Christian Jansson wrote: > >>Section 18 of rfc3261 correctly instructs > implementors to > >>close connections after a certain time (64*T1). > > > > No, it does not. Section 18 does not say when to > close sockets, > > That's your interpretation. When I read the > following sentence from > section 18: > > "It is RECOMMENDED that connections be kept open > for some > implementation-defined duration..." > > It implies to me that after the duration has passed, > the entity is > free to close the socket. > > > but > > rather that you should not close the socket to > soon. So if you feel like > > it, you could leave the connection open forever. > > I am afraid I don't read it that way; i.e. leave the > connection open > forever. > > > Not needed. Close the socket when you have to, and > probably it will be > > more effective to keep it open for a while in case > you need it again (as > > Cullen Jennings wrote). > > Exactly how long is the question. For some peering > arrangements between > service providers and for UACs always using a > default outbound proxy, > does it make sense to leave TCP/TLS sockets open for > a longer time than > a transaction. That is the crux of the problem. > > Cullen Jennings writes: > > Hmm - I did not read 3261 quite that way. > > > > I thought it was more along the lines of what you > want to get too where > > it is up to the proxy and UA to make intelligent > decision about when to > > close a connection. I think it would be good to > provide some information > > level advice about schemes UA and Proxies might > want to use to do a good > > job of this. > > Right; or schemes between proxies. > > > If this required more information to be passed > between them to do a > > good job of it that would be interesting but > without seeing the > > scheme it is hard to see that they need any more > information than > > they have today. > > Fair enough. Folks on the CC list (except > sip@ietf.org :-)) are working > on an I-D and it'll be available as soon as they are > done. > > Thanks, > > - vijay > -- > Vijay K. Gurbani > vkg@{lucent.com,research.bell-labs.com,acm.org} > Wireless Networks Group/Internet Software and > Services > Lucent Technologies/Bell Labs Innovations, 2000 > Lucent Lane, Rm 6G-440 > Naperville, Illinois 60566 Voice: +1 630 224 > 0216 > > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP > Protocol > Use sip-implementors@cs.columbia.edu for questions > on current sip > Use sipping@ietf.org for new developments on the > application of sip __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Feb 12 22:38:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23221 for ; Wed, 12 Feb 2003 22:38:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1D3mNA10707 for sip-archive@odin.ietf.org; Wed, 12 Feb 2003 22:48:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D3lvp10691; Wed, 12 Feb 2003 22:47:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D3k5p10622 for ; Wed, 12 Feb 2003 22:46:05 -0500 Received: from ihemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23179 for ; Wed, 12 Feb 2003 22:35:52 -0500 (EST) Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1D3daD07744 for ; Wed, 12 Feb 2003 22:39:36 -0500 (EST) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Feb 2003 22:39:36 -0500 Message-ID: From: "Jain, Rajnish (Rajnish)" To: "'Sean Olson'" , "Vijay K. Gurbani" , Christian Jansson , Cullen Jennings Cc: "Colasanto, Eric (Eric)" , James Ford , "Jain, Rajnish (Rajnish)" , sip@ietf.org, Sarit Galanos Mekler Subject: RE: [Sip] Impossible to use real persistent connection with sip Date: Wed, 12 Feb 2003 22:39:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I agree w/ Sean that this problem needs to be addressed in the overall scope of SIP transport layer connection management. It is well known that SIP is designed to be loosely coupled w/ transport layer. However, diverse forms of SIP entities (such as phones, proxy servers, B2BUAs, application servers) tend to be somewhat differently influenced w/ the systemic ripple created by connection-oriented transport layers. For instance, while it may be okay for a SIP phone to liberally request transport layer connections, it presents performance, scaling problems if two high traffic peer proxy servers keep churning through transport layer connections. These proxy servers would best serve the network if they communicate over persistent connections that are setup and torn down predictably. RFC 3261 suggests that a connection can be recycled, but for that to happen traffic arrival rate must be such that implementation defined idle timeouts don't occur. Any sporadic patches of idle time can render undesirable connection closure (as Vijay pointed out). Making just the implementation defined timer very large makes the problem worst. That way, the proxy server will tend to impose the large timer for all its connections even w/ SIP phones. Furthermore, since the timer is implementation defined, the two proxies may have vastly different timer values (one very large and one very solve) which can really imbalance overall interaction. Rajnish Jain, Lucent Technologies -----Original Message----- From: Sean Olson [mailto:seancolson@yahoo.com] Sent: Wednesday, February 12, 2003 8:50 PM To: Vijay K. Gurbani; Christian Jansson; Cullen Jennings Cc: Colasanto, Eric (Eric); James Ford; Jain, Rajnish (Rajnish); sip@ietf.org; Sarit Galanos Mekler Subject: Re: [Sip] Impossible to use real persistent connection with sip I'm looking forward to reading the draft. I think this is a common problem that deserves greater scrutiny. I don't think there is any lack of potential solutions. I would like to see some clean (informational) recommendations on how this should be done. In addition to connection persistence, I think connection re-use is an interesting problem that could potentially be solved with a common design. This is similar to recommendations on how best to use SCTP in a SIP environment. Regards, Sean Olson Microsoft --- "Vijay K. Gurbani" wrote: > Christian Jansson wrote: > >>Section 18 of rfc3261 correctly instructs > implementors to > >>close connections after a certain time (64*T1). > > > > No, it does not. Section 18 does not say when to > close sockets, > > That's your interpretation. When I read the > following sentence from > section 18: > > "It is RECOMMENDED that connections be kept open > for some > implementation-defined duration..." > > It implies to me that after the duration has passed, > the entity is > free to close the socket. > > > but > > rather that you should not close the socket to > soon. So if you feel like > > it, you could leave the connection open forever. > > I am afraid I don't read it that way; i.e. leave the > connection open > forever. > > > Not needed. Close the socket when you have to, and > probably it will be > > more effective to keep it open for a while in case > you need it again (as > > Cullen Jennings wrote). > > Exactly how long is the question. For some peering > arrangements between > service providers and for UACs always using a > default outbound proxy, > does it make sense to leave TCP/TLS sockets open for > a longer time than > a transaction. That is the crux of the problem. > > Cullen Jennings writes: > > Hmm - I did not read 3261 quite that way. > > > > I thought it was more along the lines of what you > want to get too where > > it is up to the proxy and UA to make intelligent > decision about when to > > close a connection. I think it would be good to > provide some information > > level advice about schemes UA and Proxies might > want to use to do a good > > job of this. > > Right; or schemes between proxies. > > > If this required more information to be passed > between them to do a > > good job of it that would be interesting but > without seeing the > > scheme it is hard to see that they need any more > information than > > they have today. > > Fair enough. Folks on the CC list (except > sip@ietf.org :-)) are working > on an I-D and it'll be available as soon as they are > done. > > Thanks, > > - vijay > -- > Vijay K. Gurbani > vkg@{lucent.com,research.bell-labs.com,acm.org} > Wireless Networks Group/Internet Software and > Services > Lucent Technologies/Bell Labs Innovations, 2000 > Lucent Lane, Rm 6G-440 > Naperville, Illinois 60566 Voice: +1 630 224 > 0216 > > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP > Protocol > Use sip-implementors@cs.columbia.edu for questions > on current sip > Use sipping@ietf.org for new developments on the > application of sip __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Feb 13 00:23:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24750 for ; Thu, 13 Feb 2003 00:23:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1D5X7U15869 for sip-archive@odin.ietf.org; Thu, 13 Feb 2003 00:33:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D5WZp15860; Thu, 13 Feb 2003 00:32:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D5Vsp15834 for ; Thu, 13 Feb 2003 00:31:54 -0500 Received: from proxy-blr.primus-india.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24745 for ; Thu, 13 Feb 2003 00:21:38 -0500 (EST) Received: from dexceldesigns.com (ptil-67-160-ind.primus-india.net [203.196.160.67] (may be forged)) by proxy-blr.primus-india.com (8.11.2/8.11.2) with ESMTP id h1DArYv15552 for ; Thu, 13 Feb 2003 16:23:34 +0530 Message-ID: <001301c2d31b$e3f3ab10$dd9a83ca@DOMAIN.dexceldesigns.com> From: margaretmary To: Date: Thu, 13 Feb 2003 10:23:46 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C2D349.FD9FB210" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailserver: Sent using PostMaster (v4.1.13) Subject: [Sip] query on OPTIONS call flow Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C2D349.FD9FB210 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hello sir, Where can i find the call flow for OPTIONS method. please try to send the link or in which draft can i find that? Regards, Margaret ------=_NextPart_000_0010_01C2D349.FD9FB210 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
hello sir,
 
Where can i find the call flow for = OPTIONS=20 method.
please try to send the link or in which = draft can i=20 find that?
 
 
Regards,
Margaret


--------------------------------------------------------------
Dexcel Electronics Designs (P) Ltd., Bangalore, India
------=_NextPart_000_0010_01C2D349.FD9FB210-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Feb 13 04:15:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07679 for ; Thu, 13 Feb 2003 04:15:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1D9P4u05871 for sip-archive@odin.ietf.org; Thu, 13 Feb 2003 04:25:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D9OSp05818; Thu, 13 Feb 2003 04:24:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D9M6p05733 for ; Thu, 13 Feb 2003 04:22:06 -0500 Received: from mail-server.comgates.co.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07645 for ; Thu, 13 Feb 2003 04:11:45 -0500 (EST) Received: by MAIL-SERVER with Internet Mail Service (5.5.2653.19) id <11J098QX>; Thu, 13 Feb 2003 11:17:09 +0200 Message-ID: <6FEF757325DBD411B7DA000629A8A61ED6A4DA@MAIL-SERVER> From: Alex Agranov To: sip@ietf.org Subject: RE: [Sip] Silence Suppression in SDP for VoIP Date: Thu, 13 Feb 2003 11:17:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D340.AB86C8A0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D340.AB86C8A0 Content-Type: text/plain; charset="iso-8859-1" Sorry if I missed smth, but what was decided on silence suppression negotiation? Don't you think that the following case (described in one of my previous mails): (SIP UA) ----SIP---- (PSTN GW) ----SS7---- (PSTN GW) ----SIP---- (SIP UA) makes such negotiation meaningful? Best regards, Alex Agranov --- Chief Software Architect COMGATES Ltd. 15 Hagalim Avenue Herzliya, 46725 Israel Tel. +972.9.950.0404, Ext: 228 Fax. +972.9.950.0385 Mobile. +972.54.928435 ------_=_NextPart_001_01C2D340.AB86C8A0 Content-Type: text/html; charset="iso-8859-1" RE: [Sip] Silence Suppression in SDP for VoIP

Sorry if I missed smth, but what was decided on silence suppression negotiation?

Don't you think that the following case (described in one of my previous mails):

(SIP UA) ----SIP---- (PSTN GW) ----SS7---- (PSTN GW) ----SIP---- (SIP UA)

makes such negotiation meaningful?

Best regards,
                Alex Agranov
---
Chief Software Architect
COMGATES Ltd.
15 Hagalim Avenue
Herzliya, 46725
Israel
Tel. +972.9.950.0404,  Ext: 228
Fax. +972.9.950.0385
Mobile. +972.54.928435

------_=_NextPart_001_01C2D340.AB86C8A0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Feb 13 05:08:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08523 for ; Thu, 13 Feb 2003 05:08:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DAIhL08878 for sip-archive@odin.ietf.org; Thu, 13 Feb 2003 05:18:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DAINp08858; Thu, 13 Feb 2003 05:18:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DAHMp08816 for ; Thu, 13 Feb 2003 05:17:22 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08491 for ; Thu, 13 Feb 2003 05:07:03 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 13 Feb 2003 02:10:46 -0800 Received: from 143.239.211.125 by lw14fd.law14.hotmail.msn.com with HTTP; Thu, 13 Feb 2003 10:10:46 GMT X-Originating-IP: [143.239.211.125] From: "Jon Murphy" To: sip@ietf.org Date: Thu, 13 Feb 2003 10:10:46 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Feb 2003 10:10:46.0668 (UTC) FILETIME=[2D0C44C0:01C2D348] Subject: [Sip] message size Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, It seems to be well accepted that 500 bytes can be taken as a good average approximation of a SIP request. Is there a similarly well accepted value for a SIP provisional response? e.g. the "100 Trying" prov. response.. thanks for your help jon _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Feb 13 05:31:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08831 for ; Thu, 13 Feb 2003 05:31:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DAen010291 for sip-archive@odin.ietf.org; Thu, 13 Feb 2003 05:40:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DAeTp10276; Thu, 13 Feb 2003 05:40:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DAd7p10203 for ; Thu, 13 Feb 2003 05:39:07 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08816 for ; Thu, 13 Feb 2003 05:28:47 -0500 (EST) Received: from Natarajucl1127 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HA800IZTT79UZ@mta0.huawei.com> for sip@ietf.org; Thu, 13 Feb 2003 18:30:49 +0800 (CST) Date: Thu, 13 Feb 2003 16:02:25 +0530 From: "Nataraju A.B." Subject: Re: [Sip] message size To: Jon Murphy , sip@ietf.org Message-id: <005901c2d34b$343dd2b0$5d02120a@in.huawei.com> Organization: HTIPL MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: multipart/alternative; boundary="Boundary_(ID_RAbwZk96HUUCBPXr7QBtGw)" X-Priority: 3 X-MSMail-priority: Normal References: Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_RAbwZk96HUUCBPXr7QBtGw) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT ----- Original Message ----- From: Jon Murphy To: sip@ietf.org Sent: Thursday, February 13, 2003 3-40 Subject: [Sip] message size Hi, It seems to be well accepted that 500 bytes can be taken as a good average approximation of a SIP request. Is there a similarly well accepted value for a SIP provisional response? e.g. the "100 Trying" prov. response.. I feel its better to have a multiple of 2^x -> 512. also I feel for response messages 256 bytes suffices for most of the cases.. thanks for your help jon Regards, ------------------------------------------- Nataraju A.B. Huawei Technologies India Pvt. Ltd., Tel : +91-80-5217152 / 4 Xtn 142 ------------------------------------------- "Each problem that I solved became a rule which served afterwards to solve other problems." - Rene Descartes (1596-1650), "Discours de la Methode" --Boundary_(ID_RAbwZk96HUUCBPXr7QBtGw) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
----- Original Message -----
From: Jon Murphy
Sent: Thursday, February 13, 2003 3-40
Subject: [Sip] message size


Hi,

It seems to be well accepted that 500 bytes can be taken as a good average
approximation of a SIP request. Is there a similarly well accepted value for
a SIP provisional response? e.g. the "100 Trying" prov. response..
I feel its better to have a multiple of 2^x -> 512.
also I feel for response messages 256 bytes suffices for most of the cases..

thanks for your help

jon

Regards,
-------------------------------------------
Nataraju A.B.
Huawei Technologies India Pvt. Ltd.,
Tel : +91-80-5217152 / 4 Xtn 142
-------------------------------------------
"Each problem that I solved became a rule which served afterwards to solve other problems."
- Rene Descartes (1596-1650), "Discours de la Methode"
--Boundary_(ID_RAbwZk96HUUCBPXr7QBtGw)-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Feb 13 05:57:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09113 for ; Thu, 13 Feb 2003 05:57:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DB6nI10956 for sip-archive@odin.ietf.org; Thu, 13 Feb 2003 06:06:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DB6Qp10938; Thu, 13 Feb 2003 06:06:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DB5Zp10897 for ; Thu, 13 Feb 2003 06:05:35 -0500 Received: from mirlo.dit.upm.es (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09093 for ; Thu, 13 Feb 2003 05:55:15 -0500 (EST) Received: from faisan (faisan [138.4.50.4]) by mirlo.dit.upm.es (8.8.5/8.7.3) with SMTP id KAA11019 for ; Thu, 13 Feb 2003 10:59:39 GMT Reply-To: From: "Manuel Moreno" To: Date: Thu, 13 Feb 2003 11:59:16 +0100 Message-ID: <004601c2d34e$f556a000$0432048a@cipres.upm.es> 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 V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Over sessions and dialogs Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi everybody We have one SIP session with "n" dialogs... With BYE (and the specific tags) is posible to close one particular dialog in the SIP session ... Is possible to close all dialogs and the session with one BYE withot tags?? Thank you Manuel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Feb 13 06:18:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09433 for ; Thu, 13 Feb 2003 06:18:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DBSN212376 for sip-archive@odin.ietf.org; Thu, 13 Feb 2003 06:28:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DBRKp12343; Thu, 13 Feb 2003 06:27:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DBQdp12281 for ; Thu, 13 Feb 2003 06:26:39 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09405 for ; Thu, 13 Feb 2003 06:16:17 -0500 (EST) Received: from Natarajucl1127 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HA800I9MVENUP@mta0.huawei.com> for sip@ietf.org; Thu, 13 Feb 2003 19:18:25 +0800 (CST) Date: Thu, 13 Feb 2003 16:50:03 +0530 From: "Nataraju A.B." Subject: Re: [Sip] Over sessions and dialogs To: mmoreno@cipres.upm.es, sip@ietf.org Message-id: <008801c2d351$dbad13c0$5d02120a@in.huawei.com> Organization: HTIPL MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: multipart/alternative; boundary="Boundary_(ID_DZ467twxYIEr3XFfMkWqJg)" X-Priority: 3 X-MSMail-priority: Normal References: <004601c2d34e$f556a000$0432048a@cipres.upm.es> Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_DZ467twxYIEr3XFfMkWqJg) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT ----- Original Message ----- From: Manuel Moreno To: sip@ietf.org Sent: Thursday, February 13, 2003 4-29 Subject: [Sip] Over sessions and dialogs Hi everybody We have one SIP session with "n" dialogs... With BYE (and the specific tags) is posible to close one particular dialog in the SIP session ... ABN: Logically sepaking this is not required..... If I am missing something, please let me know.. Is possible to close all dialogs and the session with one BYE withot tags?? ABN: a 3261 compliant stack must be able to close all teh dialogs within that particular session. Thank you Manuel Regards, ------------------------------------------- Nataraju A.B. Huawei Technologies India Pvt. Ltd., Tel : +91-80-5217152 / 4 Xtn 142 ------------------------------------------- "Each problem that I solved became a rule which served afterwards to solve other problems." - Rene Descartes (1596-1650), "Discours de la Methode" --Boundary_(ID_DZ467twxYIEr3XFfMkWqJg) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
----- Original Message -----
Sent: Thursday, February 13, 2003 4-29
Subject: [Sip] Over sessions and dialogs

Hi everybody

We have one SIP session with "n" dialogs...

With BYE (and the specific tags) is posible to close one particular dialog
in the SIP session ...
ABN: Logically sepaking this is not required.....
If I am missing something, please let me know..

Is possible to close all dialogs and the session with one BYE withot tags??
ABN: a 3261 compliant stack must be able to close all teh dialogs within that particular session.

Thank you

Manuel
Regards,
-------------------------------------------
Nataraju A.B.
Huawei Technologies India Pvt. Ltd.,
Tel : +91-80-5217152 / 4 Xtn 142
-------------------------------------------
"Each problem that I solved became a rule which served afterwards to solve other problems."
- Rene Descartes (1596-1650), "Discours de la Methode"
--Boundary_(ID_DZ467twxYIEr3XFfMkWqJg)-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Feb 13 07:04:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10360 for ; Thu, 13 Feb 2003 07:04:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DCE3E15509 for sip-archive@odin.ietf.org; Thu, 13 Feb 2003 07:14:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DCDVp15477; Thu, 13 Feb 2003 07:13:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DCC8p15443 for ; Thu, 13 Feb 2003 07:12:08 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10313 for ; Thu, 13 Feb 2003 07:01:45 -0500 (EST) Received: from cisco.com (desh.cisco.com [192.122.173.43]) by sj-msg-core-2.cisco.com (8.12.2/8.12.6) with ESMTP id h1DC5Esv007320 for ; Thu, 13 Feb 2003 04:05:15 -0800 (PST) Received: from rkalshet-w2k.cisco.com ([10.77.138.171]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id RAA16634 for ; Thu, 13 Feb 2003 17:34:59 +0530 (IST) Message-Id: <4.3.2.7.2.20030213163904.0356c838@desh.cisco.com> X-Sender: rkalshet@desh.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Feb 2003 17:35:25 +0530 To: sip@ietf.org From: "Rajesh Kalshetty (rkalshet)" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Sip] INVITE client Transaction.... Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi all, I have a question Regarding the INVITE client Transactions state m/c . When a client transaction moves to the proceeding state after receiving a provisional response by how much time it has to wait in that state for a final response. A Invite B |------------------>| | 1xx | |<------------------| | | | x client crashes. | | suppose that client B crashes after it sends a provisional response,i don't find any way for the A's client transaction to come out of the proceeding state in RFC. Regrds, Rajesh k. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Feb 13 09:45:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13185 for ; Thu, 13 Feb 2003 09:45:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DEtNX25204 for sip-archive@odin.ietf.org; Thu, 13 Feb 2003 09:55:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DEsqp25172; Thu, 13 Feb 2003 09:54:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CIjFp12560 for ; Wed, 12 Feb 2003 13:45:15 -0500 Received: from sporus.bol.com.br (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11290 for ; Wed, 12 Feb 2003 13:35:14 -0500 (EST) Received: from bol.com.br (200.221.24.129) by sporus.bol.com.br (5.1.071) id 3E25BF46008B7B2B for sip@ietf.org; Wed, 12 Feb 2003 16:41:05 -0200 Date: Wed, 12 Feb 2003 16:38:57 -0200 Message-Id: MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" From: "stellachung" To: sip@ietf.org X-XaM3-API-Version: 2.4 R3 ( B4 ) X-SenderIP: 143.106.12.23 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1CIjFp12561 Subject: [Sip] Question Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, my name is Stella and I´m having some doubts about SIP. I want to know if there is any standard defined about Mobility using SIP, like RFC´s ou Drafts. Thanks a lot. __________________________________________________________________________ E-mail Premium BOL Antivírus, anti-spam e até 100 MB de espaço. Assine já! http://email.bol.com.br/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Feb 13 10:26:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15661 for ; Thu, 13 Feb 2003 10:26:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DFaPn28023 for sip-archive@odin.ietf.org; Thu, 13 Feb 2003 10:36:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DFa0p27984; Thu, 13 Feb 2003 10:36:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DFYvp27888 for ; Thu, 13 Feb 2003 10:34:57 -0500 Received: from pmesmtp01.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15597 for ; Thu, 13 Feb 2003 10:24:31 -0500 (EST) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HA9000156Z47R@firewall.wcom.com> for sip@ietf.org; Thu, 13 Feb 2003 15:28:16 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HA900I016W7PT@dgismtp02.wcomnet.com>; Thu, 13 Feb 2003 15:28:16 +0000 (GMT) Received: from hsinnreich2 ([166.42.33.2]) by dgismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HA900IFR6Y53W@dgismtp02.wcomnet.com>; Thu, 13 Feb 2003 15:27:44 +0000 (GMT) Date: Thu, 13 Feb 2003 09:27:41 -0600 From: Henry Sinnreich Subject: RE: [Sip] Question In-reply-to: To: "'stellachung'" , sip@ietf.org Message-id: <000101c2d374$748ba0d0$02212aa6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=iso-8859-1 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1DFYwp27889 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit >> about Mobility using SIP There is much information at http://www.cs.columbia.edu/~hgs/sip/drafts_mobility.html and http://www.argreenhouse.com/sip-mobile/ Henry > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of stellachung > Sent: Wednesday, February 12, 2003 12:39 PM > To: sip@ietf.org > Subject: [Sip] Question > > > Hi, my name is Stella and I´m having some doubts about > SIP. I want to know if there is any standard defined > about Mobility using SIP, like RFC´s ou Drafts. > Thanks a lot. > > > > ______________________________________________________________ > ____________ > E-mail Premium BOL > Antivírus, anti-spam e até 100 MB de espaço. Assine já! > http://email.bol.com.br/ > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Feb 13 10:27:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15693 for ; Thu, 13 Feb 2003 10:27:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DFbSX28681 for sip-archive@odin.ietf.org; Thu, 13 Feb 2003 10:37:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DFbAp28376; Thu, 13 Feb 2003 10:37:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DFZZp27949 for ; Thu, 13 Feb 2003 10:35:35 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15610 for ; Thu, 13 Feb 2003 10:25:06 -0500 (EST) Received: from prasannacl1105 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HA900JUL6XB9I@mta0.huawei.com> for sip@ietf.org; Thu, 13 Feb 2003 23:27:13 +0800 (CST) Date: Thu, 13 Feb 2003 21:00:13 +0530 From: Prasanna Venkatesh Subject: RE: [Sip] Over sessions and dialogs In-reply-to: <004601c2d34e$f556a000$0432048a@cipres.upm.es> To: mmoreno@cipres.upm.es, sip@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi, As per RFC-3261 it is not allowed to send a BYE unless and until you have a To tag i.e. a BYE is only allowed in the "early" state in a client. And in RFC-2543-bis02, no overlapping of transactions are allowed. Hence your scenario can never araise. One more clarification on your question, there cannot be more than one dialog unless and until there is a To tag. Cheers, Prasanna -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Manuel Moreno Sent: Thursday, February 13, 2003 4:29 PM To: sip@ietf.org Subject: [Sip] Over sessions and dialogs Hi everybody We have one SIP session with "n" dialogs... With BYE (and the specific tags) is posible to close one particular dialog in the SIP session ... Is possible to close all dialogs and the session with one BYE withot tags?? Thank you Manuel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Feb 13 10:27:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15707 for ; Thu, 13 Feb 2003 10:27:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DFbVt28695 for sip-archive@odin.ietf.org; Thu, 13 Feb 2003 10:37:31 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DFbFp28486; Thu, 13 Feb 2003 10:37:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DFZsp27973 for ; Thu, 13 Feb 2003 10:35:54 -0500 Received: from mta2 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15614 for ; Thu, 13 Feb 2003 10:25:26 -0500 (EST) Received: from mta2 (localhost [127.0.0.1]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTP id <0HA900292722F9@mta2.huawei.com> for sip@ietf.org; Thu, 13 Feb 2003 23:30:02 +0800 (CST) Received: from mailin.huawei.com ([10.18.1.252]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTP id <0HA9003CV721R3@mta2.huawei.com> for sip@ietf.org; Thu, 13 Feb 2003 23:30:02 +0800 (CST) Received: from nkannanCL1068 ([10.18.2.104]) by mailin.huawei.com (Netscape Messaging Server 4.15) with ESMTP id HA974O00.U17; Thu, 13 Feb 2003 23:31:36 +0800 Date: Thu, 13 Feb 2003 20:56:10 +0530 From: Natesan Kannan Subject: Re: [Sip] INVITE client Transaction.... To: "Rajesh Kalshetty (rkalshet)" , sip@ietf.org Message-id: <001e01c2d374$3cbe3280$6802120a@in.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4.3.2.7.2.20030213163904.0356c838@desh.cisco.com> Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Excerpt from a previous query on the same subject and Jonathan's reply embedded... -Kannan ********* This is an application issue. It can decide to give up at any time and send CANCEL. We don't want to specify the maximum time a user will let the phone ring. -Jonathan R. Vijaya Venkatachalam wrote: > Hi, > > I have a question regarding the INVITE transaction > state machine. > > It seems that in RFC 3261 - transaction state machine for > INVITE transactions, there is a potential for > the client side transaction to indefinitely be > in the "Proceeding" state since all timers > are cancelled on the reception of a 1xx response. > > Can somebody tell me how the client side transaction > can come out of this state, if the server transaction on > the remote end dies? > > Is it that the timer B is not cancelled and that only > timer A is cancelled when the 1xx is received or is > there some other means. > > Appreciate a quick response. > > Thanks, > Vijaya ********* ----- Original Message ----- From: "Rajesh Kalshetty (rkalshet)" To: Sent: Thursday, February 13, 2003 5:35 PM Subject: [Sip] INVITE client Transaction.... > > Hi all, > > I have a question Regarding the INVITE client Transactions state m/c . When > a client transaction moves to the proceeding state after receiving a > provisional response by how much time it has to wait in that state for a > final response. > > > A Invite B > |------------------>| > | 1xx | > |<------------------| > | | > | x client crashes. > | | > > suppose that client B crashes after it sends a provisional response,i don't > find any way for the A's client transaction to come out of the proceeding > state in RFC. > > > Regrds, > Rajesh k. > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Feb 13 15:53:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29622 for ; Thu, 13 Feb 2003 15:53:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DKvDd19438 for sip-archive@odin.ietf.org; Thu, 13 Feb 2003 15:57:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DKutp19410; Thu, 13 Feb 2003 15:56:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DKtPp19315 for ; Thu, 13 Feb 2003 15:55:25 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29544 for ; Thu, 13 Feb 2003 15:51:34 -0500 (EST) Received: from dingdong.cisco.com (IDENT:mirapoint@dingdong.cisco.com [64.102.17.16]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1DKt7JR010163; Thu, 13 Feb 2003 15:55:07 -0500 (EST) Received: from cisco.com (dhcp-64-102-93-108.cisco.com [64.102.93.108]) by dingdong.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABL15076; Thu, 13 Feb 2003 15:55:05 -0500 (EST) Message-ID: <3E4C062A.9090209@cisco.com> Date: Thu, 13 Feb 2003 15:55:06 -0500 From: suheel hussain Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'stellachung'" CC: Henry Sinnreich , sip@ietf.org Subject: Re: [Sip] Question References: <000101c2d374$748ba0d0$02212aa6@hsinnreich2> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1DKtPp19320 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Stella, you can also try these URLs. http://www.softarmor.com/sipping/drafts/ http://www.softarmor.com/sipwg/drafts/ -suheel Henry Sinnreich wrote: >>>about Mobility using SIP >> > > There is much information at > > http://www.cs.columbia.edu/~hgs/sip/drafts_mobility.html and > > http://www.argreenhouse.com/sip-mobile/ > > Henry > > >>-----Original Message----- >>From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On >>Behalf Of stellachung >>Sent: Wednesday, February 12, 2003 12:39 PM >>To: sip@ietf.org >>Subject: [Sip] Question >> >> >>Hi, my name is Stella and I´m having some doubts about >>SIP. I want to know if there is any standard defined >>about Mobility using SIP, like RFC´s ou Drafts. >>Thanks a lot. >> >> >> >>______________________________________________________________ >>____________ >>E-mail Premium BOL >>Antivírus, anti-spam e até 100 MB de espaço. Assine já! >>http://email.bol.com.br/ >> >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current >>sip Use sipping@ietf.org for new developments on the >>application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Feb 13 19:08:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22901 for ; Thu, 13 Feb 2003 19:08:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1E0BU332192 for sip-archive@odin.ietf.org; Thu, 13 Feb 2003 19:11:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1E0Awp32176; Thu, 13 Feb 2003 19:10:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1E09bp32119 for ; Thu, 13 Feb 2003 19:09:37 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22488 for ; Thu, 13 Feb 2003 19:05:43 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h1E09OLc018305 for ; Thu, 13 Feb 2003 18:09:24 -0600 From: "Dean Willis" To: Date: Thu, 13 Feb 2003 18:09:09 -0600 Message-ID: <000001c2d3bd$4c6d0cd0$ee036e3f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1E09bp32120 Subject: [Sip] SIP Congestion Safety draft revised Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Based on list discussion, I've made a few small revisions to: http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-congestsafe-01.html http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-congestsafe-01.txt http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-congestsafe-01.xml The basic changes here are that we've added some discussion of dealing with responses, and a new response code for a UAS to use if it needs to send a big response and doesn't know that the path is congestion safe and therefore can't send the big response, as well as some discussion of what we mean by this. The basic approach taken here is "If a UAS receives a request that is not marked congestion-safe, then it can't send a response larger than the request." We add a new response code (514) for the UAS to send if it can't meet this constraint. You might wonder "Gee, doesn't this mean that if some fool sends a HUGE request through a bunch of unsafe proxies to a UAS, that the UAS can then send a HUGE response?" The problem is that a complete solution requires solving reverse path MTU discovery, and I just don't see that happening. So, we have something of a compromise that makes a moderately reasonable guess about non-deterministic things. Of course, life is much better if the proxies in between implement congestion-safety, so that we don't run into this problem at all. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Feb 14 06:49:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17435 for ; Fri, 14 Feb 2003 06:49:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1EBrI919041 for sip-archive@odin.ietf.org; Fri, 14 Feb 2003 06:53:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EBqnp18959; Fri, 14 Feb 2003 06:52:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EBmmp18621 for ; Fri, 14 Feb 2003 06:48:48 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17006; Fri, 14 Feb 2003 06:44:42 -0500 (EST) Message-Id: <200302141144.GAA17006@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 14 Feb 2003 06:44:41 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-referredby-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : The SIP Referred-By Mechanism Author(s) : R. Sparks Filename : draft-ietf-sip-referredby-01.txt Pages : 24 Date : 2003-2-13 The SIP REFER method [2] provides a mechanism where one party (the referrer) gives a second party (the referree) an arbitrary URI to reference. If that URI is a SIP URI, the referree will send a SIP request, often an INVITE, to that URI (the refer target). This document extends the REFER method allowing the referrer to provide information about the reference to the refer target using the referree as an intermediary. This information includes the identity of the referrer and the URI to which the referrer referred. The mechanism utilizes S/MIME to help protect this information from a malicious intermediary. This protection is optional, but a recipient may refuse to accept a request unless it is present. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-referredby-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-referredby-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-referredby-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-13152905.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-referredby-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-referredby-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-13152905.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Feb 14 07:54:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21235 for ; Fri, 14 Feb 2003 07:54:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1ECwSI24090 for sip-archive@odin.ietf.org; Fri, 14 Feb 2003 07:58:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ECpkp23816; Fri, 14 Feb 2003 07:51:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ECo5p23764 for ; Fri, 14 Feb 2003 07:50:05 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21026; Fri, 14 Feb 2003 07:45:56 -0500 (EST) Message-Id: <200302141245.HAA21026@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 14 Feb 2003 07:45:56 -0500 Subject: [Sip] I-D ACTION:draft-johnston-sip-osp-token-04.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Session Initiation Protocol Private Extension for an OSP Authorization Token Author(s) : A. Johnston, D. Rawlins Filename : draft-johnston-sip-osp-token-04.txt Pages : 9 Date : 2003-2-13 This draft proposes a private extension to the Session Initiation Protocol (SIP) for carrying OSP (Open Settlements Protocol) authorization tokens in applications such as clearinghouses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-johnston-sip-osp-token-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-johnston-sip-osp-token-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-johnston-sip-osp-token-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-14080437.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-johnston-sip-osp-token-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-johnston-sip-osp-token-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-14080437.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Feb 14 12:12:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27626 for ; Fri, 14 Feb 2003 12:12:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1EHFoS08586 for sip-archive@odin.ietf.org; Fri, 14 Feb 2003 12:15:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EHFEp08558; Fri, 14 Feb 2003 12:15:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EH7Rp08112 for ; Fri, 14 Feb 2003 12:07:27 -0500 Received: from revere.sonusnet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27317 for ; Fri, 14 Feb 2003 12:02:57 -0500 (EST) Received: from host-1.ttiworld.com (host-1 [10.10.100.6]) by revere.sonusnet.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id h1EH6X710278 for ; Fri, 14 Feb 2003 12:06:33 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] I-D ACTION:draft-johnston-sip-osp-token-04.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Fri, 14 Feb 2003 11:06:42 -0600 Message-ID: <81877B9826317E448987499EB79AE7024F6947@host-1.ttiworld.com> Thread-Topic: [Sip] I-D ACTION:draft-johnston-sip-osp-token-04.txt Thread-Index: AcLUKAVNqf2YAXYVSG+2Iv/TcnOseAAI1cSg From: "Kevin Summers" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1EH7Rp08113 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I think that it might be likely (actually, highly likely) that multiple domains might "touch" a call and there could be a requirement for multiple OSP tokens within a request. Would it make sense to include something akin to the Authorization header's realm string with the token? I am thinking that it would be something that qualifies the token. Any comments? -Kevin -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Friday, February 14, 2003 6:46 AM Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-johnston-sip-osp-token-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Session Initiation Protocol Private Extension for an OSP Authorization Token Author(s) : A. Johnston, D. Rawlins Filename : draft-johnston-sip-osp-token-04.txt Pages : 9 Date : 2003-2-13 This draft proposes a private extension to the Session Initiation Protocol (SIP) for carrying OSP (Open Settlements Protocol) authorization tokens in applications such as clearinghouses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-johnston-sip-osp-token-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-johnston-sip-osp-token-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-johnston-sip-osp-token-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Feb 14 15:09:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03334 for ; Fri, 14 Feb 2003 15:09:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1EKCxK21409 for sip-archive@odin.ietf.org; Fri, 14 Feb 2003 15:12:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EKCHp21365; Fri, 14 Feb 2003 15:12:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EK9Jp21235 for ; Fri, 14 Feb 2003 15:09:19 -0500 Received: from dgesmtp01.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03213 for ; Fri, 14 Feb 2003 15:05:01 -0500 (EST) Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.wcom.com (Iplanet MTA) with ESMTP id <0HAB00MB4ED9QR@firewall.wcom.com> for sip@ietf.org; Fri, 14 Feb 2003 20:03:10 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HAB00901ECUFD@pmismtp02.wcomnet.com>; Fri, 14 Feb 2003 20:03:10 +0000 (GMT) Received: from hsinnreich2 ([166.50.105.79]) by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HAB0095RECX8U@pmismtp02.wcomnet.com>; Fri, 14 Feb 2003 20:03:02 +0000 (GMT) Date: Fri, 14 Feb 2003 14:02:58 -0600 From: Henry Sinnreich Subject: RE: [Sip] I-D ACTION:draft-johnston-sip-osp-token-04.txt In-reply-to: <81877B9826317E448987499EB79AE7024F6947@host-1.ttiworld.com> To: "'Kevin Summers'" , sip@ietf.org Message-id: <000901c2d464$1502fa50$4f6932a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Any comments? Kevin, > that multiple domains might "touch" a call and there could be > a requirement for multiple OSP tokens within a request. Would > it make sense to include something akin to the Authorization > header's realm string with the token? The model for the inter-domain AAA is that only the end networks and a possible clearing house server are aware of each call in the 'retail' mode. There may be several transit networks, but for scalability reasons, they are transparent. It is a matter of peering agreements between ISPs to handle inter-ISP traffic, not matter what the application is. If transit networks would be aware of each call and accounting would be required, we would be back to the PSTN model, not a desirable model for the Internet IMHO. Having said this, domains may chose to insert multiple tokens. But this is not a good reason for the IETF to legitimize PSTN-like complications, per call billing and multi-party settlement models. My two cents, Henry > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Kevin Summers > Sent: Friday, February 14, 2003 11:07 AM > To: sip@ietf.org > Subject: RE: [Sip] I-D ACTION:draft-johnston-sip-osp-token-04.txt > > > I think that it might be likely (actually, highly likely) > that multiple domains might "touch" a call and there could be > a requirement for multiple OSP tokens within a request. Would > it make sense to include something akin to the Authorization > header's realm string with the token? I am thinking that it > would be something that qualifies the token. > > Any comments? > > -Kevin > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Friday, February 14, 2003 6:46 AM > Cc: sip@ietf.org > Subject: [Sip] I-D ACTION:draft-johnston-sip-osp-token-04.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Session Initiation Protocol Private Extension > for an > OSP Authorization Token > Author(s) : A. Johnston, D. Rawlins > Filename : draft-johnston-sip-osp-token-04.txt > Pages : 9 > Date : 2003-2-13 > > This draft proposes a private extension to the Session Initiation > Protocol (SIP) for carrying OSP (Open Settlements Protocol) > authorization tokens in applications such as clearinghouses. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-johnston-sip-osp-tok > en-04.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body > of the message. > > Internet-Drafts are also available by anonymous FTP. Login > with the username "anonymous" and a password of your e-mail > address. After logging in, type "cd internet-drafts" and then > "get draft-johnston-sip-osp-token-04.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-johnston-sip-osp-token-04.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail > reader implementation to automatically retrieve the ASCII > version of the Internet-Draft. > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Feb 14 15:18:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03556 for ; Fri, 14 Feb 2003 15:18:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1EKMeO21876 for sip-archive@odin.ietf.org; Fri, 14 Feb 2003 15:22:40 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EKMLp21862; Fri, 14 Feb 2003 15:22:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EKLxp21834 for ; Fri, 14 Feb 2003 15:21:59 -0500 Received: from revere.sonusnet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03535 for ; Fri, 14 Feb 2003 15:17:40 -0500 (EST) Received: from host-1.ttiworld.com (host-1 [10.10.100.6]) by revere.sonusnet.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id h1EKLF728265; Fri, 14 Feb 2003 15:21:15 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] I-D ACTION:draft-johnston-sip-osp-token-04.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Fri, 14 Feb 2003 14:21:25 -0600 Message-ID: <81877B9826317E448987499EB79AE7024DAEAF@host-1.ttiworld.com> Thread-Topic: [Sip] I-D ACTION:draft-johnston-sip-osp-token-04.txt Thread-Index: AcLUZOoCV8ZFXw7jQbSiTa4GZuuSxQAACSaA From: "Kevin Summers" To: "Henry Sinnreich" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1EKLxp21835 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit My intent was not to suggest that we revert to a PSTN model -- only that more than one clearinghouse may be involved. How a set of ISPs choose to do business should be their choice. Seems that multi-party scenarios may also require support of more than one token -- for which context of the token is needed. -----Original Message----- From: Henry Sinnreich [mailto:Henry.Sinnreich@wcom.com] Sent: Friday, February 14, 2003 2:03 PM To: 'Kevin Summers'; sip@ietf.org Subject: RE: [Sip] I-D ACTION:draft-johnston-sip-osp-token-04.txt > Any comments? Kevin, > that multiple domains might "touch" a call and there could be > a requirement for multiple OSP tokens within a request. Would > it make sense to include something akin to the Authorization > header's realm string with the token? The model for the inter-domain AAA is that only the end networks and a possible clearing house server are aware of each call in the 'retail' mode. There may be several transit networks, but for scalability reasons, they are transparent. It is a matter of peering agreements between ISPs to handle inter-ISP traffic, not matter what the application is. If transit networks would be aware of each call and accounting would be required, we would be back to the PSTN model, not a desirable model for the Internet IMHO. Having said this, domains may chose to insert multiple tokens. But this is not a good reason for the IETF to legitimize PSTN-like complications, per call billing and multi-party settlement models. My two cents, Henry > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Kevin Summers > Sent: Friday, February 14, 2003 11:07 AM > To: sip@ietf.org > Subject: RE: [Sip] I-D ACTION:draft-johnston-sip-osp-token-04.txt > > > I think that it might be likely (actually, highly likely) > that multiple domains might "touch" a call and there could be > a requirement for multiple OSP tokens within a request. Would > it make sense to include something akin to the Authorization > header's realm string with the token? I am thinking that it > would be something that qualifies the token. > > Any comments? > > -Kevin > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Friday, February 14, 2003 6:46 AM > Cc: sip@ietf.org > Subject: [Sip] I-D ACTION:draft-johnston-sip-osp-token-04.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Session Initiation Protocol Private Extension > for an > OSP Authorization Token > Author(s) : A. Johnston, D. Rawlins > Filename : draft-johnston-sip-osp-token-04.txt > Pages : 9 > Date : 2003-2-13 > > This draft proposes a private extension to the Session Initiation > Protocol (SIP) for carrying OSP (Open Settlements Protocol) > authorization tokens in applications such as clearinghouses. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-johnston-sip-osp-tok > en-04.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body > of the message. > > Internet-Drafts are also available by anonymous FTP. Login > with the username "anonymous" and a password of your e-mail > address. After logging in, type "cd internet-drafts" and then > "get draft-johnston-sip-osp-token-04.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-johnston-sip-osp-token-04.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail > reader implementation to automatically retrieve the ASCII > version of the Internet-Draft. > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Feb 14 17:09:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06755 for ; Fri, 14 Feb 2003 17:09:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1EMDLw30021 for sip-archive@odin.ietf.org; Fri, 14 Feb 2003 17:13:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EMCjp29986; Fri, 14 Feb 2003 17:12:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EMA5p29890 for ; Fri, 14 Feb 2003 17:10:05 -0500 Received: from dgesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06690 for ; Fri, 14 Feb 2003 17:05:43 -0500 (EST) Received: from pmismtp06.wcomnet.com ([166.38.62.54]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0HAB00I9JJXXED@firewall.wcom.com> for sip@ietf.org; Fri, 14 Feb 2003 22:03:33 +0000 (GMT) Received: from pmismtp06.wcomnet.com by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HAB00101JQWTG@pmismtp06.wcomnet.com>; Fri, 14 Feb 2003 22:03:33 +0000 (GMT) Received: from hsinnreich2 ([166.50.105.79]) by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HAB0023CJWZ0W@pmismtp06.wcomnet.com>; Fri, 14 Feb 2003 22:03:02 +0000 (GMT) Date: Fri, 14 Feb 2003 16:02:59 -0600 From: Henry Sinnreich Subject: RE: [Sip] I-D ACTION:draft-johnston-sip-osp-token-04.txt In-reply-to: <81877B9826317E448987499EB79AE7024DAEAF@host-1.ttiworld.com> To: "'Kevin Summers'" , sip@ietf.org Message-id: <000101c2d474$d7a58900$4f6932a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > -- only that more than one clearinghouse may be involved. Glad for this clarification, but would like to make sure we have the same understanding: 1. There is a choice between several clearinghouses, just like having more than one credit card, or 2. Use you own clearinghouse, which in turn settles though another clearinghouse. This is a valid scenario as well, but inter-clearinghouse transactions would be quite removed from SIP and may use something else, such as web services as a mechanism. This brings back the point, why SIP AAA should not target AAA platforms that are not known to be used commercially, like DIAMETER discussed in other messages here (the SIP AAA I-D), but web services, so as to be consistent with e-commerce going forward. Henry > -----Original Message----- > From: Kevin Summers [mailto:Kevin.Summers@sonusnet.com] > Sent: Friday, February 14, 2003 2:21 PM > To: Henry Sinnreich; sip@ietf.org > Subject: RE: [Sip] I-D ACTION:draft-johnston-sip-osp-token-04.txt > > > My intent was not to suggest that we revert to a PSTN model > -- only that more than one clearinghouse may be involved. How > a set of ISPs choose to do business should be their choice. > Seems that multi-party scenarios may also require support of > more than one token -- for which context of the token is needed. > > -----Original Message----- > From: Henry Sinnreich [mailto:Henry.Sinnreich@wcom.com] > Sent: Friday, February 14, 2003 2:03 PM > To: 'Kevin Summers'; sip@ietf.org > Subject: RE: [Sip] I-D ACTION:draft-johnston-sip-osp-token-04.txt > > > > Any comments? > > Kevin, > > > that multiple domains might "touch" a call and there could be a > > requirement for multiple OSP tokens within a request. Would it make > > sense to include something akin to the Authorization > header's realm > > string with the token? > > The model for the inter-domain AAA is that only the end > networks and a possible clearing house server are aware of > each call in the 'retail' mode. There may be several transit > networks, but for scalability reasons, they are transparent. > It is a matter of peering agreements between ISPs to handle > inter-ISP traffic, not matter what the application is. > > If transit networks would be aware of each call and > accounting would be required, we would be back to the PSTN > model, not a desirable model for the Internet IMHO. > > Having said this, domains may chose to insert multiple > tokens. But this is not a good reason for the IETF to > legitimize PSTN-like complications, per call billing and > multi-party settlement models. > > My two cents, Henry > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > > Behalf Of Kevin Summers > > Sent: Friday, February 14, 2003 11:07 AM > > To: sip@ietf.org > > Subject: RE: [Sip] I-D ACTION:draft-johnston-sip-osp-token-04.txt > > > > > > I think that it might be likely (actually, highly likely) > > that multiple domains might "touch" a call and there could be > > a requirement for multiple OSP tokens within a request. Would > > it make sense to include something akin to the Authorization > > header's realm string with the token? I am thinking that it > > would be something that qualifies the token. > > > > Any comments? > > > > -Kevin > > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Friday, February 14, 2003 6:46 AM > > Cc: sip@ietf.org > > Subject: [Sip] I-D ACTION:draft-johnston-sip-osp-token-04.txt > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > > > > Title : Session Initiation Protocol Private Extension > > for an > > OSP Authorization Token > > Author(s) : A. Johnston, D. Rawlins > > Filename : draft-johnston-sip-osp-token-04.txt > > Pages : 9 > > Date : 2003-2-13 > > > > This draft proposes a private extension to the Session Initiation > > Protocol (SIP) for carrying OSP (Open Settlements Protocol) > > authorization tokens in applications such as clearinghouses. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-johnston-sip-osp-tok > > en-04.txt > > > > To remove yourself from the IETF Announcement list, send a > message to > > ietf-announce-request with the word unsubscribe in the body > > of the message. > > > > Internet-Drafts are also available by anonymous FTP. Login > > with the username "anonymous" and a password of your e-mail > > address. After logging in, type "cd internet-drafts" and then > > "get draft-johnston-sip-osp-token-04.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-johnston-sip-osp-token-04.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant > > mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail > > reader implementation to automatically retrieve the ASCII > > version of the Internet-Draft. > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current > > sip Use sipping@ietf.org for new developments on the > > application of sip > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Mon Feb 17 10:33:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24063 for ; Mon, 17 Feb 2003 10:33:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1HFcqE01752 for sip-archive@odin.ietf.org; Mon, 17 Feb 2003 10:38:52 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HFcAp01718; Mon, 17 Feb 2003 10:38:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HFZFp00787 for ; Mon, 17 Feb 2003 10:35:15 -0500 Received: from i3smtp.i3domain.inin.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23902 for ; Mon, 17 Feb 2003 10:29:36 -0500 (EST) Received: from I3EXCHANGE [172.16.1.4] by i3smtp.i3domain.inin.com - SurfControl E-mail Filter (4.5); Monday, 17 February 2003, 10:33:22 Message-ID: <58A40B582A73F54AB5D8739C0678F3A803E3917D@i3exchange.i3domain.inin.com> From: "Snyder, Duke" To: Date: Mon, 17 Feb 2003 10:33:17 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: [Sip] I-D ACTION:draft-johnston-sip-osp-token-04.txt Thread-Index: AcLUdyy8sTbZizzbR1myLuha2jWosgCHpWAg Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1HFZFp00788 Subject: [Sip] draft-mahy-sip-peer-3pcc-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Is there any mechanism to have an application 'request' that the phone answer it's alerting call. draft-mahy-sip-peer-3pcc-00.txt has a mechanism for a dialer app to inform the phone to dial or disconnect, but not one to answer. A typically example of this is that the dialer makes the call, and then once a human is detected, route the call to an agent by calling the agents phone. The missing part here is that the agent has to physically pick up the phone, rather than having the phone automatically answer the call. Part 2: Does anyone know if any phones support (or plan to support) the current draft? Thanks, Duke Snyder Interactive Intelligence _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Feb 18 12:36:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02671 for ; Tue, 18 Feb 2003 12:36:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1IHgX312056 for sip-archive@odin.ietf.org; Tue, 18 Feb 2003 12:42:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1IHfTp11996; Tue, 18 Feb 2003 12:41:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1IHb5p11228 for ; Tue, 18 Feb 2003 12:37:05 -0500 Received: from mail.cit.ie (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02529 for ; Tue, 18 Feb 2003 12:30:51 -0500 (EST) Received: from EEB174W2Kvk (unverified [157.190.81.172]) by cit.ie (Rockliffe SMTPRA 5.2.5) with SMTP id for ; Tue, 18 Feb 2003 15:19:42 +0000 Reply-To: From: "Valerie Kenneally" To: Date: Tue, 18 Feb 2003 15:31:51 -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.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] SIP messages Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, Just wondering if a document has been written discussing the different SIP messages and the headers and contents they contain. Thanks in advance, Valerie Kenneally -------------------Legal Disclaimer--------------------------------------- The above electronic mail transmission is confidential and intended only for the person to whom it is addressed. Its contents may be protected by legal and/or professional privilege. Should it be received by you in error please contact the sender at the above quoted email address. Any unauthorised form of reproduction of this message is strictly prohibited. The Institute does not guarantee the security of any information electronically transmitted and is not liable if the information contained in this communication is not a proper and complete record of the message as transmitted by the sender nor for any delay in its receipt. ---------------------------------------------------------------------------------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Feb 18 13:57:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05032 for ; Tue, 18 Feb 2003 13:57:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1IJ32k17435 for sip-archive@odin.ietf.org; Tue, 18 Feb 2003 14:03:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1IJ2Xp17393; Tue, 18 Feb 2003 14:02:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1IIxSp17203 for ; Tue, 18 Feb 2003 13:59:28 -0500 Received: from mail.cit.ie (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04943 for ; Tue, 18 Feb 2003 13:53:14 -0500 (EST) Received: from EEB174W2Kvk (unverified [157.190.81.172]) by cit.ie (Rockliffe SMTPRA 5.2.5) with SMTP id for ; Tue, 18 Feb 2003 18:45:06 +0000 Reply-To: From: "Valerie Kenneally" To: Date: Tue, 18 Feb 2003 18:57:16 -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.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] To and From header contents Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, In RFC 3261 in section 12.2.1.1 Generating the Request, it states "Usage of the URI from the To and From fields in the original request within subsequent requests is done for backwards compatibility with RFC 2543, which used the URI for dialog identification. In this specification, only the tags are used for dialog identification. It is expected that mandatory reflection of the original To and From URI in mid-dialog requests will be deprecated in a subsequent revision of this specification." Is this likely to happen? If so what would the To and From URIs be replaced with? Some feedback on this issue asap would be greatly appreciated Thanks in advance, Valerie Kenneally -------------------Legal Disclaimer--------------------------------------- The above electronic mail transmission is confidential and intended only for the person to whom it is addressed. Its contents may be protected by legal and/or professional privilege. Should it be received by you in error please contact the sender at the above quoted email address. Any unauthorised form of reproduction of this message is strictly prohibited. The Institute does not guarantee the security of any information electronically transmitted and is not liable if the information contained in this communication is not a proper and complete record of the message as transmitted by the sender nor for any delay in its receipt. ---------------------------------------------------------------------------------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Feb 18 18:25:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11333 for ; Tue, 18 Feb 2003 18:25:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1INUsO03122 for sip-archive@odin.ietf.org; Tue, 18 Feb 2003 18:30:54 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1INUXp03103; Tue, 18 Feb 2003 18:30:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1INSKp02995 for ; Tue, 18 Feb 2003 18:28:20 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11250; Tue, 18 Feb 2003 18:22:01 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h1INO2JX008621; Tue, 18 Feb 2003 18:24:02 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Feb 2003 17:25:48 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3C80833@dyn-tx-exch-001.dynamicsoft.com> From: Kelvin Porter To: mmusic@ietf.org, "'sip@ietf.org'" Date: Tue, 18 Feb 2003 17:25:48 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Java SDP API - JSR 141: Public Review 2 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, There is a new version of the Java SDP API available for review. Thank you for your consideration. Regards, Kelvin R. Porter -----Original Message----- From: Harold Ogle [mailto:harold.ogle@SUN.COM] Sent: Thursday, February 13, 2003 12:35 PM To: JCP-INTEREST@JAVA.SUN.COM Subject: JSR 141: Public Review 2 The Expert Group for JSR-000141 SDP API has released a second public review draft, which is now available from http://jcp.org/aboutJava/communityprocess/review/jsr141/index2.html This public review closes on 15 March 2003. =========================================================================== To unsubscribe, send email to listserv@java.sun.com and include in the body of the message "signoff JCP-INTEREST". For general help, send email to listserv@java.sun.com and include in the body of the message "help". _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Feb 18 18:51:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11921 for ; Tue, 18 Feb 2003 18:51:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1INuqF04877 for sip-archive@odin.ietf.org; Tue, 18 Feb 2003 18:56:52 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1INuSp04867; Tue, 18 Feb 2003 18:56:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1INtBp04815 for ; Tue, 18 Feb 2003 18:55:11 -0500 Received: from mail.bredband.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11854 for ; Tue, 18 Feb 2003 18:48:51 -0500 (EST) Received: from b2mail01.bredband.local ([192.168.46.46]) by mail.bredband.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 19 Feb 2003 00:52:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Sip] INVITE, CANCEL and BYE, re-transitions Date: Wed, 19 Feb 2003 00:52:38 +0100 Message-ID: Thread-Topic: [Sip] INVITE, CANCEL and BYE, re-transitions Thread-Index: AcLNbgdpZ2d6dUXaQW+zlmCNEww6iwKOm3UQ From: "Thomas Vasen" To: , X-OriginalArrivalTime: 18 Feb 2003 23:52:39.0405 (UTC) FILETIME=[D1CB89D0:01C2D7A8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1INtBp04816 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, From your answer I understand that if a proxy goes down during call setup SIP is not design to properly handle call tear down. In this case the phones will be ringing forever. Is there any work being done on improving these scenarios? //Thomas. -----Original Message----- From: Brett Tate [mailto:brett@broadsoft.com] Sent: onsdag 5 februari 2003 23:53 To: sip@ietf.org Subject: RE: [Sip] INVITE, CANCEL and BYE, re-transitions "This list is for NEW development of the core SIP Protocol. Use sip-implementors@cs.columbia.edu for questions on current sip. Use sipping@ietf.org for new developments on the application of sip." > I would just like to verify my understanding > regarding 'Backup Routes' with SIP. > > Suppose one UA has 2 routes, one primary to > PROXY1, and one secondary to PROXY2. > > Suppose PROXY1 is down. > When the UA sets up a session, it will > Send INVITE to Proxy 1 > Timeout > Eventually send INVITE to Proxy 2, and setup the session. When advancing to proxy 2, one or more of the following should change within INVITE to denote forking: 1) From tag 2) Call-ID 3) Via branch > Suppose now Proxy 1 and 2 are UP. > UA send INVITE to Proxy 1 > Proxy sends trying and sets up session. > Proxy 1 dies. > UA sends BYE to Proxy 1, though does not receive any response. The 100 Trying response does not create an early dialog. Thus CANCEL must be sent instead of a BYE. > Shouldn't at this point the UA try to send the > BYE to the Proxy 2 as well? The CANCEL should only be sent where the INVITE was sent. (This is mainly because the top via entry is used to help identify the cancelled request.) If a 101-2xx response was received and the proxy's Record-Route entry included a hostname representing both proxies, the BYE could target advance to proxy 2 when proxy 1 is not responding. Please see RFC 3261 sections 9, 12, and 13 for a more complete description. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Feb 18 23:05:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17668 for ; Tue, 18 Feb 2003 23:05:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1J4B9c22857 for sip-archive@odin.ietf.org; Tue, 18 Feb 2003 23:11:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J4Abp22839; Tue, 18 Feb 2003 23:10:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J482p22737 for ; Tue, 18 Feb 2003 23:08:02 -0500 Received: from proxy-blr.primus-india.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17553 for ; Tue, 18 Feb 2003 23:01:34 -0500 (EST) Received: from dexceldesigns.com (ptil-67-160-ind.primus-india.net [203.196.160.67] (may be forged)) by proxy-blr.primus-india.com (8.11.2/8.11.2) with ESMTP id h1J9XGK13188 for ; Wed, 19 Feb 2003 15:03:16 +0530 Message-ID: <000a01c2d7cd$d3ac09d0$dd9a83ca@DOMAIN.dexceldesigns.com> From: margaretmary To: Date: Wed, 19 Feb 2003 09:47:33 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C2D7FB.ED5355E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailserver: Sent using PostMaster (v4.1.13) Subject: [Sip] query on proxy server Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C2D7FB.ED5355E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello sir, When OPTIONS request from UA is sent to Proxy server, waht is the = response sent by the proxy server to UA. Where can i find the call flow for this scenario. Please provide a solution for this Regards, Margaret ------=_NextPart_000_0007_01C2D7FB.ED5355E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello sir,
 
When OPTIONS request from UA is sent to = Proxy=20 server, waht is the response sent by the proxy server to = UA.
 
Where can i find the call flow for this = scenario.
Please provide a solution for = this
 
 
Regards,
Margaret

--------------------------------------------------------------
Dexcel Electronics Designs (P) Ltd., Bangalore, India
------=_NextPart_000_0007_01C2D7FB.ED5355E0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Feb 18 23:40:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18221 for ; Tue, 18 Feb 2003 23:40:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1J4kX325028 for sip-archive@odin.ietf.org; Tue, 18 Feb 2003 23:46:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J4jjp24918; Tue, 18 Feb 2003 23:45:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J4ikp24807 for ; Tue, 18 Feb 2003 23:44:46 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18119 for ; Tue, 18 Feb 2003 23:38:19 -0500 (EST) Received: from prasannacl1105 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HAJ004V8GZD1F@mta0.huawei.com> for sip@ietf.org; Wed, 19 Feb 2003 12:40:28 +0800 (CST) Date: Wed, 19 Feb 2003 10:13:22 +0530 From: Prasanna Venkatesh Subject: RE: [Sip] query on proxy server In-reply-to: <000a01c2d7cd$d3ac09d0$dd9a83ca@DOMAIN.dexceldesigns.com> To: margaretmary , sip@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT The behaviour of a proxy for handling OPTIONS request is defined in RFC-3261 section 11.2 . Cheers, Prasanna -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of margaretmary Sent: Wednesday, February 19, 2003 9:48 AM To: sip@ietf.org Subject: [Sip] query on proxy server Hello sir, When OPTIONS request from UA is sent to Proxy server, waht is the response sent by the proxy server to UA. Where can i find the call flow for this scenario. Please provide a solution for this Regards, Margaret -------------------------------------------------------------- Dexcel Electronics Designs (P) Ltd., Bangalore, India _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Feb 19 01:16:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19944 for ; Wed, 19 Feb 2003 01:16:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1J6MkR31502 for sip-archive@odin.ietf.org; Wed, 19 Feb 2003 01:22:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J6MMp31462; Wed, 19 Feb 2003 01:22:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J6KFp31354 for ; Wed, 19 Feb 2003 01:20:15 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19916 for ; Wed, 19 Feb 2003 01:13:48 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 18 Feb 2003 22:17:36 -0800 Received: from 193.220.224.9 by lw8fd.law8.hotmail.msn.com with HTTP; Wed, 19 Feb 2003 06:17:36 GMT X-Originating-IP: [193.220.224.9] From: "Ritesh Maheshwari" To: vkenneally@cit.ie, sip@ietf.org Subject: Re: [Sip] SIP messages Date: Wed, 19 Feb 2003 06:17:36 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Feb 2003 06:17:36.0611 (UTC) FILETIME=[98CD7B30:01C2D7DE] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , hi, I guess you are talking about RFC 3261. Try it on google. - Ritesh Maheshwari Final yr, Computer Sci & Engg IIT Kharagpur, India rite_m@yahoo.com, rite_m@hotmail.com, riteshm@cse.iitkgp.dhs.org >From: "Valerie Kenneally" >Reply-To: >To: >Subject: [Sip] SIP messages >Date: Tue, 18 Feb 2003 15:31:51 -0000 > >Hi all, > > Just wondering if a document has been written discussing the different SIP >messages and the headers and contents they contain. > >Thanks in advance, >Valerie Kenneally > > >-------------------Legal Disclaimer--------------------------------------- > >The above electronic mail transmission is confidential and intended only >for the person to whom it is addressed. Its contents may be protected by >legal and/or professional privilege. Should it be received by you in error >please contact the sender at the above quoted email address. Any >unauthorised form of reproduction of this message is strictly prohibited. >The Institute does not guarantee the security of any information >electronically transmitted and is not liable if the information contained >in this communication is not a proper and complete record of the message as >transmitted by the sender nor for any delay in its receipt. > >---------------------------------------------------------------------------------------- > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Feb 19 03:56:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16326 for ; Wed, 19 Feb 2003 03:56:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1J92AZ20165 for sip-archive@odin.ietf.org; Wed, 19 Feb 2003 04:02:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J91bp19936; Wed, 19 Feb 2003 04:01:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J90gp19854 for ; Wed, 19 Feb 2003 04:00:42 -0500 Received: from iisc.ernet.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16281 for ; Wed, 19 Feb 2003 03:54:09 -0500 (EST) Received: from hirp.iisc.ernet.in (hirp.iisc.ernet.in [144.16.94.229]) by iisc.ernet.in (8.9.2/8.9.0) with ESMTP id OAA34092; Wed, 19 Feb 2003 14:31:10 +0530 (IST) Received: from localhost (john@localhost) by hirp.iisc.ernet.in (8.11.2/8.8.7) with ESMTP id h1J902p25405; Wed, 19 Feb 2003 14:30:02 +0530 Date: Wed, 19 Feb 2003 14:30:02 +0530 (IST) From: John J C To: Ritesh Maheshwari cc: , Subject: Re: [Sip] SIP messages In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi , U can get the RFC 3261 from this link. http://community.roxen.com/developers/idocs/rfc/rfc3261.html Regards, John -- John J Chooracken Senior Engineer - R&D HFCL-IISc Research Program IISc Campus - Bangalore - 560 012 Voice: (+91)-80-3562062 Email: john@hirp.iisc.ernet.in chooracken@yahoo.com Never argue with fools, first they take you to their level then, beat you with their superior experience. -- Anonymous!!! _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Feb 19 07:09:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20313 for ; Wed, 19 Feb 2003 07:09:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JCFiD03120 for sip-archive@odin.ietf.org; Wed, 19 Feb 2003 07:15:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JCFEp03101; Wed, 19 Feb 2003 07:15:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JCBNp02945 for ; Wed, 19 Feb 2003 07:11:23 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20159; Wed, 19 Feb 2003 07:04:49 -0500 (EST) Message-Id: <200302191204.HAA20159@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 19 Feb 2003 07:04:49 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-congestsafe-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Session Initiation Protocol Extension to Assure Congestion Safety Author(s) : D. Willis, B. Campbell Filename : draft-ietf-sip-congestsafe-01.txt Pages : 13 Date : 2003-2-14 The Session Initiation Protocol allows the use of UDP for transport of SIP messages. The use of UDP inherently risks network congestion problems, as UDP itself does not define congestion prevention, avoidance, detection, or correction mechanisms. This problem is aggravated by large SIP messages which fragment at the UDP level. Transport protocols in SIP are also negotiated on a per-hop basis, at the SIP level, so SIP proxies may convert from TCP to UDP and so forth. This document defines what it means for SIP nodes to be congestion safe and specifies an extension by which a SIP User Agent may require that its requests are treated in a congestion safe manner. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-congestsafe-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-congestsafe-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-congestsafe-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-14105248.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-congestsafe-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-congestsafe-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-14105248.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Feb 19 08:14:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24120 for ; Wed, 19 Feb 2003 08:14:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JDKQA08580 for sip-archive@odin.ietf.org; Wed, 19 Feb 2003 08:20:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JDK3p08556; Wed, 19 Feb 2003 08:20:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JDI3p08466 for ; Wed, 19 Feb 2003 08:18:03 -0500 Received: from samar.sasken.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24072 for ; Wed, 19 Feb 2003 08:11:25 -0500 (EST) Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.12.6/8.12.6) with SMTP id h1JDFBW9027309 for ; Wed, 19 Feb 2003 18:45:11 +0530 (IST) Received: from ncc-nf.nt.sasi.com ([202.21.147.224]) by samar; Wed, 19 Feb 2003 18:45:08 +0530 (IST) Received: from sunf3.nt.sasi.com (sunf3.nt.sasi.com [202.21.147.3]) by ncc-nf.nt.sasi.com (8.11.6/8.11.6) with ESMTP id h1JDF8R10768 for ; Wed, 19 Feb 2003 18:45:08 +0530 (IST) Received: from ravis (pcnt-ravis.nt.sasi.com [172.17.5.61]) by sunf3.nt.sasi.com (8.11.6/8.11.6) with SMTP id h1JDF8K01593 for ; Wed, 19 Feb 2003 18:45:08 +0530 (IST) From: "Ravi Shiroor" To: Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-congestsafe-01.txt Date: Wed, 19 Feb 2003 18:47:29 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <200302191204.HAA20159@ietf.org> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > Internet-Drafts@ietf.org > Sent: Wednesday, February 19, 2003 5:35 PM > To: IETF-Announce: ; > Cc: sip@ietf.org > Subject: [Sip] I-D ACTION:draft-ietf-sip-congestsafe-01.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol > Working Group of the IETF. > > Title : Session Initiation Protocol Extension to Assure > Congestion Safety > Author(s) : D. Willis, B. Campbell > Filename : draft-ietf-sip-congestsafe-01.txt > Pages : 13 > Date : 2003-2-14 > > The Session Initiation Protocol allows the use of UDP for transport > of SIP messages. The use of UDP inherently risks network congestion > problems, as UDP itself does not define congestion prevention, > avoidance, detection, or correction mechanisms. This problem is > aggravated by large SIP messages which fragment at the UDP level. > Transport protocols in SIP are also negotiated on a per-hop basis, at > the SIP level, so SIP proxies may convert from TCP to UDP and so > forth. I remember that we had a discussion (was it here or on sip-implementors?) and the conclusion was that no proxy will do a conversion from TCP to UDP. (reliable to non-reliable transport). > This document defines what it means for SIP nodes to be > congestion safe and specifies an extension by which a SIP User Agent > may require that its requests are treated in a congestion safe > manner. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-congestsafe-01.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of > the message. > > Internet-Drafts are also available by anonymous FTP. Login with > the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-sip-congestsafe-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sip-congestsafe-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Feb 19 17:24:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11138 for ; Wed, 19 Feb 2003 17:24:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JMV1w15354 for sip-archive@odin.ietf.org; Wed, 19 Feb 2003 17:31:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JMULp15320; Wed, 19 Feb 2003 17:30:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JMQbp15216 for ; Wed, 19 Feb 2003 17:26:37 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11024 for ; Wed, 19 Feb 2003 17:19:47 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h1JMNaLc009096; Wed, 19 Feb 2003 16:23:37 -0600 From: "Dean Willis" To: "'Ravi Shiroor'" , Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-congestsafe-01.txt Date: Wed, 19 Feb 2003 16:23:26 -0600 Message-ID: <002c01c2d865$86b1a200$83f30a0a@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1JMQcp15217 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > I remember that we had a discussion (was it here or on > sip-implementors?) and the conclusion was that no proxy will > do a conversion from TCP to UDP. (reliable to non-reliable > transport). I don't recall this discussion. While mixing transports may not seem like a great idea, it does happen in real networks. One very likely scenario is SCTP between proxies with UDP or TCP between the proxies and UAs. -- dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Feb 21 08:47:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29343 for ; Fri, 21 Feb 2003 08:47:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LDt1123862 for sip-archive@odin.ietf.org; Fri, 21 Feb 2003 08:55:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LDsFp23832; Fri, 21 Feb 2003 08:54:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KC42p06062 for ; Thu, 20 Feb 2003 07:04:02 -0500 Received: from sumo.vocaltec.co.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07978 for ; Thu, 20 Feb 2003 06:56:57 -0500 (EST) From: Oleg_Levy@vocaltec.com Received: from ilnimo.vocaltec.co.il (ilnimo.vocaltec.co.il [194.90.71.135]) by sumo.vocaltec.co.il (8.11.6+Sun/8.11.6) with ESMTP id h1KBtMU11779 for ; Thu, 20 Feb 2003 13:55:22 +0200 (IST) To: sip@ietf.org Cc: Alex_Fishman@vocaltec.com, Michael_Fortinsky@vocaltec.com, Avi_Damri@vocaltec.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 Message-ID: Date: Thu, 20 Feb 2003 13:56:46 +0200 X-MIMETrack: Serialize by Router on ILNimo/Vocaltec_Comm(Release 5.0.8 |June 18, 2001) at 02/20/2003 01:56:47 PM, Serialize complete at 02/20/2003 01:56:47 PM Content-Type: multipart/alternative; boundary="=_alternative 0041FC82C2256CD3_=" Subject: [Sip] RFC 3326 question Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 0041FC82C2256CD3_= Content-Type: text/plain; charset="US-ASCII" Hi RFC3326 specifies a method for transferring the Cause parameter defined in Q.850. In ISUP interworking scenarios the Reason header is used in CANCEL requests to specify the cause value, however other parameters like Location are still not transferred. What is the correct way to transfer the rest of the parameters? regards Oleg Levy Team Leader ---------------------------------------------- VocalTec Communications Ltd. Tel: +972-9-9707832 Cell: +972-55-655199 Fax: +972-9-9708505 eMail: buskila@vocaltec.com ---------------------------------------------- --=_alternative 0041FC82C2256CD3_= Content-Type: text/html; charset="US-ASCII"
Hi

RFC3326 specifies a method for transferring the Cause parameter defined in Q.850. In ISUP interworking scenarios the Reason header is used in CANCEL requests to specify the cause value, however other parameters like Location are still not transferred.

What is the correct way to transfer the rest of the parameters?

regards




Oleg Levy
Team Leader
----------------------------------------------
VocalTec Communications Ltd.
Tel: +972-9-9707832
Cell: +972-55-655199
Fax: +972-9-9708505
eMail: buskila@vocaltec.com
---------------------------------------------- --=_alternative 0041FC82C2256CD3_=-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Feb 21 09:19:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00971 for ; Fri, 21 Feb 2003 09:19:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LEQfb26047 for sip-archive@odin.ietf.org; Fri, 21 Feb 2003 09:26:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LEQFp26021; Fri, 21 Feb 2003 09:26:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LENOp25922 for ; Fri, 21 Feb 2003 09:23:24 -0500 Received: from mirlo.dit.upm.es (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00815 for ; Fri, 21 Feb 2003 09:15:48 -0500 (EST) Received: from faisan (faisan [138.4.50.4]) by mirlo.dit.upm.es (8.8.5/8.7.3) with SMTP id OAA16129 for ; Fri, 21 Feb 2003 14:20:24 GMT Reply-To: From: "Manuel Moreno" To: Date: Fri, 21 Feb 2003 15:19:54 +0100 Message-ID: <000901c2d9b4$4e63cfe0$0432048a@cipres.upm.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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 V5.50.4522.1200 Content-Transfer-Encoding: 8bit Subject: [Sip] Questions Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all: From the RFC 3261, I understand that other request type, different to INVITE, can establish a dialog. Is this an opened road ??. Is correct my interpretation??. In this case, for to close one dialog, which method ( or answer) I can use and how ??? In the RFC 3261, section 12.3, pag 77 said: “...The mechanism for terminating confirmed dialogs is method specific. In this specifications, the BYE method terminates a session and the dialog associated with it........” I think for INVITE only. Is correct?? Thak you Manuel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Feb 21 13:16:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09686 for ; Fri, 21 Feb 2003 13:16:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LINOw10240 for sip-archive@odin.ietf.org; Fri, 21 Feb 2003 13:23:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LIMnp10193; Fri, 21 Feb 2003 13:22:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LIGmp09972 for ; Fri, 21 Feb 2003 13:16:48 -0500 Received: from broadsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09492 for ; Fri, 21 Feb 2003 13:09:06 -0500 (EST) Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.12.6) id h1LICwqk041213; Fri, 21 Feb 2003 13:12:58 -0500 (EST) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] Questions Date: Fri, 21 Feb 2003 13:15:27 -0500 Message-ID: <000601c2d9d5$366734b0$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <000901c2d9b4$4e63cfe0$0432048a@cipres.upm.es> Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > From the RFC 3261, I understand that > other request type, different to INVITE, > can establish a dialog. rfc3265 discusses a subscription dialog. > In this case, for to close one dialog, > which method ( or answer) I can use > and how ??? The following quote that you provided explains that BYE can close INVITE established dialogs. In addition, the CANCEL can close INVITE established early dialogs. Sending a SUBSCRIBE with Expires: 0, closes subscription dialogs. Sending NOTIFY with Subscription-State: terminated, closes subscription dialogs. A proxy refusing to proxy any more messages will close dialogs which expire. Returning a 481 to a request communicates that a dialog is unknown. It will lead to explicit or implicit closure of the dialog. > In the RFC 3261, section 12.3, pag 77 said: > > “...The mechanism for terminating confirmed > dialogs is method specific. In this > specifications, the BYE method terminates a > session and the dialog associated with it........” > > I think for INVITE only. Is correct?? The "In this specifications" text is meant to convey that the BYE closes the associated invite established dialog and the session created by the invite established dialog. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Feb 25 05:43:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22880 for ; Tue, 25 Feb 2003 05:43:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PAqcb17020 for sip-archive@odin.ietf.org; Tue, 25 Feb 2003 05:52:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PAmqp16890; Tue, 25 Feb 2003 05:48:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PAdHp16624 for ; Tue, 25 Feb 2003 05:39:17 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22697 for ; Tue, 25 Feb 2003 05:29:47 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 25 Feb 2003 11:33:39 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Feb 2003 11:33:38 +0100 Message-Id: <953B9B08F98DD61183F8000347AE66011ACC31@G8PPV.blf01.telekom.de> From: "Jesske, R" To: nkannan@huawei.com, rkalshet@cisco.com, sip@ietf.org Subject: AW: [Sip] INVITE client Transaction.... Date: Tue, 25 Feb 2003 11:33:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1PAdHp16625 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Dear all, From my understanding from an operator point of view this question is valid and belongs not only to the application. A operator/service provider network needs timeouts regarding the answer to a call. If I make this depended on the application I will get interoperable applications. Also it is not defined (from my point of understanding) within RFC 3261 in which cases timer B (I think this belongs also to other SIP timers) will be cancelled/terminated. Or can somebody give me clarification on this issue. Best Regards Roland Jesske Deutsche Telekom AG T Com Zentrale Roland Jesske, T38-12 Section T38; Signalling, Gateways and Switching Systems Am Kavalleriesand 3, 64295 Darmstadt, Germany Phone: +49 6151 83-5940 Fax: +49 6151 83-4577 > -----Ursprüngliche Nachricht----- > Von: Natesan Kannan [mailto:nkannan@huawei.com] > Gesendet: Donnerstag, 13. Februar 2003 16:26 > An: Rajesh Kalshetty (rkalshet); sip@ietf.org > Betreff: Re: [Sip] INVITE client Transaction.... > > > Excerpt from a previous query on the same subject and Jonathan's reply > embedded... > -Kannan > > ********* > This is an application issue. It can decide to give up at any time and > send CANCEL. We don't want to specify the maximum time a user will let > the phone ring. > > -Jonathan R. > > Vijaya Venkatachalam wrote: > > Hi, > > > > I have a question regarding the INVITE transaction > > state machine. > > > > It seems that in RFC 3261 - transaction state machine for > > INVITE transactions, there is a potential for > > the client side transaction to indefinitely be > > in the "Proceeding" state since all timers > > are cancelled on the reception of a 1xx response. > > > > Can somebody tell me how the client side transaction > > can come out of this state, if the server transaction on > > the remote end dies? > > > > Is it that the timer B is not cancelled and that only > > timer A is cancelled when the 1xx is received or is > > there some other means. > > > > Appreciate a quick response. > > > > Thanks, > > Vijaya > ********* > ----- Original Message ----- > From: "Rajesh Kalshetty (rkalshet)" > To: > Sent: Thursday, February 13, 2003 5:35 PM > Subject: [Sip] INVITE client Transaction.... > > > > > > Hi all, > > > > I have a question Regarding the INVITE client Transactions > state m/c . > When > > a client transaction moves to the proceeding state after > receiving a > > provisional response by how much time it has to wait in > that state for a > > final response. > > > > > > A Invite B > > |------------------>| > > | 1xx | > > |<------------------| > > | | > > | x client crashes. > > | | > > > > suppose that client B crashes after it sends a provisional > response,i > don't > > find any way for the A's client transaction to come out of > the proceeding > > state in RFC. > > > > > > Regrds, > > Rajesh k. > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Feb 25 06:01:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23141 for ; Tue, 25 Feb 2003 06:01:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PBA0B18458 for sip-archive@odin.ietf.org; Tue, 25 Feb 2003 06:10:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PB6Wp17536; Tue, 25 Feb 2003 06:06:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PB0Sp17337 for ; Tue, 25 Feb 2003 06:00:28 -0500 Received: from mta2 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22959 for ; Tue, 25 Feb 2003 05:50:57 -0500 (EST) Received: from mta2 (localhost [127.0.0.1]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTP id <0HAV007082CPP0@mta2.huawei.com> for sip@ietf.org; Tue, 25 Feb 2003 18:55:38 +0800 (CST) Received: from mailin.huawei.com ([10.18.1.252]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTP id <0HAV008Q32CO5L@mta2.huawei.com> for sip@ietf.org; Tue, 25 Feb 2003 18:55:37 +0800 (CST) Received: from nkannanCL1068 ([10.18.2.104]) by mailin.huawei.com (Netscape Messaging Server 4.15) with ESMTP id HAV2FE00.W0M; Tue, 25 Feb 2003 18:57:14 +0800 Date: Tue, 25 Feb 2003 16:21:36 +0530 From: Natesan Kannan Subject: Re: [Sip] INVITE client Transaction.... To: "Jesske, R" , rkalshet@cisco.com, sip@ietf.org Message-id: <002901c2dcbb$de84dec0$6802120a@in.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <953B9B08F98DD61183F8000347AE66011ACC31@G8PPV.blf01.telekom.de> Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Dear Roland, This is exactly why the ringing timer is not controlled by the protocol. This would enable you to deploy a uniform alert time across a multi-service switching network. In this case, 'the application' could refer to the switching entity. -Kannan ----- Original Message ----- From: "Jesske, R" To: ; ; Sent: Tuesday, February 25, 2003 4:03 PM Subject: AW: [Sip] INVITE client Transaction.... Dear all, From my understanding from an operator point of view this question is valid and belongs not only to the application. A operator/service provider network needs timeouts regarding the answer to a call. If I make this depended on the application I will get interoperable applications. Also it is not defined (from my point of understanding) within RFC 3261 in which cases timer B (I think this belongs also to other SIP timers) will be cancelled/terminated. Or can somebody give me clarification on this issue. Best Regards Roland Jesske Deutsche Telekom AG T Com Zentrale Roland Jesske, T38-12 Section T38; Signalling, Gateways and Switching Systems Am Kavalleriesand 3, 64295 Darmstadt, Germany Phone: +49 6151 83-5940 Fax: +49 6151 83-4577 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Feb 25 06:10:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23268 for ; Tue, 25 Feb 2003 06:10:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PBJYe18801 for sip-archive@odin.ietf.org; Tue, 25 Feb 2003 06:19:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PBG6p18699; Tue, 25 Feb 2003 06:16:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PB4xp17489 for ; Tue, 25 Feb 2003 06:04:59 -0500 Received: from sonim-india.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23006 for ; Tue, 25 Feb 2003 05:55:26 -0500 (EST) Received: (from root@localhost) by sonim-india.com (8.11.6/8.11.6) id h1PAQ3e29694 for ; Tue, 25 Feb 2003 15:56:03 +0530 Received: from boxer (boxer.sonim-india.com [192.168.2.88]) by sonim-india.com (8.11.6/8.11.6) with SMTP id h1PAPtV29245; Tue, 25 Feb 2003 15:55:55 +0530 From: "Vishal Verma" To: "Jesske, R" , , , Cc: Subject: RE: [Sip] INVITE client Transaction.... Date: Tue, 25 Feb 2003 16:33:02 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <953B9B08F98DD61183F8000347AE66011ACC31@G8PPV.blf01.telekom.de> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal X-MIME-Autoconverted: from 8bit to quoted-printable by sonim-india.com id h1PAPtV29245 X-AntiVirus: Scanned for Viruses at sonim communications (india) pvt. ltd. Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1PB4xp17490 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I would like to suggest minor modification here ... 1xx response from User B should not cancel timer at User A but 1xx response should reset and increment the INVITE timer at User A .User A should start timer of this much duration and retransmit message after timer expiry where , initial timer and increment should be configurable values so after receiving 1xx response timer value should be calculated as final_timer_value = present_timer_value + timer_increment where , present_timer_value, timer_increment are configurable values regards, vishal -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Jesske, R Sent: Tuesday, February 25, 2003 4:04 PM To: nkannan@huawei.com; rkalshet@cisco.com; sip@ietf.org Subject: AW: [Sip] INVITE client Transaction.... Dear all, >From my understanding from an operator point of view this question is valid and belongs not only to the application. A operator/service provider network needs timeouts regarding the answer to a call. If I make this depended on the application I will get interoperable applications. Also it is not defined (from my point of understanding) within RFC 3261 in which cases timer B (I think this belongs also to other SIP timers) will be cancelled/terminated. Or can somebody give me clarification on this issue. Best Regards Roland Jesske Deutsche Telekom AG T Com Zentrale Roland Jesske, T38-12 Section T38; Signalling, Gateways and Switching Systems Am Kavalleriesand 3, 64295 Darmstadt, Germany Phone: +49 6151 83-5940 Fax: +49 6151 83-4577 > -----Ursprüngliche Nachricht----- > Von: Natesan Kannan [mailto:nkannan@huawei.com] > Gesendet: Donnerstag, 13. Februar 2003 16:26 > An: Rajesh Kalshetty (rkalshet); sip@ietf.org > Betreff: Re: [Sip] INVITE client Transaction.... > > > Excerpt from a previous query on the same subject and Jonathan's reply > embedded... > -Kannan > > ********* > This is an application issue. It can decide to give up at any time and > send CANCEL. We don't want to specify the maximum time a user will let > the phone ring. > > -Jonathan R. > > Vijaya Venkatachalam wrote: > > Hi, > > > > I have a question regarding the INVITE transaction > > state machine. > > > > It seems that in RFC 3261 - transaction state machine for > > INVITE transactions, there is a potential for > > the client side transaction to indefinitely be > > in the "Proceeding" state since all timers > > are cancelled on the reception of a 1xx response. > > > > Can somebody tell me how the client side transaction > > can come out of this state, if the server transaction on > > the remote end dies? > > > > Is it that the timer B is not cancelled and that only > > timer A is cancelled when the 1xx is received or is > > there some other means. > > > > Appreciate a quick response. > > > > Thanks, > > Vijaya > ********* > ----- Original Message ----- > From: "Rajesh Kalshetty (rkalshet)" > To: > Sent: Thursday, February 13, 2003 5:35 PM > Subject: [Sip] INVITE client Transaction.... > > > > > > Hi all, > > > > I have a question Regarding the INVITE client Transactions > state m/c . > When > > a client transaction moves to the proceeding state after > receiving a > > provisional response by how much time it has to wait in > that state for a > > final response. > > > > > > A Invite B > > |------------------>| > > | 1xx | > > |<------------------| > > | | > > | x client crashes. > > | | > > > > suppose that client B crashes after it sends a provisional > response,i > don't > > find any way for the A's client transaction to come out of > the proceeding > > state in RFC. > > > > > > Regrds, > > Rajesh k. > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Feb 25 08:23:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00469 for ; Tue, 25 Feb 2003 08:23:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PDWuk28627 for sip-archive@odin.ietf.org; Tue, 25 Feb 2003 08:32:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PDPgp28296; Tue, 25 Feb 2003 08:25:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LGPbp02133 for ; Fri, 21 Feb 2003 11:25:37 -0500 Received: from newman.gte.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05308; Fri, 21 Feb 2003 11:17:58 -0500 (EST) Received: from rcmppc2.gte.com (rcmppc2.gte.com [132.197.73.30]) by newman.gte.com (8.9.1/8.9.1) with ESMTP id LAA26845; Fri, 21 Feb 2003 11:21:46 -0500 (EST) Message-Id: <5.1.1.6.0.20030221110917.04229140@pophost.gte.com> X-Sender: sjj0@pophost.gte.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 21 Feb 2003 11:22:08 -0500 To: Allison Mankin From: Stuart Jacobs Cc: sipping@ietf.org, sip@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Sip] Re: [Sipping] New version of the SIP-AAA reqs draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Allison, This material is part of ongoing efforts of Verizon and Verizon management to engage in thoughtful considerations of the fundamental changes and challenges facing the telecommunications industry. To meet its fiduciary responsibilities, management must explore all alternatives, even those that may appear highly speculative and hypothetical. Statements and representations contained herein are preliminary and/or tentative and should not be relied on unless approved by the appropriate Verizon governing body. The following represent the anticipated approach Verizon most likely will use. I cannot be more firm at this time as our architectural plans are not finalized. Verizon's current direction for our Next Generation Network (NGN) VoIP Services will likely use a challenge/response approach (ala. Radius) for authentication and access control between our SIP service customers and SIP Proxies. All our SIP service customers will probably go through SIP Proxies. We will not support SIP UA to SIP UA within our operational domain. Our SIP Proxies will likely authenticate themselves to other SIP Proxies and other back-office systems (OSSs, Application Servers, EMSs, etc.) by use of IPsec, specifically IKE combined with X.509v3 server certificates and ESP transport mode Null-encryption using HMAC-SHA1-96. Access controls (rights/policies) between our intermediate systems (incl. SIP Proxies, Gateways , etc.) are expected to be based on use of policy certificates. All policy and identity certificates are expected to be distributed via a redundant hierarchy of LDAP servers (repositories). Accounting data will most likely be compiled by our SIP Proxies and transferred to billing systems with authentication provided by IPsec. The actual billing data will probably be captured in the form of XML in conjunction with XML signatures (as defined by the W3C). Stu At 2/20/03 05:24 PM, you wrote: >Stu, > >You are not doing the usage accounting with Radius, then. > >It is only doing the remote access authentication? > >We can work with this scenario. Could you speak to this in >the open mailing list? I would like to rule out Radius for >call detail and usage-based accounting, but it is ok for the >other A's. > >Allison > > > Diameter in our Next Generation Network (NGN) VoIP Services. We will be > > doing our usage accounting within SIP Proxies and intend to transfer said > > accounting "call detail records" back to our billing OSSes via other > > protocols with IPsec providing authentication and confidentiality for > these > > transfers. We currently do not plan on any deployment of Diameter within > > Verizon's wireline NGN architecture. We will probably continue to use > > Radius for remote access authentication at the application layer for a > > number or years into the future. > > > > Stu Jacobs > > > > At 2/14/03 09:58 PM, you wrote: > > > > >Jiri, > > > > > >It always seems good to be able to stay with installed base, but > > >there's a factor against our supporting RADIUS drafts for SIP's > > >accounting - safety. Even though there is deployment, there are > > >some extremely bad cases of damage in production, and the IETF > > >has concluded that RADIUS is not suitable for usage-based accounting > > >(RFC2975). > > > > > >Unless there is no intention of having in SIP accounting usage-based, > > >monetary, auditable applications, RADIUS is not the solution. The > > >protocol just does not preserve a complete stream of reliable > > >accounting records that are auditable on any level, especially with > > >any roaming. As Bernard Aboba stated to this WG, quoting Mike O'Dell, > > >the use of RADIUS may even be illegal in situations where there is an > > >authority over the billing. Records are too easily lost by the > > >protocol. This is stated clearly by RFC2975. This is the reason why > > >the Operations and Mgt Area developed Diameter. On these technical* > > >grounds, that the RADIUS protocol does not have enough reliability, > > >the work must be based on the Diameter protocol, which is now > > >approved. Alternatively, work could be done that does not include > > >usage-based accounting, but this does not seem to be what is > > >envisioned in the SIPPING AAA requirements. > > > > > >Allison > > > > > >P.S. There's a current investigation of RADIUS compatibility mode > > >in Diameter for this - more needs to be thought about it. > > > > > > > > At 07:46 PM 2/11/2003, john.loughney@nokia.com wrote: > > > > >Hi Henry, > > > > > > > > > >> >but one option is develop a solution using > > > > >> > Diameter in RADIUS-compatibility mode. > > > > >> > > > > >> OK, this is better than nothing. We'll take what we can :-) > > > > >> > > > > >> As mentioned, the installed base is RADIUS, no matter how > > > > >> voluminous the DIAMETER literature may be. > > > > > > > > > >I think the issues is that the IETF should recommend what is the > > > > >right thing to do & why. If people choose to do something else, > > > > >well, that is life. > > > > > > > > Remember that running code does not necessarily mean something known > > > > to compile -- that is something known to be deployed. > > > > > > > > >I understand what you are asking but I do note that some > > > > >people have thought that the potential for AAA is much greater > > > > >than the existing installed base. > > > > > > > > I actually think that the deployment argument is a very important one. > > > > > > > > -Jiri > > > > > > > > _______________________________________________ > > > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > > > This list is for NEW development of the application of SIP > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sip@ietf.org for new developments of core SIP > > >_______________________________________________ > > >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > >This list is for NEW development of the application of SIP > > >Use sip-implementors@cs.columbia.edu for questions on current sip > > >Use sip@ietf.org for new developments of core SIP > > > > ========================== > > Stuart Jacobs CISSP > > PMTS - Sr. Technologist > > Verizon Laboratories > > 40 Sylvan Road Waltham, MA 02451-1128 USA > > telephone: (781) 466-3076 fax: (781) 466-2838 > > stu.jacobs@labs.gte.com sjj0@labs.gte.com stu.jacobs@verizon.com > > ========================== > > ========================== Stuart Jacobs CISSP PMTS - Sr. Technologist Verizon Laboratories 40 Sylvan Road Waltham, MA 02451-1128 USA telephone: (781) 466-3076 fax: (781) 466-2838 stu.jacobs@labs.gte.com sjj0@labs.gte.com stu.jacobs@verizon.com ========================== _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Feb 25 09:15:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01652 for ; Tue, 25 Feb 2003 09:15:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PEP0432488 for sip-archive@odin.ietf.org; Tue, 25 Feb 2003 09:25:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PEObp32437; Tue, 25 Feb 2003 09:24:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PELpp32360 for ; Tue, 25 Feb 2003 09:21:51 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01571; Tue, 25 Feb 2003 09:12:18 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.36 #1 (Debian)) id 18nfsR-0002a7-00; Tue, 25 Feb 2003 16:16:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15963.31403.288541.988747@harjus.eng.song.fi> Date: Tue, 25 Feb 2003 16:16:11 +0200 To: Stuart Jacobs Cc: Allison Mankin , sipping@ietf.org, sip@ietf.org Subject: [Sip] Re: [Sipping] New version of the SIP-AAA reqs draft In-Reply-To: <5.1.1.6.0.20030221110917.04229140@pophost.gte.com> References: <5.1.1.6.0.20030221110917.04229140@pophost.gte.com> X-Mailer: VM 7.07 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit nobody replied to my bye question, but after some more thinking i have myself come to the conclusion that it is impossible for a regular sip proxy without a dialog state or a crypto identification of all requests from its clients to do any accounting at all. so it would be important for a sip-aaa requirements draft to list the preconditions for sip accounting. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Feb 25 10:30:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03382 for ; Tue, 25 Feb 2003 10:30:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PFdfN05657 for sip-archive@odin.ietf.org; Tue, 25 Feb 2003 10:39:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PFd8p05617; Tue, 25 Feb 2003 10:39:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PFX6p04495 for ; Tue, 25 Feb 2003 10:33:06 -0500 Received: from mail1-0.chcgil.ameritech.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03022; Tue, 25 Feb 2003 10:23:31 -0500 (EST) Received: from repligate ([67.36.180.12]) by mail1-0.chcgil.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20030225152724.CYNZ29339.mail1-0.chcgil.ameritech.net@repligate>; Tue, 25 Feb 2003 09:27:24 -0600 Message-ID: <0ae201c2dce2$6b372190$8500a8c0@repligate> From: "Jim Fleming" To: "Stuart Jacobs" Cc: , References: <5.1.1.6.0.20030221110917.04229140@pophost.gte.com> Date: Tue, 25 Feb 2003 09:27:32 -0600 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.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] "...management must explore all alternatives..." ?? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit From: "Stuart Jacobs" "...management must explore all alternatives..." ==== Do you mean "explore all alternatives" provided by the I* society...(small s...aka The Big Lie Society)... ...after ethnic cleansing has been done by the I* society thugs...? ----- Original Message ----- From: "Stuart Jacobs" To: "Allison Mankin" Cc: ; Sent: Friday, February 21, 2003 10:22 AM Subject: [Sip] Re: [Sipping] New version of the SIP-AAA reqs draft > Allison, > > This material is part of ongoing efforts of Verizon and Verizon management > to engage in thoughtful considerations of the fundamental changes and > challenges facing the telecommunications industry. To meet its fiduciary > responsibilities, management must explore all alternatives, even those that > may appear highly speculative and hypothetical. Statements and > representations contained herein are preliminary and/or tentative and > should not be relied on unless approved by the appropriate Verizon > governing body. The following represent the anticipated approach Verizon > most likely will use. I cannot be more firm at this time as our > architectural plans are not finalized. > > Verizon's current direction for our Next Generation Network (NGN) VoIP > Services will likely use a challenge/response approach (ala. Radius) for > authentication and access control between our SIP service customers and SIP > Proxies. All our SIP service customers will probably go through SIP > Proxies. We will not support SIP UA to SIP UA within our operational > domain. Our SIP Proxies will likely authenticate themselves to other SIP > Proxies and other back-office systems (OSSs, Application Servers, EMSs, > etc.) by use of IPsec, specifically IKE combined with X.509v3 server > certificates and ESP transport mode Null-encryption using > HMAC-SHA1-96. Access controls (rights/policies) between our intermediate > systems (incl. SIP Proxies, Gateways , etc.) are expected to be based on > use of policy certificates. All policy and identity certificates are > expected to be distributed via a redundant hierarchy of LDAP servers > (repositories). Accounting data will most likely be compiled by our SIP > Proxies and transferred to billing systems with authentication provided by > IPsec. The actual billing data will probably be captured in the form of > XML in conjunction with XML signatures (as defined by the W3C). > > Stu > > At 2/20/03 05:24 PM, you wrote: > >Stu, > > > >You are not doing the usage accounting with Radius, then. > > > >It is only doing the remote access authentication? > > > >We can work with this scenario. Could you speak to this in > >the open mailing list? I would like to rule out Radius for > >call detail and usage-based accounting, but it is ok for the > >other A's. > > > >Allison > > > > > Diameter in our Next Generation Network (NGN) VoIP Services. We will be > > > doing our usage accounting within SIP Proxies and intend to transfer said > > > accounting "call detail records" back to our billing OSSes via other > > > protocols with IPsec providing authentication and confidentiality for > > these > > > transfers. We currently do not plan on any deployment of Diameter within > > > Verizon's wireline NGN architecture. We will probably continue to use > > > Radius for remote access authentication at the application layer for a > > > number or years into the future. > > > > > > Stu Jacobs > > > > > > At 2/14/03 09:58 PM, you wrote: > > > > > > >Jiri, > > > > > > > >It always seems good to be able to stay with installed base, but > > > >there's a factor against our supporting RADIUS drafts for SIP's > > > >accounting - safety. Even though there is deployment, there are > > > >some extremely bad cases of damage in production, and the IETF > > > >has concluded that RADIUS is not suitable for usage-based accounting > > > >(RFC2975). > > > > > > > >Unless there is no intention of having in SIP accounting usage-based, > > > >monetary, auditable applications, RADIUS is not the solution. The > > > >protocol just does not preserve a complete stream of reliable > > > >accounting records that are auditable on any level, especially with > > > >any roaming. As Bernard Aboba stated to this WG, quoting Mike O'Dell, > > > >the use of RADIUS may even be illegal in situations where there is an > > > >authority over the billing. Records are too easily lost by the > > > >protocol. This is stated clearly by RFC2975. This is the reason why > > > >the Operations and Mgt Area developed Diameter. On these technical* > > > >grounds, that the RADIUS protocol does not have enough reliability, > > > >the work must be based on the Diameter protocol, which is now > > > >approved. Alternatively, work could be done that does not include > > > >usage-based accounting, but this does not seem to be what is > > > >envisioned in the SIPPING AAA requirements. > > > > > > > >Allison > > > > > > > >P.S. There's a current investigation of RADIUS compatibility mode > > > >in Diameter for this - more needs to be thought about it. > > > > > > > > > > At 07:46 PM 2/11/2003, john.loughney@nokia.com wrote: > > > > > >Hi Henry, > > > > > > > > > > > >> >but one option is develop a solution using > > > > > >> > Diameter in RADIUS-compatibility mode. > > > > > >> > > > > > >> OK, this is better than nothing. We'll take what we can :-) > > > > > >> > > > > > >> As mentioned, the installed base is RADIUS, no matter how > > > > > >> voluminous the DIAMETER literature may be. > > > > > > > > > > > >I think the issues is that the IETF should recommend what is the > > > > > >right thing to do & why. If people choose to do something else, > > > > > >well, that is life. > > > > > > > > > > Remember that running code does not necessarily mean something known > > > > > to compile -- that is something known to be deployed. > > > > > > > > > > >I understand what you are asking but I do note that some > > > > > >people have thought that the potential for AAA is much greater > > > > > >than the existing installed base. > > > > > > > > > > I actually think that the deployment argument is a very important one. > > > > > > > > > > -Jiri > > > > > > > > > > _______________________________________________ > > > > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > > > > This list is for NEW development of the application of SIP > > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > > Use sip@ietf.org for new developments of core SIP > > > >_______________________________________________ > > > >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > > >This list is for NEW development of the application of SIP > > > >Use sip-implementors@cs.columbia.edu for questions on current sip > > > >Use sip@ietf.org for new developments of core SIP > > > > > > ========================== > > > Stuart Jacobs CISSP > > > PMTS - Sr. Technologist > > > Verizon Laboratories > > > 40 Sylvan Road Waltham, MA 02451-1128 USA > > > telephone: (781) 466-3076 fax: (781) 466-2838 > > > stu.jacobs@labs.gte.com sjj0@labs.gte.com stu.jacobs@verizon.com > > > ========================== > > > > > ========================== > Stuart Jacobs CISSP > PMTS - Sr. Technologist > Verizon Laboratories > 40 Sylvan Road Waltham, MA 02451-1128 USA > telephone: (781) 466-3076 fax: (781) 466-2838 > stu.jacobs@labs.gte.com sjj0@labs.gte.com stu.jacobs@verizon.com > ========================== > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Tue Feb 25 17:49:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20567 for ; Tue, 25 Feb 2003 17:49:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PMwan05925 for sip-archive@odin.ietf.org; Tue, 25 Feb 2003 17:58:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PMw3p05907; Tue, 25 Feb 2003 17:58:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PMt0p05824 for ; Tue, 25 Feb 2003 17:55:00 -0500 Received: from broadsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20522 for ; Tue, 25 Feb 2003 17:45:15 -0500 (EST) Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.12.6) id h1PMnAOm095523; Tue, 25 Feb 2003 17:49:10 -0500 (EST) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] INVITE, CANCEL and BYE, re-transitions Date: Tue, 25 Feb 2003 17:51:44 -0500 Message-ID: <001c01c2dd20$790fdd50$2b01a8c0@broadsoft.com> 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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > From your answer I understand that if a proxy > goes down during call setup SIP is not design > to properly handle call tear down. In this case > the phones will be ringing forever. RFC 3261 section 13.3.1.1 presents the mechanism to deal with the ring forever problem. Beyond that, the UAS needs to deal with knowing if it is a good idea to ring forever. Most vendors realize that phone users will not likely want their phone to power/audibly ring indefinitely; however some might think that it is cool new "annoy the neighbors" feature. :) > Is there any work being done on improving these > scenarios? RFC 3262, RFC 3263, RFC 3311, and draft-ietf-sip-session-timer address many of the fault tolerant issues. See the following two links for currently chartered items of the sip and sipping working groups. http://www.ietf.org/html.charters/sip-charter.html http://www.ietf.org/html.charters/sipping-charter.html > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: onsdag 5 februari 2003 23:53 > To: sip@ietf.org > Subject: RE: [Sip] INVITE, CANCEL and BYE, re-transitions > > "This list is for NEW development of the core SIP Protocol. > Use sip-implementors@cs.columbia.edu for questions on current sip. > Use sipping@ietf.org for new developments on the application of sip." > > > I would just like to verify my understanding > > regarding 'Backup Routes' with SIP. > > > > Suppose one UA has 2 routes, one primary to > > PROXY1, and one secondary to PROXY2. > > > > Suppose PROXY1 is down. > > When the UA sets up a session, it will > > Send INVITE to Proxy 1 > > Timeout > > Eventually send INVITE to Proxy 2, and setup the session. > > When advancing to proxy 2, one or more of the > following should change within INVITE to > denote forking: > 1) From tag > 2) Call-ID > 3) Via branch > > > Suppose now Proxy 1 and 2 are UP. > > UA send INVITE to Proxy 1 > > Proxy sends trying and sets up session. > > Proxy 1 dies. > > UA sends BYE to Proxy 1, though does not receive any response. > > The 100 Trying response does not create an early > dialog. Thus CANCEL must be sent instead of a BYE. > > > Shouldn't at this point the UA try to send the > > BYE to the Proxy 2 as well? > > The CANCEL should only be sent where the INVITE > was sent. (This is mainly because the top via entry > is used to help identify the cancelled request.) > > If a 101-2xx response was received and the > proxy's Record-Route entry included a hostname > representing both proxies, the BYE could > target advance to proxy 2 when proxy 1 is not > responding. > > Please see RFC 3261 sections 9, 12, and 13 for > a more complete description. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Feb 26 07:26:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02373 for ; Wed, 26 Feb 2003 07:26:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QCa0303727 for sip-archive@odin.ietf.org; Wed, 26 Feb 2003 07:36:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QCZIp03702; Wed, 26 Feb 2003 07:35:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QCXEp03624 for ; Wed, 26 Feb 2003 07:33:14 -0500 Received: from mailserv.intranet.gr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02334 for ; Wed, 26 Feb 2003 07:23:09 -0500 (EST) Received: from mailserv.intranet.gr (localhost [127.0.0.1]) by mailserv.intranet.gr (8.11.3/8.11.3) with ESMTP id h1QCT3V17226 for ; Wed, 26 Feb 2003 14:29:03 +0200 (EET) Received: from hal.intranet.gr (hal.intranet.GR [146.124.2.254]) by mailserv.intranet.gr (8.11.3/8.11.3) with ESMTP id h1QCT2i17218; Wed, 26 Feb 2003 14:29:02 +0200 (EET) Received: from dpdssal (pcdpd120 [146.124.2.235]) by hal.intranet.gr (8.10.2+Sun/8.10.2) with SMTP id h1QCJ4P10078; Wed, 26 Feb 2003 14:19:04 +0200 (EET) From: "F.S.Salloum" To: "Sip@Ietf. Org" Cc: "Tasos Dagiouklas" Date: Wed, 26 Feb 2003 14:30:42 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1253" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Of-hook and On-hook @ sip? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear all, One simple question is there a similar message in SIP which works like on-hook and off-hook on the PSTN world (Q-931)? I know that this can be implemented playing with the state machines of the hard-sip-phone but we were wondering if this has been investigated from you guys. Thanks F.S.Salloum _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Feb 26 08:46:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04131 for ; Wed, 26 Feb 2003 08:46:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QDtc309445 for sip-archive@odin.ietf.org; Wed, 26 Feb 2003 08:55:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QDt2p09422; Wed, 26 Feb 2003 08:55:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QDrhp09355 for ; Wed, 26 Feb 2003 08:53:43 -0500 Received: from mail.ireste.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04110 for ; Wed, 26 Feb 2003 08:43:42 -0500 (EST) Received: from polytech.univ-nantes.fr (cvs [193.52.81.5]) by mail.ireste.fr (8.11.2/8.11.2) with ESMTP id h1QDfta22753 for ; Wed, 26 Feb 2003 14:41:55 +0100 Message-ID: <3E5CC3DB.20706@polytech.univ-nantes.fr> Date: Wed, 26 Feb 2003 14:40:43 +0100 From: Antoine Duval User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021203 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] whiteboard Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi everybody ! I'm searching information for developping a shared whiteboard (protocol and application) with sip, but i'm not satisfied of results... That why, i'm posting this email here, in case you can help me. Any idea ? Antoine _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Feb 26 11:10:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13958 for ; Wed, 26 Feb 2003 11:10:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QGJpW21972 for sip-archive@odin.ietf.org; Wed, 26 Feb 2003 11:19:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QGIsp21915; Wed, 26 Feb 2003 11:18:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QGE1p21669 for ; Wed, 26 Feb 2003 11:14:01 -0500 Received: from dgesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13774; Wed, 26 Feb 2003 11:03:56 -0500 (EST) Received: from pmismtp06.wcomnet.com ([166.38.62.54]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0HAX00FESBBBFL@firewall.wcom.com>; Wed, 26 Feb 2003 16:04:23 +0000 (GMT) Received: from pmismtp06.wcomnet.com by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HAX00M01BBB3Q@pmismtp06.wcomnet.com>; Wed, 26 Feb 2003 16:04:23 +0000 (GMT) Received: from hsinnreich2 ([166.50.97.127]) by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HAX00L3JBBAHT@pmismtp06.wcomnet.com>; Wed, 26 Feb 2003 16:04:23 +0000 (GMT) Date: Wed, 26 Feb 2003 10:04:22 -0600 From: Henry Sinnreich Subject: RE: [Sip] whiteboard In-reply-to: <3E5CC3DB.20706@polytech.univ-nantes.fr> To: "'Antoine Duval'" , sip@ietf.org, sipping@ietf.org Cc: Alan Johnston , Rohan Mahy , Eric Burger Message-id: <004d01c2ddb0$ba9fc290$bd8332a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I believe the shared whiteboard is of special interest to the conferencing design team of the SIPPING WG - where this belongs BTW. Thanks, Henry Henry Sinnreich WorldCom 400 International Parkway Richardson, Texas 75081 USA > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Antoine Duval > Sent: Wednesday, February 26, 2003 7:41 AM > To: sip@ietf.org > Subject: [Sip] whiteboard > > > Hi everybody ! > > I'm searching information for developping a shared whiteboard > (protocol > and application) with sip, but i'm not satisfied of results... > > That why, i'm posting this email here, in case you can help me. > > Any idea ? > > Antoine > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Feb 26 11:39:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15126 for ; Wed, 26 Feb 2003 11:39:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QGmxr24442 for sip-archive@odin.ietf.org; Wed, 26 Feb 2003 11:48:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QGmVp24423; Wed, 26 Feb 2003 11:48:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QGjxp24290 for ; Wed, 26 Feb 2003 11:45:59 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15031 for ; Wed, 26 Feb 2003 11:35:53 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.6/8.12.6) with ESMTP id h1QGd7F3015790; Wed, 26 Feb 2003 09:39:08 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 26 Feb 2003 09:39:07 -0700 Message-ID: Thread-Topic: Sip timers and what granularity do we want in the sip protocol mib? thread-index: AcLdtZSa3MKcbv49Td+TvT2dOd4MPA== From: "Jean-Francois Mule" To: Cc: "Kevin Lingle" , "Kavitha P." X-Approved: ondar Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1QGjxp24291 Subject: [Sip] Sip timers and what granularity do we want in the sip protocol mib? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit We have currently some tables for timers & retry counters in sip-mib-draft04 (sipCommonCfgTimer and sipCommonCfgRetry). Reading more about rfc3261, it seems that SIP entities have to set the various variable timers (Timer A - K based on T1 by default or as the spec mandates it). Most if not all default timer values are dependent on the value of T1. So, in the past sip mib drafts, we've always provided more flexibility (i.e. provided ways to touch specific method timers without affecting their default values to T1 but allowing more granularity if needed). I see the same proposal here. In other words, we've got 2 options: --- OPTION A - define atomic timers (this is my preference even if it means default all the atomic timers to multiples of T1) SipCommonCfgTimerEntry ::= SEQUENCE { sipCfgTimerA Unsigned32, sipCfgTimerB Unsigned32, sipCfgTimerC Unsigned32, sipCfgTimerD Unsigned32, sipCfgTimerE Unsigned32, sipCfgTimerF Unsigned32, sipCfgTimerG Unsigned32, sipCfgTimerH Unsigned32, sipCfgTimerI Unsigned32, sipCfgTimerJ Unsigned32, sipCfgTimerK Unsigned32, sipCfgTimerT1 Unsigned32, sipCfgTimerT2 Unsigned32, sipCfgTimerT4 Unsigned32 } --- OPTION B - define t1, t2, t4 and that is it. One can make the argument that that is all we really need. SipCommonCfgTimerEntry ::= SEQUENCE { sipCfgTimerT1 Unsigned32, sipCfgTimerT2 Unsigned32, sipCfgTimerT4 Unsigned32 } Looking at it from an implementation point of view, I've always preferred to expose more granularity rather than the bare minimum (it is often built it in the code anyway). Any comments? Jean-Francois. --- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Feb 26 12:00:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16011 for ; Wed, 26 Feb 2003 12:00:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QHA6G26948 for sip-archive@odin.ietf.org; Wed, 26 Feb 2003 12:10:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QH9Op26771; Wed, 26 Feb 2003 12:09:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QH2lp25319 for ; Wed, 26 Feb 2003 12:02:47 -0500 Received: from web41511.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15620 for ; Wed, 26 Feb 2003 11:52:40 -0500 (EST) Message-ID: <20030226165635.56833.qmail@web41511.mail.yahoo.com> Received: from [193.12.63.119] by web41511.mail.yahoo.com via HTTP; Wed, 26 Feb 2003 08:56:35 PST Date: Wed, 26 Feb 2003 08:56:35 -0800 (PST) From: Sean Olson Subject: Re: [Sip] Sip timers and what granularity do we want in the sip protocol mib? To: Jean-Francois Mule , sip@ietf.org Cc: Kevin Lingle , "Kavitha P." In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , It would be interesting to know how common it is for implementations to actually change these timer values. In other words, do these really need to be exposed in the MIB at all? --- Jean-Francois Mule wrote: > We have currently some tables for timers & retry > counters in > sip-mib-draft04 (sipCommonCfgTimer and > sipCommonCfgRetry). > Reading more about rfc3261, it seems that SIP > entities have to set the > various variable timers (Timer A - K based on T1 by > default or as the > spec mandates it). Most if not all default timer > values are dependent on > the value of T1. > > So, in the past sip mib drafts, we've always > provided more flexibility > (i.e. provided ways to touch specific method timers > without affecting > their default values to T1 but allowing more > granularity if needed). I > see the same proposal here. In other words, we've > got 2 options: > > --- OPTION A - define atomic timers > (this is my preference even if it means default all > the atomic timers to > multiples of T1) > > SipCommonCfgTimerEntry ::= SEQUENCE { > sipCfgTimerA Unsigned32, > sipCfgTimerB Unsigned32, > sipCfgTimerC Unsigned32, > sipCfgTimerD Unsigned32, > sipCfgTimerE Unsigned32, > sipCfgTimerF Unsigned32, > sipCfgTimerG Unsigned32, > sipCfgTimerH Unsigned32, > sipCfgTimerI Unsigned32, > sipCfgTimerJ Unsigned32, > sipCfgTimerK Unsigned32, > sipCfgTimerT1 Unsigned32, > sipCfgTimerT2 Unsigned32, > sipCfgTimerT4 Unsigned32 > } > > --- OPTION B - define t1, t2, t4 and that is it. > One can make the argument that that is all we really > need. > SipCommonCfgTimerEntry ::= SEQUENCE { > sipCfgTimerT1 Unsigned32, > sipCfgTimerT2 Unsigned32, > sipCfgTimerT4 Unsigned32 > } > > > Looking at it from an implementation point of view, > I've always > preferred to expose more granularity rather than the > bare minimum (it is > often built it in the code anyway). > > Any comments? > Jean-Francois. > --- > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP > Protocol > Use sip-implementors@cs.columbia.edu for questions > on current sip > Use sipping@ietf.org for new developments on the > application of sip __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Feb 26 12:44:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17613 for ; Wed, 26 Feb 2003 12:44:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QHsQo29524 for sip-archive@odin.ietf.org; Wed, 26 Feb 2003 12:54:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QHs0p29505; Wed, 26 Feb 2003 12:54:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QHqvp29429 for ; Wed, 26 Feb 2003 12:52:57 -0500 Received: from gateway.hns.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17534; Wed, 26 Feb 2003 12:42:48 -0500 (EST) Received: from excore1.hns.com (excore1.hns.com [139.85.52.104]) by gateway.hns.com (Switch-3.0.0/Switch-3.0.0) with ESMTP id h1QHk3J3028089; Wed, 26 Feb 2003 12:46:03 -0500 (EST) Received: from atlas (atlas.hns.com [139.85.177.110]) by excore1.hns.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h1QHjvD10991; Wed, 26 Feb 2003 12:45:57 -0500 (EST) To: Sean Olson Cc: Jean-Francois Mule , "Kavitha P." , Kevin Lingle , sip@ietf.org, sip-admin@ietf.org Subject: Re: [Sip] Sip timers and what granularity do we want in the sip protocol mib? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Arjun Roychowdhury" Date: Wed, 26 Feb 2003 12:45:55 -0500 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.10 |March 22, 2002) at 02/26/2003 12:44:00 PM, Serialize complete at 02/26/2003 12:44:00 PM Content-Type: text/plain; charset="us-ascii" X-Filtered: Sendmail MIME Filter v1.0.7 excore1.hns.com h1QHjvD10991 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Just speaking from experience - some of our customers do play with these settings to suit their deployed networks. I cannot provide more conclusive reasons (unless these folks speak out on their own) May not be very common but it does happen - so I would vote for these parameters to remain. regds arjun -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301 212 7860 (M): 240 997 0066{@vtext.com} Sean Olson Sent by: sip-admin@ietf.org 02/26/2003 11:56 AM To: Jean-Francois Mule , sip@ietf.org cc: Kevin Lingle , "Kavitha P." Subject: Re: [Sip] Sip timers and what granularity do we want in the sip protocol mib? It would be interesting to know how common it is for implementations to actually change these timer values. In other words, do these really need to be exposed in the MIB at all? --- Jean-Francois Mule wrote: > We have currently some tables for timers & retry > counters in > sip-mib-draft04 (sipCommonCfgTimer and > sipCommonCfgRetry). > Reading more about rfc3261, it seems that SIP > entities have to set the > various variable timers (Timer A - K based on T1 by > default or as the > spec mandates it). Most if not all default timer > values are dependent on > the value of T1. > > So, in the past sip mib drafts, we've always > provided more flexibility > (i.e. provided ways to touch specific method timers > without affecting > their default values to T1 but allowing more > granularity if needed). I > see the same proposal here. In other words, we've > got 2 options: > > --- OPTION A - define atomic timers > (this is my preference even if it means default all > the atomic timers to > multiples of T1) > > SipCommonCfgTimerEntry ::= SEQUENCE { > sipCfgTimerA Unsigned32, > sipCfgTimerB Unsigned32, > sipCfgTimerC Unsigned32, > sipCfgTimerD Unsigned32, > sipCfgTimerE Unsigned32, > sipCfgTimerF Unsigned32, > sipCfgTimerG Unsigned32, > sipCfgTimerH Unsigned32, > sipCfgTimerI Unsigned32, > sipCfgTimerJ Unsigned32, > sipCfgTimerK Unsigned32, > sipCfgTimerT1 Unsigned32, > sipCfgTimerT2 Unsigned32, > sipCfgTimerT4 Unsigned32 > } > > --- OPTION B - define t1, t2, t4 and that is it. > One can make the argument that that is all we really > need. > SipCommonCfgTimerEntry ::= SEQUENCE { > sipCfgTimerT1 Unsigned32, > sipCfgTimerT2 Unsigned32, > sipCfgTimerT4 Unsigned32 > } > > > Looking at it from an implementation point of view, > I've always > preferred to expose more granularity rather than the > bare minimum (it is > often built it in the code anyway). > > Any comments? > Jean-Francois. > --- > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP > Protocol > Use sip-implementors@cs.columbia.edu for questions > on current sip > Use sipping@ietf.org for new developments on the > application of sip __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Feb 26 12:55:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17999 for ; Wed, 26 Feb 2003 12:55:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QI55c29965 for sip-archive@odin.ietf.org; Wed, 26 Feb 2003 13:05:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QI4Vp29911; Wed, 26 Feb 2003 13:04:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QI23p29776 for ; Wed, 26 Feb 2003 13:02:03 -0500 Received: from auemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17806 for ; Wed, 26 Feb 2003 12:51:54 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1QHtmT29707 for ; Wed, 26 Feb 2003 12:55:48 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Feb 2003 17:55:47 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EC15@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Sean Olson'" , Jean-Francois Mule , sip@ietf.org Cc: Kevin Lingle , "Kavitha P." Subject: RE: [Sip] Sip timers and what granularity do we want in the sip p rotocol mib? Date: Wed, 26 Feb 2003 17:55:46 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , For use over the radio interface, 3GPP has recommended longer values of some of these timers, based on the increased round trip delay that might be expected. Therefore an piece of user equipment that can use SIP in either mobile environment or directly connected to the internet might need to be able to alter the values of these timers. Of course, whether that is best done by the MIB or not is a different question. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Sean Olson [mailto:seancolson@yahoo.com] > Sent: 26 February 2003 16:57 > To: Jean-Francois Mule; sip@ietf.org > Cc: Kevin Lingle; Kavitha P. > Subject: Re: [Sip] Sip timers and what granularity do we want > in the sip > protocol mib? > > > It would be interesting to know how common it is > for implementations to actually change these > timer values. In other words, do these really > need to be exposed in the MIB at all? > > > --- Jean-Francois Mule wrote: > > We have currently some tables for timers & retry > > counters in > > sip-mib-draft04 (sipCommonCfgTimer and > > sipCommonCfgRetry). > > Reading more about rfc3261, it seems that SIP > > entities have to set the > > various variable timers (Timer A - K based on T1 by > > default or as the > > spec mandates it). Most if not all default timer > > values are dependent on > > the value of T1. > > > > So, in the past sip mib drafts, we've always > > provided more flexibility > > (i.e. provided ways to touch specific method timers > > without affecting > > their default values to T1 but allowing more > > granularity if needed). I > > see the same proposal here. In other words, we've > > got 2 options: > > > > --- OPTION A - define atomic timers > > (this is my preference even if it means default all > > the atomic timers to > > multiples of T1) > > > > SipCommonCfgTimerEntry ::= SEQUENCE { > > sipCfgTimerA Unsigned32, > > sipCfgTimerB Unsigned32, > > sipCfgTimerC Unsigned32, > > sipCfgTimerD Unsigned32, > > sipCfgTimerE Unsigned32, > > sipCfgTimerF Unsigned32, > > sipCfgTimerG Unsigned32, > > sipCfgTimerH Unsigned32, > > sipCfgTimerI Unsigned32, > > sipCfgTimerJ Unsigned32, > > sipCfgTimerK Unsigned32, > > sipCfgTimerT1 Unsigned32, > > sipCfgTimerT2 Unsigned32, > > sipCfgTimerT4 Unsigned32 > > } > > > > --- OPTION B - define t1, t2, t4 and that is it. > > One can make the argument that that is all we really > > need. > > SipCommonCfgTimerEntry ::= SEQUENCE { > > sipCfgTimerT1 Unsigned32, > > sipCfgTimerT2 Unsigned32, > > sipCfgTimerT4 Unsigned32 > > } > > > > > > Looking at it from an implementation point of view, > > I've always > > preferred to expose more granularity rather than the > > bare minimum (it is > > often built it in the code anyway). > > > > Any comments? > > Jean-Francois. > > --- > > _______________________________________________ > > Sip mailing list > > https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP > > Protocol > > Use sip-implementors@cs.columbia.edu for questions > > on current sip > > Use sipping@ietf.org for new developments on the > > application of sip > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.yahoo.com/ > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Feb 26 12:58:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18146 for ; Wed, 26 Feb 2003 12:58:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QI7ct30783 for sip-archive@odin.ietf.org; Wed, 26 Feb 2003 13:07:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QI7Dp30383; Wed, 26 Feb 2003 13:07:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QI6Kp30027 for ; Wed, 26 Feb 2003 13:06:20 -0500 Received: from fox.iptel.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18052; Wed, 26 Feb 2003 12:56:12 -0500 (EST) Received: from jku07.fokus.fraunhofer.de (port-212-202-200-46.reverse.qdsl-home.de [212.202.200.46]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id h1QHxSJ31894; Wed, 26 Feb 2003 18:59:28 +0100 Message-Id: <5.2.0.9.0.20030226125028.00b3e288@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 26 Feb 2003 12:54:38 +0100 To: jh@lohi.eng.song.fi, Stuart Jacobs From: Jiri Kuthan Subject: Re: [Sip] Re: [Sipping] New version of the SIP-AAA reqs draft Cc: Allison Mankin , sipping@ietf.org, sip@ietf.org In-Reply-To: <15963.31403.288541.988747@harjus.eng.song.fi> References: <5.1.1.6.0.20030221110917.04229140@pophost.gte.com> <5.1.1.6.0.20030221110917.04229140@pophost.gte.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Sorry for latency -- yes, I think that is a very important issue, and mentioning it in the draft would be very good. (Has anyone else made the observation too that operationally-related questions are rarely replied here?) I agree too it takes awareness of dialog state. It doesn't imply though, a proxy needs to be stateful -- record-routing can help, most likely along with some message integrity check if the dialog information is sensitive (which is most likely the case with AAA). -jiri At 03:16 PM 2/25/2003, jh@lohi.eng.song.fi wrote: >nobody replied to my bye question, but after some more thinking i have >myself come to the conclusion that it is impossible for a regular sip >proxy without a dialog state or a crypto identification of all requests >from its clients to do any accounting at all. > >so it would be important for a sip-aaa requirements draft to list the >preconditions for sip accounting. > >-- juha > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Feb 26 15:45:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24503 for ; Wed, 26 Feb 2003 15:45:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QKtaX09432 for sip-archive@odin.ietf.org; Wed, 26 Feb 2003 15:55:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QKt9p09409; Wed, 26 Feb 2003 15:55:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QKrcp09324 for ; Wed, 26 Feb 2003 15:53:38 -0500 Received: from smtp.ccpu.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24411 for ; Wed, 26 Feb 2003 15:43:28 -0500 (EST) Received: from [172.16.1.166] (helo=CCPU00215) by smtp.ccpu.com with smtp (Exim 3.13 #1 (Debian)) id 18o8Sa-0002Sj-00 for ; Wed, 26 Feb 2003 12:47:24 -0800 From: "Hwan Dong" To: Date: Wed, 26 Feb 2003 12:47:14 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Subject: [Sip] One question Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello, I got a question for the timer B in rfc3261 in the following scenarion: UAC ---INVITE----> <--1xx----- ---CANCEL----> <--200(CAN)----- ...(no 487)... in section 9.1, it says: " Note that both the transaction corresponding to the original request and the CANCEL transaction will complete independently. However, a UAC canceling a request cannot rely on receiving a 487 (Request Terminated) response for the original request, as an RFC 2543- compliant UAS will not generate such a response. If there is no final response for the original request in 64*T1 seconds (T1 is defined in Section 17.1.1.1), the client SHOULD then consider the original transaction cancelled and SHOULD destroy the client transaction handling the original request." Does this mean there is some timer(timer B?) running for the proceeding INVITE client transaction? Otherwise, how do we know how long to wait for 487? But in section 17.1.1.2: when INVITE client transaction enters PROCEEDING stage, the timer B is not running anymore. Could someone clarify this scenario? Thanks, --Hwan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Feb 26 16:29:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26487 for ; Wed, 26 Feb 2003 16:29:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QLcvu13058 for sip-archive@odin.ietf.org; Wed, 26 Feb 2003 16:38:57 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QLcPp13034; Wed, 26 Feb 2003 16:38:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QLTPp11965 for ; Wed, 26 Feb 2003 16:29:25 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26090 for ; Wed, 26 Feb 2003 16:19:14 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h1QLN7Lc011659; Wed, 26 Feb 2003 15:23:09 -0600 From: "Dean Willis" To: "'F.S.Salloum'" , "'Sip@Ietf. Org'" Cc: "'Tasos Dagiouklas'" Subject: RE: [Sip] Of-hook and On-hook @ sip? Date: Wed, 26 Feb 2003 15:22:56 -0600 Message-ID: <007201c2dddd$3c1dc4d0$ee036e3f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1QLTPp11966 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit F. S. Salloum asked: > One simple question is there a similar message > in SIP which works like on-hook and off-hook on > the PSTN world (Q-931)? > > I know that this can be implemented playing with > the state machines of the hard-sip-phone but we were > wondering if this has been investigated from you guys. In short, no. But the long answer, is "maybe, depending on what you want to do with it". On/off hook are valid terms in the confined space of a traditional phone line, which is either "in use" or "not is use". We tend to assume that if a line is on-hook, then there is no session on that line and the phone attached to it (if any -- the line is usually on-hook even if there is no phone) may be rung to request a new session to the phone. We also tend to assume that if a line is off-hook, that there is no session on that line and the phone may NOT be rung to request a new session, and that only signaling on that line (such as call waiting tones) or preemption on that line (barge-in) can be used to communicate with the user. So there are a couple of questions that might be asked here: 1) Is the user of the phone busy with another call right now? 2) Is all the bandwidth available to a phone in-use right now? Sometimes, in SIP-land, these concepts make no sense. For example, I have 100Mb/s to my phone. I can juggle six different calls simultaneously. And sometimes I wach a video stream, set up with SIP, on my PC at the same time. But sometimes, they do make sense. Imagine a single-line phone adapter such as the Cisco box distributed by Vonage. On one side, an rj-45 for ethernet. On the other side, an rj-11 for a phone. Assume a really simple version, with no call waiting. Let's say we want an upstream server to, if there's a session on my UA, automatically forward any new session requests to my voice mail. The question is (as #1 or #2), hows does it KNOW I'm in a session? Seveal options come to mind. Option 1: The upstream server is a dialog-stateful proxy. If I have an ongoing INVITE dialog, it automagically diverts new INVITEs to my voice mail. Option 2: The upstream server is a B2BUA, which is by definition dialog-stateful, and it does the same diversion thing. Option 3: We use an event package, and the upstream server subscribes to the session state of my adapter. When my adapter starts a session, it sends a NOTIFY to the server saying "I have a session, for which I have an identifier.". When my adapter stops a session, it sends anotehr NOIFY saying "This session (using identifier) has ended". -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Wed Feb 26 16:50:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27733 for ; Wed, 26 Feb 2003 16:50:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QM0Fr14416 for sip-archive@odin.ietf.org; Wed, 26 Feb 2003 17:00:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QLxop14132; Wed, 26 Feb 2003 16:59:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QLw9p14075 for ; Wed, 26 Feb 2003 16:58:09 -0500 Received: from ihemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27549 for ; Wed, 26 Feb 2003 16:47:58 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1QLpi507133; Wed, 26 Feb 2003 16:51:45 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id PAA08828; Wed, 26 Feb 2003 15:51:43 -0600 (CST) Message-ID: <3E5D36ED.5050800@lucent.com> Date: Wed, 26 Feb 2003 15:51:41 -0600 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories 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: Dean Willis CC: "'F.S.Salloum'" , "'Sip@Ietf. Org'" , "'Tasos Dagiouklas'" Subject: Re: [Sip] Of-hook and On-hook @ sip? References: <007201c2dddd$3c1dc4d0$ee036e3f@txdwillis> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dean Willis wrote: [...] > Option 3: We use an event package, and the upstream server subscribes to the > session state of my adapter. When my adapter starts a session, it sends a > NOTIFY to the server saying "I have a session, for which I have an > identifier.". When my adapter stops a session, it sends anotehr NOIFY saying > "This session (using identifier) has ended". One such event package is specified by the SPIRITS protocol. For implementation experience, see: http://www.ietf.org/internet-drafts/draft-gurbani-spirits-implementation-00.txt Cheers, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Feb 27 01:21:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09664 for ; Thu, 27 Feb 2003 01:21:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1R6V8f12246 for sip-archive@odin.ietf.org; Thu, 27 Feb 2003 01:31:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R6URp12215; Thu, 27 Feb 2003 01:30:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R6RNp12138 for ; Thu, 27 Feb 2003 01:27:23 -0500 Received: from node24.neomagic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09615 for ; Thu, 27 Feb 2003 01:16:59 -0500 (EST) Received: from node26.neomagic.com (node26.neomagic.com [192.168.51.26]) by node24.neomagic.com (8.12.5/8.12.5) with ESMTP id h1R7Dmwl027108; Wed, 26 Feb 2003 23:13:48 -0800 Received: from neomagic.com ([192.168.31.253]) by node26.neomagic.com (8.12.5/8.12.5) with ESMTP id h1R7KACV026175; Wed, 26 Feb 2003 23:20:14 -0800 Message-ID: <3E5DAE89.7030103@neomagic.com> Date: Thu, 27 Feb 2003 11:52:01 +0530 From: Mukul Purohit Organization: NeoMagic User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Natesan Kannan , sip@ietf.org Subject: Re: [Sip] INVITE client Transaction.... References: <4.3.2.7.2.20030213163904.0356c838@desh.cisco.com> <001e01c2d374$3cbe3280$6802120a@in.huawei.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi, I Still have few doubts .... (inline) Natesan Kannan wrote: > Excerpt from a previous query on the same subject and Jonathan's reply > embedded... > -Kannan > > ********* > This is an application issue. It can decide to give up at any time and > send CANCEL. We don't want to specify the maximum time a user will let > the phone ring. "... if the server transaction on the remote end dies." If this is due to the crashing of the remote machine (as depicted in scenario by Rajesh), then how can sending CANCEL by the application useful (in coming out of the proceeding state). Since remote machine is not contactable, it cannot send "200" to CANCEL, and "487" to INVITE. So INVITE transaction is still stucked waiting for "487". What I can think is that application (or stack's transaction layer) is required to ensure a mechanism to cancel the INVITE transaction through CANCEL transaction. Is this correct? > > -Jonathan R. > > Vijaya Venkatachalam wrote: > >>Hi, >> >>I have a question regarding the INVITE transaction >>state machine. >> >>It seems that in RFC 3261 - transaction state machine for >>INVITE transactions, there is a potential for >>the client side transaction to indefinitely be >>in the "Proceeding" state since all timers >>are cancelled on the reception of a 1xx response. >> >>Can somebody tell me how the client side transaction >>can come out of this state, if the server transaction on >>the remote end dies? >> >>Is it that the timer B is not cancelled and that only >>timer A is cancelled when the 1xx is received or is >>there some other means. >> >>Appreciate a quick response. >> >>Thanks, >>Vijaya > > ********* > ----- Original Message ----- > From: "Rajesh Kalshetty (rkalshet)" > To: > Sent: Thursday, February 13, 2003 5:35 PM > Subject: [Sip] INVITE client Transaction.... > > > >>Hi all, >> >>I have a question Regarding the INVITE client Transactions state m/c . > > When > >>a client transaction moves to the proceeding state after receiving a >>provisional response by how much time it has to wait in that state for a >>final response. >> >> >> A Invite B >> |------------------>| >> | 1xx | >> |<------------------| >> | | >> | x client crashes. >> | | >> >>suppose that client B crashes after it sends a provisional response,i > > don't > >>find any way for the A's client transaction to come out of the proceeding >>state in RFC. >> >> >>Regrds, >>Rajesh k. >> >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Feb 27 01:40:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09853 for ; Thu, 27 Feb 2003 01:40:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1R6nrT13474 for sip-archive@odin.ietf.org; Thu, 27 Feb 2003 01:49:53 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R6nTp13466; Thu, 27 Feb 2003 01:49:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R6m5p13432 for ; Thu, 27 Feb 2003 01:48:05 -0500 Received: from mta2 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09810 for ; Thu, 27 Feb 2003 01:37:38 -0500 (EST) Received: from mta2 (localhost [127.0.0.1]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTP id <0HAY00A0ZFYI3O@mta2.huawei.com> for sip@ietf.org; Thu, 27 Feb 2003 14:42:19 +0800 (CST) Received: from mailin.huawei.com ([10.18.1.252]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTP id <0HAY00KXDFYDVU@mta2.huawei.com> for sip@ietf.org; Thu, 27 Feb 2003 14:42:18 +0800 (CST) Received: from nkannanCL1068 ([10.18.2.104]) by mailin.huawei.com (Netscape Messaging Server 4.15) with ESMTP id HAYG1300.T0C; Thu, 27 Feb 2003 14:43:51 +0800 Date: Thu, 27 Feb 2003 12:08:11 +0530 From: Natesan Kannan Subject: Re: [Sip] INVITE client Transaction.... To: Mukul Purohit , sip@ietf.org Message-id: <002a01c2de2a$cc7a3930$6802120a@in.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4.3.2.7.2.20030213163904.0356c838@desh.cisco.com> <001e01c2d374$3cbe3280$6802120a@in.huawei.com> <3E5DAE89.7030103@neomagic.com> Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi, RFC 3261 says, in section 9: "Note that both the transaction corresponding to the original request and the CANCEL transaction will complete independently. However, a UAC canceling a request cannot rely on receiving a 487 (Request Terminated) response for the original request, as an RFC 2543- compliant UAS will not generate such a response. If there is no final response for the original request in 64*T1 seconds (T1 is defined in Section 17.1.1.1), the client SHOULD then consider the original transaction cancelled and SHOULD destroy the client transaction handling the original request." Secondly, the scenario of CANCEL not getting a 200 response because of the server crash cannot happen, as CANCEL is hop-by-hop and a 200 OK is sent from the next proxy in line. In general, the timer mentioned above could be started irrespective of *any* response to the CANCEL, including a time-out. -Kannan ----- Original Message ----- From: "Mukul Purohit" To: "Natesan Kannan" ; Sent: Thursday, February 27, 2003 11:52 AM Subject: Re: [Sip] INVITE client Transaction.... > hi, > I Still have few doubts .... (inline) > > Natesan Kannan wrote: > > Excerpt from a previous query on the same subject and Jonathan's reply > > embedded... > > -Kannan > > > > ********* > > This is an application issue. It can decide to give up at any time and > > send CANCEL. We don't want to specify the maximum time a user will let > > the phone ring. > > > "... if the server transaction on the remote end dies." If this is due > to the crashing of the remote machine (as depicted in scenario by > Rajesh), then how can sending CANCEL by the application useful (in > coming out of the proceeding state). Since remote machine is not > contactable, it cannot send "200" to CANCEL, and "487" to INVITE. So > INVITE transaction is still stucked waiting for "487". > What I can think is that application (or stack's transaction layer) is > required to ensure a mechanism to cancel the INVITE transaction through > CANCEL transaction. Is this correct? > > > > > -Jonathan R. > > > > Vijaya Venkatachalam wrote: > > > >>Hi, > >> > >>I have a question regarding the INVITE transaction > >>state machine. > >> > >>It seems that in RFC 3261 - transaction state machine for > >>INVITE transactions, there is a potential for > >>the client side transaction to indefinitely be > >>in the "Proceeding" state since all timers > >>are cancelled on the reception of a 1xx response. > >> > >>Can somebody tell me how the client side transaction > >>can come out of this state, if the server transaction on > >>the remote end dies? > >> > >>Is it that the timer B is not cancelled and that only > >>timer A is cancelled when the 1xx is received or is > >>there some other means. > >> > >>Appreciate a quick response. > >> > >>Thanks, > >>Vijaya > > > > ********* > > ----- Original Message ----- > > From: "Rajesh Kalshetty (rkalshet)" > > To: > > Sent: Thursday, February 13, 2003 5:35 PM > > Subject: [Sip] INVITE client Transaction.... > > > > > > > >>Hi all, > >> > >>I have a question Regarding the INVITE client Transactions state m/c . > > > > When > > > >>a client transaction moves to the proceeding state after receiving a > >>provisional response by how much time it has to wait in that state for a > >>final response. > >> > >> > >> A Invite B > >> |------------------>| > >> | 1xx | > >> |<------------------| > >> | | > >> | x client crashes. > >> | | > >> > >>suppose that client B crashes after it sends a provisional response,i > > > > don't > > > >>find any way for the A's client transaction to come out of the proceeding > >>state in RFC. > >> > >> > >>Regrds, > >>Rajesh k. > >> > >> > >> > >>_______________________________________________ > >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>This list is for NEW development of the core SIP Protocol > >>Use sip-implementors@cs.columbia.edu for questions on current sip > >>Use sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Feb 27 02:35:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21683 for ; Thu, 27 Feb 2003 02:35:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1R7jYR27611 for sip-archive@odin.ietf.org; Thu, 27 Feb 2003 02:45:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R7j8p27592; Thu, 27 Feb 2003 02:45:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R62rp10592 for ; Thu, 27 Feb 2003 01:02:53 -0500 Received: from web10308.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA09154 for ; Thu, 27 Feb 2003 00:52:31 -0500 (EST) Message-ID: <20030227055627.26121.qmail@web10308.mail.yahoo.com> Received: from [194.175.117.86] by web10308.mail.yahoo.com via HTTP; Wed, 26 Feb 2003 21:56:27 PST Date: Wed, 26 Feb 2003 21:56:27 -0800 (PST) From: murali foru To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Sip] SIP grammar Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi All, I have a small doubt on SIP grammar defined in RFC 3261. I see the grammar to be ambigious. Accept = "Accept" HCOLON [ accept-range *(COMMA accept-range) ] accept-range = media-range *(SEMI accept-param) media-range = ( "*/*" / ( m-type SLASH "*" ) / ( m-type SLASH m-subtype ) ) *( SEMI m-parameter ) accept-param = ("q" EQUAL qvalue) / generic-param Both m-parameter and accept-param are delimited by SEMI. How do I differentiate? Thanks in advance Regards, Murali __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Feb 27 03:33:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22841 for ; Thu, 27 Feb 2003 03:33:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1R8h9f31367 for sip-archive@odin.ietf.org; Thu, 27 Feb 2003 03:43:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R8gap31346; Thu, 27 Feb 2003 03:42:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R8djp31205 for ; Thu, 27 Feb 2003 03:39:45 -0500 Received: from seimg0.sei.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22771 for ; Thu, 27 Feb 2003 03:29:20 -0500 (EST) Received: from sei-is.sei.co.jp (sei-is.sei.co.jp [133.153.208.201]) by seimg0.sei.co.jp (8.11.6/3.7W) with ESMTP id h1R8X4Y23756; Thu, 27 Feb 2003 17:33:05 +0900 Received: from seimh1.seimh.sei.co.jp by sei-is.sei.co.jp (8.8.8/3.6W-02/02/99) id RAA02949; Thu, 27 Feb 2003 17:33:03 +0900 (JST) Received: from pop2.osaka.sei.co.jp ([133.153.206.3]) by seimh1.seimh.sei.co.jp (8.11.6/3.7W) with ESMTP id h1R8X3320140; Thu, 27 Feb 2003 17:33:03 +0900 Received: from [133.153.176.218] by pop2.osaka.sei.co.jp (8.8.8/R8-sei-generic/solaris-1.0-02/27/98) with ESMTP id RAA20273; Thu, 27 Feb 2003 17:32:56 +0900 (JST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 27 Feb 2003 17:32:53 +0900 From: Eiji Tomimura To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Interaction RFC3262 and Record-Route header included in 18x response Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear all, I would like to clarify when we use PRACK and Record-Route header for 18x response. Consider the following scenario. The UAC receives 18x response with Record-Route header, and route set and remote target are updated based on section 12.1.2 of RFC3261: UAC Proxy ----INVITE----> <--- 18x ----- w/ Record-Route header ---- PRACK ---> --- Question 1) When the UAC construct PRACK, it MUST follow the procedure described in section 12.2.1.1 of RFC3261, and Request-URI should be changed to the remote target, and also Route header should be included. Is that correct? --- Question 2) In case the UAC try to cancel the call: UAC Proxy ----INVITE----> <--- 18x ----- w/ Record-Route header ---- PRACK ---> <--- 200 OK---- ----CANCEL----> <--- 200 OK---- <--- 487 ------ ---- ACK -----> When the UAC construct CANCEL, as described in section 9.1 of RFC3261, it MUST use the same Request-URI as in the original INVITE. It means that the UAC MUST NOT use route set and remote target information received already in Record-Route header. Is that correct? --- Question 3) In the scenario described in Question 2), the UAC finally sends ACK after receiving 487 response. When the UAC construct ACK, as described in section 17.1.1.3 of RFC3261, it MUST use the same Request-URI as in the original INVITE. It means that the UAC MUST NOT use route set and remote target information received already in Record-Route header. Is that correct? --- Thank you very much for your assistance. Regards, - Eiji Tomimura -- Eiji Tomimura Senior Engineer Systems Technology Dept., Information Technology R&D Laboratories Sumitomo Electric Industries, Ltd. Phone: +81-6-6466-5632 Fax: +81-6-6462-4586 Email: tomimura@sei.co.jp _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Feb 27 03:37:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22905 for ; Thu, 27 Feb 2003 03:37:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1R8lVJ31512 for sip-archive@odin.ietf.org; Thu, 27 Feb 2003 03:47:31 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R8kjp31489; Thu, 27 Feb 2003 03:46:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R8hSp31383 for ; Thu, 27 Feb 2003 03:43:28 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22839 for ; Thu, 27 Feb 2003 03:33:02 -0500 (EST) Received: from SANTHOSHCL1095 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HAY00HXLKSUKQ@mta0.huawei.com> for sip@ietf.org; Thu, 27 Feb 2003 16:26:58 +0800 (CST) Date: Thu, 27 Feb 2003 13:59:18 +0530 From: Santhosh Jose Subject: Re: [Sip] SIP grammar To: murali foru , sip@ietf.org Reply-to: Santhosh Jose Message-id: <00a001c2de3a$53034d70$5a02120a@in.huawei.com> Organization: Huawei Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20030227055627.26121.qmail@web10308.mail.yahoo.com> Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hello Murali, Please refer to section 14.1 of RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1 (quoted below) Each media-range MAY be followed by one or more accept-params, beginning with the "q" parameter for indicating a relative quality factor. The first "q" parameter (if any) separates the media-range parameter(s) from the accept-params. Quality factors allow the user or user agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (section 3.9). The default value is q=1. Note: Use of the "q" parameter name to separate media type parameters from Accept extension parameters is due to historical practice. Although this prevents any media type parameter named "q" from being used with a media range, such an event is believed to be unlikely given the lack of any "q" parameters in the IANA media type registry and the rare usage of any media type parameters in Accept. Future media types are discouraged from registering any parameter named "q". This clearly defines the usage of media and accept parameters . Regards, Santhosh Jose ----- Original Message ----- From: "murali foru" To: Sent: Thursday, February 27, 2003 11:26 AM Subject: [Sip] SIP grammar > Hi All, > > I have a small doubt on SIP grammar defined in RFC > 3261. I see the grammar to be ambigious. > > Accept = "Accept" HCOLON > [ accept-range *(COMMA > accept-range) ] > accept-range = media-range *(SEMI accept-param) > media-range = ( "*/*" > / ( m-type SLASH "*" ) > / ( m-type SLASH m-subtype ) > ) *( SEMI m-parameter ) > accept-param = ("q" EQUAL qvalue) / generic-param > > Both m-parameter and accept-param are delimited by > SEMI. How do I differentiate? > > Thanks in advance > > Regards, > Murali > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.yahoo.com/ > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Feb 27 07:51:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28480 for ; Thu, 27 Feb 2003 07:51:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RD1k215318 for sip-archive@odin.ietf.org; Thu, 27 Feb 2003 08:01:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RD1Gp15225; Thu, 27 Feb 2003 08:01:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCtwp14702 for ; Thu, 27 Feb 2003 07:55:58 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27894; Thu, 27 Feb 2003 07:45:27 -0500 (EST) Message-Id: <200302271245.HAA27894@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 27 Feb 2003 07:45:27 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-smime-aes-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : S/MIME AES Requirement for SIP Author(s) : J. Peterson Filename : draft-ietf-sip-smime-aes-00.txt Pages : 6 Date : 2003-2-26 RFC3261 currently specifies 3DES as the required minimum ciphersuite for implementations of S/MIME in SIP. This document updates the normative guidance of RFC3261 to require the Advanced Encryption Standard (AES) for S/MIME. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-smime-aes-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-smime-aes-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-sip-smime-aes-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-26160948.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-smime-aes-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-smime-aes-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-26160948.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Feb 27 13:10:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14611 for ; Thu, 27 Feb 2003 13:10:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RIL2D09548 for sip-archive@odin.ietf.org; Thu, 27 Feb 2003 13:21:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RIKPp09492; Thu, 27 Feb 2003 13:20:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RIIVp09378 for ; Thu, 27 Feb 2003 13:18:31 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14517 for ; Thu, 27 Feb 2003 13:07:54 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.6/8.12.6) with ESMTP id h1RIAjF3001244; Thu, 27 Feb 2003 11:10:45 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Sip] Sip timers and what granularity do we want in the sip protocol mib? Date: Thu, 27 Feb 2003 11:10:45 -0700 Message-ID: Thread-Topic: [Sip] Sip timers and what granularity do we want in the sip protocol mib? thread-index: AcLdyOTClF4ncDzSRuuoYfDDOIKUNgAwmJDg From: "Jean-Francois Mule" To: "Drage, Keith (Keith)" , "Sean Olson" , "Arjun Roychowdhury" Cc: "Kevin Lingle" , "Kavitha P." , X-Approved: ondar Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1RIIVp09380 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Thank you for your input. We will keep the following for the upcoming sipmib draft: > > > SipCommonCfgTimerEntry ::= SEQUENCE { > > > sipCfgTimerA Unsigned32, > > > sipCfgTimerB Unsigned32, > > > sipCfgTimerC Unsigned32, > > > sipCfgTimerD Unsigned32, > > > sipCfgTimerE Unsigned32, > > > sipCfgTimerF Unsigned32, > > > sipCfgTimerG Unsigned32, > > > sipCfgTimerH Unsigned32, > > > sipCfgTimerI Unsigned32, > > > sipCfgTimerJ Unsigned32, > > > sipCfgTimerK Unsigned32, > > > sipCfgTimerT1 Unsigned32, > > > sipCfgTimerT2 Unsigned32, > > > sipCfgTimerT4 Unsigned32 > > > } Jean-Francois. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Feb 27 18:37:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27880 for ; Thu, 27 Feb 2003 18:37:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RNlds31606 for sip-archive@odin.ietf.org; Thu, 27 Feb 2003 18:47:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RNl8p31593; Thu, 27 Feb 2003 18:47:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RNj8p31488 for ; Thu, 27 Feb 2003 18:45:08 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27811 for ; Thu, 27 Feb 2003 18:34:24 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1RNb3202037 for ; Fri, 28 Feb 2003 01:37:04 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 28 Feb 2003 01:38:19 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 28 Feb 2003 01:38:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Sip timers and what granularity do we want in the sip protocol mib? Date: Fri, 28 Feb 2003 01:38:18 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701428E3B@esebe019.ntc.nokia.com> Thread-Topic: [Sip] Sip timers and what granularity do we want in the sip protocol mib? Thread-Index: AcLdwgqU6a5lzGPeTpuJ+mWGAKdnfgAjRRdw To: , , , Cc: , X-OriginalArrivalTime: 27 Feb 2003 23:38:18.0828 (UTC) FILETIME=[4E91A8C0:01C2DEB9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1RNj8p31489 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I think T1, T2, T4 and Timer D are enough. Regards, Hisham > -----Original Message----- > From: ext Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Wednesday, February 26, 2003 7:56 PM > To: 'Sean Olson'; Jean-Francois Mule; sip@ietf.org > Cc: Kevin Lingle; Kavitha P. > Subject: RE: [Sip] Sip timers and what granularity do we want > in the sip > protocol mib? > > > For use over the radio interface, 3GPP has recommended longer > values of some of these timers, based on the increased round > trip delay that might be expected. Therefore an piece of user > equipment that can use SIP in either mobile environment or > directly connected to the internet might need to be able to > alter the values of these timers. > > Of course, whether that is best done by the MIB or not is a > different question. > > Keith > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > > -----Original Message----- > > From: Sean Olson [mailto:seancolson@yahoo.com] > > Sent: 26 February 2003 16:57 > > To: Jean-Francois Mule; sip@ietf.org > > Cc: Kevin Lingle; Kavitha P. > > Subject: Re: [Sip] Sip timers and what granularity do we want > > in the sip > > protocol mib? > > > > > > It would be interesting to know how common it is > > for implementations to actually change these > > timer values. In other words, do these really > > need to be exposed in the MIB at all? > > > > > > --- Jean-Francois Mule wrote: > > > We have currently some tables for timers & retry > > > counters in > > > sip-mib-draft04 (sipCommonCfgTimer and > > > sipCommonCfgRetry). > > > Reading more about rfc3261, it seems that SIP > > > entities have to set the > > > various variable timers (Timer A - K based on T1 by > > > default or as the > > > spec mandates it). Most if not all default timer > > > values are dependent on > > > the value of T1. > > > > > > So, in the past sip mib drafts, we've always > > > provided more flexibility > > > (i.e. provided ways to touch specific method timers > > > without affecting > > > their default values to T1 but allowing more > > > granularity if needed). I > > > see the same proposal here. In other words, we've > > > got 2 options: > > > > > > --- OPTION A - define atomic timers > > > (this is my preference even if it means default all > > > the atomic timers to > > > multiples of T1) > > > > > > SipCommonCfgTimerEntry ::= SEQUENCE { > > > sipCfgTimerA Unsigned32, > > > sipCfgTimerB Unsigned32, > > > sipCfgTimerC Unsigned32, > > > sipCfgTimerD Unsigned32, > > > sipCfgTimerE Unsigned32, > > > sipCfgTimerF Unsigned32, > > > sipCfgTimerG Unsigned32, > > > sipCfgTimerH Unsigned32, > > > sipCfgTimerI Unsigned32, > > > sipCfgTimerJ Unsigned32, > > > sipCfgTimerK Unsigned32, > > > sipCfgTimerT1 Unsigned32, > > > sipCfgTimerT2 Unsigned32, > > > sipCfgTimerT4 Unsigned32 > > > } > > > > > > --- OPTION B - define t1, t2, t4 and that is it. > > > One can make the argument that that is all we really > > > need. > > > SipCommonCfgTimerEntry ::= SEQUENCE { > > > sipCfgTimerT1 Unsigned32, > > > sipCfgTimerT2 Unsigned32, > > > sipCfgTimerT4 Unsigned32 > > > } > > > > > > > > > Looking at it from an implementation point of view, > > > I've always > > > preferred to expose more granularity rather than the > > > bare minimum (it is > > > often built it in the code anyway). > > > > > > Any comments? > > > Jean-Francois. > > > --- > > > _______________________________________________ > > > Sip mailing list > > > https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP > > > Protocol > > > Use sip-implementors@cs.columbia.edu for questions > > > on current sip > > > Use sipping@ietf.org for new developments on the > > > application of sip > > > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Tax Center - forms, calculators, tips, more > > http://taxes.yahoo.com/ > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Feb 28 02:03:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10288 for ; Fri, 28 Feb 2003 02:03:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1S7Dp302273 for sip-archive@odin.ietf.org; Fri, 28 Feb 2003 02:13:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1S7D8p02123; Fri, 28 Feb 2003 02:13:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1S78Np28603 for ; Fri, 28 Feb 2003 02:08:23 -0500 Received: from node24.neomagic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05554 for ; Fri, 28 Feb 2003 01:57:30 -0500 (EST) Received: from node26.neomagic.com (node26.neomagic.com [192.168.51.26]) by node24.neomagic.com (8.12.5/8.12.5) with ESMTP id h1S7sWwl025883; Thu, 27 Feb 2003 23:54:32 -0800 Received: from neomagic.com ([192.168.31.253]) by node26.neomagic.com (8.12.5/8.12.5) with ESMTP id h1S80vCV028451; Fri, 28 Feb 2003 00:01:04 -0800 Message-ID: <3E5F0999.10802@neomagic.com> Date: Fri, 28 Feb 2003 12:32:49 +0530 From: Mukul Purohit Organization: NeoMagic User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Natesan Kannan , sip@ietf.org Subject: Re: [Sip] INVITE client Transaction.... References: <4.3.2.7.2.20030213163904.0356c838@desh.cisco.com> <001e01c2d374$3cbe3280$6802120a@in.huawei.com> <3E5DAE89.7030103@neomagic.com> <002a01c2de2a$cc7a3930$6802120a@in.huawei.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi coments inline .... first a request : can u provide me the link to the previuos discussion on the same subject, as u had mentioned. I browsed the archive but cudnt filter out the mails. Natesan Kannan wrote: > Hi, > > RFC 3261 says, in section 9: > "Note that both the transaction corresponding to the original request > and the CANCEL transaction will complete independently. However, a > UAC canceling a request cannot rely on receiving a 487 (Request > Terminated) response for the original request, as an RFC 2543- > compliant UAS will not generate such a response. If there is no > final response for the original request in 64*T1 seconds (T1 is > defined in Section 17.1.1.1), the client SHOULD then consider the > original transaction cancelled and SHOULD destroy the client > transaction handling the original request." Doesnt it implies that transaction layer must cancel the transaction after this timeout (which can be timer B). If the implication is that UA must start this timer (called by some other name) then Timer B and this timer are duplicated (unnecessary overhead ). > Secondly, the scenario of CANCEL not getting a 200 response because of > the server crash cannot happen, as CANCEL is hop-by-hop and a 200 OK is sent > from the next proxy in line. I am not sure on this. Wont the proxy reply with trying and wait for an OK from the remote host and then send an OK. Please clarify on this issue. > In general, the timer mentioned above could be started irrespective of > *any* response to the CANCEL, including a time-out. I agree to this. But this timer must be started at transaction layer when initial INVITE request is send (that is the reason i m calling it timer B) and a mention in the state diagram over the path from *proceeding* state to *terminated* state on the expiry of this timer. - mukul > -Kannan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Feb 28 02:07:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16075 for ; Fri, 28 Feb 2003 02:07:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1S7I8N02387 for sip-archive@odin.ietf.org; Fri, 28 Feb 2003 02:18:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1S7GDp02340; Fri, 28 Feb 2003 02:16:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RFWsp27530 for ; Thu, 27 Feb 2003 10:32:54 -0500 Received: from smtp02.sohu.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07807 for ; Thu, 27 Feb 2003 10:22:19 -0500 (EST) Received: from dxf (unknown [166.111.64.129]) by smtp02.sohu.com (Postfix) with ESMTP id 4F4DC6ABF8 for ; Thu, 27 Feb 2003 23:25:55 +0800 (CST) Date: Fri, 28 Feb 2003 0:21:11 +0800 From: "Gemini6" Reply-To: Gemini6@sohu.com To: "sip@ietf.org" X-mailer: Foxmail 4.1 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Message-Id: <20030227152555.4F4DC6ABF8@smtp02.sohu.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1RFWsp27531 Subject: [Sip] understanding problem Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit hi all in rfc2543 page 103 A proxy server forwards any response for Call-IDs for which it does not have a pending transaction according to the response's Via header. what's the meaning of Call-IDs here? Do the response's Via header been used to determine a transaction is pending or not? It seems not (from the others parts of this rfc). ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Gemini6 ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Gemini6@sohu.com ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-02-28 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Feb 28 02:08:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16114 for ; Fri, 28 Feb 2003 02:08:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1S7IrL02449 for sip-archive@odin.ietf.org; Fri, 28 Feb 2003 02:18:53 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1S7INp02406; Fri, 28 Feb 2003 02:18:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RJ10p12669 for ; Thu, 27 Feb 2003 14:01:00 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16657; Thu, 27 Feb 2003 13:50:21 -0500 (EST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h1RIsI6N003242; Thu, 27 Feb 2003 10:54:18 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABV32175; Thu, 27 Feb 2003 10:54:07 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA09393; Thu, 27 Feb 2003 10:54:06 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15966.24270.833471.219940@thomasm-u1.cisco.com> Date: Thu, 27 Feb 2003 10:54:06 -0800 (PST) To: Internet-Drafts@ietf.org Cc: IETF-Announce:;, sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-smime-aes-00.txt In-Reply-To: <200302271245.HAA27894@ietf.org> References: <200302271245.HAA27894@ietf.org> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit So I don't get it. Why is this SIP specific? It seems to me that this should be taken up by the SMIME wg. For one thing, this would break any SIP message which contains SMIME which is then relayed to email, or anything else which uses SMIME. Also: I don't think that AES is considered "more secure" than 3DES. Faster yes. Lastly, this is underspecified as it doesn't say what mode to use, text about IV's, etc, etc. Another good reason to punt this to a more appropriate wg. Mike Internet-Drafts@ietf.org writes: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol Working Group of the IETF. > > Title : S/MIME AES Requirement for SIP > Author(s) : J. Peterson > Filename : draft-ietf-sip-smime-aes-00.txt > Pages : 6 > Date : 2003-2-26 > > RFC3261 currently specifies 3DES as the required minimum ciphersuite > for implementations of S/MIME in SIP. This document updates the > normative guidance of RFC3261 to require the Advanced Encryption > Standard (AES) for S/MIME. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-smime-aes-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-sip-smime-aes-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-sip-smime-aes-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-Type: text/plain > Content-ID: <2003-2-26160948.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-ietf-sip-smime-aes-00.txt > Content-Type: text/plain > Content-ID: <2003-2-26160948.I-D@ietf.org> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Feb 28 02:50:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16602 for ; Fri, 28 Feb 2003 02:50:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1S80ra05099 for sip-archive@odin.ietf.org; Fri, 28 Feb 2003 03:00:53 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1S80Sp05078; Fri, 28 Feb 2003 03:00:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1S7xAp05024 for ; Fri, 28 Feb 2003 02:59:10 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16562 for ; Fri, 28 Feb 2003 02:48:15 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h1S7pfC29995; Fri, 28 Feb 2003 07:51:41 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Feb 2003 02:51:51 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214E86@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Michael Thomas'" Cc: sip@ietf.org Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-smime-aes-00.txt Date: Fri, 28 Feb 2003 02:51:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Well, obviously the use of AES for S/MIME is not SIP-specific; hence the fact that we reference smime-aes-alg, the S/MIME WG draft defining the use of AES by S/MIME (currently in IETF LC), in our SIP draft. sip-smime-aes merely provides text to replace some specific existing language in RFC3261 that recommended 3DES for S/MIME (as well as cleaning up some related S/MIME details). Adopting AES would not necessarily, as you suggest, render incomprehensible any SIP message S/MIME body that is relayed to email - the email UA would merely need to support smime-aes-alg; we aren't inventing something new here. Futhermore, we are intentionally not necessarily specifying modes for AES and the like - we're relying on the existing smime-aes-alg mode to specify how AES should be used with S/MIME. The thrust of this draft is merely to point the SIP standard to AES rather than 3DES. As for the 'more secure' phrase, are you perhaps reading an older version of the draft? The current text says "comparably secure" to 3DES. I changed the text since the last revision in response to a comment to similar effect. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Thursday, February 27, 2003 10:54 AM > To: Internet-Drafts@ietf.org > Cc: IETF-Announce; sip@ietf.org > Subject: [Sip] I-D ACTION:draft-ietf-sip-smime-aes-00.txt > > > > So I don't get it. Why is this SIP specific? It > seems to me that this should be taken up by the > SMIME wg. For one thing, this would break any SIP > message which contains SMIME which is then relayed > to email, or anything else which uses SMIME. > > Also: I don't think that AES is considered "more > secure" than 3DES. Faster yes. Lastly, this is > underspecified as it doesn't say what mode to use, > text about IV's, etc, etc. Another good reason to > punt this to a more appropriate wg. > > Mike > > Internet-Drafts@ietf.org writes: > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > This draft is a work item of the Session Initiation > Protocol Working Group of the IETF. > > > > Title : S/MIME AES Requirement for SIP > > Author(s) : J. Peterson > > Filename : draft-ietf-sip-smime-aes-00.txt > > Pages : 6 > > Date : 2003-2-26 > > > > RFC3261 currently specifies 3DES as the required minimum > ciphersuite > > for implementations of S/MIME in SIP. This document updates the > > normative guidance of RFC3261 to require the Advanced Encryption > > Standard (AES) for S/MIME. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-smime-aes-00.txt > > > > To remove yourself from the IETF Announcement list, send a > message to > > ietf-announce-request with the word unsubscribe in the > body of the message. > > > > Internet-Drafts are also available by anonymous FTP. Login > with the username > > "anonymous" and a password of your e-mail address. After > logging in, > > type "cd internet-drafts" and then > > "get draft-ietf-sip-smime-aes-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-sip-smime-aes-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-Type: text/plain > > Content-ID: <2003-2-26160948.I-D@ietf.org> > > > > ENCODING mime > > FILE /internet-drafts/draft-ietf-sip-smime-aes-00.txt > > Content-Type: text/plain > > Content-ID: <2003-2-26160948.I-D@ietf.org> > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Feb 28 07:32:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23281 for ; Fri, 28 Feb 2003 07:32:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SCgWu23585 for sip-archive@odin.ietf.org; Fri, 28 Feb 2003 07:42:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SCfrp23520; Fri, 28 Feb 2003 07:41:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SCe4p23315 for ; Fri, 28 Feb 2003 07:40:04 -0500 Received: from usjk1001.kddi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23057 for ; Fri, 28 Feb 2003 07:29:04 -0500 (EST) Received: from usjk1005.kddi.com (usjk1005 [10.96.2.2]) by usjk1001.kddi.com (3.7W-030228132558) with ESMTP id VAA00308; Fri, 28 Feb 2003 21:33:00 +0900 (JST) Received: from usjk1010.kddi.com (localhost [127.0.0.1]) by usjk1005.kddi.com (3.7W-021210104931) with ESMTP id VAA07564; Fri, 28 Feb 2003 21:32:59 +0900 (JST) Received: from KDDI-0003PC0281.kddi.com ([133.128.137.10]) by usjk1010.kddi.com (InterMail vM.5.01.02.00 201-253-116-121-20001201) with ESMTP id <20030228123258.KVYW1044.usjk1010.kddi.com@KDDI-0003PC0281.kddi.com>; Fri, 28 Feb 2003 21:32:58 +0900 To: tomimura@sei.co.jp, sip@ietf.org Subject: Re: [Sip] Interaction RFC3262 and Record-Route header included in 18xresponse From: Takuya Sawada References: In-Reply-To: Message-Id: <200302282132.BEE81174.BEB-VUXTB@kddi.com> X-Mailer: Winbiff [Version 2.41] X-Accept-Language: ja,en Date: Fri, 28 Feb 2003 21:32:58 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hello, I think you are correct, as described in RFCs. - CANCEL and ACK for non-2xx are related to (INVITE) TRANSACTION. - PRACK is related to (early) DIALOG (established by INVITE). That is why they are different. Note that ACK for 2xx is constructed as PRACK except that it uses routing information from 2xx not from reliable 18x. Regards, Takuya Sawada > Dear all, > > I would like to clarify when we use PRACK and Record-Route header for 18x > response. > > Consider the following scenario. The UAC receives 18x response with > Record-Route header, and route set and remote target are updated based on > section 12.1.2 of RFC3261: > > UAC Proxy > ----INVITE----> > <--- 18x ----- w/ Record-Route header > ---- PRACK ---> > > > --- > Question 1) > > When the UAC construct PRACK, it MUST follow the procedure described in > section 12.2.1.1 of RFC3261, and Request-URI should be changed to the remote > target, and also Route header should be included. > > Is that correct? > > > --- > Question 2) > > In case the UAC try to cancel the call: > > UAC Proxy > ----INVITE----> > <--- 18x ----- w/ Record-Route header > ---- PRACK ---> > <--- 200 OK---- > > ----CANCEL----> > <--- 200 OK---- > > <--- 487 ------ > ---- ACK -----> > > > When the UAC construct CANCEL, as described in section 9.1 of RFC3261, it > MUST use the same Request-URI as in the original INVITE. It means that the > UAC MUST NOT use route set and remote target information received already in > Record-Route header. > > Is that correct? > > --- > > Question 3) > > In the scenario described in Question 2), the UAC finally sends ACK after > receiving 487 response. > > When the UAC construct ACK, as described in section 17.1.1.3 of RFC3261, it > MUST use the same Request-URI as in the original INVITE. It means that the > UAC MUST NOT use route set and remote target information received already in > Record-Route header. > > Is that correct? > > --- > > Thank you very much for your assistance. > > Regards, > - Eiji Tomimura > > > > -- > Eiji Tomimura > Senior Engineer > Systems Technology Dept., Information Technology R&D Laboratories > Sumitomo Electric Industries, Ltd. > Phone: +81-6-6466-5632 Fax: +81-6-6462-4586 Email: tomimura@sei.co.jp > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -------- Takuya Sawada KDDI Corporation (KDDI) KDDI Bldg. 2-3-2 Nishishinjuku Shinjuku-ku, Tokyo 163-8003, Japan Tel: +81-3-3347-7406 Fax: +81-3-3347-7418 tu-sawada@kddi.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Feb 28 12:14:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05188 for ; Fri, 28 Feb 2003 12:14:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SHP3113086 for sip-archive@odin.ietf.org; Fri, 28 Feb 2003 12:25:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SHOXp13060; Fri, 28 Feb 2003 12:24:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SHMep12983 for ; Fri, 28 Feb 2003 12:22:40 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05064 for ; Fri, 28 Feb 2003 12:11:34 -0500 (EST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h1SHFV6N029225; Fri, 28 Feb 2003 09:15:31 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABW21085; Fri, 28 Feb 2003 09:15:30 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA09626; Fri, 28 Feb 2003 09:15:29 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15967.39217.712208.98413@thomasm-u1.cisco.com> Date: Fri, 28 Feb 2003 09:15:29 -0800 (PST) To: "Peterson, Jon" Cc: "'Michael Thomas'" , sip@ietf.org Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-smime-aes-00.txt In-Reply-To: <15A2739B7DAA624D8091C65981D7DA8101214E86@stntexch2.va.neustar.com> References: <15A2739B7DAA624D8091C65981D7DA8101214E86@stntexch2.va.neustar.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit First off, it seems that I misread the references which negates one of comments about being underspecified (I thought it pointed at a NIST doc, instead of the smime wg draft). And yes, I couldn't find the current draft yet, so I read the previous draft... if it says "comparable", that's fine. But I guess I'm still sort of mystified as to why this even needs a draft for SIP. The current wording says that other cipher suites are OK... so what are we doing here which causes interoperability that otherwise wouldn't have happened? AFAIK, there's no negotiation for anything in SIP about the cipher suites for SMIME, so we're still in the "ready, fire, aim" situation as before... what problem is being solved here? Mike Peterson, Jon writes: > > Well, obviously the use of AES for S/MIME is not SIP-specific; hence the > fact that we reference smime-aes-alg, the S/MIME WG draft defining the use > of AES by S/MIME (currently in IETF LC), in our SIP draft. sip-smime-aes > merely provides text to replace some specific existing language in RFC3261 > that recommended 3DES for S/MIME (as well as cleaning up some related S/MIME > details). > > Adopting AES would not necessarily, as you suggest, render incomprehensible > any SIP message S/MIME body that is relayed to email - the email UA would > merely need to support smime-aes-alg; we aren't inventing something new > here. Futhermore, we are intentionally not necessarily specifying modes for > AES and the like - we're relying on the existing smime-aes-alg mode to > specify how AES should be used with S/MIME. The thrust of this draft is > merely to point the SIP standard to AES rather than 3DES. > > As for the 'more secure' phrase, are you perhaps reading an older version of > the draft? The current text says "comparably secure" to 3DES. I changed the > text since the last revision in response to a comment to similar effect. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Thursday, February 27, 2003 10:54 AM > > To: Internet-Drafts@ietf.org > > Cc: IETF-Announce; sip@ietf.org > > Subject: [Sip] I-D ACTION:draft-ietf-sip-smime-aes-00.txt > > > > > > > > So I don't get it. Why is this SIP specific? It > > seems to me that this should be taken up by the > > SMIME wg. For one thing, this would break any SIP > > message which contains SMIME which is then relayed > > to email, or anything else which uses SMIME. > > > > Also: I don't think that AES is considered "more > > secure" than 3DES. Faster yes. Lastly, this is > > underspecified as it doesn't say what mode to use, > > text about IV's, etc, etc. Another good reason to > > punt this to a more appropriate wg. > > > > Mike > > > > Internet-Drafts@ietf.org writes: > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > This draft is a work item of the Session Initiation > > Protocol Working Group of the IETF. > > > > > > Title : S/MIME AES Requirement for SIP > > > Author(s) : J. Peterson > > > Filename : draft-ietf-sip-smime-aes-00.txt > > > Pages : 6 > > > Date : 2003-2-26 > > > > > > RFC3261 currently specifies 3DES as the required minimum > > ciphersuite > > > for implementations of S/MIME in SIP. This document updates the > > > normative guidance of RFC3261 to require the Advanced Encryption > > > Standard (AES) for S/MIME. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-sip-smime-aes-00.txt > > > > > > To remove yourself from the IETF Announcement list, send a > > message to > > > ietf-announce-request with the word unsubscribe in the > > body of the message. > > > > > > Internet-Drafts are also available by anonymous FTP. Login > > with the username > > > "anonymous" and a password of your e-mail address. After > > logging in, > > > type "cd internet-drafts" and then > > > "get draft-ietf-sip-smime-aes-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-sip-smime-aes-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-Type: text/plain > > > Content-ID: <2003-2-26160948.I-D@ietf.org> > > > > > > ENCODING mime > > > FILE /internet-drafts/draft-ietf-sip-smime-aes-00.txt > > > Content-Type: text/plain > > > Content-ID: <2003-2-26160948.I-D@ietf.org> > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Feb 28 14:10:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09308 for ; Fri, 28 Feb 2003 14:10:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SJLWw21049 for sip-archive@odin.ietf.org; Fri, 28 Feb 2003 14:21:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SJKlp20995; Fri, 28 Feb 2003 14:20:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SJJCp20881 for ; Fri, 28 Feb 2003 14:19:12 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09252 for ; Fri, 28 Feb 2003 14:08:03 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h1SJB9C07748; Fri, 28 Feb 2003 19:11:09 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Feb 2003 14:11:19 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214E88@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Michael Thomas'" Cc: sip@ietf.org Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-smime-aes-00.txt Date: Fri, 28 Feb 2003 14:11:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I was able to grab the draft from the repository now; maybe it wasn't available immediately after the I-D announcement. The rationale for this draft, as it states itself, is to provide an encryption algorithm that is easier for lightweight SIP UAs to implement, and to use the same encryption algorithm that we mandate for TLS. If we supersede the text in RFC3261 before S/MIME is widely implemented, there will be no need for dual-algorithm implementations (supporting both 3DES and AES, which currently would be required for implementing TLS and S/MIME). Many implementers of lightweight UAs have complained that S/MIME is too heavy, in part because of the 3DES requirement. I think this is reason enough to push this draft forward. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Friday, February 28, 2003 9:15 AM > To: Peterson, Jon > Cc: 'Michael Thomas'; sip@ietf.org > Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-smime-aes-00.txt > > > > First off, it seems that I misread the references > which negates one of comments about being > underspecified (I thought it pointed at a NIST > doc, instead of the smime wg draft). And yes, I > couldn't find the current draft yet, so I read the > previous draft... if it says "comparable", that's > fine. > > But I guess I'm still sort of mystified as to why > this even needs a draft for SIP. The current > wording says that other cipher suites are OK... > so what are we doing here which causes > interoperability that otherwise wouldn't have > happened? AFAIK, there's no negotiation for > anything in SIP about the cipher suites for SMIME, > so we're still in the "ready, fire, aim" situation > as before... what problem is being solved here? > > Mike > > Peterson, Jon writes: > > > > Well, obviously the use of AES for S/MIME is not > SIP-specific; hence the > > fact that we reference smime-aes-alg, the S/MIME WG draft > defining the use > > of AES by S/MIME (currently in IETF LC), in our SIP draft. > sip-smime-aes > > merely provides text to replace some specific existing > language in RFC3261 > > that recommended 3DES for S/MIME (as well as cleaning up > some related S/MIME > > details). > > > > Adopting AES would not necessarily, as you suggest, render > incomprehensible > > any SIP message S/MIME body that is relayed to email - the > email UA would > > merely need to support smime-aes-alg; we aren't inventing > something new > > here. Futhermore, we are intentionally not necessarily > specifying modes for > > AES and the like - we're relying on the existing > smime-aes-alg mode to > > specify how AES should be used with S/MIME. The thrust of > this draft is > > merely to point the SIP standard to AES rather than 3DES. > > > > As for the 'more secure' phrase, are you perhaps reading > an older version of > > the draft? The current text says "comparably secure" to > 3DES. I changed the > > text since the last revision in response to a comment to > similar effect. > > > > Jon Peterson > > NeuStar, Inc. > > > > > -----Original Message----- > > > From: Michael Thomas [mailto:mat@cisco.com] > > > Sent: Thursday, February 27, 2003 10:54 AM > > > To: Internet-Drafts@ietf.org > > > Cc: IETF-Announce; sip@ietf.org > > > Subject: [Sip] I-D ACTION:draft-ietf-sip-smime-aes-00.txt > > > > > > > > > > > > So I don't get it. Why is this SIP specific? It > > > seems to me that this should be taken up by the > > > SMIME wg. For one thing, this would break any SIP > > > message which contains SMIME which is then relayed > > > to email, or anything else which uses SMIME. > > > > > > Also: I don't think that AES is considered "more > > > secure" than 3DES. Faster yes. Lastly, this is > > > underspecified as it doesn't say what mode to use, > > > text about IV's, etc, etc. Another good reason to > > > punt this to a more appropriate wg. > > > > > > Mike > > > > > > Internet-Drafts@ietf.org writes: > > > > A New Internet-Draft is available from the on-line > > > Internet-Drafts directories. > > > > This draft is a work item of the Session Initiation > > > Protocol Working Group of the IETF. > > > > > > > > Title : S/MIME AES Requirement for SIP > > > > Author(s) : J. Peterson > > > > Filename : draft-ietf-sip-smime-aes-00.txt > > > > Pages : 6 > > > > Date : 2003-2-26 > > > > > > > > RFC3261 currently specifies 3DES as the required minimum > > > ciphersuite > > > > for implementations of S/MIME in SIP. This document > updates the > > > > normative guidance of RFC3261 to require the Advanced > Encryption > > > > Standard (AES) for S/MIME. > > > > > > > > A URL for this Internet-Draft is: > > > > > http://www.ietf.org/internet-drafts/draft-ietf-sip-smime-aes-00.txt > > > > > > > > To remove yourself from the IETF Announcement list, send a > > > message to > > > > ietf-announce-request with the word unsubscribe in the > > > body of the message. > > > > > > > > Internet-Drafts are also available by anonymous FTP. Login > > > with the username > > > > "anonymous" and a password of your e-mail address. After > > > logging in, > > > > type "cd internet-drafts" and then > > > > "get draft-ietf-sip-smime-aes-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-sip-smime-aes-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-Type: text/plain > > > > Content-ID: <2003-2-26160948.I-D@ietf.org> > > > > > > > > ENCODING mime > > > > FILE /internet-drafts/draft-ietf-sip-smime-aes-00.txt > > > > Content-Type: text/plain > > > > Content-ID: <2003-2-26160948.I-D@ietf.org> > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the > application of sip > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Feb 28 14:24:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09597 for ; Fri, 28 Feb 2003 14:24:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SJZEu21564 for sip-archive@odin.ietf.org; Fri, 28 Feb 2003 14:35:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SJYUp21523; Fri, 28 Feb 2003 14:34:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SJX6p21466 for ; Fri, 28 Feb 2003 14:33:06 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09550 for ; Fri, 28 Feb 2003 14:21:56 -0500 (EST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-msg-core-2.cisco.com (8.12.2/8.12.6) with ESMTP id h1SJPTHK003197; Fri, 28 Feb 2003 11:25:34 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABW36743; Fri, 28 Feb 2003 11:25:47 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA09633; Fri, 28 Feb 2003 11:25:47 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15967.47035.141217.311911@thomasm-u1.cisco.com> Date: Fri, 28 Feb 2003 11:25:47 -0800 (PST) To: "Peterson, Jon" Cc: "'Michael Thomas'" , sip@ietf.org Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-smime-aes-00.txt In-Reply-To: <15A2739B7DAA624D8091C65981D7DA8101214E88@stntexch2.va.neustar.com> References: <15A2739B7DAA624D8091C65981D7DA8101214E88@stntexch2.va.neustar.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit 3DES is the least of your problems. It's the use of CMS and certs that causes the bloat: 3DES is only about 10k of code. Also: it's generally prudent to have backup algorithms. I don't see why we should be trying to bend over backward to chase this since there's still a lot of 3DES legacy out there making the likelihood of 3DES-free images pretty low in the long run. In any case, you still haven't answered my question: how is this promoting interoperability? As far as I can see, it's just a pointer to the aes-smime draft and nothing else. Why is this needed? Mike Peterson, Jon writes: > > I was able to grab the draft from the repository now; maybe it wasn't > available immediately after the I-D announcement. > > The rationale for this draft, as it states itself, is to provide an > encryption algorithm that is easier for lightweight SIP UAs to implement, > and to use the same encryption algorithm that we mandate for TLS. If we > supersede the text in RFC3261 before S/MIME is widely implemented, there > will be no need for dual-algorithm implementations (supporting both 3DES and > AES, which currently would be required for implementing TLS and S/MIME). > Many implementers of lightweight UAs have complained that S/MIME is too > heavy, in part because of the 3DES requirement. I think this is reason > enough to push this draft forward. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Friday, February 28, 2003 9:15 AM > > To: Peterson, Jon > > Cc: 'Michael Thomas'; sip@ietf.org > > Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-smime-aes-00.txt > > > > > > > > First off, it seems that I misread the references > > which negates one of comments about being > > underspecified (I thought it pointed at a NIST > > doc, instead of the smime wg draft). And yes, I > > couldn't find the current draft yet, so I read the > > previous draft... if it says "comparable", that's > > fine. > > > > But I guess I'm still sort of mystified as to why > > this even needs a draft for SIP. The current > > wording says that other cipher suites are OK... > > so what are we doing here which causes > > interoperability that otherwise wouldn't have > > happened? AFAIK, there's no negotiation for > > anything in SIP about the cipher suites for SMIME, > > so we're still in the "ready, fire, aim" situation > > as before... what problem is being solved here? > > > > Mike > > > > Peterson, Jon writes: > > > > > > Well, obviously the use of AES for S/MIME is not > > SIP-specific; hence the > > > fact that we reference smime-aes-alg, the S/MIME WG draft > > defining the use > > > of AES by S/MIME (currently in IETF LC), in our SIP draft. > > sip-smime-aes > > > merely provides text to replace some specific existing > > language in RFC3261 > > > that recommended 3DES for S/MIME (as well as cleaning up > > some related S/MIME > > > details). > > > > > > Adopting AES would not necessarily, as you suggest, render > > incomprehensible > > > any SIP message S/MIME body that is relayed to email - the > > email UA would > > > merely need to support smime-aes-alg; we aren't inventing > > something new > > > here. Futhermore, we are intentionally not necessarily > > specifying modes for > > > AES and the like - we're relying on the existing > > smime-aes-alg mode to > > > specify how AES should be used with S/MIME. The thrust of > > this draft is > > > merely to point the SIP standard to AES rather than 3DES. > > > > > > As for the 'more secure' phrase, are you perhaps reading > > an older version of > > > the draft? The current text says "comparably secure" to > > 3DES. I changed the > > > text since the last revision in response to a comment to > > similar effect. > > > > > > Jon Peterson > > > NeuStar, Inc. > > > > > > > -----Original Message----- > > > > From: Michael Thomas [mailto:mat@cisco.com] > > > > Sent: Thursday, February 27, 2003 10:54 AM > > > > To: Internet-Drafts@ietf.org > > > > Cc: IETF-Announce; sip@ietf.org > > > > Subject: [Sip] I-D ACTION:draft-ietf-sip-smime-aes-00.txt > > > > > > > > > > > > > > > > So I don't get it. Why is this SIP specific? It > > > > seems to me that this should be taken up by the > > > > SMIME wg. For one thing, this would break any SIP > > > > message which contains SMIME which is then relayed > > > > to email, or anything else which uses SMIME. > > > > > > > > Also: I don't think that AES is considered "more > > > > secure" than 3DES. Faster yes. Lastly, this is > > > > underspecified as it doesn't say what mode to use, > > > > text about IV's, etc, etc. Another good reason to > > > > punt this to a more appropriate wg. > > > > > > > > Mike > > > > > > > > Internet-Drafts@ietf.org writes: > > > > > A New Internet-Draft is available from the on-line > > > > Internet-Drafts directories. > > > > > This draft is a work item of the Session Initiation > > > > Protocol Working Group of the IETF. > > > > > > > > > > Title : S/MIME AES Requirement for SIP > > > > > Author(s) : J. Peterson > > > > > Filename : draft-ietf-sip-smime-aes-00.txt > > > > > Pages : 6 > > > > > Date : 2003-2-26 > > > > > > > > > > RFC3261 currently specifies 3DES as the required minimum > > > > ciphersuite > > > > > for implementations of S/MIME in SIP. This document > > updates the > > > > > normative guidance of RFC3261 to require the Advanced > > Encryption > > > > > Standard (AES) for S/MIME. > > > > > > > > > > A URL for this Internet-Draft is: > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-sip-smime-aes-00.txt > > > > > > > > > > To remove yourself from the IETF Announcement list, send a > > > > message to > > > > > ietf-announce-request with the word unsubscribe in the > > > > body of the message. > > > > > > > > > > Internet-Drafts are also available by anonymous FTP. Login > > > > with the username > > > > > "anonymous" and a password of your e-mail address. After > > > > logging in, > > > > > type "cd internet-drafts" and then > > > > > "get draft-ietf-sip-smime-aes-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-sip-smime-aes-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-Type: text/plain > > > > > Content-ID: <2003-2-26160948.I-D@ietf.org> > > > > > > > > > > ENCODING mime > > > > > FILE /internet-drafts/draft-ietf-sip-smime-aes-00.txt > > > > > Content-Type: text/plain > > > > > Content-ID: <2003-2-26160948.I-D@ietf.org> > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sipping@ietf.org for new developments on the > > application of sip > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Feb 28 14:35:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10019 for ; Fri, 28 Feb 2003 14:35:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SJjns22700 for sip-archive@odin.ietf.org; Fri, 28 Feb 2003 14:45:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SJgFp22599; Fri, 28 Feb 2003 14:42:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SJfrp22570 for ; Fri, 28 Feb 2003 14:41:53 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09847 for ; Fri, 28 Feb 2003 14:30:44 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h1SJXsC08281; Fri, 28 Feb 2003 19:33:54 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Feb 2003 14:34:05 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214E89@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Michael Thomas'" Cc: sip@ietf.org Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-smime-aes-00.txt Date: Fri, 28 Feb 2003 14:33:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , No, Michael, I did answer your question: the one that went "what problem are we solving here?" This draft promotes interoperability by specifying one encryption algorithm that all SIP S/MIME implementations must support. The draft is indeed just a pointer to the specification of AES for S/MIME, yes. You might argue that it is of no value to use AES rather than 3DES, but I've pointed to a few ways that this is valuable. It is hardly 'bending over backwards' to amend a single paragraph of text in RFC3261. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Friday, February 28, 2003 11:26 AM > To: Peterson, Jon > Cc: 'Michael Thomas'; sip@ietf.org > Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-smime-aes-00.txt > > > > 3DES is the least of your problems. It's the use > of CMS and certs that causes the bloat: 3DES is > only about 10k of code. Also: it's generally > prudent to have backup algorithms. I don't see why > we should be trying to bend over backward to chase > this since there's still a lot of 3DES legacy out > there making the likelihood of 3DES-free images > pretty low in the long run. > > In any case, you still haven't answered my > question: how is this promoting interoperability? > As far as I can see, it's just a pointer to the > aes-smime draft and nothing else. Why is this > needed? > > Mike > > Peterson, Jon writes: > > > > I was able to grab the draft from the repository now; > maybe it wasn't > > available immediately after the I-D announcement. > > > > The rationale for this draft, as it states itself, is to provide an > > encryption algorithm that is easier for lightweight SIP > UAs to implement, > > and to use the same encryption algorithm that we mandate > for TLS. If we > > supersede the text in RFC3261 before S/MIME is widely > implemented, there > > will be no need for dual-algorithm implementations > (supporting both 3DES and > > AES, which currently would be required for implementing > TLS and S/MIME). > > Many implementers of lightweight UAs have complained that > S/MIME is too > > heavy, in part because of the 3DES requirement. I think > this is reason > > enough to push this draft forward. > > > > Jon Peterson > > NeuStar, Inc. > > > > > -----Original Message----- > > > From: Michael Thomas [mailto:mat@cisco.com] > > > Sent: Friday, February 28, 2003 9:15 AM > > > To: Peterson, Jon > > > Cc: 'Michael Thomas'; sip@ietf.org > > > Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-smime-aes-00.txt > > > > > > > > > > > > First off, it seems that I misread the references > > > which negates one of comments about being > > > underspecified (I thought it pointed at a NIST > > > doc, instead of the smime wg draft). And yes, I > > > couldn't find the current draft yet, so I read the > > > previous draft... if it says "comparable", that's > > > fine. > > > > > > But I guess I'm still sort of mystified as to why > > > this even needs a draft for SIP. The current > > > wording says that other cipher suites are OK... > > > so what are we doing here which causes > > > interoperability that otherwise wouldn't have > > > happened? AFAIK, there's no negotiation for > > > anything in SIP about the cipher suites for SMIME, > > > so we're still in the "ready, fire, aim" situation > > > as before... what problem is being solved here? > > > > > > Mike > > > > > > Peterson, Jon writes: > > > > > > > > Well, obviously the use of AES for S/MIME is not > > > SIP-specific; hence the > > > > fact that we reference smime-aes-alg, the S/MIME WG draft > > > defining the use > > > > of AES by S/MIME (currently in IETF LC), in our SIP draft. > > > sip-smime-aes > > > > merely provides text to replace some specific existing > > > language in RFC3261 > > > > that recommended 3DES for S/MIME (as well as cleaning up > > > some related S/MIME > > > > details). > > > > > > > > Adopting AES would not necessarily, as you suggest, render > > > incomprehensible > > > > any SIP message S/MIME body that is relayed to email - the > > > email UA would > > > > merely need to support smime-aes-alg; we aren't inventing > > > something new > > > > here. Futhermore, we are intentionally not necessarily > > > specifying modes for > > > > AES and the like - we're relying on the existing > > > smime-aes-alg mode to > > > > specify how AES should be used with S/MIME. The thrust of > > > this draft is > > > > merely to point the SIP standard to AES rather than 3DES. > > > > > > > > As for the 'more secure' phrase, are you perhaps reading > > > an older version of > > > > the draft? The current text says "comparably secure" to > > > 3DES. I changed the > > > > text since the last revision in response to a comment to > > > similar effect. > > > > > > > > Jon Peterson > > > > NeuStar, Inc. > > > > > > > > > -----Original Message----- > > > > > From: Michael Thomas [mailto:mat@cisco.com] > > > > > Sent: Thursday, February 27, 2003 10:54 AM > > > > > To: Internet-Drafts@ietf.org > > > > > Cc: IETF-Announce; sip@ietf.org > > > > > Subject: [Sip] I-D ACTION:draft-ietf-sip-smime-aes-00.txt > > > > > > > > > > > > > > > > > > > > So I don't get it. Why is this SIP specific? It > > > > > seems to me that this should be taken up by the > > > > > SMIME wg. For one thing, this would break any SIP > > > > > message which contains SMIME which is then relayed > > > > > to email, or anything else which uses SMIME. > > > > > > > > > > Also: I don't think that AES is considered "more > > > > > secure" than 3DES. Faster yes. Lastly, this is > > > > > underspecified as it doesn't say what mode to use, > > > > > text about IV's, etc, etc. Another good reason to > > > > > punt this to a more appropriate wg. > > > > > > > > > > Mike > > > > > > > > > > Internet-Drafts@ietf.org writes: > > > > > > A New Internet-Draft is available from the on-line > > > > > Internet-Drafts directories. > > > > > > This draft is a work item of the Session Initiation > > > > > Protocol Working Group of the IETF. > > > > > > > > > > > > Title : S/MIME AES Requirement for SIP > > > > > > Author(s) : J. Peterson > > > > > > Filename : draft-ietf-sip-smime-aes-00.txt > > > > > > Pages : 6 > > > > > > Date : 2003-2-26 > > > > > > > > > > > > RFC3261 currently specifies 3DES as the required minimum > > > > > ciphersuite > > > > > > for implementations of S/MIME in SIP. This document > > > updates the > > > > > > normative guidance of RFC3261 to require the Advanced > > > Encryption > > > > > > Standard (AES) for S/MIME. > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-sip-smime-aes-00.txt > > > > > > > > > > > > To remove yourself from the IETF Announcement > list, send a > > > > > message to > > > > > > ietf-announce-request with the word unsubscribe in the > > > > > body of the message. > > > > > > > > > > > > Internet-Drafts are also available by anonymous > FTP. Login > > > > > with the username > > > > > > "anonymous" and a password of your e-mail address. After > > > > > logging in, > > > > > > type "cd internet-drafts" and then > > > > > > "get draft-ietf-sip-smime-aes-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-sip-smime-aes-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-Type: text/plain > > > > > > Content-ID: <2003-2-26160948.I-D@ietf.org> > > > > > > > > > > > > ENCODING mime > > > > > > FILE /internet-drafts/draft-ietf-sip-smime-aes-00.txt > > > > > > Content-Type: text/plain > > > > > > Content-ID: <2003-2-26160948.I-D@ietf.org> > > > > > _______________________________________________ > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP Protocol > > > > > Use sip-implementors@cs.columbia.edu for questions > on current sip > > > > > Use sipping@ietf.org for new developments on the > > > application of sip > > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on > current sip > > > > Use sipping@ietf.org for new developments on the > application of sip > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Feb 28 14:45:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10347 for ; Fri, 28 Feb 2003 14:45:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SJtt723156 for sip-archive@odin.ietf.org; Fri, 28 Feb 2003 14:55:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SJtWp23114; Fri, 28 Feb 2003 14:55:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SJsPp23046 for ; Fri, 28 Feb 2003 14:54:25 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10297 for ; Fri, 28 Feb 2003 14:43:17 -0500 (EST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h1SJlE56000348; Fri, 28 Feb 2003 11:47:14 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABW39490; Fri, 28 Feb 2003 11:47:13 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA09637; Fri, 28 Feb 2003 11:47:13 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15967.48321.698509.92563@thomasm-u1.cisco.com> Date: Fri, 28 Feb 2003 11:47:13 -0800 (PST) To: "Peterson, Jon" Cc: "'Michael Thomas'" , sip@ietf.org Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-smime-aes-00.txt In-Reply-To: <15A2739B7DAA624D8091C65981D7DA8101214E89@stntexch2.va.neustar.com> References: <15A2739B7DAA624D8091C65981D7DA8101214E89@stntexch2.va.neustar.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Peterson, Jon writes: > > No, Michael, I did answer your question: the one that went "what problem are > we solving here?" > > This draft promotes interoperability by specifying one encryption algorithm > that all SIP S/MIME implementations must support. Except if you support S/MIME, then you by definition support 3DES, or so sez RFC 2633. Are you suggesting that these implementations not be RFC 2633 conformant? How else could they claim to support for S/MIME? > The draft is indeed just a > pointer to the specification of AES for S/MIME, yes. You might argue that it > is of no value to use AES rather than 3DES, but I've pointed to a few ways > that this is valuable. It is hardly 'bending over backwards' to amend a > single paragraph of text in RFC3261. I've made no claim about AES vs. 3DES. What does seem fairly clear is that the rationale given here is rather suspect. SIP-specific profiles of other protocols which are contrary to the minimum requirements plainly stated in those protocols is a very dangerous path to go down. Indeed, that is precicely the kind of thing that would cause interoperability to *break*. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip