From mailnull@www1.ietf.org Fri Nov 1 01:13:01 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29558 for ; Fri, 1 Nov 2002 01:13:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA16F4d25242 for sip-archive@odin.ietf.org; Fri, 1 Nov 2002 01:15: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 gA16Ecv25226; Fri, 1 Nov 2002 01:14: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 gA16Cnv25183 for ; Fri, 1 Nov 2002 01:12:49 -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 BAA29501 for ; Fri, 1 Nov 2002 01:10:15 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA16CbKV023973; Fri, 1 Nov 2002 07:12:37 +0100 (MET) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.112]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id gA16CaG3016476; Fri, 1 Nov 2002 08:12:36 +0200 (EET) Message-ID: <3DC21B54.8A9CE43E@lmf.ericsson.se> Date: Fri, 01 Nov 2002 08:12:37 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Arunachalam Venkatraman CC: sip@ietf.org Subject: Re: [Sip] SIPS question 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 Hi Arunachalam, If there are no record routing proxies in the path, your second "rule" may work just fine. However, I am not sure your first "rule" would work when there are record routing proxies. Like Hisham said, if UA2 has registered itself with P1 using SIPS-URI, P1 will contact UA2 using SIPS-URI. Now, UA2 MUST insert SIPS-URI in the Contact header, which again means that UA1 may end up in a situation where the Request-URI for the next request is SIPS-URI, and according to the spec it MUST now use TLS for that request - even if it doesn't support TLS, and even if it's not going to use the Request-URI to route the message in the first place. Now, changing the text in the spec MAY help: the change would be that the UAC does not make any transport based decissions based on the Request-URI, but on the URI it actually uses to route the request (which of course MAY be the Request-URI, but also the top Route). I also think part of the basic problem is the fact that the URI may change from SIP to SIPS in the signalling path. I don't think that is true for HTTP/HTTPS, is it? Thanks for your comments! Regards, Christer Holmberg Ericsson Finland Arunachalam Venkatraman wrote: > Christer > Interesting issue. > > How about this for a solution --- > The UAS sends a SIPS URI in its Contact only if one of the following is > true- > 1. The top Route in its Route Set is a SIPS URI > 2. If no Route set has been established, the Contact in the request is a > SIPS-URI. > > In all other cases, it sends a SIP-URI in its Contact. > > Will this work? > > Venkat > > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > Christer Holmberg > Sent: Thursday, October 31, 2002 6:43 AM > To: hisham.khartabil@nokia.com > Cc: jon.peterson@neustar.biz; sip@ietf.org > Subject: Re: [Sip] SIPS question > > Hi, > > > > > > Hi, > > > > > > > > > > > I guess UA2 should have registered with P1 using a sips-uri > > > > > in the contact-header. P1 doesn't care about the > > > > > contact-header sent in the 200 OK. UA2 contact-header is > > > > > telling UA1 (not P1) to contact it using TLS. > > > > > > > > > > No, but the Contact header value will be used in requests > > > > > during the session, as part of the route set or Request-URI > > > > > (depending on if loose routing is used etc) > > > > > > > > What I meant to say is that if UA2 had registered with P1 > > > using a sips-uri in the contact-header, then when P1 is > > > routing the INVITE, it will put sips-uri in the record-route > > > header since the request uri (retrieved from the registrar) > > > is a sips-uri. > > > > > > > Since P1 contacted UA2 using sips, the 200 ok must contain > > > a contact-header with sips-uri. > > > > > > Ok. So, in this case UA1 will receive a Record-Route with > > > SIPS-URI. So, the next time UA1 sends a request the SIPS-URI > > > indicates it shall use TLS - which UA1 may not even support. > > > > No, P1 will modify the record-route header in the response and will make > it a sip-uri. > > > >And, since UA1 used SIP-URI in its own Contact header, P1 > > >shall use UDP (or TCP) to forward requests received from UA2, > > >so now we would have the separate-transport-in-each-direction > > >problem between UA1 and P1, wouldn't we? > > > > UA1 will have a different route-set that UA2. > > True. > > However, EVEN if UA2 has registered itself with P1 using SIPS-URI, and P1 > uses TLS to > contact it, UA1 will still receive a Contact header with SIPS-URI, and > according to the > RFC ("if the Request-URI is SIPS-URI, TLS MUST be used") it would have to > use TLS for the > other requests, even if it doesn't support TLS, and even if the requests > aren't even sent > to UA2 (UA1 send them to P1, which record-routed). > > 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 > > _______________________________________________ > 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 Nov 1 01:20:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29729 for ; Fri, 1 Nov 2002 01:20:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA16MVS25539 for sip-archive@odin.ietf.org; Fri, 1 Nov 2002 01:22: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 gA16MDv25520; Fri, 1 Nov 2002 01:22: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 g9VH6dv13070 for ; Thu, 31 Oct 2002 12:06:39 -0500 Received: from ronda.convergentnet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01398 for ; Thu, 31 Oct 2002 12:04:11 -0500 (EST) Received: by RONDA with Internet Mail Service (5.5.2655.55) id ; Thu, 31 Oct 2002 11:51:50 -0500 Message-ID: From: "Zhang, Bo" To: "'sip@ietf.org'" Date: Thu, 31 Oct 2002 11:50:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] SIP MIB module ID conflicts 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, all, I got a SIP MIB draft 04 version from http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-mib-04.txt. I'm NOT sure if this is the latest. But in it, there is a conflict definition of Module ID. The sipTC and sipUAMIB both have module ID of { mib-2 9992 }. If this has already been fixed, could some one post the latest document? Thanks, Bo _______________________________________________ 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 Nov 1 03:42:44 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01224 for ; Fri, 1 Nov 2002 03:42:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA18imb08748 for sip-archive@odin.ietf.org; Fri, 1 Nov 2002 03:44: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 gA18i4v08715; Fri, 1 Nov 2002 03:44: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 gA18dwv08527 for ; Fri, 1 Nov 2002 03:39:58 -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 DAA01172 for ; Fri, 1 Nov 2002 03:37:22 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA18djKV020994; Fri, 1 Nov 2002 09:39:45 +0100 (MET) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.51]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id gA18djZb024920; Fri, 1 Nov 2002 10:39:45 +0200 (EET) Message-ID: <3DC23DD0.C8050AFA@lmf.ericsson.se> Date: Fri, 01 Nov 2002 10:39:44 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Janne Kario CC: sip@ietf.org Subject: Re: [Sip] (no subject) 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 Janne, Janne Kario wrote: > > A quick question. What is the relation between > > draft-ietf-sip-asserted-identity-02 This draft provides a short-term solution that works within trusted domains. > and > > draft-peterson-sip-identity-01 This one provides a long-term solution which is more general. Regards, 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 Fri Nov 1 04:45:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02216 for ; Fri, 1 Nov 2002 04:45:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA19los12743 for sip-archive@odin.ietf.org; Fri, 1 Nov 2002 04:47: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 gA19lDv12705; Fri, 1 Nov 2002 04:47: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 gA19i4v12559 for ; Fri, 1 Nov 2002 04:44:04 -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 EAA02148 for ; Fri, 1 Nov 2002 04:41:28 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA19hQO05244 for ; Fri, 1 Nov 2002 11:43:26 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 1 Nov 2002 11:43:51 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 1 Nov 2002 11:43:51 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 1 Nov 2002 11:43:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] SIPS question Date: Fri, 1 Nov 2002 11:43:40 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE6F64@esebe019.ntc.nokia.com> Thread-Topic: [Sip] SIPS question Thread-Index: AcKBb0/U7/S3DsYHTIG8BMHHqjWX4AAGoDnQ To: , Cc: X-OriginalArrivalTime: 01 Nov 2002 09:43:50.0992 (UTC) FILETIME=[2F11AD00:01C2818B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA19i4v12560 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 > -----Original Message----- > From: ext Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Friday, November 01, 2002 8:13 AM > To: Arunachalam Venkatraman > Cc: sip@ietf.org > Subject: Re: [Sip] SIPS question > > > > Hi Arunachalam, > > If there are no record routing proxies in the path, your > second "rule" may > work just fine. > > However, I am not sure your first "rule" would work when > there are record > routing proxies. Like Hisham said, if UA2 has registered > itself with P1 using > SIPS-URI, P1 will contact UA2 using SIPS-URI. Now, UA2 MUST > insert SIPS-URI in > the Contact header, which again means that UA1 may end up in > a situation where > the Request-URI for the next request is SIPS-URI, and > according to the spec it > MUST now use TLS for that request - even if it doesn't > support TLS, and even > if it's not going to use the Request-URI to route the message > in the first > place. Yes, the problem is in the sentence in section 8.1.2 "Independent of which URI is used as input to the procedures of [4], if the Request-URI specifies a SIPS resource, the UAC MUST follow the procedures of [4] as if the input URI were a SIPS URI." Why is that sentence there? The original problem remains, and that is what if UAS decides it wants to use TLS when it receives an INVITE, my answer remains the same: reject the INVITE, but with which response code? How does UAC know that the UAS rejected the INVITE because it wants it over TLS? /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 Fri Nov 1 06:21:50 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03613 for ; Fri, 1 Nov 2002 06:21:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1BNji17656 for sip-archive@odin.ietf.org; Fri, 1 Nov 2002 06:23: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 gA1BN5v17639; Fri, 1 Nov 2002 06:23: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 gA1BKPv17567 for ; Fri, 1 Nov 2002 06:20:25 -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 GAA03543 for ; Fri, 1 Nov 2002 06:17:59 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gA1BKMM13512 for ; Fri, 1 Nov 2002 06:20:23 -0500 (EST) Received: by en0060D057.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Nov 2002 11:20:22 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EB19@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Gonzalo Camarillo'" , Janne Kario Cc: sip@ietf.org Subject: RE: [Sip] (no subject) Date: Fri, 1 Nov 2002 11:20:14 -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: , Except that we agreed that we would no longer use the terms "short term" and "long term" in association with these. No one has ever suggested that we would obsolete one when the other is completed. Their relative status should be taken purely on the basis of the applicability statements, which Gonzalo has correctly summarized, and the fact that one used P-headers and the other normal headers (refer to sipchanges document for status of P-headers). Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: 01 November 2002 08:40 > To: Janne Kario > Cc: sip@ietf.org > Subject: Re: [Sip] (no subject) > > > Janne, > > Janne Kario wrote: > > > > A quick question. What is the relation between > > > > draft-ietf-sip-asserted-identity-02 > > This draft provides a short-term solution that works within trusted > domains. > > > and > > > > draft-peterson-sip-identity-01 > > This one provides a long-term solution which is more general. > > Regards, > > 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 > _______________________________________________ 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 Nov 1 07:24:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04606 for ; Fri, 1 Nov 2002 07:24:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1CQ4620561 for sip-archive@odin.ietf.org; Fri, 1 Nov 2002 07:26: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 gA1CPbv20541; Fri, 1 Nov 2002 07:25: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 gA1CN5v20471 for ; Fri, 1 Nov 2002 07:23:05 -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 HAA04590 for ; Fri, 1 Nov 2002 07:20:39 -0500 (EST) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gA1CNHvp006101; Fri, 1 Nov 2002 07:23:17 -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 AAN91079; Fri, 1 Nov 2002 07:23:00 -0500 (EST) Message-ID: <3DC27223.161DB1B0@cisco.com> Date: Fri, 01 Nov 2002 07:22:59 -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: "Zhang, Bo" CC: "'sip@ietf.org'" Subject: Re: [Sip] SIP MIB module ID conflicts 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 "Zhang, Bo" wrote: > > Hello, all, > > I got a SIP MIB draft 04 version from > > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-mib-04.txt. > > I'm NOT sure if this is the latest. But in it, there is a conflict > definition > of Module ID. The sipTC and sipUAMIB both have module ID of > { mib-2 9992 }. If this has already been fixed, could some one post > the latest document? bo, -04 is the latest published version of the doc. -05 is planned, but for several reasons has been slow coming. wrt the module id issues... those mib-2 oids are placeholders anyway. they are not official IANA assigned numbers, so the conflict is not a big issue. granted, they should be unique, but no one should be attempting to implement these mibs as "mib-2 " anyway. they are draft mibs at this point. i will make sure they have unique oids for the next revision though. btw, we expect -05 revision to be the last before we go to IESG for an rfc. -04 _was_ ready for that, but the coming of RFC 3261 caused us to pause (didn't expect to pause this long though;) and update the mib draft to be inline with the new sip rfc. thanks kevin > > Thanks, > > Bo > _______________________________________________ > 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 checkout: http://wwwin-eng.cisco.com/Eng/IOS/SNMP_WWW/mib-police/ Sometimes I think I understand everything, then I regain consciousness. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= _______________________________________________ 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 Nov 1 08:26:56 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05749 for ; Fri, 1 Nov 2002 08:26:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1DSrJ23650 for sip-archive@odin.ietf.org; Fri, 1 Nov 2002 08:28: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 gA1DSNv23637; Fri, 1 Nov 2002 08:28: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 gA1DQev23582 for ; Fri, 1 Nov 2002 08:26:40 -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 IAA05731 for ; Fri, 1 Nov 2002 08:24:06 -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 gA1DRSs00529 for ; Fri, 1 Nov 2002 15:27:28 +0200 (EET) Received: from ifaistos.intranet.gr (ifaistos.intranet.GR [146.124.20.203]) by mailserv.intranet.gr (8.11.3/8.11.3) with ESMTP id gA1DRM300479 for ; Fri, 1 Nov 2002 15:27:22 +0200 (EET) Received: from intracom.gr (pcrnd105 [146.124.20.189]) by ifaistos.intranet.gr (8.9.1b+Sun/8.9.1) with ESMTP id PAA04475 for ; Fri, 1 Nov 2002 15:23:18 +0200 (EET) Message-ID: <3DC28041.2030606@intracom.gr> Date: Fri, 01 Nov 2002 15:23:13 +0200 From: Paraskevopoulos Pavlos Organization: INTRACOM User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: el, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] INVITE without SDP body. 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 'm trying to build a SIP gateway, and I would appreciate a little help. Think of that scenario ISDN GW SIP-EP ---------------------------------------------------------------- -->SETUP --->INVITE(no SDP) ALERTING<--- 180<----- CONNECT<--- 200<----- ---->ACK(SDP) I want to send the INVITE request without SDP info. The SDP info will come later with the ACK. Does the INVITE request have to contain a Required or Supported header with option tag 100rel? Thanks in advance. _______________________________________________ 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 Nov 1 08:43:49 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06538 for ; Fri, 1 Nov 2002 08:43:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1DjjF24714 for sip-archive@odin.ietf.org; Fri, 1 Nov 2002 08:45: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 gA1DjKv24684; Fri, 1 Nov 2002 08:45: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 gA1Divv24647 for ; Fri, 1 Nov 2002 08:44:57 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06251; Fri, 1 Nov 2002 08:42:30 -0500 (EST) Message-Id: <200211011342.IAA06251@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, 01 Nov 2002 08:42:29 -0500 Subject: [Sip] I-D ACTION:draft-jennings-sip-app-info-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 : SIP Support for Application Initiation Author(s) : C. Jennings Filename : draft-jennings-sip-app-info-00.txt Pages : 10 Date : 2002-10-31 This document describes SIP extensions to allow network elements to request a UA to initiate a scripted application that is associated with a dialog. It provides a mechanism for the network elements to find out a UA's ability to fetch and execute scripts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jennings-sip-app-info-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-jennings-sip-app-info-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-jennings-sip-app-info-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-31150258.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-jennings-sip-app-info-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-jennings-sip-app-info-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-31150258.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 Nov 1 08:45:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06739 for ; Fri, 1 Nov 2002 08:45:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1DlMN24989 for sip-archive@odin.ietf.org; Fri, 1 Nov 2002 08:47:22 -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 gA1Dl6v24916; Fri, 1 Nov 2002 08:47: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 gA1DkLv24788 for ; Fri, 1 Nov 2002 08:46:21 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06572; Fri, 1 Nov 2002 08:43:53 -0500 (EST) Message-Id: <200211011343.IAA06572@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, 01 Nov 2002 08:43:53 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-authid-body-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 : SIP Authenticated Identity Body (AIB) Format Author(s) : J. Peterson Filename : draft-ietf-sip-authid-body-00.txt Pages : 10 Date : 2002-10-31 RFC3261 introduces the concept of adding an S/MIME body to a SIP request or response in order to provide reference integrity over its headers. This document provides a more specific mechanism to derive integrity and authentication properties from an 'authenticated identity body', a digitally-signed SIP message or message fragment. A standard format for such bodies (known as Authenticated Identity Bodies, or AIBs) is given in this document. Some considerations for the processing of AIBs by recipients of SIP messages with such bodies are also given. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-authid-body-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-authid-body-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-authid-body-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: <2002-10-31150559.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-authid-body-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-authid-body-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-31150559.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 Nov 1 08:48:40 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06816 for ; Fri, 1 Nov 2002 08:48:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1DobW25166 for sip-archive@odin.ietf.org; Fri, 1 Nov 2002 08:50:37 -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 gA1DoKv25134; Fri, 1 Nov 2002 08:50: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 gA1DkHv24756 for ; Fri, 1 Nov 2002 08:46:17 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06550; Fri, 1 Nov 2002 08:43:49 -0500 (EST) Message-Id: <200211011343.IAA06550@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, 01 Nov 2002 08:43:49 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-identity-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 : Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) Author(s) : J. Peterson Filename : draft-ietf-sip-identity-00.txt Pages : 15 Date : 2002-10-31 The existing mechanisms for expressing identity in the Session Initiation Protocol oftentimes do not permit an administrative domain to verify securely the identity of the originator of a request. This document recommends practices and conventions for authenticating end users, and proposes a way to distribute cryptographically secure authenticated identities within SIP messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-identity-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-identity-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-identity-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: <2002-10-31150549.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-identity-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-identity-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-31150549.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 Nov 1 08:48:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06829 for ; Fri, 1 Nov 2002 08:48:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1DocB25178 for sip-archive@odin.ietf.org; Fri, 1 Nov 2002 08:50: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 gA1DoGv25114; Fri, 1 Nov 2002 08:50: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 gA1Dkav24828 for ; Fri, 1 Nov 2002 08:46:36 -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 IAA06595 for ; Fri, 1 Nov 2002 08:44:08 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA1DkXKV011888; Fri, 1 Nov 2002 14:46:33 +0100 (MET) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.112]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id gA1DkXZb014724; Fri, 1 Nov 2002 15:46:33 +0200 (EET) Message-ID: <3DC285B6.FE7A10AE@lmf.ericsson.se> Date: Fri, 01 Nov 2002 15:46:30 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Paraskevopoulos Pavlos CC: sip@ietf.org Subject: Re: [Sip] INVITE without SDP body. References: <3DC28041.2030606@intracom.gr> 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, 100rel is needed only if you want to use PRACK. It has nothing to do with the fact if you have a SDP in the INVITE or not. Note, however, that if you use PRACK you may have to send the SDP before you send the ACK (in a PRACK), but that's another issue... Regards, Christer Holmberg Ericsson Finland Paraskevopoulos Pavlos wrote: > Hello, > > I 'm trying to build a SIP gateway, and I would appreciate a little help. > > Think of that scenario > > ISDN GW SIP-EP > ---------------------------------------------------------------- > -->SETUP --->INVITE(no SDP) > > ALERTING<--- 180<----- > CONNECT<--- 200<----- > ---->ACK(SDP) > > > I want to send the INVITE request without SDP info. The SDP info will > come later with the ACK. > Does the INVITE request have to contain a Required or Supported header > with option tag 100rel? > > Thanks in advance. > > _______________________________________________ > 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 Nov 1 09:34:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11504 for ; Fri, 1 Nov 2002 09:34:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1Eaac09349 for sip-archive@odin.ietf.org; Fri, 1 Nov 2002 09:36: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 gA1EZvv09261; Fri, 1 Nov 2002 09:35: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 gA1EXev08934 for ; Fri, 1 Nov 2002 09:33:40 -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 JAA11197 for ; Fri, 1 Nov 2002 09:31:13 -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 gA1EYjs23498 for ; Fri, 1 Nov 2002 16:34:45 +0200 (EET) Received: from ifaistos.intranet.gr (ifaistos.intranet.GR [146.124.20.203]) by mailserv.intranet.gr (8.11.3/8.11.3) with ESMTP id gA1EYi323490; Fri, 1 Nov 2002 16:34:44 +0200 (EET) Received: from intracom.gr (pcrnd105 [146.124.20.189]) by ifaistos.intranet.gr (8.9.1b+Sun/8.9.1) with ESMTP id QAA07628; Fri, 1 Nov 2002 16:30:37 +0200 (EET) Message-ID: <3DC29008.7060202@intracom.gr> Date: Fri, 01 Nov 2002 16:30:32 +0200 From: Paraskevopoulos Pavlos Organization: INTRACOM User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: el, en MIME-Version: 1.0 To: Christer Holmberg , sip@ietf.org Subject: Re: [Sip] INVITE without SDP body. References: <3DC28041.2030606@intracom.gr> <3DC285B6.FE7A10AE@lmf.ericsson.se> Content-Type: multipart/alternative; boundary="------------050702070109030903050200" 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: , --------------050702070109030903050200 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thanks for your response. I agree but I 'm a bit confused because in the draft-elwell-sippping-qsig2sip-03.txt (Interworking between SIP and QSIG), it is mentioned : If the SIP INVITE request does not contain SDP information and does not contain either a Required header or a Supported header with option tag 100rel, the gateway SHALL NOT issue a QSIG SETUP message and SHALL send a SIP 488 (NOT ACCEPTABLE HERE) response. What did I understand wrong? Thanks again. Christer Holmberg wrote: >Hi, > >100rel is needed only if you want to use PRACK. It has nothing to do with the >fact if you have a SDP in the INVITE or not. > >Note, however, that if you use PRACK you may have to send the SDP before you >send the ACK (in a PRACK), but that's another issue... > >Regards, > >Christer Holmberg >Ericsson Finland > > >Paraskevopoulos Pavlos wrote: > > > >>Hello, >> >>I 'm trying to build a SIP gateway, and I would appreciate a little help. >> >>Think of that scenario >> >>ISDN GW SIP-EP >>---------------------------------------------------------------- >>-->SETUP --->INVITE(no SDP) >> >> ALERTING<--- 180<----- >> CONNECT<--- 200<----- >> ---->ACK(SDP) >> >> >>I want to send the INVITE request without SDP info. The SDP info will >>come later with the ACK. >>Does the INVITE request have to contain a Required or Supported header >>with option tag 100rel? >> >>Thanks in advance. >> >>_______________________________________________ >>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 >> >> > > > > > --------------050702070109030903050200 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks for your response.
I agree but I 'm a bit confused because in the
draft-elwell-sippping-qsig2sip-03.txt (Interworking between SIP and QSIG),  
it is mentioned :

    If the SIP INVITE request does not contain SDP information and does not contain
    either a Required header or a Supported header with option tag 100rel, the gateway
    SHALL NOT issue a QSIG SETUP message and SHALL send a SIP 488 (NOT ACCEPTABLE HERE) response.

What did I understand wrong?

Thanks again.


Christer Holmberg wrote:
Hi,

100rel is needed only if you want to use PRACK. It has nothing to do with the
fact if you have a SDP in the INVITE or not.

Note, however, that if you use PRACK you may have to send the SDP before you
send the ACK (in a PRACK), but that's another issue...

Regards,

Christer Holmberg
Ericsson Finland


Paraskevopoulos Pavlos wrote:

  
Hello,

I 'm trying to build a SIP gateway, and I would appreciate a little help.

Think of that scenario

ISDN                     GW                         SIP-EP
----------------------------------------------------------------
-->SETUP                 --->INVITE(no SDP)

             ALERTING<---                      180<-----
             CONNECT<---                       200<-----
                        ---->ACK(SDP)


I want to send the INVITE request without SDP info. The SDP info will
come later with the ACK.
Does the INVITE request have to contain a Required or Supported header
with option tag 100rel?

Thanks in advance.

_______________________________________________
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

--------------050702070109030903050200-- _______________________________________________ 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 Nov 1 11:02:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18909 for ; Fri, 1 Nov 2002 11:02:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1G4MZ07566 for sip-archive@odin.ietf.org; Fri, 1 Nov 2002 11:04:22 -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 gA1G3Uv06795; Fri, 1 Nov 2002 11:03: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 gA1G2Yv06696 for ; Fri, 1 Nov 2002 11:02:34 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18702 for ; Fri, 1 Nov 2002 11:00:06 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gA1G2Ed15957; Fri, 1 Nov 2002 11:02:14 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Nov 2002 11:02:15 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400DE93@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Paraskevopoulos Pavlos'" , Christer Holmberg , sip@ietf.org Subject: RE: [Sip] INVITE without SDP body. Date: Fri, 1 Nov 2002 11:02:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C281C0.0A73514E" 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_01C281C0.0A73514E Content-Type: text/plain The problem is not with SDP, it's with the use of encapsulated protocol content. Without 100rel the UAS can't reliably deliver such content beforew the final response. This affects encapsulated ISUP too. -----Original Message----- From: Paraskevopoulos Pavlos [mailto:ppar@intracom.gr] Sent: Friday, November 01, 2002 9:31 AM To: Christer Holmberg; sip@ietf.org Subject: Re: [Sip] INVITE without SDP body. Thanks for your response. I agree but I 'm a bit confused because in the draft-elwell-sippping-qsig2sip-03.txt (Interworking between SIP and QSIG), it is mentioned : If the SIP INVITE request does not contain SDP information and does not contain either a Required header or a Supported header with option tag 100rel, the gateway SHALL NOT issue a QSIG SETUP message and SHALL send a SIP 488 (NOT ACCEPTABLE HERE) response. What did I understand wrong? Thanks again. Christer Holmberg wrote: Hi, 100rel is needed only if you want to use PRACK. It has nothing to do with the fact if you have a SDP in the INVITE or not. Note, however, that if you use PRACK you may have to send the SDP before you send the ACK (in a PRACK), but that's another issue... Regards, Christer Holmberg Ericsson Finland Paraskevopoulos Pavlos wrote: Hello, I 'm trying to build a SIP gateway, and I would appreciate a little help. Think of that scenario ISDN GW SIP-EP ---------------------------------------------------------------- -->SETUP --->INVITE(no SDP) ALERTING<--- 180<----- CONNECT<--- 200<----- ---->ACK(SDP) I want to send the INVITE request without SDP info. The SDP info will come later with the ACK. Does the INVITE request have to contain a Required or Supported header with option tag 100rel? Thanks in advance. _______________________________________________ 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_01C281C0.0A73514E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sip] INVITE without SDP body.

The problem is not with SDP, it's with the use of = encapsulated protocol content.  Without 100rel the UAS can't = reliably deliver such content beforew the final response.  This = affects encapsulated ISUP too.

 
-----Original Message-----
From: Paraskevopoulos Pavlos [mailto:ppar@intracom.gr]
Sent: Friday, November 01, 2002 9:31 AM
To: Christer Holmberg; sip@ietf.org
Subject: Re: [Sip] INVITE without SDP body.


Thanks for your response.
I agree but I 'm a bit confused because in the =
draft-elwell-sippping-qsig2sip-03.txt (Interworking = between SIP and QSIG), 
it is mentioned :

    If the SIP INVITE request does not = contain SDP information and does not contain
    either a Required header or a = Supported header with option tag 100rel, the gateway
    SHALL NOT issue a QSIG SETUP = message and SHALL send a SIP 488 (NOT ACCEPTABLE HERE) response.

What did I understand wrong?

Thanks again.


Christer Holmberg wrote:

Hi,

100rel is needed only if you want to use PRACK. It = has nothing to do with the
fact if you have a SDP in the INVITE or not.

Note, however, that if you use PRACK you may have to = send the SDP before you
send the ACK (in a PRACK), but that's another = issue...

Regards,

Christer Holmberg
Ericsson Finland


Paraskevopoulos Pavlos wrote:

  Hello,

I 'm trying to build a SIP gateway, and I would = appreciate a little help.

Think of that scenario

ISDN          = ;           = GW           &nbs= p;           &nbs= p; SIP-EP
---------------------------------------------------------------= -
-->SETUP        &nbs= p;        --->INVITE(no = SDP)

          &nb= sp;  = ALERTING<---         &nb= sp;            = 180<-----
          &nb= sp;  = CONNECT<---         &nbs= p;           &nbs= p; 200<-----
          &nb= sp;           &nb= sp; ---->ACK(SDP)


I want to send the INVITE request without SDP info. = The SDP info will
come later with the ACK.
Does the INVITE request have to contain a Required = or Supported header
with option tag 100rel?

Thanks in advance.

_______________________________________________
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_01C281C0.0A73514E-- _______________________________________________ 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 Nov 1 11:56:13 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22327 for ; Fri, 1 Nov 2002 11:56:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1GwA127329 for sip-archive@odin.ietf.org; Fri, 1 Nov 2002 11:58: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 gA1GrRv26543; Fri, 1 Nov 2002 11:53: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 gA1Gr0v26363 for ; Fri, 1 Nov 2002 11:53: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 LAA21876 for ; Fri, 1 Nov 2002 11:50:31 -0500 (EST) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gA1Gqtot009939 for ; Fri, 1 Nov 2002 08:52:55 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABF75954; Fri, 1 Nov 2002 08:50:28 -0800 (PST) Date: Fri, 1 Nov 2002 08:53:34 -0800 Mime-Version: 1.0 (Apple Message framework v546) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Rohan Mahy To: sip@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <75C8D55B-EDBA-11D6-98BC-0003938AF740@cisco.com> X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Subject: [Sip] WGLC on draft-ietf-sip-compression-02.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: 7bit Hi, I'd like to start an abbreviated WGLC on draft-ietf-sip-compression-02.txt. Until it appears in the archive, please access it here: http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-compression-02.txt This draft has one known open issue which is being discussed on the list now (whether the ~8k static SIP dictionary is mandatory or optional). As the draft is short and seems uncontroversial, WGLC will close on Nov 12. Please note that WGLC will probably overlap significantly with IETF LC for this draft. thanks, -rohan _______________________________________________ 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 Nov 1 12:03:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22731 for ; Fri, 1 Nov 2002 12:03:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1H55l28902 for sip-archive@odin.ietf.org; Fri, 1 Nov 2002 12: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 gA1H3mv28457; Fri, 1 Nov 2002 12:03: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 gA1H1ov28054 for ; Fri, 1 Nov 2002 12:01:50 -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 LAA22487 for ; Fri, 1 Nov 2002 11:59:19 -0500 (EST) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gA1H1cPP010000; Fri, 1 Nov 2002 09:01:38 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABF76066; Fri, 1 Nov 2002 08:59:11 -0800 (PST) Date: Fri, 1 Nov 2002 09:02:18 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "'Dean Willis'" , jon.peterson@neustar.biz, Allison Mankin To: sip@ietf.org From: Rohan Mahy Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Subject: [Sip] WGLC (redux) for draft-ietf-sip-sec-agree-05.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: 7bit Hi Folks, Based on the substantial changes made to sec-agree in response to IESG review, we are asking the WG to officially review the new version. Until it appears in the archive, it is available at: http://standards.ericsson.net/sip/drafts/draft-ietf-sip-sec-agree-05.txt WGLC will end on Nov 8. thanks, -rohan _______________________________________________ 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 Nov 1 12:14:44 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23248 for ; Fri, 1 Nov 2002 12:14:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1HGge00421 for sip-archive@odin.ietf.org; Fri, 1 Nov 2002 12:16: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 gA1HCCv31719; Fri, 1 Nov 2002 12:12: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 gA1HBTv31679 for ; Fri, 1 Nov 2002 12:11:29 -0500 Received: from oak.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23049 for ; Fri, 1 Nov 2002 12:09:00 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id gA1HB5b16407; Fri, 1 Nov 2002 17:11:05 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Nov 2002 12:11:44 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB356@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Christer Holmberg'" , Arunachalam Venkatraman Cc: sip@ietf.org Subject: RE: [Sip] SIPS question Date: Fri, 1 Nov 2002 12:11: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: , I think the problem with much of the language that has been cited from RFC3261 in this thread is that we expected SIPS to be strict-routed. I don't think any of these problems with intermediaries and retargeting arise if strict routing is used. Unfortunately, both loose routing and SIPS arose relatively late in the game for RFC3261, and we may not have fully studied their interaction. A few other notes about this thread: While I agree that HTTP R-U's cannot be retargeted to HTTPS, I think retargeting SIP to SIPS is attractive and workable, provided strict routing is used (or language is introduced to bring SIPS into parity with loose routing). It is desirable to be able to secure as much of the communications path as possible. The recipient of a request should be able to ascertain whether or not the request was retargeted to SIPS by checking to see if the To header field uses the SIPS scheme. Finally, when we were working on the design of SIPS, we noted that there were a class of problems that resulted from specifying transport=tls (or any optional transport, including =tcp and =sctp) in Contact/Record-Route header fields. Hence there is language in bis that says things like: The [Record-Route] URI SHOULD NOT contain the transport parameter unless the proxy has knowledge (such as in a private network) that the next downstream element that will be in the path of subsequent requests supports that transport. Similar language should probably be introduced for SIPS, and the Contact header. Anyway, for the time being, I suspect that the simplest bug fix is to say that whenever a route set or remote target for a dialog contains a SIPS URI, requests must be strict routed. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Thursday, October 31, 2002 10:13 PM > To: Arunachalam Venkatraman > Cc: sip@ietf.org > Subject: Re: [Sip] SIPS question > > > > Hi Arunachalam, > > If there are no record routing proxies in the path, your > second "rule" may > work just fine. > > However, I am not sure your first "rule" would work when > there are record > routing proxies. Like Hisham said, if UA2 has registered > itself with P1 using > SIPS-URI, P1 will contact UA2 using SIPS-URI. Now, UA2 MUST > insert SIPS-URI in > the Contact header, which again means that UA1 may end up in > a situation where > the Request-URI for the next request is SIPS-URI, and > according to the spec it > MUST now use TLS for that request - even if it doesn't > support TLS, and even > if it's not going to use the Request-URI to route the message > in the first > place. > > Now, changing the text in the spec MAY help: the change would > be that the UAC > does not make any transport based decissions based on the > Request-URI, but on > the URI it actually uses to route the request (which of > course MAY be the > Request-URI, but also the top Route). > > I also think part of the basic problem is the fact that the > URI may change > from SIP to SIPS in the signalling path. I don't think that > is true for > HTTP/HTTPS, is it? > > Thanks for your comments! > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > Arunachalam Venkatraman wrote: > > > Christer > > Interesting issue. > > > > How about this for a solution --- > > The UAS sends a SIPS URI in its Contact only if one of the > following is > > true- > > 1. The top Route in its Route Set is a SIPS URI > > 2. If no Route set has been established, the Contact in the > request is a > > SIPS-URI. > > > > In all other cases, it sends a SIP-URI in its Contact. > > > > Will this work? > > > > Venkat > > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > > Christer Holmberg > > Sent: Thursday, October 31, 2002 6:43 AM > > To: hisham.khartabil@nokia.com > > Cc: jon.peterson@neustar.biz; sip@ietf.org > > Subject: Re: [Sip] SIPS question > > > > Hi, > > > > > > > > Hi, > > > > > > > > > > > > > I guess UA2 should have registered with P1 using > a sips-uri > > > > > > in the contact-header. P1 doesn't care about the > > > > > > contact-header sent in the 200 OK. UA2 contact-header is > > > > > > telling UA1 (not P1) to contact it using TLS. > > > > > > > > > > > > No, but the Contact header value will be used in requests > > > > > > during the session, as part of the route set or Request-URI > > > > > > (depending on if loose routing is used etc) > > > > > > > > > > What I meant to say is that if UA2 had registered with P1 > > > > using a sips-uri in the contact-header, then when P1 is > > > > routing the INVITE, it will put sips-uri in the record-route > > > > header since the request uri (retrieved from the registrar) > > > > is a sips-uri. > > > > > > > > > Since P1 contacted UA2 using sips, the 200 ok must contain > > > > a contact-header with sips-uri. > > > > > > > > Ok. So, in this case UA1 will receive a Record-Route with > > > > SIPS-URI. So, the next time UA1 sends a request the SIPS-URI > > > > indicates it shall use TLS - which UA1 may not even support. > > > > > > No, P1 will modify the record-route header in the > response and will make > > it a sip-uri. > > > > > >And, since UA1 used SIP-URI in its own Contact header, P1 > > > >shall use UDP (or TCP) to forward requests received from UA2, > > > >so now we would have the separate-transport-in-each-direction > > > >problem between UA1 and P1, wouldn't we? > > > > > > UA1 will have a different route-set that UA2. > > > > True. > > > > However, EVEN if UA2 has registered itself with P1 using > SIPS-URI, and P1 > > uses TLS to > > contact it, UA1 will still receive a Contact header with > SIPS-URI, and > > according to the > > RFC ("if the Request-URI is SIPS-URI, TLS MUST be used") it > would have to > > use TLS for the > > other requests, even if it doesn't support TLS, and even if > the requests > > aren't even sent > > to UA2 (UA1 send them to P1, which record-routed). > > > > 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 > > > > _______________________________________________ > > 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 Nov 1 12:16:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23324 for ; Fri, 1 Nov 2002 12:16:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1HIjB00661 for sip-archive@odin.ietf.org; Fri, 1 Nov 2002 12:18: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 gA1HHEv00455; Fri, 1 Nov 2002 12:17: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 gA1HGrv00437 for ; Fri, 1 Nov 2002 12:16:53 -0500 Received: from oak.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23235 for ; Fri, 1 Nov 2002 12:14:24 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id gA1HGnb16628; Fri, 1 Nov 2002 17:16:49 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Nov 2002 12:17:27 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB358@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Janne Kario'" , sip@ietf.org Subject: RE: [Sip] (no subject) Date: Fri, 1 Nov 2002 12:17:25 -0500 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 gA1HGrv00438 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 Yes, they have overlapping functions, but their implementation strategies reflect two different sets of requirements for identity management in SIP. The asserted-identity-02 assumes a 'walled-garden' hop-by-hop network of trusted proxy servers (see the sipping-nai-reqs-02 document for more details). draft-ietf-sip-identity-00 (which has superseded the 'draft-peterson' document below) attempts to find an end-to-end cryptographic identity solution. For various reasons, the 'walled garden' approach to identity was not considered suitable for widespread Internet deployment; hence its reliance on P- headers and so on. In fact, there is now some text at the beginning of sip-identity-00 that briefly discusses the differences between its approach and the approach in asserted-identity-02. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Janne Kario [mailto:jkario78@hotmail.com] > Sent: Thursday, October 31, 2002 1:25 PM > To: sip@ietf.org > Subject: [Sip] (no subject) > > > A quick question. What is the relation between > > draft-ietf-sip-asserted-identity-02 > > and > > draft-peterson-sip-identity-01 > > It seems to me that they have some overlapping functions. > > _________________________________________________________________ > Surf the Web without missing calls! Get MSN Broadband. > http://resourcecenter.msn.com/access/plans/freeactivation.asp > > _______________________________________________ > 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 Nov 1 12:46:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25142 for ; Fri, 1 Nov 2002 12:46:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1Hm8N11088 for sip-archive@odin.ietf.org; Fri, 1 Nov 2002 12:48: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 gA1Hkav10569; Fri, 1 Nov 2002 12:46: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 gA1HjUv10521 for ; Fri, 1 Nov 2002 12:45:30 -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 MAA25019 for ; Fri, 1 Nov 2002 12:43:00 -0500 (EST) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gA1HjPPP007196; Fri, 1 Nov 2002 09:45:25 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABF76838; Fri, 1 Nov 2002 09:42:58 -0800 (PST) Date: Fri, 1 Nov 2002 09:46:05 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "'Dean Willis'" , jon.peterson@neustar.biz, Allison Mankin , rohan@cisco.com To: sip@ietf.org From: Rohan Mahy Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Subject: [Sip] WGLC (official) for scvrtdisco 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 Folks, According to my records, we did an expert review for scvrtdisco which closed on May 22, but never did an official WGLC. Let's do an official abbreviated WGLC for this document ending on Nov 8. The document is available at until it appears in the archive: http://www.softarmor.com/sipwg/drafts/draft-willis-sip-scvrtdisco-06.txt thanks, -rohan _______________________________________________ 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 Nov 1 15:16:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02603 for ; Fri, 1 Nov 2002 15:16:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1KIJv01233 for sip-archive@odin.ietf.org; Fri, 1 Nov 2002 15:18:19 -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 gA1KHev01182; Fri, 1 Nov 2002 15:17:40 -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 gA1KGbv01140 for ; Fri, 1 Nov 2002 15:16:37 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02561; Fri, 1 Nov 2002 15:14:06 -0500 (EST) Message-Id: <200211012014.PAA02561@ietf.org> To: IETF-Announce: ; Cc: sip@ietf.org From: The IESG Reply-to: iesg@ietf.org Date: Fri, 01 Nov 2002 15:14:06 -0500 Subject: [Sip] Last Call: Session Initiation Protocol Extension Header Field for Service Route Discovery During Registration to Proposed Standard 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: , The IESG has received a request from the Session Initiation Protocol Working Group to consider Session Initiation Protocol Extension Header Field for Service Route Discovery During Registration as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2002-11-15. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-scvrtdisco-01.txt _______________________________________________ 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 Nov 1 15:51:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03825 for ; Fri, 1 Nov 2002 15:51:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1Kr0E03158 for sip-archive@odin.ietf.org; Fri, 1 Nov 2002 15:53: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 gA1Kqcv03123; Fri, 1 Nov 2002 15:52: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 gA1KpTv03062 for ; Fri, 1 Nov 2002 15:51:29 -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 PAA03705 for ; Fri, 1 Nov 2002 15:48:59 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gA1KoKpR027327; Fri, 1 Nov 2002 15:50:20 -0500 (EST) Received: from dynamicsoft.com (NJ-AKRISTENSEN.dynamicsoft.com [63.113.46.43]) by DYN-EXCH-001.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VBC4QRTV; Fri, 1 Nov 2002 15:51:16 -0500 Message-ID: <3DC2E944.8070102@dynamicsoft.com> Date: Fri, 01 Nov 2002 15:51:16 -0500 From: Anders Kristensen 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: "Peterson, Jon" CC: "'Christer Holmberg'" , Arunachalam Venkatraman , sip@ietf.org Subject: Re: [Sip] SIPS question References: <15A2739B7DAA624D8091C65981D7DA815EB356@stntexch2.va.neustar.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 Wouldn't it be unfortunate if we were to downgrade an otherwise all-loose routing signaling path to strict routing because of the situation discussed here. I agree with Christer that the problem lies with the text of section 26.2.2 which requires that the UAC use TLS even though it's not routing the request based on the R-URI but to the top Route. It seems that 26.2.2 didn't anticipate that 1) the scheme of the R-URI of a subequent request can be sips even though it was sip for the original request, and 2) initial requests with a sips R-URI but a preloaded Route whose top URI is a sip URI. This last case could be common, for example, in cases where a service route has a sip URI top entry. Is there a problem in clarifying section 26.2.2 to say that request is sent using a transport of the top Route if there is one, or else to the R-URI? It seems more natural to use the properties of the next-hop URI that the request is in fact being sent to. It is clearly also the case, as Jon points out, that the UAS should be at least discouraged from using a sips Contact when the top R-R isn't sips (or it somehow *knows* that that proxy does in fact support sips). If the original request has a Record-Route header, I don't think it should matter whether or not the UAC happens to support sips or not - as long as the upstream record-routing proxy does, that should be enough, no? Anders Peterson, Jon wrote: > I think the problem with much of the language that has been cited from > RFC3261 in this thread is that we expected SIPS to be strict-routed. I don't > think any of these problems with intermediaries and retargeting arise if > strict routing is used. Unfortunately, both loose routing and SIPS arose > relatively late in the game for RFC3261, and we may not have fully studied > their interaction. > > A few other notes about this thread: > > While I agree that HTTP R-U's cannot be retargeted to HTTPS, I think > retargeting SIP to SIPS is attractive and workable, provided strict routing > is used (or language is introduced to bring SIPS into parity with loose > routing). It is desirable to be able to secure as much of the communications > path as possible. > > The recipient of a request should be able to ascertain whether or not the > request was retargeted to SIPS by checking to see if the To header field > uses the SIPS scheme. > > Finally, when we were working on the design of SIPS, we noted that there > were a class of problems that resulted from specifying transport=tls (or any > optional transport, including =tcp and =sctp) in Contact/Record-Route header > fields. Hence there is language in bis that says things like: > > The [Record-Route] URI SHOULD NOT > contain the transport parameter unless the proxy has knowledge > (such as in a private network) that the next downstream element > that will be in the path of subsequent requests supports that > transport. > > Similar language should probably be introduced for SIPS, and the Contact > header. > > Anyway, for the time being, I suspect that the simplest bug fix is to say > that whenever a route set or remote target for a dialog contains a SIPS URI, > requests must be strict routed. > > Jon Peterson > NeuStar, Inc. > > >>-----Original Message----- >>From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] >>Sent: Thursday, October 31, 2002 10:13 PM >>To: Arunachalam Venkatraman >>Cc: sip@ietf.org >>Subject: Re: [Sip] SIPS question >> >> >> >>Hi Arunachalam, >> >>If there are no record routing proxies in the path, your >>second "rule" may >>work just fine. >> >>However, I am not sure your first "rule" would work when >>there are record >>routing proxies. Like Hisham said, if UA2 has registered >>itself with P1 using >>SIPS-URI, P1 will contact UA2 using SIPS-URI. Now, UA2 MUST >>insert SIPS-URI in >>the Contact header, which again means that UA1 may end up in >>a situation where >>the Request-URI for the next request is SIPS-URI, and >>according to the spec it >>MUST now use TLS for that request - even if it doesn't >>support TLS, and even >>if it's not going to use the Request-URI to route the message >>in the first >>place. >> >>Now, changing the text in the spec MAY help: the change would >>be that the UAC >>does not make any transport based decissions based on the >>Request-URI, but on >>the URI it actually uses to route the request (which of >>course MAY be the >>Request-URI, but also the top Route). >> >>I also think part of the basic problem is the fact that the >>URI may change >>from SIP to SIPS in the signalling path. I don't think that >>is true for >>HTTP/HTTPS, is it? >> >>Thanks for your comments! >> >>Regards, >> >>Christer Holmberg >>Ericsson Finland >> >> >> >> >>Arunachalam Venkatraman wrote: >> >> >>>Christer >>>Interesting issue. >>> >>>How about this for a solution --- >>>The UAS sends a SIPS URI in its Contact only if one of the >> >>following is >> >>>true- >>>1. The top Route in its Route Set is a SIPS URI >>>2. If no Route set has been established, the Contact in the >> >>request is a >> >>>SIPS-URI. >>> >>>In all other cases, it sends a SIP-URI in its Contact. >>> >>>Will this work? >>> >>>Venkat >>> >>>-----Original Message----- >>>From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of >>>Christer Holmberg >>>Sent: Thursday, October 31, 2002 6:43 AM >>>To: hisham.khartabil@nokia.com >>>Cc: jon.peterson@neustar.biz; sip@ietf.org >>>Subject: Re: [Sip] SIPS question >>> >>>Hi, >>> >>> >>>>>>>Hi, >>>>>>> >>>>>>> >>>>>>>>I guess UA2 should have registered with P1 using >>>>>>> >>a sips-uri >> >>>>>>>in the contact-header. P1 doesn't care about the >>>>>>>contact-header sent in the 200 OK. UA2 contact-header is >>>>>>>telling UA1 (not P1) to contact it using TLS. >>>>>>> >>>>>>>No, but the Contact header value will be used in requests >>>>>>>during the session, as part of the route set or Request-URI >>>>>>>(depending on if loose routing is used etc) >>>>>> >>>>>>What I meant to say is that if UA2 had registered with P1 >>>>> >>>>>using a sips-uri in the contact-header, then when P1 is >>>>>routing the INVITE, it will put sips-uri in the record-route >>>>>header since the request uri (retrieved from the registrar) >>>>>is a sips-uri. >>>>> >>>>> >>>>>>Since P1 contacted UA2 using sips, the 200 ok must contain >>>>> >>>>>a contact-header with sips-uri. >>>>> >>>>>Ok. So, in this case UA1 will receive a Record-Route with >>>>>SIPS-URI. So, the next time UA1 sends a request the SIPS-URI >>>>>indicates it shall use TLS - which UA1 may not even support. >>>> >>>>No, P1 will modify the record-route header in the >>> >>response and will make >> >>>it a sip-uri. >>> >>> >>>>>And, since UA1 used SIP-URI in its own Contact header, P1 >>>>>shall use UDP (or TCP) to forward requests received from UA2, >>>>>so now we would have the separate-transport-in-each-direction >>>>>problem between UA1 and P1, wouldn't we? >>>> >>>>UA1 will have a different route-set that UA2. >>> >>>True. >>> >>>However, EVEN if UA2 has registered itself with P1 using >> >>SIPS-URI, and P1 >> >>>uses TLS to >>>contact it, UA1 will still receive a Contact header with >> >>SIPS-URI, and >> >>>according to the >>>RFC ("if the Request-URI is SIPS-URI, TLS MUST be used") it >> >>would have to >> >>>use TLS for the >>>other requests, even if it doesn't support TLS, and even if >> >>the requests >> >>>aren't even sent >>>to UA2 (UA1 send them to P1, which record-routed). >>> >>>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 >>> >>>_______________________________________________ >>>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 Fri Nov 1 19:09:46 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09923 for ; Fri, 1 Nov 2002 19:09:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA20BlH15338 for sip-archive@odin.ietf.org; Fri, 1 Nov 2002 19:11: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 gA20BFv15316; Fri, 1 Nov 2002 19:11: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 gA209Mv15213 for ; Fri, 1 Nov 2002 19:09:22 -0500 Received: from oak.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09691 for ; Fri, 1 Nov 2002 19:06:49 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id gA2098b29994; Sat, 2 Nov 2002 00:09:08 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Nov 2002 19:09:46 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB364@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Anders Kristensen'" Cc: sip@ietf.org Subject: RE: [Sip] SIPS question Date: Fri, 1 Nov 2002 19:09:45 -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: , To be clear, that text in 26.2.2 is not normative, it is merely descriptive. The functional behavior of SIPS is specified elsewhere in the document; changing the wording of 26.2.2 does not change anything's behavior. I maintain that the problem normative text in 8.1.2 (end of 1st paragraph) was most likely written without sufficient consideration of loose routing. I can assure you that we were quite mindful of your culprit 2) below, and considered it a desirable case (in which TLS rightfully MUST be employed by the UAC to contact the first hop). We weren't really mindful of 1)... but again, throughout this discussion it has been a little unclear why a UA would specify a URI in the Contact address in responses that differs from the Contact address it sends when it registers (we call both of those things by the same name for a reason); this has been something of a corner case. I agree that it would be unfortunate to throw away loose routing for SIPS entirely - when I suggested this was the simplest fix, I meant simplest from a specification perspective. I know the text in 8.1.2 is bad, arguably 26.2.2 needs to be changed, but I haven't been able to go through the whole spec (as well as RFC3263) and hunt for similar text... mandating strict routing provides a one-sentence band-aid. In the long run, though, I agree it would be better to fix all the places where there is language contrary to lr. Finally, speaking to a point that has occasionally been brought up in this thread, RFC3261-compliant proxies MUST support SIPS. By RFC3261, proxies MUST support TLS, and TLS implementations MUST support SIPS. At a specification level, it isn't clear to me that we need to worry about ascertaining proxy support for SIPS any more than we worry about proxy support for TCP. I don't think this part of the behavior is broken, anyway. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Anders Kristensen [mailto:akristensen@dynamicsoft.com] > Sent: Friday, November 01, 2002 12:51 PM > To: Peterson, Jon > Cc: 'Christer Holmberg'; Arunachalam Venkatraman; sip@ietf.org > Subject: Re: [Sip] SIPS question > > > Wouldn't it be unfortunate if we were to downgrade an otherwise > all-loose routing signaling path to strict routing because of the > situation discussed here. > > I agree with Christer that the problem lies with the text of section > 26.2.2 which requires that the UAC use TLS even though it's not routing > the request based on the R-URI but to the top Route. It seems that > 26.2.2 didn't anticipate that 1) the scheme of the R-URI of a subequent > request can be sips even though it was sip for the original request, and > 2) initial requests with a sips R-URI but a preloaded Route whose top > URI is a sip URI. This last case could be common, for example, in cases > where a service route has a sip URI top entry. > > Is there a problem in clarifying section 26.2.2 to say that request is > sent using a transport of the top Route if there is one, or else to the > R-URI? It seems more natural to use the properties of the next-hop URI > that the request is in fact being sent to. > > It is clearly also the case, as Jon points out, that the UAS should be > at least discouraged from using a sips Contact when the top R-R isn't > sips (or it somehow *knows* that that proxy does in fact support sips). > If the original request has a Record-Route header, I don't think it > should matter whether or not the UAC happens to support sips or not - as > long as the upstream record-routing proxy does, that should be enough, no? > > Anders > > > Peterson, Jon wrote: > > I think the problem with much of the language that has been > cited from > > RFC3261 in this thread is that we expected SIPS to be > strict-routed. I don't > > think any of these problems with intermediaries and > retargeting arise if > > strict routing is used. Unfortunately, both loose routing > and SIPS arose > > relatively late in the game for RFC3261, and we may not > have fully studied > > their interaction. > > > > A few other notes about this thread: > > > > While I agree that HTTP R-U's cannot be retargeted to HTTPS, I think > > retargeting SIP to SIPS is attractive and workable, > provided strict routing > > is used (or language is introduced to bring SIPS into > parity with loose > > routing). It is desirable to be able to secure as much of > the communications > > path as possible. > > > > The recipient of a request should be able to ascertain > whether or not the > > request was retargeted to SIPS by checking to see if the To > header field > > uses the SIPS scheme. > > > > Finally, when we were working on the design of SIPS, we > noted that there > > were a class of problems that resulted from specifying > transport=tls (or any > > optional transport, including =tcp and =sctp) in > Contact/Record-Route header > > fields. Hence there is language in bis that says things like: > > > > The [Record-Route] URI SHOULD NOT > > contain the transport parameter unless the proxy > has knowledge > > (such as in a private network) that the next > downstream element > > that will be in the path of subsequent requests > supports that > > transport. > > > > Similar language should probably be introduced for SIPS, > and the Contact > > header. > > > > Anyway, for the time being, I suspect that the simplest bug > fix is to say > > that whenever a route set or remote target for a dialog > contains a SIPS URI, > > requests must be strict routed. > > > > Jon Peterson > > NeuStar, Inc. > > > > > >>-----Original Message----- > >>From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > >>Sent: Thursday, October 31, 2002 10:13 PM > >>To: Arunachalam Venkatraman > >>Cc: sip@ietf.org > >>Subject: Re: [Sip] SIPS question > >> > >> > >> > >>Hi Arunachalam, > >> > >>If there are no record routing proxies in the path, your > >>second "rule" may > >>work just fine. > >> > >>However, I am not sure your first "rule" would work when > >>there are record > >>routing proxies. Like Hisham said, if UA2 has registered > >>itself with P1 using > >>SIPS-URI, P1 will contact UA2 using SIPS-URI. Now, UA2 MUST > >>insert SIPS-URI in > >>the Contact header, which again means that UA1 may end up in > >>a situation where > >>the Request-URI for the next request is SIPS-URI, and > >>according to the spec it > >>MUST now use TLS for that request - even if it doesn't > >>support TLS, and even > >>if it's not going to use the Request-URI to route the message > >>in the first > >>place. > >> > >>Now, changing the text in the spec MAY help: the change would > >>be that the UAC > >>does not make any transport based decissions based on the > >>Request-URI, but on > >>the URI it actually uses to route the request (which of > >>course MAY be the > >>Request-URI, but also the top Route). > >> > >>I also think part of the basic problem is the fact that the > >>URI may change > >>from SIP to SIPS in the signalling path. I don't think that > >>is true for > >>HTTP/HTTPS, is it? > >> > >>Thanks for your comments! > >> > >>Regards, > >> > >>Christer Holmberg > >>Ericsson Finland > >> > >> > >> > >> > >>Arunachalam Venkatraman wrote: > >> > >> > >>>Christer > >>>Interesting issue. > >>> > >>>How about this for a solution --- > >>>The UAS sends a SIPS URI in its Contact only if one of the > >> > >>following is > >> > >>>true- > >>>1. The top Route in its Route Set is a SIPS URI > >>>2. If no Route set has been established, the Contact in the > >> > >>request is a > >> > >>>SIPS-URI. > >>> > >>>In all other cases, it sends a SIP-URI in its Contact. > >>> > >>>Will this work? > >>> > >>>Venkat > >>> > >>>-----Original Message----- > >>>From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > >>>Christer Holmberg > >>>Sent: Thursday, October 31, 2002 6:43 AM > >>>To: hisham.khartabil@nokia.com > >>>Cc: jon.peterson@neustar.biz; sip@ietf.org > >>>Subject: Re: [Sip] SIPS question > >>> > >>>Hi, > >>> > >>> > >>>>>>>Hi, > >>>>>>> > >>>>>>> > >>>>>>>>I guess UA2 should have registered with P1 using > >>>>>>> > >>a sips-uri > >> > >>>>>>>in the contact-header. P1 doesn't care about the > >>>>>>>contact-header sent in the 200 OK. UA2 contact-header is > >>>>>>>telling UA1 (not P1) to contact it using TLS. > >>>>>>> > >>>>>>>No, but the Contact header value will be used in requests > >>>>>>>during the session, as part of the route set or Request-URI > >>>>>>>(depending on if loose routing is used etc) > >>>>>> > >>>>>>What I meant to say is that if UA2 had registered with P1 > >>>>> > >>>>>using a sips-uri in the contact-header, then when P1 is > >>>>>routing the INVITE, it will put sips-uri in the record-route > >>>>>header since the request uri (retrieved from the registrar) > >>>>>is a sips-uri. > >>>>> > >>>>> > >>>>>>Since P1 contacted UA2 using sips, the 200 ok must contain > >>>>> > >>>>>a contact-header with sips-uri. > >>>>> > >>>>>Ok. So, in this case UA1 will receive a Record-Route with > >>>>>SIPS-URI. So, the next time UA1 sends a request the SIPS-URI > >>>>>indicates it shall use TLS - which UA1 may not even support. > >>>> > >>>>No, P1 will modify the record-route header in the > >>> > >>response and will make > >> > >>>it a sip-uri. > >>> > >>> > >>>>>And, since UA1 used SIP-URI in its own Contact header, P1 > >>>>>shall use UDP (or TCP) to forward requests received from UA2, > >>>>>so now we would have the separate-transport-in-each-direction > >>>>>problem between UA1 and P1, wouldn't we? > >>>> > >>>>UA1 will have a different route-set that UA2. > >>> > >>>True. > >>> > >>>However, EVEN if UA2 has registered itself with P1 using > >> > >>SIPS-URI, and P1 > >> > >>>uses TLS to > >>>contact it, UA1 will still receive a Contact header with > >> > >>SIPS-URI, and > >> > >>>according to the > >>>RFC ("if the Request-URI is SIPS-URI, TLS MUST be used") it > >> > >>would have to > >> > >>>use TLS for the > >>>other requests, even if it doesn't support TLS, and even if > >> > >>the requests > >> > >>>aren't even sent > >>>to UA2 (UA1 send them to P1, which record-routed). > >>> > >>>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 > >>> > >>>_______________________________________________ > >>>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 Sat Nov 2 08:38:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04759 for ; Sat, 2 Nov 2002 08:38:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA2De8q31520 for sip-archive@odin.ietf.org; Sat, 2 Nov 2002 08:40: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 gA2DaJv30827; Sat, 2 Nov 2002 08:36: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 gA2DX0v30728 for ; Sat, 2 Nov 2002 08:33:00 -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 IAA04680 for ; Sat, 2 Nov 2002 08:30:31 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA2DWtKV006344; Sat, 2 Nov 2002 14:32:55 +0100 (MET) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id gA2DWsZb006775; Sat, 2 Nov 2002 15:32:54 +0200 (EET) Message-ID: <3DC3D406.C2006F06@lmf.ericsson.se> Date: Sat, 02 Nov 2002 15:32:54 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Paraskevopoulos Pavlos CC: sip@ietf.org Subject: Re: [Sip] INVITE without SDP body. References: <3DC28041.2030606@intracom.gr> <3DC285B6.FE7A10AE@lmf.ericsson.se> <3DC29008.7060202@intracom.gr> 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, > Thanks for your response. > I agree but I 'm a bit confused because in the > draft-elwell-sippping-qsig2sip-03.txt (Interworking between SIP and > QSIG), > it is mentioned : > > If the SIP INVITE request does not contain SDP information and > does not contain > either a Required header or a Supported header with option tag > 100rel, the gateway > SHALL NOT issue a QSIG SETUP message and SHALL send a SIP 488 (NOT > ACCEPTABLE HERE) response. > > What did I understand wrong? I don't think you understood anything wrong :) Specific SIP APPLICATIONS (in your case the QSIG-to-SIP interworking) may require certain things (eg some SIP extensions, SDP in the INVITE etc etc etc), but it is not a general SIP PROTOCOL requirement that you must use PRACK if you don't have SDP in the INVITE. Regards, Christer Holmberg Ericsson Finland > > > Thanks again. > > > Christer Holmberg wrote: > >> Hi, >> >> 100rel is needed only if you want to use PRACK. It has nothing to do >> with the >> fact if you have a SDP in the INVITE or not. >> >> Note, however, that if you use PRACK you may have to send the SDP >> before you >> send the ACK (in a PRACK), but that's another issue... >> >> Regards, >> >> Christer Holmberg >> Ericsson Finland >> >> >> Paraskevopoulos Pavlos wrote: >> >> >> > Hello, >> > >> > I 'm trying to build a SIP gateway, and I would appreciate a little >> > help. >> > >> > Think of that scenario >> > >> > ISDN GW SIP-EP >> > ---------------------------------------------------------------- >> > -->SETUP --->INVITE(no SDP) >> > >> > ALERTING<--- 180<----- >> > CONNECT<--- 200<----- >> > ---->ACK(SDP) >> > >> > >> > I want to send the INVITE request without SDP info. The SDP info >> > will >> > come later with the ACK. >> > Does the INVITE request have to contain a Required or Supported >> > header >> > with option tag 100rel? >> > >> > Thanks in advance. >> > >> > _______________________________________________ >> > 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 Sat Nov 2 11:28:43 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08168 for ; Sat, 2 Nov 2002 11:28:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA2GUfZ06976 for sip-archive@odin.ietf.org; Sat, 2 Nov 2002 11:30: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 gA2GUGv06966; Sat, 2 Nov 2002 11: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 gA2GSQv06899 for ; Sat, 2 Nov 2002 11:28:26 -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 LAA08132 for ; Sat, 2 Nov 2002 11:25:56 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA2GSFQ1024013; Sat, 2 Nov 2002 17:28:15 +0100 (MET) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id gA2GSDZb012546; Sat, 2 Nov 2002 18:28:13 +0200 (EET) Message-ID: <3DC3FD1D.89938E8F@lmf.ericsson.se> Date: Sat, 02 Nov 2002 18:28:13 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'Anders Kristensen'" , sip@ietf.org Subject: Re: [Sip] SIPS question References: <15A2739B7DAA624D8091C65981D7DA815EB364@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 Hi, First, I keep mentioning chapter 26.2.2, but as Hisham said, the same thing is basically said also (maybe even more clear) in chapter 8.1.2. Then: I DO agree with Jon that it should be possible to use TLS only between specific hosts in the path. I DO NOT, however, like the proposal that we should allow this only for strict routing, since the RFC basically recommends not to use strict routing in the first place... So, I agree with Anders that we need a generic solution which works also for loose routing. So, I think the easiest, and also best, solution is to change the text about the Request-URI - to say that the if-to-use-TLS decission should be made based the URI actually used for the message routing, which again MAY be the Request-URI, but also the top Route. Or, is there something else which would be messed up with such a change? Also, it's not only about mid-session requests, even if that may be so in most cases. Assume the Request-URI for the initial INVITE is SIPS-URI, but the UAC uses an outbound proxy, ie using a pre-configured Route with SIP-URI. Also, what if one wants to use TEL-URL (or whatever non-SIP-URI?) Then one could argue that we will have to define TELS-URL etc... We shall remember that SIP DOES allow the use of multiple URI schemes, which again is different from HTTP. So, MAYBE we would need a more generic solution, ie using another mechanism to indicate the use of TLS (eg using the transport parameter, and/or a Require header option tag). But, that's another discussion :) Regards, Christer Holmberg Ericsson Finland "Peterson, Jon" wrote: > To be clear, that text in 26.2.2 is not normative, it is merely descriptive. > The functional behavior of SIPS is specified elsewhere in the document; > changing the wording of 26.2.2 does not change anything's behavior. > > I maintain that the problem normative text in 8.1.2 (end of 1st paragraph) > was most likely written without sufficient consideration of loose routing. I > can assure you that we were quite mindful of your culprit 2) below, and > considered it a desirable case (in which TLS rightfully MUST be employed by > the UAC to contact the first hop). We weren't really mindful of 1)... but > again, throughout this discussion it has been a little unclear why a UA > would specify a URI in the Contact address in responses that differs from > the Contact address it sends when it registers (we call both of those things > by the same name for a reason); this has been something of a corner case. > > I agree that it would be unfortunate to throw away loose routing for SIPS > entirely - when I suggested this was the simplest fix, I meant simplest from > a specification perspective. I know the text in 8.1.2 is bad, arguably > 26.2.2 needs to be changed, but I haven't been able to go through the whole > spec (as well as RFC3263) and hunt for similar text... mandating strict > routing provides a one-sentence band-aid. In the long run, though, I agree > it would be better to fix all the places where there is language contrary to > lr. > > Finally, speaking to a point that has occasionally been brought up in this > thread, RFC3261-compliant proxies MUST support SIPS. By RFC3261, proxies > MUST support TLS, and TLS implementations MUST support SIPS. At a > specification level, it isn't clear to me that we need to worry about > ascertaining proxy support for SIPS any more than we worry about proxy > support for TCP. I don't think this part of the behavior is broken, anyway. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Anders Kristensen [mailto:akristensen@dynamicsoft.com] > > Sent: Friday, November 01, 2002 12:51 PM > > To: Peterson, Jon > > Cc: 'Christer Holmberg'; Arunachalam Venkatraman; sip@ietf.org > > Subject: Re: [Sip] SIPS question > > > > > > Wouldn't it be unfortunate if we were to downgrade an otherwise > > all-loose routing signaling path to strict routing because of the > > situation discussed here. > > > > I agree with Christer that the problem lies with the text of section > > 26.2.2 which requires that the UAC use TLS even though it's not routing > > the request based on the R-URI but to the top Route. It seems that > > 26.2.2 didn't anticipate that 1) the scheme of the R-URI of a subequent > > request can be sips even though it was sip for the original request, and > > 2) initial requests with a sips R-URI but a preloaded Route whose top > > URI is a sip URI. This last case could be common, for example, in cases > > where a service route has a sip URI top entry. > > > > Is there a problem in clarifying section 26.2.2 to say that request is > > sent using a transport of the top Route if there is one, or else to the > > R-URI? It seems more natural to use the properties of the next-hop URI > > that the request is in fact being sent to. > > > > It is clearly also the case, as Jon points out, that the UAS should be > > at least discouraged from using a sips Contact when the top R-R isn't > > sips (or it somehow *knows* that that proxy does in fact support sips). > > If the original request has a Record-Route header, I don't think it > > should matter whether or not the UAC happens to support sips or not - as > > long as the upstream record-routing proxy does, that should be enough, no? > > > > Anders > > > > > > Peterson, Jon wrote: > > > I think the problem with much of the language that has been > > cited from > > > RFC3261 in this thread is that we expected SIPS to be > > strict-routed. I don't > > > think any of these problems with intermediaries and > > retargeting arise if > > > strict routing is used. Unfortunately, both loose routing > > and SIPS arose > > > relatively late in the game for RFC3261, and we may not > > have fully studied > > > their interaction. > > > > > > A few other notes about this thread: > > > > > > While I agree that HTTP R-U's cannot be retargeted to HTTPS, I think > > > retargeting SIP to SIPS is attractive and workable, > > provided strict routing > > > is used (or language is introduced to bring SIPS into > > parity with loose > > > routing). It is desirable to be able to secure as much of > > the communications > > > path as possible. > > > > > > The recipient of a request should be able to ascertain > > whether or not the > > > request was retargeted to SIPS by checking to see if the To > > header field > > > uses the SIPS scheme. > > > > > > Finally, when we were working on the design of SIPS, we > > noted that there > > > were a class of problems that resulted from specifying > > transport=tls (or any > > > optional transport, including =tcp and =sctp) in > > Contact/Record-Route header > > > fields. Hence there is language in bis that says things like: > > > > > > The [Record-Route] URI SHOULD NOT > > > contain the transport parameter unless the proxy > > has knowledge > > > (such as in a private network) that the next > > downstream element > > > that will be in the path of subsequent requests > > supports that > > > transport. > > > > > > Similar language should probably be introduced for SIPS, > > and the Contact > > > header. > > > > > > Anyway, for the time being, I suspect that the simplest bug > > fix is to say > > > that whenever a route set or remote target for a dialog > > contains a SIPS URI, > > > requests must be strict routed. > > > > > > Jon Peterson > > > NeuStar, Inc. > > > > > > > > >>-----Original Message----- > > >>From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > >>Sent: Thursday, October 31, 2002 10:13 PM > > >>To: Arunachalam Venkatraman > > >>Cc: sip@ietf.org > > >>Subject: Re: [Sip] SIPS question > > >> > > >> > > >> > > >>Hi Arunachalam, > > >> > > >>If there are no record routing proxies in the path, your > > >>second "rule" may > > >>work just fine. > > >> > > >>However, I am not sure your first "rule" would work when > > >>there are record > > >>routing proxies. Like Hisham said, if UA2 has registered > > >>itself with P1 using > > >>SIPS-URI, P1 will contact UA2 using SIPS-URI. Now, UA2 MUST > > >>insert SIPS-URI in > > >>the Contact header, which again means that UA1 may end up in > > >>a situation where > > >>the Request-URI for the next request is SIPS-URI, and > > >>according to the spec it > > >>MUST now use TLS for that request - even if it doesn't > > >>support TLS, and even > > >>if it's not going to use the Request-URI to route the message > > >>in the first > > >>place. > > >> > > >>Now, changing the text in the spec MAY help: the change would > > >>be that the UAC > > >>does not make any transport based decissions based on the > > >>Request-URI, but on > > >>the URI it actually uses to route the request (which of > > >>course MAY be the > > >>Request-URI, but also the top Route). > > >> > > >>I also think part of the basic problem is the fact that the > > >>URI may change > > >>from SIP to SIPS in the signalling path. I don't think that > > >>is true for > > >>HTTP/HTTPS, is it? > > >> > > >>Thanks for your comments! > > >> > > >>Regards, > > >> > > >>Christer Holmberg > > >>Ericsson Finland > > >> > > >> > > >> > > >> > > >>Arunachalam Venkatraman wrote: > > >> > > >> > > >>>Christer > > >>>Interesting issue. > > >>> > > >>>How about this for a solution --- > > >>>The UAS sends a SIPS URI in its Contact only if one of the > > >> > > >>following is > > >> > > >>>true- > > >>>1. The top Route in its Route Set is a SIPS URI > > >>>2. If no Route set has been established, the Contact in the > > >> > > >>request is a > > >> > > >>>SIPS-URI. > > >>> > > >>>In all other cases, it sends a SIP-URI in its Contact. > > >>> > > >>>Will this work? > > >>> > > >>>Venkat > > >>> > > >>>-----Original Message----- > > >>>From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > > >>>Christer Holmberg > > >>>Sent: Thursday, October 31, 2002 6:43 AM > > >>>To: hisham.khartabil@nokia.com > > >>>Cc: jon.peterson@neustar.biz; sip@ietf.org > > >>>Subject: Re: [Sip] SIPS question > > >>> > > >>>Hi, > > >>> > > >>> > > >>>>>>>Hi, > > >>>>>>> > > >>>>>>> > > >>>>>>>>I guess UA2 should have registered with P1 using > > >>>>>>> > > >>a sips-uri > > >> > > >>>>>>>in the contact-header. P1 doesn't care about the > > >>>>>>>contact-header sent in the 200 OK. UA2 contact-header is > > >>>>>>>telling UA1 (not P1) to contact it using TLS. > > >>>>>>> > > >>>>>>>No, but the Contact header value will be used in requests > > >>>>>>>during the session, as part of the route set or Request-URI > > >>>>>>>(depending on if loose routing is used etc) > > >>>>>> > > >>>>>>What I meant to say is that if UA2 had registered with P1 > > >>>>> > > >>>>>using a sips-uri in the contact-header, then when P1 is > > >>>>>routing the INVITE, it will put sips-uri in the record-route > > >>>>>header since the request uri (retrieved from the registrar) > > >>>>>is a sips-uri. > > >>>>> > > >>>>> > > >>>>>>Since P1 contacted UA2 using sips, the 200 ok must contain > > >>>>> > > >>>>>a contact-header with sips-uri. > > >>>>> > > >>>>>Ok. So, in this case UA1 will receive a Record-Route with > > >>>>>SIPS-URI. So, the next time UA1 sends a request the SIPS-URI > > >>>>>indicates it shall use TLS - which UA1 may not even support. > > >>>> > > >>>>No, P1 will modify the record-route header in the > > >>> > > >>response and will make > > >> > > >>>it a sip-uri. > > >>> > > >>> > > >>>>>And, since UA1 used SIP-URI in its own Contact header, P1 > > >>>>>shall use UDP (or TCP) to forward requests received from UA2, > > >>>>>so now we would have the separate-transport-in-each-direction > > >>>>>problem between UA1 and P1, wouldn't we? > > >>>> > > >>>>UA1 will have a different route-set that UA2. > > >>> > > >>>True. > > >>> > > >>>However, EVEN if UA2 has registered itself with P1 using > > >> > > >>SIPS-URI, and P1 > > >> > > >>>uses TLS to > > >>>contact it, UA1 will still receive a Contact header with > > >> > > >>SIPS-URI, and > > >> > > >>>according to the > > >>>RFC ("if the Request-URI is SIPS-URI, TLS MUST be used") it > > >> > > >>would have to > > >> > > >>>use TLS for the > > >>>other requests, even if it doesn't support TLS, and even if > > >> > > >>the requests > > >> > > >>>aren't even sent > > >>>to UA2 (UA1 send them to P1, which record-routed). > > >>> > > >>>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 > > >>> > > >>>_______________________________________________ > > >>>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 _______________________________________________ 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 Sat Nov 2 16:48:10 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13069 for ; Sat, 2 Nov 2002 16:48:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA2LoAB22499 for sip-archive@odin.ietf.org; Sat, 2 Nov 2002 16:50: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 gA2Lnjv22460; Sat, 2 Nov 2002 16:49: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 gA2LYGv21359 for ; Sat, 2 Nov 2002 16:34:16 -0500 Received: from IPOfCard1.guest-tek.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12776 for ; Sat, 2 Nov 2002 16:31:44 -0500 (EST) Received: from dynamicsoft.com ([141.154.107.210]) by IPOfCard1.guest-tek.com (8.11.6/8.8.7) with ESMTP id gA2LWer13390; Sat, 2 Nov 2002 16:32:40 -0500 Message-ID: <3DC43776.4070500@dynamicsoft.com> Date: Sat, 02 Nov 2002 15:37:10 -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: "Peterson, Jon" CC: "'Anders Kristensen'" , sip@ietf.org Subject: Re: [Sip] SIPS question References: <15A2739B7DAA624D8091C65981D7DA815EB364@stntexch2.va.neustar.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 I think we have lost sight of the semantics of SIPS. To me, SIPS is a way to tell a UA that ***the entire path*** was hop-by-hop secured. If a UA cannot know this with certainty, and we support these mixed scenarios, that devalues what sips is trying to do. Secure on just some hops is the same is insecure, and therefore, not useful. I also think it is a travesty to turn off loose routing to handle sips. I am not convinced this is needed or wise. I would prefer to add words which prohibit using sips at any hop unless the previous was sips. -Jonathan R. Peterson, Jon wrote: > To be clear, that text in 26.2.2 is not normative, it is merely descriptive. > The functional behavior of SIPS is specified elsewhere in the document; > changing the wording of 26.2.2 does not change anything's behavior. > > I maintain that the problem normative text in 8.1.2 (end of 1st paragraph) > was most likely written without sufficient consideration of loose routing. I > can assure you that we were quite mindful of your culprit 2) below, and > considered it a desirable case (in which TLS rightfully MUST be employed by > the UAC to contact the first hop). We weren't really mindful of 1)... but > again, throughout this discussion it has been a little unclear why a UA > would specify a URI in the Contact address in responses that differs from > the Contact address it sends when it registers (we call both of those things > by the same name for a reason); this has been something of a corner case. > > I agree that it would be unfortunate to throw away loose routing for SIPS > entirely - when I suggested this was the simplest fix, I meant simplest from > a specification perspective. I know the text in 8.1.2 is bad, arguably > 26.2.2 needs to be changed, but I haven't been able to go through the whole > spec (as well as RFC3263) and hunt for similar text... mandating strict > routing provides a one-sentence band-aid. In the long run, though, I agree > it would be better to fix all the places where there is language contrary to > lr. > > Finally, speaking to a point that has occasionally been brought up in this > thread, RFC3261-compliant proxies MUST support SIPS. By RFC3261, proxies > MUST support TLS, and TLS implementations MUST support SIPS. At a > specification level, it isn't clear to me that we need to worry about > ascertaining proxy support for SIPS any more than we worry about proxy > support for TCP. I don't think this part of the behavior is broken, anyway. > > Jon Peterson > NeuStar, Inc. > > >>-----Original Message----- >>From: Anders Kristensen [mailto:akristensen@dynamicsoft.com] >>Sent: Friday, November 01, 2002 12:51 PM >>To: Peterson, Jon >>Cc: 'Christer Holmberg'; Arunachalam Venkatraman; sip@ietf.org >>Subject: Re: [Sip] SIPS question >> >> >>Wouldn't it be unfortunate if we were to downgrade an otherwise >>all-loose routing signaling path to strict routing because of the >>situation discussed here. >> >>I agree with Christer that the problem lies with the text of section >>26.2.2 which requires that the UAC use TLS even though it's not routing >>the request based on the R-URI but to the top Route. It seems that >>26.2.2 didn't anticipate that 1) the scheme of the R-URI of a subequent >>request can be sips even though it was sip for the original request, and >>2) initial requests with a sips R-URI but a preloaded Route whose top >>URI is a sip URI. This last case could be common, for example, in cases >>where a service route has a sip URI top entry. >> >>Is there a problem in clarifying section 26.2.2 to say that request is >>sent using a transport of the top Route if there is one, or else to the >>R-URI? It seems more natural to use the properties of the next-hop URI >>that the request is in fact being sent to. >> >>It is clearly also the case, as Jon points out, that the UAS should be >>at least discouraged from using a sips Contact when the top R-R isn't >>sips (or it somehow *knows* that that proxy does in fact support sips). >>If the original request has a Record-Route header, I don't think it >>should matter whether or not the UAC happens to support sips or not - as >>long as the upstream record-routing proxy does, that should be enough, no? >> >>Anders >> >> >>Peterson, Jon wrote: >> >>>I think the problem with much of the language that has been >> >>cited from >> >>>RFC3261 in this thread is that we expected SIPS to be >> >>strict-routed. I don't >> >>>think any of these problems with intermediaries and >> >>retargeting arise if >> >>>strict routing is used. Unfortunately, both loose routing >> >>and SIPS arose >> >>>relatively late in the game for RFC3261, and we may not >> >>have fully studied >> >>>their interaction. >>> >>>A few other notes about this thread: >>> >>>While I agree that HTTP R-U's cannot be retargeted to HTTPS, I think >>>retargeting SIP to SIPS is attractive and workable, >> >>provided strict routing >> >>>is used (or language is introduced to bring SIPS into >> >>parity with loose >> >>>routing). It is desirable to be able to secure as much of >> >>the communications >> >>>path as possible. >>> >>>The recipient of a request should be able to ascertain >> >>whether or not the >> >>>request was retargeted to SIPS by checking to see if the To >> >>header field >> >>>uses the SIPS scheme. >>> >>>Finally, when we were working on the design of SIPS, we >> >>noted that there >> >>>were a class of problems that resulted from specifying >> >>transport=tls (or any >> >>>optional transport, including =tcp and =sctp) in >> >>Contact/Record-Route header >> >>>fields. Hence there is language in bis that says things like: >>> >>> The [Record-Route] URI SHOULD NOT >>> contain the transport parameter unless the proxy >> >>has knowledge >> >>> (such as in a private network) that the next >> >>downstream element >> >>> that will be in the path of subsequent requests >> >>supports that >> >>> transport. >>> >>>Similar language should probably be introduced for SIPS, >> >>and the Contact >> >>>header. >>> >>>Anyway, for the time being, I suspect that the simplest bug >> >>fix is to say >> >>>that whenever a route set or remote target for a dialog >> >>contains a SIPS URI, >> >>>requests must be strict routed. >>> >>>Jon Peterson >>>NeuStar, Inc. >>> >>> >>> >>>>-----Original Message----- >>>>From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] >>>>Sent: Thursday, October 31, 2002 10:13 PM >>>>To: Arunachalam Venkatraman >>>>Cc: sip@ietf.org >>>>Subject: Re: [Sip] SIPS question >>>> >>>> >>>> >>>>Hi Arunachalam, >>>> >>>>If there are no record routing proxies in the path, your >>>>second "rule" may >>>>work just fine. >>>> >>>>However, I am not sure your first "rule" would work when >>>>there are record >>>>routing proxies. Like Hisham said, if UA2 has registered >>>>itself with P1 using >>>>SIPS-URI, P1 will contact UA2 using SIPS-URI. Now, UA2 MUST >>>>insert SIPS-URI in >>>>the Contact header, which again means that UA1 may end up in >>>>a situation where >>>>the Request-URI for the next request is SIPS-URI, and >>>>according to the spec it >>>>MUST now use TLS for that request - even if it doesn't >>>>support TLS, and even >>>>if it's not going to use the Request-URI to route the message >>>>in the first >>>>place. >>>> >>>>Now, changing the text in the spec MAY help: the change would >>>>be that the UAC >>>>does not make any transport based decissions based on the >>>>Request-URI, but on >>>>the URI it actually uses to route the request (which of >>>>course MAY be the >>>>Request-URI, but also the top Route). >>>> >>>>I also think part of the basic problem is the fact that the >>>>URI may change >>> >>>>from SIP to SIPS in the signalling path. I don't think that >>> >>>>is true for >>>>HTTP/HTTPS, is it? >>>> >>>>Thanks for your comments! >>>> >>>>Regards, >>>> >>>>Christer Holmberg >>>>Ericsson Finland >>>> >>>> >>>> >>>> >>>>Arunachalam Venkatraman wrote: >>>> >>>> >>>> >>>>>Christer >>>>>Interesting issue. >>>>> >>>>>How about this for a solution --- >>>>>The UAS sends a SIPS URI in its Contact only if one of the >>>> >>>>following is >>>> >>>> >>>>>true- >>>>>1. The top Route in its Route Set is a SIPS URI >>>>>2. If no Route set has been established, the Contact in the >>>> >>>>request is a >>>> >>>> >>>>>SIPS-URI. >>>>> >>>>>In all other cases, it sends a SIP-URI in its Contact. >>>>> >>>>>Will this work? >>>>> >>>>>Venkat >>>>> >>>>>-----Original Message----- >>>>>From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of >>>>>Christer Holmberg >>>>>Sent: Thursday, October 31, 2002 6:43 AM >>>>>To: hisham.khartabil@nokia.com >>>>>Cc: jon.peterson@neustar.biz; sip@ietf.org >>>>>Subject: Re: [Sip] SIPS question >>>>> >>>>>Hi, >>>>> >>>>> >>>>> >>>>>>>>>Hi, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>I guess UA2 should have registered with P1 using >>>>>>>>> >>>>a sips-uri >>>> >>>> >>>>>>>>>in the contact-header. P1 doesn't care about the >>>>>>>>>contact-header sent in the 200 OK. UA2 contact-header is >>>>>>>>>telling UA1 (not P1) to contact it using TLS. >>>>>>>>> >>>>>>>>>No, but the Contact header value will be used in requests >>>>>>>>>during the session, as part of the route set or Request-URI >>>>>>>>>(depending on if loose routing is used etc) >>>>>>>> >>>>>>>>What I meant to say is that if UA2 had registered with P1 >>>>>>> >>>>>>>using a sips-uri in the contact-header, then when P1 is >>>>>>>routing the INVITE, it will put sips-uri in the record-route >>>>>>>header since the request uri (retrieved from the registrar) >>>>>>>is a sips-uri. >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Since P1 contacted UA2 using sips, the 200 ok must contain >>>>>>> >>>>>>>a contact-header with sips-uri. >>>>>>> >>>>>>>Ok. So, in this case UA1 will receive a Record-Route with >>>>>>>SIPS-URI. So, the next time UA1 sends a request the SIPS-URI >>>>>>>indicates it shall use TLS - which UA1 may not even support. >>>>>> >>>>>>No, P1 will modify the record-route header in the >>>>> >>>>response and will make >>>> >>>> >>>>>it a sip-uri. >>>>> >>>>> >>>>> >>>>>>>And, since UA1 used SIP-URI in its own Contact header, P1 >>>>>>>shall use UDP (or TCP) to forward requests received from UA2, >>>>>>>so now we would have the separate-transport-in-each-direction >>>>>>>problem between UA1 and P1, wouldn't we? >>>>>> >>>>>>UA1 will have a different route-set that UA2. >>>>> >>>>>True. >>>>> >>>>>However, EVEN if UA2 has registered itself with P1 using >>>> >>>>SIPS-URI, and P1 >>>> >>>> >>>>>uses TLS to >>>>>contact it, UA1 will still receive a Contact header with >>>> >>>>SIPS-URI, and >>>> >>>> >>>>>according to the >>>>>RFC ("if the Request-URI is SIPS-URI, TLS MUST be used") it >>>> >>>>would have to >>>> >>>> >>>>>use TLS for the >>>>>other requests, even if it doesn't support TLS, and even if >>>> >>>>the requests >>>> >>>> >>>>>aren't even sent >>>>>to UA2 (UA1 send them to P1, which record-routed). >>>>> >>>>>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 >>>>> >>>>>_______________________________________________ >>>>>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 > -- 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 Sat Nov 2 17:10:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13501 for ; Sat, 2 Nov 2002 17:10:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA2MCjr24200 for sip-archive@odin.ietf.org; Sat, 2 Nov 2002 17:12: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 gA2MCLv24175; Sat, 2 Nov 2002 17:12: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 gA2MBPv24134 for ; Sat, 2 Nov 2002 17:11:25 -0500 Received: from oak.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13473 for ; Sat, 2 Nov 2002 17:08:53 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id gA2MBAb18705; Sat, 2 Nov 2002 22:11:10 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Sat, 2 Nov 2002 17:11:50 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB36B@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Christer Holmberg'" Cc: "'Anders Kristensen'" , sip@ietf.org Subject: RE: [Sip] SIPS question Date: Sat, 2 Nov 2002 17:11:49 -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: , inline. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Saturday, November 02, 2002 8:28 AM > To: Peterson, Jon > Cc: 'Anders Kristensen'; sip@ietf.org > Subject: Re: [Sip] SIPS question > > > > Hi, > > First, I keep mentioning chapter 26.2.2, but as Hisham said, the same thing is > basically said also (maybe even more clear) in chapter 8.1.2. > Yes, we agree that this text is the problem. I worry that there might be other instances... > Then: > > I DO agree with Jon that it should be possible to use TLS only between specific > hosts in the path. > > I DO NOT, however, like the proposal that we should allow this only for strict > routing, since the RFC basically recommends not to use strict routing in the > first place... So, I agree with Anders that we need a generic solution which > works also for loose routing. > Understood - I also agree it would be better to make SIPS work with loose routing. > So, I think the easiest, and also best, solution is to change the text about the > Request-URI - to say that the if-to-use-TLS decission should be made based the > URI actually used for the message routing, which again MAY be the Request-URI, > but also the top Route. > Agreed. > Or, is there something else which would be messed up with > such a change? > Well, my real worry is that we need to go through the whole document set and make sure it's consistent. That is doable, though. > Also, it's not only about mid-session requests, even if that may be so in most > cases. Assume the Request-URI for the initial INVITE is SIPS-URI, but the UAC > uses an outbound proxy, ie using a pre-configured Route with SIP-URI. > The design of SIPS used as the 'remote target', as the AoR of the destination, necessitates that this first hop go over TLS. Look, as I said, outbound proxies are proxy servers, proxy servers MUST support TLS, and entities that support TLS MUST support SIPS. Converting this Route header to a TLS route is plausible and allowed by the spec. We actually want the request to fail if, for whatever reason (non-compliance with 3261), the outbound proxy cannot do TLS - that is desirable. SIPS in the 'remote target' is supposed to secure the entire request path, and it is supposed to fail if the path cannot be secured. > Also, what if one wants to use TEL-URL (or whatever non-SIP-URI?) Then one could > argue that we will have to define TELS-URL etc... We shall remember that SIP > DOES allow the use of multiple URI schemes, which again is different from HTTP. > So, MAYBE we would need a more generic solution, ie using another mechanism to > indicate the use of TLS (eg using the transport parameter, and/or a Require > header option tag). But, that's another discussion :) > Obviously, a tel URL could be part of a SIP[S] URI if you need to express a secure telephone number. But in some ways this misses the point of the SIPS mechanism. The most important property that SIPS provides has to do with the use of the NAPTR/SRV procedures described in RFC3263. There are certain forms of downgrade attacks that could arise if the DNS is used to describe transport options for a particular domain (including secure and non-secure options). Having an address-of-record that identifies itself as a secure resource allows a client to know that the DNS should supply a secure connection option, and that if it does not, then the DNS itself may be compromised. This is discussed at some length in RFC3263. The point is, this hop-by-hop-all-the-way security concept really only applies to URIs that have a hostname component, that have a concept of a domain. tel URLs are opaque identifiers, and they are not Internet-friendly from a routing perspective or a security perspective. Hence ENUM. We considered both transport parameters (transport=tls was obsoleted in favor of SIPS, as I'm sure you recall) and Require/Supported option tags in our deliberations about SIPS. The point is that we wanted a resource identifier that indicates directly that it should be contacted securely. > Regards, > > Christer Holmberg > Ericsson Finland > > > > > > > > > > > > "Peterson, Jon" wrote: > > > To be clear, that text in 26.2.2 is not normative, it is > merely descriptive. > > The functional behavior of SIPS is specified elsewhere in > the document; > > changing the wording of 26.2.2 does not change anything's behavior. > > > > I maintain that the problem normative text in 8.1.2 (end of > 1st paragraph) > > was most likely written without sufficient consideration of > loose routing. I > > can assure you that we were quite mindful of your culprit > 2) below, and > > considered it a desirable case (in which TLS rightfully > MUST be employed by > > the UAC to contact the first hop). We weren't really > mindful of 1)... but > > again, throughout this discussion it has been a little > unclear why a UA > > would specify a URI in the Contact address in responses > that differs from > > the Contact address it sends when it registers (we call > both of those things > > by the same name for a reason); this has been something of > a corner case. > > > > I agree that it would be unfortunate to throw away loose > routing for SIPS > > entirely - when I suggested this was the simplest fix, I > meant simplest from > > a specification perspective. I know the text in 8.1.2 is > bad, arguably > > 26.2.2 needs to be changed, but I haven't been able to go > through the whole > > spec (as well as RFC3263) and hunt for similar text... > mandating strict > > routing provides a one-sentence band-aid. In the long run, > though, I agree > > it would be better to fix all the places where there is > language contrary to > > lr. > > > > Finally, speaking to a point that has occasionally been > brought up in this > > thread, RFC3261-compliant proxies MUST support SIPS. By > RFC3261, proxies > > MUST support TLS, and TLS implementations MUST support SIPS. At a > > specification level, it isn't clear to me that we need to > worry about > > ascertaining proxy support for SIPS any more than we worry > about proxy > > support for TCP. I don't think this part of the behavior is > broken, anyway. > > > > Jon Peterson > > NeuStar, Inc. > > > > > -----Original Message----- > > > From: Anders Kristensen [mailto:akristensen@dynamicsoft.com] > > > Sent: Friday, November 01, 2002 12:51 PM > > > To: Peterson, Jon > > > Cc: 'Christer Holmberg'; Arunachalam Venkatraman; sip@ietf.org > > > Subject: Re: [Sip] SIPS question > > > > > > > > > Wouldn't it be unfortunate if we were to downgrade an otherwise > > > all-loose routing signaling path to strict routing because of the > > > situation discussed here. > > > > > > I agree with Christer that the problem lies with the text > of section > > > 26.2.2 which requires that the UAC use TLS even though > it's not routing > > > the request based on the R-URI but to the top Route. It seems that > > > 26.2.2 didn't anticipate that 1) the scheme of the R-URI > of a subequent > > > request can be sips even though it was sip for the > original request, and > > > 2) initial requests with a sips R-URI but a preloaded > Route whose top > > > URI is a sip URI. This last case could be common, for > example, in cases > > > where a service route has a sip URI top entry. > > > > > > Is there a problem in clarifying section 26.2.2 to say > that request is > > > sent using a transport of the top Route if there is one, > or else to the > > > R-URI? It seems more natural to use the properties of the > next-hop URI > > > that the request is in fact being sent to. > > > > > > It is clearly also the case, as Jon points out, that the > UAS should be > > > at least discouraged from using a sips Contact when the > top R-R isn't > > > sips (or it somehow *knows* that that proxy does in fact > support sips). > > > If the original request has a Record-Route header, I > don't think it > > > should matter whether or not the UAC happens to support > sips or not - as > > > long as the upstream record-routing proxy does, that > should be enough, no? > > > > > > Anders > > > > > > > > > Peterson, Jon wrote: > > > > I think the problem with much of the language that has been > > > cited from > > > > RFC3261 in this thread is that we expected SIPS to be > > > strict-routed. I don't > > > > think any of these problems with intermediaries and > > > retargeting arise if > > > > strict routing is used. Unfortunately, both loose routing > > > and SIPS arose > > > > relatively late in the game for RFC3261, and we may not > > > have fully studied > > > > their interaction. > > > > > > > > A few other notes about this thread: > > > > > > > > While I agree that HTTP R-U's cannot be retargeted to > HTTPS, I think > > > > retargeting SIP to SIPS is attractive and workable, > > > provided strict routing > > > > is used (or language is introduced to bring SIPS into > > > parity with loose > > > > routing). It is desirable to be able to secure as much of > > > the communications > > > > path as possible. > > > > > > > > The recipient of a request should be able to ascertain > > > whether or not the > > > > request was retargeted to SIPS by checking to see if the To > > > header field > > > > uses the SIPS scheme. > > > > > > > > Finally, when we were working on the design of SIPS, we > > > noted that there > > > > were a class of problems that resulted from specifying > > > transport=tls (or any > > > > optional transport, including =tcp and =sctp) in > > > Contact/Record-Route header > > > > fields. Hence there is language in bis that says things like: > > > > > > > > The [Record-Route] URI SHOULD NOT > > > > contain the transport parameter unless the proxy > > > has knowledge > > > > (such as in a private network) that the next > > > downstream element > > > > that will be in the path of subsequent requests > > > supports that > > > > transport. > > > > > > > > Similar language should probably be introduced for SIPS, > > > and the Contact > > > > header. > > > > > > > > Anyway, for the time being, I suspect that the simplest bug > > > fix is to say > > > > that whenever a route set or remote target for a dialog > > > contains a SIPS URI, > > > > requests must be strict routed. > > > > > > > > Jon Peterson > > > > NeuStar, Inc. > > > > > > > > > > > >>-----Original Message----- > > > >>From: Christer Holmberg > [mailto:christer.holmberg@lmf.ericsson.se] > > > >>Sent: Thursday, October 31, 2002 10:13 PM > > > >>To: Arunachalam Venkatraman > > > >>Cc: sip@ietf.org > > > >>Subject: Re: [Sip] SIPS question > > > >> > > > >> > > > >> > > > >>Hi Arunachalam, > > > >> > > > >>If there are no record routing proxies in the path, your > > > >>second "rule" may > > > >>work just fine. > > > >> > > > >>However, I am not sure your first "rule" would work when > > > >>there are record > > > >>routing proxies. Like Hisham said, if UA2 has registered > > > >>itself with P1 using > > > >>SIPS-URI, P1 will contact UA2 using SIPS-URI. Now, UA2 MUST > > > >>insert SIPS-URI in > > > >>the Contact header, which again means that UA1 may end up in > > > >>a situation where > > > >>the Request-URI for the next request is SIPS-URI, and > > > >>according to the spec it > > > >>MUST now use TLS for that request - even if it doesn't > > > >>support TLS, and even > > > >>if it's not going to use the Request-URI to route the message > > > >>in the first > > > >>place. > > > >> > > > >>Now, changing the text in the spec MAY help: the change would > > > >>be that the UAC > > > >>does not make any transport based decissions based on the > > > >>Request-URI, but on > > > >>the URI it actually uses to route the request (which of > > > >>course MAY be the > > > >>Request-URI, but also the top Route). > > > >> > > > >>I also think part of the basic problem is the fact that the > > > >>URI may change > > > >>from SIP to SIPS in the signalling path. I don't think that > > > >>is true for > > > >>HTTP/HTTPS, is it? > > > >> > > > >>Thanks for your comments! > > > >> > > > >>Regards, > > > >> > > > >>Christer Holmberg > > > >>Ericsson Finland > > > >> > > > >> > > > >> > > > >> > > > >>Arunachalam Venkatraman wrote: > > > >> > > > >> > > > >>>Christer > > > >>>Interesting issue. > > > >>> > > > >>>How about this for a solution --- > > > >>>The UAS sends a SIPS URI in its Contact only if one of the > > > >> > > > >>following is > > > >> > > > >>>true- > > > >>>1. The top Route in its Route Set is a SIPS URI > > > >>>2. If no Route set has been established, the Contact in the > > > >> > > > >>request is a > > > >> > > > >>>SIPS-URI. > > > >>> > > > >>>In all other cases, it sends a SIP-URI in its Contact. > > > >>> > > > >>>Will this work? > > > >>> > > > >>>Venkat > > > >>> > > > >>>-----Original Message----- > > > >>>From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On > Behalf Of > > > >>>Christer Holmberg > > > >>>Sent: Thursday, October 31, 2002 6:43 AM > > > >>>To: hisham.khartabil@nokia.com > > > >>>Cc: jon.peterson@neustar.biz; sip@ietf.org > > > >>>Subject: Re: [Sip] SIPS question > > > >>> > > > >>>Hi, > > > >>> > > > >>> > > > >>>>>>>Hi, > > > >>>>>>> > > > >>>>>>> > > > >>>>>>>>I guess UA2 should have registered with P1 using > > > >>>>>>> > > > >>a sips-uri > > > >> > > > >>>>>>>in the contact-header. P1 doesn't care about the > > > >>>>>>>contact-header sent in the 200 OK. UA2 contact-header is > > > >>>>>>>telling UA1 (not P1) to contact it using TLS. > > > >>>>>>> > > > >>>>>>>No, but the Contact header value will be used in requests > > > >>>>>>>during the session, as part of the route set or Request-URI > > > >>>>>>>(depending on if loose routing is used etc) > > > >>>>>> > > > >>>>>>What I meant to say is that if UA2 had registered with P1 > > > >>>>> > > > >>>>>using a sips-uri in the contact-header, then when P1 is > > > >>>>>routing the INVITE, it will put sips-uri in the record-route > > > >>>>>header since the request uri (retrieved from the registrar) > > > >>>>>is a sips-uri. > > > >>>>> > > > >>>>> > > > >>>>>>Since P1 contacted UA2 using sips, the 200 ok must contain > > > >>>>> > > > >>>>>a contact-header with sips-uri. > > > >>>>> > > > >>>>>Ok. So, in this case UA1 will receive a Record-Route with > > > >>>>>SIPS-URI. So, the next time UA1 sends a request the SIPS-URI > > > >>>>>indicates it shall use TLS - which UA1 may not even support. > > > >>>> > > > >>>>No, P1 will modify the record-route header in the > > > >>> > > > >>response and will make > > > >> > > > >>>it a sip-uri. > > > >>> > > > >>> > > > >>>>>And, since UA1 used SIP-URI in its own Contact header, P1 > > > >>>>>shall use UDP (or TCP) to forward requests received from UA2, > > > >>>>>so now we would have the separate-transport-in-each-direction > > > >>>>>problem between UA1 and P1, wouldn't we? > > > >>>> > > > >>>>UA1 will have a different route-set that UA2. > > > >>> > > > >>>True. > > > >>> > > > >>>However, EVEN if UA2 has registered itself with P1 using > > > >> > > > >>SIPS-URI, and P1 > > > >> > > > >>>uses TLS to > > > >>>contact it, UA1 will still receive a Contact header with > > > >> > > > >>SIPS-URI, and > > > >> > > > >>>according to the > > > >>>RFC ("if the Request-URI is SIPS-URI, TLS MUST be used") it > > > >> > > > >>would have to > > > >> > > > >>>use TLS for the > > > >>>other requests, even if it doesn't support TLS, and even if > > > >> > > > >>the requests > > > >> > > > >>>aren't even sent > > > >>>to UA2 (UA1 send them to P1, which record-routed). > > > >>> > > > >>>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 > > > >>> > > > >>>_______________________________________________ > > > >>>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 > _______________________________________________ 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 Sat Nov 2 17:11:22 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13523 for ; Sat, 2 Nov 2002 17:11:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA2MDMq24257 for sip-archive@odin.ietf.org; Sat, 2 Nov 2002 17:13:22 -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 gA2MD5v24233; Sat, 2 Nov 2002 17:13: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 gA2MCUv24192 for ; Sat, 2 Nov 2002 17:12:30 -0500 Received: from oak.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13492 for ; Sat, 2 Nov 2002 17:09:58 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id gA2MCGb18716; Sat, 2 Nov 2002 22:12:17 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Sat, 2 Nov 2002 17:12:56 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB36C@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Jonathan Rosenberg'" Cc: "'Anders Kristensen'" , sip@ietf.org Subject: RE: [Sip] SIPS question Date: Sat, 2 Nov 2002 17:12:55 -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: , inline. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Saturday, November 02, 2002 12:37 PM > To: Peterson, Jon > Cc: 'Anders Kristensen'; sip@ietf.org > Subject: Re: [Sip] SIPS question > > > I think we have lost sight of the semantics of SIPS. > > To me, SIPS is a way to tell a UA that ***the entire path*** was > hop-by-hop secured. If a UA cannot know this with certainty, and we > support these mixed scenarios, that devalues what sips is trying to do. Actually, I recall our discussions of SIPS involving more than just hop-by-hop-all-the-way scenarios - more than just the use of SIPS as an AoR. Since we deprecated transport=tls, there is another reasonable application of SIPS for characterizing particular hops that should go over TLS (we discussed its use in Route headers, Contact headers, etc). The point is using SIPS in the 'remote target' implies the e2e semantic, but its use elsewhere has a different significance. There are plenty of reasons why we might want individual hops to go over TLS, and SIPS is a reasonable way to express this. The problem is just that the text is a little schizo about how to differentiate the use of SIPS as an AoR from the use of SIPS as an element in a Route set, and that this confusion seems to have arisen from loose v. strict routing. > Secure on just some hops is the same is insecure, and therefore, not > useful. > Obviously that's dependent on particular deployments. Some hops that a request traverses might have different security requirements than others. Only the SIPS AoR usage has the connotation that all the hops must be secure. > I also think it is a travesty to turn off loose routing to handle sips. > I am not convinced this is needed or wise. I don't think I characterize it as a 'travesty', but I agree it is less desirable, and it is unneeded. I suggested strict routing for SIPS only based on my assessment of necessary textual changes, but after studying the text for a while I agree we can probably salvage SIPS for lr. > > I would prefer to add words which prohibit using sips at any hop unless > the previous was sips. > This prohibits useful security functions that seem orthogonal to the concerns Christer et al have raised. > -Jonathan R. > > Peterson, Jon wrote: > > To be clear, that text in 26.2.2 is not normative, it is > merely descriptive. > > The functional behavior of SIPS is specified elsewhere in > the document; > > changing the wording of 26.2.2 does not change anything's behavior. > > > > I maintain that the problem normative text in 8.1.2 (end of > 1st paragraph) > > was most likely written without sufficient consideration of > loose routing. I > > can assure you that we were quite mindful of your culprit > 2) below, and > > considered it a desirable case (in which TLS rightfully > MUST be employed by > > the UAC to contact the first hop). We weren't really > mindful of 1)... but > > again, throughout this discussion it has been a little > unclear why a UA > > would specify a URI in the Contact address in responses > that differs from > > the Contact address it sends when it registers (we call > both of those things > > by the same name for a reason); this has been something of > a corner case. > > > > I agree that it would be unfortunate to throw away loose > routing for SIPS > > entirely - when I suggested this was the simplest fix, I > meant simplest from > > a specification perspective. I know the text in 8.1.2 is > bad, arguably > > 26.2.2 needs to be changed, but I haven't been able to go > through the whole > > spec (as well as RFC3263) and hunt for similar text... > mandating strict > > routing provides a one-sentence band-aid. In the long run, > though, I agree > > it would be better to fix all the places where there is > language contrary to > > lr. > > > > Finally, speaking to a point that has occasionally been > brought up in this > > thread, RFC3261-compliant proxies MUST support SIPS. By > RFC3261, proxies > > MUST support TLS, and TLS implementations MUST support SIPS. At a > > specification level, it isn't clear to me that we need to > worry about > > ascertaining proxy support for SIPS any more than we worry > about proxy > > support for TCP. I don't think this part of the behavior is > broken, anyway. > > > > Jon Peterson > > NeuStar, Inc. > > > > > >>-----Original Message----- > >>From: Anders Kristensen [mailto:akristensen@dynamicsoft.com] > >>Sent: Friday, November 01, 2002 12:51 PM > >>To: Peterson, Jon > >>Cc: 'Christer Holmberg'; Arunachalam Venkatraman; sip@ietf.org > >>Subject: Re: [Sip] SIPS question > >> > >> > >>Wouldn't it be unfortunate if we were to downgrade an otherwise > >>all-loose routing signaling path to strict routing because of the > >>situation discussed here. > >> > >>I agree with Christer that the problem lies with the text > of section > >>26.2.2 which requires that the UAC use TLS even though it's > not routing > >>the request based on the R-URI but to the top Route. It seems that > >>26.2.2 didn't anticipate that 1) the scheme of the R-URI of > a subequent > >>request can be sips even though it was sip for the original > request, and > >>2) initial requests with a sips R-URI but a preloaded Route > whose top > >>URI is a sip URI. This last case could be common, for > example, in cases > >>where a service route has a sip URI top entry. > >> > >>Is there a problem in clarifying section 26.2.2 to say that > request is > >>sent using a transport of the top Route if there is one, or > else to the > >>R-URI? It seems more natural to use the properties of the > next-hop URI > >>that the request is in fact being sent to. > >> > >>It is clearly also the case, as Jon points out, that the > UAS should be > >>at least discouraged from using a sips Contact when the top > R-R isn't > >>sips (or it somehow *knows* that that proxy does in fact > support sips). > >>If the original request has a Record-Route header, I don't think it > >>should matter whether or not the UAC happens to support > sips or not - as > >>long as the upstream record-routing proxy does, that should > be enough, no? > >> > >>Anders > >> > >> > >>Peterson, Jon wrote: > >> > >>>I think the problem with much of the language that has been > >> > >>cited from > >> > >>>RFC3261 in this thread is that we expected SIPS to be > >> > >>strict-routed. I don't > >> > >>>think any of these problems with intermediaries and > >> > >>retargeting arise if > >> > >>>strict routing is used. Unfortunately, both loose routing > >> > >>and SIPS arose > >> > >>>relatively late in the game for RFC3261, and we may not > >> > >>have fully studied > >> > >>>their interaction. > >>> > >>>A few other notes about this thread: > >>> > >>>While I agree that HTTP R-U's cannot be retargeted to > HTTPS, I think > >>>retargeting SIP to SIPS is attractive and workable, > >> > >>provided strict routing > >> > >>>is used (or language is introduced to bring SIPS into > >> > >>parity with loose > >> > >>>routing). It is desirable to be able to secure as much of > >> > >>the communications > >> > >>>path as possible. > >>> > >>>The recipient of a request should be able to ascertain > >> > >>whether or not the > >> > >>>request was retargeted to SIPS by checking to see if the To > >> > >>header field > >> > >>>uses the SIPS scheme. > >>> > >>>Finally, when we were working on the design of SIPS, we > >> > >>noted that there > >> > >>>were a class of problems that resulted from specifying > >> > >>transport=tls (or any > >> > >>>optional transport, including =tcp and =sctp) in > >> > >>Contact/Record-Route header > >> > >>>fields. Hence there is language in bis that says things like: > >>> > >>> The [Record-Route] URI SHOULD NOT > >>> contain the transport parameter unless the proxy > >> > >>has knowledge > >> > >>> (such as in a private network) that the next > >> > >>downstream element > >> > >>> that will be in the path of subsequent requests > >> > >>supports that > >> > >>> transport. > >>> > >>>Similar language should probably be introduced for SIPS, > >> > >>and the Contact > >> > >>>header. > >>> > >>>Anyway, for the time being, I suspect that the simplest bug > >> > >>fix is to say > >> > >>>that whenever a route set or remote target for a dialog > >> > >>contains a SIPS URI, > >> > >>>requests must be strict routed. > >>> > >>>Jon Peterson > >>>NeuStar, Inc. > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > >>>>Sent: Thursday, October 31, 2002 10:13 PM > >>>>To: Arunachalam Venkatraman > >>>>Cc: sip@ietf.org > >>>>Subject: Re: [Sip] SIPS question > >>>> > >>>> > >>>> > >>>>Hi Arunachalam, > >>>> > >>>>If there are no record routing proxies in the path, your > >>>>second "rule" may > >>>>work just fine. > >>>> > >>>>However, I am not sure your first "rule" would work when > >>>>there are record > >>>>routing proxies. Like Hisham said, if UA2 has registered > >>>>itself with P1 using > >>>>SIPS-URI, P1 will contact UA2 using SIPS-URI. Now, UA2 MUST > >>>>insert SIPS-URI in > >>>>the Contact header, which again means that UA1 may end up in > >>>>a situation where > >>>>the Request-URI for the next request is SIPS-URI, and > >>>>according to the spec it > >>>>MUST now use TLS for that request - even if it doesn't > >>>>support TLS, and even > >>>>if it's not going to use the Request-URI to route the message > >>>>in the first > >>>>place. > >>>> > >>>>Now, changing the text in the spec MAY help: the change would > >>>>be that the UAC > >>>>does not make any transport based decissions based on the > >>>>Request-URI, but on > >>>>the URI it actually uses to route the request (which of > >>>>course MAY be the > >>>>Request-URI, but also the top Route). > >>>> > >>>>I also think part of the basic problem is the fact that the > >>>>URI may change > >>> > >>>>from SIP to SIPS in the signalling path. I don't think that > >>> > >>>>is true for > >>>>HTTP/HTTPS, is it? > >>>> > >>>>Thanks for your comments! > >>>> > >>>>Regards, > >>>> > >>>>Christer Holmberg > >>>>Ericsson Finland > >>>> > >>>> > >>>> > >>>> > >>>>Arunachalam Venkatraman wrote: > >>>> > >>>> > >>>> > >>>>>Christer > >>>>>Interesting issue. > >>>>> > >>>>>How about this for a solution --- > >>>>>The UAS sends a SIPS URI in its Contact only if one of the > >>>> > >>>>following is > >>>> > >>>> > >>>>>true- > >>>>>1. The top Route in its Route Set is a SIPS URI > >>>>>2. If no Route set has been established, the Contact in the > >>>> > >>>>request is a > >>>> > >>>> > >>>>>SIPS-URI. > >>>>> > >>>>>In all other cases, it sends a SIP-URI in its Contact. > >>>>> > >>>>>Will this work? > >>>>> > >>>>>Venkat > >>>>> > >>>>>-----Original Message----- > >>>>>From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > >>>>>Christer Holmberg > >>>>>Sent: Thursday, October 31, 2002 6:43 AM > >>>>>To: hisham.khartabil@nokia.com > >>>>>Cc: jon.peterson@neustar.biz; sip@ietf.org > >>>>>Subject: Re: [Sip] SIPS question > >>>>> > >>>>>Hi, > >>>>> > >>>>> > >>>>> > >>>>>>>>>Hi, > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>I guess UA2 should have registered with P1 using > >>>>>>>>> > >>>>a sips-uri > >>>> > >>>> > >>>>>>>>>in the contact-header. P1 doesn't care about the > >>>>>>>>>contact-header sent in the 200 OK. UA2 contact-header is > >>>>>>>>>telling UA1 (not P1) to contact it using TLS. > >>>>>>>>> > >>>>>>>>>No, but the Contact header value will be used in requests > >>>>>>>>>during the session, as part of the route set or Request-URI > >>>>>>>>>(depending on if loose routing is used etc) > >>>>>>>> > >>>>>>>>What I meant to say is that if UA2 had registered with P1 > >>>>>>> > >>>>>>>using a sips-uri in the contact-header, then when P1 is > >>>>>>>routing the INVITE, it will put sips-uri in the record-route > >>>>>>>header since the request uri (retrieved from the registrar) > >>>>>>>is a sips-uri. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>Since P1 contacted UA2 using sips, the 200 ok must contain > >>>>>>> > >>>>>>>a contact-header with sips-uri. > >>>>>>> > >>>>>>>Ok. So, in this case UA1 will receive a Record-Route with > >>>>>>>SIPS-URI. So, the next time UA1 sends a request the SIPS-URI > >>>>>>>indicates it shall use TLS - which UA1 may not even support. > >>>>>> > >>>>>>No, P1 will modify the record-route header in the > >>>>> > >>>>response and will make > >>>> > >>>> > >>>>>it a sip-uri. > >>>>> > >>>>> > >>>>> > >>>>>>>And, since UA1 used SIP-URI in its own Contact header, P1 > >>>>>>>shall use UDP (or TCP) to forward requests received from UA2, > >>>>>>>so now we would have the separate-transport-in-each-direction > >>>>>>>problem between UA1 and P1, wouldn't we? > >>>>>> > >>>>>>UA1 will have a different route-set that UA2. > >>>>> > >>>>>True. > >>>>> > >>>>>However, EVEN if UA2 has registered itself with P1 using > >>>> > >>>>SIPS-URI, and P1 > >>>> > >>>> > >>>>>uses TLS to > >>>>>contact it, UA1 will still receive a Contact header with > >>>> > >>>>SIPS-URI, and > >>>> > >>>> > >>>>>according to the > >>>>>RFC ("if the Request-URI is SIPS-URI, TLS MUST be used") it > >>>> > >>>>would have to > >>>> > >>>> > >>>>>use TLS for the > >>>>>other requests, even if it doesn't support TLS, and even if > >>>> > >>>>the requests > >>>> > >>>> > >>>>>aren't even sent > >>>>>to UA2 (UA1 send them to P1, which record-routed). > >>>>> > >>>>>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 > >>>>> > >>>>>_______________________________________________ > >>>>>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 > > > > -- > 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 Sat Nov 2 17:49:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14056 for ; Sat, 2 Nov 2002 17:49:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA2MpCB26141 for sip-archive@odin.ietf.org; Sat, 2 Nov 2002 17:51:12 -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 gA2Moov26038; Sat, 2 Nov 2002 17:50: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 gA2Mnjv25942 for ; Sat, 2 Nov 2002 17:49:45 -0500 Received: from kevlar.softarmor.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13993 for ; Sat, 2 Nov 2002 17:47:13 -0500 (EST) Received: from kevlar.softarmor.com (kevlar.softarmor.com [127.0.0.1]) by kevlar.softarmor.com (8.12.5/8.12.5) with ESMTP id gA2MoQHF009962; Sat, 2 Nov 2002 16:50:26 -0600 Received: (from dwillis@localhost) by kevlar.softarmor.com (8.12.5/8.12.5/Submit) id gA2MoQbJ009960; Sat, 2 Nov 2002 16:50:26 -0600 X-Authentication-Warning: kevlar.softarmor.com: dwillis set sender to dean.willis@softarmor.com using -f Subject: Re: [Sip] WGLC (official) for scvrtdisco From: Dean Willis To: Rohan Mahy Cc: sip@ietf.org, jon.peterson@neustar.biz, Allison Mankin In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 02 Nov 2002 16:50:26 -0600 Message-Id: <1036277426.1374.89.camel@kevlar.softarmor.com> Mime-Version: 1.0 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 Oops -- administrative malfunction here. The document draft-willis-sip-scvrtdisco-06 was actually obsoleted by draft-ietf-sip-scvrtdisco-00, which we last called August 18 and is now in IETF Last Call. I seem to have, well, forgotten to delete the obsoleted draft from the tracking system, which accounts for it never having progressed beyond expert review. Sorry 'bout that. Unfortunately, there seems to be another administrative glitch, as the version that should be in IETF Last Call is -02, and they seem to have announced IETF Last Call on -01. I'll look into that. I WOULD like to point out that some changes gave been made to the draft during the pre-AD-review period -- we added discussion of using the double-recording trick for dual-homes proxies. So please DO pay attention to the IETF last call, ok? Thanks, -- Dean On Fri, 2002-11-01 at 11:46, Rohan Mahy wrote: > Hi Folks, > > According to my records, we did an expert review for scvrtdisco which > closed on May 22, but never did an official WGLC. Let's do an official > abbreviated WGLC for this document ending on Nov 8. > > The document is available at until it appears in the archive: > > http://www.softarmor.com/sipwg/drafts/draft-willis-sip-scvrtdisco-06.txt > > thanks, > -rohan > > _______________________________________________ > 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 Nov 4 06:57:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09908 for ; Mon, 4 Nov 2002 06:57:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4BxPf20903 for sip-archive@odin.ietf.org; Mon, 4 Nov 2002 06:59: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 gA4Bwav20851; Mon, 4 Nov 2002 06:58: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 gA4Bt4v20758 for ; Mon, 4 Nov 2002 06:55:04 -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 GAA09820 for ; Mon, 4 Nov 2002 06:52:36 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA4Bt1KV008512; Mon, 4 Nov 2002 12:55:01 +0100 (MET) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.112]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id gA4Bt0Zb022813; Mon, 4 Nov 2002 13:55:00 +0200 (EET) Message-ID: <3DC66014.3EDC9C47@lmf.ericsson.se> Date: Mon, 04 Nov 2002 13:55:00 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'Anders Kristensen'" , sip@ietf.org Subject: Re: [Sip] SIPS question References: <15A2739B7DAA624D8091C65981D7DA815EB36B@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 Hi, > >Also, it's not only about mid-session requests, even if that may be so in > >most cases. Assume the Request-URI for the initial INVITE is SIPS-URI, but > the > >UAC uses an outbound proxy, ie using a pre-configured Route with SIP-URI. > > The design of SIPS used as the 'remote target', as the AoR of the > destination, necessitates that this first hop go over TLS. Look, as I said, > outbound proxies are proxy servers, proxy servers MUST support TLS, and > entities that support TLS MUST support SIPS. Converting this Route header to > a TLS route is plausible and allowed by the spec. Yes, but the problem is again if the UAC doesn't support TLS. Assume the UAC gets the Request-URI SIPS-URI from some "external source" (ENUM, data base, whatever...), but since it uses an outbound proxy, using a predefined Route with SIP-URI, it doesn't care about the Request-URI SIPS-URI. I don't know if that scenario is "allowed" or not, but my point was that the problem would be the same as for mid-session requests. > We considered both transport parameters (transport=tls was obsoleted in > favor of SIPS, as I'm sure you recall) and Require/Supported option tags in > our deliberations about SIPS. The point is that we wanted a resource > identifier that indicates directly that it should be contacted securely. Another option would be that the URI in the TO header, which IS end-to-end, would be used to indicate if to use TLS or not. That would not allow that TLS is used between specific hops only, though. Now, however, TLS would be used for the mid-session requests EVEN if the record routing proxies insert SIP-URI in the Record-Route headers, and/or the UAC inserts SIP-URI in the Contact header, since the TO header URI would not change. Now TLS would always be used for the whole session, and not only for the INVITE, but I assume that is how most people intend to use it anyway. Or? But, I still think the easiest fix would be to change the text as proposed earlier. Then, we may have to write something about the outbound proxy scenario - or use Jonathan's proposal to use TLS only if the previous hop used TLS (assuming we want to use TLS end-to-end ONLY, that is). 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 Mon Nov 4 09:10:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13450 for ; Mon, 4 Nov 2002 09:10:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4ECup27611 for sip-archive@odin.ietf.org; Mon, 4 Nov 2002 09:12: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 gA4ECLv27596; Mon, 4 Nov 2002 09:12: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 gA4E8Fv27460 for ; Mon, 4 Nov 2002 09:08:15 -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 JAA13250 for ; Mon, 4 Nov 2002 09:05:45 -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 gA4E8cB25023 for ; Mon, 4 Nov 2002 16:08:38 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 4 Nov 2002 16:08:10 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 4 Nov 2002 16:08:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] SIPS question Date: Mon, 4 Nov 2002 16:08:09 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE6F6B@esebe019.ntc.nokia.com> Thread-Topic: [Sip] SIPS question Thread-Index: AcKD+vZ6l1ANQKicT6WZ6iEoOHMh1QADtlHA To: , Cc: , X-OriginalArrivalTime: 04 Nov 2002 14:08:10.0499 (UTC) FILETIME=[9B4FA530:01C2840B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA4E8Fv27461 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 Removing this restriction seems to fix the problem, I think. "Independent of which URI is used as input to the procedures of [4], if the Request-URI specifies a SIPS resource, the UAC MUST follow the procedures of [4] as if the input URI were a SIPS URI." But also, would mandating that: if a REGISTER has a sips-uri contact, the To-header must contain a sips-uri work? and visa versa? eg: UA2 registers with sips-uri in both To-header and contact-header (sips in both or neither, but not mixed). In this case, UA2 home proxy will reject the request with 404 if UA1 sends a request with sip-uri. UA2 can also reject the request directly if it doesn't want to accept requests not using TLS. Regards, Hisham > -----Original Message----- > From: ext Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Monday, November 04, 2002 1:55 PM > To: Peterson, Jon > Cc: 'Anders Kristensen'; sip@ietf.org > Subject: Re: [Sip] SIPS question > > > > Hi, > > > >Also, it's not only about mid-session requests, even if > that may be so in > > >most cases. Assume the Request-URI for the initial INVITE > is SIPS-URI, but > > the > > >UAC uses an outbound proxy, ie using a pre-configured > Route with SIP-URI. > > > > The design of SIPS used as the 'remote target', as the AoR of the > > destination, necessitates that this first hop go over TLS. > Look, as I said, > > outbound proxies are proxy servers, proxy servers MUST > support TLS, and > > entities that support TLS MUST support SIPS. Converting > this Route header to > > a TLS route is plausible and allowed by the spec. > > Yes, but the problem is again if the UAC doesn't support TLS. > Assume the UAC > gets the Request-URI SIPS-URI from some "external source" > (ENUM, data base, > whatever...), but since it uses an outbound proxy, using a > predefined Route with > SIP-URI, it doesn't care about the Request-URI SIPS-URI. > > I don't know if that scenario is "allowed" or not, but my > point was that the > problem would be the same as for mid-session requests. > > > We considered both transport parameters (transport=tls was > obsoleted in > > favor of SIPS, as I'm sure you recall) and > Require/Supported option tags in > > our deliberations about SIPS. The point is that we wanted a resource > > identifier that indicates directly that it should be > contacted securely. > > Another option would be that the URI in the TO header, which > IS end-to-end, > would be used to indicate if to use TLS or not. That would > not allow that TLS is > used between specific hops only, though. > > Now, however, TLS would be used for the mid-session requests > EVEN if the record > routing proxies insert SIP-URI in the Record-Route headers, > and/or the UAC > inserts SIP-URI in the Contact header, since the TO header > URI would not change. > > Now TLS would always be used for the whole session, and not > only for the INVITE, > but I assume that is how most people intend to use it anyway. Or? > > But, I still think the easiest fix would be to change the > text as proposed > earlier. Then, we may have to write something about the > outbound proxy scenario > - or use Jonathan's proposal to use TLS only if the previous > hop used TLS > (assuming we want to use TLS end-to-end ONLY, that is). > > 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 > _______________________________________________ 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 Nov 4 10:13:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17241 for ; Mon, 4 Nov 2002 10:13:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4FFBG31709 for sip-archive@odin.ietf.org; Mon, 4 Nov 2002 10:15: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 gA4FEkv31676; Mon, 4 Nov 2002 10:14: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 gA4F9Ov31303 for ; Mon, 4 Nov 2002 10:09:24 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16774; Mon, 4 Nov 2002 10:06:54 -0500 (EST) Message-Id: <200211041506.KAA16774@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: Mon, 04 Nov 2002 10:06:53 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-sec-agree-05.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 : Security Mechanism Agreement for the Session Initiation Protocol (SIP) Sessions Author(s) : J. Arkko et al. Filename : draft-ietf-sip-sec-agree-05.txt Pages : 25 Date : 2002-11-1 This document defines new functionality for negotiating the security mechanisms used between a Session Initiation Protocol (SIP) user agent and its next-hop SIP entity. This new functionality supplements the existing methods of choosing security mechanisms between SIP entities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-sec-agree-05.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-sec-agree-05.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-sec-agree-05.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: <2002-11-1143656.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-sec-agree-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-sec-agree-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-1143656.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 Mon Nov 4 22:16:52 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20896 for ; Mon, 4 Nov 2002 22:16:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA53Ivm28153 for sip-archive@odin.ietf.org; Mon, 4 Nov 2002 22:18: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 gA53IGv28135; Mon, 4 Nov 2002 22:18: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 gA53GQv28082 for ; Mon, 4 Nov 2002 22:16:26 -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 WAA20838 for ; Mon, 4 Nov 2002 22:13:50 -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 gA53FKnX006001 for ; Mon, 4 Nov 2002 22:15:21 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Nov 2002 21:16:17 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A642E6@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'sip@ietf.org'" Date: Mon, 4 Nov 2002 21:16:16 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RFC3265 (SIP Events) bugs now in bugzilla 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've now entered all of the SIP Events bugs that I know about into the working group bugzilla tracking system. If you have a moment or two and know of a bug in 3265, head over to http://www.sipwg.org/ and make sure that it's been documented. I don't think I've missed anything, but I'd hate to leave a known problem off the list. Send e-mail directly to me if a missing bug has already been discussed on an IETF mailing list. Send e-mail to the working group list if you know of a bug that hasn't yet been publicly discussed. Thanks! /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 Tue Nov 5 06:29:46 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12726 for ; Tue, 5 Nov 2002 06:29:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5BViX02591 for sip-archive@odin.ietf.org; Tue, 5 Nov 2002 06:31: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 gA5BVQv02579; Tue, 5 Nov 2002 06:31: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 gA5BE3v01075 for ; Tue, 5 Nov 2002 06:14:03 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11389; Tue, 5 Nov 2002 06:11:32 -0500 (EST) Message-Id: <200211051111.GAA11389@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, 05 Nov 2002 06:11:32 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-compression-02.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 : Compressing the Session Initiation Protocol Author(s) : G. Camarillo Filename : draft-ietf-sip-compression-02.txt Pages : 12 Date : 2002-11-4 This document describes a mechanism to signal that compression is desired for one or more SIP messages. It also states when it is appropriate to send compressed SIP messages to a SIP entity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-compression-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-compression-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-compression-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-4172649.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-compression-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-compression-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-4172649.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 Nov 5 06:32:50 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12912 for ; Tue, 5 Nov 2002 06:32:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5BYnx02969 for sip-archive@odin.ietf.org; Tue, 5 Nov 2002 06:34: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 gA5BYUv02953; Tue, 5 Nov 2002 06: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 gA5BE7v01081 for ; Tue, 5 Nov 2002 06:14:07 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11406; Tue, 5 Nov 2002 06:11:38 -0500 (EST) Message-Id: <200211051111.GAA11406@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, 05 Nov 2002 06:11:37 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-scvrtdisco-02.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-02.txt Pages : 16 Date : 2002-11-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-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-scvrtdisco-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-scvrtdisco-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-4172659.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-scvrtdisco-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-scvrtdisco-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-4172659.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 Nov 5 07:10:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14551 for ; Tue, 5 Nov 2002 07:10:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5CC5706071 for sip-archive@odin.ietf.org; Tue, 5 Nov 2002 07:12: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 gA5CBZv06046; Tue, 5 Nov 2002 07:11: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 gA5C96v05956 for ; Tue, 5 Nov 2002 07:09:06 -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 HAA14429 for ; Tue, 5 Nov 2002 07:06:37 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA5C93Q1011158; Tue, 5 Nov 2002 13:09:03 +0100 (MET) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.51]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id gA5C93Zb002777; Tue, 5 Nov 2002 14:09:03 +0200 (EET) Message-ID: <3DC7B4DD.89A1798@lmf.ericsson.se> Date: Tue, 05 Nov 2002 14:09:01 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rohan Mahy CC: sip@ietf.org Subject: Re: [Sip] WGLC on draft-ietf-sip-compression-02.txt References: <75C8D55B-EDBA-11D6-98BC-0003938AF740@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 Hi, The issue with the size of the dictionary does not belong to this draft. It belongs to the static dictionary draft, and it was resolved in SIPPING already. Thanks, Gonzalo Rohan Mahy wrote: > > Hi, > > I'd like to start an abbreviated WGLC on > draft-ietf-sip-compression-02.txt. Until it appears in the archive, > please access it here: > > http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-compression-02.txt > > This draft has one known open issue which is being discussed on the > list now (whether the ~8k static SIP dictionary is mandatory or > optional). > > As the draft is short and seems uncontroversial, WGLC will close on Nov > 12. Please note that WGLC will probably overlap significantly with > IETF LC for this draft. > > thanks, > -rohan > > _______________________________________________ > 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 -- 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 Tue Nov 5 14:45:43 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08384 for ; Tue, 5 Nov 2002 14:45:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5Jljw04453 for sip-archive@odin.ietf.org; Tue, 5 Nov 2002 14:47: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 gA5JkJv04411; Tue, 5 Nov 2002 14:46: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 gA5Jisv04359 for ; Tue, 5 Nov 2002 14:44:54 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08084 for ; Tue, 5 Nov 2002 14:42:21 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gA5Jinm6000255 for ; Tue, 5 Nov 2002 14:44:49 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gA5JilH9005722 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 5 Nov 2002 14:44:48 -0500 (EST) Message-ID: <3DC8200C.1090900@cs.columbia.edu> Date: Tue, 05 Nov 2002 14:46:20 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016 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] PDF versions of SIP RFCs available 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 PDF versions of some of the SIP RFCs, including RFC 3261-65, are available at http://www.cs.columbia.edu/sip/drafts.html. RFC 3261-65 were converted from the nroff source provided by the RFC editor. A Perl script kindly provided by Jonathan Lennox did the rough conversion back into LaTeX, followed by a fair amount of hand-editing. (It would be nice if the RFC editor would use a more information-preserving semantic mark-up format rather than visual nroff mark-up.) Gonzalo Camarillo converted RFC 3312. There are likely formatting mistakes left; please let me know if you find any. Henning _______________________________________________ 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 Nov 5 16:25:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15824 for ; Tue, 5 Nov 2002 16:25:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5LRv110452 for sip-archive@odin.ietf.org; Tue, 5 Nov 2002 16:27: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 gA5LRPv10418; Tue, 5 Nov 2002 16:27: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 gA5LOZv10310 for ; Tue, 5 Nov 2002 16:24:35 -0500 Received: from mail.trinityconvergence.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15577 for ; Tue, 5 Nov 2002 16:22:01 -0500 (EST) Received: from DBX09611 [64.90.17.177] by mail.trinityconvergence.com with ESMTP (SMTPD32-7.12) id A70C3E400F4; Tue, 05 Nov 2002 16:24:28 -0500 From: "Christopher P Rigano" To: Date: Tue, 5 Nov 2002 16:21:49 -0500 Message-ID: <00d201c28511$5d72ad50$2302020a@DBX09611> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D3_01C284E7.749CA550" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: [Sip] SIP Positions 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_00D3_01C284E7.749CA550 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Greetings, Had the opportunity to work on a SIP project in RTP NC and it was one of the most enjoyable experiences I've had. As it has come to an end, I am wondering if there is an information base or other resource I could use to find SIP projects with openings in the RTP area. Many thanks, CPR ------=_NextPart_000_00D3_01C284E7.749CA550 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings,

 

Had the opportunity to work on a SIP project in = RTP= = NC= and it was one of the most enjoyable experiences I’ve had. As it has come to = an end, I am wondering if there is an information base or other resource I could = use to find SIP projects with openings in the RTP = area.

 

Many thanks,

 

CPR

------=_NextPart_000_00D3_01C284E7.749CA550-- _______________________________________________ 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 Nov 5 16:35:15 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16448 for ; Tue, 5 Nov 2002 16:35:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5LbIY11332 for sip-archive@odin.ietf.org; Tue, 5 Nov 2002 16:37: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 gA5Lauv10881; Tue, 5 Nov 2002 16:36: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 gA5LYhv10771 for ; Tue, 5 Nov 2002 16:34:43 -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 QAA16230 for ; Tue, 5 Nov 2002 16:32:09 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.70]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gA5LYbYH024943; Tue, 5 Nov 2002 16:34:38 -0500 (EST) Message-ID: <3DC8396C.6010805@dynamicsoft.com> Date: Tue, 05 Nov 2002 16:34:36 -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: Christopher P Rigano CC: sip@ietf.org Subject: Re: [Sip] SIP Positions References: <00d201c28511$5d72ad50$2302020a@DBX09611> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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 Well, this is not really the right subject for this list, but pulver collects ip telephony jobs (http://www.pulver.com) and his shows are often used as a grounds for job hunting. -Jonathan R. Christopher P Rigano wrote: > Greetings, > > > > Had the opportunity to work on a SIP project in RTP NC and it was one of > the most enjoyable experiences I’ve had. As it has come to an end, I am > wondering if there is an information base or other resource I could use > to find SIP projects with openings in the RTP area. > > > > Many thanks, > > > > CPR > -- 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 Nov 5 17:19:26 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20166 for ; Tue, 5 Nov 2002 17:19:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5MLTp14591 for sip-archive@odin.ietf.org; Tue, 5 Nov 2002 17:21:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5ML4v14563; Tue, 5 Nov 2002 17:21: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 gA5MI7v14341 for ; Tue, 5 Nov 2002 17:18:07 -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 RAA19788 for ; Tue, 5 Nov 2002 17:15:32 -0500 (EST) Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.11.6) id gA5MI1g49916; Tue, 5 Nov 2002 17:18:01 -0500 (EST) Reply-To: From: "Brett Tate" To: "sip-ietf \(E-mail\)" Date: Tue, 5 Nov 2002 17:18:14 -0500 Message-ID: <003801c28519$3c6fc630$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: <9BF66EBF6BEFD942915B4D4D45C051F3A642E7@DYN-TX-EXCH-001.dynamicsoft.com> Content-Transfer-Encoding: 7bit Subject: [Sip] RE: [Sip-implementors] Questions about 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 Moving the thread to the SIP list to ensure that this is correct understanding and direction of the sip specifications. The thread deals with calls and subscriptions which sharing the same dialog. It covers 4 main topics: A) Which events and responses can retarget a dialog by supplying a new Contact? Current answer: INVITE, UPDATE, SUBSCRIBE, NOTIFY, their 2xx responses, and INVITE 101-199 responses. B) What is the best way to resolve retargeting race conditions? Current answer: assume no retries occurred and always use last received. C) Does a received 481 trigger the releasing of call and all subscriptions on the dialog? Current answer: yes. D) Can a call be established on a dialog which currently only has subscriptions? Current answer: yes. The rest of this email is in response to one of the emails on sip-implementors. ------- > > 1a) It makes the presence of a To-tag no > > longer sufficient enough to distinguish > > an invite from re-invite. > > In my experience, that's never really been > all that useful. It is useful for proxies and B2BUA's. > You always have session state > for ongoing sessions; you can use its absence > or presence to determine whether an INVITE > is a re-INVITE. After a restart, the dialog state cannot be trusted by proxy or B2BUA. A B2BUA sending a re-invite to audit the dialog might be interpreted as a new call at the UAS. This would especially be true if the UAS allows subscriptions to be remembered or revived after a restart. Another aspect is the following: A subscribes B. A calls B on the dialog. A sends BYE and receives INVITE prior to BYE's 200 response. Should A assume this was re-invite or a call back? Because of udp retries the wrong decision might be made by the UAS or proxy. Another aspect is the following: A subscribes B. A calls B on the dialog. A sends BYE. B or proxy sends a failure response. B sends INVITE to A. Should A and proxies treat this as an invite or re-invite? > > 1b) How does a 481 response to an INVITE > > over a subscription dialog effect the > > subscription dialog? > > Consistency dictates that it would remove > the subscription. This should be clarified. > I've opened a bug. I guess the sending of a 481 to a NOTIFY, also triggers a release of a call and cancellation of all subscriptions (both directions) on the dialog. > > Should a 2xx invite response Contact take > > precedence over a just received SUBSCRIBE? > > Depends on which you receive last. Received last does not guarantee sent last. > > How do we know which was actually sent > > first by the called party? > > Should a 2xx INVITE response Contact take > precedence over a just received INVITE? > How do we know which was actually sent > first by the called party? > It's the same question. It isn't the same question since a dialog only supports 1 outstanding INVITE; otherwise a 491 is triggered. However the UPDATE without sdp might have the same problem. > > Without timestamping all requests and > > responses, one solution for all > > these race conditions is to immediately > > try multiple locations to resolve the > > ambiguity. > > Or you could just refrain from retargeting > ever few milliseconds like you're hopped up on > PCP. :) I agree. However I'm not sure how all devices intend to retarget during mobility, fault, and load triggered situations. > To be fair, there are some corner cases that > can pop up. As I point out above with the > INVITE/INVITE response problem above, though, > these dialog handling problems are problems > with the base spec, not the extensions. We should > probably have a discussion about this particular > race condition on the SIP list. _______________________________________________ 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 Nov 5 21:55:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06831 for ; Tue, 5 Nov 2002 21:55:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA62vkR29825 for sip-archive@odin.ietf.org; Tue, 5 Nov 2002 21: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 gA62v8v29803; Tue, 5 Nov 2002 21:57: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 gA62thv29762 for ; Tue, 5 Nov 2002 21:55:43 -0500 Received: from acmepacket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06738 for ; Tue, 5 Nov 2002 21:53:07 -0500 (EST) Received: from BPenfield [127.0.0.1] by acmepacket.com (SMTPD32-7.07) id A4A68B5001A0; Tue, 05 Nov 2002 21:55:34 -0500 Message-ID: <001001c2853f$f1e5d380$2300000a@BPenfield> From: "Bob Penfield" To: Subject: Re: [Sip] WGLC (official) for scvrtdisco Date: Tue, 5 Nov 2002 21:55:20 -0500 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.2720.3000 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 The draft mentions the Path header (twice) in section 6.2: "While in itself harmless, this complicates matters for nodes that use the recorded route vector (or recorded Path vector) in the determination of a service route for future use." and "Instead of following the procedure in RFC 3261 [4], proxies used with Service-Route that are inserting Record-Route or Path header field values SHOULD record not one but two route values when processing the request." There is no reference to the Path draft/RFC. Should it say Service-Route vector/header instead? However, given the SHOULD NOT about proxies modifying the Service-Route header, Path might be correct, but the discussion seems to be more appropriate to the Path draft/RFC. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.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 Nov 6 01:09:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12203 for ; Wed, 6 Nov 2002 01:09:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA66BQf08612 for sip-archive@odin.ietf.org; Wed, 6 Nov 2002 01:11: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 gA66B4v08599; Wed, 6 Nov 2002 01:11: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 gA669Mv08546 for ; Wed, 6 Nov 2002 01:09:22 -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 BAA12163 for ; Wed, 6 Nov 2002 01:06:42 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA6694KV008682; Wed, 6 Nov 2002 07:09:04 +0100 (MET) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.51]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id gA6692Zb021202; Wed, 6 Nov 2002 08:09:03 +0200 (EET) Message-ID: <3DC8B1FE.50B3899A@lmf.ericsson.se> Date: Wed, 06 Nov 2002 08:09:02 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: Jonathan Rosenberg , Bob Penfield , Jiri Kuthan , Jiri Kuthan , manoj mallik , sip , tomimura@sei.co.jp, alan.johnston@wcom.com References: <475FF955A05DD411980D00508B6D5FB00439EB2B@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Sipping] Tags in respones to CANCEL WAS: Re: Question aboutSection 3.8 ofdraft-ietf-sipping-basic-call-flows-01.txt(Eiji Tomimura) 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 Keith, You are actually right. I have moved this thread to SIP now. Thanks, Gonzalo "Drage, Keith (Keith)" wrote: > > Hang on. You are discussing a set of example flows on the sipping list. > > That discussion should not be used to rewrite SIP. > > The example flows should merely show an example of what is legitimate in RFC 3261. > > If you think RFC 3261 needs fixing, then it should be discussed on the SIP list, which an appropriate bug fix finally agreed and listed. > > Keith > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: 05 November 2002 15:34 > > To: Jonathan Rosenberg > > Cc: Bob Penfield; Jiri Kuthan; Jiri Kuthan; manoj mallik; > > sipping@ietf.org; tomimura@sei.co.jp; alan.johnston@wcom.com > > Subject: Re: [Sipping] Tags in respones to CANCEL WAS: Re: Question > > about Section 3.8 ofdraft-ietf-sipping-basic-call-flows-01.txt(Eiji > > Tomimura) > > > > > > Hi, > > > > Let's try to finish this discussion. Summarizing: > > > > Should the 200 OK responses to CANCEL have a To tag? > > > > Reasons for NO: > > > > CANCEL is hop-by-hop, and therefore, 200 OK responses for CANCEL are > > also hop-by-hop. If we look at 100 Trying responses, which are > > hop-by-hop as well, we see that they do not have a tag. > > > > Reasons for YES: > > > > Final responses to any request have tags. Even non-2xx final responses > > for INVITE, which are hop-by-hop, have a tag. > > > > Note that user agents and proxies will have to be prepared to receive > > 200 OK responses for CANCEL with or without tags anyway, to improve > > interoperability. So, this is not a big deal after all. Our > > decision is > > only useful as long as it helps develop a coherent spec. > > > > > > I would suggest to go for YES, document it, and move on. > > > > Comments? > > > > Thanks, > > > > Gonzalo > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > _______________________________________________ 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 Nov 6 03:23:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08837 for ; Wed, 6 Nov 2002 03:23:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA68P8C25074 for sip-archive@odin.ietf.org; Wed, 6 Nov 2002 03:25: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 gA68Ofv24999; Wed, 6 Nov 2002 03:24: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 gA68NBv24929 for ; Wed, 6 Nov 2002 03:23:12 -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 DAA08751 for ; Wed, 6 Nov 2002 03:20:30 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA68NQB21403 for ; Wed, 6 Nov 2002 10:23:26 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 6 Nov 2002 10:22:55 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Nov 2002 10:22:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 6 Nov 2002 10:22:55 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE6F84@esebe019.ntc.nokia.com> Thread-Topic: [Sip-implementors] Questions about Dialogs Thread-Index: AcKFAyH1LEJMaaTkQLuhYEl2I63EPQAaPBhQ To: , Cc: X-OriginalArrivalTime: 06 Nov 2002 08:22:56.0616 (UTC) FILETIME=[B5B36E80:01C2856D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA68NCv24930 Subject: [Sip] RE: [Sip-implementors] Questions about 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: 8bit redirected to sip... > -----Original Message----- > From: ext Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Tuesday, November 05, 2002 9:40 PM > To: Khartabil Hisham (NMP/Helsinki); Adam Roach; > sip-implementors@cs.columbia.edu > Cc: brett@broadsoft.com > Subject: RE: [Sip-implementors] Questions about Dialogs > > > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > > > May I suggest that we only allow target refresh requests to > > have the same method as the request that created the dialog. > > i.e.: only a reINVITE can be target refresh requests for a > > dialog created by INVITE, only reSUBSCRIBE can be target > > refresh requests for a dialog created by SUBSCRIBE. > > > > For a dialog created by INVITE, a SUBSCRIBE does not update > > the target. For a dialog created by SUBSCRIBE, an INVITE does > > not update the target. > > > > This is the only way to do it to avoid complexity and > > confusion. Otherwise you got to start asking about REFER and > > other extensions that create dialogs. > > > > I would prefer implementors to be able to build a generic > > dialogs module in their stack that doesn't need to know about > > methods. I mean what if I send a MESSAGE within a dialog? my > > generic dialogs module no longer can be method agnostic > > because it has to know that MESSAGE does not refresh a > > target, but it has to know that SUBSCRIBE does... too complicated. > > How does your generic dialogs module know not to create a dialog > when you send a MESSAGE that doesn't correspond to an existing > dialog? Its up to the user of the module to know. Like a session module on top of it. I don't want to update my dialogs module for every extension. I'll just build modules on top of it. Anyway, this is too much architecture stuff. > > You already need to keep track of a variety of attributes for > each method, such as which messages can start a dialog and which > can't; in other words, you can't have generic handling for > unknown methods. You must assign them attributes before your > dialog manager can do anything sensible. > > Tracking which method initiated a dialog is no more complicated > than tracking which methods can retarget. > > That said, allowing only the initiating method to retarget can be > a rather severe restriction. I may have application logic that > knows that it needs to retarget at some point, and it does > so by sending an INVITE. However, with your proposal, that > would fail if the dialog had been created with a SUBSCRIBE*. > Instead, you'd need the application to keep track of which came > first and use it for retargeting. Now, that seems messy. > > /a > > * What? How would one plausibly get an INVITE on a dialog > created by a SUBSCRIBE, you ask? I'm glad you did. Imagine > that I've subscribed to the terminal state of the phone > on your desk, because I want to get ahold of you as soon > as you get off the phone. When I finally get a NOTIFY to > let me know that your terminal has transitioned to a "free" > state (i.e. on-hook), I want to send an INVITE. Of course, > I want to make sure I only contact that one terminal that > just became free. The only way I can reliably do this is > by sending an INVITE in the same dialog. There you go. This example doesn't clarify the need for an INVITE to retarget a dialog initiated with a SUBSCRIBE. Its actually saying that an INVITE needs to use the same target that was established with the SUBSCRIBE. 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 Wed Nov 6 06:43:15 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13486 for ; Wed, 6 Nov 2002 06:43:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA6BjFG05426 for sip-archive@odin.ietf.org; Wed, 6 Nov 2002 06:45: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 gA6Bhlv05230; Wed, 6 Nov 2002 06:43: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 gA6BYbv04093 for ; Wed, 6 Nov 2002 06:34:37 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12809; Wed, 6 Nov 2002 06:32:05 -0500 (EST) Message-Id: <200211061132.GAA12809@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, 06 Nov 2002 06:32:05 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-dhcpv6-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 : DHCPv6 Options for SIP Servers Author(s) : H. Schulzrinne, B. Volz Filename : draft-ietf-sip-dhcpv6-01.txt Pages : 7 Date : 2002-11-5 This document defines a DHCPv6 option that contains a list of domain names or IPv6 addresses that can be mapped to one or more SIP outbound proxy servers. This is one of the many methods that a SIP client can use to obtain the addresses of such a local SIP server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-dhcpv6-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-dhcpv6-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-dhcpv6-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: <2002-11-5193611.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-dhcpv6-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-dhcpv6-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-5193611.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 Nov 6 06:51:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13844 for ; Wed, 6 Nov 2002 06:51:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA6BrIT05798 for sip-archive@odin.ietf.org; Wed, 6 Nov 2002 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 gA6Bqwv05769; Wed, 6 Nov 2002 06:52: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 gA6Bo2v05647 for ; Wed, 6 Nov 2002 06:50:02 -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 GAA13666 for ; Wed, 6 Nov 2002 06:47:31 -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 gA6BnxU26846 for ; Wed, 6 Nov 2002 06:49:59 -0500 (EST) Received: by en0060D057.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Nov 2002 11:49:58 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00696E386@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Gonzalo Camarillo , "Drage, Keith (Keith)" Cc: Jonathan Rosenberg , Bob Penfield , Jiri Kuthan , Jiri Kuthan , manoj mallik , sip , tomimura@sei.co.jp, alan.johnston@wcom.com Date: Wed, 6 Nov 2002 11:49:57 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Sip] RE: [Sipping] Tags in respones to CANCEL WAS: Re: Question about Section 3.8 ofdraft-ietf-sipping-basic-call-flows-01.txt(Eiji Tomimur a) 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: , Having had trouble in the past with implementors following the examples rather than the core specification (not in IETF) I believe we could usefully strengthen statements in all these example documents. I would suggest something along the lines of: "The flows in this document represent specific examples of behaviour that is possible using RFC 3261 [list other RFCs whose functionality is used]. Other behaviours are possible and may be more or less appropriate depending on the application that is being implemented. This document does not modify or enhance in any manner the requirements of RFC 3261 [list other RFCs], and reference should always be made to those specifications to resolve questions of required behaviour." is added in a prominent place in all the example flow documents. I believe there is an important place for example flows, and I certainly still have some difficulting interpreting some bits of RFC 3261 despite the massive improvement given by the rewrite (the usage of the Contact header for example), so do not take this comment as in any way trying to downgrade the importance of these documents. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: 06 November 2002 06:09 > To: Drage, Keith (Keith) > Cc: Jonathan Rosenberg; Bob Penfield; Jiri Kuthan; Jiri Kuthan; manoj > mallik; sip; tomimura@sei.co.jp; alan.johnston@wcom.com > Subject: Re: [Sipping] Tags in respones to CANCEL WAS: Re: Question > aboutSection 3.8 ofdraft-ietf-sipping-basic-call-flows-01.txt(Eiji > Tomimura) > > > Keith, > > You are actually right. I have moved this thread to SIP now. > > Thanks, > > Gonzalo > > "Drage, Keith (Keith)" wrote: > > > > Hang on. You are discussing a set of example flows on the > sipping list. > > > > That discussion should not be used to rewrite SIP. > > > > The example flows should merely show an example of what is > legitimate in RFC 3261. > > > > If you think RFC 3261 needs fixing, then it should be > discussed on the SIP list, which an appropriate bug fix > finally agreed and listed. > > > > Keith > > > > Keith Drage > > Lucent Technologies > > Tel: +44 1793 776249 > > Email: drage@lucent.com > > > > > -----Original Message----- > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > Sent: 05 November 2002 15:34 > > > To: Jonathan Rosenberg > > > Cc: Bob Penfield; Jiri Kuthan; Jiri Kuthan; manoj mallik; > > > sipping@ietf.org; tomimura@sei.co.jp; alan.johnston@wcom.com > > > Subject: Re: [Sipping] Tags in respones to CANCEL WAS: > Re: Question > > > about Section 3.8 > ofdraft-ietf-sipping-basic-call-flows-01.txt(Eiji > > > Tomimura) > > > > > > > > > Hi, > > > > > > Let's try to finish this discussion. Summarizing: > > > > > > Should the 200 OK responses to CANCEL have a To tag? > > > > > > Reasons for NO: > > > > > > CANCEL is hop-by-hop, and therefore, 200 OK responses for > CANCEL are > > > also hop-by-hop. If we look at 100 Trying responses, which are > > > hop-by-hop as well, we see that they do not have a tag. > > > > > > Reasons for YES: > > > > > > Final responses to any request have tags. Even non-2xx > final responses > > > for INVITE, which are hop-by-hop, have a tag. > > > > > > Note that user agents and proxies will have to be > prepared to receive > > > 200 OK responses for CANCEL with or without tags anyway, > to improve > > > interoperability. So, this is not a big deal after all. Our > > > decision is > > > only useful as long as it helps develop a coherent spec. > > > > > > > > > I would suggest to go for YES, document it, and move on. > > > > > > Comments? > > > > > > Thanks, > > > > > > Gonzalo > > > _______________________________________________ > > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > _______________________________________________ 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 Nov 6 10:32:29 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26900 for ; Wed, 6 Nov 2002 10:32:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA6FYUC21008 for sip-archive@odin.ietf.org; Wed, 6 Nov 2002 10:34: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 gA6FXiv20980; Wed, 6 Nov 2002 10:33: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 gA6FVMv20795 for ; Wed, 6 Nov 2002 10:31:22 -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 KAA26667 for ; Wed, 6 Nov 2002 10:28:50 -0500 (EST) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id gA6FcTWr013139; Wed, 6 Nov 2002 09:38:30 -0600 From: "Dean Willis" To: "'Bob Penfield'" , Subject: RE: [Sip] WGLC (official) for scvrtdisco Date: Wed, 6 Nov 2002 09:31:13 -0600 Message-ID: <008301c285a9$8b1d36b0$30e00cd8@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <001001c2853f$f1e5d380$2300000a@BPenfield> 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 Yes, we should add a reference to the Path draft. This can be easily done in Authors 48 if we don't have any other changes that necessitate a revision before then -- and by then, we would hope that Path (currently in RFC Editor Queue) has an RFC number. Good catch. -- Dean > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Bob Penfield > Sent: Tuesday, November 05, 2002 8:55 PM > To: sip@ietf.org > Subject: Re: [Sip] WGLC (official) for scvrtdisco > > > The draft mentions the Path header (twice) in section 6.2: > > "While in itself harmless, this complicates matters for > nodes that use > the recorded route vector (or recorded Path vector) in the > determination of a service route for future use." > > and > > "Instead of following the procedure in RFC 3261 [4], > proxies used with > Service-Route that are inserting Record-Route or Path header field > values SHOULD record not one but two route values when > processing the > request." > > There is no reference to the Path draft/RFC. Should it say > Service-Route vector/header instead? However, given the > SHOULD NOT about proxies modifying the Service-Route header, > Path might be correct, but the discussion seems to be more > appropriate to the Path draft/RFC. > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.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 Nov 6 11:24:06 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00106 for ; Wed, 6 Nov 2002 11:24:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA6GQ7t25245 for sip-archive@odin.ietf.org; Wed, 6 Nov 2002 11:26: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 gA6GPbv25214; Wed, 6 Nov 2002 11:25: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 gA6GMqv25070 for ; Wed, 6 Nov 2002 11:22:52 -0500 Received: from tnint11.telogy.design.ti.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00012; Wed, 6 Nov 2002 11:20:19 -0500 (EST) Received: by tnint11.telogy.design.ti.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Nov 2002 11:20:12 -0500 Message-ID: <37A3C2F21006D611995100B0D0F9B73C012A2C89@tnint11.telogy.design.ti.com> From: "Yadavalli, Satyamurthy" To: "'sipping@ietf.org'" , sip-implementors@cs.columbia.edu Cc: "'sip@ietf.org'" Date: Wed, 6 Nov 2002 11:20:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: [Sip-implementors] "Early Media" 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 figure out that a discussion on this issue occured earlier with proposals to use 183 Session Progress etc., (Subject: "[Sip] Local vs. Remote ringback on 180") Was a conclusion reached and was it incorporated into any (draft) RFC? -Satya > -----Original Message----- > From: Yadavalli, Satyamurthy [mailto:syadavalli@telogy.com] > Sent: Sunday, November 03, 2002 12:56 AM > To: 'sipping@ietf.org'; sip-implementors@cs.columbia.edu > Subject: [Sip-implementors] "Early Media" > > > Hi, > Would like to know how to achieve the following using any of > the SIP related > RFCs: > > UA1 invites UA2. Say UA2 generates a local ringing tone (or > some audio) to > alert its user. However, UA2 woud like to feed some (ringing) > audio back to > UA1 (in addition to the 180 RINGING response). And also say > UA2 may like its > early media to be overriding any locally generated ringback > that UA1 may be > generating to its user about the call in progress. > > This 'early media' may have its own characteristics such as codec > requirements etc., different from those of the final > dialogue. How (ofcourse > via an SDP but attached to which SIP response: 180?) are these to be > described by UA2 to UA1 so that UA1 may load the necessary > codecs etc., so > as to be able to present the early media (to be received from > UA2) to its > user. And also how to indicate when the audio path (RTP) for > this early > media is to be established/released. > > Is there any RFC that describes how to provide this kind of > 'subdialogue' > before the actual SIP dialogue is established? A quick glance > at the UPDATE > RFC appeared to somewhat support this kind of requirement but > appeared (at > first glance) to specify the main dialogue itself and didnot appear to > clearly say when to establish/release this 'subdialogue'. > > Appreciate any help in this regard, > Thanks, > Satya > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ 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 Nov 6 12:50:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04077 for ; Wed, 6 Nov 2002 12:50:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA6HqVJ31792 for sip-archive@odin.ietf.org; Wed, 6 Nov 2002 12:52: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 gA6Hpov31733; Wed, 6 Nov 2002 12:51: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 gA6Hohv31653 for ; Wed, 6 Nov 2002 12:50:43 -0500 Received: from web14205.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03923 for ; Wed, 6 Nov 2002 12:48:09 -0500 (EST) Message-ID: <20021106175037.83611.qmail@web14205.mail.yahoo.com> Received: from [136.182.2.222] by web14205.mail.yahoo.com via HTTP; Wed, 06 Nov 2002 09:50:37 PST Date: Wed, 6 Nov 2002 09:50:37 -0800 (PST) From: Lei Yu To: sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1362211306-1036605037=:83600" Subject: [Sip] Question about hostname's BNF definition 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: , --0-1362211306-1036605037=:83600 Content-Type: text/plain; charset=us-ascii Hi, Everyone, I have 2 questions related to BNF definition for hostname. Here is the part from RFC3261: " hostname = *( domainlabel "." ) toplabel [ "." ] domainlabel = alphanum / alphanum *( alphanum / "-" ) alphanum toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum " And here are my 2 questions: (1). Based on the BNF definition for hostname, a "." at the end is legal which means the following string is a legal hostname: "company.com." This is wrong, right? No "." should be allowed at the end of hostname. (2). Based on the different definition for domainlable and toplable, toplable does not alow token starts with DIGIT. Why is that? Thanks. Lei Yu Software Engineer Motorola --------------------------------- Do you Yahoo!? HotJobs - Search new jobs daily now --0-1362211306-1036605037=:83600 Content-Type: text/html; charset=us-ascii Hi, Everyone,
I have 2 questions related to BNF definition for
hostname. Here is the part from RFC3261:
"
hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum
/ alphanum *( alphanum / "-" ) alphanum
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
"
And here are my 2 questions:
(1). Based on the BNF definition for hostname,
a "." at the end is legal which means the following
string is a legal hostname:
"company.com."
This is wrong, right? No "." should be allowed
at the end of hostname.
(2). Based on the different definition for
domainlable and toplable, toplable does not alow
token starts with DIGIT. Why is that?


Thanks.

Lei Yu
Software Engineer
Motorola


Do you Yahoo!?
HotJobs - Search new jobs daily now --0-1362211306-1036605037=:83600-- _______________________________________________ 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 Nov 6 13:33:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05851 for ; Wed, 6 Nov 2002 13:33:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA6IZEF02167 for sip-archive@odin.ietf.org; Wed, 6 Nov 2002 13: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 gA6IYhv02090; Wed, 6 Nov 2002 13:34: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 gA6IX8v01953 for ; Wed, 6 Nov 2002 13:33: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 NAA05768 for ; Wed, 6 Nov 2002 13:30:34 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gA6IWmxF016269; Wed, 6 Nov 2002 10:32:48 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAN19381; Wed, 6 Nov 2002 10:27:09 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA13823; Wed, 6 Nov 2002 10:32:55 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15817.24662.879281.25692@thomasm-u1.cisco.com> Date: Wed, 6 Nov 2002 10:32:54 -0800 (PST) To: Jonathan Rosenberg Cc: "Peterson, Jon" , "'Anders Kristensen'" , sip@ietf.org Subject: Re: [Sip] SIPS question In-Reply-To: <3DC43776.4070500@dynamicsoft.com> References: <15A2739B7DAA624D8091C65981D7DA815EB364@stntexch2.va.neustar.com> <3DC43776.4070500@dynamicsoft.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 Jonathan Rosenberg writes: > I think we have lost sight of the semantics of SIPS. > > To me, SIPS is a way to tell a UA that ***the entire path*** was > hop-by-hop secured. If a UA cannot know this with certainty, How could a UA ever know this for certain? It looks to me that the best a UA can do is hope. 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 From mailnull@www1.ietf.org Wed Nov 6 14:39:49 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08715 for ; Wed, 6 Nov 2002 14:39:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA6JfpK06837 for sip-archive@odin.ietf.org; Wed, 6 Nov 2002 14:41: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 gA6JfGv06808; Wed, 6 Nov 2002 14:41: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 gA6JdIv06645 for ; Wed, 6 Nov 2002 14:39:18 -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 OAA08629 for ; Wed, 6 Nov 2002 14:36:45 -0500 (EST) Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.11.6) id gA6JdD508963; Wed, 6 Nov 2002 14:39:13 -0500 (EST) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] Question about hostname's BNF definition Date: Wed, 6 Nov 2002 14:39:26 -0500 Message-ID: <000201c285cc$380b9160$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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <20021106175037.83611.qmail@web14205.mail.yahoo.com> 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 have 2 questions related to BNF definition > for hostname. Here is the part from RFC3261: > > hostname = *( domainlabel "." ) toplabel [ "." ] > domainlabel = alphanum / alphanum *( alphanum / "-" ) alphanum > toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum > > And here are my 2 questions: > (1). Based on the BNF definition for hostname, > a "." at the end is legal which means the following > string is a legal hostname: > "company.com." > This is wrong, right? No "." should be allowed > at the end of hostname. A dot at the end of hostname is valid; see rfc1034 section 3.1. It indicates that it is complete (also referred to as absolute or fully qualified). > (2). Based on the different definition for > domainlable and toplable, toplable does not alow > token starts with DIGIT. Why is that? See rfc1034 section 3.5 for definition. I assume that it was for a quicker distinction between IPv4address and hostname. However this restriction is not very limiting since it applies to the suffixes such as ".com", ".gov", etcetera. If I recall correctly, the no starting-with-digits used to also apply to the "domainlable" portion. The restriction was relaxed to accommodate company names such as 3com and 8x8; however I can't recall the rfc that relaxed the rule. _______________________________________________ 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 Nov 6 16:23:49 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12908 for ; Wed, 6 Nov 2002 16:23:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA6LPr013197 for sip-archive@odin.ietf.org; Wed, 6 Nov 2002 16:25: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 gA6LFuv12821; Wed, 6 Nov 2002 16:15: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 gA6LEYv12765 for ; Wed, 6 Nov 2002 16:14:34 -0500 Received: from caduceus.fm.intel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12581 for ; Wed, 6 Nov 2002 16:12:00 -0500 (EST) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id gA6LAEt13580 for ; Wed, 6 Nov 2002 21:10:14 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.27 2002/10/16 23:46:59 dmccart Exp $) with SMTP id gA6LAQL26533 for ; Wed, 6 Nov 2002 21:10:26 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002110613130131609 for ; Wed, 06 Nov 2002 13:13:01 -0800 Received: from fmsmsx404.amr.corp.intel.com ([132.233.42.208]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Nov 2002 13:14:27 -0800 content-class: urn:content-classes:message Date: Wed, 6 Nov 2002 13:14:27 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: B2BUA question. X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Index: AcKF2XyBkdUCigK5RaGRwNbxrDXDYQ== From: "Padhye, Chinmay" To: X-OriginalArrivalTime: 06 Nov 2002 21:14:27.0965 (UTC) FILETIME=[7D7EBAD0:01C285D9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA6LEZv12766 Subject: [Sip] B2BUA 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 Hello, This is from the definition of B2BUA from RFC 3261 - 'Since it is a concatenation of a UAC and UAS, no explicit definitions are needed for its behavior." Since the behavior of a B2BUA is the same as the behavior of a UAC/UAS, what was the need for defining a new logical entity - B2BUA? I am trying to understand the motivation behind adding this definition in the RFC. Regards, Chinmay _______________________________________________ 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 Nov 6 21:28:39 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20326 for ; Wed, 6 Nov 2002 21:28:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA72Ujj30223 for sip-archive@odin.ietf.org; Wed, 6 Nov 2002 21:30: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 gA72U7v30174; Wed, 6 Nov 2002 21:30: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 gA72NLv29914 for ; Wed, 6 Nov 2002 21:23:21 -0500 Received: from imo-d09.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20179 for ; Wed, 6 Nov 2002 21:20:45 -0500 (EST) Received: from bertculpepper@netscape.net by imo-d09.mx.aol.com (mail_out_v34.13.) id j.5d.52aa4ab (16237); Wed, 6 Nov 2002 21:23:08 -0500 (EST) Received: from netscape.net (76.143.8.67.cfl.rr.com [67.8.143.76]) by air-in03.mx.aol.com (v89.12) with ESMTP id MAILININ31-1106212308; Wed, 06 Nov 2002 21:23:08 -0500 Message-ID: <3DC9CE93.6000505@netscape.net> Date: Wed, 06 Nov 2002 21:23:15 -0500 From: Bert Culpepper User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: "Padhye, Chinmay" CC: sip@ietf.org Subject: Re: [Sip] B2BUA question. References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Unknown (No Version) 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'll provide my opinion on why this term was included in RFC3261, other folks may provide different/better reasons. The previous RFC defined UAC, UAS, Registar, Proxy, and Redirect Server logical entities. As services (both legacy and new) were designed using SIP, it was determined that a combination of defined logical entities was needed to implement the services and still be compliant with the specification. This particular combination became common enough that (I presume) the authors thought it should be mentioned in the new RFC, to avoid mis-interpretation. Regards, Bert Padhye, Chinmay wrote: > Hello, > > This is from the definition of B2BUA from RFC 3261 - > > 'Since it is a concatenation of a UAC and UAS, no explicit definitions are needed for its behavior." > > Since the behavior of a B2BUA is the same as the behavior of a UAC/UAS, what was the need for defining a new logical entity - B2BUA? I am trying to understand the motivation behind adding this definition in the RFC. > > Regards, > > Chinmay > _______________________________________________ > 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 Nov 6 21:41:39 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21074 for ; Wed, 6 Nov 2002 21:41:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA72hi431378 for sip-archive@odin.ietf.org; Wed, 6 Nov 2002 21:43: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 gA72gBv31301; Wed, 6 Nov 2002 21:42: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 gA72e4v31203 for ; Wed, 6 Nov 2002 21:40:04 -0500 Received: from hermes.fm.intel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20943 for ; Wed, 6 Nov 2002 21:37:27 -0500 (EST) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id gA72cFO06916 for ; Thu, 7 Nov 2002 02:38:15 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.27 2002/10/16 23:46:59 dmccart Exp $) with SMTP id gA72Zrk23586 for ; Thu, 7 Nov 2002 02:35:53 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002110618382825275 ; Wed, 06 Nov 2002 18:38:28 -0800 Received: from fmsmsx404.amr.corp.intel.com ([132.233.42.208]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Nov 2002 18:39:54 -0800 content-class: urn:content-classes:message Subject: RE: [Sip] B2BUA question. Date: Wed, 6 Nov 2002 18:39:54 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [Sip] B2BUA question. X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Index: AcKGBKApZ4EM5vH2EdawTgBQi2jYqAAAa/vA From: "Padhye, Chinmay" To: "Bert Culpepper" , X-OriginalArrivalTime: 07 Nov 2002 02:39:54.0669 (UTC) FILETIME=[F4514DD0:01C28606] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA72e4v31204 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 Hello, Thanks for the reply. So the B2BUA logical entity is a combination of "ONLY" the UAC and UAS logical entities. Is this an accurate statement? Regards, Chinmay -----Original Message----- From: Bert Culpepper [mailto:bertculpepper@netscape.net] Sent: Wednesday, November 06, 2002 6:23 PM To: Padhye, Chinmay Cc: sip@ietf.org Subject: Re: [Sip] B2BUA question. Hi, I'll provide my opinion on why this term was included in RFC3261, other folks may provide different/better reasons. The previous RFC defined UAC, UAS, Registar, Proxy, and Redirect Server logical entities. As services (both legacy and new) were designed using SIP, it was determined that a combination of defined logical entities was needed to implement the services and still be compliant with the specification. This particular combination became common enough that (I presume) the authors thought it should be mentioned in the new RFC, to avoid mis-interpretation. Regards, Bert Padhye, Chinmay wrote: > Hello, > > This is from the definition of B2BUA from RFC 3261 - > > 'Since it is a concatenation of a UAC and UAS, no explicit definitions are needed for its behavior." > > Since the behavior of a B2BUA is the same as the behavior of a UAC/UAS, what was the need for defining a new logical entity - B2BUA? I am trying to understand the motivation behind adding this definition in the RFC. > > Regards, > > Chinmay > _______________________________________________ > 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 Nov 7 01:34:27 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25386 for ; Thu, 7 Nov 2002 01:34:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA76aaP10559 for sip-archive@odin.ietf.org; Thu, 7 Nov 2002 01:36: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 gA76a5v10530; Thu, 7 Nov 2002 01:36: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 gA76Wjv10357 for ; Thu, 7 Nov 2002 01:32:45 -0500 Received: from fthsmtp01.cbsinc.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25302 for ; Thu, 7 Nov 2002 01:30:05 -0500 (EST) Received: by fthsmtp01 with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Nov 2002 01:29:49 -0500 Message-ID: From: KANUMURI Sreeram To: sip@ietf.org Cc: "'Ranjit Kumar Avasarala'" Date: Thu, 7 Nov 2002 01:31:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Sip] on SIP Hard phones 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 am looking for a SIP-Hard phone which will support the MID call signalling(DTMF--INFO methods) i have seen the snom 100 Hard phone from http://www.snom.de and it is not supporting the INFO method. so can any one tell me what are the Hard phones availble(any pointer )and which support the INFO method. TIA -sreeram _______________________________________________ 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 Nov 7 01:59:39 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25732 for ; Thu, 7 Nov 2002 01:59:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA771mi12122 for sip-archive@odin.ietf.org; Thu, 7 Nov 2002 02:01: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 gA771Mv12108; Thu, 7 Nov 2002 02:01: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 gA7703v11861 for ; Thu, 7 Nov 2002 02:00:03 -0500 Received: from btlmail.bplmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25672 for ; Thu, 7 Nov 2002 01:57:19 -0500 (EST) Received: from [10.10.13.58] (helo=RKUMAR) by btlmail.bplmail.com with smtp (Exim 3.22 #1 (Red Hat Linux)) id 189gbH-0001FJ-00 for ; Thu, 07 Nov 2002 12:27:11 +0530 Reply-To: From: "Ranjit Kumar Avasarala" To: "Sip-Ietf" Date: Thu, 7 Nov 2002 12:30:18 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <3DC9CE93.6000505@netscape.net> Content-Transfer-Encoding: 7bit Subject: [Sip] SIP Servlet API` 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 I wanted to the know the status of draft draft-kristensen-sip-servlet and what is the general industry opinion on SIP servlets. Like how useful it will be to enable SIP Servlets talk to existing SIP stacks ? Thanks Ranjit _______________________________________________ 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 Nov 7 02:55:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06412 for ; Thu, 7 Nov 2002 02:55:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA77vVq24633 for sip-archive@odin.ietf.org; Thu, 7 Nov 2002 02:57: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 gA77v2v24601; Thu, 7 Nov 2002 02:57: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 gA77r9v24410 for ; Thu, 7 Nov 2002 02:53:09 -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 CAA06360; Thu, 7 Nov 2002 02:50:29 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA77qrKV018611; Thu, 7 Nov 2002 08:52:53 +0100 (MET) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.51]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id gA77qqZb010436; Thu, 7 Nov 2002 09:52:52 +0200 (EET) Message-ID: <3DCA1BD5.BC3280FC@lmf.ericsson.se> Date: Thu, 07 Nov 2002 09:52:53 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Yadavalli, Satyamurthy" CC: "'sipping@ietf.org'" , sip-implementors@cs.columbia.edu, "'sip@ietf.org'" References: <37A3C2F21006D611995100B0D0F9B73C012A2C89@tnint11.telogy.design.ti.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Sipping] RE: [Sip-implementors] "Early Media" 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, It has not yet been incorporated to amy draft, but it will be as soon as we find some spare cycles... we are working on it. Thanks, Gonzalo "Yadavalli, Satyamurthy" wrote: > > I figure out that a discussion on this issue occured earlier with proposals > to use 183 Session Progress etc., > (Subject: "[Sip] Local vs. Remote ringback on 180") > Was a conclusion reached and was it incorporated into any (draft) RFC? > -Satya > > > -----Original Message----- > > From: Yadavalli, Satyamurthy [mailto:syadavalli@telogy.com] > > Sent: Sunday, November 03, 2002 12:56 AM > > To: 'sipping@ietf.org'; sip-implementors@cs.columbia.edu > > Subject: [Sip-implementors] "Early Media" > > > > > > Hi, > > Would like to know how to achieve the following using any of > > the SIP related > > RFCs: > > > > UA1 invites UA2. Say UA2 generates a local ringing tone (or > > some audio) to > > alert its user. However, UA2 woud like to feed some (ringing) > > audio back to > > UA1 (in addition to the 180 RINGING response). And also say > > UA2 may like its > > early media to be overriding any locally generated ringback > > that UA1 may be > > generating to its user about the call in progress. > > > > This 'early media' may have its own characteristics such as codec > > requirements etc., different from those of the final > > dialogue. How (ofcourse > > via an SDP but attached to which SIP response: 180?) are these to be > > described by UA2 to UA1 so that UA1 may load the necessary > > codecs etc., so > > as to be able to present the early media (to be received from > > UA2) to its > > user. And also how to indicate when the audio path (RTP) for > > this early > > media is to be established/released. > > > > Is there any RFC that describes how to provide this kind of > > 'subdialogue' > > before the actual SIP dialogue is established? A quick glance > > at the UPDATE > > RFC appeared to somewhat support this kind of requirement but > > appeared (at > > first glance) to specify the main dialogue itself and didnot appear to > > clearly say when to establish/release this 'subdialogue'. > > > > Appreciate any help in this regard, > > Thanks, > > Satya > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP -- 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 Thu Nov 7 03:04:20 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06590 for ; Thu, 7 Nov 2002 03:04:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA786Sx25187 for sip-archive@odin.ietf.org; Thu, 7 Nov 2002 03:06: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 gA786Av25172; Thu, 7 Nov 2002 03:06: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 gA7848v24977 for ; Thu, 7 Nov 2002 03:04:08 -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 DAA06533 for ; Thu, 7 Nov 2002 03:01:28 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA783oKV022000; Thu, 7 Nov 2002 09:03:50 +0100 (MET) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.51]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id gA783oZb011143; Thu, 7 Nov 2002 10:03:50 +0200 (EET) Message-ID: <3DCA1E66.13687F4C@lmf.ericsson.se> Date: Thu, 07 Nov 2002 10:03:50 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Padhye, Chinmay" CC: Bert Culpepper , sip@ietf.org Subject: Re: [Sip] B2BUA question. 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 Hi, I do not understand what you mean by "ONLY", but I will take a stab at a response anyway. If by "ONLY" you mean that it does not implement other protocols, the answer is no. A B2BUA can receive a SIP request acting as a SIP UAC, send an LDAP query acting as an LDAP client, and then send a SIP request acting as a SIP UAC. A B2BUA handles two dialogs, and it behaves as a UA for both dialogs. The B2BUA typically uses information in requests or responses in one dialog to create requests or responses in the other one. An example of a B2BUA is a 3rd party call controller. Regards, Gonzalo "Padhye, Chinmay" wrote: > > Hello, > > Thanks for the reply. > > So the B2BUA logical entity is a combination of "ONLY" the UAC and UAS logical entities. Is this an accurate statement? > > Regards, > > Chinmay > > -----Original Message----- > From: Bert Culpepper [mailto:bertculpepper@netscape.net] > Sent: Wednesday, November 06, 2002 6:23 PM > To: Padhye, Chinmay > Cc: sip@ietf.org > Subject: Re: [Sip] B2BUA question. > > Hi, > > I'll provide my opinion on why this term was included in RFC3261, other > folks may provide different/better reasons. > > The previous RFC defined UAC, UAS, Registar, Proxy, and Redirect Server > logical entities. As services (both legacy and new) were designed using > SIP, it was determined that a combination of defined logical entities > was needed to implement the services and still be compliant with the > specification. This particular combination became common enough that (I > presume) the authors thought it should be mentioned in the new RFC, to > avoid mis-interpretation. > > Regards, > Bert > > Padhye, Chinmay wrote: > > > Hello, > > > > This is from the definition of B2BUA from RFC 3261 - > > > > 'Since it is a concatenation of a UAC and UAS, no explicit definitions are needed for its behavior." > > > > Since the behavior of a B2BUA is the same as the behavior of a UAC/UAS, what was the need for defining a new logical entity - B2BUA? I am trying to understand the motivation behind adding this definition in the RFC. > > > > Regards, > > > > Chinmay > > _______________________________________________ > > 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 -- 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 Thu Nov 7 03:29:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07111 for ; Thu, 7 Nov 2002 03:29:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA78VoU26927 for sip-archive@odin.ietf.org; Thu, 7 Nov 2002 03:31: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 gA78VNv26889; Thu, 7 Nov 2002 03:31: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 gA78Olv26634 for ; Thu, 7 Nov 2002 03:24:47 -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 DAA06952 for ; Thu, 7 Nov 2002 03:22:07 -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; 7 Nov 2002 08:24:35 -0000 Reply-To: From: "Sean Olson" To: "'Jonathan Rosenberg'" , "'Peterson, Jon'" Cc: "'Anders Kristensen'" , Subject: RE: [Sip] SIPS question Date: Thu, 7 Nov 2002 00:24:41 -0800 Message-ID: <000a01c28637$1eec2170$6b01a8c0@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1081 In-Reply-To: <3DC43776.4070500@dynamicsoft.com> 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 It would be awkward to deprecate "transport=TLS" if SIPS required the entire e2e path to be TLS when used in a Route: header. And I agree that something is really wrong if loose routing has to be disabled to support SIPS. We need something in between. The wording suggested should of course take into account the potential asymmetry between the inbound and outbound Record-Route. /sean -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Saturday, November 02, 2002 12:37 PM To: Peterson, Jon Cc: 'Anders Kristensen'; sip@ietf.org Subject: Re: [Sip] SIPS question I think we have lost sight of the semantics of SIPS. To me, SIPS is a way to tell a UA that ***the entire path*** was hop-by-hop secured. If a UA cannot know this with certainty, and we support these mixed scenarios, that devalues what sips is trying to do. Secure on just some hops is the same is insecure, and therefore, not useful. I also think it is a travesty to turn off loose routing to handle sips. I am not convinced this is needed or wise. I would prefer to add words which prohibit using sips at any hop unless the previous was sips. -Jonathan R. _______________________________________________ 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 Nov 7 04:19:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07884 for ; Thu, 7 Nov 2002 04:19:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA79M3H30408 for sip-archive@odin.ietf.org; Thu, 7 Nov 2002 04:22: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 gA78gmv28078; Thu, 7 Nov 2002 03:42: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 gA78dOv27825 for ; Thu, 7 Nov 2002 03:39:24 -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 DAA07226; Thu, 7 Nov 2002 03:36:44 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA78dAKV002845; Thu, 7 Nov 2002 09:39:10 +0100 (MET) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.51]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id gA78d9Zb013883; Thu, 7 Nov 2002 10:39:09 +0200 (EET) Message-ID: <3DCA26AE.715CF40F@lmf.ericsson.se> Date: Thu, 07 Nov 2002 10:39:10 +0200 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: Rohan Mahy , Dean Willis , Jon Peterson , Allison Mankin 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, we are updating the design teams web pages: http://www.softarmor.com/sipping/teams/index.html http://www.softarmor.com/sipwg/teams/index.html As you know, the IESG is moving towards a more transparent process regarding IETF LCs (e.g., the ID tracker). We would like to do the same with the SIPish design teams. From now on, design teams will have to be rather small groups working on an specific issue. They will typically have email discussions, but we want to encourage conference calls as well. We believe that having a conference call every now and then helps avoid synchronization problems among the design team members. We would like to see informal progress reports as well. Design teams should not be like black boxes where nobody outside knows what is going on. We will try to have at least one chair monitoring the progress of each design team. Having clear deliverables is a good thing as well. Therefore, I would like to ask people activelly involved in any design team to send me a private mail. We need to know the members of the design team, whether there is a mailing list, the documents produced so far, and the documents the team intends to produce. Thanks, Gonzalo, Dean, Rohan and Jon _______________________________________________ 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 Nov 7 06:43:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12333 for ; Thu, 7 Nov 2002 06:43:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7BjBR08343 for sip-archive@odin.ietf.org; Thu, 7 Nov 2002 06:45: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 gA7Biiv08318; Thu, 7 Nov 2002 06:44: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 gA7Bhov08261 for ; Thu, 7 Nov 2002 06:43:50 -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 GAA12250 for ; Thu, 7 Nov 2002 06:41:19 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.7]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gA7BhbYH025961; Thu, 7 Nov 2002 06:43:37 -0500 (EST) Message-ID: <3DCA51E7.9090204@dynamicsoft.com> Date: Thu, 07 Nov 2002 06:43:35 -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: KANUMURI Sreeram CC: sip@ietf.org, "'Ranjit Kumar Avasarala'" Subject: Re: [Sip] on SIP Hard phones 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 Transporting DTMF in INFO is not an IETF approved approach for conveying DTMF. It is a bad thing, in fact, for many reasons, not the least of which is the fact that DTMF will get sent in the signaling path even when no one cares, increasing proxy load uneccesarily. I STRONGLY recommend that you look at some of the recent activity in the application interaction area, which is sorting out this whole DTMF mess. Please see: http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-app-interaction-framework-00.txt http://www.ietf.org/internet-drafts/draft-jennings-sip-app-info-00.txt http://www.ietf.org/internet-drafts/draft-burger-sipping-kpml-00.txt -Jonathan R. KANUMURI Sreeram wrote: > Hi all, > I am looking for a SIP-Hard phone which will support the MID call > signalling(DTMF--INFO methods) > i have seen the snom 100 Hard phone from http://www.snom.de and it is not > supporting the INFO method. > > so can any one tell me what are the Hard phones availble(any pointer )and > which support the INFO method. > > > TIA > > -sreeram > _______________________________________________ > 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 > -- 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 Thu Nov 7 06:47:27 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13099 for ; Thu, 7 Nov 2002 06:47:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7BnR308557 for sip-archive@odin.ietf.org; Thu, 7 Nov 2002 06:49: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 gA7Bm6v08496; Thu, 7 Nov 2002 06:48: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 gA7BlQv08446 for ; Thu, 7 Nov 2002 06:47:26 -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 GAA12709 for ; Thu, 7 Nov 2002 06:44:51 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.7]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gA7BlGYH025964; Thu, 7 Nov 2002 06:47:17 -0500 (EST) Message-ID: <3DCA52C3.9010203@dynamicsoft.com> Date: Thu, 07 Nov 2002 06:47:15 -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: "Padhye, Chinmay" CC: sip@ietf.org Subject: Re: [Sip] B2BUA question. 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 We added the term to the spec since it was used so much in other places, we wanted to have a concrete definition so people wouldn't be confused. -Jonathan R. Padhye, Chinmay wrote: > Hello, > > This is from the definition of B2BUA from RFC 3261 - > > 'Since it is a concatenation of a UAC and UAS, no explicit definitions are needed for its behavior." > > Since the behavior of a B2BUA is the same as the behavior of a UAC/UAS, what was the need for defining a new logical entity - B2BUA? I am trying to understand the motivation behind adding this definition in the RFC. > > Regards, > > Chinmay > _______________________________________________ > 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 > -- 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 Thu Nov 7 07:02:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14776 for ; Thu, 7 Nov 2002 07:02:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7C4ss09501 for sip-archive@odin.ietf.org; Thu, 7 Nov 2002 07:04: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 gA7C1Kv09274; Thu, 7 Nov 2002 07:01: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 gA7BxWv09041 for ; Thu, 7 Nov 2002 06:59:32 -0500 Received: from capmail.MX.talkyonline.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14193 for ; Thu, 7 Nov 2002 06:57:00 -0500 (EST) Received: by capmail.MX.talkyonline.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Nov 2002 12:55:44 +0100 Message-ID: From: Juan Luis Esteban To: "'Bert Culpepper'" , "Padhye, Chinmay" Cc: sip@ietf.org Subject: RE: [Sip] B2BUA question. Date: Thu, 7 Nov 2002 12:55:41 +0100 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: , Session Controllers deployed at the edge of the IP network or at ITSP peering points are another example of B2BUA entities. SCs allow layer 3 topology hiding, admission control... QoS features are also being added by some vendors. -----Mensaje original----- De: Bert Culpepper [mailto:bertculpepper@netscape.net] Enviado el: jueves, 07 de noviembre de 2002 3:23 Para: Padhye, Chinmay CC: sip@ietf.org Asunto: Re: [Sip] B2BUA question. Hi, I'll provide my opinion on why this term was included in RFC3261, other folks may provide different/better reasons. The previous RFC defined UAC, UAS, Registar, Proxy, and Redirect Server logical entities. As services (both legacy and new) were designed using SIP, it was determined that a combination of defined logical entities was needed to implement the services and still be compliant with the specification. This particular combination became common enough that (I presume) the authors thought it should be mentioned in the new RFC, to avoid mis-interpretation. Regards, Bert Padhye, Chinmay wrote: > Hello, > > This is from the definition of B2BUA from RFC 3261 - > > 'Since it is a concatenation of a UAC and UAS, no explicit definitions are needed for its behavior." > > Since the behavior of a B2BUA is the same as the behavior of a UAC/UAS, what was the need for defining a new logical entity - B2BUA? I am trying to understand the motivation behind adding this definition in the RFC. > > Regards, > > Chinmay > _______________________________________________ > 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 Nov 7 09:18:04 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25346 for ; Thu, 7 Nov 2002 09:18:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7EK4X20251 for sip-archive@odin.ietf.org; Thu, 7 Nov 2002 09:20: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 gA7EIov20197; Thu, 7 Nov 2002 09:18: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 gA7EHov20146 for ; Thu, 7 Nov 2002 09:17:50 -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 JAA25271 for ; Thu, 7 Nov 2002 09:15:19 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gA7EGnnX020432; Thu, 7 Nov 2002 09:16:49 -0500 (EST) Received: from dynamicsoft.com (63.113.46.11 [63.113.46.11]) by DYN-EXCH-001.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VBC4Q9D9; Thu, 7 Nov 2002 09:17:44 -0500 Message-ID: <3DCA75FD.1020903@dynamicsoft.com> Date: Thu, 07 Nov 2002 09:17:33 -0500 From: Anders Kristensen 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: ranjit.avasarala@bplmail.com CC: Sip-Ietf Subject: Re: [Sip] SIP Servlet API` 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 Ranjit Kumar Avasarala wrote: > Hi all > > I wanted to the know the status of draft draft-kristensen-sip-servlet and It's very much out of date. The API is being standardized within the JCP and is just about completed. You can find the latest draft at http://jcp.org/en/jsr/detail?id=116 Thanks, Anders > what is the general industry opinion on SIP servlets. > Like how useful it will be to enable SIP Servlets talk to existing SIP > stacks ? > > Thanks > Ranjit > > _______________________________________________ > 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 Nov 7 09:56:53 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26708 for ; Thu, 7 Nov 2002 09:56:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7EwsV22795 for sip-archive@odin.ietf.org; Thu, 7 Nov 2002 09:58: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 gA7Ervv22557; Thu, 7 Nov 2002 09:53: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 gA7Eqgv22476 for ; Thu, 7 Nov 2002 09:52:42 -0500 Received: from ihemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26481; Thu, 7 Nov 2002 09:50:10 -0500 (EST) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gA7EqXd04287; Thu, 7 Nov 2002 09:52:33 -0500 (EST) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Nov 2002 08:52:33 -0600 Message-ID: From: "Ejzak, Richard P (Richard)" To: "'Gonzalo Camarillo'" , "Yadavalli, Satyamurthy" Cc: "'sipping@ietf.org'" , sip-implementors@cs.columbia.edu, "'sip@ietf.org'" Subject: RE: [Sip] Re: [Sipping] RE: [Sip-implementors] "Early Media" Date: Thu, 7 Nov 2002 08:52:32 -0600 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: , Gonzalo, Satya, We have also been looking for cycles to work on a draft. A collaboration may be in order... Richard -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: Thursday, November 07, 2002 1:53 AM To: Yadavalli, Satyamurthy Cc: 'sipping@ietf.org'; sip-implementors@cs.columbia.edu; 'sip@ietf.org' Subject: [Sip] Re: [Sipping] RE: [Sip-implementors] "Early Media" Hi, It has not yet been incorporated to amy draft, but it will be as soon as we find some spare cycles... we are working on it. Thanks, Gonzalo "Yadavalli, Satyamurthy" wrote: > > I figure out that a discussion on this issue occured earlier with proposals > to use 183 Session Progress etc., > (Subject: "[Sip] Local vs. Remote ringback on 180") > Was a conclusion reached and was it incorporated into any (draft) RFC? > -Satya > > > -----Original Message----- > > From: Yadavalli, Satyamurthy [mailto:syadavalli@telogy.com] > > Sent: Sunday, November 03, 2002 12:56 AM > > To: 'sipping@ietf.org'; sip-implementors@cs.columbia.edu > > Subject: [Sip-implementors] "Early Media" > > > > > > Hi, > > Would like to know how to achieve the following using any of > > the SIP related > > RFCs: > > > > UA1 invites UA2. Say UA2 generates a local ringing tone (or > > some audio) to > > alert its user. However, UA2 woud like to feed some (ringing) > > audio back to > > UA1 (in addition to the 180 RINGING response). And also say > > UA2 may like its > > early media to be overriding any locally generated ringback > > that UA1 may be > > generating to its user about the call in progress. > > > > This 'early media' may have its own characteristics such as codec > > requirements etc., different from those of the final > > dialogue. How (ofcourse > > via an SDP but attached to which SIP response: 180?) are these to be > > described by UA2 to UA1 so that UA1 may load the necessary > > codecs etc., so > > as to be able to present the early media (to be received from > > UA2) to its > > user. And also how to indicate when the audio path (RTP) for > > this early > > media is to be established/released. > > > > Is there any RFC that describes how to provide this kind of > > 'subdialogue' > > before the actual SIP dialogue is established? A quick glance > > at the UPDATE > > RFC appeared to somewhat support this kind of requirement but > > appeared (at > > first glance) to specify the main dialogue itself and didnot appear to > > clearly say when to establish/release this 'subdialogue'. > > > > Appreciate any help in this regard, > > Thanks, > > Satya > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP -- 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 _______________________________________________ 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 Nov 7 12:21:36 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02878 for ; Thu, 7 Nov 2002 12:21:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7HNdl01119 for sip-archive@odin.ietf.org; Thu, 7 Nov 2002 12:23: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 gA7HFhv00694; Thu, 7 Nov 2002 12:15: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 gA7HCQv00580 for ; Thu, 7 Nov 2002 12:12:26 -0500 Received: from mail3.telefonica.com.ar (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02409 for ; Thu, 7 Nov 2002 12:09:52 -0500 (EST) Received: by mailhub.sote.tasa.com.ar with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Nov 2002 14:12:26 -0300 Message-ID: From: De Leo Walter To: "'sip@ietf.org'" Date: Thu, 7 Nov 2002 14:12:24 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Sip] SIP Nat Traversal Reference needed 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 will be very thankful if someone could send me a pointer to a complete set of work items referred to this subject. Regards. Walter _______________________________________________ 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 Nov 7 12:33:49 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03368 for ; Thu, 7 Nov 2002 12:33:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7HZq601865 for sip-archive@odin.ietf.org; Thu, 7 Nov 2002 12:35: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 gA7HTQv01438; Thu, 7 Nov 2002 12:29: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 gA7HRKv01344 for ; Thu, 7 Nov 2002 12:27:20 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03064; Thu, 7 Nov 2002 12:24:45 -0500 (EST) Message-Id: <200211071724.MAA03064@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , sip@ietf.org From: The IESG Date: Thu, 07 Nov 2002 12:24:45 -0500 Subject: [Sip] Protocol Action: DHCPv6 Options for SIP Servers to Proposed Standard 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: , The IESG has approved the Internet-Draft 'DHCPv6 Options for SIP Servers' as a Proposed Standard. This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. Technical Summary This draft specifies two DHCPv6 options that allows SIP clients to locate a local SIP server that is to be used for all outbound SIP requests, a so-called outbound proxy server. SIP clients MAY contact the address identified in the SIP URL directly, without involving a local SIP server. However in some circumstances, such as particularly when a firewall is present, SIP clients need to use a local server for outbound requests. The SIP DHCPv6 option (for use in IPv6 environments) is one of many possible solutions for locating the outbound SIP server; manual configuration is an example of another. This document defines two DHCPv6 options that describe a local outbound SIP proxy: one carries a list of domain names, the other a list of 128-bit (binary) IPv6 addresses. Like the DHCPv4 option for this function (currently in the RFC Editor's queue), the SIP DHCPv6 option uses RFC 1035 encoding (Section 3.1 of RFC 1035), after careful review of the design by the DHCP working group and the Internet Area Directors. Working Group Summary The working group supported advancement of this specification. Protocol Quality The document was reviewed for the IESG by Allison Mankin. During IETF Last Call, it was noted that the consequences of a rogue DHCP server might be quite serious for SIP clients. RFC 3118 provides a means for mutual authentication between a DHCP client and server, and there is a plan for development of a specification for clients to authenticate their servers without the mutual authentication requirement. This document inherits the Security Considerations of the DHCPv6 specification (to be announced at the same time as this). In addition, the SIP RFC (draft-ietf-sip-rfc2543bis-09.txt), currently in the RFC Editor queue, advises SIP clients to authenticate servers they use, by careful checking of the server certificate provided by use of a TLS connection for the client-to- server communication. _______________________________________________ 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 Nov 7 14:10:33 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06611 for ; Thu, 7 Nov 2002 14:10:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7JCbg09201 for sip-archive@odin.ietf.org; Thu, 7 Nov 2002 14:12:37 -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 gA7J8fv08870; Thu, 7 Nov 2002 14:08: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 gA7J0qv07884 for ; Thu, 7 Nov 2002 14:00:52 -0500 Received: from cypress.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06275 for ; Thu, 7 Nov 2002 13:58:16 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by cypress.neustar.com (8.11.6/8.11.6) with ESMTP id gA7J0TX04001; Thu, 7 Nov 2002 19:00:29 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Nov 2002 14:01:17 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB394@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'hisham.khartabil@nokia.com'" , christer.holmberg@lmf.ericsson.se Cc: akristensen@dynamicsoft.com, sip@ietf.org Subject: RE: [Sip] SIPS question Date: Thu, 7 Nov 2002 14:01:06 -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'm not sure I favor removal of this 8.1.2 text entirely. After some reflection, I think what we're looking for is a rule that reflects the use of SIPS in the destination address-of-record to which a request is sent (in a dialog, this is largely applicable only to the initial request), not the Request-URI. If we're concerned about the destination address-of-record of the initial request, we should probably be talking about the To header field. So, as a correction (to the text in 8.1.2 anyway) I might suggest something like: "Independent of which URI is used as the input to the procedures of [4], if the To header field specifies a SIPS resource, the UAC MUST follow the procedures of [4] as if the input URI were a SIPS URI." Squinting at the flows for a moment, I don't see this giving rise to the sort of concerns that Christer raised about the Contact header and retargeting (when the SIPS URI is used in Route/Contact headers), but it still provides the hBh-all-the-way property that SIPS was designed for. A similar correction could be made to the informative text in 26.2.2. Any thoughts about this? Any other text that would need to be amended? Jon Peterson NeuStar, Inc. > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Monday, November 04, 2002 6:08 AM > To: christer.holmberg@lmf.ericsson.se; jon.peterson@neustar.biz > Cc: akristensen@dynamicsoft.com; sip@ietf.org > Subject: RE: [Sip] SIPS question > > > Removing this restriction seems to fix the problem, I think. > > "Independent > of which URI is used as input to the procedures of [4], if the > Request-URI specifies a SIPS resource, the UAC MUST follow the > procedures of [4] as if the input URI were a SIPS URI." > > But also, would mandating that: if a REGISTER has a sips-uri > contact, the To-header must contain a sips-uri work? and visa versa? > > eg: UA2 registers with sips-uri in both To-header and > contact-header (sips in both or neither, but not mixed). > > In this case, UA2 home proxy will reject the request with 404 > if UA1 sends a request with sip-uri. UA2 can also reject the > request directly if it doesn't want to accept requests not using TLS. > > Regards, > Hisham > > > -----Original Message----- > > From: ext Christer Holmberg > [mailto:christer.holmberg@lmf.ericsson.se] > > Sent: Monday, November 04, 2002 1:55 PM > > To: Peterson, Jon > > Cc: 'Anders Kristensen'; sip@ietf.org > > Subject: Re: [Sip] SIPS question > > > > > > > > Hi, > > > > > >Also, it's not only about mid-session requests, even if > > that may be so in > > > >most cases. Assume the Request-URI for the initial INVITE > > is SIPS-URI, but > > > the > > > >UAC uses an outbound proxy, ie using a pre-configured > > Route with SIP-URI. > > > > > > The design of SIPS used as the 'remote target', as the AoR of the > > > destination, necessitates that this first hop go over TLS. > > Look, as I said, > > > outbound proxies are proxy servers, proxy servers MUST > > support TLS, and > > > entities that support TLS MUST support SIPS. Converting > > this Route header to > > > a TLS route is plausible and allowed by the spec. > > > > Yes, but the problem is again if the UAC doesn't support TLS. > > Assume the UAC > > gets the Request-URI SIPS-URI from some "external source" > > (ENUM, data base, > > whatever...), but since it uses an outbound proxy, using a > > predefined Route with > > SIP-URI, it doesn't care about the Request-URI SIPS-URI. > > > > I don't know if that scenario is "allowed" or not, but my > > point was that the > > problem would be the same as for mid-session requests. > > > > > We considered both transport parameters (transport=tls was > > obsoleted in > > > favor of SIPS, as I'm sure you recall) and > > Require/Supported option tags in > > > our deliberations about SIPS. The point is that we wanted > a resource > > > identifier that indicates directly that it should be > > contacted securely. > > > > Another option would be that the URI in the TO header, which > > IS end-to-end, > > would be used to indicate if to use TLS or not. That would > > not allow that TLS is > > used between specific hops only, though. > > > > Now, however, TLS would be used for the mid-session requests > > EVEN if the record > > routing proxies insert SIP-URI in the Record-Route headers, > > and/or the UAC > > inserts SIP-URI in the Contact header, since the TO header > > URI would not change. > > > > Now TLS would always be used for the whole session, and not > > only for the INVITE, > > but I assume that is how most people intend to use it anyway. Or? > > > > But, I still think the easiest fix would be to change the > > text as proposed > > earlier. Then, we may have to write something about the > > outbound proxy scenario > > - or use Jonathan's proposal to use TLS only if the previous > > hop used TLS > > (assuming we want to use TLS end-to-end ONLY, that is). > > > > 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 > > > _______________________________________________ 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 Nov 7 14:11:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06634 for ; Thu, 7 Nov 2002 14:11:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7JD7A09233 for sip-archive@odin.ietf.org; Thu, 7 Nov 2002 14:13: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 gA7Ixfv07800; Thu, 7 Nov 2002 13:59: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 gA7IuHv07620 for ; Thu, 7 Nov 2002 13:56:17 -0500 Received: from hermes.fm.intel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06184 for ; Thu, 7 Nov 2002 13:53:41 -0500 (EST) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id gA7IsVa27531 for ; Thu, 7 Nov 2002 18:54:31 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.27 2002/10/16 23:46:59 dmccart Exp $) with SMTP id gA7Iq9x08287 for ; Thu, 7 Nov 2002 18:52:09 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002110710544302234 ; Thu, 07 Nov 2002 10:54:43 -0800 Received: from fmsmsx404.amr.corp.intel.com ([132.233.42.208]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 7 Nov 2002 10:56:10 -0800 content-class: urn:content-classes:message Subject: RE: [Sip] B2BUA question. Date: Thu, 7 Nov 2002 10:56:10 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [Sip] B2BUA question. Thread-Index: AcKGNDjogTqOzfImEdawTgBQi2jYqAAVWfSQ X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 From: "Padhye, Chinmay" To: "Bert Culpepper" , "Gonzalo Camarillo" , "Jonathan Rosenberg" , "Juan Luis Esteban" Cc: X-OriginalArrivalTime: 07 Nov 2002 18:56:10.0287 (UTC) FILETIME=[561B4BF0:01C2868F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA7IuHv07621 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 Hello, My response is inline starting with [Chinmay]. Regards, Chinmay -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: Thursday, November 07, 2002 12:04 AM To: Padhye, Chinmay Cc: Bert Culpepper; sip@ietf.org Subject: Re: [Sip] B2BUA question. Hi, I do not understand what you mean by "ONLY", but I will take a stab at a response anyway. If by "ONLY" you mean that it does not implement other protocols, the answer is no. A B2BUA can receive a SIP request acting as a SIP UAC, send an LDAP query acting as an LDAP client, and then send a SIP request acting as a SIP UAC. ---------------------------------- [Chinmay] I think its better if we separate logical entities with physical entities or applications that contain/behave as multiple logical entities. An application may contain a B2BUA logical entity, a LDAP client, a proxy entity, a registrar entity, etc. A physical entity may contain many such applications. My statement - 'the B2BUA logical entity is a combination of "ONLY" the UAC and UAS logical entities. Is this an accurate statement?', was meant only for the B2BUA logical entity and not for the application. Hence in the above example the B2BUA logical entity cannot send the LDAP query. The LDAP client, which is part of the same application, sends the LDAP query. ---------------------------------- A B2BUA handles two dialogs, and it behaves as a UA for both dialogs. The B2BUA typically uses information in requests or responses in one dialog to create requests or responses in the other one. An example of a B2BUA is a 3rd party call controller. ---------------------------------- [Chinmay] I need some more clarifications on some scenarios. Consider the following scenarios. Scenario 1 - UA1 B2BUA UA2 |-- INVITE -------> | | | CID:1 | -- INVITE ---->| CID:x In the above scenario can 'x' take the value 1? IMO this x MUST not be equal to 1, because the UAC part of the B2BUA must not use CID:1 to generate the outgoing INVITE. Is this right. Scenario 2 - I am not sure if this part of the email belongs here or in the implementers list. Let me know if I should move this part of the email to the implementers list. UA1 B2BUA UA2 UA3 |-- INVITE -------> | | | | CID:1 | -- INVITE ---->| | | | CID:2 | | | | | | | | -- INVITE ----------------->| | | CID:3 | | | | | | | | <-- 200 OK --- | | | <---- 200 OK ---- | | | | | <-- 200 OK -----------------| | <----- 200 OK --- | | | ????????? Can this be forwarded. In this scenario the B2BUA, on receiving the INVITE request from UA1, generates new INVITE request to two UAs, UA2 and UA3. (A similar scenario will occur if a downstream proxy forks and receives multiple 200 OKs.) - Can the B2BUA generate two INVITE/Requests, for one incoming INVITE/Request? Is this allowed by the protocol/definition of B2BUA? IMO this should be allowed. Now both the UAs respond with 200 OK responses. - Is the B2BUA allowed to generate two responses towards UA1 (with different to-tags)? IMO this also should be allowed. ---------------------------------- Regards, Gonzalo "Padhye, Chinmay" wrote: > > Hello, > > Thanks for the reply. > > So the B2BUA logical entity is a combination of "ONLY" the UAC and UAS logical entities. Is this an accurate statement? > > Regards, > > Chinmay > > -----Original Message----- > From: Bert Culpepper [mailto:bertculpepper@netscape.net] > Sent: Wednesday, November 06, 2002 6:23 PM > To: Padhye, Chinmay > Cc: sip@ietf.org > Subject: Re: [Sip] B2BUA question. > > Hi, > > I'll provide my opinion on why this term was included in RFC3261, other > folks may provide different/better reasons. > > The previous RFC defined UAC, UAS, Registar, Proxy, and Redirect Server > logical entities. As services (both legacy and new) were designed using > SIP, it was determined that a combination of defined logical entities > was needed to implement the services and still be compliant with the > specification. This particular combination became common enough that (I > presume) the authors thought it should be mentioned in the new RFC, to > avoid mis-interpretation. > > Regards, > Bert > > Padhye, Chinmay wrote: > > > Hello, > > > > This is from the definition of B2BUA from RFC 3261 - > > > > 'Since it is a concatenation of a UAC and UAS, no explicit definitions are needed for its behavior." > > > > Since the behavior of a B2BUA is the same as the behavior of a UAC/UAS, what was the need for defining a new logical entity - B2BUA? I am trying to understand the motivation behind adding this definition in the RFC. > > > > Regards, > > > > Chinmay > > _______________________________________________ > > 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 -- 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 Fri Nov 8 00:59:58 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27089 for ; Fri, 8 Nov 2002 00:59:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8625n19458 for sip-archive@odin.ietf.org; Fri, 8 Nov 2002 01:02: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 gA861av19427; Fri, 8 Nov 2002 01:01: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 gA85xqv19322 for ; Fri, 8 Nov 2002 00:59:52 -0500 Received: from momus.sc.intel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27013 for ; Fri, 8 Nov 2002 00:56:51 -0500 (EST) Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by momus.sc.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.48 2002/10/16 23:47:34 dmccart Exp $) with SMTP id gA85wuh14581 for ; Fri, 8 Nov 2002 05:59:06 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002110721581123613 ; Thu, 07 Nov 2002 21:58:11 -0800 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Nov 2002 21:57:50 -0800 Message-ID: <12B638FEE763F74696D8544752E7204801BACC2B@bgsmsx101.iind.intel.com> From: "Kaul, Amit" To: "Padhye, Chinmay" , Bert Culpepper , Gonzalo Camarillo , Jonathan Rosenberg , Juan Luis Esteban Cc: sip@ietf.org Subject: RE: [Sip] B2BUA question. Date: Thu, 7 Nov 2002 21:53:06 -0800 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 that we might want to limit our discussion only within SIP properties of B2BUA to get some common understanding of B2BUA as a SIP logical entity. In addition to few queries which Chinmay has pointed out,I can think of some basic points that need to be clarified/discussed about B2BUA : - Can B2BUA behave as a forwarding agent like Proxy, witout initiating a new dialog ? - Can B2BUA decide to Fork like a Proxy ? - Can B2BUA decide to switch between UAC/UAS and Proxy functionality like Proxy and Redirect functionality. - Is it mandatory for B2BUA to be always call-stateful ? - Since a UA can be stateless (RFC3261 Sec 8.2.7), is stateless B2BUA also possible ? - Finally, can B2BUA be called as a combination of "Proxy and UAS/UAC" or just "UAS/UAC" combo ? I know that the above list is not complete and possibly might have been answered before, but I do hope that this thread will bring some consensus on the more concrete "SIP definition" of B2BUA. I suggest that, to start with, there be some kind of FAQ regarding B2BUA documented somewhere. Any Comments ? thanks __amit > -----Original Message----- > From: Padhye, Chinmay [mailto:chinmay.padhye@intel.com] > Sent: Friday, November 08, 2002 12:26 AM > To: Bert Culpepper; Gonzalo Camarillo; Jonathan Rosenberg; Juan Luis > Esteban > Cc: sip@ietf.org > Subject: RE: [Sip] B2BUA question. > > > Hello, > > My response is inline starting with [Chinmay]. > > Regards, > > Chinmay > > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Thursday, November 07, 2002 12:04 AM > To: Padhye, Chinmay > Cc: Bert Culpepper; sip@ietf.org > Subject: Re: [Sip] B2BUA question. > > > Hi, > > I do not understand what you mean by "ONLY", but I will take > a stab at a > response anyway. If by "ONLY" you mean that it does not > implement other > protocols, the answer is no. A B2BUA can receive a SIP > request acting as > a SIP UAC, send an LDAP query acting as an LDAP client, and > then send a > SIP request acting as a SIP UAC. > > ---------------------------------- > [Chinmay] > > I think its better if we separate logical entities with > physical entities or applications that contain/behave as > multiple logical entities. An application may contain a B2BUA > logical entity, a LDAP client, a proxy entity, a registrar > entity, etc. A physical entity may contain many such applications. > > My statement - 'the B2BUA logical entity is a > combination of "ONLY" the UAC and UAS logical entities. Is > this an accurate statement?', was meant only for the B2BUA > logical entity and not for the application. > > Hence in the above example the B2BUA logical entity > cannot send the LDAP query. The LDAP client, which is part of > the same application, sends the LDAP query. > ---------------------------------- > > A B2BUA handles two dialogs, and it behaves as a UA for both dialogs. > The B2BUA typically uses information in requests or responses in one > dialog to create requests or responses in the other one. An > example of a > B2BUA is a 3rd party call controller. > > ---------------------------------- > [Chinmay] > > I need some more clarifications on some scenarios. > > Consider the following scenarios. > > Scenario 1 - > > UA1 B2BUA UA2 > |-- INVITE -------> | | > | CID:1 | -- INVITE ---->| > CID:x > > In the above scenario can 'x' take the value 1? > > IMO this x MUST not be equal to 1, because the UAC part > of the B2BUA must not use CID:1 to generate the outgoing > INVITE. Is this right. > > Scenario 2 - > > I am not sure if this part of the email belongs here or > in the implementers list. Let me know if I should move this > part of the email to the implementers list. > > UA1 B2BUA UA2 UA3 > |-- INVITE -------> | | | > | CID:1 | -- INVITE ---->| | > | | CID:2 | | > | | | | > | | -- INVITE ----------------->| > | | CID:3 | | > | | | | > | | <-- 200 OK --- | | > | <---- 200 OK ---- | | | > | | <-- 200 OK -----------------| > | <----- 200 OK --- | | | > ????????? > Can this be forwarded. > > In this scenario the B2BUA, on receiving the INVITE request > from UA1, generates new INVITE request to two UAs, UA2 and > UA3. (A similar scenario will occur if a downstream proxy > forks and receives multiple 200 OKs.) > > - Can the B2BUA generate two INVITE/Requests, for one > incoming INVITE/Request? Is this allowed by the > protocol/definition of B2BUA? > > IMO this should be allowed. > > Now both the UAs respond with 200 OK responses. > > - Is the B2BUA allowed to generate two responses towards UA1 > (with different to-tags)? > > IMO this also should be allowed. > > ---------------------------------- > > Regards, > > Gonzalo > > > "Padhye, Chinmay" wrote: > > > > Hello, > > > > Thanks for the reply. > > > > So the B2BUA logical entity is a combination of > "ONLY" the UAC and UAS logical entities. Is this an accurate > statement? > > > > Regards, > > > > Chinmay > > > > -----Original Message----- > > From: Bert Culpepper [mailto:bertculpepper@netscape.net] > > Sent: Wednesday, November 06, 2002 6:23 PM > > To: Padhye, Chinmay > > Cc: sip@ietf.org > > Subject: Re: [Sip] B2BUA question. > > > > Hi, > > > > I'll provide my opinion on why this term was included in > RFC3261, other > > folks may provide different/better reasons. > > > > The previous RFC defined UAC, UAS, Registar, Proxy, and > Redirect Server > > logical entities. As services (both legacy and new) were > designed using > > SIP, it was determined that a combination of defined > logical entities > > was needed to implement the services and still be compliant with the > > specification. This particular combination became common > enough that (I > > presume) the authors thought it should be mentioned in the > new RFC, to > > avoid mis-interpretation. > > > > Regards, > > Bert > > > > Padhye, Chinmay wrote: > > > > > Hello, > > > > > > This is from the definition of B2BUA from RFC 3261 - > > > > > > 'Since it is a concatenation of a UAC and UAS, no > explicit definitions are needed for its behavior." > > > > > > Since the behavior of a B2BUA is the same as the > behavior of a UAC/UAS, what was the need for defining a new > logical entity - B2BUA? I am trying to understand the > motivation behind adding this definition in the RFC. > > > > > > Regards, > > > > > > Chinmay > > > _______________________________________________ > > > 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 > > -- > 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 > _______________________________________________ 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 Nov 8 01:36:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28369 for ; Fri, 8 Nov 2002 01:36:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA86cEO22247 for sip-archive@odin.ietf.org; Fri, 8 Nov 2002 01:38: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 gA86bYv22200; Fri, 8 Nov 2002 01:37:34 -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 gA86aev21587 for ; Fri, 8 Nov 2002 01:36:40 -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 BAA28296 for ; Fri, 8 Nov 2002 01:33:59 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA86aRKV010071; Fri, 8 Nov 2002 07:36:27 +0100 (MET) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.112]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id gA86aRZb015466; Fri, 8 Nov 2002 08:36:27 +0200 (EET) Message-ID: <3DCB5B6E.514E40D9@lmf.ericsson.se> Date: Fri, 08 Nov 2002 08:36:30 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'hisham.khartabil@nokia.com'" , akristensen@dynamicsoft.com, sip@ietf.org Subject: Re: [Sip] SIPS question References: <15A2739B7DAA624D8091C65981D7DA815EB394@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 Hi, > I'm not sure I favor removal of this 8.1.2 text entirely. After some > reflection, I think what we're looking for is a rule that reflects the use > of SIPS in the destination address-of-record to which a request is sent (in > a dialog, this is largely applicable only to the initial request), not the > Request-URI. If we're concerned about the destination address-of-record of > the initial request, we should probably be talking about the To header > field. > > So, as a correction (to the text in 8.1.2 anyway) I might suggest something > like: > > "Independent of which URI is used as the input to the procedures of [4], if > the To header field specifies a SIPS resource, the UAC MUST follow the > procedures of [4] as if the input URI were a SIPS URI." A couple of questions on this: First, to make that "rule" above work in both directions, do we also need to specify that when the session is initiated there must be a SIPS-URI also in the From header, since the To and From values will be "switched" for requests sent in the other direction? I guess it's not enough if the UAC inserts SIPS-URI in the Contact header. Second, my understanding of this is also that this would PREVENT the use of TLS between specific nodes, let's say two proxies, in the path if the UAC did not require TLS by inserting SIPS-URI in the To header. EVEN if one proxy, P1, inserts a SIPS-URI Record-Route, a SIPS-URI Request-URI, and establish a TLS connection with P2, when a request is sent in the other direction (P2-to-P1) the To header SIP-URI would indicate that TLS shall not be used. Or, would the change affect UAs (maybe only UACs?) only? Regards, Christer Holmberg Ericsson Finland > Squinting at the flows for a moment, I don't see this giving rise to the > sort of concerns that Christer raised about the Contact header and > retargeting (when the SIPS URI is used in Route/Contact headers), but it > still provides the hBh-all-the-way property that SIPS was designed for. > A similar correction could be made to the informative text in 26.2.2. Any > thoughts about this? Any other text that would need to be amended? > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Monday, November 04, 2002 6:08 AM > > To: christer.holmberg@lmf.ericsson.se; jon.peterson@neustar.biz > > Cc: akristensen@dynamicsoft.com; sip@ietf.org > > Subject: RE: [Sip] SIPS question > > > > > > Removing this restriction seems to fix the problem, I think. > > > > "Independent > > of which URI is used as input to the procedures of [4], if the > > Request-URI specifies a SIPS resource, the UAC MUST follow the > > procedures of [4] as if the input URI were a SIPS URI." > > > > But also, would mandating that: if a REGISTER has a sips-uri > > contact, the To-header must contain a sips-uri work? and visa versa? > > > > eg: UA2 registers with sips-uri in both To-header and > > contact-header (sips in both or neither, but not mixed). > > > > In this case, UA2 home proxy will reject the request with 404 > > if UA1 sends a request with sip-uri. UA2 can also reject the > > request directly if it doesn't want to accept requests not using TLS. > > > > Regards, > > Hisham > > > > > -----Original Message----- > > > From: ext Christer Holmberg > > [mailto:christer.holmberg@lmf.ericsson.se] > > > Sent: Monday, November 04, 2002 1:55 PM > > > To: Peterson, Jon > > > Cc: 'Anders Kristensen'; sip@ietf.org > > > Subject: Re: [Sip] SIPS question > > > > > > > > > > > > Hi, > > > > > > > >Also, it's not only about mid-session requests, even if > > > that may be so in > > > > >most cases. Assume the Request-URI for the initial INVITE > > > is SIPS-URI, but > > > > the > > > > >UAC uses an outbound proxy, ie using a pre-configured > > > Route with SIP-URI. > > > > > > > > The design of SIPS used as the 'remote target', as the AoR of the > > > > destination, necessitates that this first hop go over TLS. > > > Look, as I said, > > > > outbound proxies are proxy servers, proxy servers MUST > > > support TLS, and > > > > entities that support TLS MUST support SIPS. Converting > > > this Route header to > > > > a TLS route is plausible and allowed by the spec. > > > > > > Yes, but the problem is again if the UAC doesn't support TLS. > > > Assume the UAC > > > gets the Request-URI SIPS-URI from some "external source" > > > (ENUM, data base, > > > whatever...), but since it uses an outbound proxy, using a > > > predefined Route with > > > SIP-URI, it doesn't care about the Request-URI SIPS-URI. > > > > > > I don't know if that scenario is "allowed" or not, but my > > > point was that the > > > problem would be the same as for mid-session requests. > > > > > > > We considered both transport parameters (transport=tls was > > > obsoleted in > > > > favor of SIPS, as I'm sure you recall) and > > > Require/Supported option tags in > > > > our deliberations about SIPS. The point is that we wanted > > a resource > > > > identifier that indicates directly that it should be > > > contacted securely. > > > > > > Another option would be that the URI in the TO header, which > > > IS end-to-end, > > > would be used to indicate if to use TLS or not. That would > > > not allow that TLS is > > > used between specific hops only, though. > > > > > > Now, however, TLS would be used for the mid-session requests > > > EVEN if the record > > > routing proxies insert SIP-URI in the Record-Route headers, > > > and/or the UAC > > > inserts SIP-URI in the Contact header, since the TO header > > > URI would not change. > > > > > > Now TLS would always be used for the whole session, and not > > > only for the INVITE, > > > but I assume that is how most people intend to use it anyway. Or? > > > > > > But, I still think the easiest fix would be to change the > > > text as proposed > > > earlier. Then, we may have to write something about the > > > outbound proxy scenario > > > - or use Jonathan's proposal to use TLS only if the previous > > > hop used TLS > > > (assuming we want to use TLS end-to-end ONLY, that is). > > > > > > 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 > > > > > _______________________________________________ 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 Nov 8 01:59:36 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28774 for ; Fri, 8 Nov 2002 01:59:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA871jl23111 for sip-archive@odin.ietf.org; Fri, 8 Nov 2002 02:01: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 gA871Nv23064; Fri, 8 Nov 2002 02:01: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 gA7KZ4v15513 for ; Thu, 7 Nov 2002 15:35:04 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08965 for <1timer>; Thu, 7 Nov 2002 15:11:40 -0500 (EST) Message-Id: <200211072011.PAA08965@ietf.org> From: The IESG To: All IETF Working Groups: ; x-msg: NoteWell Date: Thu, 07 Nov 2002 15:11:40 -0500 Subject: [Sip] Note Well Statement 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: , From time to time, especially just before a meeting, this statement is to be sent to each and every IETF working group mailing list. =========================================================================== NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. _______________________________________________ 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 Nov 8 01:59:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28787 for ; Fri, 8 Nov 2002 01:59:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA871sr23126 for sip-archive@odin.ietf.org; Fri, 8 Nov 2002 02:01: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 gA871bv23083; Fri, 8 Nov 2002 02: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 gA7Lmdv23541 for ; Thu, 7 Nov 2002 16:48:39 -0500 Received: from ronda.convergentnet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14642 for ; Thu, 7 Nov 2002 16:46:04 -0500 (EST) Received: by RONDA with Internet Mail Service (5.5.2655.55) id ; Thu, 7 Nov 2002 16:33:36 -0500 Message-ID: From: "Zhang, Bo" To: "'Kevin Lingle'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] SIP MIB module ID conflicts Date: Thu, 7 Nov 2002 16:33:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) 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: , Hello, all, Besides the OID question, I'm a little confused on the port table in common MIB and the server table in UA MIB. The row of the port table only specifies rcv and snd transport protocols. It does NOT contain IP address or port ID to be used for the port. How is the port used exactly? It looks like that each row in the UA server table specifies a UAS that a UAC can contact. It is used for outbound proxy, right? I would greatly appreciate it if anyone can help me out here. Bo -----Original Message----- From: Kevin Lingle [mailto:klingle@cisco.com] Sent: Friday, November 01, 2002 7:23 AM To: Zhang, Bo Cc: 'sip@ietf.org' Subject: Re: [Sip] SIP MIB module ID conflicts "Zhang, Bo" wrote: > > Hello, all, > > I got a SIP MIB draft 04 version from > > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-mib-04.txt. > > I'm NOT sure if this is the latest. But in it, there is a conflict > definition > of Module ID. The sipTC and sipUAMIB both have module ID of > { mib-2 9992 }. If this has already been fixed, could some one post > the latest document? bo, -04 is the latest published version of the doc. -05 is planned, but for several reasons has been slow coming. wrt the module id issues... those mib-2 oids are placeholders anyway. they are not official IANA assigned numbers, so the conflict is not a big issue. granted, they should be unique, but no one should be attempting to implement these mibs as "mib-2 " anyway. they are draft mibs at this point. i will make sure they have unique oids for the next revision though. btw, we expect -05 revision to be the last before we go to IESG for an rfc. -04 _was_ ready for that, but the coming of RFC 3261 caused us to pause (didn't expect to pause this long though;) and update the mib draft to be inline with the new sip rfc. thanks kevin > > Thanks, > > Bo > _______________________________________________ > 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 checkout: http://wwwin-eng.cisco.com/Eng/IOS/SNMP_WWW/mib-police/ Sometimes I think I understand everything, then I regain consciousness. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= _______________________________________________ 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 Nov 8 02:10:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08707 for ; Fri, 8 Nov 2002 02:10:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA87D9v31979 for sip-archive@odin.ietf.org; Fri, 8 Nov 2002 02:13: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 gA87Cbv31956; Fri, 8 Nov 2002 02:12: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 gA879tv30715 for ; Fri, 8 Nov 2002 02:09:55 -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 CAA08337 for ; Fri, 8 Nov 2002 02:07:13 -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.34 #1 (Debian)) id 18A3Gs-0003Nq-00; Fri, 08 Nov 2002 09:09:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15819.25394.673375.798212@harjus.eng.song.fi> Date: Fri, 8 Nov 2002 09:09:38 +0200 To: Christer Holmberg Cc: "Peterson, Jon" , "'hisham.khartabil@nokia.com'" , akristensen@dynamicsoft.com, sip@ietf.org Subject: Re: [Sip] SIPS question In-Reply-To: <3DCB5B6E.514E40D9@lmf.ericsson.se> References: <15A2739B7DAA624D8091C65981D7DA815EB394@stntexch2.va.neustar.com> <3DCB5B6E.514E40D9@lmf.ericsson.se> X-Mailer: VM 7.03 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 this SIPS discussion reminds me about the dangers of rushing something new and unimplemented into a standards specification at the last minute. i have the feeling that the working group should start slowing down introduction of new specifications and extensions before the existing stuff has been widely implemented. -- 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 Fri Nov 8 02:21:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08834 for ; Fri, 8 Nov 2002 02:21:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA87Nt500581 for sip-archive@odin.ietf.org; Fri, 8 Nov 2002 02:23: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 gA87NOv00565; Fri, 8 Nov 2002 02:23: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 gA87K7v00461 for ; Fri, 8 Nov 2002 02:20:07 -0500 Received: from Mistralsoftware.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08806 for ; Fri, 8 Nov 2002 02:17:23 -0500 (EST) Received: from gauthamL [192.168.11.26] by mistralsoftware.com [192.168.10.12] with SMTP (MDaemon.PRO.v5.0.0.R) for ; Fri, 08 Nov 2002 13:02:19 +0530 Date: Fri, 8 Nov 2002 12:55:09 +0530 From: "A. N. Gautham" To: "Padhye, Chinmay" Cc: sip@ietf.org Subject: Re: [Sip] B2BUA question. Message-Id: <20021108125509.61119e2c.gautham@mistralsoftware.com> In-Reply-To: References: Organization: Mistral X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MDRemoteIP: 192.168.11.26 X-Return-Path: gautham@mistralsoftware.com X-MDaemon-Deliver-To: sip@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 Hi, The way I understand the definition of a B2BUA, it is combination of 2 User Agents. Their behaviour in all respects is like that of 2 endpoints. So, in the following scenario: A<--------->((UA-1) (UA-2))<------------>B A calls the B2BUA, which consists of UA-1 and UA-2. In response to that, UA-2 initiates a dialog with B. So, for all 'protocol' purposes, A---UA1 and UA-2---B are different dialogs. From this it follows, that the call-ids must be different. Also, since an endpoint would never send two '200 ok's, UA-1 can also not 'forward' more than one '200 ok'. Please correct me if I am wrong. Hope this helps. Regards, A. N. Gautham. On Thu, 7 Nov 2002 10:56:10 -0800 "Padhye, Chinmay" wrote: > Hello, > > My response is inline starting with [Chinmay]. > > Regards, > > Chinmay > > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Thursday, November 07, 2002 12:04 AM > To: Padhye, Chinmay > Cc: Bert Culpepper; sip@ietf.org > Subject: Re: [Sip] B2BUA question. > > > Hi, > > I do not understand what you mean by "ONLY", but I will take a stab at a > response anyway. If by "ONLY" you mean that it does not implement other > protocols, the answer is no. A B2BUA can receive a SIP request acting as > a SIP UAC, send an LDAP query acting as an LDAP client, and then send a > SIP request acting as a SIP UAC. > > ---------------------------------- > [Chinmay] > > I think its better if we separate logical entities with physical entities or applications that contain/behave as multiple logical entities. An application may contain a B2BUA logical entity, a LDAP client, a proxy entity, a registrar entity, etc. A physical entity may contain many such applications. > > My statement - 'the B2BUA logical entity is a combination of "ONLY" the UAC and UAS logical entities. Is this an accurate statement?', was meant only for the B2BUA logical entity and not for the application. > > Hence in the above example the B2BUA logical entity cannot send the LDAP query. The LDAP client, which is part of the same application, sends the LDAP query. > ---------------------------------- > > A B2BUA handles two dialogs, and it behaves as a UA for both dialogs. > The B2BUA typically uses information in requests or responses in one > dialog to create requests or responses in the other one. An example of a > B2BUA is a 3rd party call controller. > > ---------------------------------- > [Chinmay] > > I need some more clarifications on some scenarios. > > Consider the following scenarios. > > Scenario 1 - > > UA1 B2BUA UA2 > |-- INVITE -------> | | > | CID:1 | -- INVITE ---->| > CID:x > > In the above scenario can 'x' take the value 1? > > IMO this x MUST not be equal to 1, because the UAC part of the B2BUA must not use CID:1 to generate the outgoing INVITE. Is this right. > > Scenario 2 - > > I am not sure if this part of the email belongs here or in the implementers list. Let me know if I should move this part of the email to the implementers list. > > UA1 B2BUA UA2 UA3 > |-- INVITE -------> | | | > | CID:1 | -- INVITE ---->| | > | | CID:2 | | > | | | | > | | -- INVITE ----------------->| > | | CID:3 | | > | | | | > | | <-- 200 OK --- | | > | <---- 200 OK ---- | | | > | | <-- 200 OK -----------------| > | <----- 200 OK --- | | | > ????????? > Can this be forwarded. > > In this scenario the B2BUA, on receiving the INVITE request from UA1, generates new INVITE request to two UAs, UA2 and UA3. (A similar scenario will occur if a downstream proxy forks and receives multiple 200 OKs.) > > - Can the B2BUA generate two INVITE/Requests, for one incoming INVITE/Request? Is this allowed by the protocol/definition of B2BUA? > > IMO this should be allowed. > > Now both the UAs respond with 200 OK responses. > > - Is the B2BUA allowed to generate two responses towards UA1 (with different to-tags)? > > IMO this also should be allowed. > > ---------------------------------- > > Regards, > > Gonzalo > > > "Padhye, Chinmay" wrote: > > > > Hello, > > > > Thanks for the reply. > > > > So the B2BUA logical entity is a combination of "ONLY" the UAC and UAS logical entities. Is this an accurate statement? > > > > Regards, > > > > Chinmay > > > > -----Original Message----- > > From: Bert Culpepper [mailto:bertculpepper@netscape.net] > > Sent: Wednesday, November 06, 2002 6:23 PM > > To: Padhye, Chinmay > > Cc: sip@ietf.org > > Subject: Re: [Sip] B2BUA question. > > > > Hi, > > > > I'll provide my opinion on why this term was included in RFC3261, other > > folks may provide different/better reasons. > > > > The previous RFC defined UAC, UAS, Registar, Proxy, and Redirect Server > > logical entities. As services (both legacy and new) were designed using > > SIP, it was determined that a combination of defined logical entities > > was needed to implement the services and still be compliant with the > > specification. This particular combination became common enough that (I > > presume) the authors thought it should be mentioned in the new RFC, to > > avoid mis-interpretation. > > > > Regards, > > Bert > > > > Padhye, Chinmay wrote: > > > > > Hello, > > > > > > This is from the definition of B2BUA from RFC 3261 - > > > > > > 'Since it is a concatenation of a UAC and UAS, no explicit definitions are needed for its behavior." > > > > > > Since the behavior of a B2BUA is the same as the behavior of a UAC/UAS, what was the need for defining a new logical entity - B2BUA? I am trying to understand the motivation behind adding this definition in the RFC. > > > > > > Regards, > > > > > > Chinmay > > > _______________________________________________ > > > 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 > > -- > 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 > _______________________________________________ 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 Nov 8 04:19:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11236 for ; Fri, 8 Nov 2002 04:19:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA89LL708320 for sip-archive@odin.ietf.org; Fri, 8 Nov 2002 04:21: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 gA89Jxv08236; Fri, 8 Nov 2002 04:19:59 -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 gA89J0v08203 for ; Fri, 8 Nov 2002 04:19:00 -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 EAA11211 for ; Fri, 8 Nov 2002 04:16:19 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA89IgKV028750; Fri, 8 Nov 2002 10:18:42 +0100 (MET) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.51]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id gA89IfZb025580; Fri, 8 Nov 2002 11:18:41 +0200 (EET) Message-ID: <3DCB8177.87FBB0BD@lmf.ericsson.se> Date: Fri, 08 Nov 2002 11:18:47 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Prasanna CC: sip@ietf.org, schulzrinne@cs.columbia.edu, Gonzalo.Camarillo@ericsson.com, oran@cisco.com, ranjit@huawei.com References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: definition of 155 (Update Requested) response code 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, The 155 status code will not be defined by the Reason spec. It will eventually be defined when we work on a solution for the HERFP issue. Thanks for the comment, Gonzalo Prasanna wrote: > > Hi, > Now that RFC-3311 (UPDATE) does not define the 155 response code, which > document defines the 155 response code. As this is referred for HERFP in > the "reason" draft, is it proposed that the "reason" draft will define this > code. > Thanks and Regards, > Prasanna > Huawei Technologies. _______________________________________________ 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 Nov 8 04:37:37 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11522 for ; Fri, 8 Nov 2002 04:37:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA89dlM09888 for sip-archive@odin.ietf.org; Fri, 8 Nov 2002 04:39: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 gA89dOv09856; Fri, 8 Nov 2002 04:39: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 gA89b2v09219 for ; Fri, 8 Nov 2002 04:37:02 -0500 Received: from capmail.MX.talkyonline.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11463 for ; Fri, 8 Nov 2002 04:34:21 -0500 (EST) Received: by capmail.MX.talkyonline.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Nov 2002 10:33:00 +0100 Message-ID: From: Juan Luis Esteban To: "'Padhye, Chinmay'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] B2BUA question. Date: Fri, 8 Nov 2002 10:32:53 +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 gA89b2v09220 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, Regarding scenario 1, I think you´re right. per RFC326, CIDs must be globally unique, and dialog IDs at each UA consist of Call-ID + local tag + remote tag. Since the B2BUA mantains 2 dialogs, one as UAS and another one as UAC, I agree that Call-IDs must be different. Regarding scenario 2, dialog at UA1 will be instantiated based on the first 200OK received with the to tag. I think that only one dialog will be created/mantained by UA1. Nevertheless, it should be possible that the B2BUA create 2 dialogs with UA2 and UA3 and perform some kind of audio mixing, which is an implementation choice. I would think that scenario 2 could be though of as a simple conferencing bridge implemented with a B2BUA. (?) Nevertheless, I think that the second 200OK from B2BUA to UA1 should not be sent. B2BUA does not need to mantain two dialogs at the UAS side in this example, nor does UA1. regards, -----Mensaje original----- De: Padhye, Chinmay [mailto:chinmay.padhye@intel.com] Enviado el: jueves, 07 de noviembre de 2002 19:56 Para: Bert Culpepper; Gonzalo Camarillo; Jonathan Rosenberg; Juan Luis Esteban CC: sip@ietf.org Asunto: RE: [Sip] B2BUA question. Hello, My response is inline starting with [Chinmay]. Regards, Chinmay -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: Thursday, November 07, 2002 12:04 AM To: Padhye, Chinmay Cc: Bert Culpepper; sip@ietf.org Subject: Re: [Sip] B2BUA question. Hi, I do not understand what you mean by "ONLY", but I will take a stab at a response anyway. If by "ONLY" you mean that it does not implement other protocols, the answer is no. A B2BUA can receive a SIP request acting as a SIP UAC, send an LDAP query acting as an LDAP client, and then send a SIP request acting as a SIP UAC. ---------------------------------- [Chinmay] I think its better if we separate logical entities with physical entities or applications that contain/behave as multiple logical entities. An application may contain a B2BUA logical entity, a LDAP client, a proxy entity, a registrar entity, etc. A physical entity may contain many such applications. My statement - 'the B2BUA logical entity is a combination of "ONLY" the UAC and UAS logical entities. Is this an accurate statement?', was meant only for the B2BUA logical entity and not for the application. Hence in the above example the B2BUA logical entity cannot send the LDAP query. The LDAP client, which is part of the same application, sends the LDAP query. ---------------------------------- A B2BUA handles two dialogs, and it behaves as a UA for both dialogs. The B2BUA typically uses information in requests or responses in one dialog to create requests or responses in the other one. An example of a B2BUA is a 3rd party call controller. ---------------------------------- [Chinmay] I need some more clarifications on some scenarios. Consider the following scenarios. Scenario 1 - UA1 B2BUA UA2 |-- INVITE -------> | | | CID:1 | -- INVITE ---->| CID:x In the above scenario can 'x' take the value 1? IMO this x MUST not be equal to 1, because the UAC part of the B2BUA must not use CID:1 to generate the outgoing INVITE. Is this right. Scenario 2 - I am not sure if this part of the email belongs here or in the implementers list. Let me know if I should move this part of the email to the implementers list. UA1 B2BUA UA2 UA3 |-- INVITE -------> | | | | CID:1 | -- INVITE ---->| | | | CID:2 | | | | | | | | -- INVITE ----------------->| | | CID:3 | | | | | | | | <-- 200 OK --- | | | <---- 200 OK ---- | | | | | <-- 200 OK -----------------| | <----- 200 OK --- | | | ????????? Can this be forwarded. In this scenario the B2BUA, on receiving the INVITE request from UA1, generates new INVITE request to two UAs, UA2 and UA3. (A similar scenario will occur if a downstream proxy forks and receives multiple 200 OKs.) - Can the B2BUA generate two INVITE/Requests, for one incoming INVITE/Request? Is this allowed by the protocol/definition of B2BUA? IMO this should be allowed. Now both the UAs respond with 200 OK responses. - Is the B2BUA allowed to generate two responses towards UA1 (with different to-tags)? IMO this also should be allowed. ---------------------------------- Regards, Gonzalo "Padhye, Chinmay" wrote: > > Hello, > > Thanks for the reply. > > So the B2BUA logical entity is a combination of "ONLY" the UAC and UAS logical entities. Is this an accurate statement? > > Regards, > > Chinmay > > -----Original Message----- > From: Bert Culpepper [mailto:bertculpepper@netscape.net] > Sent: Wednesday, November 06, 2002 6:23 PM > To: Padhye, Chinmay > Cc: sip@ietf.org > Subject: Re: [Sip] B2BUA question. > > Hi, > > I'll provide my opinion on why this term was included in RFC3261, other > folks may provide different/better reasons. > > The previous RFC defined UAC, UAS, Registar, Proxy, and Redirect Server > logical entities. As services (both legacy and new) were designed using > SIP, it was determined that a combination of defined logical entities > was needed to implement the services and still be compliant with the > specification. This particular combination became common enough that (I > presume) the authors thought it should be mentioned in the new RFC, to > avoid mis-interpretation. > > Regards, > Bert > > Padhye, Chinmay wrote: > > > Hello, > > > > This is from the definition of B2BUA from RFC 3261 - > > > > 'Since it is a concatenation of a UAC and UAS, no explicit definitions are needed for its behavior." > > > > Since the behavior of a B2BUA is the same as the behavior of a UAC/UAS, what was the need for defining a new logical entity - B2BUA? I am trying to understand the motivation behind adding this definition in the RFC. > > > > Regards, > > > > Chinmay > > _______________________________________________ > > 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 -- 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 Fri Nov 8 07:16:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14222 for ; Fri, 8 Nov 2002 07:16:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8CI8G18662 for sip-archive@odin.ietf.org; Fri, 8 Nov 2002 07: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 gA8CHdv18566; Fri, 8 Nov 2002 07:17: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 gA8CGQv18515 for ; Fri, 8 Nov 2002 07:16:26 -0500 Received: from mail-blue.research.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14121 for ; Fri, 8 Nov 2002 07:13:54 -0500 (EST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id B6D7E4CF1B; Fri, 8 Nov 2002 07:16:23 -0500 (EST) Received: from research.att.com (guard.research.att.com [135.207.1.20]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id HAA03582; Fri, 8 Nov 2002 07:16:22 -0500 (EST) Message-ID: <3DCBAB17.DDDB4633@research.att.com> Date: Fri, 08 Nov 2002 07:16:23 -0500 From: Eric Cheung Organization: AT&T Labs Research X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Padhye, Chinmay" Cc: sip@ietf.org Subject: Re: [Sip] B2BUA question. 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 Some comments re scenario 2 inline. Eric > Scenario 2 - > > I am not sure if this part of the email belongs here or in the implementers list. Let me know if I should move this part of the email to the implementers list. > > UA1 B2BUA UA2 UA3 > |-- INVITE -------> | | | > | CID:1 | -- INVITE ---->| | > | | CID:2 | | > | | | | > | | -- INVITE ----------------->| > | | CID:3 | | > | | | | > | | <-- 200 OK --- | | > | <---- 200 OK ---- | | | > | | <-- 200 OK -----------------| > | <----- 200 OK --- | | | > ????????? > Can this be forwarded. > > In this scenario the B2BUA, on receiving the INVITE request from UA1, generates new INVITE request to two UAs, UA2 and UA3. (A similar scenario will occur if a downstream proxy forks and receives multiple 200 OKs.) > > - Can the B2BUA generate two INVITE/Requests, for one incoming INVITE/Request? Is this allowed by the protocol/definition of B2BUA? > > IMO this should be allowed. Yes, this is allowed. The B2BUA at this point would look like: |----|-----| | | UAC | |UAS |-----| | | UAC | |----|-----| > > Now both the UAs respond with 200 OK responses. > > - Is the B2BUA allowed to generate two responses towards UA1 (with different to-tags)? > > IMO this also should be allowed. No, I don't think this is allowed. These are 3 completely distinct SIP dialogs. In fact, the 200 OK sent by UAS to UA1 should have a different to-tag from the to-tag received from UA2 and UA3. _______________________________________________ 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 Nov 8 07:29:38 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14510 for ; Fri, 8 Nov 2002 07:29:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8CVd619196 for sip-archive@odin.ietf.org; Fri, 8 Nov 2002 07:31: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 gA8CV7v19138; Fri, 8 Nov 2002 07:31: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 gA8CT8v19075 for ; Fri, 8 Nov 2002 07:29:08 -0500 Received: from mail-blue.research.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14465 for ; Fri, 8 Nov 2002 07:26:36 -0500 (EST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id 434A44CF1B; Fri, 8 Nov 2002 07:29:06 -0500 (EST) Received: from research.att.com (guard.research.att.com [135.207.1.20]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id HAA03748; Fri, 8 Nov 2002 07:29:05 -0500 (EST) Message-ID: <3DCBAE11.4D049A39@research.att.com> Date: Fri, 08 Nov 2002 07:29:05 -0500 From: Eric Cheung Organization: AT&T Labs Research X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kaul, Amit" , sip@ietf.org Subject: Re: [Sip] B2BUA question. References: <12B638FEE763F74696D8544752E7204801BACC2B@bgsmsx101.iind.intel.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 Some of my opinion below. I agree that there is a need for some common understanding of B2BUA. Perhaps an informational I-D is in order. Eric "Kaul, Amit" wrote: > > I agree that we might want to limit our discussion only within SIP > properties > of B2BUA to get some common understanding of B2BUA as a SIP logical entity. > > In addition to few queries which Chinmay has pointed out,I can think of > some basic points that need to be clarified/discussed about B2BUA : > > - Can B2BUA behave as a forwarding agent like Proxy, witout initiating > a new dialog ? No. Remember B2BUA, Proxy etc are logical entity. A physical implementation (say call it a SIP server) may be a combination of a B2BUA and a Proxy, and an INVITE may be handled by the Proxy part. > > - Can B2BUA decide to Fork like a Proxy ? A B2BUA can certainly make 2 outbound calls on receipt of 1 incoming call. But the call flow is different from a Proxy e.g. Chinmay scenario 2 > > - Can B2BUA decide to switch between UAC/UAS and Proxy functionality like > > Proxy and Redirect functionality. As above, a SIP server that implements the B2BUA, Proxy and Redirect server logical entities can do this. > > - Is it mandatory for B2BUA to be always call-stateful ? Yes, I think so. > > - Since a UA can be stateless (RFC3261 Sec 8.2.7), is stateless B2BUA > also possible ? The UAS part of a B2BUA can behave in the way describe in sec 8.2.7 to challenge unauthenticated requests. > > - Finally, can B2BUA be called as a combination of "Proxy and UAS/UAC" > or just "UAS/UAC" combo ? See above. I think it is cleaner to keep the logical entities as clean as possible. _______________________________________________ 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 Nov 8 09:22:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19523 for ; Fri, 8 Nov 2002 09:22:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8EOjc28352 for sip-archive@odin.ietf.org; Fri, 8 Nov 2002 09:24: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 gA8EO8v28320; Fri, 8 Nov 2002 09:24: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 gA8EMTv28234 for ; Fri, 8 Nov 2002 09:22:29 -0500 Received: from d12lmsgate-5.de.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19419 for ; Fri, 8 Nov 2002 09:19:54 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id gA8EMNvx048230 for ; Fri, 8 Nov 2002 15:22:23 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gA8EMNCZ127630 for ; Fri, 8 Nov 2002 15:22:23 +0100 To: sip@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 Message-ID: From: "Avshalom Houri" Date: Fri, 8 Nov 2002 16:22:20 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 08/11/2002 16:22:23, Serialize complete at 08/11/2002 16:22:23 Content-Type: multipart/alternative; boundary="=_alternative 004EEB25C2256C6B_=" Subject: [Sip] LDAP servers and SIP Authentication 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 004EEB25C2256C6B_= Content-Type: text/plain; charset="US-ASCII" Since basic authentication has been deprecated from SIP and LDAP servers do not support a uniform way for querying passwords. It seems that there is a problem with using SIP with LDAP server as a directory. For example, some LDAP servers return the user's password hashed (using MD5 or SHA or something else) but we cannot compare this with the hashed password from the client, even if the same hashing algorithm was used, because LDAP returns only the password hashed, while the client-supplied hash includes more info in the digest. The only way we can do this is by getting the password cleartext from LDAP, and do our own digest, but most LDAP servers do not allow that, not even for the directory admin. Any ideas? Thanks Avshalom --=_alternative 004EEB25C2256C6B_= Content-Type: text/html; charset="US-ASCII"
Since basic authentication has been deprecated from SIP and LDAP servers do not
support a uniform way for querying passwords. It seems that there is a problem with
using SIP with LDAP server as a directory.

For example, some LDAP servers return the user's password hashed (using MD5 or SHA
or something else) but we cannot compare this with the hashed password from the client,
even if the same hashing algorithm was used, because LDAP returns only the password
hashed, while the client-supplied hash includes more info in the digest. The only way we
can do this is by getting the password cleartext from LDAP, and do our own digest, but most
LDAP servers do not allow that, not even for the directory admin.

Any ideas?

Thanks
Avshalom


--=_alternative 004EEB25C2256C6B_=-- _______________________________________________ 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 Nov 8 10:21:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22028 for ; Fri, 8 Nov 2002 10:21:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8FN5C01007 for sip-archive@odin.ietf.org; Fri, 8 Nov 2002 10:23: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 gA8FMXv00942; Fri, 8 Nov 2002 10:22: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 gA8FLrv00855 for ; Fri, 8 Nov 2002 10:21:53 -0500 Received: from gorilla.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21915 for ; Fri, 8 Nov 2002 10:19:20 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id QAA14729 for ; Fri, 8 Nov 2002 16:21:46 +0100 (MET) Received: from siemens.com ([139.21.4.37]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id QAA25909 for ; Fri, 8 Nov 2002 16:21:47 +0100 (MET) Message-ID: <3DCBD689.9030805@siemens.com> Date: Fri, 08 Nov 2002 16:21:45 +0100 From: Peter =?UTF-8?B?UMOkcHBpbmdoYXVz?= Organization: Siemens AG User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en,de MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Sip] Buggy example in draft-ietf-sipping-reg-event-00 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, I believe to have stumbled on a buggy example in draft-ietf-sipping-reg-event-00.txt. Quotation from top of p. 19: "Later on, the user registers (5): REGISTER sip:joe@bar.com SIP/2.0 Via: SIP/2.0/UDP pc34.bar.com;branch=z9hG4bKnaaff From: sip:joe@bar.com;tag=99a8s To: sip:joe@bar.com Call-ID: 88askjda9@pc34.bar.com CSeq: 9976 REGISTER Contact: sip:joe@pc34.bar.com" The Request-URI in this example violates RFC 3261, sec. 10.2: "The userinfo and "@" components of the SIP URI MUST NOT be present." Regards, Peter Paeppinghaus -- Dr. Peter Päppinghaus Siemens AG | Phone: +49 89 - 722 40065 ICM N PG U ID A1 | Fax: +49 89 - 722 58726 Hofmannstr. 51 | Visitors: Building 1713 / Room 714 D - 81359 München | Email: peter.paeppinghaus@siemens.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 Nov 8 10:24:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22337 for ; Fri, 8 Nov 2002 10:24:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8FQ5v01345 for sip-archive@odin.ietf.org; Fri, 8 Nov 2002 10:26: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 gA8FPQv01252; Fri, 8 Nov 2002 10:25: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 gA8FOXv01133 for ; Fri, 8 Nov 2002 10:24:33 -0500 Received: from gorilla.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22091 for ; Fri, 8 Nov 2002 10:21:59 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id QAA14923 for ; Fri, 8 Nov 2002 16:24:26 +0100 (MET) Received: from siemens.com ([139.21.4.37]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id QAA26393 for ; Fri, 8 Nov 2002 16:24:28 +0100 (MET) Message-ID: <3DCBD72A.30603@siemens.com> Date: Fri, 08 Nov 2002 16:24:26 +0100 From: Peter =?UTF-8?B?UMOkcHBpbmdoYXVz?= Organization: Siemens AG User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en,de MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Sip] Buggy example in RFC 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: , Content-Transfer-Encoding: 8bit Hi, I believe to have stumbled on a buggy example in RFC 3261. The 200 OK in the REGISTER example of RFC 3261, sec. 24.1 contains an Expires header, but no expires parameter in the Contact header. This violates RFC 3261, sec. 10.3, bullet 8: "Each Contact value MUST feature an "expires" parameter indicating its expiration interval chosen by the registrar." Regards, Peter Paeppinghaus -- Dr. Peter Päppinghaus Siemens AG | Phone: +49 89 - 722 40065 ICM N PG U ID A1 | Fax: +49 89 - 722 58726 Hofmannstr. 51 | Visitors: Building 1713 / Room 714 D - 81359 München | Email: peter.paeppinghaus@siemens.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 Nov 8 12:51:32 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02255 for ; Fri, 8 Nov 2002 12:51:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8Hrab15130 for sip-archive@odin.ietf.org; Fri, 8 Nov 2002 12:53: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 gA8Hqqv15115; Fri, 8 Nov 2002 12:52: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 gA8HpRv14996 for ; Fri, 8 Nov 2002 12:51:27 -0500 Received: from capmail.MX.talkyonline.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02136 for ; Fri, 8 Nov 2002 12:48:51 -0500 (EST) Received: by capmail.MX.talkyonline.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Nov 2002 18:47:31 +0100 Message-ID: From: Juan Luis Esteban To: "'sip@ietf.org'" Subject: RE: [Sip] B2BUA question. Date: Fri, 8 Nov 2002 18:47:27 +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 gA8HpRv14997 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 both cases should be possible, case 1) could be an example of a double stage dialing scenario where B2BUA is handling both RTP streams: eg. user dials in, is prompted for PIN/Destination Number, and afterwards the second INVITE is sent by the UAC side to UA2, and B2BUA chooses to proxy RTP to perform admission, RTP steering,aggregate RTP streams from/to different UAs, etc... case 2) could be a single stage dialing scenario. In both cases dialogs on both sides are established and mantained by the B2BUA, so the behavior is consistent with the B2BUA term. also, in case 2) B2BUA could decide to proxy RTP, or not, depending on SDP info in the second INVITE and in 200OK back to UA1. RTP streams could also flow directly between UA1 and UA2 in scenario 1) , in which case the UA1-B2BUA Dialog should be modified : Re-INVITE should be sent from B2BUA back to UA1 after receiving 200OK from UA2. My opìnion is that it is implementation/service specific how dialogs on both sides are coupled, and whether B2BUA handles RTP or not. -----Mensaje original----- De: Howard Hart [mailto:howard.hart@zultys.com] Enviado el: viernes, 08 de noviembre de 2002 17:55 Para: Kaul, Amit CC: Padhye, Chinmay; Bert Culpepper; Gonzalo Camarillo; Jonathan Rosenberg; Juan Luis Esteban Asunto: Re: [Sip] B2BUA question. The question that always comes to my mind on this is how independent are the 2 UA's? i.e. - if a B2BUA is literally 2 UA's cobbled together, does this mean they are: 1) 100% standalone, independent entities that just happen to be tied together: UA1 B2BUA UA2 |-- INVITE ------->| | |<-----200 OK------| -- INVITE ---->| |-- ACK ---------->|<-----200 OK----| | |-- ACK -------->| or 2) must they operate in lockstep to add some sanity to the process? UA1 B2BUA UA2 |-- INVITE ------->| | | | -- INVITE ---->| | |<-----200 OK----| |<-----200 OK------| | |-- ACK ---------->| | | |-- ACK -------->| Personally, I vote for 2). Doesn't make sense to create a UA1 to UA2 dialog, "virtual" or otherwise, until UA2 has opted in, but where is this documented? Or maybe option 1) does make sense where the B2BUA functions as a media/RTP gateway also? Does this make it something else, or is there yet another logical entity we're missing--B2BUA Media Gateway, too much layer mixing here? Howard Hart Kaul, Amit wrote: > I agree that we might want to limit our discussion only within SIP > properties > of B2BUA to get some common understanding of B2BUA as a SIP logical entity. > > In addition to few queries which Chinmay has pointed out,I can think of > some basic points that need to be clarified/discussed about B2BUA : > > - Can B2BUA behave as a forwarding agent like Proxy, witout initiating > a new dialog ? > > - Can B2BUA decide to Fork like a Proxy ? > > - Can B2BUA decide to switch between UAC/UAS and Proxy functionality like > > Proxy and Redirect functionality. > > - Is it mandatory for B2BUA to be always call-stateful ? > > - Since a UA can be stateless (RFC3261 Sec 8.2.7), is stateless B2BUA > also possible ? > > - Finally, can B2BUA be called as a combination of "Proxy and UAS/UAC" > or just "UAS/UAC" combo ? > > I know that the above list is not complete and possibly might have been > answered > before, but I do hope that this thread will bring some consensus on the more > > concrete "SIP definition" of B2BUA. > > I suggest that, to start with, there be some kind of FAQ regarding B2BUA > documented somewhere. Any Comments ? > > thanks > __amit > > >>-----Original Message----- >>From: Padhye, Chinmay [mailto:chinmay.padhye@intel.com] >>Sent: Friday, November 08, 2002 12:26 AM >>To: Bert Culpepper; Gonzalo Camarillo; Jonathan Rosenberg; Juan Luis >>Esteban >>Cc: sip@ietf.org >>Subject: RE: [Sip] B2BUA question. >> >> >>Hello, >> >> My response is inline starting with [Chinmay]. >> >>Regards, >> >>Chinmay >> >>-----Original Message----- >>From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] >>Sent: Thursday, November 07, 2002 12:04 AM >>To: Padhye, Chinmay >>Cc: Bert Culpepper; sip@ietf.org >>Subject: Re: [Sip] B2BUA question. >> >> >>Hi, >> >>I do not understand what you mean by "ONLY", but I will take >>a stab at a >>response anyway. If by "ONLY" you mean that it does not >>implement other >>protocols, the answer is no. A B2BUA can receive a SIP >>request acting as >>a SIP UAC, send an LDAP query acting as an LDAP client, and >>then send a >>SIP request acting as a SIP UAC. >> >>---------------------------------- >>[Chinmay] >> >> I think its better if we separate logical entities with >>physical entities or applications that contain/behave as >>multiple logical entities. An application may contain a B2BUA >>logical entity, a LDAP client, a proxy entity, a registrar >>entity, etc. A physical entity may contain many such applications. >> >> My statement - 'the B2BUA logical entity is a >>combination of "ONLY" the UAC and UAS logical entities. Is >>this an accurate statement?', was meant only for the B2BUA >>logical entity and not for the application. >> >> Hence in the above example the B2BUA logical entity >>cannot send the LDAP query. The LDAP client, which is part of >>the same application, sends the LDAP query. >>---------------------------------- >> >>A B2BUA handles two dialogs, and it behaves as a UA for both dialogs. >>The B2BUA typically uses information in requests or responses in one >>dialog to create requests or responses in the other one. An >>example of a >>B2BUA is a 3rd party call controller. >> >>---------------------------------- >>[Chinmay] >> >> I need some more clarifications on some scenarios. >> >> Consider the following scenarios. >> >>Scenario 1 - >> >> UA1 B2BUA UA2 >> |-- INVITE -------> | | >> | CID:1 | -- INVITE ---->| >> CID:x >> >> In the above scenario can 'x' take the value 1? >> >> IMO this x MUST not be equal to 1, because the UAC part >>of the B2BUA must not use CID:1 to generate the outgoing >>INVITE. Is this right. >> >>Scenario 2 - >> >> I am not sure if this part of the email belongs here or >>in the implementers list. Let me know if I should move this >>part of the email to the implementers list. >> >>UA1 B2BUA UA2 UA3 >>|-- INVITE -------> | | | >>| CID:1 | -- INVITE ---->| | >>| | CID:2 | | >>| | | | >>| | -- INVITE ----------------->| >>| | CID:3 | | >>| | | | >>| | <-- 200 OK --- | | >>| <---- 200 OK ---- | | | >>| | <-- 200 OK -----------------| >>| <----- 200 OK --- | | | >> ????????? >> Can this be forwarded. >> >>In this scenario the B2BUA, on receiving the INVITE request >>from UA1, generates new INVITE request to two UAs, UA2 and >>UA3. (A similar scenario will occur if a downstream proxy >>forks and receives multiple 200 OKs.) >> >>- Can the B2BUA generate two INVITE/Requests, for one >>incoming INVITE/Request? Is this allowed by the >>protocol/definition of B2BUA? >> >>IMO this should be allowed. >> >>Now both the UAs respond with 200 OK responses. >> >>- Is the B2BUA allowed to generate two responses towards UA1 >>(with different to-tags)? >> >>IMO this also should be allowed. >> >>---------------------------------- >> >>Regards, >> >>Gonzalo >> >> >>"Padhye, Chinmay" wrote: >> >>>Hello, >>> >>> Thanks for the reply. >>> >>> So the B2BUA logical entity is a combination of >> >>"ONLY" the UAC and UAS logical entities. Is this an accurate >>statement? >> >>>Regards, >>> >>>Chinmay >>> >>>-----Original Message----- >>>From: Bert Culpepper [mailto:bertculpepper@netscape.net] >>>Sent: Wednesday, November 06, 2002 6:23 PM >>>To: Padhye, Chinmay >>>Cc: sip@ietf.org >>>Subject: Re: [Sip] B2BUA question. >>> >>>Hi, >>> >>>I'll provide my opinion on why this term was included in >> >>RFC3261, other >> >>>folks may provide different/better reasons. >>> >>>The previous RFC defined UAC, UAS, Registar, Proxy, and >> >>Redirect Server >> >>>logical entities. As services (both legacy and new) were >> >>designed using >> >>>SIP, it was determined that a combination of defined >> >>logical entities >> >>>was needed to implement the services and still be compliant with the >>>specification. This particular combination became common >> >>enough that (I >> >>>presume) the authors thought it should be mentioned in the >> >>new RFC, to >> >>>avoid mis-interpretation. >>> >>>Regards, >>>Bert >>> >>>Padhye, Chinmay wrote: >>> >>> >>>>Hello, >>>> >>>> This is from the definition of B2BUA from RFC 3261 - >>>> >>>> 'Since it is a concatenation of a UAC and UAS, no >>> >>explicit definitions are needed for its behavior." >> >>>> Since the behavior of a B2BUA is the same as the >>> >>behavior of a UAC/UAS, what was the need for defining a new >>logical entity - B2BUA? I am trying to understand the >>motivation behind adding this definition in the RFC. >> >>>>Regards, >>>> >>>>Chinmay >>>>_______________________________________________ >>>>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 >> >>-- >>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 >> > > _______________________________________________ > 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 Nov 8 13:35:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05856 for ; Fri, 8 Nov 2002 13:35:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8IbqB19413 for sip-archive@odin.ietf.org; Fri, 8 Nov 2002 13:37: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 gA8IbRv19369; Fri, 8 Nov 2002 13:37: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 gA8IYTv18634 for ; Fri, 8 Nov 2002 13:34:29 -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 NAA05614 for ; Fri, 8 Nov 2002 13:31:52 -0500 (EST) Received: from jku07.fokus.fraunhofer.de (80-24-93-126.uc.nombres.ttd.es [80.24.93.126]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id gA8IXZn21918; Fri, 8 Nov 2002 19:33:35 +0100 Message-Id: <5.1.0.14.0.20021108183934.03607e70@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 08 Nov 2002 18:54:26 +0100 To: Gonzalo Camarillo , Jonathan Rosenberg From: Jiri Kuthan Cc: Bob Penfield , Jiri Kuthan , Jiri Kuthan , manoj mallik , sip@ietf.org, tomimura@sei.co.jp, alan.johnston@wcom.com In-Reply-To: <3DC7E504.328E8E73@lmf.ericsson.se> References: <20021018160003.25511.87497.Mailman@www1.ietf.org> <5.1.0.14.0.20021019211147.03502eb8@mailhost.fokus.gmd.de> <5.1.0.14.0.20021020145656.03bc3d38@mailhost.fokus.gmd.de> <001b01c27872$a7d871a0$6901a8c0@BPenfield> <3DB42B4F.7000409@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Sip] Re: [Sipping] Tags in respones to CANCEL WAS: Re: Question about Section 3.8 ofdraft-ietf-sipping-basic-call-flows-01.txt(Eiji Tomimura) 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 neither choice could harm interoperability and none of the cons/prons is a particularly strong argument. All in all, to-tags are primarily used to establish a dialog and when a CANCEL is processed, the dialog is destroyed before ever set up. My esthetic preference is "YES" too -- just to avoid special-casing. It it primarily a clarification issue. The text was making some people believe that proxy servers had to guarantee to-tags in their replies to CANCELs equal to to-tags in replies to cancelled INVITE. Thanks, -Jiri At 04:34 PM 11/5/2002, Gonzalo Camarillo wrote: >Hi, > >Let's try to finish this discussion. Summarizing: > >Should the 200 OK responses to CANCEL have a To tag? > >Reasons for NO: > >CANCEL is hop-by-hop, and therefore, 200 OK responses for CANCEL are >also hop-by-hop. If we look at 100 Trying responses, which are >hop-by-hop as well, we see that they do not have a tag. > >Reasons for YES: > >Final responses to any request have tags. Even non-2xx final responses >for INVITE, which are hop-by-hop, have a tag. > >Note that user agents and proxies will have to be prepared to receive >200 OK responses for CANCEL with or without tags anyway, to improve >interoperability. So, this is not a big deal after all. Our decision is >only useful as long as it helps develop a coherent spec. > > >I would suggest to go for YES, document it, and move on. > >Comments? > >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 Fri Nov 8 13:42:46 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06871 for ; Fri, 8 Nov 2002 13:42:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8Iio220217 for sip-archive@odin.ietf.org; Fri, 8 Nov 2002 13:44: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 gA8IiRv20124; Fri, 8 Nov 2002 13:44: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 gA8IgIv19949 for ; Fri, 8 Nov 2002 13:42:18 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06476; Fri, 8 Nov 2002 13:39:42 -0500 (EST) Message-Id: <200211081839.NAA06476@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, 08 Nov 2002 13:39:42 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-guidelines-06.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 : Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-sip-guidelines-06.txt Pages : 22 Date : 2002-11-8 The Session Initiation Protocol (SIP) is a flexible, yet simple tool for establishing interactive connections across the Internet. Part of this flexibility is the ease with which it can be extended. In order to facilitate effective and interoperable extensions to SIP, some guidelines need to be followed when developing SIP extensions. This document outlines a set of such guidelines for authors of SIP extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-guidelines-06.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-guidelines-06.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-guidelines-06.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: <2002-11-8125007.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-guidelines-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-guidelines-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-8125007.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 Nov 8 13:42:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06881 for ; Fri, 8 Nov 2002 13:42:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8IipH20241 for sip-archive@odin.ietf.org; Fri, 8 Nov 2002 13:44: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 gA8IiYv20162; Fri, 8 Nov 2002 13:44:34 -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 gA8IgTv19982 for ; Fri, 8 Nov 2002 13:42:29 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06523; Fri, 8 Nov 2002 13:39:54 -0500 (EST) Message-Id: <200211081839.NAA06523@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, 08 Nov 2002 13:39:54 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-session-timer-10.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 for Session Timer Author(s) : S. Donovan, J. Rosenberg Filename : draft-ietf-sip-session-timer-10.txt Pages : 25 Date : 2002-11-8 This document defines an extension to the Session Initiation Protocol (SIP). This extension allows for a periodic refresh of SIP sessions through a re-INVITE or UPDATE request. The refresh allows both user agents and proxies to determine if the SIP session is still active. The extension defines two new header fields, Session-Expires, which conveys the lifetime of the session, and Min-SE, which conveys the minimum allowed value for the session timer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-session-timer-10.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-session-timer-10.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-session-timer-10.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: <2002-11-8125026.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-session-timer-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-session-timer-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-8125026.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 Nov 8 14:40:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06876 for ; Fri, 8 Nov 2002 13:42:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8Iip320229 for sip-archive@odin.ietf.org; Fri, 8 Nov 2002 13:44: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 gA8IiUv20143; Fri, 8 Nov 2002 13:44: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 gA8IgNv19962 for ; Fri, 8 Nov 2002 13:42: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 NAA06501; Fri, 8 Nov 2002 13:39:47 -0500 (EST) Message-Id: <200211081839.NAA06501@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, 08 Nov 2002 13:39:47 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-callerprefs-07.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 (SIP) Caller Preferences and Callee Capabilities Author(s) : H. Schulzrinne, J. Rosenberg Filename : draft-ietf-sip-callerprefs-07.txt Pages : 46 Date : 2002-11-8 This document describes a set of extensions to the Session Initiation Protocol (SIP) which allow a caller to express preferences about request handling in servers. These preferences include the ability to select which URIs a request gets routed to, and to specify certain request handling directives in proxies and redirect servers. It does so by defining four new request headers, Accept-Contact, Reject- Contact, Require-Contact and Request-Disposition, which specify the caller's preferences. The extension also defines new parameters for the Contact header that describe the capabilities and characteristics of a UA. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-callerprefs-07.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-callerprefs-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-callerprefs-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-8125016.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-callerprefs-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-callerprefs-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-8125017.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 Nov 8 16:25:15 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15559 for ; Fri, 8 Nov 2002 16:25:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8LRKf31251 for sip-archive@odin.ietf.org; Fri, 8 Nov 2002 16:27:20 -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 gA8LQAv31166; Fri, 8 Nov 2002 16:26: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 gA8LNCv31023 for ; Fri, 8 Nov 2002 16:23:12 -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 QAA15388 for ; Fri, 8 Nov 2002 16:20:36 -0500 (EST) Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.11.6) id gA8LN6t50383; Fri, 8 Nov 2002 16:23:06 -0500 (EST) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] B2BUA question. Date: Fri, 8 Nov 2002 16:23:22 -0500 Message-ID: <001401c2876d$117db030$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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <12B638FEE763F74696D8544752E7204801BACC2B@bgsmsx101.iind.intel.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 > I agree that we might want to limit > our discussion only within SIP properties > of B2BUA to get some common understanding > of B2BUA as a SIP logical entity. > > In addition to few queries which Chinmay > has pointed out, I can think of > some basic points that need to be > clarified/discussed about B2BUA : A B2BUA can do everything that a UA can. In the process, the B2BUA can choose to proxy nothing or most everything over the multiple dialogs. If someone wants to perform an exhaustive evaluation of proxy-vs-B2BUA, that is more of a sipping issue since it deals with network deployment. However such an evaluation gets complicated because each vendor can code or configure their B2BUA to varying degrees concerning what information should be proxied. Such a decision is determined based upon the assigned task/service of the B2BUA. Some products can even assume a dialog-stateful proxy role within a dialog; then it can morph into a B2BUA when it desires to start sending requests within established halves of a dialog. (e.g. a dialog-stateful proxy which wants to release both halves of a dialog and can satisfy the authentication challenges.) After morphing into a B2BUA, it must be careful within the 2 halves of the dialog since it has trampled on another UA's CSeq space. _______________________________________________ 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 Nov 10 08:37:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16203 for ; Sun, 10 Nov 2002 08:37:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAADd5T05042 for sip-archive@odin.ietf.org; Sun, 10 Nov 2002 08:39: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 gAADcKv05006; Sun, 10 Nov 2002 08:38: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 gAADYev04350 for ; Sun, 10 Nov 2002 08:34:40 -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 IAA16005 for ; Sun, 10 Nov 2002 08:32:06 -0500 (EST) Received: from softarmor.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id gAADYbQs028366 for ; Sun, 10 Nov 2002 07:34:37 -0600 Message-ID: <3DCE605F.6070203@softarmor.com> Date: Sun, 10 Nov 2002 07:34:23 -0600 From: Dean Willis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016 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] Draft agenda for SIP WG at IETF 55 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 provide feedback on the draft agenda posted at: http://www.softarmor.com/sipwg/meets/ietf55/agenda.html or, for those of your preferring simplest text: Tuesday November 19, 1930-2200, Salon I 1930 Agenda Bash 1935 Status and Charter, Chairs 1945 Identity and Privacy and AuthID Open Issues Jon Peterson http://www.ietf.org/internet-drafts/draft-ietf-sip-identity-00.txt http://www.ietf.org/internet-drafts/draft-ietf-sip-privacy-general-01.txt http://www.ietf.org/internet-drafts/draft-peterson-sip-smime-aes-00.txt http://www.ietf.org/internet-drafts/draft-ietf-sip-authid-body-00.txt 2030 Content Indirection Open Issues Sean Olson http://www.ietf.org/internet-drafts/draft-ietf-sip-content-indirect-mech-00.txt 2100 RFC3261 Open Issues such as SIPS URI Jonathan Rosenberg http://www.ietf.org/rfc/rfc3261.txt?number=3261 2130 Caller Preferences Open Issues Jonathan Rosenberg http://www.ietf.org/internet-drafts/draft-ietf-sip-callerprefs-07.txt 2145 SIP Guidelines Open Issues Rohan Mahy http://www.ietf.org/internet-drafts/draft-ietf-sip-guidelines-06.txt (Note: Author suggested discussion not needed) _______________________________________________ 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 Nov 11 07:00:32 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16035 for ; Mon, 11 Nov 2002 07:00:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gABC2Z806281 for sip-archive@odin.ietf.org; Mon, 11 Nov 2002 07:02: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 gABBxvv06195; Mon, 11 Nov 2002 06:59: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 gABBusv06138 for ; Mon, 11 Nov 2002 06:56:54 -0500 Received: from NREXCH.netrake.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15934 for ; Mon, 11 Nov 2002 06:54:21 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 11 Nov 2002 05:56:52 -0600 Message-ID: <7E06D3212981524CA10D2A114937C414093AF3@nrexch.netrake.net> Thread-Topic: [Sip-implementors] Ambiguity in "absoluteURI" (Cannot resolve between "srvr" and"reg-name") Thread-Index: AcKJeFATPoj4Nm0KQ2iA/5+/jlvtUQAAIoKg From: "Rob Phillips" To: "Gade Ramesh" , , Cc: , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gABBusv06139 Subject: [Sip] RE: [Sip-implementors] Ambiguity in "absoluteURI" (Cannot resolve between "srvr" and"reg-name") 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 was discussed on the list earlier. The answer is: If it matches srvr, then it's srvr. If it matches reg-name, then it's reg-name. If it matches both, then it's srvr, since it's the more specific case. So in your specific examples: userA@domainLabel.com is "srvr". domainLabel.com is also "srvr". If you had something like: regname@@something::like@this.com however, it would only resolve to "reg-name". - rob -----Original Message----- From: Gade Ramesh [mailto:gramesh@cdotb.ernet.in] Sent: Monday, November 11, 2002 2:44 AM To: sip-implementors@cs.columbia.edu; sip@ietf.org Cc: rprakash@cdotb.ernet.in; pramodhn@cdotb.ernet.in; titty@cdotb.ernet.in Subject: [Sip-implementors] Ambiguity in "absoluteURI" (Cannot resolve between "srvr" and"reg-name") Hi, I'm am trying to implement a SIP parser. I have an issue here while parsing the Absolute-uri. I am not able to resolve between "srvr" and "reg-name". ----------------------------------------------------------------------- *) Absolute uri: absoluteURI = scheme ":" ( hier-part / opaque-part ) scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) hier-part = ( net-path / abs-path ) [ "?" query ] net-path = "//" authority [ abs-path ] abs-path = "/" path-segments authority = srvr / reg-name srvr = [ [ userinfo "@" ] hostport ] reg-name = 1*( unreserved / escaped / "$" / "," / ";" / ":" / "@" / "&" / "=" / "+" ) userinfo = ( user / telephone-subscriber ) [ ":" password ] "@" user = 1*( unreserved / escaped / user-unreserved ) unreserved = alphanum / mark mark = "-" / "_" / "." / "!" / "~" / "*" / "'" / "(" / ")" user-unreserved= "&" / "=" / "+" / "$" / "," / ";" / "?" / "/" password = *( unreserved / escaped / "&" / "=" / "+" / "$" / "," ) hostport = host [ ":" port ] host = hostname / IPv4address / IPv6reference ------------------------------------------------------------------------ Here the problem is with "authority". srvr contains "@" and reg-name can contain multiple "@" characters. How do I resolve between the 2 non-terminals? Example 1: userA@domainLabel.com. Example 2: domainLabel.com "srvr" can contain either "userinfo@hostport" or "hostport". In hostport, port is optional. Both examples 1 and 2, according to the grammar, can match with both reg-name and srvr. How do I decide whether it belongs to reg-name or srvr? One possibility is: ------------------- If token contains multiple "@"s, then it could be resolved as reg-name. (But then, this aspect is not specified in the grammar and it is our hack.) Could somebody kindly help me out with this aspect? Thanks in advance. G. Ramesh Research Engineer, Internet Telephony Group ===================================================================== C-DOT (Centre for Development of Telematics) 71/1, Sneha Complex, Miller Road, Bangalore - 560052, India email: gramesh@cdotb.ernet.in Phone: +91-80-2263399, +91-80-2383951, Fax: +91-80-2263256 ===================================================================== _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ 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 Nov 11 07:31:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16317 for ; Mon, 11 Nov 2002 07:31:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gABCX5907628 for sip-archive@odin.ietf.org; Mon, 11 Nov 2002 07:33: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 gABCUdv07518; Mon, 11 Nov 2002 07:30: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 gABCRZv07445 for ; Mon, 11 Nov 2002 07:27:35 -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 HAA16269 for ; Mon, 11 Nov 2002 07:25:01 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 11 Nov 2002 04:27:33 -0800 Received: from 212.143.185.30 by sea1fd.sea1.hotmail.msn.com with HTTP; Mon, 11 Nov 2002 12:27:32 GMT X-Originating-IP: [212.143.185.30] From: "Leonardo Rico" To: sip@ietf.org Date: Mon, 11 Nov 2002 07:27:32 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Nov 2002 12:27:33.0152 (UTC) FILETIME=[B5A9DA00:01C2897D] Subject: [Sip] B2BUA 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 was looking into the issue of B2BUA and found it not clear in some aspects. For example some mail exchange in July 2001 says a B2BUA associates one or more calls meaning it can also be only one or more then 2. All definitions I found say it is UAS on one side and UAC on the other. Can it also be UAC on one or more sides (meaning it initiated calls to a few UAs)? What type of applications will it be used for. The drafts talk about using it for FW traversal, Anonymizer, 3PCC. Do you see it also functioning as a PBX for example? What other type of applications do you see functioning as B2BUA? Do you see it coupled with a SIP Proxy/Registrar/Redirect in one physical entity? Thanks _________________________________________________________________ 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 Mon Nov 11 07:41:38 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16568 for ; Mon, 11 Nov 2002 07:41:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gABCheY08494 for sip-archive@odin.ietf.org; Mon, 11 Nov 2002 07:43: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 gABCfCv08449; Mon, 11 Nov 2002 07:41: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 gABCcmv08371 for ; Mon, 11 Nov 2002 07:38:48 -0500 Received: from em.njupt.edu.cn (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA16503 for ; Mon, 11 Nov 2002 07:36:09 -0500 (EST) Message-Id: <200211111236.HAA16503@ietf.org> Received: (qmail 10640 invoked from network); 11 Nov 2002 13:04:54 -0000 Received: from unknown (HELO toto) (10.10.3.123) by em.njupt.edu.cn with SMTP; 11 Nov 2002 13:04:54 -0000 Date: Mon, 11 Nov 2002 20:41:40 +0800 From: feng zhang Reply-To: y01317@njupt.edu.cn To: "sip@ietf.org" Organization: NUPT-CED202 X-mailer: FoxMail 4.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id gABCcmv08372 Subject: [Sip] why NO sent-by 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 Hello all, Quote RFC3261 section 18.1.1 Sending Requests: Before a request is sent, the client transport MUST insert a value of the "sent-by" field into the Via header field. This field contains an IP address or host name, and port. The usage of an FQDN is RECOMMENDED. This field is used for sending responses under certain conditions, described below. If the port is absent, the default value depends on the transport. It is 5060 for UDP, TCP and SCTP, 5061 for TLS. But I can not find "sent-by" parameter in draft-ietf-sipping-basic-call-flows-01, Why? The RFC uses "MUST" for it. Thanks. _______________________________________________ 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 Nov 11 10:16:53 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21723 for ; Mon, 11 Nov 2002 10:16:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gABFIwG16134 for sip-archive@odin.ietf.org; Mon, 11 Nov 2002 10:18:58 -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 gABFGRv16061; Mon, 11 Nov 2002 10:16: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 gABF2Ev14974 for ; Mon, 11 Nov 2002 10:02:14 -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 JAA21136 for ; Mon, 11 Nov 2002 09:59:39 -0500 (EST) Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.11.6) id gABF2Bd93455; Mon, 11 Nov 2002 10:02:11 -0500 (EST) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] why NO sent-by Date: Mon, 11 Nov 2002 10:01:16 -0500 Message-ID: <000001c28993$2fd82f10$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" 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) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <200211111236.HAA16503@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 > But I can not find "sent-by" parameter in > draft-ietf-sipping-basic-call-flows-01, > Why? The RFC uses "MUST" for it. Please re-look at the Via header syntax within rfc3261 section 25.1. The flows do include the "sent-by" parameter. _______________________________________________ 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 Nov 11 11:58:43 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24754 for ; Mon, 11 Nov 2002 11:58:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gABH0oq22341 for sip-archive@odin.ietf.org; Mon, 11 Nov 2002 12:00: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 gABH0Lv22320; Mon, 11 Nov 2002 12:00: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 gABGqXv22024 for ; Mon, 11 Nov 2002 11:52:33 -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 LAA24437 for ; Mon, 11 Nov 2002 11:49:56 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gABGqnof025240 for ; Mon, 11 Nov 2002 11:52:49 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAU61089; Mon, 11 Nov 2002 11:57:23 -0500 (EST) Message-ID: <3DCFE04C.BA98CBD3@cisco.com> Date: Mon, 11 Nov 2002 11:52:28 -0500 From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: draft-ietf-sip-session-timer-10 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 has been a fair amount of discussion over the last few months, on the sip or sip-implementors lists, trying to clarify the meaning of the session timer draft. I'm a bit concerned that the latest draft still leaves some doubt about the meaning. Session Refresh Request is defined as follows in draft-ietf-sip-session-timer-10: Session Refresh Request: An INVITE or UPDATE request within a dialog. If the request generates a 2xx response, the session expiration is increased to the current time plus the session interval obtained from the response. A session refresh request is not to be confused with a target refresh request, defined in Section 6 of [1], which is a request that can update the remote target of a dialog. This explicitly tried to distinguish this from a Target Refresh Request. That is defined as follows in rfc 3261 (taken from various places): Target Refresh Request: A target refresh request sent within a dialog is defined as a request that can modify the remote target of the dialog. For dialogs that have been established with an INVITE, the only target refresh request defined is re-INVITE A UAC SHOULD include a Contact header field in any target refresh requests within a dialog, and unless there is a need to change it, the URI SHOULD be the same as used in previous requests within the dialog. If the "secure" flag is true, that URI MUST be a SIPS URI. As discussed in Section 12.2.2, a Contact header field in a target refresh request updates the remote target URI. This allows a UA to provide a new contact address, should its address change during the duration of the dialog. This latter suggests that a target refresh request need not actually change the target. So an INVITE within a dialog must always be a target refresh request. But the definition of Session Refresh Request is also just an INVITE. So despite the attempt to distinguish the two, it seems that *every* INVITE within a dialog is both a Session Refresh Request and a Target Refresh Request. Draft-ietf-sip-session-timer-10 also says (in different places): The default value of the Session-Expires header field, when not present, is infinity. This means that absence of the Session-Expires header field implies no expiration. A UAC MAY include a Session-Expires in an initial session refresh request request if it wishes for a session timer to be applied to the session. The value of this header field indicates the session interval desired by the UAC. In a session refresh request sent within a dialog with an active session timer, the header field SHOULD be present. When present, it MUST be equal to the maximum of the Min-SE header field (recall that its default value when not present is zero) and the current session interval. Putting this all together, I think it effectively says: Every reINVITE or UPDATE within a dialog refreshes the session timer. If a session timer was already active within the session then the reINVITE or UPDATE SHOULD refresh it to the value previously established. (The maximum of the Min-SE header field and the current session interval.) If a reINVITE or UPDATE does not contain a Session-Expires header, then the session timer is deactivated. (Set to an infinite value.) Given all the discussion that has gone on before on this subject, I think the language is still pretty confusing. I'm don't see where the term "session refresh request" does much to help clarify what is required. For instance, what is an "initial session refresh request"? I think it is typically the initial INVITE that establishes a dialog. It isn't itself in a dialog, and so doesn't qualify as a session refresh request at all. I don't know what the best solution is. One possibility would be to reword the text. Another would be to simply include some additional examples to show the other cases. Paul _______________________________________________ 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 Nov 11 12:18:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25158 for ; Mon, 11 Nov 2002 12:18:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gABHKsh23931 for sip-archive@odin.ietf.org; Mon, 11 Nov 2002 12:20: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 gABHKUv23882; Mon, 11 Nov 2002 12:20: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 gABH2Zv22431 for ; Mon, 11 Nov 2002 12:02:35 -0500 Received: from jupiter.securelogix.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24786 for ; Mon, 11 Nov 2002 11:59:57 -0500 (EST) Received: by jupiter with Internet Mail Service (5.5.2448.0) id ; Mon, 11 Nov 2002 11:02:30 -0600 Message-ID: <493BB8BDBB5AD511A7BB00104B62EE280105FF20@jupiter> From: David Oliver To: "'sip@ietf.org'" Subject: FW: [Sip] I-D ACTION:draft-ietf-sip-guidelines-06.txt (nits) Date: Mon, 11 Nov 2002 11:02:29 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) 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: , A couple of nits... 4.4 Syntactic Issues Para 3... It is RECOMMENDED that this be camel case. -- One hump or two? 4.6 Examples Section Para 2: "meanining" => meaning Best Regards, David C. Oliver SecureLogix Inc. -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Friday, November 08, 2002 12:40 PM Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-guidelines-06.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 : Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-sip-guidelines-06.txt Pages : 22 Date : 2002-11-8 The Session Initiation Protocol (SIP) is a flexible, yet simple tool for establishing interactive connections across the Internet. Part of this flexibility is the ease with which it can be extended. In order to facilitate effective and interoperable extensions to SIP, some guidelines need to be followed when developing SIP extensions. This document outlines a set of such guidelines for authors of SIP extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-guidelines-06.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-guidelines-06.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-guidelines-06.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 Mon Nov 11 16:46:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03037 for ; Mon, 11 Nov 2002 16:46:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gABLma506715 for sip-archive@odin.ietf.org; Mon, 11 Nov 2002 16:48: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 gABLm6v06677; Mon, 11 Nov 2002 16:48: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 gABLixv06547 for ; Mon, 11 Nov 2002 16:44: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 QAA02970 for ; Mon, 11 Nov 2002 16:42:19 -0500 (EST) Received: from softarmor.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id gABLioQs007713 for ; Mon, 11 Nov 2002 15:44:51 -0600 Message-ID: <3DD024D2.9000104@softarmor.com> Date: Mon, 11 Nov 2002 15:44:50 -0600 From: Dean Willis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016 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] Uncle SIP Needs You -- Volunteers for IETF 55 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 need help filling two positions for the SIP Working Group Meeting at IETF 55 1) Secretary -- record and submit minutes. Just type up brief notes of issues raised and any resolutions/consensus reacher or open issues left pending. I usually take the notes in SIMPLE and get them to the chair by the end of the meeting, so I know it's not THAT big of a job (but it IS important). We DON'T need to record every he-said she-said . . . 2) Chat room coordinator -- for this meeting, we'll be using a chat room set up using Jabber to allow background discussion and the raising of questions by viewers watching over MBONE. The coordinator should post brief messages (like: We're now talking about the agenda), collect questions that are raised in the chat room, and take those questions to the microphone when we open the floor for questions. Another easy, important job, qualifying you for a heartfelt "hurrah" from our internet audience. So step right up. No harm in having multiples, too. Plenty of fun for your whole family AND all your friends. -- 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 Mon Nov 11 18:25:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05936 for ; Mon, 11 Nov 2002 18:25:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gABNRUa12272 for sip-archive@odin.ietf.org; Mon, 11 Nov 2002 18:27: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 gABNQuv12240; Mon, 11 Nov 2002 18:26: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 gABNOZv12142 for ; Mon, 11 Nov 2002 18:24:35 -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 SAA05861 for ; Mon, 11 Nov 2002 18:21:54 -0500 (EST) Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gABNOTYH028557 for ; Mon, 11 Nov 2002 18:24:29 -0500 (EST) Message-ID: <3DD03C2B.6030401@dynamicsoft.com> Date: Mon, 11 Nov 2002 18:24:27 -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] The fate of session timer? 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, As you may have noticed, I submitted an update to the session timer specification. This is an old, old spec that has been around for quite some time. It receives only minimal attention these days. The general comments on the list are generally 'too complex' and 'too hard to understand'. Some of that is wording, which I will continue to work. The bigger problem, I think, is that its not at all clear what problem this draft is REALLY solving. I assert that session timer is really useful for one thing, which is to provide a means to cleanup old session state in UAs and proxies. Normally, you'd set a timer (on the order of 5 hours or something) to discard any state thats still around. However, since a call may actually last that long, you want a way to reliably know when you can flush the state. Session timer is NOT useful for determining call durations for billing purposes. Session timer is NOT useful for quickly determining that a UA has failed, in order to recover. It operates too slowly for that. So, given this somewhat-marginal value, the complexity seems startingly high. I have begun to wonder whether that is the reason for the troubles this specification is having. So, I see a few options: 1. No one cares about this spec. Discard it entirely. 2. Continue as it is, fix up some wording, and submit. Probably no one implements it since it provides little value at high cost. 3. Change the scope. Eliminate or simplify negotiation of the timer by defining a suitably long minimum. Eliminate or simplify choosing who refreshes by requiring that the UAC support the timer. And so on. The result would be a much simpler spec. 4. others? Please provide comments, particularly if you are actively using this specification for some real problem. -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 Mon Nov 11 19:10:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06653 for ; Mon, 11 Nov 2002 19:10:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAC0D7X14630 for sip-archive@odin.ietf.org; Mon, 11 Nov 2002 19:13: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 gAC0CZv14621; Mon, 11 Nov 2002 19:12: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 gAC0Brv14596 for ; Mon, 11 Nov 2002 19:11:53 -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 TAA06633 for ; Mon, 11 Nov 2002 19:09:14 -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 gAC0AhRc004790 for ; Mon, 11 Nov 2002 19:10:47 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Nov 2002 18:11:42 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64311@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: Jonathan Rosenberg , sip@ietf.org Subject: RE: [Sip] The fate of session timer? Date: Mon, 11 Nov 2002 18:11:40 -0600 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: , > So, given this somewhat-marginal value, the complexity seems > startingly high. I have begun to wonder whether that is the > reason for the troubles this specification is having. So, I > see a few options: ... > 4. others? There's another option we might consider: simplify the mechanism greatly and add it into the baseline on the next go-round. When we start working on 3261-bis, we can make it a MUST-strength to do a periodic re-INVITE. If we fix the period in the spec instead of allowing it to be negotiated, almost all of the complication goes away. (Of course, it remains to be seen whether we could reach consensus on a single value that balances network traffic with timely removal of stale states). Then, if a proxy along the path doesn't see an re-INVITE in the specified time period, it can go stateless for the dialog. It doesn't matter if the failure was due to failure or simply implementing an earlier version of the spec: at least there's a way to clear state without limiting the services available to well-behaved clients. /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 Mon Nov 11 22:00:22 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09987 for ; Mon, 11 Nov 2002 22:00:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAC32XI23553 for sip-archive@odin.ietf.org; Mon, 11 Nov 2002 22:02: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 gAC325v23528; Mon, 11 Nov 2002 22:02: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 gAC2x7v23349 for ; Mon, 11 Nov 2002 21:59:07 -0500 Received: from smtp013.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09890 for ; Mon, 11 Nov 2002 21:56:26 -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; 12 Nov 2002 02:58:58 -0000 Reply-To: From: "Sean Olson" To: "'Adam Roach'" , "'Jonathan Rosenberg'" , Subject: RE: [Sip] The fate of session timer? Date: Mon, 11 Nov 2002 18:58:58 -0800 Message-ID: <001c01c289f7$72771750$6b01a8c0@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1081 Importance: Normal In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A64311@DYN-TX-EXCH-001.dynamicsoft.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 The problem is that periodic re-INVITE is not needed in a great number of situations. I would prefer we not make this part of the base specification. It does make sense to simplify the negotiation by either removing it or choosing reasonable defaults. /sean -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Adam Roach Sent: Monday, November 11, 2002 4:12 PM To: Jonathan Rosenberg; sip@ietf.org Subject: RE: [Sip] The fate of session timer? > So, given this somewhat-marginal value, the complexity seems > startingly high. I have begun to wonder whether that is the > reason for the troubles this specification is having. So, I > see a few options: ... > 4. others? There's another option we might consider: simplify the mechanism greatly and add it into the baseline on the next go-round. When we start working on 3261-bis, we can make it a MUST-strength to do a periodic re-INVITE. If we fix the period in the spec instead of allowing it to be negotiated, almost all of the complication goes away. (Of course, it remains to be seen whether we could reach consensus on a single value that balances network traffic with timely removal of stale states). Then, if a proxy along the path doesn't see an re-INVITE in the specified time period, it can go stateless for the dialog. It doesn't matter if the failure was due to failure or simply implementing an earlier version of the spec: at least there's a way to clear state without limiting the services available to well-behaved clients. /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 _______________________________________________ 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 Nov 11 22:39:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10876 for ; Mon, 11 Nov 2002 22:39:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAC3fEG25881 for sip-archive@odin.ietf.org; Mon, 11 Nov 2002 22:41: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 gAC3eev25858; Mon, 11 Nov 2002 22:40:40 -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 gAC3ddv25789 for ; Mon, 11 Nov 2002 22:39:39 -0500 Received: from mtiwmhc12.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10859 for ; Mon, 11 Nov 2002 22:36:56 -0500 (EST) Received: from cs.columbia.edu ([12.91.126.20]) by mtiwmhc12.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20021112033909.MGHZ13909.mtiwmhc12.worldnet.att.net@cs.columbia.edu>; Tue, 12 Nov 2002 03:39:09 +0000 Message-ID: <3DD07777.2010803@cs.columbia.edu> Date: Mon, 11 Nov 2002 22:37:27 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: seancolson@yahoo.com CC: "'Adam Roach'" , "'Jonathan Rosenberg'" , sip@ietf.org Subject: Re: [Sip] The fate of session timer? References: <001c01c289f7$72771750$6b01a8c0@cranberry> 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 There are also two somewhat separate problems of proxy session state and UA session state. Only the former is hard, since the UAs can easily determine each other's state at their convenience (and probably have other clues), but a proxy can't tell the UAs to show signs of session life. Thus, the question is whether call stateful proxies are sufficiently common and whether they couldn't use other means (such as subscribing to session state) to achieve the same aim in many cases. One general criteria for such services might be the "value-ubiquity" curve. If something is only valuable if most entities implement it and, in addition, the entities bearing a good part of the complexity cost probably have little direct incentive to do this, the feature becomes dubious. Session timer seems to be exactly that type of service. Sean Olson wrote: > The problem is that periodic re-INVITE is not needed in a great number > of > situations. I would prefer we not make this part of the base > specification. > It does make sense to simplify the negotiation by either removing it or > choosing reasonable defaults. > > /sean > > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Adam > Roach > Sent: Monday, November 11, 2002 4:12 PM > To: Jonathan Rosenberg; sip@ietf.org > Subject: RE: [Sip] The fate of session timer? > > > >>So, given this somewhat-marginal value, the complexity seems >>startingly high. I have begun to wonder whether that is the >>reason for the troubles this specification is having. So, I >>see a few options: > > ... > >>4. others? > > > There's another option we might consider: simplify the mechanism greatly > and add it into the baseline on the next go-round. > > When we start working on 3261-bis, we can make it a MUST-strength to do > a periodic re-INVITE. If we fix the period in the spec instead of > allowing it to be negotiated, almost all of the complication goes away. > (Of course, it remains to be seen whether we could reach consensus on a > single value that balances network traffic with timely removal of stale > states). > > Then, if a proxy along the path doesn't see an re-INVITE in the > specified time period, it can go stateless for the dialog. It doesn't > matter if the failure was due to failure or simply implementing an > earlier version of the spec: at least there's a way to clear state > without limiting the services available to well-behaved clients. > > /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 > > _______________________________________________ > 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 Nov 12 01:57:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13992 for ; Tue, 12 Nov 2002 01:57:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAC70BB02850 for sip-archive@odin.ietf.org; Tue, 12 Nov 2002 02:00: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 gAC6xtv02769; Tue, 12 Nov 2002 01:59: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 gAB72Yv15350 for ; Mon, 11 Nov 2002 02:02:34 -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 BAA02691 for ; Mon, 11 Nov 2002 01:59:52 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 10 Nov 2002 23:02:23 -0800 Received: from 212.143.185.30 by sea1fd.sea1.hotmail.msn.com with HTTP; Mon, 11 Nov 2002 07:02:19 GMT X-Originating-IP: [212.143.185.30] From: "Leonardo Rico" To: sip@ietf.org Date: Mon, 11 Nov 2002 02:02:19 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Nov 2002 07:02:23.0953 (UTC) FILETIME=[49465410:01C28950] Subject: [Sip] B2BUA 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 was looking into the issue of B2BUA and found it not clear in some aspects. For example some mail exchange in July 2001 says a B2BUA associates one or more calls meaning it can also be only one or more then 2. All definitions I found say it is UAS on one side and UAC on the other. Can it also be UAC on one or more sides (meaning it initiated calls to a few UAs)? What type of applications will it be used for. The drafts talk about using it for FW traversal, Anonymizer, 3PCC. Do you see it also functioning as a PBX for example? What other type of applications do you see functioning as B2BUA? Do you see it coupled with a SIP Proxy/Registrar/Redirect in one physical entity? Thanks _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus _______________________________________________ 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 Nov 12 01:57:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13993 for ; Tue, 12 Nov 2002 01:57:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAC70BV02860 for sip-archive@odin.ietf.org; Tue, 12 Nov 2002 02:00: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 gAC6xiv02746; Tue, 12 Nov 2002 01:59: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 gAAHEkv13832 for ; Sun, 10 Nov 2002 12:14:46 -0500 Received: from dac01.unicamp.br (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19806 for ; Sun, 10 Nov 2002 12:12:11 -0500 (EST) From: p012173@dac.unicamp.br Received: by dac01.unicamp.br (Postfix, from userid 12347) id B747273C408; Sun, 10 Nov 2002 15:14:41 -0200 (BRST) Received: from dac01.unicamp.br (localhost [127.0.0.1]) by dac01.unicamp.br (Postfix) with SMTP id D60E5766EC7 for ; Sun, 10 Nov 2002 15:14:40 -0200 (BRST) Received: from 143.106.50.218 (SquirrelMail authenticated user p012173) by dac01.unicamp.br with HTTP; Sun, 10 Nov 2002 15:14:40 -0200 (BRST) Message-ID: <3398.143.106.50.218.1036948480.squirrel@dac01.unicamp.br> Date: Sun, 10 Nov 2002 15:14:40 -0200 (BRST) To: X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by AMaViS perl-10 Content-Transfer-Encoding: 8bit Subject: [Sip] implementing protocols 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, I'm a student, I study at UNICAMP (Brazil) and I'm thinking about implement some VoIP protocols as an academic work. I don't know if you could help me but what I would like to know is if the SIP protocol is essencial to a VoIP application, I mean, if I'd implemented a VoIP application without this protocol I'd get a successful comunication or is it really essential? Thanks for your attention Paulo Henrique M. Santos _______________________________________________ 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 Nov 12 01:58:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14018 for ; Tue, 12 Nov 2002 01:58:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAC70Ei02874 for sip-archive@odin.ietf.org; Tue, 12 Nov 2002 02:00: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 gAC6xwv02790; Tue, 12 Nov 2002 01:59: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 gABBqxv06026 for ; Mon, 11 Nov 2002 06:52:59 -0500 Received: from ws9.cdotb.ernet.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15870 for ; Mon, 11 Nov 2002 06:48:07 -0500 (EST) Received: from cdotb.ernet.in (IDENT:gramesh@[192.168.51.234]) by ws9.cdotb.ernet.in (8.9.3/8.9.3) with ESMTP id QAA28185; Mon, 11 Nov 2002 16:48:55 +0500 (GMT+0500) Message-ID: <3DCF6DB5.15DCEF93@cdotb.ernet.in> Date: Mon, 11 Nov 2002 14:13:33 +0530 From: Gade Ramesh Organization: C-DOT X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: cdotb.itg.stacks.sip To: sip-implementors@cs.columbia.edu, sip@ietf.org CC: rprakash@cdotb.ernet.in, pramodhn@cdotb.ernet.in, titty@cdotb.ernet.in Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Ambiguity in "absoluteURI" (Cannot resolve between "srvr" and "reg-name") 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'm am trying to implement a SIP parser. I have an issue here while parsing the Absolute-uri. I am not able to resolve between "srvr" and "reg-name". ----------------------------------------------------------------------- *) Absolute uri: absoluteURI = scheme ":" ( hier-part / opaque-part ) scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) hier-part = ( net-path / abs-path ) [ "?" query ] net-path = "//" authority [ abs-path ] abs-path = "/" path-segments authority = srvr / reg-name srvr = [ [ userinfo "@" ] hostport ] reg-name = 1*( unreserved / escaped / "$" / "," / ";" / ":" / "@" / "&" / "=" / "+" ) userinfo = ( user / telephone-subscriber ) [ ":" password ] "@" user = 1*( unreserved / escaped / user-unreserved ) unreserved = alphanum / mark mark = "-" / "_" / "." / "!" / "~" / "*" / "'" / "(" / ")" user-unreserved= "&" / "=" / "+" / "$" / "," / ";" / "?" / "/" password = *( unreserved / escaped / "&" / "=" / "+" / "$" / "," ) hostport = host [ ":" port ] host = hostname / IPv4address / IPv6reference ------------------------------------------------------------------------ Here the problem is with "authority". srvr contains "@" and reg-name can contain multiple "@" characters. How do I resolve between the 2 non-terminals? Example 1: userA@domainLabel.com. Example 2: domainLabel.com "srvr" can contain either "userinfo@hostport" or "hostport". In hostport, port is optional. Both examples 1 and 2, according to the grammar, can match with both reg-name and srvr. How do I decide whether it belongs to reg-name or srvr? One possibility is: ------------------- If token contains multiple "@"s, then it could be resolved as reg-name. (But then, this aspect is not specified in the grammar and it is our hack.) Could somebody kindly help me out with this aspect? Thanks in advance. G. Ramesh Research Engineer, Internet Telephony Group ===================================================================== C-DOT (Centre for Development of Telematics) 71/1, Sneha Complex, Miller Road, Bangalore - 560052, India email: gramesh@cdotb.ernet.in Phone: +91-80-2263399, +91-80-2383951, Fax: +91-80-2263256 ===================================================================== _______________________________________________ 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 Nov 12 03:23:34 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24833 for ; Tue, 12 Nov 2002 03:23:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAC8Pl515622 for sip-archive@odin.ietf.org; Tue, 12 Nov 2002 03:25: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 gAC8A1v15124; Tue, 12 Nov 2002 03:10: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 gAC86vv14475 for ; Tue, 12 Nov 2002 03:06:57 -0500 Received: from wiprom2mx2.wipro.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24604 for ; Tue, 12 Nov 2002 03:04:12 -0500 (EST) Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx2.wipro.com (8.11.3/8.11.3) with SMTP id gAC86g102461 for ; Tue, 12 Nov 2002 13:36:43 +0530 (IST) Received: from blr-ec-msg02.wipro.com ([10.200.51.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 12 Nov 2002 13:36:42 +0530 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [Sip] The fate of session timer? Date: Tue, 12 Nov 2002 13:36:42 +0530 Message-ID: Thread-Topic: [Sip] The fate of session timer? Thread-Index: AcKJ22cRw6yo/ESQTYmQXe354oQ1ngARvHfA From: "Chandan Rajah" To: X-OriginalArrivalTime: 12 Nov 2002 08:06:42.0361 (UTC) FILETIME=[6F7A6A90:01C28A22] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAC86vv14476 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 it is important to change the actual scope of the session timer. If at all there is to be a session timer, it better do something worthwhile. Though, re-INVITEs could be a way of going about achieving this, deciding on the inter re-INVITE time is critical and can not be defaulted. Maybe, at this point it would be a good idea to rethink the entire mechanism and evaluate other prospective mechanism that could replace the current session timer. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Tuesday, November 12, 2002 4:54 AM To: sip@ietf.org Subject: [Sip] The fate of session timer? Folks, As you may have noticed, I submitted an update to the session timer specification. This is an old, old spec that has been around for quite some time. It receives only minimal attention these days. The general comments on the list are generally 'too complex' and 'too hard to understand'. Some of that is wording, which I will continue to work. The bigger problem, I think, is that its not at all clear what problem this draft is REALLY solving. I assert that session timer is really useful for one thing, which is to provide a means to cleanup old session state in UAs and proxies. Normally, you'd set a timer (on the order of 5 hours or something) to discard any state thats still around. However, since a call may actually last that long, you want a way to reliably know when you can flush the state. Session timer is NOT useful for determining call durations for billing purposes. Session timer is NOT useful for quickly determining that a UA has failed, in order to recover. It operates too slowly for that. So, given this somewhat-marginal value, the complexity seems startingly high. I have begun to wonder whether that is the reason for the troubles this specification is having. So, I see a few options: 1. No one cares about this spec. Discard it entirely. 2. Continue as it is, fix up some wording, and submit. Probably no one implements it since it provides little value at high cost. 3. Change the scope. Eliminate or simplify negotiation of the timer by defining a suitably long minimum. Eliminate or simplify choosing who refreshes by requiring that the UAC support the timer. And so on. The result would be a much simpler spec. 4. others? Please provide comments, particularly if you are actively using this specification for some real problem. -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 _______________________________________________ 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 Nov 12 06:20:50 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27286 for ; Tue, 12 Nov 2002 06:20:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gACBMtf25132 for sip-archive@odin.ietf.org; Tue, 12 Nov 2002 06:22: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 gACBMPv25112; Tue, 12 Nov 2002 06:22: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 gACBERv24864 for ; Tue, 12 Nov 2002 06:14:27 -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 GAA27179 for ; Tue, 12 Nov 2002 06:11:51 -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 gACBF3B18439 for ; Tue, 12 Nov 2002 13:15:03 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 12 Nov 2002 13:14:23 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 12 Nov 2002 13:14:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] The fate of session timer? Date: Tue, 12 Nov 2002 13:14:22 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE6FA9@esebe019.ntc.nokia.com> Thread-Topic: [Sip] The fate of session timer? Thread-Index: AcKJ22cRw6yo/ESQTYmQXe354oQ1ngARvHfAACwukfA= To: , X-OriginalArrivalTime: 12 Nov 2002 11:14:22.0962 (UTC) FILETIME=[A751C520:01C28A3C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gACBERv24865 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 As I see it, what we are specifying here is a keepalive mechanism for sessions. The value of the keepalive can have a default. UACs don't have to send any new header in an initial INVITE, but proxies and UASs requiring session keepalive can inform the UAC of such requirement by including a (proxy-)Require-header in the response?? The default values can be used. In this way, each entity can take of cleaning up its own stale sessions. No need for UAC to tell every other entity when it plans on ending the session, it can just send a BYE. Btw, do we have requirements for this, or should we write one? Regards, Hisham > -----Original Message----- > From: ext Chandan Rajah [mailto:chandan.rajah@wipro.com] > Sent: Tuesday, November 12, 2002 10:07 AM > To: sip@ietf.org > Subject: RE: [Sip] The fate of session timer? > > > I think it is important to change the actual scope of the > session timer. > If at all there is to be a session timer, it better do something > worthwhile. Though, re-INVITEs could be a way of going about achieving > this, deciding on the inter re-INVITE time is critical and can not be > defaulted. Maybe, at this point it would be a good idea to rethink the > entire mechanism and evaluate other prospective mechanism that could > replace the current session timer. > > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, November 12, 2002 4:54 AM > To: sip@ietf.org > Subject: [Sip] The fate of session timer? > > Folks, > > As you may have noticed, I submitted an update to the session timer > specification. This is an old, old spec that has been around > for quite > some time. It receives only minimal attention these days. The general > comments on the list are generally 'too complex' and 'too hard to > understand'. Some of that is wording, which I will continue > to work. The > > bigger problem, I think, is that its not at all clear what > problem this > draft is REALLY solving. > > I assert that session timer is really useful for one thing, > which is to > provide a means to cleanup old session state in UAs and proxies. > Normally, you'd set a timer (on the order of 5 hours or something) to > discard any state thats still around. However, since a call > may actually > > last that long, you want a way to reliably know when you can > flush the > state. > > Session timer is NOT useful for determining call durations > for billing > purposes. > > Session timer is NOT useful for quickly determining that a UA has > failed, in order to recover. It operates too slowly for that. > > So, given this somewhat-marginal value, the complexity seems > startingly > high. I have begun to wonder whether that is the reason for > the troubles > > this specification is having. So, I see a few options: > > 1. No one cares about this spec. Discard it entirely. > > 2. Continue as it is, fix up some wording, and submit. > Probably no one > implements it since it provides little value at high cost. > > 3. Change the scope. Eliminate or simplify negotiation of the > timer by > defining a suitably long minimum. Eliminate or simplify choosing who > refreshes by requiring that the UAC support the timer. And so on. The > result would be a much simpler spec. > > 4. others? > > > Please provide comments, particularly if you are actively using this > specification for some real problem. > > -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 > _______________________________________________ > 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 Nov 12 08:31:52 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00013 for ; Tue, 12 Nov 2002 08:31:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gACDXun32318 for sip-archive@odin.ietf.org; Tue, 12 Nov 2002 08:33: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 gACDSPv31973; Tue, 12 Nov 2002 08:28: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 gACDO5v31826 for ; Tue, 12 Nov 2002 08:24:05 -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 IAA29780 for ; Tue, 12 Nov 2002 08:21:29 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.41]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gACDO2YH028767; Tue, 12 Nov 2002 08:24:03 -0500 (EST) Message-ID: <3DD100F0.2060107@dynamicsoft.com> Date: Tue, 12 Nov 2002 08:24:00 -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: chandan.rajah@wipro.com, sip@ietf.org Subject: Re: [Sip] The fate of session timer? References: <2038BCC78B1AD641891A0D1AE133DBB7FE6FA9@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 hisham.khartabil@nokia.com wrote: > As I see it, what we are specifying here is a keepalive mechanism for > sessions. The value of the keepalive can have a default. > > UACs don't have to send any new header in an initial INVITE, but > proxies and UASs requiring session keepalive can inform the UAC of > such requirement by including a (proxy-)Require-header in the > response?? The default values can be used. No. Require/Proxy-REquire in a response is only allowed if the request contained a Supported header in the INVITE. > > In this way, each entity can take of cleaning up its own stale > sessions. No need for UAC to tell every other entity when it plans on > ending the session, it can just send a BYE. > > Btw, do we have requirements for this, or should we write one? This specification predates our requirements for requirements. So, no, there are none. I don't think we need to do a formal requirements process here. However, I think it is useful to have an email discussion of the basic requirements that underlie the current draft, to see which ones we can rule out, as it seems people seem amenable to considering a simplification: REQ 1: There shall be a way for a proxy or UA to request that a session timer be executed for a dialog. REQ 2: There shall be a way for the session timer to take place so long as EITHER the UAC or UAS supports it. REQ 3: There shall be a way for each element - proxy,UAC, UAS, to specify their desired value for the session timer. REQ 4: There shall be a way for each element to specify their minimum allowed value for the session tiemr. REQ 5: The final session timer shall be: MAX(MIN(desired timers),MAX(min timers)) REQ 6: It shall be possible to renegotiate the use of session timer, and its value, at any time during a dialog. REQ 7: Session timer shall be immune to DoS attacks introduced by a rogue UAC, UAS, or proxy. REQ 8: It shall be possible for the UAC in the initial INVITE to suggest itself for performing the refreshes. I think that captures most of it. Some of these requirements, like 6, fall out of general SIP properties, and we would be hard pressed to eliminate them. Its also possible to get simplification through redesign while still meeting the requirements. For example, it occurs to me that we could potentially send the refreshes directly from the client to the "interested" proxies. This is more overhead for the client if there is more than one interested proxy, but means that proxies which don't care about session timer don't suffer from additional message volume, which is a drawback of the current solution. By doing that, all of the negotiation becomes two-way, between a UA and a proxy, rather than N-way, and is thus much simplified. Such a solution would require a proxy requesting session timer to have a globally routable URI. Yet another solution is to define a specific "heartbeat" media stream type, which periodically genreates a keepalive. In that sense, its similar to RTCP, but not RTP specific. AN intermediary can get itself onto this heartbeat stream by being a b2bua that mucks with SDP, or using a mechanism like the session policy which I have formerly proposed: http://www.jdrosen.net/papers/draft-rosenberg-sipping-session-policy-00.txt There may be other general solutions to this too. -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 Tue Nov 12 09:23:42 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01172 for ; Tue, 12 Nov 2002 09:23:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gACEPkL02892 for sip-archive@odin.ietf.org; Tue, 12 Nov 2002 09:25: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 gACEPKv02872; Tue, 12 Nov 2002 09:25: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 gACEJBv02570 for ; Tue, 12 Nov 2002 09:19:11 -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 JAA00946 for ; Tue, 12 Nov 2002 09:16:35 -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 gACEJkB24075 for ; Tue, 12 Nov 2002 16:19:46 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 12 Nov 2002 16:19:04 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 12 Nov 2002 16:19:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] The fate of session timer? Date: Tue, 12 Nov 2002 16:19:02 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE6FAB@esebe019.ntc.nokia.com> Thread-Topic: [Sip] The fate of session timer? Thread-Index: AcKKTvNRJdpnVUvlQTqthSHkzvTuEAAwv3gQ To: Cc: , X-OriginalArrivalTime: 12 Nov 2002 14:19:03.0836 (UTC) FILETIME=[7408F5C0:01C28A56] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gACEJCv02571 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 The current draft fulfils all the requests stated below, but there has been a couple of emails on this thread asking for simplifications to the draft. That's why I asked for requirements. The simplification might start by examining the need for REQs 3-6. Also for REQ 1, what is the rationale behind a UAC or proxy requesting session timer to be started on the remote end? Each entity only needs to take care of its own stale sessions (something I tried to propose in my earlier email). Should my UAC care that the remote end has stale sessions? It should just care that the remote end doesn't think my session with it is stale. My suggestion for this was using require-header, but, as pointed out by Jonathan, it is not appropriate (something I over looked). Regards, Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, November 12, 2002 3:24 PM > To: Khartabil Hisham (NMP/Helsinki) > Cc: chandan.rajah@wipro.com; sip@ietf.org > Subject: Re: [Sip] The fate of session timer? > > > > > hisham.khartabil@nokia.com wrote: > > As I see it, what we are specifying here is a keepalive > mechanism for > > sessions. The value of the keepalive can have a default. > > > > UACs don't have to send any new header in an initial INVITE, but > > proxies and UASs requiring session keepalive can inform the UAC of > > such requirement by including a (proxy-)Require-header in the > > response?? The default values can be used. > > No. Require/Proxy-REquire in a response is only allowed if > the request > contained a Supported header in the INVITE. > > > > > In this way, each entity can take of cleaning up its own stale > > sessions. No need for UAC to tell every other entity when > it plans on > > ending the session, it can just send a BYE. > > > > Btw, do we have requirements for this, or should we write one? > > This specification predates our requirements for > requirements. So, no, > there are none. I don't think we need to do a formal requirements > process here. However, I think it is useful to have an email > discussion > of the basic requirements that underlie the current draft, to > see which > ones we can rule out, as it seems people seem amenable to > considering a > simplification: > > REQ 1: There shall be a way for a proxy or UA to request that > a session > timer be executed for a dialog. > > REQ 2: There shall be a way for the session timer to take > place so long > as EITHER the UAC or UAS supports it. > > REQ 3: There shall be a way for each element - proxy,UAC, UAS, to > specify their desired value for the session timer. > > REQ 4: There shall be a way for each element to specify their minimum > allowed value for the session tiemr. > > REQ 5: The final session timer shall be: > > MAX(MIN(desired timers),MAX(min timers)) > > REQ 6: It shall be possible to renegotiate the use of session > timer, and > its value, at any time during a dialog. > > REQ 7: Session timer shall be immune to DoS attacks introduced by a > rogue UAC, UAS, or proxy. > > REQ 8: It shall be possible for the UAC in the initial INVITE > to suggest > itself for performing the refreshes. > > > I think that captures most of it. Some of these requirements, like 6, > fall out of general SIP properties, and we would be hard pressed to > eliminate them. > > Its also possible to get simplification through redesign while still > meeting the requirements. For example, it occurs to me that we could > potentially send the refreshes directly from the client to the > "interested" proxies. This is more overhead for the client if > there is > more than one interested proxy, but means that proxies which > don't care > about session timer don't suffer from additional message > volume, which > is a drawback of the current solution. > > By doing that, all of the negotiation becomes two-way, > between a UA and > a proxy, rather than N-way, and is thus much simplified. > > Such a solution would require a proxy requesting session > timer to have a > globally routable URI. > > > Yet another solution is to define a specific "heartbeat" media stream > type, which periodically genreates a keepalive. In that sense, its > similar to RTCP, but not RTP specific. AN intermediary can get itself > onto this heartbeat stream by being a b2bua that mucks with SDP, or > using a mechanism like the session policy which I have > formerly proposed: > http://www.jdrosen.net/papers/draft-rosenberg-sipping-session- policy-00.txt There may be other general solutions to this too. -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 Tue Nov 12 10:43:58 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03642 for ; Tue, 12 Nov 2002 10:43:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gACFk4L08939 for sip-archive@odin.ietf.org; Tue, 12 Nov 2002 10:46: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 gACFjSv08834; Tue, 12 Nov 2002 10:45: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 gACFhZv08749 for ; Tue, 12 Nov 2002 10:43:35 -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 KAA03362 for ; Tue, 12 Nov 2002 10:40:52 -0500 (EST) Received: from jku07.iptel.org (dial43.cesnet.cz [195.113.150.43]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id gACFh9n04518; Tue, 12 Nov 2002 16:43:10 +0100 Message-Id: <5.1.0.14.0.20021112155218.03f33008@iptel.org> X-Sender: jiri@iptel.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 12 Nov 2002 16:05:58 +0100 To: Jonathan Rosenberg , sip@ietf.org From: Jiri Kuthan Subject: Re: [Sip] The fate of session timer? In-Reply-To: <3DD03C2B.6030401@dynamicsoft.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: , At 12:24 AM 11/12/2002, Jonathan Rosenberg wrote: [...] >I assert that session timer is really useful for one thing, which is to provide a means to cleanup old session state in UAs and proxies. I think a reasonable example of its use is firewall-control proxies (unless they are considered a broken idea anyway). The SIP session timer mechanism can be used to propagate SIP "keep-alive" messages from UAs via proxy servers down to the firewalls (translated to some MIDCOM keep-alives). In this way, the firewall-control proxies do not have to be session-stateful to keep firewall pinholes alive. Keeping them up is then UA responsibility. Simplification of the negotiation mechanisms seems like a good thing to me. -Jiri _______________________________________________ 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 Nov 12 10:49:38 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03956 for ; Tue, 12 Nov 2002 10:49:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gACFpiD09311 for sip-archive@odin.ietf.org; Tue, 12 Nov 2002 10:51: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 gACFpIv09292; Tue, 12 Nov 2002 10:51: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 gACFoRv09245 for ; Tue, 12 Nov 2002 10:50:27 -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 KAA03856 for ; Tue, 12 Nov 2002 10:47:49 -0500 (EST) Received: from sponge.cisco.com (IDENT:mirapoint@sponge.cisco.com [64.101.128.87]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gACFoLNk015536; Tue, 12 Nov 2002 07:50:22 -0800 (PST) Received: from ARUNVENKW2Kl (arunvenk-w2kl.cisco.com [64.101.150.144]) by sponge.cisco.com (Mirapoint) with SMTP id ABQ18221; Tue, 12 Nov 2002 09:50:20 -0600 (CST) From: "Arunachalam Venkatraman" To: "Chandan Rajah" Cc: Subject: RE: [Sip] The fate of session timer? Date: Tue, 12 Nov 2002 09:50:20 -0600 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 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 Chandan Why do you think the re-INVITE time is critical and cannot be defaulted? -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Chandan Rajah Sent: Tuesday, November 12, 2002 2:07 AM To: sip@ietf.org Subject: RE: [Sip] The fate of session timer? I think it is important to change the actual scope of the session timer. If at all there is to be a session timer, it better do something worthwhile. Though, re-INVITEs could be a way of going about achieving this, deciding on the inter re-INVITE time is critical and can not be defaulted. Maybe, at this point it would be a good idea to rethink the entire mechanism and evaluate other prospective mechanism that could replace the current session timer. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Tuesday, November 12, 2002 4:54 AM To: sip@ietf.org Subject: [Sip] The fate of session timer? Folks, As you may have noticed, I submitted an update to the session timer specification. This is an old, old spec that has been around for quite some time. It receives only minimal attention these days. The general comments on the list are generally 'too complex' and 'too hard to understand'. Some of that is wording, which I will continue to work. The bigger problem, I think, is that its not at all clear what problem this draft is REALLY solving. I assert that session timer is really useful for one thing, which is to provide a means to cleanup old session state in UAs and proxies. Normally, you'd set a timer (on the order of 5 hours or something) to discard any state thats still around. However, since a call may actually last that long, you want a way to reliably know when you can flush the state. Session timer is NOT useful for determining call durations for billing purposes. Session timer is NOT useful for quickly determining that a UA has failed, in order to recover. It operates too slowly for that. So, given this somewhat-marginal value, the complexity seems startingly high. I have begun to wonder whether that is the reason for the troubles this specification is having. So, I see a few options: 1. No one cares about this spec. Discard it entirely. 2. Continue as it is, fix up some wording, and submit. Probably no one implements it since it provides little value at high cost. 3. Change the scope. Eliminate or simplify negotiation of the timer by defining a suitably long minimum. Eliminate or simplify choosing who refreshes by requiring that the UAC support the timer. And so on. The result would be a much simpler spec. 4. others? Please provide comments, particularly if you are actively using this specification for some real problem. -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 _______________________________________________ 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 Nov 12 11:59:30 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06454 for ; Tue, 12 Nov 2002 11:59:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gACH1bv13796 for sip-archive@odin.ietf.org; Tue, 12 Nov 2002 12:01:37 -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 gACH0mv13701; Tue, 12 Nov 2002 12:00: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 gACGxdv13608 for ; Tue, 12 Nov 2002 11:59:39 -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 LAA06395 for ; Tue, 12 Nov 2002 11:57:01 -0500 (EST) Received: from sponge.cisco.com (IDENT:mirapoint@sponge.cisco.com [64.101.128.87]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gACGxHaE029768; Tue, 12 Nov 2002 08:59:18 -0800 (PST) Received: from ARUNVENKW2Kl (arunvenk-w2kl.cisco.com [64.101.150.144]) by sponge.cisco.com (Mirapoint) with SMTP id ABQ19702; Tue, 12 Nov 2002 10:59:27 -0600 (CST) From: "Arunachalam Venkatraman" To: "Jonathan Rosenberg" Cc: Date: Tue, 12 Nov 2002 10:59:26 -0600 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <3DD100F0.2060107@dynamicsoft.com> Content-Transfer-Encoding: 7bit Subject: [Sip] Require header in responses (was- The fate of session timer?) 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 Jonathan I believe your statement below about the rule for adding a Require header into a response should be documented in section 20.32 of the RFC3261. Regards Venkat -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Jonathan Rosenberg Sent: Tuesday, November 12, 2002 7:24 AM To: hisham.khartabil@nokia.com Cc: chandan.rajah@wipro.com; sip@ietf.org Subject: Re: [Sip] The fate of session timer? hisham.khartabil@nokia.com wrote: > As I see it, what we are specifying here is a keepalive mechanism for > sessions. The value of the keepalive can have a default. > > UACs don't have to send any new header in an initial INVITE, but > proxies and UASs requiring session keepalive can inform the UAC of > such requirement by including a (proxy-)Require-header in the > response?? The default values can be used. No. Require/Proxy-REquire in a response is only allowed if the request contained a Supported header in the INVITE. > > In this way, each entity can take of cleaning up its own stale > sessions. No need for UAC to tell every other entity when it plans on > ending the session, it can just send a BYE. > > Btw, do we have requirements for this, or should we write one? This specification predates our requirements for requirements. So, no, there are none. I don't think we need to do a formal requirements process here. However, I think it is useful to have an email discussion of the basic requirements that underlie the current draft, to see which ones we can rule out, as it seems people seem amenable to considering a simplification: REQ 1: There shall be a way for a proxy or UA to request that a session timer be executed for a dialog. REQ 2: There shall be a way for the session timer to take place so long as EITHER the UAC or UAS supports it. REQ 3: There shall be a way for each element - proxy,UAC, UAS, to specify their desired value for the session timer. REQ 4: There shall be a way for each element to specify their minimum allowed value for the session tiemr. REQ 5: The final session timer shall be: MAX(MIN(desired timers),MAX(min timers)) REQ 6: It shall be possible to renegotiate the use of session timer, and its value, at any time during a dialog. REQ 7: Session timer shall be immune to DoS attacks introduced by a rogue UAC, UAS, or proxy. REQ 8: It shall be possible for the UAC in the initial INVITE to suggest itself for performing the refreshes. I think that captures most of it. Some of these requirements, like 6, fall out of general SIP properties, and we would be hard pressed to eliminate them. Its also possible to get simplification through redesign while still meeting the requirements. For example, it occurs to me that we could potentially send the refreshes directly from the client to the "interested" proxies. This is more overhead for the client if there is more than one interested proxy, but means that proxies which don't care about session timer don't suffer from additional message volume, which is a drawback of the current solution. By doing that, all of the negotiation becomes two-way, between a UA and a proxy, rather than N-way, and is thus much simplified. Such a solution would require a proxy requesting session timer to have a globally routable URI. Yet another solution is to define a specific "heartbeat" media stream type, which periodically genreates a keepalive. In that sense, its similar to RTCP, but not RTP specific. AN intermediary can get itself onto this heartbeat stream by being a b2bua that mucks with SDP, or using a mechanism like the session policy which I have formerly proposed: http://www.jdrosen.net/papers/draft-rosenberg-sipping-session-policy-00.txt There may be other general solutions to this too. -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 _______________________________________________ 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 Nov 12 12:55:39 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08234 for ; Tue, 12 Nov 2002 12:55:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gACHvl717627 for sip-archive@odin.ietf.org; Tue, 12 Nov 2002 12:57: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 gACHrAv17413; Tue, 12 Nov 2002 12:53: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 gACHpev17323 for ; Tue, 12 Nov 2002 12:51:40 -0500 Received: from brmx1.fl.icn.siemens.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08017 for ; Tue, 12 Nov 2002 12:49:02 -0500 (EST) Received: from boca210a.boca.ssc.siemens.com (boca210a.boca.ssc.siemens.com [165.218.12.110]) by brmx1.fl.icn.siemens.com (8.9.3/8.9.3) with ESMTP id MAA13177 for ; Tue, 12 Nov 2002 12:51:35 -0500 (EST) Received: by BOCA210A with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Nov 2002 12:51:35 -0500 Message-ID: <7A25937D23A1E64C8E93CB4A50509C2A1EBE06@stca204a.bus.sc.rolm.com> From: "Stevens, Del" To: "'sip@ietf.org'" Subject: RE: [Sip] The fate of session timer? Date: Tue, 12 Nov 2002 12:51:29 -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: , All: For us the implementation of session timers has been a customer-driven requirement for our B2BUA. I agree that this draft was difficult to understand, but it satisfies several requirements for us: 1. A simple keep-a-live mechanism (as stated previously). This prevents tying up resources in our B2BUA if something happens in the network causing a SIP UA (or proxy) to "disappear" after the receipt of 200 OK. We have a configurable timer value, but the default of 30 minutes (per the draft) seems adequate. From a telco perspective, it is important from a billing perspective to have some record of a session during failure scenarios. Yes, this record is not exact, but telcos (or the like) can generally deal with inaccurate cdr records during failures better than no record at all. 2. If our B2BUA receives an INVITE from a SIP UA (or proxy) that support session timers, the negotiation takes place, allowing a symetrical keep-a-live mechanism. If the SIP UA doesn't support session timers, then our B2BUA can still use an asymetrical keep-a-live mechanism so our UA can ensure the "other" end is still there for each session. A nice off-shoot from our implementation of session timers occurs during fail-over situation. In this case, the newly active B2BUA can "re-establish" updated state information about each in progress session by issuing a re-INVITE for the session. The responses reinitializes the session timer lists on the "new" ACTIVE machine. Even though this is an old draft several sip phone manufacturers support session timers. Also, since the implementaton of session timers is not universal, we never issue "Require: timer", but let "Supported: timer" and "Session-Expires: n" to allow the negotiation to take place. If anyone is using digest authentication with session timers this creates the need for each re-INVITE to contain an Authorization header or risk being challenged (401/407). Yes, there is some messaging and processing overhead: 1) session timer negotiation + refreshes, and 2) tracking additional timers per session. But the safety net provided is a must for some customers. My vote is to keep this draft and update as necessary! Del Stevens mailto:del.stevens@icn.siemens.com Siemens Network Convergence LLC 7800 Congress Ave Boca Raton, FL 33487 -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Monday, November 11, 2002 6:24 PM To: sip@ietf.org Subject: [Sip] The fate of session timer? Folks, As you may have noticed, I submitted an update to the session timer specification. This is an old, old spec that has been around for quite some time. It receives only minimal attention these days. The general comments on the list are generally 'too complex' and 'too hard to understand'. Some of that is wording, which I will continue to work. The bigger problem, I think, is that its not at all clear what problem this draft is REALLY solving. I assert that session timer is really useful for one thing, which is to provide a means to cleanup old session state in UAs and proxies. Normally, you'd set a timer (on the order of 5 hours or something) to discard any state thats still around. However, since a call may actually last that long, you want a way to reliably know when you can flush the state. Session timer is NOT useful for determining call durations for billing purposes. Session timer is NOT useful for quickly determining that a UA has failed, in order to recover. It operates too slowly for that. So, given this somewhat-marginal value, the complexity seems startingly high. I have begun to wonder whether that is the reason for the troubles this specification is having. So, I see a few options: 1. No one cares about this spec. Discard it entirely. 2. Continue as it is, fix up some wording, and submit. Probably no one implements it since it provides little value at high cost. 3. Change the scope. Eliminate or simplify negotiation of the timer by defining a suitably long minimum. Eliminate or simplify choosing who refreshes by requiring that the UAC support the timer. And so on. The result would be a much simpler spec. 4. others? Please provide comments, particularly if you are actively using this specification for some real problem. -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 _______________________________________________ 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 Nov 12 14:59:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12692 for ; Tue, 12 Nov 2002 14:59:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gACK1qT25729 for sip-archive@odin.ietf.org; Tue, 12 Nov 2002 15:01: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 gACK17v25711; Tue, 12 Nov 2002 15: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 gACJxBv25575 for ; Tue, 12 Nov 2002 14:59:11 -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 OAA12517 for ; Tue, 12 Nov 2002 14:56:32 -0500 (EST) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0H5H00D58BHLB9@firewall.wcom.com> for sip@ietf.org; Tue, 12 Nov 2002 19:58:35 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H5H00201B9OZD@pmismtp01.wcomnet.com> for sip@ietf.org; Tue, 12 Nov 2002 19:58:34 +0000 (GMT) Received: from ajohnston.wcom.com ([166.42.33.165]) by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H5H002GEBG8US@pmismtp01.wcomnet.com> for sip@ietf.org; Tue, 12 Nov 2002 19:57:45 +0000 (GMT) Date: Tue, 12 Nov 2002 13:57:13 -0600 From: Alan Johnston X-Sender: Alan.Johnston@pop.mcit.com To: sip@ietf.org Message-id: <5.1.1.6.0.20021112134856.0272ecd0@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; charset=us-ascii; format=flowed Subject: [Sip] RE:I-D ACTION:draft-johnston-sip-osp-token-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: , All, Below is a new version of the old OSP Authorization Token header I-D for SIP. It represents some old AAA work that I'd like to bring to closure. It is proposed as a P-header as it is not a SIP WG chartered item nor do I want it to be. Anyone wishing to discuss should email myself or the authors directly - many of the authors will be in Atlanta next week as well. Please keep any discussion of this draft off the SIP WG list. Thanks, Alan Johnston WorldCom sip:alan@digitalari.com -------------------------------------------------------------------------------- To: IETF-Announce: ; Subject: I-D ACTION:draft-johnston-sip-osp-token-03.txt From: Internet-Drafts@ietf.org Date: Tue, 05 Nov 2002 06:07:45 -0500 -------------------------------------------------------------------------------- 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, H. Sinnreich, S. Thomas, R. Brennan, and D. Isakbayev Filename : draft-johnston-sip-osp-token-03.txt Pages : 8 Date : 2002-11-4 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-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-johnston-sip-osp-token-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-johnston-sip-osp-token-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. ftp://ftp.ietf.org/internet-drafts/draft-johnston-sip-osp-token-03.txt _______________________________________________ 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 Nov 12 15:43:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14466 for ; Tue, 12 Nov 2002 15:43:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gACKjBi28906 for sip-archive@odin.ietf.org; Tue, 12 Nov 2002 15:45: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 gACKefv28639; Tue, 12 Nov 2002 15:40: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 gACKdlv28570 for ; Tue, 12 Nov 2002 15:39:47 -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 PAA14232 for ; Tue, 12 Nov 2002 15:37:08 -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 gACKcARc009079; Tue, 12 Nov 2002 15:38:11 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Nov 2002 14:39:09 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64318@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Stevens, Del'" , "'sip@ietf.org'" Subject: RE: [Sip] The fate of session timer? Date: Tue, 12 Nov 2002 14:39:08 -0600 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: , Session timer isn't needed for a back to back user agent. B2BUAs are user agents, plain and simple. If you want to check liveness on either side, you can send a re-INVITE. /a > -----Original Message----- > From: Stevens, Del [mailto:Del.Stevens@icn.siemens.com] > Sent: Tuesday, November 12, 2002 11:51 > To: 'sip@ietf.org' > Subject: RE: [Sip] The fate of session timer? > > > All: > > For us the implementation of session timers has been a customer-driven > requirement for our B2BUA. I agree that this draft was difficult to > understand, but it satisfies several requirements for us: > > 1. A simple keep-a-live mechanism (as stated previously). > This prevents > tying up resources in our B2BUA if something happens in the > network causing > a SIP UA (or proxy) to "disappear" after the receipt of 200 > OK. We have a > configurable timer value, but the default of 30 minutes (per > the draft) > seems adequate. From a telco perspective, it is important > from a billing > perspective to have some record of a session during failure > scenarios. Yes, > this record is not exact, but telcos (or the like) can > generally deal with > inaccurate cdr records during failures better than no record at all. > > 2. If our B2BUA receives an INVITE from a SIP UA (or proxy) > that support > session timers, the negotiation takes place, allowing a symetrical > keep-a-live mechanism. If the SIP UA doesn't support session > timers, then > our B2BUA can still use an asymetrical keep-a-live mechanism > so our UA can > ensure the "other" end is still there for each session. > > A nice off-shoot from our implementation of session timers > occurs during > fail-over situation. In this case, the newly active B2BUA can > "re-establish" > updated state information about each in progress session by issuing a > re-INVITE for the session. The responses reinitializes the > session timer > lists on the "new" ACTIVE machine. > > Even though this is an old draft several sip phone > manufacturers support > session timers. Also, since the implementaton of session timers is not > universal, we never issue "Require: timer", but let > "Supported: timer" and > "Session-Expires: n" to allow the negotiation to take place. > > If anyone is using digest authentication with session timers > this creates > the need for each re-INVITE to contain an Authorization > header or risk being > challenged (401/407). > > Yes, there is some messaging and processing overhead: 1) session timer > negotiation + refreshes, and 2) tracking additional timers > per session. But > the safety net provided is a must for some customers. My vote > is to keep > this draft and update as necessary! > > > Del Stevens mailto:del.stevens@icn.siemens.com > Siemens Network Convergence LLC > 7800 Congress Ave > Boca Raton, FL 33487 > > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Monday, November 11, 2002 6:24 PM > To: sip@ietf.org > Subject: [Sip] The fate of session timer? > > > Folks, > > As you may have noticed, I submitted an update to the session timer > specification. This is an old, old spec that has been around > for quite > some time. It receives only minimal attention these days. The general > comments on the list are generally 'too complex' and 'too hard to > understand'. Some of that is wording, which I will continue > to work. The > bigger problem, I think, is that its not at all clear what > problem this > draft is REALLY solving. > > I assert that session timer is really useful for one thing, > which is to > provide a means to cleanup old session state in UAs and proxies. > Normally, you'd set a timer (on the order of 5 hours or something) to > discard any state thats still around. However, since a call > may actually > last that long, you want a way to reliably know when you can > flush the > state. > > Session timer is NOT useful for determining call durations > for billing > purposes. > > Session timer is NOT useful for quickly determining that a UA has > failed, in order to recover. It operates too slowly for that. > > So, given this somewhat-marginal value, the complexity seems > startingly > high. I have begun to wonder whether that is the reason for > the troubles > this specification is having. So, I see a few options: > > 1. No one cares about this spec. Discard it entirely. > > 2. Continue as it is, fix up some wording, and submit. > Probably no one > implements it since it provides little value at high cost. > > 3. Change the scope. Eliminate or simplify negotiation of the > timer by > defining a suitably long minimum. Eliminate or simplify choosing who > refreshes by requiring that the UAC support the timer. And so on. The > result would be a much simpler spec. > > 4. others? > > > Please provide comments, particularly if you are actively using this > specification for some real problem. > > -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 > _______________________________________________ > 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 Nov 12 17:09:04 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18096 for ; Tue, 12 Nov 2002 17:09:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gACMBD202994 for sip-archive@odin.ietf.org; Tue, 12 Nov 2002 17:11: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 gACLs0v01294; Tue, 12 Nov 2002 16: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 gACLqmv01236 for ; Tue, 12 Nov 2002 16:52:48 -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 QAA17573 for ; Tue, 12 Nov 2002 16:50:07 -0500 (EST) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id gACLqYQu026546; Tue, 12 Nov 2002 15:52:38 -0600 From: "Dean Willis" To: "'Leonardo Rico'" , Subject: RE: [Sip] B2BUA Date: Tue, 12 Nov 2002 15:52:30 -0600 Message-ID: <007401c28a95$cfdad320$12f10a0a@TXDWILLIS2> 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 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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 Leonardo Rico asked: > > I was looking into the issue of B2BUA and found it not clear in some > aspects. For example some mail exchange in July 2001 says a > B2BUA associates > one or more calls meaning it can also be only one or more > then 2. All definitions I found say it is UAS on one side and > UAC on the other. Can > it also be UAC on one or more sides (meaning it initiated > calls to a few > UAs)? > > What type of applications will it be used for. The drafts > talk about using > it for FW traversal, Anonymizer, 3PCC. Do you see it also > functioning as a > PBX for example? > What other type of applications do you see functioning as > B2BUA? Do you see it coupled with a SIP > Proxy/Registrar/Redirect in one physical > entity? Ok, time for my yearly B2BUA speech. There's a simple reason that we don't specify the B2BUA in any greater detail in SIP. It's a UA. It can do ANYTHING A UA CAN DO, including create and associate additional dialogs, order a beer in a bar, insult the president, translate to a different protocol, whatever. It's a completely unbounded problem space, NP complete, and totally intractable. If you believe Wolfram, the B2BUA is an example of the Universal Computer and if evolved infinitely answers Adam's Universal Question, "you know, life, the universe, and everything." Now, back to earth -- a B2BUA can be used in many different ways. Sufficiently constrained, it's called a "proxy" -- a proxy being a B2BUA that meets certain requirements for transparency. B2BUAs that break these transparency rules are useful for a wide variety of roles, including the ones you mention. They might also be useful as call-center controllers, operator-services nodes (barge-in, emergency disconnect), lawful intercept points, conference/bridge controllers, PBXes, etc. Many commercial service nodes have the capacity to act as B2BUAs as well as proxies and redirectors. That being said, transparency is still important. The transparency rules for proxies are there to protect functionality, including preservation of end-node expectations and security. We will consider the transparency requirements of proxies as we continue to define the SIP protocol. We will NOT take into account partial-transparency issues from the infinite diversity of B2BUAs. Therefore, reliance on a B2BUA is risky. Odds are, somewhere, somehow, it is going to break some piece of functionality that somebody finds critically important. You've been warned. If you use one, and it breaks something, don't blame us. -- 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 Tue Nov 12 23:03:10 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26215 for ; Tue, 12 Nov 2002 23:03:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAD45M122688 for sip-archive@odin.ietf.org; Tue, 12 Nov 2002 23:05:22 -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 gAD3aVv21082; Tue, 12 Nov 2002 22:36: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 gAD3Y1v20957 for ; Tue, 12 Nov 2002 22:34:02 -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 WAA25502 for ; Tue, 12 Nov 2002 22:31:19 -0500 (EST) Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.11.6) id gAD3Xrd05260; Tue, 12 Nov 2002 22:33:53 -0500 (EST) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] The fate of session timer? Date: Tue, 12 Nov 2002 22:34:14 -0500 Message-ID: <001f01c28ac5$8ac2ae40$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) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <3DD03C2B.6030401@dynamicsoft.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 The functionality provided by the draft is needed. I vote to perform yet another WGLC on the draft. More vendors will implement or upgrade implementations once the draft actually becomes an RFC. _______________________________________________ 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 Nov 13 02:53:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24114 for ; Wed, 13 Nov 2002 02:53:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAD7tPu10296 for sip-archive@odin.ietf.org; Wed, 13 Nov 2002 02:55: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 gAD7skv10276; Wed, 13 Nov 2002 02:54: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 gAD7q6v10199 for ; Wed, 13 Nov 2002 02:52:06 -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 CAA24086 for ; Wed, 13 Nov 2002 02:49:22 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAD7pqKV024022; Wed, 13 Nov 2002 08:51:52 +0100 (MET) Received: from lmf.ericsson.se (chzuwa01m08.eu.ericsson.se [164.48.166.8]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id gAD7pnCG001239; Wed, 13 Nov 2002 09:51:50 +0200 (EET) Message-ID: <3DD204A6.1F7EA21B@lmf.ericsson.se> Date: Wed, 13 Nov 2002 09:52:06 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Stevens, Del" CC: "'sip@ietf.org'" Subject: Re: [Sip] The fate of session timer? References: <7A25937D23A1E64C8E93CB4A50509C2A1EBE06@stca204a.bus.sc.rolm.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 Hi, Some comments/thoughts from me about this. First, since the purpose of the session-timer (as Jonathan said) currently only is to clean up sessions, and NOT to recover state etc, I would like to get anything related to the offer/answer mechanism away from it. UAs may need the send offers for real stream related purposes, so it should not have to do buffering in case there is an ongoing session-timer offer/answer transaction. No, due to the long timer value for the session-timer this will probably not happen very often, but still. Second (and please don't flame me :), would it be a good idea to have a look at the INFO method again? The reason we didn't want it in the first place was because it shall not be used for chaning state. But, since we now don't use the session-timer for state recover that reason is maybe not valid anymore (it is NOT the INFO itself which changes the call state). I think one of the keys to the success of the session-timer is to make it as light as possible. No idea to include SDPs, and absolutely no idea to use re-INVITE, which also requires ACK. But, of course it's also a question about if anyone has any interest in this work. Regards, Christer Holmberg Ericsson Finland "Stevens, Del" wrote: > All: > > For us the implementation of session timers has been a customer-driven > requirement for our B2BUA. I agree that this draft was difficult to > understand, but it satisfies several requirements for us: > > 1. A simple keep-a-live mechanism (as stated previously). This prevents > tying up resources in our B2BUA if something happens in the network causing > a SIP UA (or proxy) to "disappear" after the receipt of 200 OK. We have a > configurable timer value, but the default of 30 minutes (per the draft) > seems adequate. From a telco perspective, it is important from a billing > perspective to have some record of a session during failure scenarios. Yes, > this record is not exact, but telcos (or the like) can generally deal with > inaccurate cdr records during failures better than no record at all. > > 2. If our B2BUA receives an INVITE from a SIP UA (or proxy) that support > session timers, the negotiation takes place, allowing a symetrical > keep-a-live mechanism. If the SIP UA doesn't support session timers, then > our B2BUA can still use an asymetrical keep-a-live mechanism so our UA can > ensure the "other" end is still there for each session. > > A nice off-shoot from our implementation of session timers occurs during > fail-over situation. In this case, the newly active B2BUA can "re-establish" > updated state information about each in progress session by issuing a > re-INVITE for the session. The responses reinitializes the session timer > lists on the "new" ACTIVE machine. > > Even though this is an old draft several sip phone manufacturers support > session timers. Also, since the implementaton of session timers is not > universal, we never issue "Require: timer", but let "Supported: timer" and > "Session-Expires: n" to allow the negotiation to take place. > > If anyone is using digest authentication with session timers this creates > the need for each re-INVITE to contain an Authorization header or risk being > challenged (401/407). > > Yes, there is some messaging and processing overhead: 1) session timer > negotiation + refreshes, and 2) tracking additional timers per session. But > the safety net provided is a must for some customers. My vote is to keep > this draft and update as necessary! > > Del Stevens mailto:del.stevens@icn.siemens.com > Siemens Network Convergence LLC > 7800 Congress Ave > Boca Raton, FL 33487 > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Monday, November 11, 2002 6:24 PM > To: sip@ietf.org > Subject: [Sip] The fate of session timer? > > Folks, > > As you may have noticed, I submitted an update to the session timer > specification. This is an old, old spec that has been around for quite > some time. It receives only minimal attention these days. The general > comments on the list are generally 'too complex' and 'too hard to > understand'. Some of that is wording, which I will continue to work. The > bigger problem, I think, is that its not at all clear what problem this > draft is REALLY solving. > > I assert that session timer is really useful for one thing, which is to > provide a means to cleanup old session state in UAs and proxies. > Normally, you'd set a timer (on the order of 5 hours or something) to > discard any state thats still around. However, since a call may actually > last that long, you want a way to reliably know when you can flush the > state. > > Session timer is NOT useful for determining call durations for billing > purposes. > > Session timer is NOT useful for quickly determining that a UA has > failed, in order to recover. It operates too slowly for that. > > So, given this somewhat-marginal value, the complexity seems startingly > high. I have begun to wonder whether that is the reason for the troubles > this specification is having. So, I see a few options: > > 1. No one cares about this spec. Discard it entirely. > > 2. Continue as it is, fix up some wording, and submit. Probably no one > implements it since it provides little value at high cost. > > 3. Change the scope. Eliminate or simplify negotiation of the timer by > defining a suitably long minimum. Eliminate or simplify choosing who > refreshes by requiring that the UAC support the timer. And so on. The > result would be a much simpler spec. > > 4. others? > > Please provide comments, particularly if you are actively using this > specification for some real problem. > > -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 > _______________________________________________ > 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 Nov 13 07:38:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28956 for ; Wed, 13 Nov 2002 07:38:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gADCePo26170 for sip-archive@odin.ietf.org; Wed, 13 Nov 2002 07:40: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 gADCdrv26120; Wed, 13 Nov 2002 07:39: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 gADCa5v25427 for ; Wed, 13 Nov 2002 07:36:05 -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 HAA28914 for ; Wed, 13 Nov 2002 07:33:28 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.41]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gADCZPYH029524; Wed, 13 Nov 2002 07:35:26 -0500 (EST) Message-ID: <3DD2470B.9080809@dynamicsoft.com> Date: Wed, 13 Nov 2002 07:35:23 -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: Christer Holmberg CC: "Stevens, Del" , "'sip@ietf.org'" Subject: Re: [Sip] The fate of session timer? References: <7A25937D23A1E64C8E93CB4A50509C2A1EBE06@stca204a.bus.sc.rolm.com> <3DD204A6.1F7EA21B@lmf.ericsson.se> 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 Christer Holmberg wrote: > Second (and please don't flame me :), would it be a good idea to have a look at > the INFO method again? The reason we didn't want it in the first place was > because it shall not be used for chaning state. But, since we now don't use the > session-timer for state recover that reason is maybe not valid anymore (it is > NOT the INFO itself which changes the call state). The draft already specifies UPDATE. The UPDATE can be sent without a session description. Please explain what benefits there are to specifying the usage of INFO in addition. -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 Nov 13 07:39:17 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28972 for ; Wed, 13 Nov 2002 07:39:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gADCfLA26233 for sip-archive@odin.ietf.org; Wed, 13 Nov 2002 07:41: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 gADCf6v26215; Wed, 13 Nov 2002 07:41: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 gADCeHv26166 for ; Wed, 13 Nov 2002 07:40:17 -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 HAA28940 for ; Wed, 13 Nov 2002 07:37:40 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.41]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gADCeDYH029528; Wed, 13 Nov 2002 07:40:15 -0500 (EST) Message-ID: <3DD2482B.9030301@dynamicsoft.com> Date: Wed, 13 Nov 2002 07:40:11 -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: chandan.rajah@wipro.com, sip@ietf.org Subject: Re: [Sip] The fate of session timer? References: <2038BCC78B1AD641891A0D1AE133DBB7FE6FAB@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 hisham.khartabil@nokia.com wrote: > The current draft fulfils all the requests stated below, but there > has been a couple of emails on this thread asking for simplifications > to the draft. That's why I asked for requirements. > > The simplification might start by examining the need for REQs 3-6. > > Also for REQ 1, what is the rationale behind a UAC or proxy > requesting session timer to be started on the remote end? Each entity > only needs to take care of its own stale sessions (something I tried > to propose in my earlier email). Well, certainly one UA will care that the other UA has crashed. Session timer allows a UAC or UAS to get refreshes in order to make that determination. As Adam points out, thats not strictly needed; a UA can simply send a re-INVITE or UPDATE whenever it wants to perform a refresh. Doing it through session timer, however, avoids having both sides sending UPDATEs or re-INVITEs to refresh the session, and allows for negotiation of a timer. -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 Nov 13 08:28:15 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00108 for ; Wed, 13 Nov 2002 08:28:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gADDUJD28899 for sip-archive@odin.ietf.org; Wed, 13 Nov 2002 08:30:19 -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 gADDTgv28859; Wed, 13 Nov 2002 08: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 gADDS8v28795 for ; Wed, 13 Nov 2002 08:28:08 -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 IAA00078 for ; Wed, 13 Nov 2002 08:25:31 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.41]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gADDS5YH029552 for ; Wed, 13 Nov 2002 08:28:06 -0500 (EST) Message-ID: <3DD25363.30408@dynamicsoft.com> Date: Wed, 13 Nov 2002 08:28:03 -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] an update to caller prefs 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, As you probably noticed, I posted an update to the caller prefs spec. There were a lot of changes between this rev and the last, as the issues of rfc2533 integration get sorted out. Below you will find a list of changes. I quickly found that figuring out the "right thing" in terms of behavior was difficult without some concrete use cases to motivate it. As a result, I worked with Paul Kyzivat to put together some use cases for caller prefs. The result is a work-in-progress I-D that I did not submit yet, but might be useful for the group to take a look at in order to understand some of whats in callerr prefs: http://www.jdrosen.net/papers/draft-rosenberg-sip-callerprefs-usecases-0a.txt Paul and I will be updating this and then submit after the moratorium. I will be sending some separate emails on the various open issues in the draft. -Jonathan R. Changes from -06: * changed the priority attribute from an ordered token to an integer, by mapping values of the SIP Priority header field to integers. This is needed because, despite the text in RFC 2506, RFC 2533 does not actually support tokens with an ordered relationship. Thats a good thing, since if it did, a proxy would need to know about the attribute in order to perform the matching operation. With an integral value, it doesn't need to. * requested IANA to assign ASN.1 values for the various attributes. This was done per Graham Klyne's recommendation. Even though we don't need them, they would allow other ASN.1 based protocols to use these attributes. * In rfc2533, feature tag values can be either quoted or not. When quotes are present, it means that the value is to be compared CS, and when not present, CI. We need to provide a similar clue to proxies, so they can determine whether an attribute value is to be compared CI or CS. We can't use quoted strings for that, since each contact parameter value is already surrounded by quoted strings. So, a pair of angle brackets <> is now used to indicate a CS comparison. * clarified that a proxy doesn't need to know anything about the feature tags in order to properly perform the matching operation. I hadn't figured out how this was supported in rfc2533, but after a discussion with Graham at ietf 54, I now understand. The following text was added to summarize the basic idea: -- It is important to note that the proxy does not have to know anything about the meaning of the feature tags that it is comparing. The rules for performing the comparison depend on syntactic hints present in the values of each feature tag. For example, a predicate such as: \begin{verbatim} foo>=4 \end{verbatim} implies that the feature tag foo is a numeric value. The matching rules in RFC 2533 only require to know whether the feature tag is a numeric, token, quoted string, etc. -- * pointed out in IANA considerations section that the registrations are meant for the IETF tree. * added left and right angle brackets to grammar for the string-value feature tags. * noted that the string value feature tags in caller prefs support UTF-8 strings, whereas RFC 2533 allows only US-ASCII. Explicitly pointed out that this is NOT a problem, since these values are only compared using CS rules. We got burned in bis when it was not explicitly stated that we weren't ever trying to do CI matching on arbitrary utf-8 header field values. * explicitly indicated that feature tags are from any of the registration trees defined in rfc 2506. THis includes the URI tree, which allows for vendor-specific feature tags. The usage of the URI tree for this purpose is explicitly called out. * indicated that when a caller prefs parameter and a header can indicate the same capability in a dialog-establishing message, the header takes precedence. For example, the methods parameter vs. the Allow header. If both are present, Allow is used. * removed the media feature tag (whcih indicated the top level MIME types supported by the UA), and added separate feature tags for audio, video, message, application, text and image, each as a separate boolean tag. So, if a device can do audio and video, its registration might be like: Contact: sip:1.2.3.4;audio="TRUE";video="TRUE" The benefit of this, as discussed at IETF 54, is that the Accept-Contact header can explicitly ask for things like "route this call to a device that does BOTH audio and video". This kind of split is generally needed whenever you want to ask for a UA that supports multiple values of a single feature tag. * added support for an implicit preference for media types, by examining the SDP in an INVITE. SO, for example, if the SDP has two m lines, one audio, one video, the proxy can treat it as if there was an Accept-Contact header with audio=TRUE and video=TRUE in it. This is done with MAY strenth, since I don't want to force proxies to look at bodies. * removed the "features" attribute, and added a separate boolean for voicemail and for attendant. This is because the features tag said its values are orthogonal. This orthogonality implies that they should be separate features. Also, clarified that when you say this: Contact: sip:1.2.3.4;voicemail="TRUE" in a REGISTER, it does NOT mean that this is a phone that will fall back to voicemail on no answer - it means that this device *IS* a voicemail server. That allows a caller to very explicitly request thigns like "dont route this call to voicemail" - a very, very, very handy thing IMHO. * added text recommending that if a UA registers support for a specific MIME type (such as video/h263), it should also register support for the top level MIME type (video=TRUE). * changed the BNF for the feature tag values from token to token-nobang, which is the same as token but without the !. This is necessary to avoid ambiguity over whether the ! is a negation operator or part of the feature tag value. * the negation operator used to apply to the entire disjunction. Now, it applies to an individual element. That is: Accept-Contact:*;duplex="!half,send" used to mean: (! (| (duplex=half) (duplex=send))) and now means: (| (! (duplex=half)) (duplex=send)) apparently, usage of the negation operator over the entire disjunction can introduce computation complexity into the comparison algorithm. Plus, I think this usage of applying it to individual elements is more intuitive and useful. * pointed out that there is no way to tell if a contact param is a feature tag used by caller prefs, or a contact parameter used by another extension. however, it turns out that it doesn't matter, and this is explained in the document. * added support for numeric feature inequalities and ranges. In the previous draft, if you had a numeric feature tag, such as "x-resolution", the only thing you could do as indicate that it equals some value. You couldn't ask for a UA with a display less than a certain x resolution, or within a range of values. This is a critical weakness, and would prohibit us from expressing many capabilities which will be useful for wireless (things like memory constraints, display constraints, etc.). This is fixed now, allowing all of the rfc 2533 numeric constraints. * added support for features which are strings, meaning that they are compared using case sensitive matching rules, rather than case insensitive, which is the case for tokens. THey are indicated with angle brackets. * added the Require-Contact header. It allows a UA to indicate that a request should only be routed to a matching UA, and all others are discarded. It is similar to accept-Contact, but more forceful. Several use cases required differentiating this modality from that of Accept-Contact. * added the cid and https URI schemes to the list of schemes that can be used with the schemes tag. * Consolidated BNF into one section * Grammar for Reject-Contact used to allow a q-value, even though q-values are not used for that header. This has been fixed. * implementation strength of the preferences algorithms at a compliant proxy was not specified. It is now listed as SHOULD. * mention in several places that using rfc2533 syntax as an intermediate processing step is not mandatory. Any implementation that results in the same outputs can be used. * Added subsections to the proxy processing section to facilitate reading. * The "only=TRUE" parameter present in callerprefs-05, and omitted from -06, is now back, but in a different way. It is integrated into the processing performed by a UAS, which will also honor the Accept,Reject and Require-Contact header fields. Only a UA will include the uri-user and uri-domain filter rules into the feature set that describes a UA. Combined with the rules for how require and reject-contact processing happens, the net result is that URI preferences are only ever checked at a UA; this is the only place they can be. * Some implicit preferences are now Require-Contact preferences - specifically, those where the request will fail if routed to a UA which doesn't support the preference. That includes methods and events. * Accept-Contact implicit preferences work by creating a NEW predicate for the implicit preferences, rather than adding terms to existing predicates. This has better behavior in the event the explicit preference doesn't match. For example, if a user indicates a preference for voicemail (Accept-Contact: *;voicemail="TRUE") and adds an Accept-Language header for Spanish, their call will prefer a Spanish voicemail system, and if thats not available, either a SPanish user or an English voicemail system. The least preferred contact would be an English user. * Added Accept-Language implicit preferences. * proxies no longer add an implicit uri-user and uri-domain term to the contact predicate. * Added a brief tutorial on RFC 2533, covering sufficient material to understand caller prefs without reading it. * Added mention of rfc 2738, which provides a minor update to rfc2533. * added text recommending that a UA provide full disclosure in its feature set registrations, and that it MUST list all values for a particular feature tag that it does include. * mentioned that other applications can used the capability information uploaded in caller prefs. * described the general model of how rfc2533 applies to SIP UAs, and why it matters. * consistent use of the terms header, header field * added IANA registration for pref option tag. * general improvement in terminology * clarify that you can change feature sets mid-dialog by sending an updated feature set in a target refresh request. * CHanged the four header fields from "amr" (in terms of table 1/2) to "r", since proxies shouldnt muck with them. We'd like to preserve e2e signatures on them. -- 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 Nov 13 09:55:37 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03454 for ; Wed, 13 Nov 2002 09:55:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gADEvgj02565 for sip-archive@odin.ietf.org; Wed, 13 Nov 2002 09:57: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 gADEv9v02454; Wed, 13 Nov 2002 09:57: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 gADEtsv02394 for ; Wed, 13 Nov 2002 09:55:54 -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 JAA03348 for ; Wed, 13 Nov 2002 09:53:17 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gADEtoKV007298; Wed, 13 Nov 2002 15:55:50 +0100 (MET) Received: from lmf.ericsson.se (chzuwa01m24.eu.ericsson.se [164.48.166.24]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id gADEtlCG029049; Wed, 13 Nov 2002 16:55:48 +0200 (EET) Message-ID: <3DD26805.A354CEF1@lmf.ericsson.se> Date: Wed, 13 Nov 2002 16:56:05 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Stevens, Del" , "'sip@ietf.org'" Subject: Re: [Sip] The fate of session timer? References: <7A25937D23A1E64C8E93CB4A50509C2A1EBE06@stca204a.bus.sc.rolm.com> <3DD204A6.1F7EA21B@lmf.ericsson.se> <3DD2470B.9080809@dynamicsoft.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 Hi, UPDATE without SDP is fine too. Just as long as we don't initiate offer/answer exchanges without any real meaning, and just as long as the timer refresh doesn't prevent either party to send UPDATE/re-INVITE to initiate a real offer/answer mechansim during the lifetime of the timer refresh transaction. Regards, Christer Holmberg Ericsson Finland Jonathan Rosenberg wrote: > Christer Holmberg wrote: > > > Second (and please don't flame me :), would it be a good idea to have a look at > > the INFO method again? The reason we didn't want it in the first place was > > because it shall not be used for chaning state. But, since we now don't use the > > session-timer for state recover that reason is maybe not valid anymore (it is > > NOT the INFO itself which changes the call state). > > The draft already specifies UPDATE. The UPDATE can be sent without a > session description. Please explain what benefits there are to > specifying the usage of INFO in addition. > > -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 Nov 13 11:20:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06891 for ; Wed, 13 Nov 2002 11:20:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gADGMs709490 for sip-archive@odin.ietf.org; Wed, 13 Nov 2002 11:22: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 gADGM8v09377; Wed, 13 Nov 2002 11:22: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 gADGHav09153 for ; Wed, 13 Nov 2002 11:17:37 -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 LAA06473 for ; Wed, 13 Nov 2002 11:14:58 -0500 (EST) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gADGHkHS005957; Wed, 13 Nov 2002 11:17:46 -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 AAQ55670; Wed, 13 Nov 2002 11:17:23 -0500 (EST) Message-ID: <3DD27B13.9C5DD6B1@cisco.com> Date: Wed, 13 Nov 2002 11:17:23 -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: "Zhang, Bo" CC: "'sip@ietf.org'" Subject: Re: [Sip] SIP MIB module ID conflicts 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 "Zhang, Bo" wrote: > > Hello, all, > > Besides the OID question, I'm a little confused on the port > table in common MIB and the server table in UA MIB. > > The row of the port table only specifies rcv and snd transport > protocols. It does NOT contain IP address or port ID to be used > for the port. How is the port used exactly? bo, i'm not able to reconstruct the history of this table very well. the lack of ip address information seems to make the table quite useless. i'm guessing that it's intention was to publicize all of the tcp/udp ports being used by the sip entity, but i can't say i find a compelling reason for this - as it's defined at least. the port id is embodied in the table index object: sipPort. we'll revisit this table for the next revision of the draft. any suggestions you may have are welcome. > > It looks like that each row in the UA server table specifies a > UAS that a UAC can contact. It is used for outbound proxy, right? yes, afiak that's correct. kevin > > I would greatly appreciate it if anyone can help me out here. > > Bo > > -----Original Message----- > From: Kevin Lingle [mailto:klingle@cisco.com] > Sent: Friday, November 01, 2002 7:23 AM > To: Zhang, Bo > Cc: 'sip@ietf.org' > Subject: Re: [Sip] SIP MIB module ID conflicts > > "Zhang, Bo" wrote: > > > > Hello, all, > > > > I got a SIP MIB draft 04 version from > > > > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-mib-04.txt. > > > > I'm NOT sure if this is the latest. But in it, there is a conflict > > definition > > of Module ID. The sipTC and sipUAMIB both have module ID of > > { mib-2 9992 }. If this has already been fixed, could some one post > > the latest document? > > bo, > > -04 is the latest published version of the doc. > -05 is planned, but for several reasons has been > slow coming. > > wrt the module id issues... those mib-2 oids are > placeholders anyway. they are not official IANA > assigned numbers, so the conflict is not a big issue. > granted, they should be unique, but no one should be > attempting to implement these mibs as "mib-2 " > anyway. they are draft mibs at this point. > > i will make sure they have unique oids for the next > revision though. > > btw, we expect -05 revision to be the > last before we go to IESG for an rfc. -04 _was_ ready > for that, but the coming of RFC 3261 caused us to pause > (didn't expect to pause this long though;) and update > the mib draft to be inline with the new sip rfc. > > thanks > kevin > > > > Thanks, > > > > Bo > > _______________________________________________ > > 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 > checkout: http://wwwin-eng.cisco.com/Eng/IOS/SNMP_WWW/mib-police/ > Sometimes I think I understand everything, then I regain consciousness. > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > _______________________________________________ > 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 checkout: http://wwwin-eng.cisco.com/Eng/IOS/SNMP_WWW/mib-police/ Sometimes I think I understand everything, then I regain consciousness. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= _______________________________________________ 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 Nov 13 11:26:22 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07169 for ; Wed, 13 Nov 2002 11:26:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gADGSTJ10250 for sip-archive@odin.ietf.org; Wed, 13 Nov 2002 11:28:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADGS9v10155; Wed, 13 Nov 2002 11:28: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 gADGN7v09652 for ; Wed, 13 Nov 2002 11:23:07 -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 LAA06871 for ; Wed, 13 Nov 2002 11:20:28 -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 gADGNeB07473 for ; Wed, 13 Nov 2002 18:23:40 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 13 Nov 2002 18:22:24 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 13 Nov 2002 18:22:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] The fate of session timer? Date: Wed, 13 Nov 2002 18:22:23 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE6FB7@esebe019.ntc.nokia.com> Thread-Topic: [Sip] The fate of session timer? Thread-Index: AcKLEjmXzkbMvwe9SM6RVns230twBAAG3KDA To: Cc: , X-OriginalArrivalTime: 13 Nov 2002 16:22:24.0705 (UTC) FILETIME=[D9B5B310:01C28B30] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gADGN8v09659 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 > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, November 13, 2002 2:40 PM > To: Khartabil Hisham (NMP/Helsinki) > Cc: chandan.rajah@wipro.com; sip@ietf.org > Subject: Re: [Sip] The fate of session timer? > > > > > hisham.khartabil@nokia.com wrote: > > The current draft fulfils all the requests stated below, but there > > has been a couple of emails on this thread asking for > simplifications > > to the draft. That's why I asked for requirements. > > > > The simplification might start by examining the need for REQs 3-6. > > > > Also for REQ 1, what is the rationale behind a UAC or proxy > > requesting session timer to be started on the remote end? > Each entity > > only needs to take care of its own stale sessions > (something I tried > > to propose in my earlier email). > > Well, certainly one UA will care that the other UA has > crashed. Session > timer allows a UAC or UAS to get refreshes in order to make that > determination. This requires both ends to have support for session timer. Also, is it a safe assumption to make that if a UA doesn't send a session-timer refresh, then it has crashed? In you earlier email, you pointed out that the sole purpose of session-timer is to clean up old sessions. "I assert that session timer is really useful for one thing, which is to provide a means to cleanup old session state in UAs and proxies." Why does my UA care about cleaning up old session at the remote side? or Is the purpose of this I-D already extended? Regards, Hisham > As Adam points out, thats not strictly needed; > a UA can > simply send a re-INVITE or UPDATE whenever it wants to perform a > refresh. Doing it through session timer, however, avoids having both > sides sending UPDATEs or re-INVITEs to refresh the session, > and allows > for negotiation of a timer. > > -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 Nov 13 11:50:39 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07844 for ; Wed, 13 Nov 2002 11:50:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gADGql311984 for sip-archive@odin.ietf.org; Wed, 13 Nov 2002 11:52: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 gADGjfv11672; Wed, 13 Nov 2002 11:45: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 gADGiLv11606 for ; Wed, 13 Nov 2002 11:44:21 -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 LAA07643 for ; Wed, 13 Nov 2002 11:41:42 -0500 (EST) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gADGi5Ni002408; Wed, 13 Nov 2002 08:44:10 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABH11995; Wed, 13 Nov 2002 08:41:39 -0800 (PST) Date: Wed, 13 Nov 2002 08:44:05 -0800 Subject: Re: [Sip] The fate of session timer? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: Jonathan Rosenberg , sip@ietf.org To: Jiri Kuthan From: Rohan Mahy In-Reply-To: <5.1.0.14.0.20021112155218.03f33008@iptel.org> Message-Id: <1F0FED3E-F727-11D6-B86C-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) 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 likewise consider the existing mechanism a good approach for firewall control. For all of the applications that I would use, I need intermediaries to be able to request a timer, and I want the ability to use the mechanism when only one side supports it. For that reason, I don't think we will get much less complicated. I think we should clarify the language and publish it. thanks, -rohan On Tuesday, November 12, 2002, at 07:05 AM, Jiri Kuthan wrote: > At 12:24 AM 11/12/2002, Jonathan Rosenberg wrote: > [...] >> I assert that session timer is really useful for one thing, which is >> to provide a means to cleanup old session state in UAs and proxies. > > I think a reasonable example of its use is firewall-control proxies > (unless they are considered a broken idea anyway). The SIP session > timer mechanism can be used to propagate SIP "keep-alive" messages > from UAs via proxy servers down to the firewalls (translated to some > MIDCOM keep-alives). In this way, the firewall-control proxies do not > have to be session-stateful to keep firewall pinholes alive. Keeping > them up is then UA responsibility. > > Simplification of the negotiation mechanisms seems like a good thing > to me. > > -Jiri > > > _______________________________________________ > 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 Nov 13 11:50:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07857 for ; Wed, 13 Nov 2002 11:50:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gADGqn711996 for sip-archive@odin.ietf.org; Wed, 13 Nov 2002 11:52: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 gADGm5v11784; Wed, 13 Nov 2002 11:48: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 gADGlFv11731 for ; Wed, 13 Nov 2002 11:47:15 -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 LAA07693 for ; Wed, 13 Nov 2002 11:44:36 -0500 (EST) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gADGkYIX011085; Wed, 13 Nov 2002 08:46:34 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABH12023; Wed, 13 Nov 2002 08:44:08 -0800 (PST) Date: Wed, 13 Nov 2002 08:46:34 -0800 Subject: Re: [Sip] The fate of session timer? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "Stevens, Del" , "'sip@ietf.org'" To: Christer Holmberg From: Rohan Mahy In-Reply-To: <3DD204A6.1F7EA21B@lmf.ericsson.se> Message-Id: <782D8C6F-F727-11D6-B86C-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) 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 Christer, if you don't like reINVITE, you should use an UPDATE instead. that is much better than an INFO! thanks, -rohan On Tuesday, November 12, 2002, at 11:52 PM, Christer Holmberg wrote: > > Hi, > > Some comments/thoughts from me about this. > > First, since the purpose of the session-timer (as Jonathan said) > currently only > is to clean up sessions, and NOT to recover state etc, I would like to > get > anything related to the offer/answer mechanism away from it. UAs may > need the > send offers for real stream related purposes, so it should not have to > do > buffering in case there is an ongoing session-timer offer/answer > transaction. > No, due to the long timer value for the session-timer this will > probably not > happen very often, but still. > > Second (and please don't flame me :), would it be a good idea to have > a look at > the INFO method again? The reason we didn't want it in the first place > was > because it shall not be used for chaning state. But, since we now > don't use the > session-timer for state recover that reason is maybe not valid anymore > (it is > NOT the INFO itself which changes the call state). > > I think one of the keys to the success of the session-timer is to make > it as > light as possible. No idea to include SDPs, and absolutely no idea to > use > re-INVITE, which also requires ACK. But, of course it's also a > question about if > anyone has any interest in this work. > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > > > > > > > > > "Stevens, Del" wrote: > >> All: >> >> For us the implementation of session timers has been a customer-driven >> requirement for our B2BUA. I agree that this draft was difficult to >> understand, but it satisfies several requirements for us: >> >> 1. A simple keep-a-live mechanism (as stated previously). This >> prevents >> tying up resources in our B2BUA if something happens in the network >> causing >> a SIP UA (or proxy) to "disappear" after the receipt of 200 OK. We >> have a >> configurable timer value, but the default of 30 minutes (per the >> draft) >> seems adequate. From a telco perspective, it is important from a >> billing >> perspective to have some record of a session during failure >> scenarios. Yes, >> this record is not exact, but telcos (or the like) can generally deal >> with >> inaccurate cdr records during failures better than no record at all. >> >> 2. If our B2BUA receives an INVITE from a SIP UA (or proxy) that >> support >> session timers, the negotiation takes place, allowing a symetrical >> keep-a-live mechanism. If the SIP UA doesn't support session timers, >> then >> our B2BUA can still use an asymetrical keep-a-live mechanism so our >> UA can >> ensure the "other" end is still there for each session. >> >> A nice off-shoot from our implementation of session timers occurs >> during >> fail-over situation. In this case, the newly active B2BUA can >> "re-establish" >> updated state information about each in progress session by issuing a >> re-INVITE for the session. The responses reinitializes the session >> timer >> lists on the "new" ACTIVE machine. >> >> Even though this is an old draft several sip phone manufacturers >> support >> session timers. Also, since the implementaton of session timers is not >> universal, we never issue "Require: timer", but let "Supported: >> timer" and >> "Session-Expires: n" to allow the negotiation to take place. >> >> If anyone is using digest authentication with session timers this >> creates >> the need for each re-INVITE to contain an Authorization header or >> risk being >> challenged (401/407). >> >> Yes, there is some messaging and processing overhead: 1) session timer >> negotiation + refreshes, and 2) tracking additional timers per >> session. But >> the safety net provided is a must for some customers. My vote is to >> keep >> this draft and update as necessary! >> >> Del Stevens mailto:del.stevens@icn.siemens.com >> Siemens Network Convergence LLC >> 7800 Congress Ave >> Boca Raton, FL 33487 >> >> -----Original Message----- >> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >> Sent: Monday, November 11, 2002 6:24 PM >> To: sip@ietf.org >> Subject: [Sip] The fate of session timer? >> >> Folks, >> >> As you may have noticed, I submitted an update to the session timer >> specification. This is an old, old spec that has been around for quite >> some time. It receives only minimal attention these days. The general >> comments on the list are generally 'too complex' and 'too hard to >> understand'. Some of that is wording, which I will continue to work. >> The >> bigger problem, I think, is that its not at all clear what problem >> this >> draft is REALLY solving. >> >> I assert that session timer is really useful for one thing, which is >> to >> provide a means to cleanup old session state in UAs and proxies. >> Normally, you'd set a timer (on the order of 5 hours or something) to >> discard any state thats still around. However, since a call may >> actually >> last that long, you want a way to reliably know when you can flush the >> state. >> >> Session timer is NOT useful for determining call durations for billing >> purposes. >> >> Session timer is NOT useful for quickly determining that a UA has >> failed, in order to recover. It operates too slowly for that. >> >> So, given this somewhat-marginal value, the complexity seems >> startingly >> high. I have begun to wonder whether that is the reason for the >> troubles >> this specification is having. So, I see a few options: >> >> 1. No one cares about this spec. Discard it entirely. >> >> 2. Continue as it is, fix up some wording, and submit. Probably no one >> implements it since it provides little value at high cost. >> >> 3. Change the scope. Eliminate or simplify negotiation of the timer by >> defining a suitably long minimum. Eliminate or simplify choosing who >> refreshes by requiring that the UAC support the timer. And so on. The >> result would be a much simpler spec. >> >> 4. others? >> >> Please provide comments, particularly if you are actively using this >> specification for some real problem. >> >> -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 >> _______________________________________________ >> 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 Wed Nov 13 12:05:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08644 for ; Wed, 13 Nov 2002 12:05:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gADH7C013591 for sip-archive@odin.ietf.org; Wed, 13 Nov 2002 12:07:12 -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 gADGuSv12386; Wed, 13 Nov 2002 11: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 gADGthv12322 for ; Wed, 13 Nov 2002 11:55:43 -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 LAA08123 for ; Wed, 13 Nov 2002 11:53:04 -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 gADGtOR23239; Wed, 13 Nov 2002 11:55:24 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] The fate of session timer? Date: Wed, 13 Nov 2002 10:55:31 -0600 Message-ID: <81877B9826317E448987499EB79AE70215A2CB@host-1.ttiworld.com> Thread-Topic: [Sip] The fate of session timer? Thread-Index: AcKJ2e4UC4KcT0AyTc+H/5IcJLdI/gBWvhPw From: "Kevin Summers" To: "Jonathan Rosenberg" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gADGthv12323 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 is a valuable and useful extension. That it can function asymmetrically (i.e., only one participant in a session needs to support session timer) is particularly useful WRT interoperability. My opinion is that we go with option (2). -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Monday, November 11, 2002 5:24 PM To: sip@ietf.org Subject: [Sip] The fate of session timer? Folks, As you may have noticed, I submitted an update to the session timer specification. This is an old, old spec that has been around for quite some time. It receives only minimal attention these days. The general comments on the list are generally 'too complex' and 'too hard to understand'. Some of that is wording, which I will continue to work. The bigger problem, I think, is that its not at all clear what problem this draft is REALLY solving. I assert that session timer is really useful for one thing, which is to provide a means to cleanup old session state in UAs and proxies. Normally, you'd set a timer (on the order of 5 hours or something) to discard any state thats still around. However, since a call may actually last that long, you want a way to reliably know when you can flush the state. Session timer is NOT useful for determining call durations for billing purposes. Session timer is NOT useful for quickly determining that a UA has failed, in order to recover. It operates too slowly for that. So, given this somewhat-marginal value, the complexity seems startingly high. I have begun to wonder whether that is the reason for the troubles this specification is having. So, I see a few options: 1. No one cares about this spec. Discard it entirely. 2. Continue as it is, fix up some wording, and submit. Probably no one implements it since it provides little value at high cost. 3. Change the scope. Eliminate or simplify negotiation of the timer by defining a suitably long minimum. Eliminate or simplify choosing who refreshes by requiring that the UAC support the timer. And so on. The result would be a much simpler spec. 4. others? Please provide comments, particularly if you are actively using this specification for some real problem. -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 _______________________________________________ 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 Nov 13 12:14:30 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09011 for ; Wed, 13 Nov 2002 12:14:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gADHGcm14472 for sip-archive@odin.ietf.org; Wed, 13 Nov 2002 12:16: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 gADH0Dv12708; Wed, 13 Nov 2002 12:00: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 gADGxUv12612 for ; Wed, 13 Nov 2002 11:59:30 -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 LAA08299 for ; Wed, 13 Nov 2002 11:56:51 -0500 (EST) Received: from sponge.cisco.com (IDENT:mirapoint@sponge.cisco.com [64.101.128.87]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gADGx8aG002275; Wed, 13 Nov 2002 08:59:08 -0800 (PST) Received: from ARUNVENKW2Kl (arunvenk-w2kl-1.cisco.com [64.101.164.105]) by sponge.cisco.com (Mirapoint) with SMTP id ABT00054; Wed, 13 Nov 2002 10:59:18 -0600 (CST) From: "Arunachalam Venkatraman" To: "Jonathan Rosenberg" Cc: Subject: RE: [Sip] The fate of session timer? Date: Wed, 13 Nov 2002 10:59:17 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <3DD2470B.9080809@dynamicsoft.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 Jonathan Whenever we overload one request to do disparate functions, we have a source of confusion, race conditions etc. For example, although the likelihood of such an intersection is relatively small, it is possible that an offer/answer exchange is required at the time a session timer refresh is in progress using UPDATE (or INVITE). This required extra logic in the implementation to sequence these and is an overhead for a remote corner case. Further, the rules about crossing UPDATEs/INVITEs resulting in 491 have to be handled even though it would seem to make perfect sense to be able to accept an UPDATE without SDP (sent for session refresh) while an UPDATE with SDP has been sent out by the UA. It seems silly to have to re-attempt a session refresh when the previous UPDATE/491 has verified the existence of the session at both ends. Having a separate request for session timer eliminates unnecessary overloading of the existing requests. But this seems like a big ado over a trivial issue. So, the idea of proxies subscribing to a UserAgent to detect session state is a good alternative. User agents can always verify session existence using any request they choose that makes sense in the context of the dialog. Since the session refreshes are supposed to be infrequent, having refreshes cross each other is not very likely if the durations are randomly chosen. Further, it hardly matters that the requests crossed since any (non-BYE/ non-481/408) request/response exchange verifies the session liveness, anyway, achieving the purpose. Regards Venkat -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Jonathan Rosenberg Sent: Wednesday, November 13, 2002 6:35 AM To: Christer Holmberg Cc: Stevens, Del; 'sip@ietf.org' Subject: Re: [Sip] The fate of session timer? Christer Holmberg wrote: > Second (and please don't flame me :), would it be a good idea to have a look at > the INFO method again? The reason we didn't want it in the first place was > because it shall not be used for chaning state. But, since we now don't use the > session-timer for state recover that reason is maybe not valid anymore (it is > NOT the INFO itself which changes the call state). The draft already specifies UPDATE. The UPDATE can be sent without a session description. Please explain what benefits there are to specifying the usage of INFO in addition. -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 _______________________________________________ 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 Nov 13 12:15:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09050 for ; Wed, 13 Nov 2002 12:15:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gADHHGc14574 for sip-archive@odin.ietf.org; Wed, 13 Nov 2002 12:17: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 gADH0Hv12729; Wed, 13 Nov 2002 12:00: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 gADGxZv12616 for ; Wed, 13 Nov 2002 11:59:35 -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 LAA08298 for ; Wed, 13 Nov 2002 11:56:51 -0500 (EST) Received: from sponge.cisco.com (IDENT:mirapoint@sponge.cisco.com [64.101.128.87]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gADGx8aE002275; Wed, 13 Nov 2002 08:59:08 -0800 (PST) Received: from ARUNVENKW2Kl (arunvenk-w2kl-1.cisco.com [64.101.164.105]) by sponge.cisco.com (Mirapoint) with SMTP id ABT00052; Wed, 13 Nov 2002 10:59:17 -0600 (CST) From: "Arunachalam Venkatraman" To: "Jonathan Rosenberg" Cc: Date: Wed, 13 Nov 2002 10:59:16 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Subject: [Sip] RE: Require header in responses (was- The fate of session timer?) 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 Jonathan I believe your statement below about the rule for adding a Require header into a response should be documented in section 20.32 of the RFC3261. Regards Venkat -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Jonathan Rosenberg Sent: Tuesday, November 12, 2002 7:24 AM To: hisham.khartabil@nokia.com Cc: chandan.rajah@wipro.com; sip@ietf.org Subject: Re: [Sip] The fate of session timer? hisham.khartabil@nokia.com wrote: > As I see it, what we are specifying here is a keepalive mechanism for > sessions. The value of the keepalive can have a default. > > UACs don't have to send any new header in an initial INVITE, but > proxies and UASs requiring session keepalive can inform the UAC of > such requirement by including a (proxy-)Require-header in the > response?? The default values can be used. No. Require/Proxy-REquire in a response is only allowed if the request contained a Supported header in the INVITE. > > In this way, each entity can take of cleaning up its own stale > sessions. No need for UAC to tell every other entity when it plans on > ending the session, it can just send a BYE. > > Btw, do we have requirements for this, or should we write one? This specification predates our requirements for requirements. So, no, there are none. I don't think we need to do a formal requirements process here. However, I think it is useful to have an email discussion of the basic requirements that underlie the current draft, to see which ones we can rule out, as it seems people seem amenable to considering a simplification: REQ 1: There shall be a way for a proxy or UA to request that a session timer be executed for a dialog. REQ 2: There shall be a way for the session timer to take place so long as EITHER the UAC or UAS supports it. REQ 3: There shall be a way for each element - proxy,UAC, UAS, to specify their desired value for the session timer. REQ 4: There shall be a way for each element to specify their minimum allowed value for the session tiemr. REQ 5: The final session timer shall be: MAX(MIN(desired timers),MAX(min timers)) REQ 6: It shall be possible to renegotiate the use of session timer, and its value, at any time during a dialog. REQ 7: Session timer shall be immune to DoS attacks introduced by a rogue UAC, UAS, or proxy. REQ 8: It shall be possible for the UAC in the initial INVITE to suggest itself for performing the refreshes. I think that captures most of it. Some of these requirements, like 6, fall out of general SIP properties, and we would be hard pressed to eliminate them. Its also possible to get simplification through redesign while still meeting the requirements. For example, it occurs to me that we could potentially send the refreshes directly from the client to the "interested" proxies. This is more overhead for the client if there is more than one interested proxy, but means that proxies which don't care about session timer don't suffer from additional message volume, which is a drawback of the current solution. By doing that, all of the negotiation becomes two-way, between a UA and a proxy, rather than N-way, and is thus much simplified. Such a solution would require a proxy requesting session timer to have a globally routable URI. Yet another solution is to define a specific "heartbeat" media stream type, which periodically genreates a keepalive. In that sense, its similar to RTCP, but not RTP specific. AN intermediary can get itself onto this heartbeat stream by being a b2bua that mucks with SDP, or using a mechanism like the session policy which I have formerly proposed: http://www.jdrosen.net/papers/draft-rosenberg-sipping-session-policy-00.txt There may be other general solutions to this too. -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 _______________________________________________ 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 Nov 13 14:48:52 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14858 for ; Wed, 13 Nov 2002 14:48:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gADJoxK25566 for sip-archive@odin.ietf.org; Wed, 13 Nov 2002 14:50: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 gADJo7v25491; Wed, 13 Nov 2002 14:50: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 gADJjbv25234 for ; Wed, 13 Nov 2002 14:45:37 -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 OAA14624 for ; Wed, 13 Nov 2002 14:42:58 -0500 (EST) Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.11.6) id gADJjV751706; Wed, 13 Nov 2002 14:45:31 -0500 (EST) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] The fate of session timer? Date: Wed, 13 Nov 2002 14:45:54 -0500 Message-ID: <002d01c28b4d$47edbaa0$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) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <782D8C6F-F727-11D6-B86C-0003938AF740@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 > if you don't like reINVITE, you should > use an UPDATE instead. The UPDATE method is basically going to become the mechanism to "update" most any header which is valid within an INVITE. If this is not the intention of the header, new methods like RETARGET, AUDIT, IDENTITY, SUPPORTED, and ALLOW should be defined. _______________________________________________ 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 Nov 13 20:04:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23350 for ; Wed, 13 Nov 2002 20:04:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAE179f12033 for sip-archive@odin.ietf.org; Wed, 13 Nov 2002 20:07: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 gAE12hv11622; Wed, 13 Nov 2002 20:02: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 gAE10uv11532 for ; Wed, 13 Nov 2002 20:00:56 -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 TAA23254 for ; Wed, 13 Nov 2002 19:58:12 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gAE10k522506 for ; Wed, 13 Nov 2002 20:00:47 -0500 (EST) Received: by en0060D057.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Nov 2002 01:00:45 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB006B2778E@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Jonathan Rosenberg , hisham.khartabil@nokia.com Cc: chandan.rajah@wipro.com, sip@ietf.org Subject: RE: [Sip] The fate of session timer? Date: Thu, 14 Nov 2002 01:00:44 -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: , Actually, if we really want to proceed with session timer, then I think putting a requirements draft through SIPPING is an excellent idea. We have had too many discussions in the past of what are we trying to achieve, so I think obtaining consensus as to whether there are requirements and what those requirements are is an excellent idea. And by the way, 1) I see no requirements below on the treatment in response to non-supporting entities, i.e. the compatibility requirements. 2) Some of these requirements seem to specify the implementation - who says we need a timer in the first place - the base requirement is that we do a cleanup within certain time constraints, yes, but stating "timer" implies we are always going to do this after a determined period of time rather than as and when we feel like it. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 12 November 2002 13:24 > To: hisham.khartabil@nokia.com > Cc: chandan.rajah@wipro.com; sip@ietf.org > Subject: Re: [Sip] The fate of session timer? > > > > This specification predates our requirements for > requirements. So, no, > there are none. I don't think we need to do a formal requirements > process here. However, I think it is useful to have an email > discussion > of the basic requirements that underlie the current draft, to > see which > ones we can rule out, as it seems people seem amenable to > considering a > simplification: > > REQ 1: There shall be a way for a proxy or UA to request that > a session > timer be executed for a dialog. > > REQ 2: There shall be a way for the session timer to take > place so long > as EITHER the UAC or UAS supports it. > > REQ 3: There shall be a way for each element - proxy,UAC, UAS, to > specify their desired value for the session timer. > > REQ 4: There shall be a way for each element to specify their minimum > allowed value for the session tiemr. > > REQ 5: The final session timer shall be: > > MAX(MIN(desired timers),MAX(min timers)) > > REQ 6: It shall be possible to renegotiate the use of session > timer, and > its value, at any time during a dialog. > > REQ 7: Session timer shall be immune to DoS attacks introduced by a > rogue UAC, UAS, or proxy. > > REQ 8: It shall be possible for the UAC in the initial INVITE > to suggest > itself for performing the refreshes. > > > I think that captures most of it. Some of these requirements, like 6, > fall out of general SIP properties, and we would be hard pressed to > eliminate them. > > Its also possible to get simplification through redesign while still > meeting the requirements. For example, it occurs to me that we could > potentially send the refreshes directly from the client to the > "interested" proxies. This is more overhead for the client if > there is > more than one interested proxy, but means that proxies which > don't care > about session timer don't suffer from additional message > volume, which > is a drawback of the current solution. > > By doing that, all of the negotiation becomes two-way, > between a UA and > a proxy, rather than N-way, and is thus much simplified. > > Such a solution would require a proxy requesting session > timer to have a > globally routable URI. > > > Yet another solution is to define a specific "heartbeat" media stream > type, which periodically genreates a keepalive. In that sense, its > similar to RTCP, but not RTP specific. AN intermediary can get itself > onto this heartbeat stream by being a b2bua that mucks with SDP, or > using a mechanism like the session policy which I have > formerly proposed: > http://www.jdrosen.net/papers/draft-rosenberg-sipping-session- policy-00.txt There may be other general solutions to this too. _______________________________________________ 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 Nov 14 03:13:10 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12965 for ; Thu, 14 Nov 2002 03:13:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAE8FOl11292 for sip-archive@odin.ietf.org; Thu, 14 Nov 2002 03:15: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 gAE8BHv11085; Thu, 14 Nov 2002 03:11: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 gAE86qv10193 for ; Thu, 14 Nov 2002 03:06:52 -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 DAA12719 for ; Thu, 14 Nov 2002 03:04:07 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAE86dQ1028299; Thu, 14 Nov 2002 09:06:40 +0100 (MET) Received: from lmf.ericsson.se (chzuwa01m27.eu.ericsson.se [164.48.166.27]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id gAE86aCG010751; Thu, 14 Nov 2002 10:06:37 +0200 (EET) Message-ID: <3DD359A5.CF2B76A6@lmf.ericsson.se> Date: Thu, 14 Nov 2002 10:07:01 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rohan Mahy CC: "Stevens, Del" , "'sip@ietf.org'" Subject: Re: [Sip] The fate of session timer? References: <782D8C6F-F727-11D6-B86C-0003938AF740@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 Hi, > if you don't like reINVITE, you should use an UPDATE instead. that is > much better than an INFO! I have nothing against using UPDATE. My question was only if the original reason not to use INFO isn't valid anymore :) Regards, Christer Holmberg Ericsson Finland > > > thanks, > -rohan > > On Tuesday, November 12, 2002, at 11:52 PM, Christer Holmberg wrote: > > > > > Hi, > > > > Some comments/thoughts from me about this. > > > > First, since the purpose of the session-timer (as Jonathan said) > > currently only > > is to clean up sessions, and NOT to recover state etc, I would like to > > get > > anything related to the offer/answer mechanism away from it. UAs may > > need the > > send offers for real stream related purposes, so it should not have to > > do > > buffering in case there is an ongoing session-timer offer/answer > > transaction. > > No, due to the long timer value for the session-timer this will > > probably not > > happen very often, but still. > > > > Second (and please don't flame me :), would it be a good idea to have > > a look at > > the INFO method again? The reason we didn't want it in the first place > > was > > because it shall not be used for chaning state. But, since we now > > don't use the > > session-timer for state recover that reason is maybe not valid anymore > > (it is > > NOT the INFO itself which changes the call state). > > > > I think one of the keys to the success of the session-timer is to make > > it as > > light as possible. No idea to include SDPs, and absolutely no idea to > > use > > re-INVITE, which also requires ACK. But, of course it's also a > > question about if > > anyone has any interest in this work. > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > "Stevens, Del" wrote: > > > >> All: > >> > >> For us the implementation of session timers has been a customer-driven > >> requirement for our B2BUA. I agree that this draft was difficult to > >> understand, but it satisfies several requirements for us: > >> > >> 1. A simple keep-a-live mechanism (as stated previously). This > >> prevents > >> tying up resources in our B2BUA if something happens in the network > >> causing > >> a SIP UA (or proxy) to "disappear" after the receipt of 200 OK. We > >> have a > >> configurable timer value, but the default of 30 minutes (per the > >> draft) > >> seems adequate. From a telco perspective, it is important from a > >> billing > >> perspective to have some record of a session during failure > >> scenarios. Yes, > >> this record is not exact, but telcos (or the like) can generally deal > >> with > >> inaccurate cdr records during failures better than no record at all. > >> > >> 2. If our B2BUA receives an INVITE from a SIP UA (or proxy) that > >> support > >> session timers, the negotiation takes place, allowing a symetrical > >> keep-a-live mechanism. If the SIP UA doesn't support session timers, > >> then > >> our B2BUA can still use an asymetrical keep-a-live mechanism so our > >> UA can > >> ensure the "other" end is still there for each session. > >> > >> A nice off-shoot from our implementation of session timers occurs > >> during > >> fail-over situation. In this case, the newly active B2BUA can > >> "re-establish" > >> updated state information about each in progress session by issuing a > >> re-INVITE for the session. The responses reinitializes the session > >> timer > >> lists on the "new" ACTIVE machine. > >> > >> Even though this is an old draft several sip phone manufacturers > >> support > >> session timers. Also, since the implementaton of session timers is not > >> universal, we never issue "Require: timer", but let "Supported: > >> timer" and > >> "Session-Expires: n" to allow the negotiation to take place. > >> > >> If anyone is using digest authentication with session timers this > >> creates > >> the need for each re-INVITE to contain an Authorization header or > >> risk being > >> challenged (401/407). > >> > >> Yes, there is some messaging and processing overhead: 1) session timer > >> negotiation + refreshes, and 2) tracking additional timers per > >> session. But > >> the safety net provided is a must for some customers. My vote is to > >> keep > >> this draft and update as necessary! > >> > >> Del Stevens mailto:del.stevens@icn.siemens.com > >> Siemens Network Convergence LLC > >> 7800 Congress Ave > >> Boca Raton, FL 33487 > >> > >> -----Original Message----- > >> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > >> Sent: Monday, November 11, 2002 6:24 PM > >> To: sip@ietf.org > >> Subject: [Sip] The fate of session timer? > >> > >> Folks, > >> > >> As you may have noticed, I submitted an update to the session timer > >> specification. This is an old, old spec that has been around for quite > >> some time. It receives only minimal attention these days. The general > >> comments on the list are generally 'too complex' and 'too hard to > >> understand'. Some of that is wording, which I will continue to work. > >> The > >> bigger problem, I think, is that its not at all clear what problem > >> this > >> draft is REALLY solving. > >> > >> I assert that session timer is really useful for one thing, which is > >> to > >> provide a means to cleanup old session state in UAs and proxies. > >> Normally, you'd set a timer (on the order of 5 hours or something) to > >> discard any state thats still around. However, since a call may > >> actually > >> last that long, you want a way to reliably know when you can flush the > >> state. > >> > >> Session timer is NOT useful for determining call durations for billing > >> purposes. > >> > >> Session timer is NOT useful for quickly determining that a UA has > >> failed, in order to recover. It operates too slowly for that. > >> > >> So, given this somewhat-marginal value, the complexity seems > >> startingly > >> high. I have begun to wonder whether that is the reason for the > >> troubles > >> this specification is having. So, I see a few options: > >> > >> 1. No one cares about this spec. Discard it entirely. > >> > >> 2. Continue as it is, fix up some wording, and submit. Probably no one > >> implements it since it provides little value at high cost. > >> > >> 3. Change the scope. Eliminate or simplify negotiation of the timer by > >> defining a suitably long minimum. Eliminate or simplify choosing who > >> refreshes by requiring that the UAC support the timer. And so on. The > >> result would be a much simpler spec. > >> > >> 4. others? > >> > >> Please provide comments, particularly if you are actively using this > >> specification for some real problem. > >> > >> -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 > >> _______________________________________________ > >> 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 Nov 14 03:13:42 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13032 for ; Thu, 14 Nov 2002 03:13:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAE8Fva11324 for sip-archive@odin.ietf.org; Thu, 14 Nov 2002 03:15: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 gAE8EOv11264; Thu, 14 Nov 2002 03:14: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 gAE8ANv11040 for ; Thu, 14 Nov 2002 03:10:23 -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 DAA12831 for ; Thu, 14 Nov 2002 03:07:37 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAE8A9KV000184; Thu, 14 Nov 2002 09:10:09 +0100 (MET) Received: from lmf.ericsson.se (chzuwa01m27.eu.ericsson.se [164.48.166.27]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id gAE8A7CG010971; Thu, 14 Nov 2002 10:10:07 +0200 (EET) Message-ID: <3DD35A78.5DF3C99C@lmf.ericsson.se> Date: Thu, 14 Nov 2002 10:10:32 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: jdrosen@dynamicsoft.com, chandan.rajah@wipro.com, sip@ietf.org Subject: Re: [Sip] The fate of session timer? References: <2038BCC78B1AD641891A0D1AE133DBB7FE6FB7@esebe019.ntc.nokia.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 Hi, > > Well, certainly one UA will care that the other UA has > > crashed. Session > > timer allows a UAC or UAS to get refreshes in order to make that > > determination. > > This requires both ends to have support for session timer. Also, is it a safe assumption to make that if a UA doesn't send a session-timer refresh, then it has crashed? > > In you earlier email, you pointed out that the sole purpose of session-timer is to clean up old sessions. > > "I assert that session timer is really useful for one thing, which is to > provide a means to cleanup old session state in UAs and proxies." > > Why does my UA care about cleaning up old session at the remote side? or Is the purpose of this I-D already extended? I don't think your UA is supposed to clean up sessions on the remote side. The remote side will clean up its own sessions if it doesn't get a timer refresh from you, right? 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 Thu Nov 14 03:16:49 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13141 for ; Thu, 14 Nov 2002 03:16:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAE8J3611479 for sip-archive@odin.ietf.org; Thu, 14 Nov 2002 03:19: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 gAE894v10995; Thu, 14 Nov 2002 03:09: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 gAE86kv10184 for ; Thu, 14 Nov 2002 03:06:46 -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 DAA12716 for ; Thu, 14 Nov 2002 03:04:01 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAE86UKV029073; Thu, 14 Nov 2002 09:06:30 +0100 (MET) Received: from lmf.ericsson.se (chzuwa01m27.eu.ericsson.se [164.48.166.27]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id gAE86RCG010740; Thu, 14 Nov 2002 10:06:28 +0200 (EET) Message-ID: <3DD3599C.A7E5C9FD@lmf.ericsson.se> Date: Thu, 14 Nov 2002 10:06:53 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Arunachalam Venkatraman CC: Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] The fate of session timer? 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 Hi, > Jonathan > Whenever we overload one request to do disparate functions, we have a source > of confusion, race conditions etc. > For example, although the likelihood of such an intersection is relatively > small, it is possible that an offer/answer exchange is required at the time > a session timer refresh is in progress using UPDATE (or INVITE). I had the same concern, but obviously you don't have that problem if you use UPDATE -without- SDP for the timer refresh. Regards, Christer Holmberg Ericsson Finland > This > required extra logic in the implementation to sequence these and is an > overhead for a remote corner case. Further, the rules about crossing > UPDATEs/INVITEs resulting in 491 have to be handled even though it would > seem to make perfect sense to be able to accept an UPDATE without SDP (sent > for session refresh) while an UPDATE with SDP has been sent out by the UA. > It seems silly to have to re-attempt a session refresh when the previous > UPDATE/491 has verified the existence of the session at both ends. > > Having a separate request for session timer eliminates unnecessary > overloading of the existing requests. But this seems like a big ado over a > trivial issue. > > So, the idea of proxies subscribing to a UserAgent to detect session state > is a good alternative. User agents can always verify session existence using > any request they choose that makes sense in the context of the dialog. Since > the session refreshes are supposed to be infrequent, having refreshes cross > each other is not very likely if the durations are randomly chosen. Further, > it hardly matters that the requests crossed since any (non-BYE/ non-481/408) > request/response exchange verifies the session liveness, anyway, achieving > the purpose. > > Regards > Venkat > > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Jonathan > Rosenberg > Sent: Wednesday, November 13, 2002 6:35 AM > To: Christer Holmberg > Cc: Stevens, Del; 'sip@ietf.org' > Subject: Re: [Sip] The fate of session timer? > > Christer Holmberg wrote: > > > Second (and please don't flame me :), would it be a good idea to have a > look at > > the INFO method again? The reason we didn't want it in the first place was > > because it shall not be used for chaning state. But, since we now don't > use the > > session-timer for state recover that reason is maybe not valid anymore (it > is > > NOT the INFO itself which changes the call state). > > The draft already specifies UPDATE. The UPDATE can be sent without a > session description. Please explain what benefits there are to > specifying the usage of INFO in addition. > > -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 > > _______________________________________________ > 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 Nov 14 04:55:17 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14423 for ; Thu, 14 Nov 2002 04:55:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAE9vWV16661 for sip-archive@odin.ietf.org; Thu, 14 Nov 2002 04:57: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 gAE9t2v16614; Thu, 14 Nov 2002 04: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 gAE9rDv16552 for ; Thu, 14 Nov 2002 04:53:13 -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 EAA14369 for ; Thu, 14 Nov 2002 04:50:26 -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 gAE9qTO22597 for ; Thu, 14 Nov 2002 11:52:29 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 14 Nov 2002 11:52:57 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 14 Nov 2002 11:52:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] The fate of session timer? Date: Thu, 14 Nov 2002 11:52:56 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE6FBC@esebe019.ntc.nokia.com> Thread-Topic: [Sip] The fate of session timer? Thread-Index: AcKLtlhL/8uLaf81QOK4h6yLzgT/CwADKkfw To: Cc: , , X-OriginalArrivalTime: 14 Nov 2002 09:52:57.0712 (UTC) FILETIME=[9C4F4700:01C28BC3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAE9rDv16553 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 Christer, > -----Original Message----- > From: ext Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Thursday, November 14, 2002 10:11 AM > To: Khartabil Hisham (NMP/Helsinki) > Cc: jdrosen@dynamicsoft.com; chandan.rajah@wipro.com; sip@ietf.org > Subject: Re: [Sip] The fate of session timer? > > > > Hi, > > > > Well, certainly one UA will care that the other UA has > > > crashed. Session > > > timer allows a UAC or UAS to get refreshes in order to make that > > > determination. > > > > This requires both ends to have support for session timer. > Also, is it a safe assumption to make that if a UA doesn't > send a session-timer refresh, then it has crashed? > > > > In you earlier email, you pointed out that the sole purpose > of session-timer is to clean up old sessions. > > > > "I assert that session timer is really useful for one > thing, which is to > > provide a means to cleanup old session state in UAs and proxies." > > > > Why does my UA care about cleaning up old session at the > remote side? or Is the purpose of this I-D already extended? > > I don't think your UA is supposed to clean up sessions on the > remote side. The remote side will clean up its own sessions > if it doesn't get a timer refresh from you, right? Right, but what I'm saying is why does my UA have need to dictate to the remote UA when it can or cannot clean OLD sessions? I think its a local matter. /Hisham > > 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 Thu Nov 14 05:04:39 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14704 for ; Thu, 14 Nov 2002 05:04:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAEA6hc17071 for sip-archive@odin.ietf.org; Thu, 14 Nov 2002 05:06: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 gAEA4Hv16976; Thu, 14 Nov 2002 05:04: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 gAEA3rv16908 for ; Thu, 14 Nov 2002 05:03:53 -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 FAA14584 for ; Thu, 14 Nov 2002 05:01:18 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAEA3pKV013296; Thu, 14 Nov 2002 11:03:51 +0100 (MET) Received: from lmf.ericsson.se (chzuwa01m02.eu.ericsson.se [164.48.166.2]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id gAEA3mCG017670; Thu, 14 Nov 2002 12:03:49 +0200 (EET) Message-ID: <3DD3751E.81649D97@lmf.ericsson.se> Date: Thu, 14 Nov 2002 12:04:14 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: jdrosen@dynamicsoft.com, chandan.rajah@wipro.com, sip@ietf.org Subject: Re: [Sip] The fate of session timer? References: <2038BCC78B1AD641891A0D1AE133DBB7FE6FBC@esebe019.ntc.nokia.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 Hi, > >>> Well, certainly one UA will care that the other UA has > > > > crashed. Session > > > > timer allows a UAC or UAS to get refreshes in order to make that > > > > determination. > > > > > > This requires both ends to have support for session timer. > > Also, is it a safe assumption to make that if a UA doesn't > > send a session-timer refresh, then it has crashed? > > > > > > In you earlier email, you pointed out that the sole purpose > > of session-timer is to clean up old sessions. > > > > > > "I assert that session timer is really useful for one > > thing, which is to > > > provide a means to cleanup old session state in UAs and proxies." > > > > > > Why does my UA care about cleaning up old session at the > > remote side? or Is the purpose of this I-D already extended? > > > > I don't think your UA is supposed to clean up sessions on the > > remote side. The remote side will clean up its own sessions > > if it doesn't get a timer refresh from you, right? > > Right, but what I'm saying is why does my UA have need to dictate to the remote UA when it can or cannot clean OLD sessions? I think its a local matter. In that case you don't use the session-timer in the first place. The whole idea of the mechanism is that the nodes can negotiate to send periodical refreshes. Please also remember that this mechanism will allow your UA to find out if the remote party has LOST state of the call. Regards, Christer Holmberg Ericsson Finland > > > /Hisham > > > > > 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 Thu Nov 14 06:05:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15443 for ; Thu, 14 Nov 2002 06:05:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAEB7Qv20699 for sip-archive@odin.ietf.org; Thu, 14 Nov 2002 06:07: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 gAEB4vv20058; Thu, 14 Nov 2002 06:04: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 gAEB1av19954 for ; Thu, 14 Nov 2002 06:01:36 -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 FAA15348 for ; Thu, 14 Nov 2002 05:59:00 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAEB2EB29065 for ; Thu, 14 Nov 2002 13:02:14 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 14 Nov 2002 13:01:28 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 14 Nov 2002 13:01:27 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 14 Nov 2002 13:01:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] The fate of session timer? Date: Thu, 14 Nov 2002 13:01:20 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE6FBD@esebe019.ntc.nokia.com> Thread-Topic: [Sip] The fate of session timer? Thread-Index: AcKLxSiISj8NdqyZScyddhlclZJtQgAB7CRg To: Cc: , , X-OriginalArrivalTime: 14 Nov 2002 11:01:21.0427 (UTC) FILETIME=[2A507E30:01C28BCD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAEB1av19955 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 > -----Original Message----- > From: ext Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Thursday, November 14, 2002 12:04 PM > To: Khartabil Hisham (NMP/Helsinki) > Cc: jdrosen@dynamicsoft.com; chandan.rajah@wipro.com; sip@ietf.org > Subject: Re: [Sip] The fate of session timer? > > Please also remember that this mechanism will allow your UA > to find out if the remote party has LOST state of the call. What was the purpose of session-timer again? We need to define a scope and then abide by it. /Hisham > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > > > > > > /Hisham > > > > > > > > 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 Thu Nov 14 06:38:56 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15924 for ; Thu, 14 Nov 2002 06:38:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAEBf1u22353 for sip-archive@odin.ietf.org; Thu, 14 Nov 2002 06:41: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 gAEBciv22248; Thu, 14 Nov 2002 06:38: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 gAEBZEv21588 for ; Thu, 14 Nov 2002 06:35:14 -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 GAA15858 for ; Thu, 14 Nov 2002 06:32:34 -0500 (EST) From: ssubir@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 gAEBFPi18788; Thu, 14 Nov 2002 16:45:27 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256C71.003F4EC3 ; Thu, 14 Nov 2002 17:01:29 +0530 X-Lotus-FromDomain: HSSBLR To: Christer Holmberg cc: hisham.khartabil@nokia.com, jdrosen@dynamicsoft.com, chandan.rajah@wipro.com, sip@ietf.org Message-ID: <65256C71.003F4DDF.00@sampark.hss.hns.com> Date: Thu, 14 Nov 2002 17:01:18 +0530 Subject: Re: [Sip] The fate of session timer? 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: , >Please also remember that this mechanism will allow your UA to >find out if the remote party has LOST state of the call. UA would rather depend on the associated application than signaling to decide LOST state. Thanks, Subir _______________________________________________ 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 Nov 14 09:16:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19736 for ; Thu, 14 Nov 2002 09:16:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAEEIDH31464 for sip-archive@odin.ietf.org; Thu, 14 Nov 2002 09:18: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 gAEEFav31366; Thu, 14 Nov 2002 09:15: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 gAEEBDv31220 for ; Thu, 14 Nov 2002 09:11:13 -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 JAA19318 for ; Thu, 14 Nov 2002 09:08:36 -0500 (EST) Received: from sponge.cisco.com (IDENT:mirapoint@sponge.cisco.com [64.101.128.87]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAEEAvNf016480; Thu, 14 Nov 2002 06:10:57 -0800 (PST) Received: from ARUNVENKW2K1 (rtp-vpn1-966.cisco.com [10.82.227.198]) by sponge.cisco.com (Mirapoint) with SMTP id ABT12093; Thu, 14 Nov 2002 08:10:57 -0600 (CST) From: "Arunachalam Venkatraman" To: "Christer Holmberg" Cc: "Jonathan Rosenberg" , Subject: RE: [Sip] The fate of session timer? Date: Thu, 14 Nov 2002 08:18:40 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3DD3599C.A7E5C9FD@lmf.ericsson.se> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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 Christer That is not true. Another UPDATE may neither be received nor sent (491/500 with Retry after rules) when an UPDATE has been sent/received. Cheers, Venkat -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] Sent: Thursday, November 14, 2002 2:07 AM To: Arunachalam Venkatraman Cc: Jonathan Rosenberg; sip@ietf.org Subject: Re: [Sip] The fate of session timer? Hi, > Jonathan > Whenever we overload one request to do disparate functions, we have a source > of confusion, race conditions etc. > For example, although the likelihood of such an intersection is relatively > small, it is possible that an offer/answer exchange is required at the time > a session timer refresh is in progress using UPDATE (or INVITE). I had the same concern, but obviously you don't have that problem if you use UPDATE -without- SDP for the timer refresh. Regards, Christer Holmberg Ericsson Finland > This > required extra logic in the implementation to sequence these and is an > overhead for a remote corner case. Further, the rules about crossing > UPDATEs/INVITEs resulting in 491 have to be handled even though it would > seem to make perfect sense to be able to accept an UPDATE without SDP (sent > for session refresh) while an UPDATE with SDP has been sent out by the UA. > It seems silly to have to re-attempt a session refresh when the previous > UPDATE/491 has verified the existence of the session at both ends. > > Having a separate request for session timer eliminates unnecessary > overloading of the existing requests. But this seems like a big ado over a > trivial issue. > > So, the idea of proxies subscribing to a UserAgent to detect session state > is a good alternative. User agents can always verify session existence using > any request they choose that makes sense in the context of the dialog. Since > the session refreshes are supposed to be infrequent, having refreshes cross > each other is not very likely if the durations are randomly chosen. Further, > it hardly matters that the requests crossed since any (non-BYE/ non-481/408) > request/response exchange verifies the session liveness, anyway, achieving > the purpose. > > Regards > Venkat > > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Jonathan > Rosenberg > Sent: Wednesday, November 13, 2002 6:35 AM > To: Christer Holmberg > Cc: Stevens, Del; 'sip@ietf.org' > Subject: Re: [Sip] The fate of session timer? > > Christer Holmberg wrote: > > > Second (and please don't flame me :), would it be a good idea to have a > look at > > the INFO method again? The reason we didn't want it in the first place was > > because it shall not be used for chaning state. But, since we now don't > use the > > session-timer for state recover that reason is maybe not valid anymore (it > is > > NOT the INFO itself which changes the call state). > > The draft already specifies UPDATE. The UPDATE can be sent without a > session description. Please explain what benefits there are to > specifying the usage of INFO in addition. > > -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 > > _______________________________________________ > 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 Nov 14 10:02:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21091 for ; Thu, 14 Nov 2002 10:02:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAEF4B701689 for sip-archive@odin.ietf.org; Thu, 14 Nov 2002 10:04: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 gAEF1ev01607; Thu, 14 Nov 2002 10:01:40 -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 gAEEsMv01314 for ; Thu, 14 Nov 2002 09:54:22 -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 JAA20829 for ; Thu, 14 Nov 2002 09:51:45 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAEEsHQ1005037; Thu, 14 Nov 2002 15:54:18 +0100 (MET) Received: from lmf.ericsson.se (chzuwa01m03.eu.ericsson.se [164.48.166.3]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id gAEEsFCG004950; Thu, 14 Nov 2002 16:54:15 +0200 (EET) Message-ID: <3DD3B930.E6230AC3@lmf.ericsson.se> Date: Thu, 14 Nov 2002 16:54:40 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Arunachalam Venkatraman CC: Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] The fate of session timer? 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 Hi, > Christer > That is not true. Another UPDATE may neither be received nor sent (491/500 > with Retry after rules) when an UPDATE has been sent/received. If that is the case I don't want to use UPDATE :) To my understanding the current functionality of the session-timer has nothing to do with the offer/answer mechanism, so I see no reason why it should "block" other possible offer/answer transactions. Regards, Christer Holmberg Ericsson Finland > > Cheers, > Venkat > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Thursday, November 14, 2002 2:07 AM > To: Arunachalam Venkatraman > Cc: Jonathan Rosenberg; sip@ietf.org > Subject: Re: [Sip] The fate of session timer? > > Hi, > > > Jonathan > > Whenever we overload one request to do disparate functions, we have a > source > > of confusion, race conditions etc. > > For example, although the likelihood of such an intersection is relatively > > small, it is possible that an offer/answer exchange is required at the > time > > a session timer refresh is in progress using UPDATE (or INVITE). > > I had the same concern, but obviously you don't have that problem if you use > UPDATE -without- SDP for the timer refresh. > > Regards, > > Christer Holmberg > Ericsson Finland > > > This > > required extra logic in the implementation to sequence these and is an > > overhead for a remote corner case. Further, the rules about crossing > > UPDATEs/INVITEs resulting in 491 have to be handled even though it would > > seem to make perfect sense to be able to accept an UPDATE without SDP > (sent > > for session refresh) while an UPDATE with SDP has been sent out by the UA. > > It seems silly to have to re-attempt a session refresh when the previous > > UPDATE/491 has verified the existence of the session at both ends. > > > > Having a separate request for session timer eliminates unnecessary > > overloading of the existing requests. But this seems like a big ado over a > > trivial issue. > > > > So, the idea of proxies subscribing to a UserAgent to detect session state > > is a good alternative. User agents can always verify session existence > using > > any request they choose that makes sense in the context of the dialog. > Since > > the session refreshes are supposed to be infrequent, having refreshes > cross > > each other is not very likely if the durations are randomly chosen. > Further, > > it hardly matters that the requests crossed since any (non-BYE/ > non-481/408) > > request/response exchange verifies the session liveness, anyway, achieving > > the purpose. > > > > Regards > > Venkat > > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Jonathan > > Rosenberg > > Sent: Wednesday, November 13, 2002 6:35 AM > > To: Christer Holmberg > > Cc: Stevens, Del; 'sip@ietf.org' > > Subject: Re: [Sip] The fate of session timer? > > > > Christer Holmberg wrote: > > > > > Second (and please don't flame me :), would it be a good idea to have a > > look at > > > the INFO method again? The reason we didn't want it in the first place > was > > > because it shall not be used for chaning state. But, since we now don't > > use the > > > session-timer for state recover that reason is maybe not valid anymore > (it > > is > > > NOT the INFO itself which changes the call state). > > > > The draft already specifies UPDATE. The UPDATE can be sent without a > > session description. Please explain what benefits there are to > > specifying the usage of INFO in addition. > > > > -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 > > > > _______________________________________________ > > 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 Nov 14 12:46:27 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25281 for ; Thu, 14 Nov 2002 12:46:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAEHmZv11925 for sip-archive@odin.ietf.org; Thu, 14 Nov 2002 12:48: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 gAEHjlv11848; Thu, 14 Nov 2002 12:45: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 gAEHcev11556 for ; Thu, 14 Nov 2002 12:38:40 -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 MAA25066 for ; Thu, 14 Nov 2002 12:36:00 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAEHcUQ1009995; Thu, 14 Nov 2002 18:38:30 +0100 (MET) Received: from lmf.ericsson.se (chzuwa01m22.eu.ericsson.se [164.48.166.22]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id gAEHcSCG011980; Thu, 14 Nov 2002 19:38:28 +0200 (EET) Message-ID: <3DD3DFAD.B1086DCB@lmf.ericsson.se> Date: Thu, 14 Nov 2002 19:38:53 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: jdrosen@dynamicsoft.com, chandan.rajah@wipro.com, sip@ietf.org Subject: Re: [Sip] The fate of session timer? References: <2038BCC78B1AD641891A0D1AE133DBB7FE6FBD@esebe019.ntc.nokia.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 Hi, > >Please also remember that this mechanism will allow your UA > >to find out if the remote party has LOST state of the call. > > What was the purpose of session-timer again? We need to define a scope and then abide by it. I guess one issue is what the UA shall do if it doesn't receive the refresh. Shall it simply clean its internal call state, or shall it also send a BYE, to make sure that possible call state is also cleared in intermediate proxies? 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 Thu Nov 14 12:50:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25368 for ; Thu, 14 Nov 2002 12:50:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAEHqTs12090 for sip-archive@odin.ietf.org; Thu, 14 Nov 2002 12:52:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAEHo8v12003; Thu, 14 Nov 2002 12:50: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 gAEHcnv11565 for ; Thu, 14 Nov 2002 12:38:49 -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 MAA25089 for ; Thu, 14 Nov 2002 12:36:09 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAEHccQ1010014; Thu, 14 Nov 2002 18:38:38 +0100 (MET) Received: from lmf.ericsson.se (chzuwa01m22.eu.ericsson.se [164.48.166.22]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id gAEHcZCG011985; Thu, 14 Nov 2002 19:38:36 +0200 (EET) Message-ID: <3DD3DFB5.25926145@lmf.ericsson.se> Date: Thu, 14 Nov 2002 19:39:01 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ssubir@hss.hns.com CC: hisham.khartabil@nokia.com, jdrosen@dynamicsoft.com, chandan.rajah@wipro.com, sip@ietf.org Subject: Re: [Sip] The fate of session timer? References: <65256C71.003F4DDF.00@sampark.hss.hns.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 Hi, > >Please also remember that this mechanism will allow your UA to > >find out if the remote party has LOST state of the call. > > UA would rather depend on the associated application than signaling to > decide LOST state. That's not my point. If I send refreshes (or whatever SIP request), and the remote end doesn't recognise the session, I know something is wrong - no matter if it's within the actual scope of the session timer or not... Regards, Christer Holmberg Ericsson Finland > > > Thanks, > Subir > > _______________________________________________ > 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 Nov 14 20:01:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11523 for ; Thu, 14 Nov 2002 20:01:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAF13JX06316 for sip-archive@odin.ietf.org; Thu, 14 Nov 2002 20:03:19 -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 gAF10rv06145; Thu, 14 Nov 2002 20:00: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 gAF0v1v05900 for ; Thu, 14 Nov 2002 19:57:01 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11167; Thu, 14 Nov 2002 19:54:17 -0500 (EST) Message-Id: <200211150054.TAA11167@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , sip@ietf.org From: The IESG Date: Thu, 14 Nov 2002 19:54:17 -0500 Subject: [Sip] Protocol Action: Security Mechanism Agreement for SIP Sessions to Proposed Standard 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: , The IESG has approved the Internet-Draft 'Security Mechanism Agreement for SIP Sessions' as a Proposed Standard. This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. Technical Summary The SIP protocol does not currently provide any good mechanism for negotiating which security mechanism to use between two SIP entities. This document fills that hole by defining three header fields for negotiating the SIP security mechanism to be used between a SIP entity and its next SIP hop. A SIP entity applying this mechanism must always require some minimum security (i.e. integrity protection) from all communicating parties in order to secure the negotiation, but the negotiation can agree on which specific minimum security is used. Working Group Summary The SIP working group supported publication of this document. Protocol Quality This document was reviewed for the IESG by Allison Mankin _______________________________________________ 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 Nov 14 22:37:30 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16736 for ; Thu, 14 Nov 2002 22:37:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAF3dh016410 for sip-archive@odin.ietf.org; Thu, 14 Nov 2002 22:39: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 gAF3Z6v15744; Thu, 14 Nov 2002 22:35: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 gAF3Vpv15671 for ; Thu, 14 Nov 2002 22:31:51 -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 WAA16348 for ; Thu, 14 Nov 2002 22:29:08 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gAF3VZ5V000853; Thu, 14 Nov 2002 19:31:35 -0800 (PST) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with SMTP id CFG00155; Thu, 14 Nov 2002 19:32:05 -0800 (PST) From: "Cullen Jennings" To: "Jonathan Rosenberg" , Subject: RE: [Sip] The fate of session timer? Date: Thu, 14 Nov 2002 19:33:07 -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: <3DD03C2B.6030401@dynamicsoft.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 We all hope that SIP will allow us to build innovative application. Many of these application will be realized in proxies in the network. SIP has several ways, using various tags, for these applications to save all their state out in the UAs. From a reliability and scalability point of view this puts the state in exactly the right place - it is fate shared with the UAs in the call. Session timers allows the applications to cause the various timers that the application needs to be executed on the UAs. This is brilliant - it fate shares the timers with the right thing and solves some problems that have always been tricky in doing high reliability applications. I think we should close the open issues in this draft and get it to RFC. Cullen > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > Jonathan Rosenberg > Sent: Monday, November 11, 2002 3:24 PM > To: sip@ietf.org > Subject: [Sip] The fate of session timer? > > > Folks, > > As you may have noticed, I submitted an update to the session timer > specification. This is an old, old spec that has been around for quite > some time. It receives only minimal attention these days. The general > comments on the list are generally 'too complex' and 'too hard to > understand'. Some of that is wording, which I will continue to work. The > bigger problem, I think, is that its not at all clear what problem this > draft is REALLY solving. > > I assert that session timer is really useful for one thing, which is to > provide a means to cleanup old session state in UAs and proxies. > Normally, you'd set a timer (on the order of 5 hours or something) to > discard any state thats still around. However, since a call may actually > last that long, you want a way to reliably know when you can flush the > state. > > Session timer is NOT useful for determining call durations for billing > purposes. > > Session timer is NOT useful for quickly determining that a UA has > failed, in order to recover. It operates too slowly for that. > > So, given this somewhat-marginal value, the complexity seems startingly > high. I have begun to wonder whether that is the reason for the troubles > this specification is having. So, I see a few options: > > 1. No one cares about this spec. Discard it entirely. > > 2. Continue as it is, fix up some wording, and submit. Probably no one > implements it since it provides little value at high cost. > > 3. Change the scope. Eliminate or simplify negotiation of the timer by > defining a suitably long minimum. Eliminate or simplify choosing who > refreshes by requiring that the UAC support the timer. And so on. The > result would be a much simpler spec. > > 4. others? > > > Please provide comments, particularly if you are actively using this > specification for some real problem. > > -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 > _______________________________________________ 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 Nov 15 02:51:22 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02047 for ; Fri, 15 Nov 2002 02:51:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAF7rbJ05399 for sip-archive@odin.ietf.org; Fri, 15 Nov 2002 02:53:37 -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 gAF7r3v05387; Fri, 15 Nov 2002 02:53: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 gAF7ojv05310 for ; Fri, 15 Nov 2002 02:50:45 -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 CAA02000 for ; Fri, 15 Nov 2002 02:47:57 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAF7oTKV005492; Fri, 15 Nov 2002 08:50:33 +0100 (MET) Received: from lmf.ericsson.se (vrrch2-177132.am.ericsson.se [138.85.177.132]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id gAF7oQCG016843; Fri, 15 Nov 2002 09:50:27 +0200 (EET) Message-ID: <3DD4A760.BD1FF3C3@lmf.ericsson.se> Date: Fri, 15 Nov 2002 09:50:56 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] The fate of session timer? References: <3DD3B930.E6230AC3@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 Hi, I have one question about the session-timer. This has probably been discussed before, but I'd still like to bring it up. Currently the spec says that a proxy not supporting the proposed refresh timer value will send a 422 response, and after that the UAC will have to send a new INVITE, with a higher timer value. Now, in a forking environment there is a chance that 422 responses will be received from proxies in legs which may never be part of the session, and the UAC will have to send a new INVITE, and rise the value because of proxes which may never be part of the session... I guess the forking proxy may not even always forward the 422 to the UAC, while waiting for other final responses, so the UAS on that leg may never get a chance to participate in the call in the first place, since the end-user may never receive the INVITE (a proxy will return 422). So, my question is: if a value is too small for a proxy, what is the reason it simply can't change the value and forward the INVITE? In that case the INVITE will receive the UAS, and the final response will indicate the refresh value which will actually be used. Regards, Christer Holmberg Ericsson Finland Christer Holmberg wrote: > Hi, > > > Christer > > That is not true. Another UPDATE may neither be received nor sent (491/500 > > with Retry after rules) when an UPDATE has been sent/received. > > If that is the case I don't want to use UPDATE :) To my understanding the > current functionality of the session-timer has nothing to do with the > offer/answer mechanism, so I see no reason why it should "block" other possible > offer/answer transactions. > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > Cheers, > > Venkat > > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Sent: Thursday, November 14, 2002 2:07 AM > > To: Arunachalam Venkatraman > > Cc: Jonathan Rosenberg; sip@ietf.org > > Subject: Re: [Sip] The fate of session timer? > > > > Hi, > > > > > Jonathan > > > Whenever we overload one request to do disparate functions, we have a > > source > > > of confusion, race conditions etc. > > > For example, although the likelihood of such an intersection is relatively > > > small, it is possible that an offer/answer exchange is required at the > > time > > > a session timer refresh is in progress using UPDATE (or INVITE). > > > > I had the same concern, but obviously you don't have that problem if you use > > UPDATE -without- SDP for the timer refresh. > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > This > > > required extra logic in the implementation to sequence these and is an > > > overhead for a remote corner case. Further, the rules about crossing > > > UPDATEs/INVITEs resulting in 491 have to be handled even though it would > > > seem to make perfect sense to be able to accept an UPDATE without SDP > > (sent > > > for session refresh) while an UPDATE with SDP has been sent out by the UA. > > > It seems silly to have to re-attempt a session refresh when the previous > > > UPDATE/491 has verified the existence of the session at both ends. > > > > > > Having a separate request for session timer eliminates unnecessary > > > overloading of the existing requests. But this seems like a big ado over a > > > trivial issue. > > > > > > So, the idea of proxies subscribing to a UserAgent to detect session state > > > is a good alternative. User agents can always verify session existence > > using > > > any request they choose that makes sense in the context of the dialog. > > Since > > > the session refreshes are supposed to be infrequent, having refreshes > > cross > > > each other is not very likely if the durations are randomly chosen. > > Further, > > > it hardly matters that the requests crossed since any (non-BYE/ > > non-481/408) > > > request/response exchange verifies the session liveness, anyway, achieving > > > the purpose. > > > > > > Regards > > > Venkat > > > > > > -----Original Message----- > > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Jonathan > > > Rosenberg > > > Sent: Wednesday, November 13, 2002 6:35 AM > > > To: Christer Holmberg > > > Cc: Stevens, Del; 'sip@ietf.org' > > > Subject: Re: [Sip] The fate of session timer? > > > > > > Christer Holmberg wrote: > > > > > > > Second (and please don't flame me :), would it be a good idea to have a > > > look at > > > > the INFO method again? The reason we didn't want it in the first place > > was > > > > because it shall not be used for chaning state. But, since we now don't > > > use the > > > > session-timer for state recover that reason is maybe not valid anymore > > (it > > > is > > > > NOT the INFO itself which changes the call state). > > > > > > The draft already specifies UPDATE. The UPDATE can be sent without a > > > session description. Please explain what benefits there are to > > > specifying the usage of INFO in addition. > > > > > > -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 > > > > > > _______________________________________________ > > > 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 Nov 15 03:14:46 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02437 for ; Fri, 15 Nov 2002 03:14:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAF8H0L06874 for sip-archive@odin.ietf.org; Fri, 15 Nov 2002 03:17: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 gAF8GLv06858; Fri, 15 Nov 2002 03:16: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 gAF8ELv06763 for ; Fri, 15 Nov 2002 03:14:21 -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 DAA02402 for ; Fri, 15 Nov 2002 03:11:34 -0500 (EST) Received: from mira-sjc5-1.cisco.com (IDENT:mirapoint@mira-sjc5-1.cisco.com [171.71.163.15]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gAF8E05V029445; Fri, 15 Nov 2002 00:14:00 -0800 (PST) Received: from sprajpat-w2k01.cisco.com (sjc-vpn3-230.cisco.com [10.21.64.230]) by mira-sjc5-1.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id ABD02514; Fri, 15 Nov 2002 00:09:05 -0800 (PST) Message-Id: <4.3.2.7.2.20021115000854.02104da0@mira-sjc5-1> X-Sender: sprajpat@mira-sjc5-1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 15 Nov 2002 00:13:58 -0800 To: Christer Holmberg From: Surendra Prajapat Subject: Re: [Sip] The fate of session timer? Cc: Jonathan Rosenberg , sip@ietf.org In-Reply-To: <3DD4A760.BD1FF3C3@lmf.ericsson.se> References: <3DD3B930.E6230AC3@lmf.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , As I understand it from the extenstion, the expire time is negotiated between entities which are already in a dialog. So in case of forking the timer value will only be negotiated with entities which eventually be participating in the call. -Surendra that it should not happen till the session is established and so even in forking At 09:50 AM 11/15/2002 +0200, Christer Holmberg wrote: >Hi, > >I have one question about the session-timer. This has probably been discussed >before, but I'd still like to bring it up. > >Currently the spec says that a proxy not supporting the proposed refresh timer >value will send a 422 response, and after that the UAC will have to send a new >INVITE, with a higher timer value. > >Now, in a forking environment there is a chance that 422 responses will be >received >from proxies in legs which may never be part of the session, and the UAC >will have >to send a new INVITE, and rise the value because of proxes which may never >be part >of the session... I guess the forking proxy may not even always forward >the 422 to >the UAC, while waiting for other final responses, so the UAS on that leg >may never >get a chance to participate in the call in the first place, since the >end-user may >never receive the INVITE (a proxy will return 422). > >So, my question is: if a value is too small for a proxy, what is the reason it >simply can't change the value and forward the INVITE? In that case the >INVITE will >receive the UAS, and the final response will indicate the refresh value >which will >actually be used. > >Regards, > >Christer Holmberg >Ericsson Finland > > > >Christer Holmberg wrote: > > > Hi, > > > > > Christer > > > That is not true. Another UPDATE may neither be received nor sent > (491/500 > > > with Retry after rules) when an UPDATE has been sent/received. > > > > If that is the case I don't want to use UPDATE :) To my understanding the > > current functionality of the session-timer has nothing to do with the > > offer/answer mechanism, so I see no reason why it should "block" other > possible > > offer/answer transactions. > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > Cheers, > > > Venkat > > > > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > > Sent: Thursday, November 14, 2002 2:07 AM > > > To: Arunachalam Venkatraman > > > Cc: Jonathan Rosenberg; sip@ietf.org > > > Subject: Re: [Sip] The fate of session timer? > > > > > > Hi, > > > > > > > Jonathan > > > > Whenever we overload one request to do disparate functions, we have a > > > source > > > > of confusion, race conditions etc. > > > > For example, although the likelihood of such an intersection is > relatively > > > > small, it is possible that an offer/answer exchange is required at the > > > time > > > > a session timer refresh is in progress using UPDATE (or INVITE). > > > > > > I had the same concern, but obviously you don't have that problem if > you use > > > UPDATE -without- SDP for the timer refresh. > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > > This > > > > required extra logic in the implementation to sequence these and is an > > > > overhead for a remote corner case. Further, the rules about crossing > > > > UPDATEs/INVITEs resulting in 491 have to be handled even though it > would > > > > seem to make perfect sense to be able to accept an UPDATE without SDP > > > (sent > > > > for session refresh) while an UPDATE with SDP has been sent out by > the UA. > > > > It seems silly to have to re-attempt a session refresh when the > previous > > > > UPDATE/491 has verified the existence of the session at both ends. > > > > > > > > Having a separate request for session timer eliminates unnecessary > > > > overloading of the existing requests. But this seems like a big ado > over a > > > > trivial issue. > > > > > > > > So, the idea of proxies subscribing to a UserAgent to detect > session state > > > > is a good alternative. User agents can always verify session existence > > > using > > > > any request they choose that makes sense in the context of the dialog. > > > Since > > > > the session refreshes are supposed to be infrequent, having refreshes > > > cross > > > > each other is not very likely if the durations are randomly chosen. > > > Further, > > > > it hardly matters that the requests crossed since any (non-BYE/ > > > non-481/408) > > > > request/response exchange verifies the session liveness, anyway, > achieving > > > > the purpose. > > > > > > > > Regards > > > > Venkat > > > > > > > > -----Original Message----- > > > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > Jonathan > > > > Rosenberg > > > > Sent: Wednesday, November 13, 2002 6:35 AM > > > > To: Christer Holmberg > > > > Cc: Stevens, Del; 'sip@ietf.org' > > > > Subject: Re: [Sip] The fate of session timer? > > > > > > > > Christer Holmberg wrote: > > > > > > > > > Second (and please don't flame me :), would it be a good idea to > have a > > > > look at > > > > > the INFO method again? The reason we didn't want it in the first > place > > > was > > > > > because it shall not be used for chaning state. But, since we now > don't > > > > use the > > > > > session-timer for state recover that reason is maybe not valid > anymore > > > (it > > > > is > > > > > NOT the INFO itself which changes the call state). > > > > > > > > The draft already specifies UPDATE. The UPDATE can be sent without a > > > > session description. Please explain what benefits there are to > > > > specifying the usage of INFO in addition. > > > > > > > > -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 > > > > > > > > _______________________________________________ > > > > 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 Fri Nov 15 04:43:13 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03766 for ; Fri, 15 Nov 2002 04:43:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAF9jSO12062 for sip-archive@odin.ietf.org; Fri, 15 Nov 2002 04:45: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 gAF9iPv12009; Fri, 15 Nov 2002 04:44: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 gAF9h1v11916 for ; Fri, 15 Nov 2002 04:43:01 -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 EAA03688 for ; Fri, 15 Nov 2002 04:40:14 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAF9glQ1028965; Fri, 15 Nov 2002 10:42:47 +0100 (MET) Received: from lmf.ericsson.se (vrrch2-177134.am.ericsson.se [138.85.177.134]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id gAF9ggCG023435; Fri, 15 Nov 2002 11:42:44 +0200 (EET) Message-ID: <3DD4C1B2.3D3C71DD@lmf.ericsson.se> Date: Fri, 15 Nov 2002 11:43:14 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Surendra Prajapat CC: Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] The fate of session timer? References: <3DD3B930.E6230AC3@lmf.ericsson.se> <4.3.2.7.2.20021115000854.02104da0@mira-sjc5-1> 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, > As I understand it from the extenstion, the expire time is negotiated > between entities which are already in a dialog. So in case > of forking the timer value will only be negotiated with entities which > eventually be participating in the call. Eeeh... I don't really understand... The UAC sends an INVITE, which gets forked. ANYONE receiving the INVITE, no matter if they will be part of the established dialog or not, can reject it with 422. If one wants to re-negotiate the timer when the session is established we of course don't have this situation, but that is not what I was talking about. Regards, Christer Holmberg Ericsson Finland > > > -Surendra > > that it should not happen till the session is established and so even in > forking > At 09:50 AM 11/15/2002 +0200, Christer Holmberg wrote: > > >Hi, > > > >I have one question about the session-timer. This has probably been discussed > >before, but I'd still like to bring it up. > > > >Currently the spec says that a proxy not supporting the proposed refresh timer > >value will send a 422 response, and after that the UAC will have to send a new > >INVITE, with a higher timer value. > > > >Now, in a forking environment there is a chance that 422 responses will be > >received > >from proxies in legs which may never be part of the session, and the UAC > >will have > >to send a new INVITE, and rise the value because of proxes which may never > >be part > >of the session... I guess the forking proxy may not even always forward > >the 422 to > >the UAC, while waiting for other final responses, so the UAS on that leg > >may never > >get a chance to participate in the call in the first place, since the > >end-user may > >never receive the INVITE (a proxy will return 422). > > > >So, my question is: if a value is too small for a proxy, what is the reason it > >simply can't change the value and forward the INVITE? In that case the > >INVITE will > >receive the UAS, and the final response will indicate the refresh value > >which will > >actually be used. > > > >Regards, > > > >Christer Holmberg > >Ericsson Finland > > > > > > > >Christer Holmberg wrote: > > > > > Hi, > > > > > > > Christer > > > > That is not true. Another UPDATE may neither be received nor sent > > (491/500 > > > > with Retry after rules) when an UPDATE has been sent/received. > > > > > > If that is the case I don't want to use UPDATE :) To my understanding the > > > current functionality of the session-timer has nothing to do with the > > > offer/answer mechanism, so I see no reason why it should "block" other > > possible > > > offer/answer transactions. > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > > > > > > Cheers, > > > > Venkat > > > > > > > > -----Original Message----- > > > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > > > Sent: Thursday, November 14, 2002 2:07 AM > > > > To: Arunachalam Venkatraman > > > > Cc: Jonathan Rosenberg; sip@ietf.org > > > > Subject: Re: [Sip] The fate of session timer? > > > > > > > > Hi, > > > > > > > > > Jonathan > > > > > Whenever we overload one request to do disparate functions, we have a > > > > source > > > > > of confusion, race conditions etc. > > > > > For example, although the likelihood of such an intersection is > > relatively > > > > > small, it is possible that an offer/answer exchange is required at the > > > > time > > > > > a session timer refresh is in progress using UPDATE (or INVITE). > > > > > > > > I had the same concern, but obviously you don't have that problem if > > you use > > > > UPDATE -without- SDP for the timer refresh. > > > > > > > > Regards, > > > > > > > > Christer Holmberg > > > > Ericsson Finland > > > > > > > > > This > > > > > required extra logic in the implementation to sequence these and is an > > > > > overhead for a remote corner case. Further, the rules about crossing > > > > > UPDATEs/INVITEs resulting in 491 have to be handled even though it > > would > > > > > seem to make perfect sense to be able to accept an UPDATE without SDP > > > > (sent > > > > > for session refresh) while an UPDATE with SDP has been sent out by > > the UA. > > > > > It seems silly to have to re-attempt a session refresh when the > > previous > > > > > UPDATE/491 has verified the existence of the session at both ends. > > > > > > > > > > Having a separate request for session timer eliminates unnecessary > > > > > overloading of the existing requests. But this seems like a big ado > > over a > > > > > trivial issue. > > > > > > > > > > So, the idea of proxies subscribing to a UserAgent to detect > > session state > > > > > is a good alternative. User agents can always verify session existence > > > > using > > > > > any request they choose that makes sense in the context of the dialog. > > > > Since > > > > > the session refreshes are supposed to be infrequent, having refreshes > > > > cross > > > > > each other is not very likely if the durations are randomly chosen. > > > > Further, > > > > > it hardly matters that the requests crossed since any (non-BYE/ > > > > non-481/408) > > > > > request/response exchange verifies the session liveness, anyway, > > achieving > > > > > the purpose. > > > > > > > > > > Regards > > > > > Venkat > > > > > > > > > > -----Original Message----- > > > > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > > Jonathan > > > > > Rosenberg > > > > > Sent: Wednesday, November 13, 2002 6:35 AM > > > > > To: Christer Holmberg > > > > > Cc: Stevens, Del; 'sip@ietf.org' > > > > > Subject: Re: [Sip] The fate of session timer? > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > Second (and please don't flame me :), would it be a good idea to > > have a > > > > > look at > > > > > > the INFO method again? The reason we didn't want it in the first > > place > > > > was > > > > > > because it shall not be used for chaning state. But, since we now > > don't > > > > > use the > > > > > > session-timer for state recover that reason is maybe not valid > > anymore > > > > (it > > > > > is > > > > > > NOT the INFO itself which changes the call state). > > > > > > > > > > The draft already specifies UPDATE. The UPDATE can be sent without a > > > > > session description. Please explain what benefits there are to > > > > > specifying the usage of INFO in addition. > > > > > > > > > > -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 > > > > > > > > > > _______________________________________________ > > > > > 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 Fri Nov 15 08:30:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07826 for ; Fri, 15 Nov 2002 08:30:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAFDWG322988 for sip-archive@odin.ietf.org; Fri, 15 Nov 2002 08:32: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 gAFDTCv22898; Fri, 15 Nov 2002 08:29: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 gAFDO1v22783 for ; Fri, 15 Nov 2002 08:24:01 -0500 Received: from brmx1.fl.icn.siemens.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07626 for ; Fri, 15 Nov 2002 08:21:22 -0500 (EST) Received: from boca210a.boca.ssc.siemens.com (boca210a.boca.ssc.siemens.com [165.218.12.110]) by brmx1.fl.icn.siemens.com (8.9.3/8.9.3) with ESMTP id IAA18140; Fri, 15 Nov 2002 08:23:40 -0500 (EST) Received: by BOCA210A with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Nov 2002 08:23:39 -0500 Message-ID: <7A25937D23A1E64C8E93CB4A50509C2A1EBE0D@stca204a.bus.sc.rolm.com> From: "Stevens, Del" To: "'Christer Holmberg'" , hisham.khartabil@nokia.com Cc: jdrosen@dynamicsoft.com, chandan.rajah@wipro.com, sip@ietf.org Subject: RE: [Sip] The fate of session timer? Date: Fri, 15 Nov 2002 08:23:39 -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: , Christer, The draft currently states, and I agree, that if the session timer expires prior to receiving a 200 response to the refresh, the UA SHOULD send a BYE. Of course, the UA expecting a refresh SHOULD also send a BYE if a refresh is not received prior to the session timer expiring. This ensures that all UAs and Proxies "involved" in the session will perform appropriate cleanup. Del > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Thursday, November 14, 2002 12:39 PM > To: hisham.khartabil@nokia.com > Cc: jdrosen@dynamicsoft.com; chandan.rajah@wipro.com; sip@ietf.org > Subject: Re: [Sip] The fate of session timer? > > > > Hi, > > > >Please also remember that this mechanism will allow your UA > > >to find out if the remote party has LOST state of the call. > > > > What was the purpose of session-timer again? We need to > define a scope and then abide by it. > > I guess one issue is what the UA shall do if it doesn't > receive the refresh. Shall it simply > clean its internal call state, or shall it also send a BYE, > to make sure that possible call > state is also cleared in intermediate proxies? > > 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 > _______________________________________________ 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 Nov 15 09:46:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09482 for ; Fri, 15 Nov 2002 09:46:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAFEmE227081 for sip-archive@odin.ietf.org; Fri, 15 Nov 2002 09:48: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 gAFEjav27014; Fri, 15 Nov 2002 09:45: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 gAFEfwv26907 for ; Fri, 15 Nov 2002 09:41:58 -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 JAA09391 for ; Fri, 15 Nov 2002 09:39:20 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAFEfqQ1024535; Fri, 15 Nov 2002 15:41:52 +0100 (MET) Received: from lmf.ericsson.se (vrrch2-177140.am.ericsson.se [138.85.177.140]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id gAFEflCG011585; Fri, 15 Nov 2002 16:41:48 +0200 (EET) Message-ID: <3DD507C9.6AB15AD1@lmf.ericsson.se> Date: Fri, 15 Nov 2002 16:42:17 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Stevens, Del" CC: hisham.khartabil@nokia.com, jdrosen@dynamicsoft.com, chandan.rajah@wipro.com, sip@ietf.org Subject: Re: [Sip] The fate of session timer? References: <7A25937D23A1E64C8E93CB4A50509C2A1EBE0D@stca204a.bus.sc.rolm.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 Hi, I think we are talking about separate issues here. I am not talking about the case where the session timer expires prior to the receiving of a 200 OK response. I am talking about what may happen during the session setup, when the initial INVITE may be forked to multiple proxies in different legs. Regards, Christer Holmberg Ericsson Finland > Christer, > > The draft currently states, and I agree, that if the session timer expires > prior to receiving a 200 response to the refresh, the UA SHOULD send a BYE. > Of course, the UA expecting a refresh SHOULD also send a BYE if a refresh is > not received prior to the session timer expiring. This ensures that all UAs > and Proxies "involved" in the session will perform appropriate cleanup. > > Del > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Sent: Thursday, November 14, 2002 12:39 PM > > To: hisham.khartabil@nokia.com > > Cc: jdrosen@dynamicsoft.com; chandan.rajah@wipro.com; sip@ietf.org > > Subject: Re: [Sip] The fate of session timer? > > > > > > > > Hi, > > > > > >Please also remember that this mechanism will allow your UA > > > >to find out if the remote party has LOST state of the call. > > > > > > What was the purpose of session-timer again? We need to > > define a scope and then abide by it. > > > > I guess one issue is what the UA shall do if it doesn't > > receive the refresh. Shall it simply > > clean its internal call state, or shall it also send a BYE, > > to make sure that possible call > > state is also cleared in intermediate proxies? > > > > 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 > > _______________________________________________ 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 Nov 15 10:03:58 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09837 for ; Fri, 15 Nov 2002 10:03:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAFF65f27636 for sip-archive@odin.ietf.org; Fri, 15 Nov 2002 10:06: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 gAFF3Yv27545; Fri, 15 Nov 2002 10:03:34 -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 gAFF0Hv27459 for ; Fri, 15 Nov 2002 10:00:17 -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 JAA09692 for ; Fri, 15 Nov 2002 09:57:38 -0500 (EST) Received: from sponge.cisco.com (IDENT:mirapoint@sponge.cisco.com [64.101.128.87]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAFF0CNf010284 for ; Fri, 15 Nov 2002 07:00:12 -0800 (PST) Received: from ARUNVENKW2K1 (sjc-vpn2-118.cisco.com [10.21.112.118]) by sponge.cisco.com (Mirapoint) with SMTP id ABT25625; Fri, 15 Nov 2002 09:00:11 -0600 (CST) From: "Arunachalam Venkatraman" To: Subject: RE: [Sip] The fate of session timer? Date: Fri, 15 Nov 2002 09:07:49 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3DD4A760.BD1FF3C3@lmf.ericsson.se> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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 Christer The proxy cannot change the value and send it to the same UAS again because a proxy cannot up the CSEQ and originate a request. The UAS receiving the request with the changed value of session timer has to recognize it as a new request, so it has to have a higher CSEQ. Regards, Venkat -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Christer Holmberg Sent: Friday, November 15, 2002 1:51 AM To: Jonathan Rosenberg; sip@ietf.org Subject: Re: [Sip] The fate of session timer? Hi, I have one question about the session-timer. This has probably been discussed before, but I'd still like to bring it up. Currently the spec says that a proxy not supporting the proposed refresh timer value will send a 422 response, and after that the UAC will have to send a new INVITE, with a higher timer value. Now, in a forking environment there is a chance that 422 responses will be received from proxies in legs which may never be part of the session, and the UAC will have to send a new INVITE, and rise the value because of proxes which may never be part of the session... I guess the forking proxy may not even always forward the 422 to the UAC, while waiting for other final responses, so the UAS on that leg may never get a chance to participate in the call in the first place, since the end-user may never receive the INVITE (a proxy will return 422). So, my question is: if a value is too small for a proxy, what is the reason it simply can't change the value and forward the INVITE? In that case the INVITE will receive the UAS, and the final response will indicate the refresh value which will actually be used. Regards, Christer Holmberg Ericsson Finland Christer Holmberg wrote: > Hi, > > > Christer > > That is not true. Another UPDATE may neither be received nor sent (491/500 > > with Retry after rules) when an UPDATE has been sent/received. > > If that is the case I don't want to use UPDATE :) To my understanding the > current functionality of the session-timer has nothing to do with the > offer/answer mechanism, so I see no reason why it should "block" other possible > offer/answer transactions. > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > Cheers, > > Venkat > > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Sent: Thursday, November 14, 2002 2:07 AM > > To: Arunachalam Venkatraman > > Cc: Jonathan Rosenberg; sip@ietf.org > > Subject: Re: [Sip] The fate of session timer? > > > > Hi, > > > > > Jonathan > > > Whenever we overload one request to do disparate functions, we have a > > source > > > of confusion, race conditions etc. > > > For example, although the likelihood of such an intersection is relatively > > > small, it is possible that an offer/answer exchange is required at the > > time > > > a session timer refresh is in progress using UPDATE (or INVITE). > > > > I had the same concern, but obviously you don't have that problem if you use > > UPDATE -without- SDP for the timer refresh. > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > This > > > required extra logic in the implementation to sequence these and is an > > > overhead for a remote corner case. Further, the rules about crossing > > > UPDATEs/INVITEs resulting in 491 have to be handled even though it would > > > seem to make perfect sense to be able to accept an UPDATE without SDP > > (sent > > > for session refresh) while an UPDATE with SDP has been sent out by the UA. > > > It seems silly to have to re-attempt a session refresh when the previous > > > UPDATE/491 has verified the existence of the session at both ends. > > > > > > Having a separate request for session timer eliminates unnecessary > > > overloading of the existing requests. But this seems like a big ado over a > > > trivial issue. > > > > > > So, the idea of proxies subscribing to a UserAgent to detect session state > > > is a good alternative. User agents can always verify session existence > > using > > > any request they choose that makes sense in the context of the dialog. > > Since > > > the session refreshes are supposed to be infrequent, having refreshes > > cross > > > each other is not very likely if the durations are randomly chosen. > > Further, > > > it hardly matters that the requests crossed since any (non-BYE/ > > non-481/408) > > > request/response exchange verifies the session liveness, anyway, achieving > > > the purpose. > > > > > > Regards > > > Venkat > > > > > > -----Original Message----- > > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Jonathan > > > Rosenberg > > > Sent: Wednesday, November 13, 2002 6:35 AM > > > To: Christer Holmberg > > > Cc: Stevens, Del; 'sip@ietf.org' > > > Subject: Re: [Sip] The fate of session timer? > > > > > > Christer Holmberg wrote: > > > > > > > Second (and please don't flame me :), would it be a good idea to have a > > > look at > > > > the INFO method again? The reason we didn't want it in the first place > > was > > > > because it shall not be used for chaning state. But, since we now don't > > > use the > > > > session-timer for state recover that reason is maybe not valid anymore > > (it > > > is > > > > NOT the INFO itself which changes the call state). > > > > > > The draft already specifies UPDATE. The UPDATE can be sent without a > > > session description. Please explain what benefits there are to > > > specifying the usage of INFO in addition. > > > > > > -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 > > > > > > _______________________________________________ > > > 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 Fri Nov 15 11:59:53 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12418 for ; Fri, 15 Nov 2002 11:59:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAFH21k01373 for sip-archive@odin.ietf.org; Fri, 15 Nov 2002 12:02: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 gAFGxDv01239; Fri, 15 Nov 2002 11:59: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 gAFGmRv00928 for ; Fri, 15 Nov 2002 11:48:27 -0500 Received: from fmis402r.omnitel.it (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12136; Fri, 15 Nov 2002 11:45:47 -0500 (EST) From: loretosa@vizzavi.it Received: from fmis440.omnitel.it by fmis402r.omnitel.it via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 15 Nov 2002 16:48:22 UT Received: (private information removed) Received: (private information removed) Content-Class: urn:content-classes:message To: , , Date: Fri, 15 Nov 2002 17:45:23 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft CDO for Windows 2000 Thread-Index: AcKMxmQS7Vg7JYolQQuGOYSryipSUg== X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] sip module for NS 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, i'm looking for a sip module for Network Simulator. do you know, if it exists. And if yes, where it's possible download. Sal personal mail: loretosa@vizzavi.it work mail: salvatore.loreto@eri.ericsson.se loreto@coritel.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 Fri Nov 15 12:30:34 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12988 for ; Fri, 15 Nov 2002 12:30:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAFHWhU03490 for sip-archive@odin.ietf.org; Fri, 15 Nov 2002 12:32: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 gAFHUGv03421; Fri, 15 Nov 2002 12: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 gAFHQpv03310 for ; Fri, 15 Nov 2002 12:26:51 -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 MAA12863 for ; Fri, 15 Nov 2002 12:24:11 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAFHQjKV026633; Fri, 15 Nov 2002 18:26:45 +0100 (MET) Received: from lmf.ericsson.se (vrrch1-177037.am.ericsson.se [138.85.177.37]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id gAFHQhCG018200; Fri, 15 Nov 2002 19:26:44 +0200 (EET) Message-ID: <3DD52E71.80942B29@lmf.ericsson.se> Date: Fri, 15 Nov 2002 19:27:14 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Arunachalam Venkatraman CC: sip@ietf.org Subject: Re: [Sip] The fate of session timer? 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 Hi, I never said the proxy should change the value and send it to the same UAS again... What I said was two things: 1. The UAC MAY receive 422 from proxies in early legs which will never be used in the call, because if the message was forked. 2. A forking proxy may "buffer" a 422 it receives from a proxy in a leg, while waiting for final responses from other legs. Then, if it receives a 200 OK from another leg the UAS behind the proxy who sent the 422 never received the INVITE, so it was never given a chance to participate in the call. So, because of these reasons (even if the first would never take place, I still think the second is valid) my proposal was that proxies should NOT have to return 422. Instead they should be able to update the refresh value to a higher value and simply forward the INVITE. This way the INVITE would reach every UAS, and every UAS would be given a chance to participate in the call. Now, if the refresh value received by the UAS for some reason is too low, it can choose to either return 422 or return 200 with an updated value. If this value now, for whatever reason, is too big for the UAC it may either terminate the call or try to re-negoatiate the refresh value. Now, I realise a drawback with this proposal is that if the UAS updates the value, intermediate proxies will not be able to indicate in case they, for whatever reason, think the value is too high. One reason too solve this would be to define also a "max value" header, if really needed. I also earlier said that this has been discussed before, and that there may be issues I didn't think of now. 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 Fri Nov 15 13:24:38 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14763 for ; Fri, 15 Nov 2002 13:24:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAFIQlN06222 for sip-archive@odin.ietf.org; Fri, 15 Nov 2002 13:26: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 gAFIO5v06177; Fri, 15 Nov 2002 13:24: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 gAFIKcv06086 for ; Fri, 15 Nov 2002 13:20:38 -0500 Received: from jupiter.securelogix.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14641 for ; Fri, 15 Nov 2002 13:17:57 -0500 (EST) Received: by jupiter with Internet Mail Service (5.5.2448.0) id ; Fri, 15 Nov 2002 12:20:37 -0600 Message-ID: <493BB8BDBB5AD511A7BB00104B62EE280105FF2B@jupiter> From: David Oliver To: "'Drage, Keith (Keith)'" , Jonathan Rosenberg , hisham.khartabil@nokia.com Cc: chandan.rajah@wipro.com, sip@ietf.org Subject: RE: [Sip] The fate of session timer? Date: Fri, 15 Nov 2002 12:20:36 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) 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: , Keith, I believe there is no requirement that a proxy MUST perform a cleanup after a period of time. It's just a good idea for proxies to abandon dialogs that appear to be "dead". By abandonment I mean discarding state of a dialog after a successfully OKed INVITE and before a BYE. Timer C handles timeouts between INVITE and OK. It seems that determining a dialog to be dead by a proxy in SIP is only reasonably determined by inactivity. Changing the term "timer" to "timeout" in the requirements should reflect this. It is a practical requirement that User Agent changes are minimal (including no change for common situations), to allow for interworking with existing "hard" devices, and to recognize that the benefits primarily accrue to proxies. In particular, a UA that does not support extended dialogs (e.g. answering machine, pager, IM application) should be implicitly conformant. In general, it would seem unlikely that user agent implementations are likely to negotiate a shorter timeout. Exceptions would include mobile devices, where lost calls are common. Currently implemented proxies are likely to perform ad hoc abandonment of timed out dialogs to prevent possible overload (even if this requires human intervention, up to and including a reboot). A minimally conformant proxy could be possibly be implemented by simply changing the parameters of an existing timer to use the default timeout. Ignoring a UA-requested timeout would merely keep resources allocated for slightly longer than necessary. Although it would be possible for a proxy to specify a timeout period, this would only be useful where many dialogs "die", and would only work where at least one UA is fully conformant. I am not certain if this has much utility. Based on these musings, these look like possible requirements: 1) A stateful proxy MUST NOT abandon a dialog until a timeout period has elapsed since the last observed SIP activity. A proxy MAY abandon any dialog after the timeout period. 2) The default timeout period MUST be such that non-conformant UAs are rarely affected. 3) A UA shall be implicitly conformant if its dialogs terminate normally in less than the default timeout period. 3) Either (or both) the UAC or UAS MAY request a changed timeout period. Any requesting UA is responsible for ensuring the dialog is refreshed at its requested period. Best Regards, David C. Oliver SecureLogix Inc. +1 210 402 9669 david.oliver@securelogix.com -----Original Message----- From: Drage, Keith (Keith) [mailto:drage@lucent.com] Sent: Wednesday, November 13, 2002 7:01 PM To: Jonathan Rosenberg; hisham.khartabil@nokia.com Cc: chandan.rajah@wipro.com; sip@ietf.org Subject: RE: [Sip] The fate of session timer? Actually, if we really want to proceed with session timer, then I think putting a requirements draft through SIPPING is an excellent idea. We have had too many discussions in the past of what are we trying to achieve, so I think obtaining consensus as to whether there are requirements and what those requirements are is an excellent idea. And by the way, 1) I see no requirements below on the treatment in response to non-supporting entities, i.e. the compatibility requirements. 2) Some of these requirements seem to specify the implementation - who says we need a timer in the first place - the base requirement is that we do a cleanup within certain time constraints, yes, but stating "timer" implies we are always going to do this after a determined period of time rather than as and when we feel like it. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.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 Nov 15 13:34:20 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14935 for ; Fri, 15 Nov 2002 13:34:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAFIaUC06537 for sip-archive@odin.ietf.org; Fri, 15 Nov 2002 13:36:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFIXMv06458; Fri, 15 Nov 2002 13:33: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 gAFIUYv06339 for ; Fri, 15 Nov 2002 13:30:34 -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 NAA14853 for ; Fri, 15 Nov 2002 13:27:53 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.85]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAFIUVYH000962 for ; Fri, 15 Nov 2002 13:30:31 -0500 (EST) Message-ID: <3DD53D44.3070209@dynamicsoft.com> Date: Fri, 15 Nov 2002 13:30: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] Update to SIP guidelines 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, As you probably saw, I submitted an update to the guidelines draft. The changes were mostly minor, based on comments received since the last revision. Changes are: * implementors of extensions MUST check that their BNF doesn't conflict with any BNF in standards track extensions. * recommend BNF be collected at the end of the document. * changed recommended naming convention for documents so that the useful information is in the first few words * updated references * added discussion on IANA Considerations sections * added discussion on usage of terminology from rfc3261 * added header field parameters as another way to extend SIP * removed usage guidelines section, as it was repetitive * added justification of why method names are capitalized * more details on header naming conventions * updating discussion on case sensitivity * upgraded to MUST usage of the common SIP grammar for headers * example sections can omit SDP and content lengths, but you need to point it out. -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 Fri Nov 15 16:09:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19188 for ; Fri, 15 Nov 2002 16:09:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAFLBAs16810 for sip-archive@odin.ietf.org; Fri, 15 Nov 2002 16:11: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 gAFL7xv16692; Fri, 15 Nov 2002 16:07:59 -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 gAFKudv15644 for ; Fri, 15 Nov 2002 15:56:39 -0500 Received: from jupiter.securelogix.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18760 for ; Fri, 15 Nov 2002 15:53:58 -0500 (EST) Received: by jupiter with Internet Mail Service (5.5.2448.0) id ; Fri, 15 Nov 2002 14:56:37 -0600 Message-ID: <493BB8BDBB5AD511A7BB00104B62EE280105FF2D@jupiter> From: David Oliver To: "'sip@ietf.org'" Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-guidelines-06.txt (nits) Date: Fri, 15 Nov 2002 14:56:36 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) 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: , A couple of nits... 4.4 Syntactic Issues Para 3... It is RECOMMENDED that this be camel case. -- One hump or two? 4.6 Examples Section Para 2: "meanining" => meaning Best Regards, David C. Oliver SecureLogix Inc. -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Friday, November 08, 2002 12:40 PM Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-guidelines-06.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 : Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-sip-guidelines-06.txt Pages : 22 Date : 2002-11-8 The Session Initiation Protocol (SIP) is a flexible, yet simple tool for establishing interactive connections across the Internet. Part of this flexibility is the ease with which it can be extended. In order to facilitate effective and interoperable extensions to SIP, some guidelines need to be followed when developing SIP extensions. This document outlines a set of such guidelines for authors of SIP extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-guidelines-06.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-guidelines-06.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-guidelines-06.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 Nov 15 17:31:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21945 for ; Fri, 15 Nov 2002 17:31:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAFMXKI22486 for sip-archive@odin.ietf.org; Fri, 15 Nov 2002 17:33:20 -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 gAFMUMv22271; Fri, 15 Nov 2002 17:30: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 gAFMP0v22070 for ; Fri, 15 Nov 2002 17:25:00 -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 RAA21761 for ; Fri, 15 Nov 2002 17:22:17 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.85]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAFMOqYH001073; Fri, 15 Nov 2002 17:24:53 -0500 (EST) Message-ID: <3DD57431.10508@dynamicsoft.com> Date: Fri, 15 Nov 2002 17:24:49 -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: De Leo Walter CC: "'sip@ietf.org'" Subject: Re: [Sip] SIP Nat Traversal Reference needed 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 A nontrivial exercise. I have tried to keep an up to date list on my web page. You can find the list at: http://www.jdrosen.net/links.html the best place is to read the sipping nat scenarios doc, since that puts it all together. -Jonathan R. De Leo Walter wrote: > Hi. > I will be very thankful if someone could send me a pointer to a complete set > of work items referred to this subject. > > Regards. > Walter > _______________________________________________ > 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 > -- 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 Fri Nov 15 18:06:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23021 for ; Fri, 15 Nov 2002 18:06:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAFN9Bo25322 for sip-archive@odin.ietf.org; Fri, 15 Nov 2002 18:09: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 gAFN6lv24584; Fri, 15 Nov 2002 18:06: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 gAFMmhv23866 for ; Fri, 15 Nov 2002 17:48:43 -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 RAA22433 for ; Fri, 15 Nov 2002 17:46:00 -0500 (EST) Received: from jku07.iptel.org (dhcp213.fokus.gmd.de [195.37.78.213]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id gAFMmKn22682; Fri, 15 Nov 2002 23:48:20 +0100 Message-Id: <5.1.0.14.0.20021115234217.00b73870@iptel.org> X-Sender: jiri@iptel.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 15 Nov 2002 23:46:12 +0100 To: Jonathan Rosenberg , De Leo Walter From: Jiri Kuthan Subject: IETF Archive (was Re: [Sip] SIP Nat Traversal Reference needed Cc: "'sip@ietf.org'" In-Reply-To: <3DD57431.10508@dynamicsoft.com> References: 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 maintain an archive of related IETF work at http://www.iptel.org/ietf/. It includes both up-to-date and expired items, and wdiffs with previous versions. It is automatically updated every day so that you always get the most up-to-date versions of Internet Drafts. There is a section on the topic in question too. -Jiri At 11:24 PM 11/15/2002, Jonathan Rosenberg wrote: >A nontrivial exercise. > >I have tried to keep an up to date list on my web page. You can find the list at: > >http://www.jdrosen.net/links.html > >the best place is to read the sipping nat scenarios doc, since that puts it all together. > >-Jonathan R. > >De Leo Walter wrote: >>Hi. >>I will be very thankful if someone could send me a pointer to a complete set >>of work items referred to this subject. >>Regards. >>Walter >>_______________________________________________ >>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 > >-- >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 Fri Nov 15 20:18:20 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25715 for ; Fri, 15 Nov 2002 20:18:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAG1KXP31074 for sip-archive@odin.ietf.org; Fri, 15 Nov 2002 20:20: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 gAG1I5v30997; Fri, 15 Nov 2002 20:18: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 gAG1Cov30857 for ; Fri, 15 Nov 2002 20:12:50 -0500 Received: from gamma.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25582; Fri, 15 Nov 2002 20:10:01 -0500 (EST) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id gAG1CaD03753; Fri, 15 Nov 2002 17:12:36 -0800 (PST) Message-Id: <200211160112.gAG1CaD03753@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, sip@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 15 Nov 2002 17:12:36 -0800 Subject: [Sip] RFC 3420 on Internet Media Type message/sipfrag 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 Request for Comments is now available in online RFC libraries. RFC 3420 Title: Internet Media Type message/sipfrag Author(s): R. Sparks Status: Standards Track Date: November 2002 Mailbox: rsparks@dynamicsoft.com Pages: 8 Characters: 14745 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sip-sipfrag-00.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3420.txt This document registers the message/sipfrag Multipurpose Internet Mail Extensions (MIME) media type. This type is similar to message/sip, but allows certain subsets of well formed Session Initiation Protocol (SIP) messages to be represented instead of requiring a complete SIP message. In addition to end-to-end security uses, message/sipfrag is used with the REFER method to convey information about the status of a referenced request. This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <021115171105.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3420 --OtherAccess Content-Type: Message/External-body; name="rfc3420.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <021115171105.RFC@RFC-EDITOR.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 Sat Nov 16 13:06:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21688 for ; Sat, 16 Nov 2002 13:06:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAGI94j19581 for sip-archive@odin.ietf.org; Sat, 16 Nov 2002 13:09: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 gAGI6Nv18955; Sat, 16 Nov 2002 13:06: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 gAGHxqv18813 for ; Sat, 16 Nov 2002 12:59:52 -0500 Received: from mailserver.sylantro.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21563 for ; Sat, 16 Nov 2002 12:57:11 -0500 (EST) Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Sat, 16 Nov 2002 09:57:54 -0800 X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Received: by mailserver.sylantro.com with Internet Mail Service ( 5.5.2653.19) id ; Sat, 16 Nov 2002 09:57:54 -0800 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD093DE9@mailserver.sylantro.com> From: "Eric Nielsen" To: "'sip@ietf.org'" cc: "'stu.jacobs@verzion.com'" Date: Sat, 16 Nov 2002 09:57:53 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 11C858A832795-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] draft of broad requirements for VoIP security 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 draft draft-jacobs-signaling-security-requirements-00.txt http://www.ietf.org/internet-drafts/draft-jacobs-signaling-security-requirem ents-00.txt attempts to define the body of security requirements that must be dealt with in order to carrier-scale VoIP deployments. The requirements are generic, and are not written relative to specific threats. We wrote the draft at the suggestion of Jeff Schiller as a way to get the IETF community to identify what existing security mechanisms exist that can provide the type of authentication necessary for using SIP, MGCP and Megaco in real carrier type deployments. This was a direct result of our own pursuit a light-weight key distribution mechanism. A significant issue for this draft is that the requirements do not neatly fit into any one WG charter. I believe this is more of a security issue than an application level issue. However, the SIP WG has done more to deal with security than other application level WGs. Security it is an essential part of VoIP, and SIP already includes many of the needed features. Thus we are posting this note here. The goal of this draft is to get agreement on the broader requirements, followed by an determining what gaps there are between what exists and what is needed. Obviously if we could see a full solution, we would not be pursuing this. For example, common usage of current technology leads to poor practices in handling keying material. The technology must be defined so that it is possible to define simple and secure common practices. We would like to work to get agreement on the requirements, as well as how to best meet them. Thank you, Eric Nielsen Sylantro Systems Stuart Jacobs CISSP Verizon Laboratories _______________________________________________ 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 Nov 17 11:24:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20932 for ; Sun, 17 Nov 2002 11:24:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAHGR2I24770 for sip-archive@odin.ietf.org; Sun, 17 Nov 2002 11:27: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 gAHGOEv24701; Sun, 17 Nov 2002 11:24: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 gAHGILv24559 for ; Sun, 17 Nov 2002 11:18:21 -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 LAA20745 for ; Sun, 17 Nov 2002 11:15:39 -0500 (EST) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gAHGI5sA013830; Sun, 17 Nov 2002 08:18:05 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABH55340; Sun, 17 Nov 2002 08:15:50 -0800 (PST) Date: Sun, 17 Nov 2002 08:18:01 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-2--886860936 Mime-Version: 1.0 (Apple Message framework v548) Cc: "'sip@ietf.org'" To: "Sriram Parameswar" From: Rohan Mahy In-Reply-To: Message-Id: <248C82B4-FA48-11D6-9E73-0003938AF740@cisco.com> X-Mailer: Apple Mail (2.548) Subject: [Sip] Re: Comments :draft-ietf-sip-replaces-01.txt (Re-post) 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: , --Apple-Mail-2--886860936 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hello, I think I may have responded to this email already, but I don't see in=20= record of it in my archive. In case I did not, I'd like to apologize=20 for overlooking this message, and taking so long to respond to these=20 comments. thanks, -rohan On Monday, May 13, 2002, at 01:04 PM, Sriram Parameswar wrote: > Hi, > > I had sent these comments prior to the Las Vegas Ad-Hoc, have not seen=20= > any of discussion on this draft on the list. Just re-posting one more=20= > time. > > Regards, > > Sriram > > __________________________________________ > Sriram Parameswar=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Phone: = 972-685-8540 > Nortel Networks > > Rohan, > > Some comments: > > (1)Section 4.1 says "In other words the to-tag is compared to the=20 > local tag, and the from-tag is compared to the remote tag." However in=20= > section 5.2 INV/200 estalish from-tag (operator) =3D 7743 and to-tag=20= > (Call Center) =3D 6472. However the call from the customer to Call=20 > Center has=20 > Replaces:425928@dhcp23311.acme.com;to-tag=3D7743;from-tag=3D6472, thus = the=20 > Call Center will _not_ be able to match correctly based on sections=20 > 4.1 rule. (These rules are now in Section 3). This situation is a bit confusing,=20= but the example is correct. Since the rules above apply to the UAS, the=20= local tag from the perspective of the UAS is "7743" and the remote tag=20= is "6472". If you can think of a textual way to make this clearer,=20 please send me some proposed text. > (2) Section 5.2 the NOTIFY sent to from Customer to Operator when the=20= > Customer receives 182 (Queued). Then this transaction is BYE'd. Now we=20= > _cannot_ send another NOTIFY/200 from Customer to Operator as shown -=20= > it will result in a 481. > (3) Same for section 5.7 (and section 5.8) - once Bob gets a 687, he=20= > BYE's the call with Alice. Then at the bottom of call Flow, Alice=20 > tries to send a NOTIFY for the REFER, this will result in a 481. Your comment applies now to the example in Section 7.1. The BYE in=20 this example doesn't terminate the dialog started with INVITE. Since=20 the REFER created a subscription, the dialog doesn't end until both a=20 NOTIFY with Subscription-State: terminated, and a BYE have been=20 received. > (3) Section 5.8 Invite from Proxy (forking Alice) INVITE (2a) and (2b)=20= > goes to C1. I think INVITE (2b) should go to C2. These examples were removed for the sake of brevity. thankfully! > (4) Section 5.6, just for grins, how does Alice get the Replaces=20 > information to replace the dialog between Bob and Old Timer :). Bob might be a normal user agent that support the dialog package for=20 example. In any case, this example was likewise removed for the sake=20 of brevity. hope this helps. hopefully the examples in cc-transfer will make these=20= concepts clearer for everyone. thanks, -rohan > Thats what I have from my initial reading. > > Sriram > > __________________________________________ > Sriram Parameswar=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Phone: = 972-685-8540 > Interactive Multimedia Server (IMS) Fax: 972-684-3986 > Nortel Networks, Richardson USA=A0 Email: sriramp@nortelnetworks.com > --Apple-Mail-2--886860936 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, I think I may have responded to this email already, but I don't see in record of it in my archive. In case I did not, I'd like to apologize for overlooking this message, and taking so long to respond to these comments. thanks, -rohan On Monday, May 13, 2002, at 01:04 PM, Sriram Parameswar wrote: Hi, I had sent these comments prior to the Las Vegas Ad-Hoc, have not seen any of discussion on this draft on the list. Just re-posting one more time. Regards, Sriram __________________________________________ Sriram Parameswar=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Phone: = 972-685-8540 Nortel Networks Rohan, Some comments: (1)Section 4.1 says "In other words the to-tag is compared to the local tag, and the from-tag is compared to the remote tag." However in section 5.2 INV/200 estalish from-tag (operator) =3D 7743 and to-tag (Call Center) =3D 6472. However the call from the customer to Call Center has Replaces:425928@dhcp23311.acme.com;to-tag=3D7743;from-tag=3D6472, thus = the Call Center will _not_ be able to match correctly based on sections 4.1 rule. (These rules are now in Section 3). This situation is a bit confusing, but the example is correct. Since the rules above apply to the UAS, the local tag from the perspective of the UAS is "7743" and the remote tag is "6472". If you can think of a textual way to make this clearer, please send me some proposed text. (2) Section 5.2 the NOTIFY sent to from Customer to Operator when the Customer receives 182 (Queued). Then this transaction is BYE'd. Now we _cannot_ send another NOTIFY/200 from Customer to Operator as shown - it will result in a 481. (3) Same for section 5.7 (and section 5.8) - once Bob gets a 687, he BYE's the call with Alice. Then at the bottom of call Flow, Alice tries to send a NOTIFY for the REFER, this will result in a = 481. Your comment applies now to the example in Section 7.1. The BYE in this example doesn't terminate the dialog started with INVITE. Since the REFER created a subscription, the dialog doesn't end until both a NOTIFY with Subscription-State: terminated, and a BYE have been received. (3) Section 5.8 Invite from Proxy (forking Alice) INVITE (2a) and (2b) goes to C1. I think INVITE (2b) should go to = C2. These examples were removed for the sake of brevity. thankfully! (4) Section 5.6, just for grins, how does Alice get the Replaces information to replace the dialog between Bob and Old Timer :). Bob might be a normal user agent that support the dialog package for example. In any case, this example was likewise removed for the sake of brevity. hope this helps. hopefully the examples in cc-transfer will make these concepts clearer for everyone. thanks, -rohan Thats what I have from my initial reading. Sriram __________________________________________ Sriram Parameswar=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Phone: = 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-684-3986 Nortel Networks, Richardson USA=A0 Email: = sriramp@nortelnetworks.com = --Apple-Mail-2--886860936-- _______________________________________________ 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 Nov 17 11:58:58 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21642 for ; Sun, 17 Nov 2002 11:58:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAHH17Z26480 for sip-archive@odin.ietf.org; Sun, 17 Nov 2002 12:01: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 gAHGwTv26367; Sun, 17 Nov 2002 11:58: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 gAHGr2v26285 for ; Sun, 17 Nov 2002 11:53:02 -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 LAA21434 for ; Sun, 17 Nov 2002 11:50:22 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 17 Nov 2002 08:52:57 -0800 Received: from 212.143.185.30 by sea1fd.sea1.hotmail.msn.com with HTTP; Sun, 17 Nov 2002 16:52:57 GMT X-Originating-IP: [212.143.185.30] From: "Leonardo Rico" To: sip@ietf.org, simple@mailman.dynamicsoft.com Date: Sun, 17 Nov 2002 11:52:57 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Nov 2002 16:52:57.0933 (UTC) FILETIME=[C80D17D0:01C28E59] Subject: [Sip] Presence with PIDF format 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’m looking for a UA presence application that supports PIDF format. Preferable an open source or demo I can download. Any idea? Thanks, Leonardo _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus _______________________________________________ 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 Nov 17 13:58:26 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23406 for ; Sun, 17 Nov 2002 13:58:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAHJ0bM31393 for sip-archive@odin.ietf.org; Sun, 17 Nov 2002 14:00:37 -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 gAHIvov31272; Sun, 17 Nov 2002 13:57: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 gAHIqDv31176 for ; Sun, 17 Nov 2002 13:52:13 -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 NAA23304 for ; Sun, 17 Nov 2002 13:49:32 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAHIq4Q1024471; Sun, 17 Nov 2002 19:52:04 +0100 (MET) Received: from lmf.ericsson.se (vrrch2-177132.am.ericsson.se [138.85.177.132]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WWLFD4B2; Sun, 17 Nov 2002 19:52:03 +0100 Message-ID: <3DD7E556.C6DD7225@lmf.ericsson.se> Date: Sun, 17 Nov 2002 20:52:06 +0200 X-Sybari-Trust: 754b5f6f ca231590 df17dee1 00000138 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: David Oliver CC: "'Drage, Keith (Keith)'" , Jonathan Rosenberg , hisham.khartabil@nokia.com, chandan.rajah@wipro.com, sip@ietf.org Subject: Re: [Sip] The fate of session timer? References: <493BB8BDBB5AD511A7BB00104B62EE280105FF2B@jupiter> 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 Jonathan, I have just noticed that a method PING has been added to RTSP to test the aliveness of the other end point. It may be good to align our session timer with that work... 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 Sun Nov 17 16:00:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25252 for ; Sun, 17 Nov 2002 16:00:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAHL33u03965 for sip-archive@odin.ietf.org; Sun, 17 Nov 2002 16:03: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 gAHL00v03898; Sun, 17 Nov 2002 16:00: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 gAHKuwv03811 for ; Sun, 17 Nov 2002 15:56:58 -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 PAA25169 for ; Sun, 17 Nov 2002 15:54:15 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAHKumKV000141; Sun, 17 Nov 2002 21:56:48 +0100 (MET) Received: from lmf.ericsson.se (chzuwa01m07.eu.ericsson.se [164.48.166.7]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id gAHKuiCG005498; Sun, 17 Nov 2002 22:56:45 +0200 (EET) Message-ID: <3DD802C2.BE2D02A1@lmf.ericsson.se> Date: Sun, 17 Nov 2002 22:57:38 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: David Oliver , "'Drage, Keith (Keith)'" , Jonathan Rosenberg , hisham.khartabil@nokia.com, chandan.rajah@wipro.com, sip@ietf.org Subject: Re: [Sip] The fate of session timer? References: <493BB8BDBB5AD511A7BB00104B62EE280105FF2B@jupiter> <3DD7E556.C6DD7225@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 Hi, After reading all the messages (and having written half of them myself...) I would say we should split the whole discussion into four different parts: 1. What is the functional purpose of the session-timer? Can we agree that we only use if for cleaning of call state, or does someone still want to use if for state recover, "heartbeat", charing,....? 2. What method do we use for the re-fresh? re-INVITE, UPDATE, PING, INFO, insert-your-favorite-SIP-method, etc... My personal opinion is that the refresh should not be treated as an offer/answer transaction, assuming the functional requirement doesn't require it. 3. How do the nodes do the timer negoatiation? This is was most of my mails on the issue have been about... I have presented my concerns about the current mechanism, and presented an alternative. I know, however, that it has been discussed before, so I am aware there may be issues I haven't thought about. 4. What are different nodes supposed to do if they don't receive refreshes? Cleaning up call state, send BYE, etc etc... 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 Sun Nov 17 21:21:44 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29729 for ; Sun, 17 Nov 2002 21:21:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAI2NwW17506 for sip-archive@odin.ietf.org; Sun, 17 Nov 2002 21:23:58 -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 gAI2Kov17426; Sun, 17 Nov 2002 21:20: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 gAI20ov16286 for ; Sun, 17 Nov 2002 21:00:50 -0500 Received: from cypress.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29420; Sun, 17 Nov 2002 20:58:05 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by cypress.neustar.com (8.11.6/8.11.6) with ESMTP id gAI1xYc12237; Mon, 18 Nov 2002 01:59:34 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Sun, 17 Nov 2002 21:00:37 -0500 Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E38B30A@stntexch1.va.neustar.com> From: "Yu, James" To: orit@radvision.com Cc: mankin@psg.com, "'Scott Bradner'" , iptel@lists.bell-labs.com, sip@ietf.org, sipping@ietf.org Date: Sun, 17 Nov 2002 21:00:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: request for iptell to review "url" IDs 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: , Orit, The h323 url I-D currently does not define a parameter similar to "user=phone" in the sip url to indicate that a telephone number is in the user part of the h323 url. Suggest to add that in your I-D and clarify in the I-D that tel url information including its extensions can appear in the user part when a telephone number is present in the user part. James > -----Original Message----- > From: Scott Bradner [mailto:sob@harvard.edu] > Sent: Monday, October 28, 2002 9:25 AM > To: iptel@lists.bell-labs.com; sip@ietf.org; sipping@ietf.org > Cc: antti.vaha-sipila@nokia.com; james.yu@neustar.biz; mankin@psg.com; > orit@radvision.com; schulzrinne@cs.columbia.edu > Subject: request for iptell to review "url" IDs > > > > > msg from the TSV ADs > > we would like the iptel WG to take on the following 3 IDs > > draft-antti-rfc2806bis-05.txt > draft-yu-tel-url-06.txt > draft-levin-iptel-h323-url-scheme-04.txt > > we would like the WG to review the 3 IDs to be sure that they do not > conflict in the use of terminology or technology and to work > with the ID > authors to resolve any conflicts > > anyone with opinions about these IDs should join the iptel > list and discuss > the issues there > > we expect that this task will be a short term one and we can move to > getting these IDs published > > Scott & Allison > _______________________________________________ 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 Nov 17 22:57:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01619 for ; Sun, 17 Nov 2002 22:57:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAI40FC21423 for sip-archive@odin.ietf.org; Sun, 17 Nov 2002 23: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 gAI3v6v21334; Sun, 17 Nov 2002 22:57: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 gAI3rav21261 for ; Sun, 17 Nov 2002 22:53:36 -0500 Received: from snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01512 for ; Sun, 17 Nov 2002 22:50:49 -0500 (EST) Content-Class: urn:content-classes:message Subject: RE: [Sip] The fate of session timer? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 17 Nov 2002 22:53:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <4A3384433CE2AB46A63468CB207E209D55DC@zoe.office.snowshore.com> Thread-Topic: [Sip] The fate of session timer? thread-index: AcKMWe/Bi2xSd7oCQwSPtlowOxngrACIaXAQ From: "Eric Burger" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAI3rav21262 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 Prior to the session timer draft, we hacked keep alive mechanisms with application servers. The session timer draft allows us to have a single mechanism that works for everyone. Let's get this one done! > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Thursday, November 14, 2002 10:33 PM > To: Jonathan Rosenberg; sip@ietf.org > Subject: RE: [Sip] The fate of session timer? > > > > We all hope that SIP will allow us to build innovative > application. Many of > these application will be realized in proxies in the network. SIP has > several ways, using various tags, for these applications to > save all their > state out in the UAs. From a reliability and scalability > point of view this > puts the state in exactly the right place - it is fate shared > with the UAs > in the call. > > Session timers allows the applications to cause the various > timers that the > application needs to be executed on the UAs. This is > brilliant - it fate > shares the timers with the right thing and solves some > problems that have > always been tricky in doing high reliability applications. > > I think we should close the open issues in this draft and get > it to RFC. > > Cullen > > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > > Jonathan Rosenberg > > Sent: Monday, November 11, 2002 3:24 PM > > To: sip@ietf.org > > Subject: [Sip] The fate of session timer? > > > > > > Folks, > > > > As you may have noticed, I submitted an update to the session timer > > specification. This is an old, old spec that has been > around for quite > > some time. It receives only minimal attention these days. > The general > > comments on the list are generally 'too complex' and 'too hard to > > understand'. Some of that is wording, which I will continue > to work. The > > bigger problem, I think, is that its not at all clear what > problem this > > draft is REALLY solving. > > > > I assert that session timer is really useful for one thing, > which is to > > provide a means to cleanup old session state in UAs and proxies. > > Normally, you'd set a timer (on the order of 5 hours or > something) to > > discard any state thats still around. However, since a call > may actually > > last that long, you want a way to reliably know when you > can flush the > > state. > > > > Session timer is NOT useful for determining call durations > for billing > > purposes. > > > > Session timer is NOT useful for quickly determining that a UA has > > failed, in order to recover. It operates too slowly for that. > > > > So, given this somewhat-marginal value, the complexity > seems startingly > > high. I have begun to wonder whether that is the reason for > the troubles > > this specification is having. So, I see a few options: > > > > 1. No one cares about this spec. Discard it entirely. > > > > 2. Continue as it is, fix up some wording, and submit. > Probably no one > > implements it since it provides little value at high cost. > > > > 3. Change the scope. Eliminate or simplify negotiation of > the timer by > > defining a suitably long minimum. Eliminate or simplify choosing who > > refreshes by requiring that the UAC support the timer. And > so on. The > > result would be a much simpler spec. > > > > 4. others? > > > > > > Please provide comments, particularly if you are actively using this > > specification for some real problem. > > > > -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 > > > > _______________________________________________ > 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 Nov 18 00:25:27 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03120 for ; Mon, 18 Nov 2002 00:25:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAI5Rgc25342 for sip-archive@odin.ietf.org; Mon, 18 Nov 2002 00:27: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 gAI5Ogv25249; Mon, 18 Nov 2002 00:24: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 gAI5JQv25064 for ; Mon, 18 Nov 2002 00:19:26 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03014 for ; Mon, 18 Nov 2002 00:16:39 -0500 (EST) From: akkasam@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gAI5Ibr20351 for ; Mon, 18 Nov 2002 10:48:37 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gAI5IY820331; Mon, 18 Nov 2002 10:48:34 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id gAI5KDq27892; Mon, 18 Nov 2002 10:50:13 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256C75.001CA518 ; Mon, 18 Nov 2002 10:42:52 +0530 X-Lotus-FromDomain: HSSBLR@HSS To: "Leonardo Rico" cc: sip@ietf.org, simple@mailman.dynamicsoft.com Message-ID: <65256C75.001CA483.00@sandesh.hss.hns.com> Date: Mon, 18 Nov 2002 10:46:03 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Sip] Regarding SIPS 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 According to the RFC 3261, If the Request-URI contains a SIPS URI, or the topmost Route header field value (after the post processing of bullet 6) contains a SIPS URI, the URI placed into the Record-Route header field MUST be a SIPS URI. Furthermore, if the request was not received over TLS, the proxy MUST insert a Record-Route header field How can this scencario occur. how can it happen that request uri ( or top most route header) is sips and request receiving on other than TLS. Thanks in advance With Regds Ajay Kumar Kasam _______________________________________________ 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 Nov 18 00:43:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03413 for ; Mon, 18 Nov 2002 00:43:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAI5jP726313 for sip-archive@odin.ietf.org; Mon, 18 Nov 2002 00:45: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 gAI5gDv26266; Mon, 18 Nov 2002 00:42: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 gAI5dDv26171 for ; Mon, 18 Nov 2002 00:39:13 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03330 for ; Mon, 18 Nov 2002 00:36:26 -0500 (EST) From: akkasam@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gAI5cMr24559 for ; Mon, 18 Nov 2002 11:08:22 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gAI5cJ824527; Mon, 18 Nov 2002 11:08:20 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id gAI5dwu00046; Mon, 18 Nov 2002 11:09:58 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256C75.001E73B2 ; Mon, 18 Nov 2002 11:02:36 +0530 X-Lotus-FromDomain: HSSBLR@HSS To: akkasam@hss.hns.com cc: "Leonardo Rico" , sip@ietf.org, simple@mailman.dynamicsoft.com Message-ID: <65256C75.001E6FD5.00@sandesh.hss.hns.com> Date: Mon, 18 Nov 2002 11:05:38 +0530 Subject: Re: [Sip] Regarding SIPS 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 Here is one scenario where we can expect this to occur. Supposed sip: atlanta.com , sips: bilboxi.com be pre-configured route-set at ClientA and let sip:clientb@bilboxi.com be the request uri. Now when the request reaches atlanta.com, after processing route header, the top most route header will be sips, but is received the request on other than TLS. but why doubt is why it is MUST for atlanta.com to record-route. waiting for ur response. thanks in advance ajay kumar kasam _______________________________________________ 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 Nov 18 02:43:50 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15127 for ; Mon, 18 Nov 2002 02:43:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAI7k7x08093 for sip-archive@odin.ietf.org; Mon, 18 Nov 2002 02:46: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 gAI7h5v07990; Mon, 18 Nov 2002 02:43: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 gAI7d3v07874 for ; Mon, 18 Nov 2002 02:39:03 -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 CAA15076 for ; Mon, 18 Nov 2002 02:36:15 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.14]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAI7coYH002041; Mon, 18 Nov 2002 02:38:50 -0500 (EST) Message-ID: <3DD89908.6050205@dynamicsoft.com> Date: Mon, 18 Nov 2002 02:38:48 -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: Gonzalo Camarillo CC: David Oliver , "'Drage, Keith (Keith)'" , hisham.khartabil@nokia.com, chandan.rajah@wipro.com, sip@ietf.org Subject: Re: [Sip] The fate of session timer? References: <493BB8BDBB5AD511A7BB00104B62EE280105FF2B@jupiter> <3DD7E556.C6DD7225@lmf.ericsson.se> 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 Ah, yet another case of deviation between RTSP and SIP, all for no reason. Grr. So, are you saying you propose that we adopt a new PING method for doing this in SIP? -Jonathan R. Gonzalo Camarillo wrote: > Jonathan, > > I have just noticed that a method PING has been added to RTSP to test > the aliveness of the other end point. It may be good to align our > session timer with that work... > > Gonzalo > -- 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 Mon Nov 18 02:47:46 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15198 for ; Mon, 18 Nov 2002 02:47:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAI7o3L08200 for sip-archive@odin.ietf.org; Mon, 18 Nov 2002 02:50: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 gAI7l1v08116; Mon, 18 Nov 2002 02:47: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 gAI7dLv07889 for ; Mon, 18 Nov 2002 02:39:21 -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 CAA15080 for ; Mon, 18 Nov 2002 02:36:34 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.14]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAI7dBYH002044; Mon, 18 Nov 2002 02:39:11 -0500 (EST) Message-ID: <3DD8991D.5000905@dynamicsoft.com> Date: Mon, 18 Nov 2002 02:39:09 -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: Christer Holmberg CC: Arunachalam Venkatraman , sip@ietf.org Subject: Re: [Sip] The fate of session timer? References: <3DD3B930.E6230AC3@lmf.ericsson.se> 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 Christer Holmberg wrote: > Hi, > > >>Christer >>That is not true. Another UPDATE may neither be received nor sent (491/500 >>with Retry after rules) when an UPDATE has been sent/received. > > > If that is the case I don't want to use UPDATE :) To my understanding the > current functionality of the session-timer has nothing to do with the > offer/answer mechanism, so I see no reason why it should "block" other possible > offer/answer transactions. Please read the specifications carefully. RFC 3311 only forbids sending an UPDATE with an offer while there is another offer outstanding. Thus, if you have sent an UPDATE without an offer, the specification does not prohibit you from sending another before it completes. However, I would generally recommend against such overlapping of UPDATES, as it is a recipe for trouble. Venkat had a specific complaint I want to address: > Whenever we overload one request to do disparate functions, we have a source > of confusion, race conditions etc. > For example, although the likelihood of such an intersection is relatively > small, it is possible that an offer/answer exchange is required at the time > a session timer refresh is in progress using UPDATE (or INVITE). This > required extra logic in the implementation to sequence these and is an > overhead for a remote corner case. This is a bogus issue. You need to have centralized coordination of sending/receiving requests in order to do proper cseq maintenance, remote target URI maintenance, etc. So, this function is already there. Further, the rules about crossing > UPDATEs/INVITEs resulting in 491 have to be handled even though it would > seem to make perfect sense to be able to accept an UPDATE without SDP (sent > for session refresh) while an UPDATE with SDP has been sent out by the UA. As I mention above, this is technically allowed although it makes me nervous. UPDATE can, in the future, affect other pieces of state, and thus we may run into other problems. -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 Mon Nov 18 02:51:44 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15270 for ; Mon, 18 Nov 2002 02:51:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAI7s0W08310 for sip-archive@odin.ietf.org; Mon, 18 Nov 2002 02:54: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 gAI7owv08249; Mon, 18 Nov 2002 02:50: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 gAI7mDv08155 for ; Mon, 18 Nov 2002 02:48:13 -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 CAA15167 for ; Mon, 18 Nov 2002 02:45:25 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.14]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAI7m2YH002048; Mon, 18 Nov 2002 02:48:03 -0500 (EST) Message-ID: <3DD89B30.9010709@dynamicsoft.com> Date: Mon, 18 Nov 2002 02:48:00 -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: Christer Holmberg CC: sip@ietf.org Subject: Re: [Sip] The fate of session timer? References: <3DD3B930.E6230AC3@lmf.ericsson.se> <3DD4A760.BD1FF3C3@lmf.ericsson.se> 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. Christer Holmberg wrote: > Hi, > > I have one question about the session-timer. This has probably been > discussed before, but I'd still like to bring it up. > > Currently the spec says that a proxy not supporting the proposed > refresh timer value will send a 422 response, and after that the UAC > will have to send a new INVITE, with a higher timer value. > > Now, in a forking environment there is a chance that 422 responses > will be received from proxies in legs which may never be part of the > session, and the UAC will have to send a new INVITE, and rise the > value because of proxes which may never be part of the session... This is why the session timer spec has the UA "clear" the min-expires value when the dialog is established. I > guess the forking proxy may not even always forward the 422 to the > UAC, while waiting for other final responses, so the UAS on that leg > may never get a chance to participate in the call in the first place, > since the end-user may never receive the INVITE (a proxy will return > 422). This may happen, yes. > > So, my question is: if a value is too small for a proxy, what is the > reason it simply can't change the value and forward the INVITE? In > that case the INVITE will receive the UAS, and the final response > will indicate the refresh value which will actually be used. There are two reasons. The first is documented in the security considerations section: > Next, consider the case of a rogue UAS that wishes to force a UAC to > generate refreshes at a rapid rate. In that case, the UAC has to > support session timer. The initial INVITE arrives at the rogue UAS, > which returns a 2xx with a very small session interval. The UAC uses > this timer, and quickly sends a refresh. Section 7.1 requires the UAC > to copy the current session interval into the Session-Expires header > field in the request. This enables the proxies to see the current > value. The proxies will reject this request, and provide a Min-SE > with a higher minimum. The UAC will then use this higher minimum. > Note, that if the proxies did not reject the request, but rather > proxied the request with a Min-SE header field, an attack would still > be possible. The UAS could discard this header field in a 2xx > response, and force the UAC to continue to generate rapid requests. So, the change you suggest would introduce a dos attack that a rogue UAS could launch on a UAC. The second reason was that one property we wanted to maintain was that the session refresh interval was at least as small as the smallest requested value, so long as that wasn't below someones configured minimum. Your suggested change would allow a single proxy to increase the timer to an arbitrary value, breaking this requirement. -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 Mon Nov 18 07:46:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19277 for ; Mon, 18 Nov 2002 07:46:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAICmTa20811 for sip-archive@odin.ietf.org; Mon, 18 Nov 2002 07:48:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAICjHv20692; Mon, 18 Nov 2002 07:45: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 gAICXgv19843 for ; Mon, 18 Nov 2002 07:33:42 -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 HAA19049 for ; Mon, 18 Nov 2002 07:31:03 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAICXYKV008081; Mon, 18 Nov 2002 13:33:38 +0100 (MET) Received: from lmf.ericsson.se (vrrch2-177130.am.ericsson.se [138.85.177.130]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id gAICXVCG018488; Mon, 18 Nov 2002 14:33:32 +0200 (EET) Message-ID: <3DD8DE55.34DF9786@lmf.ericsson.se> Date: Mon, 18 Nov 2002 14:34:29 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] The fate of session timer? References: <3DD3B930.E6230AC3@lmf.ericsson.se> <3DD4A760.BD1FF3C3@lmf.ericsson.se> <3DD89B30.9010709@dynamicsoft.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 Hi, > >Hi, > > > >I have one question about the session-timer. This has probably been > >discussed before, but I'd still like to bring it up. > > > >Currently the spec says that a proxy not supporting the proposed > >refresh timer value will send a 422 response, and after that the UAC > >will have to send a new INVITE, with a higher timer value. > > > >Now, in a forking environment there is a chance that 422 responses > >will be received from proxies in legs which may never be part of the > >session, and the UAC will have to send a new INVITE, and rise the > >value because of proxes which may never be part of the session... > > This is why the session timer spec has the UA "clear" the min-expires > value when the dialog is established. > > I > >guess the forking proxy may not even always forward the 422 to the > >UAC, while waiting for other final responses, so the UAS on that leg > >may never get a chance to participate in the call in the first place, > >since the end-user may never receive the INVITE (a proxy will return > >422). > > This may happen, yes. And that is not good. > >So, my question is: if a value is too small for a proxy, what is the > >reason it simply can't change the value and forward the INVITE? In > >that case the INVITE will receive the UAS, and the final response > >will indicate the refresh value which will actually be used. > > There are two reasons. > > The first is documented in the security considerations section: > > >Next, consider the case of a rogue UAS that wishes to force a UAC to > >generate refreshes at a rapid rate. In that case, the UAC has to > >support session timer. The initial INVITE arrives at the rogue UAS, > >which returns a 2xx with a very small session interval. The UAC uses > >this timer, and quickly sends a refresh. Section 7.1 requires the UAC > >to copy the current session interval into the Session-Expires header > >field in the request. This enables the proxies to see the current > >value. The proxies will reject this request, and provide a Min-SE > >with a higher minimum. The UAC will then use this higher minimum. > >Note, that if the proxies did not reject the request, but rather > >proxied the request with a Min-SE header field, an attack would still > >be possible. The UAS could discard this header field in a 2xx > >response, and force the UAC to continue to generate rapid requests. > > So, the change you suggest would introduce a dos attack that a rogue UAS > could launch on a UAC. The UAC would include a minimum value in the request, which proxies are only allowed to INCREASE, if needed. If the UAC then receives 200 OK with a SMALLER value it knows something went wrong, so it would probably choose to release the call. Every proxy, when receiving the 200 response, would also see that something has gone wrong, since the value is smaller than the value set in the INVITE request. > The second reason was that one property we wanted to maintain was that > the session refresh interval was at least as small as the smallest > requested value, so long as that wasn't below someones configured > minimum. Your suggested change would allow a single proxy to increase > the timer to an arbitrary value, breaking this requirement. That is true, but again the UAC (or UAS) would still be able to terminate the call if this happens. But, at least the UAS would get a chance to participate in the call. I also think I mentioned a max value header earlier, which could be used by the UAC to make sure the value won't get too big. Of course, that value would have to be big enough to make sure any "reasonably" configured proxy would accept it. Or, a proxy would be allow to update this value also - in either direction - and if the value gets too big the UAC can choose to release the call. 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 Mon Nov 18 07:54:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19617 for ; Mon, 18 Nov 2002 07:54:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAICv2j21153 for sip-archive@odin.ietf.org; Mon, 18 Nov 2002 07:57: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 gAICsIv21016; Mon, 18 Nov 2002 07:54: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 gAICpPv20913 for ; Mon, 18 Nov 2002 07:51:25 -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 HAA19377 for ; Mon, 18 Nov 2002 07:48:46 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAICpMQ1019168; Mon, 18 Nov 2002 13:51:22 +0100 (MET) Received: from lmf.ericsson.se (vrrch1-177026.am.ericsson.se [138.85.177.26]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WWL2ZDDS; Mon, 18 Nov 2002 13:51:20 +0100 Message-ID: <3DD8E257.8B785762@lmf.ericsson.se> Date: Mon, 18 Nov 2002 14:51:35 +0200 X-Sybari-Trust: 0a749b5d ca231590 df17dee1 00000138 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: David Oliver , "'Drage, Keith (Keith)'" , hisham.khartabil@nokia.com, chandan.rajah@wipro.com, sip@ietf.org Subject: Re: [Sip] The fate of session timer? References: <493BB8BDBB5AD511A7BB00104B62EE280105FF2B@jupiter> <3DD7E556.C6DD7225@lmf.ericsson.se> <3DD89908.6050205@dynamicsoft.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 Jonathan, Jonathan Rosenberg wrote: > > Ah, yet another case of deviation between RTSP and SIP, all for no > reason. Grr. Yes, that's exactly what I thought yesterday when I discovered it: Grrrr! > So, are you saying you propose that we adopt a new PING method for doing > this in SIP? Since the entities involved in session timer have to support session timer, it would be alright to use a new method which would be specific to this extension. PING would be a good choice. In any event, I believe that having RTSP and SIP aligned on this issue is a good thing. FYI: this is the definition of the PING method in RTSP: 10.12 PING This method is a bi-directional mechanism for server or client live- ness checking. It has no side effects. The issuer of the request MUST include a session header with the session ID of the session that is being checked for liveness. http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-02.txt 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 Mon Nov 18 09:15:55 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21508 for ; Mon, 18 Nov 2002 09:15:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAIEI4k26420 for sip-archive@odin.ietf.org; Mon, 18 Nov 2002 09:18: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 gAIEElv26332; Mon, 18 Nov 2002 09:14: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 gAIEB5v26271 for ; Mon, 18 Nov 2002 09:11:05 -0500 Received: from sm212.163.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21385 for ; Mon, 18 Nov 2002 09:08:18 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by sm212.163.com (Postfix) with SMTP id 5F49D1C707721 for ; Mon, 18 Nov 2002 22:10:40 +0800 (CST) Received: from danfo (unknown [218.17.230.213]) by 192.168.1.212 (Coremail) with SMTP id rGsAAN/02D01AubV.1 for ; Mon, 18 Nov 2002 22:10:40 +0800 (CST) Message-ID: <001c01c28f0b$d27bdbe0$8500a8c0@danfo> From: "tenwater" To: References: <20021117170001.26396.60343.Mailman@www1.ietf.org> Date: Mon, 18 Nov 2002 21:20:41 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id gAIEB5v26272 Subject: [Sip] Termination of SUBSCRIPTION 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 Hello, All I have some doubt on the RFC3265, anybody can give me some advise. 1. receive fail response of refresh SUBSCRIBE request RFC3265 P9 wrote: ======================================================================== If a SUBSCRIBE request to refresh a subscription fails with a non-481 response, the original subscription is still considered valid for the duration of the most recently known "Expires" value as negotiated by SUBSCRIBE and its response, or as communicated by NOTIFY in the "Subscription-State" header "expires" parameter. ======================================================================== A. if this means Subscriber will not retry the refresh SUBSCRIBE request even if the response is 401 or 407 or 423? B. after the time indicated by "Expires" elapsed, Subscriber will send a SUBSCRIBE(expires=0) or not? If not, CSF proxy itself have to start a timer as "Expires", else CSF proxy cannot know when a Subscription terminated. 2. receive fail response of NOTIFY request after receive a response which cannot retry, Notifier will terminate the subscription as per P14 of RFC3265, so the same problem can occur as 1.B in CSF proxy. For a session defined in RFC3261, they always send BYE to terminate a established session, why the subscription can be terminated silently? If a subscription timer will be defined as session timer? Regards, TenWater ------------------------------------------------- This is a active spring.----------------------------------------- _______________________________________________ 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 Nov 18 09:19:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21658 for ; Mon, 18 Nov 2002 09:19:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAIEM0Z26673 for sip-archive@odin.ietf.org; Mon, 18 Nov 2002 09:22: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 gAIEIwv26474; Mon, 18 Nov 2002 09:18: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 gAIEB0v26247 for ; Mon, 18 Nov 2002 09:11:00 -0500 Received: from sm212.163.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21384 for ; Mon, 18 Nov 2002 09:08:18 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by sm212.163.com (Postfix) with SMTP id 2240D1C60EE7C for ; Mon, 18 Nov 2002 22:10:41 +0800 (CST) Received: from danfo (unknown [218.17.230.213]) by 192.168.1.212 (Coremail) with SMTP id rGsAAN/02D01AubV.3 for ; Mon, 18 Nov 2002 22:10:41 +0800 (CST) Message-ID: <001d01c28f0b$d2e23ed0$8500a8c0@danfo> From: "tenwater" To: References: <20021117170001.26396.60343.Mailman@www1.ietf.org> Date: Mon, 18 Nov 2002 21:48:50 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id gAIEB1v26248 Subject: [Sip] gap between two request in same Call-ID outside of 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: 8bit Hello, all Before UAC receive a non-100(18x or final response) or timeout of a request, UAC can send another request(non-INVITE and non-CANCEL) in same Call-ID or not? for example and just a assumption, UAC send a OPTIONS but no response received, UAC send another OPTIONS within the same Call-ID. anybody can give some suggestion. thanks. Tenwater. _______________________________________________ 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 Nov 18 10:21:15 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23306 for ; Mon, 18 Nov 2002 10:21:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAIFNPU30423 for sip-archive@odin.ietf.org; Mon, 18 Nov 2002 10:23: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 gAIFKvv30332; Mon, 18 Nov 2002 10:20: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 gAIFFsv30127 for ; Mon, 18 Nov 2002 10:15:54 -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 KAA23103 for ; Mon, 18 Nov 2002 10:13:14 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.85]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAIFFiYH002549; Mon, 18 Nov 2002 10:15:45 -0500 (EST) Message-ID: <3DD9041E.4000802@dynamicsoft.com> Date: Mon, 18 Nov 2002 10:15: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: akkasam@hss.hns.com CC: Leonardo Rico , sip@ietf.org Subject: Re: [Sip] Regarding SIPS References: <65256C75.001CA483.00@sandesh.hss.hns.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. akkasam@hss.hns.com wrote: > > Hi > > According to the RFC 3261, > > If the Request-URI contains a SIPS URI, or the topmost Route header > field value (after the post processing of bullet 6) contains a > SIPS URI, the URI placed into the Record-Route header field > MUST be a SIPS URI. Furthermore, if the request was not > received over TLS, the proxy MUST insert a Record-Route header > field > > > How can this scencario occur. Remember, this is a proxy. A request arrives without any sips URIs anywhere. It comes in over UDP. Now, the proxy runs its translation service, and finds that it needs to proxy the request to a sips URI. An example where this can happen is if I do a REGISTER like this: REGISTER sip:domain.com SIP/2.0 To: sip:user@domain.com Contact: sips:1.2.3.4 -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 Mon Nov 18 10:28:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23548 for ; Mon, 18 Nov 2002 10:28:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAIFUZw30706 for sip-archive@odin.ietf.org; Mon, 18 Nov 2002 10:30: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 gAIFSBv30595; Mon, 18 Nov 2002 10:28: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 gAIFMtv30394 for ; Mon, 18 Nov 2002 10:22:55 -0500 Received: from radvpost.RADVISION.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23262; Mon, 18 Nov 2002 10:20:15 -0500 (EST) Received: by radvpost.radvision.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Nov 2002 10:23:00 -0500 Message-ID: From: Orit Levin To: "'Yu, James'" Cc: mankin@psg.com, "'Scott Bradner'" , iptel@lists.bell-labs.com, sip@ietf.org, sipping@ietf.org Date: Mon, 18 Nov 2002 10:22:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Sip] RE: request for iptell to review "url" IDs 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, Actually the exact "user" parameter appears in the H.323 Annex O which defines this and other parameters to H.323 URL. This Annex O is pending approval by the ITU-T because the telephone-URI (which it is dependant upon) hasn't been finalized yet within the IETF. I will present at my ENUM presentation today this "standardization dependencies" graph... BR, Orit Levin Chief Architect RADVISION Phone: +1.201.6896330 Video: +1.201.6896430 > -----Original Message----- > From: Yu, James [mailto:james.yu@neustar.biz] > Sent: Sunday, November 17, 2002 9:01 PM > To: orit@radvision.com > Cc: mankin@psg.com; 'Scott Bradner'; iptel@lists.bell-labs.com; > sip@ietf.org; sipping@ietf.org > Subject: RE: request for iptell to review "url" IDs > > Orit, > > The h323 url I-D currently does not define a parameter similar to > "user=phone" in the sip url to indicate that a telephone number is in the > user part of the h323 url. Suggest to add that in your I-D and clarify in > the I-D that tel url information including its extensions can appear in > the > user part when a telephone number is present in the user part. > > James > > > -----Original Message----- > > From: Scott Bradner [mailto:sob@harvard.edu] > > Sent: Monday, October 28, 2002 9:25 AM > > To: iptel@lists.bell-labs.com; sip@ietf.org; sipping@ietf.org > > Cc: antti.vaha-sipila@nokia.com; james.yu@neustar.biz; mankin@psg.com; > > orit@radvision.com; schulzrinne@cs.columbia.edu > > Subject: request for iptell to review "url" IDs > > > > > > > > > > msg from the TSV ADs > > > > we would like the iptel WG to take on the following 3 IDs > > > > draft-antti-rfc2806bis-05.txt > > draft-yu-tel-url-06.txt > > draft-levin-iptel-h323-url-scheme-04.txt > > > > we would like the WG to review the 3 IDs to be sure that they do not > > conflict in the use of terminology or technology and to work > > with the ID > > authors to resolve any conflicts > > > > anyone with opinions about these IDs should join the iptel > > list and discuss > > the issues there > > > > we expect that this task will be a short term one and we can move to > > getting these IDs published > > > > Scott & Allison > > _______________________________________________ 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 Nov 18 11:23:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25602 for ; Mon, 18 Nov 2002 11:23:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAIGPUG02203 for sip-archive@odin.ietf.org; Mon, 18 Nov 2002 11:25: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 gAIGN3v02112; Mon, 18 Nov 2002 11:23: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 gAIGHKv01876 for ; Mon, 18 Nov 2002 11:17:20 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25348 for ; Mon, 18 Nov 2002 11:14:34 -0500 (EST) From: akkasam@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gAIGGUr03920 for ; Mon, 18 Nov 2002 21:46:31 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gAIGGS803915; Mon, 18 Nov 2002 21:46:28 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id gAIGI9B15811; Mon, 18 Nov 2002 21:48:09 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256C75.0058E1B7 ; Mon, 18 Nov 2002 21:40:49 +0530 X-Lotus-FromDomain: HSSBLR@HSS To: Jonathan Rosenberg cc: Leonardo Rico , sip@ietf.org Message-ID: <65256C75.0058E0C6.00@sandesh.hss.hns.com> Date: Mon, 18 Nov 2002 21:43:57 +0530 Subject: Re: [Sip] Regarding SIPS 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 Thanks a lot for the response. I would love to know the reason for making the record-routing mandatory in the discussed scenerio. If the Request-URI contains a SIPS URI, or the topmost Route header field value (after the post processing of bullet 6) contains a SIPS URI, the URI placed into the Record-Route header field MUST be a SIPS URI. Furthermore, if the request was not received over TLS, the proxy MUST insert a Record-Route header field With Regards Ajay Kumar Jonathan Rosenberg on 11/18/2002 08:45:42 PM To: Ajay Kumar Kasam/HSSBLR@HSSBLR cc: Leonardo Rico , sip@ietf.org Subject: Re: [Sip] Regarding SIPS inline. akkasam@hss.hns.com wrote: > > Hi > > According to the RFC 3261, > > If the Request-URI contains a SIPS URI, or the topmost Route header > field value (after the post processing of bullet 6) contains a > SIPS URI, the URI placed into the Record-Route header field > MUST be a SIPS URI. Furthermore, if the request was not > received over TLS, the proxy MUST insert a Record-Route header > field > > > How can this scencario occur. Remember, this is a proxy. A request arrives without any sips URIs anywhere. It comes in over UDP. Now, the proxy runs its translation service, and finds that it needs to proxy the request to a sips URI. An example where this can happen is if I do a REGISTER like this: REGISTER sip:domain.com SIP/2.0 To: sip:user@domain.com Contact: sips:1.2.3.4 -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 _______________________________________________ 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 Nov 18 13:13:14 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28630 for ; Mon, 18 Nov 2002 13:13:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAIIFOn08771 for sip-archive@odin.ietf.org; Mon, 18 Nov 2002 13:15: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 gAIICWv08619; Mon, 18 Nov 2002 13:12: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 gAII5Iv07795 for ; Mon, 18 Nov 2002 13:05:18 -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 NAA28348 for ; Mon, 18 Nov 2002 13:02:36 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAII5wB01410 for ; Mon, 18 Nov 2002 20:05:58 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 18 Nov 2002 20:05:10 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 18 Nov 2002 20:05:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] The fate of session timer? Date: Mon, 18 Nov 2002 20:05:08 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE6FD3@esebe019.ntc.nokia.com> Thread-Topic: [Sip] The fate of session timer? Thread-Index: AcKPAfYneb1gO8X+QYm81Re9ZI/ieAAKo/ew To: , Cc: , , , X-OriginalArrivalTime: 18 Nov 2002 18:05:09.0330 (UTC) FILETIME=[082D9320:01C28F2D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAII5Iv07796 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 sounds like a good idea, but we have to be careful: PING in RTSP is used to check liveliness of the entity. We want to check liveliness of a session. So, if we use PING, we need to allow it only as a request inside dialogs. Otherwise we will run into privacy issues with presence. Regards, Hisham > -----Original Message----- > From: ext Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Monday, November 18, 2002 2:52 PM > To: Jonathan Rosenberg > Cc: David Oliver; 'Drage, Keith (Keith)'; Khartabil Hisham > (NMP/Helsinki); chandan.rajah@wipro.com; sip@ietf.org > Subject: Re: [Sip] The fate of session timer? > > > Jonathan, > > Jonathan Rosenberg wrote: > > > > Ah, yet another case of deviation between RTSP and SIP, all for no > > reason. Grr. > > Yes, that's exactly what I thought yesterday when I discovered it: > Grrrr! > > > So, are you saying you propose that we adopt a new PING > method for doing > > this in SIP? > > Since the entities involved in session timer have to support session > timer, it would be alright to use a new method which would be specific > to this extension. PING would be a good choice. > > In any event, I believe that having RTSP and SIP aligned on this issue > is a good thing. > > FYI: this is the definition of the PING method in RTSP: > > 10.12 PING > > This method is a bi-directional mechanism for server or > client live- > ness checking. It has no side effects. The issuer of the > request MUST > include a session header with the session ID of the > session that is > being checked for liveness. > > > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326b is-02.txt 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 Mon Nov 18 13:42:36 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29540 for ; Mon, 18 Nov 2002 13:42:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAIIik410511 for sip-archive@odin.ietf.org; Mon, 18 Nov 2002 13:44: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 gAIIg9v10445; Mon, 18 Nov 2002 13:42: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 gAIIa3v09620 for ; Mon, 18 Nov 2002 13:36:03 -0500 Received: from web40108.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29318 for ; Mon, 18 Nov 2002 13:33:21 -0500 (EST) Message-ID: <20021118183553.49539.qmail@web40108.mail.yahoo.com> Received: from [152.15.14.64] by web40108.mail.yahoo.com via HTTP; Mon, 18 Nov 2002 10:35:53 PST Date: Mon, 18 Nov 2002 10:35:53 -0800 (PST) From: atish shah To: sip@ietf.org In-Reply-To: <20021118170001.4050.18119.Mailman@www1.ietf.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-800836170-1037644553=:48048" Subject: [Sip] Regarding the simulation scenario for SIP extension 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: , --0-800836170-1037644553=:48048 Content-Type: text/plain; charset=us-ascii Hi All, This is Atish Shah, doing my MS in Computer Science at University Of North Carolina, Charlotte. As part of the curriculum, myself and my friends are working on Extension to the SIP for Symmetric Response Routing which has been proposed in september '02. I would like to know if there are any libraries available which can be used to implement the above scenario. we are using Javasim as a simulation tool for this. so, what can we do for this? Thanking in advance With Regards, Atish Shah. --------------------------------- Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site --0-800836170-1037644553=:48048 Content-Type: text/html; charset=us-ascii

Hi All,

This is Atish Shah, doing my MS in Computer Science at University Of North Carolina, Charlotte. As part of the curriculum, myself and my friends are working on Extension to the SIP for Symmetric Response Routing which has been proposed in september '02.

I would like to know if there are any libraries available which can be used to implement the above scenario. we are using Javasim as a simulation tool for this.

so, what can we do for this?

Thanking in advance

With Regards,

Atish Shah.


Do you Yahoo!?
Yahoo! Web Hosting - Let the expert host your site --0-800836170-1037644553=:48048-- _______________________________________________ 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 Nov 18 17:42:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06312 for ; Mon, 18 Nov 2002 17:42:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAIMiJb25434 for sip-archive@odin.ietf.org; Mon, 18 Nov 2002 17:44:19 -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 gAIMfwv25297; Mon, 18 Nov 2002 17:41: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 gAIMWkv24384 for ; Mon, 18 Nov 2002 17:32:46 -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 RAA06028; Mon, 18 Nov 2002 17:30:01 -0500 (EST) Received: from jku07.iptel.org (jku07.ietf55.ops.ietf.org [204.42.69.230]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id gAIMWXn08613; Mon, 18 Nov 2002 23:32:33 +0100 Message-Id: <5.1.0.14.0.20021118233101.00b66d70@iptel.org> X-Sender: jiri@iptel.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 18 Nov 2002 23:31:41 +0100 To: sip@ietf.org, sipping@ietf.org From: Jiri Kuthan Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Sip] Fwd: text conferencing at the 55th IETF meeting in Atlanta 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 those, who would like to use SIP for text conferencing, >experimental operation of a SIP2Jabber gateway has been set up at >iptel.org. See http://www.iptel.org/ietf55/ for guidelines how >to join the IETF chat rooms. > >Better set your expectations low -- the gateway has not been tested >with bigger user populations until now. > >-Jiri > >At 03:11 PM 11/18/2002, Marshall Rose wrote: >> Remote Access for the 55th IETF meeting in Atlanta: >> Text Conferencing >> >>At each IETF meeting, two of the working group meeting rooms are equipped >>for video multicast and remote participation. That is, for every IETF >>meeting slot, two of the working groups can see and hear the >>meeting. For the 55th IETF, in *addition* to the usual network A/V, text >>conferencing will be provided for every working group that meets. >> >>All of the conference rooms are hosted on >> >> conference.ietf.jabber.com >> >>and each is named using the official IETF abbreviation found in the >>agenda (e.g., "apparea", "dhc", "forces", and so on -- for all the >>examples that follow, we'll use "foobar" as the abbreviation). >> >>Each conference room also has a 'bot which records everything that gets >>sent: >> >> http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/foobar/ >> >>Enjoy! >> >>/mtr _______________________________________________ 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 Nov 18 20:55:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10665 for ; Mon, 18 Nov 2002 20:55:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJ1vNY03287 for sip-archive@odin.ietf.org; Mon, 18 Nov 2002 20:57: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 gAJ1sqv03181; Mon, 18 Nov 2002 20: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 gAJ1pwv03053 for ; Mon, 18 Nov 2002 20:51:58 -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 UAA10605 for ; Mon, 18 Nov 2002 20:49:12 -0500 (EST) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id gAJ1pnQs024312 for ; Mon, 18 Nov 2002 19:51:50 -0600 From: "Dean Willis" To: Date: Mon, 18 Nov 2002 19:51:47 -0600 Message-ID: <002301c28f6e$38f96c40$63442acc@TXDWILLIS2> 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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Subject: [Sip] Jabber text conference for SIP WG meeting at IETF 55 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 We're experimentally running a chat room for the remote participants at IETF 55. The Chat Room Coordinator will bring questions raised in the chat room to the microphone during the discussions. I believe Eric Cheung [cheung@research.att.com] has volunteered to act as a chat room coordinator. Go Eric! The Jabber conference info according to Marshall is: Group/Room: sip Server: conference.ietf.jabber.com We MAY have a SIMPLE--Jabber gateway running -- we hope to try it out tonight with the chat room. More on that later, if it works for us. -- 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 Tue Nov 19 01:10:31 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16685 for ; Tue, 19 Nov 2002 01:10:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJ6Clq17351 for sip-archive@odin.ietf.org; Tue, 19 Nov 2002 01:12: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 gAJ6AOv17311; Tue, 19 Nov 2002 01:10: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 gAJ662v16624 for ; Tue, 19 Nov 2002 01:06:02 -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 BAA16606 for ; Tue, 19 Nov 2002 01:03:16 -0500 (EST) Received: from sponge.cisco.com (IDENT:mirapoint@sponge.cisco.com [64.101.128.87]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gAJ65q5V021355; Mon, 18 Nov 2002 22:05:52 -0800 (PST) Received: from ARUNVENKW2K1 (sjc-vpn3-928.cisco.com [10.21.67.160]) by sponge.cisco.com (Mirapoint) with SMTP id ABY02110; Tue, 19 Nov 2002 00:05:51 -0600 (CST) From: "Arunachalam Venkatraman" To: "Rohan Mahy" Cc: Date: Tue, 19 Nov 2002 00:08:25 -0600 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 V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Sip] Comments :draft-ietf-sip-replaces-02.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: 7bit Rohan I have a few comments on this draft. 1. Section 3 - If the Replaces header field matches more than one dialog, the UA must act s if no match is found. When is this possible? Since dialog id is made up of 3 globally unique items, how can this occur? Is this statement inserted for completeness or is there such a possibility in SIP compliant User Agents? 2. Section 3 - If the Replaces header field matches a dialog which has already terminated, the UA SHOULD decline the request with a 603 Declined response. Since the purpose of the Replaces header is to replace a call so that the user agent may accept a new call, it seems somewhat at cross-purposes to decline the incoming call when the call to be replaced has terminated. Of course, without this rule, it would be impossible to ensure that only the user agent which has the call replaces it and not a different user agent in another tine of the fork. But this imposes the rule that the user agent in a consultation hold must stay on hold until the referred call arrives, to ensure the transfer is successful. This is not a bad thing but I would appreciate an affirmation that I have understood this correctly. It may not hurt to discuss this for the benefit of others who may face a similar doubt. 3. I am a little puzzled in the differentiation between the case of "match not found" and "dialog terminated". When a dialog is terminated, the state for that dialog will be uninstalled and so it will not be found to be matched with a Replaces header. So, is this intended to cover the case where a dialog survives a BYE because a subscription is pending (like, from an implicit Refer)? 4. Section 7.1 I think the Replaces header in Message *3 is incorrect and has the tags reversed. Since the Call Center plays the role of a UAS in both contexts, the Replaces header must have its local tag (To-tag 6472 from the first call), specified as the To-tag in the Replaces header of the second call. 5. Since the draft has expired, when is the next revision coming? Thanks, Venkat _______________________________________________ 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 Nov 19 08:15:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04223 for ; Tue, 19 Nov 2002 08:15:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJDHoV16152 for sip-archive@odin.ietf.org; Tue, 19 Nov 2002 08:17: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 gAJDBIv15935; Tue, 19 Nov 2002 08:11: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 gAIGUKv02411 for ; Mon, 18 Nov 2002 11:30:20 -0500 Received: from cypress.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25826; Mon, 18 Nov 2002 11:27:38 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by cypress.neustar.com (8.11.6/8.11.6) with ESMTP id gAIGT7c17121; Mon, 18 Nov 2002 16:29:07 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Nov 2002 11:30:12 -0500 Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E38B311@stntexch1.va.neustar.com> From: "Yu, James" To: "'Orit Levin'" Cc: mankin@psg.com, "'Scott Bradner'" , iptel@lists.bell-labs.com, sip@ietf.org, sipping@ietf.org Date: Mon, 18 Nov 2002 11:30:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: request for iptell to review "url" IDs 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: , Orit, I'm not familiar with the ITU-T H.323 Annex O. I assume that h323 url is an IETF standard (e.g., an IETF registered url). So it is better to include the "user" parameter and others in this h323 url I-D. For the tel url and its existing and future extensions, a general statement about how the info. (no need to describe the exact info.) can appear in the user part when "user" parameter is present would be sufficient. Otherwise, when this h323 url I-D becomes a RFC, another I-D needs to be submitted to include the "user" parameter and others that not included in this I-D. James > -----Original Message----- > From: Orit Levin [mailto:orit@radvision.com] > Sent: Monday, November 18, 2002 10:23 AM > To: 'Yu, James' > Cc: mankin@psg.com; 'Scott Bradner'; iptel@lists.bell-labs.com; > sip@ietf.org; sipping@ietf.org > Subject: RE: request for iptell to review "url" IDs > > > James, > Actually the exact "user" parameter appears in the H.323 Annex O which > defines this and other parameters to H.323 URL. > > This Annex O is pending approval by the ITU-T because the > telephone-URI > (which it is dependant upon) hasn't been finalized yet within > the IETF. > > I will present at my ENUM presentation today this "standardization > dependencies" graph... > > BR, > Orit Levin > Chief Architect > RADVISION > Phone: +1.201.6896330 > Video: +1.201.6896430 > > > > -----Original Message----- > > From: Yu, James [mailto:james.yu@neustar.biz] > > Sent: Sunday, November 17, 2002 9:01 PM > > To: orit@radvision.com > > Cc: mankin@psg.com; 'Scott Bradner'; iptel@lists.bell-labs.com; > > sip@ietf.org; sipping@ietf.org > > Subject: RE: request for iptell to review "url" IDs > > > > Orit, > > > > The h323 url I-D currently does not define a parameter similar to > > "user=phone" in the sip url to indicate that a telephone > number is in the > > user part of the h323 url. Suggest to add that in your I-D > and clarify in > > the I-D that tel url information including its extensions > can appear in > > the > > user part when a telephone number is present in the user part. > > > > James > > > > > -----Original Message----- > > > From: Scott Bradner [mailto:sob@harvard.edu] > > > Sent: Monday, October 28, 2002 9:25 AM > > > To: iptel@lists.bell-labs.com; sip@ietf.org; sipping@ietf.org > > > Cc: antti.vaha-sipila@nokia.com; james.yu@neustar.biz; > mankin@psg.com; > > > orit@radvision.com; schulzrinne@cs.columbia.edu > > > Subject: request for iptell to review "url" IDs > > > > > > > > > > > > > > > msg from the TSV ADs > > > > > > we would like the iptel WG to take on the following 3 IDs > > > > > > draft-antti-rfc2806bis-05.txt > > > draft-yu-tel-url-06.txt > > > draft-levin-iptel-h323-url-scheme-04.txt > > > > > > we would like the WG to review the 3 IDs to be sure that > they do not > > > conflict in the use of terminology or technology and to work > > > with the ID > > > authors to resolve any conflicts > > > > > > anyone with opinions about these IDs should join the iptel > > > list and discuss > > > the issues there > > > > > > we expect that this task will be a short term one and we > can move to > > > getting these IDs published > > > > > > Scott & Allison > > > > _______________________________________________ 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 Nov 19 08:16:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04268 for ; Tue, 19 Nov 2002 08:16:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJDIEF16183 for sip-archive@odin.ietf.org; Tue, 19 Nov 2002 08:18: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 gAJDFFv16064; Tue, 19 Nov 2002 08:15: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 gAIIHOv08860 for ; Mon, 18 Nov 2002 13:17:24 -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 NAA28688; Mon, 18 Nov 2002 13:14:41 -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 NAA27971; Mon, 18 Nov 2002 13:17:14 -0500 (EST) Message-Id: <5.1.1.6.0.20021118124451.02da5980@bumail47.verizon.com> X-Sender: BA8CPQQ@bumail47.verizon.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 18 Nov 2002 13:17:14 -0500 To: sip@ietf.org, sipping@ietf.org From: Stu Jacobs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Sip] Comments on draft of broad requirements for VoIP security 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: , As a follow-up to the announcement of the draft draft-jacobs-signaling-security-requirements-00.txt, with Jon Peterson's ok, we are posting a private exchange between ourselves and Jon regarding the draft. > -----Original Message----- > From: Eric Nielsen [mailto:Eric.Nielsen@sylantro.com] > Sent: Friday, November 15, 2002 11:47 AM > To: Peterson, Jon > Cc: 'stu.jacobs@verizon.com' > Subject: RE: draft-jacobs-signaling-security-requirements-00 > > > Jon, > > Stu and I spent the time to answer your questions > more point by point. We would like to share this > on the mailing list - is that OK with you? > > Also, is it possible to discuss, or at least mention it > during the IETF meeting next week? I will be attending, > and think that or an off-line discussion will be useful. > > Thanks, > > Eric Nielsen > > > > Hi, > > > > I happened to see the announcement of your draft (both on the ietf list and > > the Internet2 VidMiz list), and I have a few questions and comments. For the > > most part, my comments are confined to the portions of your document that > > discuss SIP. > > > > First, I wanted to note that RFC3261, which defines SIP, contains a lot of > > security text - a whole lot - a good starting point would be Section 26, > > which goes into a detailed threat model, considers possible attacks, > > provides protocol requirements, and even contains illustrations of the use > > of recommended mechanisms to satisfy these requirements. Several other > > chapters deal exclusively with security, in particular with defining the use > > of security mechanisms for SIP. I don't read anything in your draft that > > suggests that you are familiar with Section 26 of RFC3261. I think it might > > prove an interesting read for you. > > > > In fact, from my initial glance at your document, it appears that the > > sections pertaining to SIP contain a subset of the threats, requirements, > > and mechanism analysis that was performed as part of the process of > > assembling the security sections of RFC3261. This process involved dozens > > of contributors (from various parts of the industry) and occupied much of > > the SIP WG's attention for the first part of this year. Security isn't > > exactly something that we've swept under the rug. While most of your > > requirements are certainly valid, they have already been captured in the > > baseline specification, as have solutions to these requirements. > > > > Also, as one of the chairs of the IETF SIP WG I'm a little uncertain about > > the status of your document. What do you intend to do with it? > > > > Some of the language in the SIP sections of the draft (e.g. Security > > Association) is undefined (the reference to RFC 240x does not help me to > > understand what you mean). The concepts of authentication, session key > > exchange and the establishment of a 'Security Association' seem to be > > frequently conflated in your document (in many security mechanisms, these > > are separable operations). It might be better to restrict the ontology to > > canonical SIP entities (presumably a Call Agent acts towards a SIP entity as > > some sort of user agent or proxy server, correct?). > > > > On an organizational matter, I would also note that the security > > requirements of SIP are radically different from the requirements of Megaco > > (an Internet standard) or MGCP (a discarded proposal for an Internet > > standard). Unlike SIP, MGCP and Megaco are intended to be intradomain > > protocols - protocols that do not traverse the public Internet. Trying to > > use these protocols between administrative domains (vide 3.3.14) is probably > > ill-advised. Anyway, I would put Megaco-specific requirments into a separate > > document- the 'common' requirements in section 3.4 could be fielded out to a > > third document and referenced by the Megaco/SIP docs if necessary. > > > > I also have some brief but specific comments on your requirements: > > > > 3.1.1 - This is a requirement that is satisfied by the baseline SIP protocol > > already. While it is nice to know that this is also a requirement from your > > perspective, this is a very elementary requirement that we have already > > captured in the SIP specification, and provided a mechanism to address. > > Agree, provided that the manner of authenticating with a SIP proxy does not > prevent an initiating SIP UA from authenticating with the recipient UA > > > > > 3.1.2 - The concept that a user agent needs to communicate 'securely' with a > > proxy server (be it a failover proxy or no) is very vague. The baseline SIP > > protocol provides mechanisms like TLS that satisfy most definitions of > > 'securely' (in that TLS provides canonical security properties - integrity, > > confidentiality, authentication, replay protection). Anyway, I suspect SIP > > already meets these requirements. > > TLS requires an extensive PKI and X.509v3 certs to allow mutual > authentication. To expect a SIP phone appliance to have the computing power > and storage to a full PKI and still be commodity priced is unreasonable. > Furthermore should a SIP Proxy fail and it's backup take over, TLS will > either require an apriori relationship between the backup SIP Proxy and the > UA or force a delay while the SIP UA and the backup Proxy establish the > relationship. > > > > > 3.1.3 - I have a hard time imagining a security mechanism that wouldn't meet > > this requirement (all of the ones that come to mind do - Digest, TLS, IPSec, > > S/MIME, PGP). I would also note that your Explanatory Text seems somewhat > > out of parity with the requirement itself. > > This is there for completeness so when one proposes a security solution this > is not overlooked. > > > > > 3.1.4 - There was really no danger of anyone who uses the existing security > > mechanisms in the baseline SIP specification ever making that mistake. The > > attacks considered in RFC3261 Section 26 contain numerous instances of > > source-address spoofing, and the mechanisms provided mitigate these attacks. > > > Security mechanisms like IPsec cannot cleanly operate across NAT because > they are dependant on the Correspondent's IP address not changing. A SIP UA > is really identified by the user of the UA and not the platform upon which > the UA is executing. > > > 3.1.5 - Section 3.1.5 seems to contain a number of confusing assumptions. > > Authentication systems have no dependency on addressing (as your bullet > > 3.1.4 correctly notes). To say that all but the simplest networks use NATs > > is a bit of an exaggeration. NAT traversal, either way, is a orthogonal to > > authentication. > > The reality is that NAT will be with us for many years and many, if not > most, service provider customers use NAT between their local networks and > the service provider network. We cannot expect residential, SOHO and small > business customers to know about or even understand what NAT is let alone > whether NAT is present between their local net and the service provider net. > > > > > 3.1.6 - Again, this requirement is well-substantiated in RFC3261. Mutual > > authentication systems are already provided in SIP. > > > > This is there for completeness so when one proposes a security solution this > is not overlooked. > > > 3.1.7 - We have done a lot of work on identity in SIP. A SIP URI (we would > > say an address-of-record URI) is the predominant form of identity used, for > > example, in draft-ietf-sip-asserted-identity-02, a draft (soon to be known > > as RFC 3325) that I imagine you would find interesting. A host name is not > > an identity. > > > > We are simply stating that SIP security must work with a logical identity > and not something as mutable as an IP address. If one were to use > address-of-record URIs and TLS then the certs TLS relies on would also have > to use address-of-record URI as the identity. > > > 3.1.8 - All of the authentication mechanisms supported by SIP provide > > versioning. This requirement, I note, is the first that seems to suggest you > > are designing some sort of authentication 'protocol' for SIP. Why on earth > > would we do that? Aren't there enough authentication protocols in the world? > > This is there for completeness so when one proposes a security solution this > is not overlooked. As to whether we are designing "some sort of > authentication 'protocol' for SIP" is dependant on whether there currently exists an > authentication mechanism for SIP that meets our other requirements. > > > > > 3.1.9 - SIP supports extensible authentication mechanisms already. > > This is there for completeness so when one proposes a security solution this > is not overlooked. > > > > > 3.1.10 - This one, I think, is totally meaningless, unless you define a 'SIP > > Security Association'. I know what an IPSec SA is, do you mean that? How do > > you define the attributes of a trust relationship? What is a trust > > relationship? > > > > The problem with IPsec SAs is that they are tightly bound to IP addresses; > in point of fact, an IPsec SA is specifically identified by the following > tuple (source IP address, destination IP address, SPI). Any SA used with > SIP cannot rely on IP addresses for identification. > > > 3.1.11 - This isn't precluded in any security mechanism I'm aware of. It > > would essentially have to be IP-based authentication, which (as you note > > many times here) has a lot of problems and which therefore no one uses. > > > Agreed > > > > 3.1.12 - Again, no real risk of this using any of the mechanisms we've > > defined for SIP. > > > > IPsec SAs do rely on IP addresses and TLS would necessitate the existence of > the address-of-record URI as the identity in X.509v3 certs for UAs and SIP > Proxies. > > > 3.1.13 - These qualities are provided by RFC3261. > > > > This is there for completeness so when one proposes a security solution this > is not overlooked. > > > 3.1.14 - 'MUST operate' isn't terribly specific. But anyway, this just means > > 'must run over the Internet'. We assume in RFC3261 that SIP runs over the > > Internet, not some sort of private 'trusted domain'. > > > > This is there for completeness so when one proposes a security solution this > is not overlooked. > > > 3.1.15 - Provided in RFC3261. > > > > This is there for completeness so when one proposes a security solution this > is not overlooked. > > > 3.1.16 - Digest meets this requirement, and is an authentication mechanism. > > > Yes but Digest has problems, i.e. key management > > > 3.1.17 - Full encryption and signature algorithm requirements are given > > already in RFC3261. > > > Yes but for any alternative security mechanism this applies > > > 3.1.18 - Provided by all application-layer security mechanisms (including > > Digest, TLS, S/MIME etc). > > Yes but these mechanisms have other problems (such as working when NAT > present, dealing with Proxy failover, simplicity of provisioning, reliance > on IP addresses, etc.) > > > > > 3.1.19 - Provided by Digest, for example. > > > Agreed > > > 3.1.20 - This fleshes out, to some degree, what you think an SA should be. > > This sort of aging capability could be realized in Digest, for example, with > > a nonce cache - when the 'SA' expires, the nonce is no longer valid and a > > new challenge must be issued. > > > Yes, it means we must make it explicit, that is all. Either they are coupled > or they are decoupled. > > > 3.4.1 - I'm not sure what protocol this is a requirement for... in any > > event, few people believe that SIP is a good way to distribute > > configurations or keys. > > > This is a VoIP deployment requirement. Whatever mechanism is used to > authenticate a trusted call agent should also be able to be re-used, or at > least facilitate signing configuration files downloaded from that same > authority. If the configuration files and the image files on a VoIP network > appliance are not signed this can enable compromise of the user's keying > material, theft of services, etc... This is part of a whole security system. > > > 3.4.2 - We have a general requirement for federated identity models that has > > already been taken pretty far in SIP. You might want to look at > > draft-ietf-sip-identity-00. > > > I agree that the draft-ietf-sip-identity-00 is based on dealing with this > requirement, but not really in SIP. > > > 3.4.4 - This requirement is met by SIP in a number of ways. > > > In hop-by-hop security the entire message can be authenticated and integrity > checked. In common usage of SIP Digest many aspects of the message are not > integrity checked. While in theory it is possible to meet this requirement > in SIP, in common usage it does not. > > We need to be able to assure integrity on a hop-by-hop basis. At the same > time there needs to be a trust relationship that allows going through NATs > and proxies without requiring the intervening devices that alter the SIP > message to know the user's symmetric passphrase or private key information. > S/MIME can do end-to-end authentication (assume a full PKI and difficult > implementation for small devices) in addition to hop-by-hop authentication. > > However this is inadequate in the scenario where caller "A" is known by > carrier "AA" and caller "B" is known by caller "BB", and carrier "A" trusts > carrier "B"'s claims. In this situation there are two virtually centralized > authorities. Caller's "A" and "B" may exchange S/MIME messages for there own > end-to-end security, if they choose. However the carrier needs to > authenticate only from the endpoint to the carrier's border. With > hop-by-hop security the carrier is unable to validate the end-user's > symmetric passphrase or public key while, at the same time assure full > packet integrity on a hop-by-hop basis. I do not believe SIP can do this. I > believe your draft-ietf-sip-identity-00 requires a PKI to do this. > > > 3.4.5 - Same as 3.4.4. > > > > This simply means that the protocol must be able to perform as required in > 3.4.4 while at the same time statefully share session keys in a practical > way. For example, I am not sure how many folks would consider replicating an > IPsec SADB is practical. > > > > 3.4.6 - This seems to be potentially in conflict with 3.4.3. In any event, > > this is something of an implementation requirement, not a protocol > > requirement (no protocol requirements arise from this). > > > While this is not a protocol requirement, it is a requirement on the > handling of passphrases and public/private key pairs. Part of a security > solution is to minimize the exposure of keys. Anytime a key is persistently > stored, exposure becomes more likely. We must have a security system that > minimizes the use of stored keys, particularly those keys that are mobile, > such as human passphrases or biometrics. If my phone uses a biometric > mechanism to authenticate it, what happens when I reboot the phone? In the > real world people expect the phone to still work as it did before thereboot. > > The point here is that we need a protocol that supports good behavior > relative to human passphrases upon phone reboot.. I do not believe that it > really exists. > > > > > 3.4.7 through 3.4.12 - I'm not sure how any security mechanism that has been > > passed in the IETF could fail to meet these requirements. In any event, > > these are met by the mechanisms described in the SIP specification. Any > > security mechanism (for example, TLS) has these sorts of properties. > > > 3.4.7 requires that the security mechanims used allows the key/identity > used for authentication be associated at the VoIP layer identity. In the > case of IPsec as mention in 3261 (and MGCP and MEGACO and ...) this is not > true. IPsec security is transparent to the application layer. A message can > be authenticated that it came from source "A", however its payload can look > like it came from source "B". SIP Digest links the application identity to > security layer. TLS can vary by implementation. > > 3.4.8 key dilution or weakening of security algorithm strength is possible > in frameworks where there is negotiation of algorithms and key lengths. This > seems to be a common subject, and part of the rationale behind security > suites. > > 3.4.9 Common usage of SIP Digest does not use session keys. Instead it uses > the persistent symmetric passphrase associated with the SIP URI. Theoretical > usage might be to use session keys, however in practice what happens in what > is simple and cheap. It is very important to develop a security solution so > that when it gets used in practice the human keys are easy to manage, not > over-used or over-stored in a way that leads to greater probability of > exposure. > > If we assume IKE or some other exchange that presumes a full PKI, we have a > practical problem that seems unresolvable (as well as uneconomical) in the > next few years. > > 3.4.10 - 3.4.12 Yes, these are standard requirements. I am unaware how SIP > Digest does this, however I do know that TLS and IPsec can meet these > requirements. For IPsec IKE is required to renegotiate a new session key. > > > > 3.4.13/3.4.14 - SIP has considerations for these conditions, even for > > Digest. > > 3.4.13 This is a matter of minimizing the work required to authenticate a > message. The more parsing and interpretation, etc, required before > authentication, the greater the potential load caused by unauthorized > messages. Simplicity also keeps it more secure. Simpler is better, and it > is a judgment call on whether something is simple enough. In this respect, > IPsec, one of the security mechanisms mentioned in 3261 is very simple. > > > 3.4.14 This is the potential for tens of thousands of endpoints needing to > set up new Security associations at once. The current form of IKE was not > designed for this kind of load. I doubt TLS using certificates is either. > Manually keyed mechanisms (digest, etc.) essentially already have their > security association statically defined, so there is no set up time > involved. > > > > > 3.5.1 - I'm not sure what ENUM has to do with this requirement. > > 3.5.1 has a Non-requirement: Globally Certified Identities > > The only reason ENUM was mentioned as a related comment, ENUM > shares some of the same issues as North American LNP: Who controls > what an E.164 number connects to, and who is allowed to change > that mapping. We do not assert that some globally certified > identity gets to define what E.164 number it maps to. Instead > we assert that an E.164 points to some information about an > identity. Look up based on the identity is error prone, where-as > look up based on the E.164 number is not. > > For SIP URIs the URI should not be mistaken for the identity > of one of the endpoints of a call. Instead it is some information > about the identity. And it is also a guarantee of sorts that > the entity that you call today using that URI is the same > as you called yesterday with that URI. Third parties (carriers > in the US) have direct control on how this mapping changes, > and who has rights to request changes. > > The short answer is that a URI cannot be considered equivalent > to an enduser identity. It can't have semantics greater than > a service provider who advertises (in a directory sense) the > URI knowing where to terminate calls directed to that URI, and > having adequate knowledge to bill someone for that service. > > > > > 3.5.4 - So, signaling needs to traverse non-trusted domains, but it can be > > unencrypted? Not even because of end-user privacy concerns? I find that a > > little hard to swallow. Take a look at some of the threats in RFC3261 - > > there are vulnerabilities that arise from this. > > > > - Jon > > > All of these requirements suggest a systemic security solution that > incorporates authentication, keying, rekeying, and key storage, and human > key handling. The security issue, while composed of components defined at > multiple layers, must also link these layers as a package to make it usable. > The components must be designed to meet the system requirements. > A significant issue for this draft is that the requirements do not neatly fit into any one WG charter. I believe this is more of a security issue than an application level issue. To date the SIP WG has worked to fill in a variety of gaps whereas MGCP and Megaco say not much more than "just use IPsec". Security is an essential part of VoIP, and many of the needed features exist. Still, the issue of a cohesive, workable security solution for carrier-scale deployment remains beyond the scope of any one workgroup. Thus we are posting this note here. The goal of this draft is to get agreement on the broader requirements, followed by an determining what gaps there are between what exists and what is needed. Obviously if we could see a full solution, we would not be pursuing this. For example, common usage of current technology leads to poor practices in handling keying material. The technology must be defined so that it is possible to define simple and secure common practices. We would like to work to get agreement on the requirements, as well as how to best meet them. Thank you, Eric Nielsen Sylantro Systems Stuart Jacobs CISSP Verizon Laboratories _______________________________________________ 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 Nov 19 08:20:38 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04519 for ; Tue, 19 Nov 2002 08:20:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJDMl416428 for sip-archive@odin.ietf.org; Tue, 19 Nov 2002 08: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 gAJDJNv16278; Tue, 19 Nov 2002 08:19: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 gAJ8b0v00631 for ; Tue, 19 Nov 2002 03:37:00 -0500 Received: from motgate.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29053 for ; Tue, 19 Nov 2002 03:34:11 -0500 (EST) Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (Motorola/Motgate) with ESMTP id gAJ8anIe003520 for ; Tue, 19 Nov 2002 01:36:49 -0700 (MST) Received: [from zin05exm02.corp.mot.com (zin05exm02.corp.mot.com [10.232.0.1]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id BAA19160 for ; Tue, 19 Nov 2002 01:36:47 -0700 (MST)] Received: by zin05exm02.corp.mot.com with Internet Mail Service (5.5.2656.59) id ; Tue, 19 Nov 2002 14:06:46 +0530 Message-ID: <653138C25D8AD6118292000347080A3701238FBA@zin05exm02.corp.mot.com> From: P Sudarshanakrishnan-A14377 To: "SipWg (E-mail 2)" Date: Tue, 19 Nov 2002 14:06:44 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28FA6.CA88E52C" Subject: [Sip] Question on Supplementary Services 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_01C28FA6.CA88E52C Content-Type: text/plain; charset="iso-8859-1" All Can somebody point me to drafts, Informational RFCs or BCPs that talk about implementing Supplementary services like Call Forwarding Unconditional (CFU), Call Forwarding No Reply(CFNR), Call Forwarding Busy (CFB), Call Deflection (CD) at the User Agents. I see a old obsoleted draft that talks about a "Diversion" header for these Supp Services. Is there any plan to revive this? One straight forward approach is to send 3xx responses. This has a drawback that we cannot consult with the diverted-to party before actually diverting the call. Is there any working draft on this subject? Thanks regds krish ------_=_NextPart_001_01C28FA6.CA88E52C Content-Type: text/html; charset="iso-8859-1"
All
    Can somebody point me to drafts, Informational RFCs or BCPs that talk about
implementing Supplementary services like Call Forwarding Unconditional (CFU),
Call Forwarding No Reply(CFNR), Call Forwarding Busy (CFB), Call Deflection (CD) at the User Agents.
 
I see a old obsoleted draft that talks about a "Diversion" header for these Supp Services.
Is there any plan to revive this?
 
One straight forward approach is to send 3xx responses. This has a drawback that we cannot consult
with the diverted-to party before actually diverting the call.
 
Is there any working draft on this subject?
 
Thanks
 
regds
krish
------_=_NextPart_001_01C28FA6.CA88E52C-- _______________________________________________ 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 Nov 19 08:23:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04611 for ; Tue, 19 Nov 2002 08:23:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJDQ8G16548 for sip-archive@odin.ietf.org; Tue, 19 Nov 2002 08:26: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 gAJDNYv16468; Tue, 19 Nov 2002 08:23:34 -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 gAJC8ev12535 for ; Tue, 19 Nov 2002 07:08:40 -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 HAA02760; Tue, 19 Nov 2002 07:06:00 -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 HAA23039; Tue, 19 Nov 2002 07:08:37 -0500 (EST) Message-Id: <5.1.1.6.0.20021119070728.02d99a30@bumail47.verizon.com> X-Sender: BA8CPQQ@bumail47.verizon.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 X-Priority: 2 (High) Date: Tue, 19 Nov 2002 07:08:37 -0500 To: sip@ietf.org, sipping@ietf.org From: Stu Jacobs Cc: Eric.Nielsen@sylantro.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Sip] Comments on draft of broad requirements for VoIP security 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 am reposting this as it seems to have gotten lost the first time >As a follow-up to the announcement of the draft >draft-jacobs-signaling-security-requirements-00.txt, with Jon Peterson's ok, >we are posting a private exchange between ourselves and Jon >regarding the draft. > > > -----Original Message----- > > From: Eric Nielsen [mailto:Eric.Nielsen@sylantro.com] > > Sent: Friday, November 15, 2002 11:47 AM > > To: Peterson, Jon > > Cc: 'stu.jacobs@verizon.com' > > Subject: RE: draft-jacobs-signaling-security-requirements-00 > > > > > > Jon, > > > > Stu and I spent the time to answer your questions > > more point by point. We would like to share this > > on the mailing list - is that OK with you? > > > > Also, is it possible to discuss, or at least mention it > > during the IETF meeting next week? I will be attending, > > and think that or an off-line discussion will be useful. > > > > Thanks, > > > > Eric Nielsen > > > > > > > Hi, > > > > > > I happened to see the announcement of your draft (both on the ietf > list and > > > the Internet2 VidMiz list), and I have a few questions and comments. > For the > > > most part, my comments are confined to the portions of your document that > > > discuss SIP. > > > > > > First, I wanted to note that RFC3261, which defines SIP, contains a > lot of > > > security text - a whole lot - a good starting point would be Section 26, > > > which goes into a detailed threat model, considers possible attacks, > > > provides protocol requirements, and even contains illustrations of > the use > > > of recommended mechanisms to satisfy these requirements. Several other > > > chapters deal exclusively with security, in particular with defining > the use > > > of security mechanisms for SIP. I don't read anything in your draft that > > > suggests that you are familiar with Section 26 of RFC3261. I think it > might > > > prove an interesting read for you. > > > > > > In fact, from my initial glance at your document, it appears that the > > > sections pertaining to SIP contain a subset of the threats, requirements, > > > and mechanism analysis that was performed as part of the process of > > > assembling the security sections of RFC3261. This process involved > dozens > > > of contributors (from various parts of the industry) and occupied much of > > > the SIP WG's attention for the first part of this year. Security isn't > > > exactly something that we've swept under the rug. While most of your > > > requirements are certainly valid, they have already been captured in the > > > baseline specification, as have solutions to these requirements. > > > > > > Also, as one of the chairs of the IETF SIP WG I'm a little uncertain > about > > > the status of your document. What do you intend to do with it? > > > > > > Some of the language in the SIP sections of the draft (e.g. Security > > > Association) is undefined (the reference to RFC 240x does not help me to > > > understand what you mean). The concepts of authentication, session key > > > exchange and the establishment of a 'Security Association' seem to be > > > frequently conflated in your document (in many security mechanisms, these > > > are separable operations). It might be better to restrict the ontology to > > > canonical SIP entities (presumably a Call Agent acts towards a SIP > entity as > > > some sort of user agent or proxy server, correct?). > > > > > > On an organizational matter, I would also note that the security > > > requirements of SIP are radically different from the requirements of > Megaco > > > (an Internet standard) or MGCP (a discarded proposal for an Internet > > > standard). Unlike SIP, MGCP and Megaco are intended to be intradomain > > > protocols - protocols that do not traverse the public Internet. Trying to > > > use these protocols between administrative domains (vide 3.3.14) is > probably > > > ill-advised. Anyway, I would put Megaco-specific requirments into a > separate > > > document- the 'common' requirements in section 3.4 could be fielded > out to a > > > third document and referenced by the Megaco/SIP docs if necessary. > > > > > > I also have some brief but specific comments on your requirements: > > > > > > 3.1.1 - This is a requirement that is satisfied by the baseline SIP > protocol > > > already. While it is nice to know that this is also a requirement > from your > > > perspective, this is a very elementary requirement that we have already > > > captured in the SIP specification, and provided a mechanism to address. > > > > Agree, provided that the manner of authenticating with a SIP proxy > does not > > prevent an initiating SIP UA from authenticating with the recipient UA > > > > > > > > 3.1.2 - The concept that a user agent needs to > communicate 'securely' with a > > > proxy server (be it a failover proxy or no) is very vague. The > baseline SIP > > > protocol provides mechanisms like TLS that satisfy most definitions of > > > 'securely' (in that TLS provides canonical security properties - > integrity, > > > confidentiality, authentication, replay protection). Anyway, I > suspect SIP > > > already meets these requirements. > > > > TLS requires an extensive PKI and X.509v3 certs to allow mutual > > authentication. To expect a SIP phone appliance to have the computing > power > > and storage to a full PKI and still be commodity priced is unreasonable. > > Furthermore should a SIP Proxy fail and it's backup take over, TLS will > > either require an apriori relationship between the backup SIP Proxy and the > > UA or force a delay while the SIP UA and the backup Proxy establish the > > relationship. > > > > > > > > 3.1.3 - I have a hard time imagining a security mechanism that > wouldn't meet > > > this requirement (all of the ones that come to mind do - Digest, TLS, > IPSec, > > > S/MIME, PGP). I would also note that your Explanatory Text seems somewhat > > > out of parity with the requirement itself. > > > > This is there for completeness so when one proposes a security solution > this > > is not overlooked. > > > > > > > > 3.1.4 - There was really no danger of anyone who uses the existing > security > > > mechanisms in the baseline SIP specification ever making that > mistake. The > > > attacks considered in RFC3261 Section 26 contain numerous instances of > > > source-address spoofing, and the mechanisms provided mitigate these > attacks. > > > > > Security mechanisms like IPsec cannot cleanly operate across NAT because > > they are dependant on the Correspondent's IP address not changing. A > SIP UA > > is really identified by the user of the UA and not the platform upon which > > the UA is executing. > > > > > 3.1.5 - Section 3.1.5 seems to contain a number of confusing assumptions. > > > Authentication systems have no dependency on addressing (as your bullet > > > 3.1.4 correctly notes). To say that all but the simplest networks use > NATs > > > is a bit of an exaggeration. NAT traversal, either way, is a > orthogonal to > > > authentication. > > > > The reality is that NAT will be with us for many years and many, if not > > most, service provider customers use NAT between their local networks and > > the service provider network. We cannot expect residential, SOHO and small > > business customers to know about or even understand what NAT is let alone > > whether NAT is present between their local net and the service provider > net. > > > > > > > > 3.1.6 - Again, this requirement is well-substantiated in RFC3261. Mutual > > > authentication systems are already provided in SIP. > > > > > > > This is there for completeness so when one proposes a security solution > this > > is not overlooked. > > > > > 3.1.7 - We have done a lot of work on identity in SIP. A SIP URI (we > would > > > say an address-of-record URI) is the predominant form of identity > used, for > > > example, in draft-ietf-sip-asserted-identity-02, a draft (soon to be > known > > > as RFC 3325) that I imagine you would find interesting. A host name > is not > > > an identity. > > > > > > > We are simply stating that SIP security must work with a logical identity > > and not something as mutable as an IP address. If one were to use > > address-of-record URIs and TLS then the certs TLS relies on would also have > > to use address-of-record URI as the identity. > > > > > 3.1.8 - All of the authentication mechanisms supported by SIP provide > > > versioning. This requirement, I note, is the first that seems to > suggest you > > > are designing some sort of authentication 'protocol' for SIP. Why on > earth > > > would we do that? Aren't there enough authentication protocols in the > world? > > > > This is there for completeness so when one proposes a security solution > this > > is not overlooked. As to whether we are designing "some sort of > > authentication 'protocol' for SIP" is dependant on whether there > currently exists an > > authentication mechanism for SIP that meets our other requirements. > > > > > > > > 3.1.9 - SIP supports extensible authentication mechanisms already. > > > > This is there for completeness so when one proposes a security solution > this > > is not overlooked. > > > > > > > > 3.1.10 - This one, I think, is totally meaningless, unless you define > a 'SIP > > > Security Association'. I know what an IPSec SA is, do you mean that? > How do > > > you define the attributes of a trust relationship? What is a trust > > > relationship? > > > > > > > The problem with IPsec SAs is that they are tightly bound to IP addresses; > > in point of fact, an IPsec SA is specifically identified by the following > > tuple (source IP address, destination IP address, SPI). Any SA used with > > SIP cannot rely on IP addresses for identification. > > > > > 3.1.11 - This isn't precluded in any security mechanism I'm aware of. It > > > would essentially have to be IP-based authentication, which (as you note > > > many times here) has a lot of problems and which therefore no one uses. > > > > > Agreed > > > > > > > 3.1.12 - Again, no real risk of this using any of the mechanisms we've > > > defined for SIP. > > > > > > > IPsec SAs do rely on IP addresses and TLS would necessitate the > existence of > > the address-of-record URI as the identity in X.509v3 certs for UAs and SIP > > Proxies. > > > > > 3.1.13 - These qualities are provided by RFC3261. > > > > > > > This is there for completeness so when one proposes a security solution > this > > is not overlooked. > > > > > 3.1.14 - 'MUST operate' isn't terribly specific. But anyway, this > just means > > > 'must run over the Internet'. We assume in RFC3261 that SIP runs over the > > > Internet, not some sort of private 'trusted domain'. > > > > > > > This is there for completeness so when one proposes a security solution > this > > is not overlooked. > > > > > 3.1.15 - Provided in RFC3261. > > > > > > > This is there for completeness so when one proposes a security solution > this > > is not overlooked. > > > > > 3.1.16 - Digest meets this requirement, and is an authentication > mechanism. > > > > > Yes but Digest has problems, i.e. key management > > > > > 3.1.17 - Full encryption and signature algorithm requirements are given > > > already in RFC3261. > > > > > Yes but for any alternative security mechanism this applies > > > > > 3.1.18 - Provided by all application-layer security mechanisms (including > > > Digest, TLS, S/MIME etc). > > > > Yes but these mechanisms have other problems (such as working when NAT > > present, dealing with Proxy failover, simplicity of provisioning, reliance > > on IP addresses, etc.) > > > > > > > > 3.1.19 - Provided by Digest, for example. > > > > > Agreed > > > > > 3.1.20 - This fleshes out, to some degree, what you think an SA > should be. > > > This sort of aging capability could be realized in Digest, for > example, with > > > a nonce cache - when the 'SA' expires, the nonce is no longer valid and a > > > new challenge must be issued. > > > > > Yes, it means we must make it explicit, that is all. Either they are > coupled > > or they are decoupled. > > > > > 3.4.1 - I'm not sure what protocol this is a requirement for... in any > > > event, few people believe that SIP is a good way to distribute > > > configurations or keys. > > > > > This is a VoIP deployment requirement. Whatever mechanism is used to > > authenticate a trusted call agent should also be able to be re-used, or at > > least facilitate signing configuration files downloaded from that same > > authority. If the configuration files and the image files on a VoIP > network > > appliance are not signed this can enable compromise of the user's keying > > material, theft of services, etc... This is part of a whole security > system. > > > > > 3.4.2 - We have a general requirement for federated identity models > that has > > > already been taken pretty far in SIP. You might want to look at > > > draft-ietf-sip-identity-00. > > > > > I agree that the draft-ietf-sip-identity-00 is based on dealing with this > > requirement, but not really in SIP. > > > > > 3.4.4 - This requirement is met by SIP in a number of ways. > > > > > In hop-by-hop security the entire message can be authenticated and > integrity > > checked. In common usage of SIP Digest many aspects of the message are not > > integrity checked. While in theory it is possible to meet this requirement > > in SIP, in common usage it does not. > > > > We need to be able to assure integrity on a hop-by-hop basis. At the same > > time there needs to be a trust relationship that allows going through NATs > > and proxies without requiring the intervening devices that alter the SIP > > message to know the user's symmetric passphrase or private key information. > > S/MIME can do end-to-end authentication (assume a full PKI and difficult > > implementation for small devices) in addition to hop-by-hop > authentication. > > > > However this is inadequate in the scenario where caller "A" is known by > > carrier "AA" and caller "B" is known by caller "BB", and carrier "A" trusts > > carrier "B"'s claims. In this situation there are two virtually > centralized > > authorities. Caller's "A" and "B" may exchange S/MIME messages for > there own > > end-to-end security, if they choose. However the carrier needs to > > authenticate only from the endpoint to the carrier's border. With > > hop-by-hop security the carrier is unable to validate the end-user's > > symmetric passphrase or public key while, at the same time assure full > > packet integrity on a hop-by-hop basis. I do not believe SIP can do this. I > > believe your draft-ietf-sip-identity-00 requires a PKI to do this. > > > > > 3.4.5 - Same as 3.4.4. > > > > > > > This simply means that the protocol must be able to perform as required in > > 3.4.4 while at the same time statefully share session keys in a practical > > way. For example, I am not sure how many folks would consider > replicating an > > IPsec SADB is practical. > > > > > > > 3.4.6 - This seems to be potentially in conflict with 3.4.3. In any > event, > > > this is something of an implementation requirement, not a protocol > > > requirement (no protocol requirements arise from this). > > > > > While this is not a protocol requirement, it is a requirement on the > > handling of passphrases and public/private key pairs. Part of a security > > solution is to minimize the exposure of keys. Anytime a key is persistently > > stored, exposure becomes more likely. We must have a security system that > > minimizes the use of stored keys, particularly those keys that are mobile, > > such as human passphrases or biometrics. If my phone uses a biometric > > mechanism to authenticate it, what happens when I reboot the phone? In the > > real world people expect the phone to still work as it did before > thereboot. > > > > The point here is that we need a protocol that supports good behavior > > relative to human passphrases upon phone reboot.. I do not believe that it > > really exists. > > > > > > > > > 3.4.7 through 3.4.12 - I'm not sure how any security mechanism that > has been > > > passed in the IETF could fail to meet these requirements. In any event, > > > these are met by the mechanisms described in the SIP specification. Any > > > security mechanism (for example, TLS) has these sorts of properties. > > > > > 3.4.7 requires that the security mechanims used allows the key/identity > > used for authentication be associated at the VoIP layer identity. In the > > case of IPsec as mention in 3261 (and MGCP and MEGACO and ...) this is not > > true. IPsec security is transparent to the application layer. A message can > > be authenticated that it came from source "A", however its payload can look > > like it came from source "B". SIP Digest links the application identity to > > security layer. TLS can vary by implementation. > > > > 3.4.8 key dilution or weakening of security algorithm strength is possible > > in frameworks where there is negotiation of algorithms and key lengths. > This > > seems to be a common subject, and part of the rationale behind security > > suites. > > > > 3.4.9 Common usage of SIP Digest does not use session keys. Instead it > uses > > the persistent symmetric passphrase associated with the SIP URI. > Theoretical > > usage might be to use session keys, however in practice what happens in > what > > is simple and cheap. It is very important to develop a security solution so > > that when it gets used in practice the human keys are easy to manage, not > > over-used or over-stored in a way that leads to greater probability of > > exposure. > > > > If we assume IKE or some other exchange that presumes a full PKI, we have a > > practical problem that seems unresolvable (as well as uneconomical) in the > > next few years. > > > > 3.4.10 - 3.4.12 Yes, these are standard requirements. I am unaware how SIP > > Digest does this, however I do know that TLS and IPsec can meet these > > requirements. For IPsec IKE is required to renegotiate a new session key. > > > > > > > 3.4.13/3.4.14 - SIP has considerations for these conditions, even for > > > Digest. > > > > 3.4.13 This is a matter of minimizing the work required to authenticate a > > message. The more parsing and interpretation, etc, required before > > authentication, the greater the potential load caused by unauthorized > > messages. Simplicity also keeps it more secure. Simpler is better, and it > > is a judgment call on whether something is simple enough. In this respect, > > IPsec, one of the security mechanisms mentioned in 3261 is very simple. > > > > > > 3.4.14 This is the potential for tens of thousands of endpoints needing to > > set up new Security associations at once. The current form of IKE was not > > designed for this kind of load. I doubt TLS using certificates is either. > > Manually keyed mechanisms (digest, etc.) essentially already have their > > security association statically defined, so there is no set up time > > involved. > > > > > > > > 3.5.1 - I'm not sure what ENUM has to do with this requirement. > > > > 3.5.1 has a Non-requirement: Globally Certified Identities > > > > The only reason ENUM was mentioned as a related comment, ENUM > > shares some of the same issues as North American LNP: Who controls > > what an E.164 number connects to, and who is allowed to change > > that mapping. We do not assert that some globally certified > > identity gets to define what E.164 number it maps to. Instead > > we assert that an E.164 points to some information about an > > identity. Look up based on the identity is error prone, where-as > > look up based on the E.164 number is not. > > > > For SIP URIs the URI should not be mistaken for the identity > > of one of the endpoints of a call. Instead it is some information > > about the identity. And it is also a guarantee of sorts that > > the entity that you call today using that URI is the same > > as you called yesterday with that URI. Third parties (carriers > > in the US) have direct control on how this mapping changes, > > and who has rights to request changes. > > > > The short answer is that a URI cannot be considered equivalent > > to an enduser identity. It can't have semantics greater than > > a service provider who advertises (in a directory sense) the > > URI knowing where to terminate calls directed to that URI, and > > having adequate knowledge to bill someone for that service. > > > > > > > > 3.5.4 - So, signaling needs to traverse non-trusted domains, but it > can be > > > unencrypted? Not even because of end-user privacy concerns? I find > that a > > > little hard to swallow. Take a look at some of the threats in RFC3261 - > > > there are vulnerabilities that arise from this. > > > > > > - Jon > > > > > > All of these requirements suggest a systemic security solution that > > incorporates authentication, keying, rekeying, and key storage, and human > > key handling. The security issue, while composed of components defined at > > multiple layers, must also link these layers as a package to make it > usable. > > The components must be designed to meet the system requirements. > > > >A significant issue for this draft is that the requirements >do not neatly fit into any one WG charter. I believe this >is more of a security issue than an application level >issue. To date the SIP WG has worked to fill in a variety >of gaps whereas MGCP and Megaco say not much more than >"just use IPsec". Security is an essential part of VoIP, >and many of the needed features exist. Still, the issue of >a cohesive, workable security solution for carrier-scale >deployment remains beyond the scope of any one workgroup. >Thus we are posting this note here. > >The goal of this draft is to get agreement on the broader >requirements, followed by an determining what gaps there >are between what exists and what is needed. Obviously if >we could see a full solution, we would not be pursuing this. >For example, common usage of current technology leads to >poor practices in handling keying material. The technology >must be defined so that it is possible to define simple and >secure common practices. > >We would like to work to get agreement on the requirements, >as well as how to best meet them. > >Thank you, > >Eric Nielsen >Sylantro Systems > >Stuart Jacobs CISSP >Verizon Laboratories ========================== 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 Nov 19 14:27:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14012 for ; Tue, 19 Nov 2002 14:27:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJJTxe08132 for sip-archive@odin.ietf.org; Tue, 19 Nov 2002 14:29: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 gAJJLfv07685; Tue, 19 Nov 2002 14:21: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 gAJJ7Ev06796 for ; Tue, 19 Nov 2002 14:07:14 -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 OAA13320; Tue, 19 Nov 2002 14:04:31 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gAJJ6tsA027156; Tue, 19 Nov 2002 11:06:55 -0800 (PST) Received: from CJ650 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with SMTP id CSD00064; Tue, 19 Nov 2002 11:07:33 -0800 (PST) From: "Cullen Jennings" To: Cc: , Subject: RE: [Sip] RE: request for iptell to review "url" IDs Date: Tue, 19 Nov 2002 11:08:07 -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: <5E42C1C85C5D064A947CF92FADE6D82E38B311@stntexch1.va.neustar.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 Can we try to keep the H.323 URL discussion on the iptel@ietf.org list please. Thanks, Cullen > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Yu, > James > Sent: Monday, November 18, 2002 8:30 AM > To: 'Orit Levin' > Cc: mankin@psg.com; 'Scott Bradner'; iptel@lists.bell-labs.com; > sip@ietf.org; sipping@ietf.org > Subject: [Sip] RE: request for iptell to review "url" IDs > > > Orit, > > I'm not familiar with the ITU-T H.323 Annex O. I assume that > h323 url is an > IETF standard (e.g., an IETF registered url). So it is better to include > the "user" parameter and others in this h323 url I-D. For the tel url and > its existing and future extensions, a general statement about how > the info. > (no need to describe the exact info.) can appear in the user part when > "user" parameter is present would be sufficient. Otherwise, > when this h323 > url I-D becomes a RFC, another I-D needs to be submitted to include the > "user" parameter and others that not included in this I-D. > > James > > > -----Original Message----- > > From: Orit Levin [mailto:orit@radvision.com] > > Sent: Monday, November 18, 2002 10:23 AM > > To: 'Yu, James' > > Cc: mankin@psg.com; 'Scott Bradner'; iptel@lists.bell-labs.com; > > sip@ietf.org; sipping@ietf.org > > Subject: RE: request for iptell to review "url" IDs > > > > > > James, > > Actually the exact "user" parameter appears in the H.323 Annex O which > > defines this and other parameters to H.323 URL. > > > > This Annex O is pending approval by the ITU-T because the > > telephone-URI > > (which it is dependant upon) hasn't been finalized yet within > > the IETF. > > > > I will present at my ENUM presentation today this "standardization > > dependencies" graph... > > > > BR, > > Orit Levin > > Chief Architect > > RADVISION > > Phone: +1.201.6896330 > > Video: +1.201.6896430 > > > > > > > -----Original Message----- > > > From: Yu, James [mailto:james.yu@neustar.biz] > > > Sent: Sunday, November 17, 2002 9:01 PM > > > To: orit@radvision.com > > > Cc: mankin@psg.com; 'Scott Bradner'; iptel@lists.bell-labs.com; > > > sip@ietf.org; sipping@ietf.org > > > Subject: RE: request for iptell to review "url" IDs > > > > > > Orit, > > > > > > The h323 url I-D currently does not define a parameter similar to > > > "user=phone" in the sip url to indicate that a telephone > > number is in the > > > user part of the h323 url. Suggest to add that in your I-D > > and clarify in > > > the I-D that tel url information including its extensions > > can appear in > > > the > > > user part when a telephone number is present in the user part. > > > > > > James > > > > > > > -----Original Message----- > > > > From: Scott Bradner [mailto:sob@harvard.edu] > > > > Sent: Monday, October 28, 2002 9:25 AM > > > > To: iptel@lists.bell-labs.com; sip@ietf.org; sipping@ietf.org > > > > Cc: antti.vaha-sipila@nokia.com; james.yu@neustar.biz; > > mankin@psg.com; > > > > orit@radvision.com; schulzrinne@cs.columbia.edu > > > > Subject: request for iptell to review "url" IDs > > > > > > > > > > > > > > > > > > > > msg from the TSV ADs > > > > > > > > we would like the iptel WG to take on the following 3 IDs > > > > > > > > draft-antti-rfc2806bis-05.txt > > > > draft-yu-tel-url-06.txt > > > > draft-levin-iptel-h323-url-scheme-04.txt > > > > > > > > we would like the WG to review the 3 IDs to be sure that > > they do not > > > > conflict in the use of terminology or technology and to work > > > > with the ID > > > > authors to resolve any conflicts > > > > > > > > anyone with opinions about these IDs should join the iptel > > > > list and discuss > > > > the issues there > > > > > > > > we expect that this task will be a short term one and we > > can move to > > > > getting these IDs published > > > > > > > > Scott & Allison > > > > > > > _______________________________________________ > 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 Nov 19 16:52:40 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18019 for ; Tue, 19 Nov 2002 16:52:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJLsrS17540 for sip-archive@odin.ietf.org; Tue, 19 Nov 2002 16:54: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 gAJLkZv17189; Tue, 19 Nov 2002 16:46: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 gAJLgkv16996 for ; Tue, 19 Nov 2002 16:42:46 -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 QAA17567 for ; Tue, 19 Nov 2002 16:40:01 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.81]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAJLgeYH003326; Tue, 19 Nov 2002 16:42:40 -0500 (EST) Message-ID: <3DDAB04E.3010803@dynamicsoft.com> Date: Tue, 19 Nov 2002 16:42:38 -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: Christer Holmberg CC: sip@ietf.org Subject: Re: [Sip] The fate of session timer? References: <3DD3B930.E6230AC3@lmf.ericsson.se> <3DD4A760.BD1FF3C3@lmf.ericsson.se> <3DD89B30.9010709@dynamicsoft.com> <3DD8DE55.34DF9786@lmf.ericsson.se> 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. Christer Holmberg wrote: > Hi, >>>So, my question is: if a value is too small for a proxy, what is the >>>reason it simply can't change the value and forward the INVITE? In >>>that case the INVITE will receive the UAS, and the final response >>>will indicate the refresh value which will actually be used. >> >>There are two reasons. >> >>The first is documented in the security considerations section: >> >> >>>Next, consider the case of a rogue UAS that wishes to force a UAC to >>>generate refreshes at a rapid rate. In that case, the UAC has to >>>support session timer. The initial INVITE arrives at the rogue UAS, >>>which returns a 2xx with a very small session interval. The UAC uses >>>this timer, and quickly sends a refresh. Section 7.1 requires the UAC >>>to copy the current session interval into the Session-Expires header >>>field in the request. This enables the proxies to see the current >>>value. The proxies will reject this request, and provide a Min-SE >>>with a higher minimum. The UAC will then use this higher minimum. >>>Note, that if the proxies did not reject the request, but rather >>>proxied the request with a Min-SE header field, an attack would still >>>be possible. The UAS could discard this header field in a 2xx >>>response, and force the UAC to continue to generate rapid requests. >> >>So, the change you suggest would introduce a dos attack that a rogue UAS >>could launch on a UAC. > > > The UAC would include a minimum value in the request, which proxies are only > allowed to INCREASE, if needed. If the UAC then receives 200 OK with a SMALLER > value it knows something went wrong, so it would probably choose to release > the call. Every proxy, when receiving the 200 response, would also see that > something has gone wrong, since the value is smaller than the value set in the > INVITE request. That doesn't work. It relies on behavior at the UAS. That is the place where the rogue element is. Once you assume you cannot trust the UAS, you must rely on the proxy before it to generate an error response. I believe there is no way around that. -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 Tue Nov 19 23:10:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16615 for ; Tue, 19 Nov 2002 23:10:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAK4D8H07848 for sip-archive@odin.ietf.org; Tue, 19 Nov 2002 23:13: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 gAK48jv07671; Tue, 19 Nov 2002 23:08: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 gAK44Mv06975 for ; Tue, 19 Nov 2002 23:04:22 -0500 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15684 for ; Tue, 19 Nov 2002 23:01:34 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id gAK44D51024095 for ; Tue, 19 Nov 2002 21:04:13 -0700 (MST) Received: [from zin05exm02.corp.mot.com (zin05exm02.corp.mot.com [10.232.0.1]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id VAA21970 for ; Tue, 19 Nov 2002 21:04:11 -0700 (MST)] Received: by zin05exm02.corp.mot.com with Internet Mail Service (5.5.2656.59) id ; Wed, 20 Nov 2002 09:34:10 +0530 Message-ID: <653138C25D8AD6118292000347080A3701238FC6@zin05exm02.corp.mot.com> From: P Sudarshanakrishnan-A14377 To: "'sip@ietf.org'" Date: Wed, 20 Nov 2002 09:34:08 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29049.DFC304EC" Subject: [Sip] test - pls ignore. 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_01C29049.DFC304EC Content-Type: text/plain; charset="iso-8859-1" ------_=_NextPart_001_01C29049.DFC304EC Content-Type: text/html; charset="iso-8859-1"
 
------_=_NextPart_001_01C29049.DFC304EC-- _______________________________________________ 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 Nov 19 23:51:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17215 for ; Tue, 19 Nov 2002 23:51:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAK4rPG09628 for sip-archive@odin.ietf.org; Tue, 19 Nov 2002 23:53: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 gAK4nJv09541; Tue, 19 Nov 2002 23:49: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 gAK4k1v09471 for ; Tue, 19 Nov 2002 23:46:01 -0500 Received: from Mistralsoftware.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17074 for ; Tue, 19 Nov 2002 23:43:10 -0500 (EST) Received: from gauthamL [192.168.11.26] by mistralsoftware.com [192.168.10.12] with SMTP (MDaemon.PRO.v5.0.0.R) for ; Wed, 20 Nov 2002 10:23:17 +0530 Date: Wed, 20 Nov 2002 10:23:42 +0530 From: "A. N. Gautham" To: "tenwater" Cc: sip@ietf.org Subject: Re: [Sip] Termination of SUBSCRIPTION Message-Id: <20021120102342.03ac1dc4.gautham@mistralsoftware.com> In-Reply-To: <001c01c28f0b$d27bdbe0$8500a8c0@danfo> References: <20021117170001.26396.60343.Mailman@www1.ietf.org> <001c01c28f0b$d27bdbe0$8500a8c0@danfo> Organization: Mistral X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MDRemoteIP: 192.168.11.26 X-Return-Path: gautham@mistralsoftware.com X-MDaemon-Deliver-To: sip@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 Hi, I have an answer to one of your questions. On Mon, 18 Nov 2002 21:20:41 +0800 "tenwater" wrote: > Hello, All > > I have some doubt on the RFC3265, anybody can give me some advise. > > 1. receive fail response of refresh SUBSCRIBE request > > RFC3265 P9 wrote: > > ======================================================================== > If a SUBSCRIBE request to refresh a subscription fails with a non-481 > response, the original subscription is still considered valid for the > duration of the most recently known "Expires" value as negotiated by > SUBSCRIBE and its response, or as communicated by NOTIFY in the > "Subscription-State" header "expires" parameter. > ======================================================================== > > A. if this means Subscriber will not retry the refresh SUBSCRIBE request even if the response is 401 or 407 or 423? No, it doesnot mean that the Subscriber will not refresh SUBSCRIBE request even if the response is 401 or 407 or 423. The retry is needed if the refresh is to succeed. The text in 3265 says that the failure of the refresh request with a code other than 481 means that the original subscription (effected by the previous SUBSCRIBE) continues to be valid for the duration of the most recently known "Expires" value. > B. after the time indicated by "Expires" elapsed, Subscriber will send a SUBSCRIBE(expires=0) or not? If not, CSF proxy itself have to start a timer as "Expires", else CSF proxy cannot know when a Subscription terminated. > > 2. receive fail response of NOTIFY request > > after receive a response which cannot retry, Notifier will terminate the subscription as per P14 of RFC3265, so the same problem can occur as 1.B in CSF proxy. > > > > For a session defined in RFC3261, they always send BYE to terminate a established session, why the subscription can be terminated silently? If a subscription timer will be defined as session timer? > > Regards, > TenWater > > ------------------------------------------------- This is a active spring.----------------------------------------- Hope this helps. Regards, A. N. Gautham _______________________________________________ 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 Nov 20 00:18:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17718 for ; Wed, 20 Nov 2002 00:18:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAK5KQL10934 for sip-archive@odin.ietf.org; Wed, 20 Nov 2002 00: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 gAK5G5v10774; Wed, 20 Nov 2002 00:16: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 gAK5B6v10663 for ; Wed, 20 Nov 2002 00:11:06 -0500 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17520 for ; Wed, 20 Nov 2002 00:08:17 -0500 (EST) Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id gAK5Au51009509 for ; Tue, 19 Nov 2002 22:10:56 -0700 (MST) Received: [from zin05exm02.corp.mot.com (zin05exm02.corp.mot.com [10.232.0.1]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id WAA26194 for ; Tue, 19 Nov 2002 22:10:54 -0700 (MST)] Received: by zin05exm02.corp.mot.com with Internet Mail Service (5.5.2656.59) id ; Wed, 20 Nov 2002 10:40:53 +0530 Message-ID: <653138C25D8AD6118292000347080A37018F330C@zin05exm02.corp.mot.com> From: T Satyanarayana-A12694 To: sip@ietf.org Date: Wed, 20 Nov 2002 10:40:52 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] test message 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: , _______________________________________________ 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 Nov 20 00:25:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17792 for ; Wed, 20 Nov 2002 00:25:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAK5RLF11084 for sip-archive@odin.ietf.org; Wed, 20 Nov 2002 00:27: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 gAK5NIv11016; Wed, 20 Nov 2002 00:23: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 gAK5Eav10737 for ; Wed, 20 Nov 2002 00:14:36 -0500 Received: from harrier.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17642 for ; Wed, 20 Nov 2002 00:11:46 -0500 (EST) Received: from user-v7kakol.dialup.mindspring.com ([207.69.83.21]) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18ENBw-0000DB-00 for sip@ietf.org; Tue, 19 Nov 2002 21:14:24 -0800 Date: Wed, 20 Nov 2002 00:14:22 -0500 From: Cyrus Shaoul To: sip@ietf.org Message-Id: <20021119235354.620A.CYRUS@ntt-at.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.06 Content-Transfer-Encoding: 7bit Subject: [Sip] Unicode in Response codes. 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 SIP list members, I am new to SIP, and I wanted to confirm one thing: In RFC 3261, Section 7, it is stated that: "SIP is a text-based protocol and uses the UTF-8 charset." Also, there is a discussion of using UTF-8 in descriptive text in section 25.1 Reason-Phrase = *(reserved / unreserved / escaped / UTF8-NONASCII / UTF8-CONT / SP / HTAB) My question: Hypothetically, if the Accept-Language (sec 20.3) header was set for Japanese in a request by an entity, it could put Japanese UTF-8 text in a reason phrase and still be in compliance with the RFC. What if a server couldn't satisfy the language preferences of the client (ex: client prefers only Japanese, server only supports English)? In that case the UA will not be able to create a localized experience for the user. If a UA went on to display localized (translated) messages in the user interface based on the response code (i.e. from a set of translations of all the messages in RFC 3261 section 25), and not display the originial English text in the SIP response, would that cause any problems? Again, this is all hypothetical for now, but I am trying to think about internationalization issues after hearing a discussion about them in another WG today at IETF 55. Thanks, Cyrus cyrus@ntt-at.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 Nov 20 00:32:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17947 for ; Wed, 20 Nov 2002 00:32:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAK5YUr11305 for sip-archive@odin.ietf.org; Wed, 20 Nov 2002 00:34: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 gAK5UBv11205; Wed, 20 Nov 2002 00:30: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 gAK5Rqv11113 for ; Wed, 20 Nov 2002 00:27:52 -0500 Received: from web20704.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA17791 for ; Wed, 20 Nov 2002 00:25:02 -0500 (EST) Message-ID: <20021120052741.40951.qmail@web20704.mail.yahoo.com> Received: from [204.42.69.176] by web20704.mail.yahoo.com via HTTP; Tue, 19 Nov 2002 21:27:41 PST Date: Tue, 19 Nov 2002 21:27:41 -0800 (PST) From: Sean Olson Subject: Re: [Sip] Unicode in Response codes. To: Cyrus Shaoul , sip@ietf.org In-Reply-To: <20021119235354.620A.CYRUS@ntt-at.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: , A reasonable implementation option would be to localize based on the response code and not based on the reason phrase. But this is a good thing to document somewhere. There was discussion on having an I-D for i18n topics and SIP. I don't know the status of this, but this would be a good item to add to that draft. Regards, Sean --- Cyrus Shaoul wrote: > > Dear SIP list members, > > I am new to SIP, and I wanted to confirm one thing: > In RFC 3261, Section 7, it is stated that: > > "SIP is a text-based protocol and uses the UTF-8 > charset." > > Also, there is a discussion of using UTF-8 in > descriptive text in > section 25.1 > > Reason-Phrase = *(reserved / unreserved / > escaped > / UTF8-NONASCII / UTF8-CONT / SP > / HTAB) > > My question: Hypothetically, if the Accept-Language > (sec 20.3) header > was set for Japanese in a request by an entity, it > could put Japanese > UTF-8 text in a reason phrase and still be in > compliance with the RFC. > What if a server couldn't satisfy the language > preferences of the client > (ex: client prefers only Japanese, server only > supports English)? In > that case the UA will not be able to create a > localized experience for > the user. > If a UA went on to display localized (translated) > messages in the user > interface based on the response code (i.e. from a > set of translations of > all the messages in RFC 3261 section 25), and not > display the originial > English text in the SIP response, would that cause > any problems? > > Again, this is all hypothetical for now, but I am > trying to think about > internationalization issues after hearing a > discussion about them in > another WG today at IETF 55. > > Thanks, > > Cyrus > cyrus@ntt-at.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 __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.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 Nov 20 01:29:37 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18857 for ; Wed, 20 Nov 2002 01:29:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAK6Vu614185 for sip-archive@odin.ietf.org; Wed, 20 Nov 2002 01:31: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 gAK6Rav14050; Wed, 20 Nov 2002 01:27: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 gAK6Nav13897 for ; Wed, 20 Nov 2002 01:23:36 -0500 Received: from hawk.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18675 for ; Wed, 20 Nov 2002 01:20:46 -0500 (EST) Received: from user-v7kakol.dialup.mindspring.com ([207.69.83.21]) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18EOGh-0006hQ-00; Tue, 19 Nov 2002 22:23:24 -0800 Date: Wed, 20 Nov 2002 01:23:22 -0500 From: Cyrus Shaoul To: Sean Olson Subject: Re[2]: [Sip] Unicode in Response codes. Cc: sip@ietf.org In-Reply-To: <20021120052741.40951.qmail@web20704.mail.yahoo.com> References: <20021119235354.620A.CYRUS@ntt-at.com> <20021120052741.40951.qmail@web20704.mail.yahoo.com> Message-Id: <20021120011814.BCFC.CYRUS@ntt-at.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.06 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 Sean, Is this the draft you were thinking of? draft-fujimoto-sipping-header-lang-00.txt I will take a look at it. Does this mean that this kind of issue is under the SIPPING charter, not the SIP charter? Thank you, Cyrus On Tue, 19 Nov 2002 21:27:41 -0800 (PST) Sean Olson wrote: seancolson> A reasonable implementation option would be to seancolson> localize based on the response code and not based seancolson> on the reason phrase. But this is a good thing seancolson> to document somewhere. There was discussion on seancolson> having an I-D for i18n topics and SIP. I don't know seancolson> the status of this, but this would be a good item seancolson> to add to that draft. seancolson> seancolson> Regards, seancolson> Sean seancolson> seancolson> seancolson> --- Cyrus Shaoul wrote: seancolson> > seancolson> > Dear SIP list members, seancolson> > seancolson> > I am new to SIP, and I wanted to confirm one thing: seancolson> > In RFC 3261, Section 7, it is stated that: seancolson> > seancolson> > "SIP is a text-based protocol and uses the UTF-8 seancolson> > charset." seancolson> > seancolson> > Also, there is a discussion of using UTF-8 in seancolson> > descriptive text in seancolson> > section 25.1 seancolson> > seancolson> > Reason-Phrase = *(reserved / unreserved / seancolson> > escaped seancolson> > / UTF8-NONASCII / UTF8-CONT / SP seancolson> > / HTAB) seancolson> > seancolson> > My question: Hypothetically, if the Accept-Language seancolson> > (sec 20.3) header seancolson> > was set for Japanese in a request by an entity, it seancolson> > could put Japanese seancolson> > UTF-8 text in a reason phrase and still be in seancolson> > compliance with the RFC. seancolson> > What if a server couldn't satisfy the language seancolson> > preferences of the client seancolson> > (ex: client prefers only Japanese, server only seancolson> > supports English)? In seancolson> > that case the UA will not be able to create a seancolson> > localized experience for seancolson> > the user. seancolson> > If a UA went on to display localized (translated) seancolson> > messages in the user seancolson> > interface based on the response code (i.e. from a seancolson> > set of translations of seancolson> > all the messages in RFC 3261 section 25), and not seancolson> > display the originial seancolson> > English text in the SIP response, would that cause seancolson> > any problems? seancolson> > seancolson> > Again, this is all hypothetical for now, but I am seancolson> > trying to think about seancolson> > internationalization issues after hearing a seancolson> > discussion about them in seancolson> > another WG today at IETF 55. seancolson> > seancolson> > Thanks, seancolson> > seancolson> > Cyrus seancolson> > cyrus@ntt-at.com seancolson> > seancolson> > _______________________________________________ seancolson> > Sip mailing list seancolson> > https://www1.ietf.org/mailman/listinfo/sip seancolson> > This list is for NEW development of the core SIP seancolson> > Protocol seancolson> > Use sip-implementors@cs.columbia.edu for questions seancolson> > on current sip seancolson> > Use sipping@ietf.org for new developments on the seancolson> > application of sip seancolson> seancolson> seancolson> __________________________________________________ seancolson> Do you Yahoo!? seancolson> Yahoo! Web Hosting - Let the expert host your site seancolson> http://webhosting.yahoo.com seancolson> _______________________________________________ seancolson> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip seancolson> This list is for NEW development of the core SIP Protocol seancolson> Use sip-implementors@cs.columbia.edu for questions on current sip seancolson> 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 Nov 20 05:49:43 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16093 for ; Wed, 20 Nov 2002 05:49:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAKApqI04539 for sip-archive@odin.ietf.org; Wed, 20 Nov 2002 05:51: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 gAKAl3v04377; Wed, 20 Nov 2002 05:47: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 gAKAiQv04293 for ; Wed, 20 Nov 2002 05:44:26 -0500 Received: from fgwmail7.fujitsu.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16044 for ; Wed, 20 Nov 2002 05:41:45 -0500 (EST) Received: from m2.gw.fujitsu.co.jp by fgwmail7.fujitsu.co.jp (8.9.3/3.7W-MX0205-Fujitsu Gateway) id TAA15509 for ; Wed, 20 Nov 2002 19:44:23 +0900 (JST) (envelope-from shingo_fujimoto@jp.fujitsu.com) Received: from dm.akashi.flab.fujitsu.co.jp by m2.gw.fujitsu.co.jp (8.12.1/Fujitsu Domain Master) id gAKAiNNc029288 for ; Wed, 20 Nov 2002 19:44:23 +0900 (envelope-from shingo_fujimoto@jp.fujitsu.com) Received: from dm.akashi.flab.fujitsu.co.jp by dm.akashi.flab.fujitsu.co.jp (8.9.3/3.7W-020129-Fujitsu Labs. Akashi Domain Mail Master) id TAA13677; Wed, 20 Nov 2002 19:44:22 +0900 (JST) Received: from kmailserv.akashi.flab.fujitsu.co.jp ([10.254.200.15]) by dm.akashi.flab.fujitsu.co.jp (NAVGW 2.5.2.9) with SMTP id M2002112019442229096 ; Wed, 20 Nov 2002 19:44:22 +0900 Received: from jp.fujitsu.com (taka.pssys.flab.fujitsu.co.jp [10.254.215.65]) by kmailserv.akashi.flab.fujitsu.co.jp (8.11.6+Sun/8.11.6) with ESMTP id gAKAiMJ00281; Wed, 20 Nov 2002 19:44:22 +0900 (JST) Message-ID: <3DDB6790.2030007@jp.fujitsu.com> Date: Wed, 20 Nov 2002 19:44:32 +0900 From: Shingo Fujimoto Organization: Fujitsu Labs LTD User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: ja MIME-Version: 1.0 To: Cyrus Shaoul CC: sip@ietf.org Subject: Re: [Sip] Unicode in Response codes. References: <20021119235354.620A.CYRUS@ntt-at.com> <20021120052741.40951.qmail@web20704.mail.yahoo.com> <20021120011814.BCFC.CYRUS@ntt-at.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 I have posted the summary of discussion on Oct 16. And now, I am working on new drafts (requirement and proposal I-D). Since IETF meeting is on going, I am planning to finish and post it in December. If you have any new requirements regarding UTF8 headers, I will put them in new draft. If you could not find my post, please let me know then I will send it to you privately. Best. Cyrus Shaoul wrote: > Sean, > > Is this the draft you were thinking of? > > draft-fujimoto-sipping-header-lang-00.txt > > I will take a look at it. Does this mean that this kind of issue is > under the SIPPING charter, not the SIP charter? > > Thank you, > > Cyrus > -- ====================================== SHINGO FUJIMOTO FUJITSU LABORATORIES LIMITED E-mail: shingo_fujimoto@jp.fujitsu.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 Nov 20 06:54:44 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16861 for ; Wed, 20 Nov 2002 06:54:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAKBusp07974 for sip-archive@odin.ietf.org; Wed, 20 Nov 2002 06:56: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 gAKBr3v07816; Wed, 20 Nov 2002 06:53: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 gAKBi9v07524 for ; Wed, 20 Nov 2002 06:44:09 -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 GAA16710 for ; Wed, 20 Nov 2002 06:41:27 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAKBhwQ1012309; Wed, 20 Nov 2002 12:44:02 +0100 (MET) Received: from lmf.ericsson.se (vrrch2-177122.am.ericsson.se [138.85.177.122]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id gAKBhoCG000346; Wed, 20 Nov 2002 13:43:55 +0200 (EET) Message-ID: <3DDB75BC.8AEF2A38@lmf.ericsson.se> Date: Wed, 20 Nov 2002 13:45:00 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] The fate of session timer? References: <3DD3B930.E6230AC3@lmf.ericsson.se> <3DD4A760.BD1FF3C3@lmf.ericsson.se> <3DD89B30.9010709@dynamicsoft.com> <3DD8DE55.34DF9786@lmf.ericsson.se> <3DDAB04E.3010803@dynamicsoft.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 Hi, > >Hi, > > >>>So, my question is: if a value is too small for a proxy, what is the > >>>reason it simply can't change the value and forward the INVITE? In > >>>that case the INVITE will receive the UAS, and the final response > >>>will indicate the refresh value which will actually be used. > >> > >>There are two reasons. > >> > >>The first is documented in the security considerations section: > >> > >> > >>>Next, consider the case of a rogue UAS that wishes to force a UAC to > >>>generate refreshes at a rapid rate. In that case, the UAC has to > >>>support session timer. The initial INVITE arrives at the rogue UAS, > >>>which returns a 2xx with a very small session interval. The UAC uses > >>>this timer, and quickly sends a refresh. Section 7.1 requires the UAC > >>>to copy the current session interval into the Session-Expires header > >>>field in the request. This enables the proxies to see the current > >>>value. The proxies will reject this request, and provide a Min-SE > >>>with a higher minimum. The UAC will then use this higher minimum. > >>>Note, that if the proxies did not reject the request, but rather > >>>proxied the request with a Min-SE header field, an attack would still > >>>be possible. The UAS could discard this header field in a 2xx > >>>response, and force the UAC to continue to generate rapid requests. > >> > >>So, the change you suggest would introduce a dos attack that a rogue UAS > >>could launch on a UAC. > > > > > > The UAC would include a minimum value in the request, which proxies are only > > allowed to INCREASE, if needed. If the UAC then receives 200 OK with a SMALLER > > value it knows something went wrong, so it would probably choose to release > > the call. Every proxy, when receiving the 200 response, would also see that > > something has gone wrong, since the value is smaller than the value set in the > > INVITE request. > > That doesn't work. It relies on behavior at the UAS. That is the place > where the rogue element is. Once you assume you cannot trust the UAS, > you must rely on the proxy before it to generate an error response. I > believe there is no way around that. [CHH] Assuming that the proxies DO accept the value proposed by the UAC, and the INVITE reaches the UAS, the UAS can still insert a SMALLER value, and the situation will be the same, won't it? 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 Thu Nov 21 00:55:17 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13089 for ; Thu, 21 Nov 2002 00:55:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAL5vae12773 for sip-archive@odin.ietf.org; Thu, 21 Nov 2002 00:57: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 gAL5t8v12672; Thu, 21 Nov 2002 00:55: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 gAL5iSv12394 for ; Thu, 21 Nov 2002 00:44:28 -0500 Received: from em.njupt.edu.cn (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA12933 for ; Thu, 21 Nov 2002 00:41:22 -0500 (EST) Message-Id: <200211210541.AAA12933@ietf.org> Received: (qmail 21288 invoked from network); 21 Nov 2002 06:11:29 -0000 Received: from unknown (HELO toto) (10.10.3.123) by em.njupt.edu.cn with SMTP; 21 Nov 2002 06:11:29 -0000 Date: Thu, 21 Nov 2002 13:48:43 +0800 From: feng zhang Reply-To: y01317@njupt.edu.cn To: "sip@ietf.org" Organization: NUPT-CED202 X-mailer: FoxMail 4.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id gAL5iSv12395 Subject: [Sip] callerprefs-07 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, I think there are lots of changes between draft-ietf-sip-callerprefs-07 and draft-ietf-sip-callerprefs-06, but the author does not state the "Changes" part, I want to know what's the detailed difference? Can the authors give me an answer? Thanks a lot! ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡ _______________________________________________ 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 Nov 21 13:15:01 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13588 for ; Thu, 21 Nov 2002 13:15:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gALIHEO03907 for sip-archive@odin.ietf.org; Thu, 21 Nov 2002 13:17: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 gALIAjv03513; Thu, 21 Nov 2002 13:10: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 gALI5Ov02696 for ; Thu, 21 Nov 2002 13:05:24 -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 NAA12893 for ; Thu, 21 Nov 2002 13:02:39 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gALI59YH005804; Thu, 21 Nov 2002 13:05:15 -0500 (EST) Message-ID: <3DDD2053.2020106@dynamicsoft.com> Date: Thu, 21 Nov 2002 13:05:07 -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: y01317@njupt.edu.cn CC: "sip@ietf.org" Subject: Re: [Sip] callerprefs-07 References: <200211210541.AAA12933@ietf.org> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit 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 I emailed a list of changes to the list. Here is the message: http://www.ietf.org/mail-archive/working-groups/sip/current/msg06848.html -Jonathan R. feng zhang wrote: > Hi all, > > I think there are lots of changes between draft-ietf-sip-callerprefs-07 and draft-ietf-sip-callerprefs-06, but the author does not state the "Changes" part, I want to know what's the detailed difference? > Can the authors give me an answer? > > Thanks a lot! > > > ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡ > _______________________________________________ > 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 > -- 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 Fri Nov 22 00:41:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07305 for ; Fri, 22 Nov 2002 00:41:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAM5i7s14001 for sip-archive@odin.ietf.org; Fri, 22 Nov 2002 00:44: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 gAM5fev13903; Fri, 22 Nov 2002 00:41:40 -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 gAM5XAv13010 for ; Fri, 22 Nov 2002 00:33:10 -0500 Received: from web40611.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07111 for ; Fri, 22 Nov 2002 00:30:20 -0500 (EST) Message-ID: <20021122053259.46062.qmail@web40611.mail.yahoo.com> Received: from [202.144.91.188] by web40611.mail.yahoo.com via HTTP; Thu, 21 Nov 2002 21:32:59 PST Date: Thu, 21 Nov 2002 21:32:59 -0800 (PST) From: Mukta Singh To: sip@ietf.org Cc: mukta@ipen-india.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Sip] SIP Call Handoff 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, Can anyone tell me, Is there any draft on the SIP call handoff ? If yes ,please specify where it is available. thanks in advance Mukta Axes Technologies (I) Pvt. Ltd IDC,Bangalore __________________________________________________ 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 Nov 22 01:32:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07974 for ; Fri, 22 Nov 2002 01:32:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAM6Ymm16205 for sip-archive@odin.ietf.org; Fri, 22 Nov 2002 01:34: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 gAM6WSv16095; Fri, 22 Nov 2002 01:32: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 gAM6SUv15944 for ; Fri, 22 Nov 2002 01:28:30 -0500 Received: from web14502.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA07860 for ; Fri, 22 Nov 2002 01:25:39 -0500 (EST) Message-ID: <20021122062820.73603.qmail@web14502.mail.yahoo.com> Received: from [203.199.207.197] by web14502.mail.yahoo.com via HTTP; Thu, 21 Nov 2002 22:28:20 PST Date: Thu, 21 Nov 2002 22:28:20 -0800 (PST) From: sip learner To: sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1941791222-1037946500=:73558" Subject: [Sip] two 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: , --0-1941791222-1037946500=:73558 Content-Type: text/plain; charset=us-ascii Sir, I am a student started working on sip. please clarify my douths: 1.SIP uses offer/anwer model to negotiate session parameters. does this mean that invite/ok/ack transaction. 2/what is a dialogue mean in SIP?? can any one please help me in knowing more about these 2 questions. -SL --------------------------------- Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now --0-1941791222-1037946500=:73558 Content-Type: text/html; charset=us-ascii

Sir,

       I am a student started working on sip.

please  clarify  my douths:

1.SIP uses offer/anwer model to negotiate session parameters.

   does this mean that invite/ok/ack transaction.

2/what is a dialogue mean in SIP?? can any one please help me in knowing more about these 2 questions.

-SL


Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now --0-1941791222-1037946500=:73558-- _______________________________________________ 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 Nov 22 04:21:20 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21173 for ; Fri, 22 Nov 2002 04:21:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAM9Neq03456 for sip-archive@odin.ietf.org; Fri, 22 Nov 2002 04:23: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 gAM8qrv01133; Fri, 22 Nov 2002 03:52: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 gAM8hlv00812 for ; Fri, 22 Nov 2002 03:43:47 -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 DAA20364 for ; Fri, 22 Nov 2002 03:40:57 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 22 Nov 2002 00:43:36 -0800 Received: from 61.11.237.4 by lw8fd.law8.hotmail.msn.com with HTTP; Fri, 22 Nov 2002 08:43:35 GMT X-Originating-IP: [61.11.237.4] From: "Ritesh Maheshwari" To: sip@ietf.org Cc: sip-implementors@cs.columbia.edu Date: Fri, 22 Nov 2002 08:43:35 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Nov 2002 08:43:36.0121 (UTC) FILETIME=[3F1CE290:01C29203] Subject: [Sip] SCTP-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, I read the draft on SCTP usage for SIP which is due to expire in December. Is there any group working on that matter currently? And if yes please tell me what is the website/email and what work has been done till now? Regards, Ritesh Maheshwari Final yr, BTech Computer Sci & Engg, IIT Kharagpur, INDIA _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ 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 Nov 22 05:16:38 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21952 for ; Fri, 22 Nov 2002 05:16:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAMAIlL06291 for sip-archive@odin.ietf.org; Fri, 22 Nov 2002 05:18: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 gAM9sYv05011; Fri, 22 Nov 2002 04:54:34 -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 gAM9kqv04774 for ; Fri, 22 Nov 2002 04:46:52 -0500 Received: from qmail-b.directi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21538 for ; Fri, 22 Nov 2002 04:43:55 -0500 (EST) Received: (qmail 32426 invoked by uid 0); 22 Nov 2002 09:46:31 -0000 Received: from unknown (HELO server) (203.129.216.97) by 203.199.107.94 with SMTP; 22 Nov 2002 09:46:31 -0000 Message-ID: <001401c2920c$33446b60$61d881cb@iLocus.ilocus.com> From: "sumir" To: Date: Fri, 22 Nov 2002 15:17:32 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C2923A.47C0C790" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: [Sip] SIP STACK MARKET PLACE 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_000F_01C2923A.47C0C790 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable HI friends I would like to have some information on SIP Stack and have these = questions:=20 Q What is sip toolkit? How is it related to sip stack? Q Technically speaking what is involved in developing these stacks? Q What is the order of development, where to start? Plz help me in giving links, resources and answers releated to SIP = STACKS... Your effort will be appreciated Withwarm regards! SAM =20 ------=_NextPart_000_000F_01C2923A.47C0C790 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
HI=20 friends
 
I would like to have some information on SIP Stack and = have these=20 questions:
Q    What is sip toolkit? = How is it=20 related to sip=20 stack?
Q    Technically speaking = what is=20 involved in developing these=20 stacks?
=
Q    What is the order of = development,=20 where to start?
 
Plz help me in giving links, resources and answers releated to = SIP=20 STACKS...
 
Your effort will be appreciated
 
Withwarm regards!
SAM
 
 
 
 
------=_NextPart_000_000F_01C2923A.47C0C790-- _______________________________________________ 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 Nov 25 02:31:44 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21829 for ; Mon, 25 Nov 2002 02:31:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAP7Y6K14990 for sip-archive@odin.ietf.org; Mon, 25 Nov 2002 02:34: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 gAP7XKv14962; Mon, 25 Nov 2002 02:33: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 gAP7Rvv14749 for ; Mon, 25 Nov 2002 02:27:57 -0500 Received: from em.njupt.edu.cn (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA21774 for ; Mon, 25 Nov 2002 02:25:04 -0500 (EST) Message-Id: <200211250725.CAA21774@ietf.org> Received: (qmail 29014 invoked from network); 25 Nov 2002 07:55:37 -0000 Received: from unknown (HELO toto) (10.10.3.123) by em.njupt.edu.cn with SMTP; 25 Nov 2002 07:55:37 -0000 Date: Mon, 25 Nov 2002 15:33:19 +0800 From: feng zhang Reply-To: y01317@njupt.edu.cn To: "sip@ietf.org" Organization: NUPT-CED202 X-mailer: FoxMail 4.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id gAP7Rvv14750 Subject: [Sip] sec-agree-05 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, Can the authors of draft-ietf-sip-sec-agree-05 give me the Changes list to let me know what's the detailed differences between 05 and 04. Thanks a lot! ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡feng zhang ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡y01317@njupt.edu.cn ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2002-11-25 _______________________________________________ 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 Nov 25 06:04:55 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24264 for ; Mon, 25 Nov 2002 06:04:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAPB78o25612 for sip-archive@odin.ietf.org; Mon, 25 Nov 2002 06:07: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 gAPB6Hv25283; Mon, 25 Nov 2002 06: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 gAPB3Cv25209 for ; Mon, 25 Nov 2002 06:03:12 -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 GAA24189 for ; Mon, 25 Nov 2002 06:00:12 -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 gAPB2mQ1006221; Mon, 25 Nov 2002 12:02:48 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 25 Nov 2002 12:02:47 +0100 Message-ID: From: "Vesa Torvinen (LMF)" To: "'y01317@njupt.edu.cn'" Cc: sip@ietf.org Subject: RE: [Sip] sec-agree-05 Date: Mon, 25 Nov 2002 11:31:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAPB3Cv25210 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 Feng, Find below a summary of changes. Vesa -------------- - The beginning has been partly re-written in order to make it more readable and focused. Sections 1, 2, and 3.1 has been merged as new section 1. Some text has been moved to section 5 (Security Consideratins). - S/MIME in the context of SIP is intended to be used end-to-end, but sec-agree only negotiates hop-by-hop. The ability to negotiate S/MIME has been removed. - The HTTP Digest part has been re-designed, see the solution in sections 2.2 and 2.4. - Resolved that if you follow 3263 and end up using TLS you skip sec-agree, and for non-TLS connections you can use sec-agree to detect DNS spoofing. See the first paragraph in sections 2.3.1. - Section 3 includes new text about the use of this extension: is a matter of local policy, and could be situational in nature. - Section discussing proxy-to-proxy negotiation has been removed (ex-3.4.2) because the removal of Via headers conflicts with Sections 8.2.6 and 16.7 of RFC 3261. - Message examples added to section 4.2. - Rules for introducing new 'security mechanisms' are defined in section '6. IANA Considerations'. - Many minor editorial changes. For example, the references have been updated. - A 3GPP specific extension has been added, see Appendix A. -----Original Message----- From: feng zhang [mailto:y01317@njupt.edu.cn] Sent: 25. marraskuuta 2002 9:33 To: sip@ietf.org Subject: [Sip] sec-agree-05 Hi all, Can the authors of draft-ietf-sip-sec-agree-05 give me the Changes list to let me know what's the detailed differences between 05 and 04. Thanks a lot! ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡feng zhang ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡y01317@njupt.edu.cn ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2002-11-25 _______________________________________________ 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 Nov 25 08:22:27 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26798 for ; Mon, 25 Nov 2002 08:22:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAPDOeZ32363 for sip-archive@odin.ietf.org; Mon, 25 Nov 2002 08:24: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 gAPDO8v32342; Mon, 25 Nov 2002 08:24: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 gAPDLlv32261 for ; Mon, 25 Nov 2002 08:21:47 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26468; Mon, 25 Nov 2002 08:19:02 -0500 (EST) Message-Id: <200211251319.IAA26468@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: Mon, 25 Nov 2002 08:19:02 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-content-indirect-mech-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 : A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages Author(s) : S. Olson Filename : draft-ietf-sip-content-indirect-mech-01.txt Pages : 13 Date : 2002-11-21 This Internet-Draft proposes an extension to the URL MIME External- Body Access-Type to satisfy the content indirection requirements for SIP. These extensions are aimed at allowing any MIME part in a SIP message to be referred to indirectly via a URI. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-content-indirect-mech-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-content-indirect-mech-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-content-indirect-mech-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: <2002-11-21133936.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-content-indirect-mech-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-content-indirect-mech-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-21133936.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 Mon Nov 25 08:53:37 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27958 for ; Mon, 25 Nov 2002 08:53:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAPDtpk01779 for sip-archive@odin.ietf.org; Mon, 25 Nov 2002 08:55: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 gAPDtUv01731; Mon, 25 Nov 2002 08:55: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 gAPDqav01540 for ; Mon, 25 Nov 2002 08:52:36 -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 IAA27800 for ; Mon, 25 Nov 2002 08:49:51 -0500 (EST) Received: from hendrix.lmf.ericsson.se (hendrix.lmf.ericsson.se [131.160.11.8]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAPDqUKV009878; Mon, 25 Nov 2002 14:52:31 +0100 (MET) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.3]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id gAPDqUu4025881; Mon, 25 Nov 2002 15:52:30 +0200 (EET) Message-ID: <3DE22B1C.EEBAA2F0@lmf.ericsson.se> Date: Mon, 25 Nov 2002 15:52:28 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ritesh Maheshwari CC: sip@ietf.org, sip-implementors@cs.columbia.edu Subject: Re: [Sip] SCTP-SIP 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 the draft you are referring to is in IETF LC. Gonzalo Ritesh Maheshwari wrote: > > hi, > > I read the draft on SCTP usage for SIP which is due to expire in December. > Is there any group working on that matter currently? And if yes please tell > me what is the website/email and what work has been done till now? > > Regards, > Ritesh Maheshwari > Final yr, BTech > Computer Sci & Engg, > IIT Kharagpur, > INDIA > > _________________________________________________________________ > The new MSN 8: advanced junk mail protection and 2 months FREE* > http://join.msn.com/?page=features/junkmail > > _______________________________________________ > 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 Nov 25 10:08:56 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02320 for ; Mon, 25 Nov 2002 10:08:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAPFBBJ06960 for sip-archive@odin.ietf.org; Mon, 25 Nov 2002 10:11: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 gAPFAiv06932; Mon, 25 Nov 2002 10:10: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 gAPF9Nv06844 for ; Mon, 25 Nov 2002 10:09:23 -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 KAA02193 for ; Mon, 25 Nov 2002 10:06:37 -0500 (EST) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAPF9Koh029950 for ; Mon, 25 Nov 2002 07:09:20 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABI42443; Mon, 25 Nov 2002 07:06:55 -0800 (PST) Date: Sat, 23 Nov 2002 22:36:31 -0500 Mime-Version: 1.0 (Apple Message framework v548) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Rohan Mahy To: sip@ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.548) Content-Transfer-Encoding: 7bit Subject: [Sip] Requesting review of Join header 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 believe that the Join header (a new WG item) is nearly complete. While it cannot be published until the conferencing work is closer to done, please give it a quick read and provide comments. many thanks, -rohan _______________________________________________ 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 Nov 25 16:45:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27297 for ; Mon, 25 Nov 2002 16:45:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAPLmCS32421 for sip-archive@odin.ietf.org; Mon, 25 Nov 2002 16:48:12 -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 gAPLlVv32396; Mon, 25 Nov 2002 16:47: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 gAPLk0v32351 for ; Mon, 25 Nov 2002 16:46:00 -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 QAA27232 for ; Mon, 25 Nov 2002 16:43:10 -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 gAPLjrQs027941 for ; Mon, 25 Nov 2002 15:45:53 -0600 Received: (from dwillis@localhost) by bdsl.greycouncil.com (8.12.5/8.12.5/Submit) id gAPLjrsp027939 for sip@ietf.org; Mon, 25 Nov 2002 15:45:53 -0600 X-Authentication-Warning: bdsl.greycouncil.com: dwillis set sender to dean.willis@softarmor.com using -f From: Dean Willis To: sip@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1038260753.27269.33.camel@bdsl.greycouncil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 25 Nov 2002 15:45:53 -0600 Content-Transfer-Encoding: 7bit Subject: [Sip] DISCUSS on Service Route Discovery 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 cool new ID tracker: https://datatracker.ietf.org/public/pidtracker.cgi shows that we have an IESG "Discuss" on the Service Route Discovery draft: http://www.ietf.org/internet-drafts/draft-ietf-sip-scvrtdisco-02.txt which is currently in the "IESG Evaluation" phase of IETF Last Call. The specific issues raised are: --------------- The Security Considerations section is confusing, and (I think) wrong. The first paragraph speaks of proxies modifying things. This is indeed a threat. But the end of that paragraph and the next speak of using transport security between proxies. That does nothing against this threat -- the problem occurs from misbehavior by the authorized proxy. Transport security protects against MITM attacks, not nasty endpoints. The note at the end of the second paragrap, suggesting S/MIME, is the correct answer against this threat. Transport-level security might be useful against other threats. I suspect that fixing the first sentence of Section 7 to speak of MITMs instead of proxies will clear up the confusion; the issue of misbehaving proxies can be described briefly in the second paragraph. I'm also concerned that there's no mandatory-to-implement specified (or is S/MIME support required of Registrars elsewhere?). If not, there should be some text somewhere mandating implementation of it, though (of course) not necessarily use; the current "SHOULD" language is sufficient. --------------- The first problem is that we have intermingled MITM and misbehaving proxies. This can be easily rectified, I think, as suggested in the DISCUSS. The second concern seems to be more interesting. Is it reasonable to mandate that registrars implementing the Service-Route header field also MUST implement S/MIME? This doesn't say they have to USE it, just that they must IMPLEMENT it. My personal feeling is that implementing this in a registrar is fairly straightforward, and even the key management is easy, so it "does no harm" to include as a MUST. What do you think? -- Dean Willis _______________________________________________ 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 Nov 25 18:34:17 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00926 for ; Mon, 25 Nov 2002 18:34:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAPNaaH05316 for sip-archive@odin.ietf.org; Mon, 25 Nov 2002 18:36: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 gAPNaAv05300; Mon, 25 Nov 2002 18:36: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 gAPNYIv05225 for ; Mon, 25 Nov 2002 18:34:18 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00812; Mon, 25 Nov 2002 18:31:28 -0500 (EST) Message-Id: <200211252331.SAA00812@ietf.org> To: IETF-Announce: ; Cc: sip@ietf.org From: The IESG Reply-to: iesg@ietf.org Date: Mon, 25 Nov 2002 18:31:28 -0500 Subject: [Sip] Last Call: An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing to Proposed Standard 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: , The IESG has received a request from the Session Initiation Protocol Working Group to consider An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2002-12-9. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-symmetric-response-00.txt _______________________________________________ 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 Nov 25 21:06:06 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05896 for ; Mon, 25 Nov 2002 21:06:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAQ28Q213814 for sip-archive@odin.ietf.org; Mon, 25 Nov 2002 21:08: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 gAQ27vv13798; Mon, 25 Nov 2002 21:07: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 gAQ26Uv13176 for ; Mon, 25 Nov 2002 21:06:30 -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 VAA05841 for ; Mon, 25 Nov 2002 21:03:39 -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 gAQ25Fg2004980; Mon, 25 Nov 2002 21:05:16 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Nov 2002 20:06:20 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64347@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Dean Willis'" , sip@ietf.org Subject: RE: [Sip] DISCUSS on Service Route Discovery Date: Mon, 25 Nov 2002 20:06:11 -0600 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: , > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > > The second concern seems to be more interesting. Is it reasonable to > mandate that registrars implementing the Service-Route header > field also > MUST implement S/MIME? This doesn't say they have to USE it, just that > they must IMPLEMENT it. > > My personal feeling is that implementing this in a registrar is fairly > straightforward, and even the key management is easy, so it "does no > harm" to include as a MUST. I'm inclined to agree; first, though, I'd like to understand the threat posed by a registrar that doesn't/can't use S/MIME versus one that can. Not in the general context of registering, of course -- only in the context of the extra functionality introduced by srvrtdisco. It's not obvious to me that this point is addressing an issue raised by *this* draft, versus a general issue with SIP -- and it would be Obviously Wrong (tm) to fix problems in the base spec in every other document that mentions it, as opposed to just recording it as a bug and fixing it next go round. /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 Tue Nov 26 01:22:30 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11700 for ; Tue, 26 Nov 2002 01:22:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAQ6Opp25605 for sip-archive@odin.ietf.org; Tue, 26 Nov 2002 01:24: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 gAQ6OCv25577; Tue, 26 Nov 2002 01:24: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 gAQ6LOv25506 for ; Tue, 26 Nov 2002 01:21:24 -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 BAA11653 for ; Tue, 26 Nov 2002 01:18:32 -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 gAQ6KAg2005513 for ; Tue, 26 Nov 2002 01:20:11 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Nov 2002 00:21:13 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A6434B@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'sip@ietf.org'" Date: Tue, 26 Nov 2002 00:21:10 -0600 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 gAQ6LOv25507 Subject: [Sip] i18n issue: composed characters 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 While digging through the confctrl archives, circa 08/99, I came across a thread that probably shouldn't be lost now that we have started giving internationalization more serious thought. With Unicode, there are two different ways to encode most accented Latin characters. I beleive the same issue occurs in several other character sets (e.g. composition of Korean Hangul versus use of precomposed characters). For example, the character "Å" (an "A" with a loop over it) can be encoded in Unicode as U+00C5 or as U+212B or as the combination U+0041 U+030A. Now, with multiple possible encodings for single characters, we have the problem of, for example, someone registering as "sip:%C3%85se@bolaget.no", and someone else inviting "sip:A%CC%8Ase@bolaget.no". In both cases, the interface would render the user portion as "Åse" to the users, but matching is difficult. Of course, we *could* just leave this as a server implementation issue. This is a bit of a pain, since it means that *all* servers need to perform normalization of unicode characters before doing any processing. Bleah. Alternately, taking the suggestion Kevin Payne made so many years ago, we could specify that any user agent that has the ability to accept characters that might have multiple Unicode encodings is responsible for normalization of that input to a single, canonical form. My understanding is that Unicode defines at least two methods of normalization (Canonical and Compatibility), and that a proposal was floated to define two *additional* methods by performing the decomposition described by Unicode, followed by a canonical composition. This has the advantage of taking less space. It's not clear whether this method [1] made it into any Unicode standards. So, do we want to address this issue at all, or so we just let things break? /a [1] http://www.unicode.org/unicode/reports/tr15/tr15-10.html _______________________________________________ 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 Nov 26 02:09:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22910 for ; Tue, 26 Nov 2002 02:09:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAQ7CJY03580 for sip-archive@odin.ietf.org; Tue, 26 Nov 2002 02:12:19 -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 gAQ7BZv03546; Tue, 26 Nov 2002 02:11: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 gAQ7Ajv02992 for ; Tue, 26 Nov 2002 02:10:45 -0500 Received: from qmail-b.directi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA22791 for ; Tue, 26 Nov 2002 02:07:50 -0500 (EST) Received: (qmail 22093 invoked by uid 0); 26 Nov 2002 07:10:04 -0000 Received: from unknown (HELO server) (203.129.216.97) by 203.199.107.94 with SMTP; 26 Nov 2002 07:10:04 -0000 Message-ID: <008101c2951b$0373c6d0$61d881cb@iLocus.ilocus.com> From: "sumir" To: References: <20021122170001.28330.59818.Mailman@www1.ietf.org> Date: Tue, 26 Nov 2002 12:40:39 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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 Content-Transfer-Encoding: 8bit Subject: [Sip] Sip Stack Market Place. Follow-Up! 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 friends I am highly thankful to Mr. Mohammed Asfar of Nokia and Mr. Jeff Hoefgen of Radvision for their answers... I hv some questions like: Q1 What if I start developing a sip stack. what techical knowledge and resources I require? Q2 What is the approximate development time for developing sip stack? (man days). Q3 How many people is needed to dedicate to developing sip stack? Q4 What are my costs for developing these stacks? Q5 What technical resources I need to build these stacks? Q6 Do i need to follow certain rules if any.. Looking forward to hear from you friends soon With regards! sam ----- Original Message ----- From: To: Sent: Friday, November 22, 2002 10:30 PM Subject: Sip digest, Vol 1 #853 - 5 msgs > Send Sip mailing list submissions to > sip@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/sip > or, via email, send a message with subject or body 'help' to > sip-request@ietf.org > > You can reach the person managing the list at > sip-admin@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Sip digest..." > > > Today's Topics: > > 1. Re: callerprefs-07 (Jonathan Rosenberg) > 2. SIP Call Handoff (Mukta Singh) > 3. two questions (sip learner) > 4. SCTP-SIP (Ritesh Maheshwari) > 5. SIP STACK MARKET PLACE (sumir) > > --__--__-- > > Message: 1 > Date: Thu, 21 Nov 2002 13:05:07 -0500 > From: Jonathan Rosenberg > Organization: dynamicsoft > To: y01317@njupt.edu.cn > CC: "sip@ietf.org" > Subject: Re: [Sip] callerprefs-07 > > I emailed a list of changes to the list. Here is the message: > http://www.ietf.org/mail-archive/working-groups/sip/current/msg06848.html > > -Jonathan R. > > feng zhang wrote: > > Hi all, > > > > I think there are lots of changes between draft-ietf-sip-callerprefs-07 and draft-ietf-sip-callerprefs-06, but the author does not state the "Changes" part, I want to know what's the detailed difference? > > Can the authors give me an answer? > > > > Thanks a lot! > > > > > > ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡ > > _______________________________________________ > > 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 > > > > -- > 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 > > > --__--__-- > > Message: 2 > Date: Thu, 21 Nov 2002 21:32:59 -0800 (PST) > From: Mukta Singh > To: sip@ietf.org > Cc: mukta@ipen-india.com > Subject: [Sip] SIP Call Handoff > > > Hi, > > Can anyone tell me, Is there any draft on the SIP > call handoff ? If yes ,please specify where it is > available. > > thanks in advance > > Mukta > Axes Technologies (I) Pvt. Ltd > IDC,Bangalore > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > > --__--__-- > > Message: 3 > Date: Thu, 21 Nov 2002 22:28:20 -0800 (PST) > From: sip learner > To: sip@ietf.org > Subject: [Sip] two questions > > --0-1941791222-1037946500=:73558 > Content-Type: text/plain; charset=us-ascii > > > Sir, > > I am a student started working on sip. > > please clarify my douths: > > 1.SIP uses offer/anwer model to negotiate session parameters. > > does this mean that invite/ok/ack transaction. > > 2/what is a dialogue mean in SIP?? can any one please help me in knowing more about these 2 questions. > > -SL > > > > --------------------------------- > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now > --0-1941791222-1037946500=:73558 > Content-Type: text/html; charset=us-ascii > >

Sir,

>

       I am a student started working on sip.

>

please  clarify  my douths:

>

1.SIP uses offer/anwer model to negotiate session parameters.

>

   does this mean that invite/ok/ack transaction.

>

2/what is a dialogue mean in SIP?? can any one please help me in knowing more about these 2 questions.

>

-SL


Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now > --0-1941791222-1037946500=:73558-- > > --__--__-- > > Message: 4 > From: "Ritesh Maheshwari" > To: sip@ietf.org > Cc: sip-implementors@cs.columbia.edu > Date: Fri, 22 Nov 2002 08:43:35 +0000 > Subject: [Sip] SCTP-SIP > > > > hi, > > I read the draft on SCTP usage for SIP which is due to expire in December. > Is there any group working on that matter currently? And if yes please tell > me what is the website/email and what work has been done till now? > > Regards, > Ritesh Maheshwari > Final yr, BTech > Computer Sci & Engg, > IIT Kharagpur, > INDIA > > _________________________________________________________________ > The new MSN 8: advanced junk mail protection and 2 months FREE* > http://join.msn.com/?page=features/junkmail > > > --__--__-- > > Message: 5 > From: "sumir" > To: > Date: Fri, 22 Nov 2002 15:17:32 +0530 > Subject: [Sip] SIP STACK MARKET PLACE > > This is a multi-part message in MIME format. > > ------=_NextPart_000_000F_01C2923A.47C0C790 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > HI friends > > I would like to have some information on SIP Stack and have these = > questions:=20 > Q What is sip toolkit? How is it related to sip stack? > Q Technically speaking what is involved in developing these stacks? > Q What is the order of development, where to start? > > Plz help me in giving links, resources and answers releated to SIP = > STACKS... > > Your effort will be appreciated > > Withwarm regards! > SAM > > =20 > > > > ------=_NextPart_000_000F_01C2923A.47C0C790 > Content-Type: text/html; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > > > http-equiv=3DContent-Type> > > > > >
>
Arial"> prefix =3D o /> style=3D"FONT-FAMILY: Arial"> "urn:schemas-microsoft-com:office:office" /> style=3D"FONT-FAMILY: Arial"> >
Arial"> style=3D"FONT-FAMILY: Arial"> Arial"> style=3D"FONT-FAMILY: Arial">HI=20 > friends
>
 
>
I would like to have some information on SIP Stack and = > have these=20 > questions:
>
Arial"> style=3D"FONT-FAMILY: Arial"> style=3D"FONT-FAMILY: Arial">Q    What is sip toolkit? = > How is it=20 > related to sip=20 > stack?
 :p>
>
Arial"> style=3D"FONT-FAMILY: Arial"> style=3D"FONT-FAMILY: Arial">Q    Technically speaking = > what is=20 > involved in developing these=20 > stacks?
= > >
Arial"> style=3D"FONT-FAMILY: Arial"> >
style=3D"FONT-FAMILY: Arial">Q    What is the order of = > development,=20 > where to  style=3D"FONT-FAMILY: Arial">start?
>
style=3D"FONT-FAMILY: Arial"> 
>
Plz help me in giving links, resources and answers releated to = > SIP=20 > STACKS...
>
 
>
Your effort will be appreciated
>
 
>
Withwarm regards!
>
SAM
>
 
>
 
>
Arial"> style=3D"FONT-FAMILY: Arial"> style=3D"FONT-FAMILY: = > Arial"> 
>
Arial"> style=3D"FONT-FAMILY: Arial"> style=3D"FONT-FAMILY: = > Arial"> 
SPAN> > > ------=_NextPart_000_000F_01C2923A.47C0C790-- > > > > --__--__-- > > _______________________________________________ > 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 > > End of Sip Digest > _______________________________________________ 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 Nov 26 02:40:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23399 for ; Tue, 26 Nov 2002 02:40:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAQ7ge605985 for sip-archive@odin.ietf.org; Tue, 26 Nov 2002 02:42: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 gAQ7g2v05965; Tue, 26 Nov 2002 02: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 gAQ7eXv05891 for ; Tue, 26 Nov 2002 02:40:33 -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 CAA23344 for ; Tue, 26 Nov 2002 02:37:39 -0500 (EST) Received: from hendrix.lmf.ericsson.se (hendrix.lmf.ericsson.se [131.160.11.8]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAQ7eHKV020929; Tue, 26 Nov 2002 08:40:17 +0100 (MET) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.3]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id gAQ7eGu4018473; Tue, 26 Nov 2002 09:40:16 +0200 (EET) Message-ID: <3DE3255C.69B25A66@lmf.ericsson.se> Date: Tue, 26 Nov 2002 09:40:12 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sumir CC: sip@ietf.org Subject: Re: [Sip] Sip Stack Market Place. Follow-Up! References: <20021122170001.28330.59818.Mailman@www1.ietf.org> <008101c2951b$0373c6d0$61d881cb@iLocus.ilocus.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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 Hello, Note the piece of text that comes at the bottom of every message coming from this mailing list: > 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 This means that this is not an appropriate mailing list for your questions. Try sip-implementors instead. There you will find people that will be glad to help you out. Thanks, Gonzalo sumir wrote: > > Hi friends > > I am highly thankful to Mr. Mohammed Asfar of Nokia and Mr. Jeff Hoefgen of > Radvision for their answers... > > I hv some questions like: > Q1 What if I start developing a sip stack. what techical knowledge and > resources I require? > Q2 What is the approximate development time for developing sip stack? (man > days). Q3 > How many people is needed to dedicate to developing sip stack? > Q4 What are my costs for developing these stacks? > Q5 What technical resources I need to build these stacks? > Q6 Do i need to follow certain rules if any.. > > Looking forward to hear from you friends soon > > With regards! > sam > > ----- Original Message ----- > From: > To: > Sent: Friday, November 22, 2002 10:30 PM > Subject: Sip digest, Vol 1 #853 - 5 msgs > > > Send Sip mailing list submissions to > > sip@ietf.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://www1.ietf.org/mailman/listinfo/sip > > or, via email, send a message with subject or body 'help' to > > sip-request@ietf.org > > > > You can reach the person managing the list at > > sip-admin@ietf.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of Sip digest..." > > > > > > Today's Topics: > > > > 1. Re: callerprefs-07 (Jonathan Rosenberg) > > 2. SIP Call Handoff (Mukta Singh) > > 3. two questions (sip learner) > > 4. SCTP-SIP (Ritesh Maheshwari) > > 5. SIP STACK MARKET PLACE (sumir) > > > > --__--__-- > > > > Message: 1 > > Date: Thu, 21 Nov 2002 13:05:07 -0500 > > From: Jonathan Rosenberg > > Organization: dynamicsoft > > To: y01317@njupt.edu.cn > > CC: "sip@ietf.org" > > Subject: Re: [Sip] callerprefs-07 > > > > I emailed a list of changes to the list. Here is the message: > > http://www.ietf.org/mail-archive/working-groups/sip/current/msg06848.html > > > > -Jonathan R. > > > > feng zhang wrote: > > > Hi all, > > > > > > I think there are lots of changes between > draft-ietf-sip-callerprefs-07 and draft-ietf-sip-callerprefs-06, but the > author does not state the "Changes" part, I want to know what's the detailed > difference? > > > Can the authors give me an answer? > > > > > > Thanks a lot! > > > > > > > > > ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡ > > > _______________________________________________ > > > 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 > > > > > > > -- > > 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 > > > > > > --__--__-- > > > > Message: 2 > > Date: Thu, 21 Nov 2002 21:32:59 -0800 (PST) > > From: Mukta Singh > > To: sip@ietf.org > > Cc: mukta@ipen-india.com > > Subject: [Sip] SIP Call Handoff > > > > > > Hi, > > > > Can anyone tell me, Is there any draft on the SIP > > call handoff ? If yes ,please specify where it is > > available. > > > > thanks in advance > > > > Mukta > > Axes Technologies (I) Pvt. Ltd > > IDC,Bangalore > > > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > > http://mailplus.yahoo.com > > > > --__--__-- > > > > Message: 3 > > Date: Thu, 21 Nov 2002 22:28:20 -0800 (PST) > > From: sip learner > > To: sip@ietf.org > > Subject: [Sip] two questions > > > > --0-1941791222-1037946500=:73558 > > Content-Type: text/plain; charset=us-ascii > > > > > > Sir, > > > > I am a student started working on sip. > > > > please clarify my douths: > > > > 1.SIP uses offer/anwer model to negotiate session parameters. > > > > does this mean that invite/ok/ack transaction. > > > > 2/what is a dialogue mean in SIP?? can any one please help me in knowing > more about these 2 questions. > > > > -SL > > > > > > > > --------------------------------- > > Do you Yahoo!? > > Yahoo! Mail Plus - Powerful. Affordable. Sign up now > > --0-1941791222-1037946500=:73558 > > Content-Type: text/html; charset=us-ascii > > > >

Sir,

> >

       I am a student started working on > sip.

> >

please  clarify  my douths:

> >

1.SIP uses offer/anwer model to negotiate session parameters.

> >

   does this mean that invite/ok/ack transaction.

> >

2/what is a dialogue mean in SIP?? can any one please help me in > knowing more about these 2 questions.

> >

-SL


Do you Yahoo!?
> > href="http://rd.yahoo.com/mail/mailsig/*http://mailplus.yahoo.com">Yahoo! > Mail Plus - Powerful. Affordable. href="http://rd.yahoo.com/mail/mailsig/*http://mailplus.yahoo.com">Sign up > now > > --0-1941791222-1037946500=:73558-- > > > > --__--__-- > > > > Message: 4 > > From: "Ritesh Maheshwari" > > To: sip@ietf.org > > Cc: sip-implementors@cs.columbia.edu > > Date: Fri, 22 Nov 2002 08:43:35 +0000 > > Subject: [Sip] SCTP-SIP > > > > > > > > hi, > > > > I read the draft on SCTP usage for SIP which is due to expire in December. > > Is there any group working on that matter currently? And if yes please > tell > > me what is the website/email and what work has been done till now? > > > > Regards, > > Ritesh Maheshwari > > Final yr, BTech > > Computer Sci & Engg, > > IIT Kharagpur, > > INDIA > > > > _________________________________________________________________ > > The new MSN 8: advanced junk mail protection and 2 months FREE* > > http://join.msn.com/?page=features/junkmail > > > > > > --__--__-- > > > > Message: 5 > > From: "sumir" > > To: > > Date: Fri, 22 Nov 2002 15:17:32 +0530 > > Subject: [Sip] SIP STACK MARKET PLACE > > > > This is a multi-part message in MIME format. > > > > ------=_NextPart_000_000F_01C2923A.47C0C790 > > Content-Type: text/plain; > > charset="iso-8859-1" > > Content-Transfer-Encoding: quoted-printable > > > > HI friends > > > > I would like to have some information on SIP Stack and have these = > > questions:=20 > > Q What is sip toolkit? How is it related to sip stack? > > Q Technically speaking what is involved in developing these stacks? > > Q What is the order of development, where to start? > > > > Plz help me in giving links, resources and answers releated to SIP = > > STACKS... > > > > Your effort will be appreciated > > > > Withwarm regards! > > SAM > > > > =20 > > > > > > > > ------=_NextPart_000_000F_01C2923A.47C0C790 > > Content-Type: text/html; > > charset="iso-8859-1" > > Content-Transfer-Encoding: quoted-printable > > > > > > > > > http-equiv=3DContent-Type> > > > > > > > > > >
> >
> Arial"> > prefix =3D o /> > style=3D"FONT-FAMILY: Arial"> > "urn:schemas-microsoft-com:office:office" /> > style=3D"FONT-FAMILY: Arial"> > >
> Arial"> > style=3D"FONT-FAMILY: Arial"> > Arial"> > style=3D"FONT-FAMILY: Arial">HI=20 > > friends
> >
 
> >
I would like to have some information on SIP Stack and = > > have these=20 > > questions:
> >
> Arial"> > style=3D"FONT-FAMILY: Arial"> > style=3D"FONT-FAMILY: Arial">Q    What is sip toolkit? = > > How is it=20 > > related to sip=20 > > stack?
 > :p>
> >
> Arial"> > style=3D"FONT-FAMILY: Arial"> > style=3D"FONT-FAMILY: Arial">Q    Technically speaking = > > what is=20 > > involved in developing these=20 > > stacks?
= > > > >
> Arial"> > style=3D"FONT-FAMILY: Arial"> > >
> style=3D"FONT-FAMILY: Arial">Q    What is the order of = > > development,=20 > > where to  > style=3D"FONT-FAMILY: Arial">start?
> >
> style=3D"FONT-FAMILY: Arial"> 
> >
Plz help me in giving links, resources and answers releated to = > > SIP=20 > > STACKS...
> >
 
> >
Your effort will be appreciated
> >
 
> >
Withwarm regards!
> >
SAM
> >
 
> >
 
> >
> Arial"> > style=3D"FONT-FAMILY: Arial"> > style=3D"FONT-FAMILY: = > > Arial"> 
> >
> Arial"> > style=3D"FONT-FAMILY: Arial"> > style=3D"FONT-FAMILY: = > > Arial"> 
> SPAN> > > > > ------=_NextPart_000_000F_01C2923A.47C0C790-- > > > > > > > > --__--__-- > > > > _______________________________________________ > > 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 > > > > End of Sip Digest > > > > _______________________________________________ > 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 -- 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 Tue Nov 26 06:43:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27548 for ; Tue, 26 Nov 2002 06:43:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAQBk2719862 for sip-archive@odin.ietf.org; Tue, 26 Nov 2002 06:46: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 gAQBfxv19666; Tue, 26 Nov 2002 06:41:59 -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 gAQBcLv19548 for ; Tue, 26 Nov 2002 06:38:21 -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 GAA27416; Tue, 26 Nov 2002 06:35:35 -0500 (EST) From: aroychow@hss.hns.com 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 gAQBcIvh020571; Tue, 26 Nov 2002 06:38:18 -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 gAQBcC116666; Tue, 26 Nov 2002 06:38:13 -0500 (EST) To: Adam Roach Cc: "'sip@ietf.org'" , sip-admin@ietf.org Subject: Re: [Sip] i18n issue: composed characters MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Tue, 26 Nov 2002 06:39:29 -0500 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.10 |March 22, 2002) at 11/26/2002 06:36:16 AM, Serialize complete at 11/26/2002 06:36:16 AM Content-Type: multipart/alternative; boundary="=_alternative 003FEA8E85256C7D_=" X-Filtered: Sendmail MIME Filter v1.0.7 excore1.hns.com gAQBcC116666 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 003FEA8E85256C7D_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would agree that we should specify guidelines for this.=20 More than latin representations, Im worried about the composition of Asian = languages which seem to have this issue. And yes -> internationalization (geez you only realize how long this word=20 is when you start typing it) is definetely happening today. Technically, I am totally against loading the proxy with normalization -=20 Id much rather this happens at the UA side.=20 However, practically, I am not sure if we can enforce this - and the=20 reason I am not sure is because I dont know the acceptability of unicode encoding norms in various nations.=20 Be that may, we could look into including a SHOULD clause that a UA=20 wishing to support unicode SHOULD normalize it according to xxx scheme before sending it out. And a proxy MAY decide to implement=20 the unicode translation (for situations where enforcing a unicode normalization across UAs may not be practical). regds arjun -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301-212-7860 (M): 240-997-0066 Adam Roach Sent by: sip-admin@ietf.org 11/26/2002 01:21 AM =20 To: "'sip@ietf.org'" cc:=20 Subject: [Sip] i18n issue: composed characters While digging through the confctrl archives, circa 08/99, I came across a thread that probably shouldn't be lost now that we have started giving internationalization more serious thought. With Unicode, there are two different ways to encode most accented Latin characters. I beleive the same issue occurs in several other character sets (e.g. composition of Korean Hangul versus use of precomposed characters). For example, the character "=C5" (an "A" with a loop over it) can be encoded in Unicode as U+00C5 or as U+212B or as the combination U+0041 U+030A. Now, with multiple possible encodings for single characters, we have the problem of, for example, someone registering as "sip:%C3%85se@bolaget.no", and someone else inviting "sip:A%CC%8Ase@bolaget.no". In both cases, the interface would render the user portion as "=C5se" to the users, but matching is difficult. Of course, we *could* just leave this as a server implementation issue. This is a bit of a pain, since it means that *all* servers need to perform normalization of unicode characters before doing any processing. Bleah. Alternately, taking the suggestion Kevin Payne made so many years ago, we could specify that any user agent that has the ability to accept characters that might have multiple Unicode encodings is responsible for normalization of that input to a single, canonical form. My understanding is that Unicode defines at least two methods of normalization (Canonical and Compatibility), and that a proposal was floated to define two *additional* methods by performing the decomposition described by Unicode, followed by a canonical composition. This has the advantage of taking less space. It's not clear whether this method [1] made it into any Unicode standards. So, do we want to address this issue at all, or so we just let things break? /a [1] http://www.unicode.org/unicode/reports/tr15/tr15-10.html =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F 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 --=_alternative 003FEA8E85256C7D_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I would agree that we should specify= guidelines for this.

More than latin representations, Im = worried about the composition of Asian languages which seem to have this is= sue.
And yes -> internationalization (= geez you only realize how long this word is when you start typing it) is de= finetely happening today.

Technically,  I am totally agai= nst loading the proxy with normalization - Id much rather this happens at t= he UA side.
However, practically, I am not sure = if we can enforce this - and the reason I am not sure is because I dont kno= w the acceptability
of unicode encoding norms in various= nations.

Be that may, we could look into incl= uding a SHOULD clause that a UA wishing to support unicode SHOULD normalize= it according
to xxx scheme before sending it out.= And a proxy MAY decide to implement the unicode translation (for situation= s where enforcing
a unicode normalization across UAs m= ay not be practical).

regds
arjun




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


Adam Roach <adam@dynamicsoft.c= om>
Sent by: sip-admin@ietf.org

11/26/2002 01:21 AM

       
        To: &nbs= p;      "'sip@ietf.org'" <sip@ietf.org>
        cc: &nbs= p;      
        Subject:=        [Sip] i18n issue: composed characters


While digging through the confctrl = archives, circa 08/99, I
came across a thread that probably shouldn't be lost now that
we have started giving internationalization more serious thought.

With Unicode, there are two different ways to encode most
accented Latin characters. I beleive the same issue occurs
in several other character sets (e.g. composition of Korean
Hangul versus use of precomposed characters).

For example, the character "=C5" (an "A" with a loop ov= er it)
can be encoded in Unicode as U+00C5 or as U+212B or as the
combination U+0041 U+030A.

Now, with multiple possible encodings for single characters,
we have the problem of, for example, someone registering as
"sip:%C3%85se@bolaget.no", and someone else inviting
"sip:A%CC%8Ase@bolaget.no". In both cases, the interface
would render the user portion as "=C5se" to the users, but
matching is difficult.

Of course, we *could* just leave this as a server implementation
issue. This is a bit of a pain, since it means that *all* servers
need to perform normalization of unicode characters before
doing any processing. Bleah.

Alternately, taking the suggestion Kevin Payne made so many years
ago, we could specify that any user agent that has the ability
to accept characters that might have multiple Unicode encodings
is responsible for normalization of that input to a single, canonical
form.

My understanding is that Unicode defines at least two methods
of normalization (Canonical and Compatibility), and that a proposal
was floated to define two *additional* methods by performing the
decomposition described by Unicode, followed by a canonical
composition. This has the advantage of taking less space. It's not
clear whether this method [1] made it into any Unicode standards.

So, do we want to address this issue at all, or so we just let
things break?

/a

[1] http://www.unicode.org/unicode/reports/tr15/tr15-10.html
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
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

--=_alternative 003FEA8E85256C7D_=-- _______________________________________________ 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 Nov 26 07:35:56 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28645 for ; Tue, 26 Nov 2002 07:35:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAQCc9G23008 for sip-archive@odin.ietf.org; Tue, 26 Nov 2002 07:38: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 gAQCbev22972; Tue, 26 Nov 2002 07:37:40 -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 gAQCaDv22356 for ; Tue, 26 Nov 2002 07:36:13 -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 HAA28633 for ; Tue, 26 Nov 2002 07:33:29 -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.34 #1 (Debian)) id 18Gewl-0000Pw-00 for ; Tue, 26 Nov 2002 14:36:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15843.27323.177222.764464@harjus.eng.song.fi> Date: Tue, 26 Nov 2002 14:36:11 +0200 To: sip@ietf.org X-Mailer: VM 7.03 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Subject: [Sip] % in user part of sip uri 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 what is the reason why % is not allowed as a normal character in the user part of sip uri? in email addresses % has been allowed and used in the user part forever. unless there exists a VERY GOOD reason to break away from the 20 year old tradition as standardized in rfc 821 and later confirmed in rfc 2486, i suggest that this is recorded as a bug to be fixed in the next revision of rfc 3261. -- 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 Nov 26 09:22:39 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02340 for ; Tue, 26 Nov 2002 09:22:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAQEOsZ28933 for sip-archive@odin.ietf.org; Tue, 26 Nov 2002 09:24: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 gAQEOFv28912; Tue, 26 Nov 2002 09:24: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 gAQEMnv28871 for ; Tue, 26 Nov 2002 09:22:49 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02261 for ; Tue, 26 Nov 2002 09:20:03 -0500 (EST) Received: from cs.columbia.edu ([193.136.214.230]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id gAQEGnIh024949 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 26 Nov 2002 09:18:40 -0500 (EST) Message-ID: <3DE381C8.6070504@cs.columbia.edu> Date: Tue, 26 Nov 2002 09:14:32 -0500 From: Henning Schulzrinne Organization: Columbia University 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: jh@lohi.eng.song.fi CC: sip@ietf.org Subject: Re: [Sip] % in user part of sip uri References: <15843.27323.177222.764464@harjus.eng.song.fi> 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 Don't panic... Please consult any URI document, e.g., RFC 1738. % needs to be escaped, but can appear as %25. jh@lohi.eng.song.fi wrote: > what is the reason why % is not allowed as a normal character in the > user part of sip uri? in email addresses % has been allowed and used in > the user part forever. unless there exists a VERY GOOD reason to break > away from the 20 year old tradition as standardized in rfc 821 and later > confirmed in rfc 2486, i suggest that this is recorded as a bug to be > fixed in the next revision of rfc 3261. > > -- 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 Tue Nov 26 10:46:56 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06987 for ; Tue, 26 Nov 2002 10:46:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAQFnCI02400 for sip-archive@odin.ietf.org; Tue, 26 Nov 2002 10:49:12 -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 gAQFiOv02209; Tue, 26 Nov 2002 10:44: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 gAQFgov02154 for ; Tue, 26 Nov 2002 10:42:50 -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 KAA06745 for ; Tue, 26 Nov 2002 10:40:02 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.12]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAQFggYH008283; Tue, 26 Nov 2002 10:42:43 -0500 (EST) Message-ID: <3DE3966F.6040300@dynamicsoft.com> Date: Tue, 26 Nov 2002 10:42:39 -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: Shingo Fujimoto CC: Cyrus Shaoul , sip@ietf.org Subject: Re: [Sip] Unicode in Response codes. References: <20021119235354.620A.CYRUS@ntt-at.com> <20021120052741.40951.qmail@web20704.mail.yahoo.com> <20021120011814.BCFC.CYRUS@ntt-at.com> <3DDB6790.2030007@jp.fujitsu.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 Shingo Fujimoto wrote: > I have posted the summary of discussion on Oct 16. > > And now, I am working on new drafts (requirement and proposal I-D). > > Since IETF meeting is on going, I am planning to finish and post it in > December. > > If you have any new requirements regarding UTF8 headers, I will put them > in new draft. Cyrus' comment does introduce a new requirement - to handle language tagging in the reason phrase. To date we had only considered headers. -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 Tue Nov 26 11:07:20 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08254 for ; Tue, 26 Nov 2002 11:07:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAQG9ai04447 for sip-archive@odin.ietf.org; Tue, 26 Nov 2002 11:09: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 gAQG7Tv04102; Tue, 26 Nov 2002 11:07: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 gAQG6uv03488 for ; Tue, 26 Nov 2002 11:06:56 -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 LAA08031 for ; Tue, 26 Nov 2002 11:04:08 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.12]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAQG6rYH008293; Tue, 26 Nov 2002 11:06:53 -0500 (EST) Message-ID: <3DE39C1B.5060206@dynamicsoft.com> Date: Tue, 26 Nov 2002 11:06:51 -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: Adam Roach CC: "'sip@ietf.org'" Subject: Re: [Sip] i18n issue: composed characters References: <9BF66EBF6BEFD942915B4D4D45C051F3A6434B@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 inline. Adam Roach wrote: > While digging through the confctrl archives, circa 08/99, I > came across a thread that probably shouldn't be lost now that > we have started giving internationalization more serious thought. > > With Unicode, there are two different ways to encode most > accented Latin characters. I beleive the same issue occurs > in several other character sets (e.g. composition of Korean > Hangul versus use of precomposed characters). > > For example, the character "Å" (an "A" with a loop over it) > can be encoded in Unicode as U+00C5 or as U+212B or as the > combination U+0041 U+030A. > > Now, with multiple possible encodings for single characters, > we have the problem of, for example, someone registering as > "sip:%C3%85se@bolaget.no", and someone else inviting > "sip:A%CC%8Ase@bolaget.no". In both cases, the interface > would render the user portion as "Åse" to the users, but > matching is difficult. Actually, a first, more troubling point. THe above escape encoding requires that the SIP URI explicit point out that it uses UTF-8 for conversion of the octet sequence generated from the URI, to the original character string. Although SIP generally uses UTF-8, nowhere does the specification point out this property of the SIP URI. I recently logged this in bugzilla, as Bug 678. We'll need to clarify that in the next release. Of course, the main issue once we specify that is canonicalization, as you point out below. > > Of course, we *could* just leave this as a server implementation > issue. This is a bit of a pain, since it means that *all* servers > need to perform normalization of unicode characters before > doing any processing. Bleah. We really don't want to do that. I suspect that this is a nightmare procedure as a general rule. I'd rather distribute it to clients which support those particular characters. Not all UI will support entry of all unicode characters, so the UA would only need to know about canonicalization of those characters it supports. THis is compared to a proxy, which would need to canonicalize every potential unicode sequence (shudder). > > Alternately, taking the suggestion Kevin Payne made so many years > ago, we could specify that any user agent that has the ability > to accept characters that might have multiple Unicode encodings > is responsible for normalization of that input to a single, canonical > form. This seems like a better approach. Note that, we do currently specify that the proxy is supposed to do canonicalization: > 5. The registrar extracts the address-of-record from the To header > field of the request. If the address-of-record is not valid > for the domain in the Request-URI, the registrar MUST send a > 404 (Not Found) response and skip the remaining steps. The URI > MUST then be converted to a canonical form. To do that, all > URI parameters MUST be removed (including the user-param), and > any escaped characters MUST be converted to their unescaped > form. The result serves as an index into the list of bindings. this is reasonably well defined for US-ASCII characters, but broken for UTF-8 as you point out. As such, would we split the canoncicalization, with clients using the canonical escape encodings, and then the proxy un-escaping? If we specify a canonical escape encoding, and FURTHER mandate that clients never escape characters which do not require escaping, we may not need the proxy to unescape at all. Its not clear if there is an advantage to splitting the canonicalization between the two elements. > > My understanding is that Unicode defines at least two methods > of normalization (Canonical and Compatibility), and that a proposal > was floated to define two *additional* methods by performing the > decomposition described by Unicode, followed by a canonical > composition. This has the advantage of taking less space. It's not > clear whether this method [1] made it into any Unicode standards. > > So, do we want to address this issue at all, or so we just let > things break? Yes, we definitely want to deal with this. I don't think this is part of the requirements work that Fujimoto-san is working on; this is really part of the core specification, addressing a hole we currently have. I am surprised that the method of canonicalization is not addressed by Unicode. After all, don't they specify rules for equality checking (that is, after all, what we are after, just using canonicalization for equality checking)? Don't those rules include such encoding variations? I'm not a unicode expert, but this seems like a very basic issue. -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 Tue Nov 26 13:39:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14726 for ; Tue, 26 Nov 2002 13:39:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAQIfPN15800 for sip-archive@odin.ietf.org; Tue, 26 Nov 2002 13:41: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 gAQIefv15713; Tue, 26 Nov 2002 13:40: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 gAQIbxv15526 for ; Tue, 26 Nov 2002 13:37:59 -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 NAA14615 for ; Tue, 26 Nov 2002 13:35:11 -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 gAQIaog2008546 for ; Tue, 26 Nov 2002 13:36:50 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Nov 2002 12:37:53 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A6434D@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: Jonathan Rosenberg , Adam Roach Cc: "'sip@ietf.org'" Subject: RE: [Sip] i18n issue: composed characters Date: Tue, 26 Nov 2002 12:37:47 -0600 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: , > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > I am surprised that the method of canonicalization is not > addressed by > Unicode. After all, don't they specify rules for equality > checking (that > is, after all, what we are after, just using canonicalization for > equality checking)? Don't those rules include such encoding > variations? > I'm not a unicode expert, but this seems like a very basic issue. I think my phrasing must have been a bit confusing. Unicode *definitely* specifies canonicalization. In fact, they care so much about it, they specified *two* ways to do it. We need to pick one of these methods. I probably confused the issue unnecessarily by throwing in a reference to a proposal for two *other* ways to do it that never seemed to get off the ground (at least, as far as I can tell). /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 Tue Nov 26 14:51:52 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17998 for ; Tue, 26 Nov 2002 14:51:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAQJsA921340 for sip-archive@odin.ietf.org; Tue, 26 Nov 2002 14:54: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 gAQJmkv21019; Tue, 26 Nov 2002 14:48: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 gAQJkvv20944 for ; Tue, 26 Nov 2002 14:46:57 -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 OAA17762 for ; Tue, 26 Nov 2002 14:44:08 -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 gAQJjeg2008877; Tue, 26 Nov 2002 14:45:40 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Nov 2002 13:46:44 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64350@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Henning Schulzrinne'" , jh@lohi.eng.song.fi Cc: sip@ietf.org Subject: RE: [Sip] % in user part of sip uri Date: Tue, 26 Nov 2002 13:46:37 -0600 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: , To further reinforce this: it's fundamentally a URI escaping issue. For example, to indicate the e-mail address "adam%vax@dynamicsoft.com" in a "mailto" URL, you would be forced to represent it as "mailto:adam%25vax@dynamicsoft.com" /a > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, November 26, 2002 8:15 > To: jh@lohi.eng.song.fi > Cc: sip@ietf.org > Subject: Re: [Sip] % in user part of sip uri > > > Don't panic... Please consult any URI document, e.g., RFC > 1738. % needs > to be escaped, but can appear as %25. > > jh@lohi.eng.song.fi wrote: > > what is the reason why % is not allowed as a normal character in the > > user part of sip uri? in email addresses % has been > allowed and used in > > the user part forever. unless there exists a VERY GOOD > reason to break > > away from the 20 year old tradition as standardized in rfc > 821 and later > > confirmed in rfc 2486, i suggest that this is recorded as a > bug to be > > fixed in the next revision of rfc 3261. > > > > -- 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 > _______________________________________________ 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 Nov 26 16:34:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21882 for ; Tue, 26 Nov 2002 16:34:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAQLabs27982 for sip-archive@odin.ietf.org; Tue, 26 Nov 2002 16:36:37 -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 gAQLT8v27572; Tue, 26 Nov 2002 16:29: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 gAQLSuv27484 for ; Tue, 26 Nov 2002 16:28:56 -0500 Received: from dyn-tx-app-007.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21675 for ; Tue, 26 Nov 2002 16:26:06 -0500 (EST) Received: from RjS.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id gAQLSo101224 for ; Tue, 26 Nov 2002 15:28:50 -0600 From: Robert Sparks To: sip@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 26 Nov 2002 15:28:01 -0600 Message-Id: <1038346082.1613.2.camel@RjS.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [Sip] SIPit 12 registration is open 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 12th SIPit will be hosted by Hotsip in Stockholm February 24-28, 2003. Please see http://www.hotsip.com/sipit12/ for details and registration. Thanks, 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 Tue Nov 26 16:37:26 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21930 for ; Tue, 26 Nov 2002 16:37:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAQLdjs28648 for sip-archive@odin.ietf.org; Tue, 26 Nov 2002 16:39: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 gAQLSVv27441; Tue, 26 Nov 2002 16:28: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 gAQLQBv27358 for ; Tue, 26 Nov 2002 16:26:11 -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 QAA21594 for ; Tue, 26 Nov 2002 16:23:21 -0500 (EST) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gAQLPsu4010275; Tue, 26 Nov 2002 13:25:54 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABI61870; Tue, 26 Nov 2002 13:23:30 -0800 (PST) Date: Tue, 26 Nov 2002 13:25:50 -0800 Subject: Re: [Sip] i18n issue: composed characters Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: "'sip@ietf.org'" To: Adam Roach From: Rohan Mahy In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A6434B@DYN-TX-EXCH-001.dynamicsoft.com> Message-Id: X-Mailer: Apple Mail (2.548) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAQLQBv27359 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 On Monday, November 25, 2002, at 10:21 PM, Adam Roach wrote: > While digging through the confctrl archives, circa 08/99, I > came across a thread that probably shouldn't be lost now that > we have started giving internationalization more serious thought. > > With Unicode, there are two different ways to encode most > accented Latin characters. I beleive the same issue occurs > in several other character sets (e.g. composition of Korean > Hangul versus use of precomposed characters). > > For example, the character "Å" (an "A" with a loop over it) > can be encoded in Unicode as U+00C5 or as U+212B or as the > combination U+0041 U+030A. > > Now, with multiple possible encodings for single characters, > we have the problem of, for example, someone registering as > "sip:%C3%85se@bolaget.no", and someone else inviting > "sip:A%CC%8Ase@bolaget.no". In both cases, the interface > would render the user portion as "Åse" to the users, but > matching is difficult. > > Of course, we *could* just leave this as a server implementation > issue. This is a bit of a pain, since it means that *all* servers > need to perform normalization of unicode characters before > doing any processing. Bleah. > > Alternately, taking the suggestion Kevin Payne made so many years > ago, we could specify that any user agent that has the ability > to accept characters that might have multiple Unicode encodings > is responsible for normalization of that input to a single, canonical > form. > > My understanding is that Unicode defines at least two methods > of normalization (Canonical and Compatibility), A SIP entity which adds or modifies a URI must insure that any characters it supports which have multiple representations are represented in canonical form. (this should also cover needlessly escaping characters which don't need to be escaped). Now do we want the same requirement for quoted strings? thanks, -rohan > and that a proposal > was floated to define two *additional* methods by performing the > decomposition described by Unicode, followed by a canonical > composition. This has the advantage of taking less space. It's not > clear whether this method [1] made it into any Unicode standards. > > So, do we want to address this issue at all, or so we just let > things break? > > /a > > [1] http://www.unicode.org/unicode/reports/tr15/tr15-10.html > _______________________________________________ > 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 Nov 26 16:39:13 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22042 for ; Tue, 26 Nov 2002 16:39:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAQLfWZ28746 for sip-archive@odin.ietf.org; Tue, 26 Nov 2002 16:41: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 gAQLZCv27914; Tue, 26 Nov 2002 16:35: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 gAQLYFv27860 for ; Tue, 26 Nov 2002 16:34:15 -0500 Received: from web20708.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21831 for ; Tue, 26 Nov 2002 16:31:25 -0500 (EST) Message-ID: <20021126213408.54968.qmail@web20708.mail.yahoo.com> Received: from [207.46.137.206] by web20708.mail.yahoo.com via HTTP; Tue, 26 Nov 2002 13:34:08 PST Date: Tue, 26 Nov 2002 13:34:08 -0800 (PST) From: Sean Olson Subject: Re: [Sip] i18n issue: composed characters To: Rohan Mahy , Adam Roach Cc: "'sip@ietf.org'" 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: , > A SIP entity which adds or modifies a URI must > insure that any > characters it supports which have multiple > representations are > represented in canonical form. (this should also > cover needlessly > escaping characters which don't need to be escaped). > > Now do we want the same requirement for quoted > strings? The requirement for canonical form makes sense in any string where a software may need to make a comparison/collation such as in a URI. I think extending this to quoted strings in general may be overkill. > thanks, > -rohan __________________________________________________ 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 Tue Nov 26 16:49:10 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22356 for ; Tue, 26 Nov 2002 16:49:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAQLpTm29126 for sip-archive@odin.ietf.org; Tue, 26 Nov 2002 16:51:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAQLT5v27517; Tue, 26 Nov 2002 16:29: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 gAQLRsv27409 for ; Tue, 26 Nov 2002 16:27:54 -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 QAA21654 for ; Tue, 26 Nov 2002 16:25:04 -0500 (EST) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAQLRloh025499; Tue, 26 Nov 2002 13:27:47 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABI61896; Tue, 26 Nov 2002 13:25:23 -0800 (PST) Date: Tue, 26 Nov 2002 13:27:45 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: "'Dean Willis'" , jon.peterson@neustar.biz, rohan@cisco.com To: sip@ietf.org From: Rohan Mahy Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.548) Content-Transfer-Encoding: 7bit Subject: [Sip] WGLC for draft-ietf-sip-content-indirect-mech-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: , Content-Transfer-Encoding: 7bit Hi, I'd like to open working group last call on draft-ietf-sip-content-indirect-mech-01.txt . WGLC will close on December 15. Lets especially check the security aspects of content indirection, as that is an area that the IESG has (rightly) given much attention to recently. We should try to as well. thanks, -rohan _______________________________________________ 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 Nov 26 16:51:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22385 for ; Tue, 26 Nov 2002 16:51:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAQLrQW29184 for sip-archive@odin.ietf.org; Tue, 26 Nov 2002 16:53: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 gAQLV5v27661; Tue, 26 Nov 2002 16:31: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 gAQLUpv27633 for ; Tue, 26 Nov 2002 16:30:51 -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 QAA21728 for ; Tue, 26 Nov 2002 16:28:01 -0500 (EST) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gAQLUiKc002131; Tue, 26 Nov 2002 13:30:44 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABI61933; Tue, 26 Nov 2002 13:28:19 -0800 (PST) Date: Tue, 26 Nov 2002 13:30:38 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: To: "Arunachalam Venkatraman" From: Rohan Mahy In-Reply-To: Message-Id: <4E93DF01-0186-11D7-BC8B-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Comments :draft-ietf-sip-replaces-02.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: 7bit On Tuesday, November 19, 2002, at 01:08 AM, Arunachalam Venkatraman wrote: > Rohan > I have a few comments on this draft. > > 1. Section 3 - > If the Replaces header field matches more than one dialog, the UA > must act > s if no match is found. > > When is this possible? Since dialog id is made up of 3 globally > unique > items, how can this occur? Is this statement inserted for completeness > or is > there such a possibility in SIP compliant User Agents? this is for robustness/completeness > 2. Section 3 - > If the Replaces header field matches a dialog which has already > terminated, > the UA SHOULD decline the request with a 603 Declined response. > > Since the purpose of the Replaces header is to replace a call so that > the > user agent may accept a new call, it seems somewhat at cross-purposes > to > decline the incoming call when the call to be replaced has terminated. > Of course, without this rule, it would be impossible to ensure that > only the > user agent which has the call replaces it and not a different user > agent in > another tine of the fork. But this imposes the rule that the user > agent in a > consultation hold must stay on hold until the referred call arrives, to > ensure the transfer is successful. This is not a bad thing but I would > appreciate an affirmation that I have understood this correctly. > It may not hurt to discuss this for the benefit of others who may face > a > similar doubt. it does not require the user interface show that a call is on hold, it just requires that the dialog to replace is still up. > 3. I am a little puzzled in the differentiation between the case of > "match > not found" and "dialog terminated". > When a dialog is terminated, the state for that dialog will be > uninstalled > and so it will not be found to be matched with a Replaces header. > So, is this intended to cover the case where a dialog survives a BYE > because a subscription is pending (like, from an implicit Refer)? in which section did you see this > 4. Section 7.1 > I think the Replaces header in Message *3 is incorrect and has the > tags > reversed. Since the Call Center plays the role of a UAS in both > contexts, > the Replaces header must have its local tag (To-tag 6472 from the first > call), specified as the To-tag in the Replaces header of the second > call. no, the example is correct. A calls B. Tags in a Replaces are compared from the perspective of the UAS receiving the INVITE with Replaces. You may want to check the description of remote-tag and local-tag in Section 12 of RFC3261. I have received this question at least 4 times now, so I will certainly try to clarify this in the next rev of the document. > 5. Since the draft has expired, when is the next revision coming? as soon as I get review comments back from our Area Director. many thanks, -rohan > Thanks, > Venkat > _______________________________________________ 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 Nov 26 17:23:26 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23575 for ; Tue, 26 Nov 2002 17:23:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAQMPjT31779 for sip-archive@odin.ietf.org; Tue, 26 Nov 2002 17:25: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 gAQMHtv31394; Tue, 26 Nov 2002 17:17: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 gAQMGUv31342 for ; Tue, 26 Nov 2002 17:16:30 -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 RAA23280 for ; Tue, 26 Nov 2002 17:13:39 -0500 (EST) Received: from whoami-new.cisco.com (IDENT:mirapoint@whoami-new.cisco.com [64.101.128.102]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAQMGMoh029173; Tue, 26 Nov 2002 14:16:23 -0800 (PST) Received: from ARUNVENKW2Kl (arunvenk-w2kl-1.cisco.com [64.101.164.105]) by whoami-new.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id AAM12685; Tue, 26 Nov 2002 16:16:21 -0600 (CST) From: "Arunachalam Venkatraman" To: "Rohan Mahy" Cc: Date: Tue, 26 Nov 2002 16:16:22 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <4E93DF01-0186-11D7-BC8B-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit Subject: [Sip] RE: Comments :draft-ietf-sip-replaces-02.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: 7bit Rohan Regarding your question on Item 3, refer to Section 3. It says that if no match is found, a 481 must be sent. If it matches a dialog which has already terminated, then a 603 must be sent. What does the latter mean? If a dialog is terminated, then its state will be deleted and it won't be found, will it? Regarding item 4, The Call Center's local tag on the Call being replaced was 6472 (TO tag in message*2) Therefore, the To-Tag on the Replaces header it receives must be 6472. (To-Tag must be compared to local tag, as if they were present in an incoming request, per Section 3.) What am I missing? Thanks Venkat -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com] Sent: Tuesday, November 26, 2002 3:31 PM To: Arunachalam Venkatraman Cc: sip@ietf.org Subject: Re: Comments :draft-ietf-sip-replaces-02.txt On Tuesday, November 19, 2002, at 01:08 AM, Arunachalam Venkatraman wrote: > Rohan > I have a few comments on this draft. > > 1. Section 3 - > If the Replaces header field matches more than one dialog, the UA > must act > s if no match is found. > > When is this possible? Since dialog id is made up of 3 globally > unique > items, how can this occur? Is this statement inserted for completeness > or is > there such a possibility in SIP compliant User Agents? this is for robustness/completeness > 2. Section 3 - > If the Replaces header field matches a dialog which has already > terminated, > the UA SHOULD decline the request with a 603 Declined response. > > Since the purpose of the Replaces header is to replace a call so that > the > user agent may accept a new call, it seems somewhat at cross-purposes > to > decline the incoming call when the call to be replaced has terminated. > Of course, without this rule, it would be impossible to ensure that > only the > user agent which has the call replaces it and not a different user > agent in > another tine of the fork. But this imposes the rule that the user > agent in a > consultation hold must stay on hold until the referred call arrives, to > ensure the transfer is successful. This is not a bad thing but I would > appreciate an affirmation that I have understood this correctly. > It may not hurt to discuss this for the benefit of others who may face > a > similar doubt. it does not require the user interface show that a call is on hold, it just requires that the dialog to replace is still up. > 3. I am a little puzzled in the differentiation between the case of > "match > not found" and "dialog terminated". > When a dialog is terminated, the state for that dialog will be > uninstalled > and so it will not be found to be matched with a Replaces header. > So, is this intended to cover the case where a dialog survives a BYE > because a subscription is pending (like, from an implicit Refer)? in which section did you see this > 4. Section 7.1 > I think the Replaces header in Message *3 is incorrect and has the > tags > reversed. Since the Call Center plays the role of a UAS in both > contexts, > the Replaces header must have its local tag (To-tag 6472 from the first > call), specified as the To-tag in the Replaces header of the second > call. no, the example is correct. A calls B. Tags in a Replaces are compared from the perspective of the UAS receiving the INVITE with Replaces. You may want to check the description of remote-tag and local-tag in Section 12 of RFC3261. I have received this question at least 4 times now, so I will certainly try to clarify this in the next rev of the document. > 5. Since the draft has expired, when is the next revision coming? as soon as I get review comments back from our Area Director. many thanks, -rohan > Thanks, > Venkat > _______________________________________________ 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 Nov 26 18:33:24 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26550 for ; Tue, 26 Nov 2002 18:33:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAQNZjP03337 for sip-archive@odin.ietf.org; Tue, 26 Nov 2002 18:35: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 gAQNYjv03282; Tue, 26 Nov 2002 18:34: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 gAQNWUv03164 for ; Tue, 26 Nov 2002 18:32:30 -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 SAA26372 for ; Tue, 26 Nov 2002 18:29:38 -0500 (EST) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gAQNWMKc003387; Tue, 26 Nov 2002 15:32:22 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABI63753; Tue, 26 Nov 2002 15:29:53 -0800 (PST) Date: Tue, 26 Nov 2002 15:32:16 -0800 Subject: Re: [Sip] RE: Comments :draft-ietf-sip-replaces-02.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: sip@ietf.org To: "Arunachalam Venkatraman" From: Rohan Mahy In-Reply-To: Message-Id: <4C6F4E13-0197-11D7-BC8B-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) 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 Tuesday, November 26, 2002, at 02:16 PM, Arunachalam Venkatraman wrote: > Rohan > Regarding your question on Item 3, refer to Section 3. It says that if > no > match is found, a 481 must be sent. If it matches a dialog which has > already > terminated, then a 603 must be sent. > What does the latter mean? If a dialog is terminated, then its state > will be > deleted and it won't be found, will it? You need to keep the dialog state around anyway (in the case of UDP) for (typically) 32 secs. > Regarding item 4, > The Call Center's local tag on the Call being replaced was 6472 (TO > tag in > message*2) > Therefore, the To-Tag on the Replaces header it receives must be 6472. > (To-Tag must be compared to local tag, as if they were present in an > incoming request, per Section 3.) > What am I missing? attached is a flow from section 3.1 of draft-ietf-sipping-basic-call-flows-01.txt i have removed all headers/bodies except to/from/callid/cseq User A User B | | | INVITE F1 | |----------------------->| | 180 Ringing F2 | |<-----------------------| | | | 200 OK F3 | |<-----------------------| | ACK F4 | |----------------------->| | Both Way RTP Media | |<======================>| | | | BYE F5 | |<-----------------------| | 200 OK F6 | |----------------------->| | | F1 INVITE User A -> User B INVITE sip:UserB@biloxi.com SIP/2.0 From: BigGuy ;tag=9fxced76sl To: LittleGuy Call-ID: 3848276298220188511@atlanta.com CSeq: 1 INVITE F2 180 Ringing User B -> User A SIP/2.0 180 Ringing From: BigGuy ;tag=9fxced76sl To: LittleGuy ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.com CSeq: 1 INVITE F3 200 OK User B -> User A SIP/2.0 200 OK From: BigGuy ;tag=9fxced76sl To: LittleGuy ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.com CSeq: 1 INVITE F4 ACK User A -> User B ACK sip:UserB@biloxi.com SIP/2.0 From: BigGuy ;tag=9fxced76sl To: LittleGuy ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.com CSeq: 1 ACK Note in the BYE (F5 below) that from User A's perspective, the local tag for this dialog is 9fxced76sl, and the remote tag is 8321234356. (From the perspective of User B, the tags are reversed. the local tag is 8321234356 and the remote tag is 9fxced76sl). If User A received an INVITE with a Replaces header, Replaces: 3848276298220188511@atlanta.com;to-tag=9fxced76sl;from-tag=8321234356 it will compare the to-tag with *User A's* local tag (9fxced76sl), and the from-tag with *User A's* remote tag (8321234356). while to-tag and from-tag are confusing, the text in section 3.1 of replaces is accurate. the tags are matched as if they had been in the BYE below. F5 BYE User B -> User A BYE sip:UserA@client.atlanta.com SIP/2.0 From: LittleGuy ;tag=8321234356 To: BigGuy ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.com CSeq: 1 BYE F6 200 OK User A -> User B SIP/2.0 200 OK From: LittleGuy ;tag=8321234356 To: BigGuy ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.com CSeq: 1 BYE hope this clarifies things. thanks, -rohan > Thanks > Venkat > > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Tuesday, November 26, 2002 3:31 PM > To: Arunachalam Venkatraman > Cc: sip@ietf.org > Subject: Re: Comments :draft-ietf-sip-replaces-02.txt > > > On Tuesday, November 19, 2002, at 01:08 AM, Arunachalam Venkatraman > wrote: > >> Rohan >> I have a few comments on this draft. >> >> 1. Section 3 - >> If the Replaces header field matches more than one dialog, the >> UA >> must act >> s if no match is found. >> >> When is this possible? Since dialog id is made up of 3 globally >> unique >> items, how can this occur? Is this statement inserted for completeness >> or is >> there such a possibility in SIP compliant User Agents? > > this is for robustness/completeness > >> 2. Section 3 - >> If the Replaces header field matches a dialog which has already >> terminated, >> the UA SHOULD decline the request with a 603 Declined response. >> >> Since the purpose of the Replaces header is to replace a call so > that >> the >> user agent may accept a new call, it seems somewhat at cross-purposes >> to >> decline the incoming call when the call to be replaced has terminated. >> Of course, without this rule, it would be impossible to ensure that >> only the >> user agent which has the call replaces it and not a different user >> agent in >> another tine of the fork. But this imposes the rule that the user >> agent in a >> consultation hold must stay on hold until the referred call arrives, >> to >> ensure the transfer is successful. This is not a bad thing but I would >> appreciate an affirmation that I have understood this correctly. >> It may not hurt to discuss this for the benefit of others who may face >> a >> similar doubt. > > it does not require the user interface show that a call is on hold, it > just requires that the dialog to replace is still up. > >> 3. I am a little puzzled in the differentiation between the case of >> "match >> not found" and "dialog terminated". >> When a dialog is terminated, the state for that dialog will be >> uninstalled >> and so it will not be found to be matched with a Replaces header. >> So, is this intended to cover the case where a dialog survives >> a BYE >> because a subscription is pending (like, from an implicit Refer)? > > in which section did you see this > >> 4. Section 7.1 >> I think the Replaces header in Message *3 is incorrect and has >> the >> tags >> reversed. Since the Call Center plays the role of a UAS in both >> contexts, >> the Replaces header must have its local tag (To-tag 6472 from the >> first >> call), specified as the To-tag in the Replaces header of the second >> call. > > no, the example is correct. A calls B. Tags in a Replaces are > compared from the perspective of the UAS receiving the INVITE with > Replaces. You may want to check the description of remote-tag and > local-tag in Section 12 of RFC3261. > > I have received this question at least 4 times now, so I will certainly > try to clarify this in the next rev of the document. > >> 5. Since the draft has expired, when is the next revision coming? > > as soon as I get review comments back from our Area Director. > > many thanks, > -rohan > >> Thanks, >> Venkat >> > > _______________________________________________ > 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 Nov 27 00:43:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06508 for ; Wed, 27 Nov 2002 00:43:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAR5jfS23096 for sip-archive@odin.ietf.org; Wed, 27 Nov 2002 00:45: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 gAR5iiv23057; Wed, 27 Nov 2002 00:44: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 gAR5g4v23008 for ; Wed, 27 Nov 2002 00:42:04 -0500 Received: from mail.pingtel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06462 for ; Wed, 27 Nov 2002 00:39:10 -0500 (EST) Received: from pingtel.com ([192.168.0.3]) by mail.pingtel.com (8.11.6/8.11.6) with ESMTP id gAR5flR24004; Wed, 27 Nov 2002 00:41:47 -0500 Message-ID: <3DE45AD7.3F592815@pingtel.com> Date: Wed, 27 Nov 2002 00:40:39 -0500 From: "Daniel G. Petrie" Organization: Pingtel Corp. http://www.pingtel.com X-Mailer: Mozilla 4.73 [en]C-{C-UDP; EBM-SONY1} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Alan Johnston , Rohan Mahy , Robert Sparks , sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Replaces of early 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 Last week in Atlanta we had a sidebar discussion of the use of the Replaces header with early dialogs (draft-ietf-sip-replaces-02.txt). There is a problem with using Replaces on the UAS sided of an early dialog primarly due to forking. In a forking situation there are race conditions where either 1) the To tag is explcitly specified the INVITE with Replaces can lose the race to UAS before the branch is canceled and serially forked by the proxy. 2) if a wild card mechanism is used for the To tag you still have a race between INVITE with Replaces hitting the first UAS with no matching dialog and that of UAS where the dialog matches. The net result is that is is very hard to get predictable results if forking occurs. It seems equally difficult to determine that forking is not used in a particular environement. So the choices seem to be: 1) never allow Replaces with early dialogs 2) allow Replaces with early dialog only on the UAC 3) allow Replaces with early dialog on UAC and UAS with restricted environments. The best choice seems to be to allow replaces with early dialogs only on the UAC. This still provides the ability to do "Pick up" type services by replacing the dialog on the UAC. This means that we loose the ability for the caller to move to a different UA (e.g. administrator initiatates a call for an executive or caller want to switch to a different phone down the hall while the other end is ringing). This feature could perhaps be provided if the caller's UA uses 3PCC performing like a B2BUA until the call is setup at which time it can use REFER with Replaces. With respect to draft-ietf-sip-replaces-02.txt, section 7.1 gets removed and replaced with a statement that early dialogs cannot be Replaced on the UAS side. _______________________________________________ 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 Nov 27 02:39:52 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02563 for ; Wed, 27 Nov 2002 02:39:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAR7gFX05204 for sip-archive@odin.ietf.org; Wed, 27 Nov 2002 02:42: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 gAR7fZv05176; Wed, 27 Nov 2002 02:41: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 gAR7dhv05061 for ; Wed, 27 Nov 2002 02:39:43 -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 CAA02476 for ; Wed, 27 Nov 2002 02:36:49 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.9]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAR7dXYH008688; Wed, 27 Nov 2002 02:39:33 -0500 (EST) Message-ID: <3DE476B2.2010705@dynamicsoft.com> Date: Wed, 27 Nov 2002 02:39:30 -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: Adam Roach CC: "'sip@ietf.org'" Subject: Re: [Sip] i18n issue: composed characters References: <9BF66EBF6BEFD942915B4D4D45C051F3A6434D@DYN-TX-EXCH-001.dynamicsoft.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 Adam Roach wrote: >>-----Original Message----- >>From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >> >>I am surprised that the method of canonicalization is not >>addressed by >>Unicode. After all, don't they specify rules for equality >>checking (that >>is, after all, what we are after, just using canonicalization for >>equality checking)? Don't those rules include such encoding >>variations? >>I'm not a unicode expert, but this seems like a very basic issue. > > > I think my phrasing must have been a bit confusing. > > Unicode *definitely* specifies canonicalization. In fact, they > care so much about it, they specified *two* ways to do it. > > We need to pick one of these methods. From a skim of the relevant sections of Unicode, it wasn't clear to me which one was appropriate for us. Anyone have an informed opinion? -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 Nov 27 03:27:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03359 for ; Wed, 27 Nov 2002 03:27:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAR8U4M07529 for sip-archive@odin.ietf.org; Wed, 27 Nov 2002 03:30: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 gAR8TVv07485; Wed, 27 Nov 2002 03:29: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 gAR8Pxv07310 for ; Wed, 27 Nov 2002 03:25:59 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03252 for ; Wed, 27 Nov 2002 03:22:53 -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 <0H6800KMA7B610@mta0.huawei.com> for sip@ietf.org; Wed, 27 Nov 2002 16:23:33 +0800 (CST) Date: Wed, 27 Nov 2002 13:51:25 +0530 From: Prasanna Venkatesh In-reply-to: <3DE476B2.2010705@dynamicsoft.com> To: 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=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Sip] different messages with same call-id before 100 is sent out 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, Are there any specific scenarios where more than one request (from the same UA) having the same call-id is received by an UAC before it has sent out an 100 for the first request. The message may be of different dialogs and transactions. Overlap dialling is one such scenario, are there any other known scenarios like this? Regards, Prasanna _______________________________________________ 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 Nov 27 04:42:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04528 for ; Wed, 27 Nov 2002 04:42:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAR9ia012209 for sip-archive@odin.ietf.org; Wed, 27 Nov 2002 04:44: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 gAR9hxv12192; Wed, 27 Nov 2002 04:43:59 -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 gAR9gPv12124 for ; Wed, 27 Nov 2002 04:42:25 -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 EAA04489 for ; Wed, 27 Nov 2002 04:39:24 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAR9fM905422 for ; Wed, 27 Nov 2002 11:41:22 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Nov 2002 11:41:57 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 27 Nov 2002 11:41:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] RE: [Sip-implementors] Questions about Dialogs Date: Wed, 27 Nov 2002 11:41:55 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE700C@esebe019.ntc.nokia.com> Thread-Topic: [Sip-implementors] Questions about Dialogs Thread-Index: AcKFAyH1LEJMaaTkQLuhYEl2I63EPQAaPBhQBCFe5VA= To: , Cc: X-OriginalArrivalTime: 27 Nov 2002 09:41:56.0172 (UTC) FILETIME=[395F08C0:01C295F9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAR9gPv12125 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 continue discussing this issue... In RFC3261, its says: "For dialogs that have been established with an INVITE, the only target refresh request defined is re-INVITE (see Section 14). " RFC3265 doesn't mention anything to extend the above statement about target refresh requests, nor does sip-refer. Now, is it a general rule that any sip extension that creates a dialog, is allowed to refresh the target of an existing dialog? This is not mentioned anywhere. eg: dialog created with INVITE can be target refreshed with REFER and SUBSCRIBE. A new extension FOO also creates dialog and therefore is a target refresh request for INVITE. BAR on the other hand is a sip extension that doesn't create a dialog and therefore is not a target refresh request for INVITE. My sip stack has to be aware of all extensions is order to know which method creates dialogs and which one doesn't, and then decide if a target is to be refreshed or not. I must admit, that if I extend Adam's scenario below in that the subscription is now terminated and the dialog still exists (because of the INVITE), then targeting is valuable. But in this scenario valuable enough? I would like to hear from developers how they handled this situation, if any. Regards, Hisham > -----Original Message----- > From: ext hisham.khartabil@nokia.com > [mailto:hisham.khartabil@nokia.com] > Sent: Wednesday, November 06, 2002 10:23 AM > To: adam@dynamicsoft.com; sip@ietf.org > Cc: brett@broadsoft.com > Subject: [Sip] RE: [Sip-implementors] Questions about Dialogs > > > redirected to sip... > > > -----Original Message----- > > From: ext Adam Roach [mailto:adam@dynamicsoft.com] > > Sent: Tuesday, November 05, 2002 9:40 PM > > To: Khartabil Hisham (NMP/Helsinki); Adam Roach; > > sip-implementors@cs.columbia.edu > > Cc: brett@broadsoft.com > > Subject: RE: [Sip-implementors] Questions about Dialogs > > > > > > > -----Original Message----- > > > From: hisham.khartabil@nokia.com > [mailto:hisham.khartabil@nokia.com] > > > > > > May I suggest that we only allow target refresh requests to > > > have the same method as the request that created the dialog. > > > i.e.: only a reINVITE can be target refresh requests for a > > > dialog created by INVITE, only reSUBSCRIBE can be target > > > refresh requests for a dialog created by SUBSCRIBE. > > > > > > For a dialog created by INVITE, a SUBSCRIBE does not update > > > the target. For a dialog created by SUBSCRIBE, an INVITE does > > > not update the target. > > > > > > This is the only way to do it to avoid complexity and > > > confusion. Otherwise you got to start asking about REFER and > > > other extensions that create dialogs. > > > > > > I would prefer implementors to be able to build a generic > > > dialogs module in their stack that doesn't need to know about > > > methods. I mean what if I send a MESSAGE within a dialog? my > > > generic dialogs module no longer can be method agnostic > > > because it has to know that MESSAGE does not refresh a > > > target, but it has to know that SUBSCRIBE does... too complicated. > > > > How does your generic dialogs module know not to create a dialog > > when you send a MESSAGE that doesn't correspond to an existing > > dialog? > > Its up to the user of the module to know. Like a session > module on top of it. I don't want to update my dialogs module > for every extension. I'll just build modules on top of it. > Anyway, this is too much architecture stuff. > > > > > You already need to keep track of a variety of attributes for > > each method, such as which messages can start a dialog and which > > can't; in other words, you can't have generic handling for > > unknown methods. You must assign them attributes before your > > dialog manager can do anything sensible. > > > > Tracking which method initiated a dialog is no more complicated > > than tracking which methods can retarget. > > > > That said, allowing only the initiating method to retarget can be > > a rather severe restriction. I may have application logic that > > knows that it needs to retarget at some point, and it does > > so by sending an INVITE. However, with your proposal, that > > would fail if the dialog had been created with a SUBSCRIBE*. > > Instead, you'd need the application to keep track of which came > > first and use it for retargeting. Now, that seems messy. > > > > /a > > > > * What? How would one plausibly get an INVITE on a dialog > > created by a SUBSCRIBE, you ask? I'm glad you did. Imagine > > that I've subscribed to the terminal state of the phone > > on your desk, because I want to get ahold of you as soon > > as you get off the phone. When I finally get a NOTIFY to > > let me know that your terminal has transitioned to a "free" > > state (i.e. on-hook), I want to send an INVITE. Of course, > > I want to make sure I only contact that one terminal that > > just became free. The only way I can reliably do this is > > by sending an INVITE in the same dialog. There you go. > > This example doesn't clarify the need for an INVITE to > retarget a dialog initiated with a SUBSCRIBE. Its actually > saying that an INVITE needs to use the same target that was > established with the SUBSCRIBE. > > 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 > _______________________________________________ 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 Nov 27 09:29:01 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11335 for ; Wed, 27 Nov 2002 09:29:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAREVG029403 for sip-archive@odin.ietf.org; Wed, 27 Nov 2002 09:31: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 gAREUQv29335; Wed, 27 Nov 2002 09:30: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 gARESEv29205 for ; Wed, 27 Nov 2002 09:28:14 -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 JAA11118 for ; Wed, 27 Nov 2002 09:25:27 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.9]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gARESAYH008791; Wed, 27 Nov 2002 09:28:10 -0500 (EST) Message-ID: <3DE4D677.20203@dynamicsoft.com> Date: Wed, 27 Nov 2002 09:28:07 -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: Adam Roach CC: "'Dean Willis'" , sip@ietf.org Subject: Re: [Sip] DISCUSS on Service Route Discovery References: <9BF66EBF6BEFD942915B4D4D45C051F3A64347@DYN-TX-EXCH-001.dynamicsoft.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. Adam Roach wrote: >>-----Original Message----- >>From: Dean Willis [mailto:dean.willis@softarmor.com] >> >>The second concern seems to be more interesting. Is it reasonable to >>mandate that registrars implementing the Service-Route header >>field also >>MUST implement S/MIME? This doesn't say they have to USE it, just that >>they must IMPLEMENT it. >> >>My personal feeling is that implementing this in a registrar is fairly >>straightforward, and even the key management is easy, so it "does no >>harm" to include as a MUST. > > > I'm inclined to agree; first, though, I'd like to understand the threat > posed by a registrar that doesn't/can't use S/MIME versus one that > can. Not in the general context of registering, of course -- only > in the context of the extra functionality introduced by srvrtdisco. > > It's not obvious to me that this point is addressing an issue raised > by *this* draft, versus a general issue with SIP -- and it would > be Obviously Wrong (tm) to fix problems in the base spec in every > other document that mentions it, as opposed to just recording it > as a bug and fixing it next go round. I agree. I don't believe the threats specific to service route are worse than the general threats imposed through impersonating a registrar, which are explicitly called out in section 26.1.2 of bis. Indeed, the insertion of a fake 301 response to a REGISTER request is much more damaging than a fake service route, I believe. So, if we think that S/MIME is a MUST to protect service route, then its also a MUST for rfc 3261. I suppose the counter-argument might be this. Bis more or less assumes that there is the possibility of a direct connection between the client and registrar, as it talks about using TLS to secure registrations (Section 26.3.2.1). Almost by definition, that approach doesn't work for the problem space of service route, because of the existence of proxies between the UA and the registrar, not a common case. Thus, this draft is addressing a specific architecture where the normal bis security recommendations don't apply, and thus a different recommendation is needed. I'm not entirely sure I believe this counter-argument.... -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 Nov 27 10:52:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15829 for ; Wed, 27 Nov 2002 10:52:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARFsSt02959 for sip-archive@odin.ietf.org; Wed, 27 Nov 2002 10:54: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 gARFrDv02900; Wed, 27 Nov 2002 10:53: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 gARFpqv02732 for ; Wed, 27 Nov 2002 10:51:52 -0500 Received: from dyn-tx-app-007.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15692 for ; Wed, 27 Nov 2002 10:49:04 -0500 (EST) Received: from RjS.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id gARFpf105172; Wed, 27 Nov 2002 09:51:41 -0600 Subject: RE: [Sip] RE: [Sip-implementors] Questions about Dialogs From: Robert Sparks To: hisham.khartabil@nokia.com Cc: "adam@dynamicsoft.com" , sip@ietf.org, brett@broadsoft.com In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7FE700C@esebe019.ntc.nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB7FE700C@esebe019.ntc.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 27 Nov 2002 09:50:55 -0600 Message-Id: <1038412256.1452.129.camel@RjS.localdomain> Mime-Version: 1.0 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 Wed, 2002-11-27 at 03:41, hisham.khartabil@nokia.com wrote: > I would like to continue discussing this issue... > > In RFC3261, its says: > > "For dialogs that have been established with an > INVITE, the only target refresh request defined is re-INVITE (see > Section 14). " > > RFC3265 doesn't mention anything to extend the above statement about target refresh requests, nor does sip-refer. > > Now, is it a general rule that any sip extension that creates a dialog, is allowed to refresh the target of an existing dialog? This is not mentioned anywhere. I don't think we will find value in attempting to make a SUBSCRIBE dialog and and INVITE dialog different things if they share the same dialog identifiers. The state between them is inherently coupled (at the least because of CSeq management), so attempting to decouple them is doomed to sprawling complexity from the start. I believe it is better to model shared dialog state as exactly that, and share all of it in the same way. Thus, any method that can create a dialog can also refresh a dialog, and "refresh" must always mean the same thing without regard to method name. Otherwise, we are going to create _deep_ wells of confusion, race and edge conditions. The easiest ones to see are those involving CSeq management. I understand that this tight coupling is ugly. It would be very nice to have a separate piece of code deal with subscribes and invites, but if you want to share the dialog identifiers, you can't. You at least have to have the dialog management part in common (because of the CSeq issues). The better path to pursue is to find a good answer to the "Globally addressable URI problem" and provide a mechanism to associate two dialogs. Then we can avoid these nasty issues by never attempting to share dialog state this way. > > eg: dialog created with INVITE can be target refreshed with REFER and SUBSCRIBE. A new extension FOO also creates dialog and therefore is a target refresh request for INVITE. BAR on the other hand is a sip extension that doesn't create a dialog and therefore is not a target refresh request for INVITE. > > My sip stack has to be aware of all extensions is order to know which method creates dialogs and which one doesn't, and then decide if a target is to be refreshed or not. If you do not know the extension, you will reject the request and don't affect any existing dialogs. This is the same for methods you do know - if you reject a re-invite, the dialog that re-invite appeared in is unaffected (well, almost unaffected. You have to update the remote CSeq). > > I must admit, that if I extend Adam's scenario below in that the subscription is now terminated and the dialog still exists (because of the INVITE), then targeting is valuable. But in this scenario valuable enough? > > I would like to hear from developers how they handled this situation, if any. > > Regards, > Hisham > > > > -----Original Message----- > > From: ext hisham.khartabil@nokia.com > > [mailto:hisham.khartabil@nokia.com] > > Sent: Wednesday, November 06, 2002 10:23 AM > > To: adam@dynamicsoft.com; sip@ietf.org > > Cc: brett@broadsoft.com > > Subject: [Sip] RE: [Sip-implementors] Questions about Dialogs > > > > > > redirected to sip... > > > > > -----Original Message----- > > > From: ext Adam Roach [mailto:adam@dynamicsoft.com] > > > Sent: Tuesday, November 05, 2002 9:40 PM > > > To: Khartabil Hisham (NMP/Helsinki); Adam Roach; > > > sip-implementors@cs.columbia.edu > > > Cc: brett@broadsoft.com > > > Subject: RE: [Sip-implementors] Questions about Dialogs > > > > > > > > > > -----Original Message----- > > > > From: hisham.khartabil@nokia.com > > [mailto:hisham.khartabil@nokia.com] > > > > > > > > May I suggest that we only allow target refresh requests to > > > > have the same method as the request that created the dialog. > > > > i.e.: only a reINVITE can be target refresh requests for a > > > > dialog created by INVITE, only reSUBSCRIBE can be target > > > > refresh requests for a dialog created by SUBSCRIBE. > > > > > > > > For a dialog created by INVITE, a SUBSCRIBE does not update > > > > the target. For a dialog created by SUBSCRIBE, an INVITE does > > > > not update the target. > > > > > > > > This is the only way to do it to avoid complexity and > > > > confusion. Otherwise you got to start asking about REFER and > > > > other extensions that create dialogs. > > > > > > > > I would prefer implementors to be able to build a generic > > > > dialogs module in their stack that doesn't need to know about > > > > methods. I mean what if I send a MESSAGE within a dialog? my > > > > generic dialogs module no longer can be method agnostic > > > > because it has to know that MESSAGE does not refresh a > > > > target, but it has to know that SUBSCRIBE does... too complicated. > > > > > > How does your generic dialogs module know not to create a dialog > > > when you send a MESSAGE that doesn't correspond to an existing > > > dialog? > > > > Its up to the user of the module to know. Like a session > > module on top of it. I don't want to update my dialogs module > > for every extension. I'll just build modules on top of it. > > Anyway, this is too much architecture stuff. > > > > > > > > You already need to keep track of a variety of attributes for > > > each method, such as which messages can start a dialog and which > > > can't; in other words, you can't have generic handling for > > > unknown methods. You must assign them attributes before your > > > dialog manager can do anything sensible. > > > > > > Tracking which method initiated a dialog is no more complicated > > > than tracking which methods can retarget. > > > > > > That said, allowing only the initiating method to retarget can be > > > a rather severe restriction. I may have application logic that > > > knows that it needs to retarget at some point, and it does > > > so by sending an INVITE. However, with your proposal, that > > > would fail if the dialog had been created with a SUBSCRIBE*. > > > Instead, you'd need the application to keep track of which came > > > first and use it for retargeting. Now, that seems messy. > > > > > > /a > > > > > > * What? How would one plausibly get an INVITE on a dialog > > > created by a SUBSCRIBE, you ask? I'm glad you did. Imagine > > > that I've subscribed to the terminal state of the phone > > > on your desk, because I want to get ahold of you as soon > > > as you get off the phone. When I finally get a NOTIFY to > > > let me know that your terminal has transitioned to a "free" > > > state (i.e. on-hook), I want to send an INVITE. Of course, > > > I want to make sure I only contact that one terminal that > > > just became free. The only way I can reliably do this is > > > by sending an INVITE in the same dialog. There you go. > > > > This example doesn't clarify the need for an INVITE to > > retarget a dialog initiated with a SUBSCRIBE. Its actually > > saying that an INVITE needs to use the same target that was > > established with the SUBSCRIBE. > > > > 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 > > > _______________________________________________ > 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 Nov 27 11:15:44 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16927 for ; Wed, 27 Nov 2002 11:15:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARGI1v04768 for sip-archive@odin.ietf.org; Wed, 27 Nov 2002 11:18: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 gARGFYv04681; Wed, 27 Nov 2002 11:15:34 -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 gARGEfv04633 for ; Wed, 27 Nov 2002 11:14:41 -0500 Received: from imr1.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16812 for ; Wed, 27 Nov 2002 11:11:53 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id gARGEYd04297; Wed, 27 Nov 2002 10:14:34 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id gARGEYp14728; Wed, 27 Nov 2002 10:14:34 -0600 (CST) Received: from EAMMLEX034.lmc.ericsson.se (eammlex034.lmc.ericsson.se [142.133.1.134]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id gARGEXh16512; Wed, 27 Nov 2002 11:14:33 -0500 (EST) Received: by EAMMLEX034.lmc.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 27 Nov 2002 11:14:33 -0500 Message-ID: <32CD630F6CBED411AE180008C7894CBC0C037BA0@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'Jonathan Rosenberg'" , Adam Roach Cc: "'Dean Willis'" , sip@ietf.org Subject: RE: [Sip] DISCUSS on Service Route Discovery Date: Wed, 27 Nov 2002 11:14:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) 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 have to agree with Jonathan & Adam. Making this is MUST just to support service route *ONLY* is inconistent with RFC 3261. There are numerous things in RFC 3216 for which the same argument can apply but it does not. Lets be consistent. Rgds/gf > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, November 27, 2002 9:28 AM > To: Adam Roach > Cc: 'Dean Willis'; sip@ietf.org > Subject: Re: [Sip] DISCUSS on Service Route Discovery > > > inline. > > Adam Roach wrote: > >>-----Original Message----- > >>From: Dean Willis [mailto:dean.willis@softarmor.com] > >> > >>The second concern seems to be more interesting. Is it reasonable to > >>mandate that registrars implementing the Service-Route header > >>field also > >>MUST implement S/MIME? This doesn't say they have to USE > it, just that > >>they must IMPLEMENT it. > >> > >>My personal feeling is that implementing this in a > registrar is fairly > >>straightforward, and even the key management is easy, so it "does no > >>harm" to include as a MUST. > > > > > > I'm inclined to agree; first, though, I'd like to > understand the threat > > posed by a registrar that doesn't/can't use S/MIME versus one that > > can. Not in the general context of registering, of course -- only > > in the context of the extra functionality introduced by srvrtdisco. > > > > It's not obvious to me that this point is addressing an issue raised > > by *this* draft, versus a general issue with SIP -- and it would > > be Obviously Wrong (tm) to fix problems in the base spec in every > > other document that mentions it, as opposed to just recording it > > as a bug and fixing it next go round. > > I agree. I don't believe the threats specific to service > route are worse > than the general threats imposed through impersonating a registrar, > which are explicitly called out in section 26.1.2 of bis. Indeed, the > insertion of a fake 301 response to a REGISTER request is much more > damaging than a fake service route, I believe. > > So, if we think that S/MIME is a MUST to protect service > route, then its > also a MUST for rfc 3261. > > I suppose the counter-argument might be this. Bis more or > less assumes > that there is the possibility of a direct connection between > the client > and registrar, as it talks about using TLS to secure registrations > (Section 26.3.2.1). Almost by definition, that approach > doesn't work for > the problem space of service route, because of the existence > of proxies > between the UA and the registrar, not a common case. Thus, > this draft is > addressing a specific architecture where the normal bis security > recommendations don't apply, and thus a different > recommendation is needed. > > I'm not entirely sure I believe this counter-argument.... > > -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 > _______________________________________________ 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 Nov 28 02:10:38 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21309 for ; Thu, 28 Nov 2002 02:10:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAS7D3p32523 for sip-archive@odin.ietf.org; Thu, 28 Nov 2002 02:13: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 gAS7CFv32506; Thu, 28 Nov 2002 02:12: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 gAS78iv27973 for ; Thu, 28 Nov 2002 02:08:44 -0500 Received: from dharti.aplion.stpn.soft.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18944 for ; Thu, 28 Nov 2002 02:05:40 -0500 (EST) Received: from ravishiroor (localhost [127.0.0.1]) by dharti.aplion.stpn.soft.net (8.11.2/8.11.2) with SMTP id gAS795J25021; Thu, 28 Nov 2002 12:39:05 +0530 From: "Ravi Shiroor" To: "Prasanna Venkatesh" , Subject: RE: [Sip] different messages with same call-id before 100 is sent out Date: Thu, 28 Nov 2002 12:35:41 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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 Even in overlapped dialing scenario, the UAC wouldnt(shouldnt) be sending out a new INVITE before it receives a 484 OR before it CENCELs the last sent Invite. (else, it cant make sure that the (N)th INVITE reaches only after (N-1)th has reached the UAS) -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Prasanna Venkatesh Sent: Wednesday, November 27, 2002 1:51 PM To: sip@ietf.org Subject: [Sip] different messages with same call-id before 100 is sent out Hi, Are there any specific scenarios where more than one request (from the same UA) having the same call-id is received by an UAC before it has sent out an 100 for the first request. The message may be of different dialogs and transactions. Overlap dialling is one such scenario, are there any other known scenarios like this? Regards, Prasanna _______________________________________________ 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 Nov 28 03:12:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22638 for ; Thu, 28 Nov 2002 03:12:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAS8FAW03743 for sip-archive@odin.ietf.org; Thu, 28 Nov 2002 03:15: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 gAS8EVv03726; Thu, 28 Nov 2002 03:14: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 gAS8CQv03655 for ; Thu, 28 Nov 2002 03:12:26 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22601 for ; Thu, 28 Nov 2002 03:09:29 -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 <0H6A00MDR19T8Q@mta0.huawei.com> for sip@ietf.org; Thu, 28 Nov 2002 16:08:22 +0800 (CST) Date: Thu, 28 Nov 2002 13:36:12 +0530 From: Prasanna Venkatesh Subject: RE: [Sip] different messages with same call-id before 100 is sent out In-reply-to: To: Ravi Shiroor , sip@ietf.org, sip-implementors@cs.columbia.edu 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=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 agree with your idea that there should be a way by which it should be ensured that the Nth INVITE reaches after the (N-1)th INVITE, but it is also mandatory according to the overlapped dialing draft that CANCEL is sent after the Nth INVITE is sent, in fact the CANCEL should be sent only after a 200 is received for one of the INVITEs. Quoting from "draft-ietf-sipping-overlap-02" 3.6 Canceling pending INVITE transactions When a gateway sends a new INVITE containing new digits, it should not CANCEL the previous INVITE transaction. ......... ......... However, once a 200 OK response has been received, the gateway should CANCEL all the other INVITE transactions were generated. In any case is it valid that an overlapping INVITE is sent before a 100 is received for the previous INVITE. Coming back to the original question, what are the conditions that an INVITE can be received before 100 is sent for a pending INVITE, both bearing the same call-ids but belonging to different dialogs. Regards, Prasanna -----Original Message----- From: Ravi Shiroor [mailto:rshiroor@aplion.stpn.soft.net] Sent: Thursday, November 28, 2002 12:36 PM To: Prasanna Venkatesh; sip@ietf.org Subject: RE: [Sip] different messages with same call-id before 100 is sent out Even in overlapped dialing scenario, the UAC wouldnt(shouldnt) be sending out a new INVITE before it receives a 484 OR before it CENCELs the last sent Invite. (else, it cant make sure that the (N)th INVITE reaches only after (N-1)th has reached the UAS) -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Prasanna Venkatesh Sent: Wednesday, November 27, 2002 1:51 PM To: sip@ietf.org Subject: [Sip] different messages with same call-id before 100 is sent out Hi, Are there any specific scenarios where more than one request (from the same UA) having the same call-id is received by an UAC before it has sent out an 100 for the first request. The message may be of different dialogs and transactions. Overlap dialling is one such scenario, are there any other known scenarios like this? Regards, Prasanna _______________________________________________ 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 Nov 28 04:33:55 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23825 for ; Thu, 28 Nov 2002 04:33:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAS9aKA08078 for sip-archive@odin.ietf.org; Thu, 28 Nov 2002 04:36:20 -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 gAS9Zsv08017; Thu, 28 Nov 2002 04:35: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 gAS9Rsv07795 for ; Thu, 28 Nov 2002 04:27:54 -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 EAA23751 for ; Thu, 28 Nov 2002 04:24:58 -0500 (EST) Received: from hendrix.lmf.ericsson.se (hendrix.lmf.ericsson.se [131.160.11.8]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAS9RPQ1013589; Thu, 28 Nov 2002 10:27:26 +0100 (MET) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.3]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id gAS9RPu4026092; Thu, 28 Nov 2002 11:27:25 +0200 (EET) Message-ID: <3DE5E17C.13A2944D@lmf.ericsson.se> Date: Thu, 28 Nov 2002 11:27:24 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Prasanna Venkatesh CC: Ravi Shiroor , sip@ietf.org, sip-implementors@cs.columbia.edu Subject: Re: [Sip] different messages with same call-id before 100 is sent out 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 Hi, in the overlap case we do not care if the nth INVITE reaches the other end before the (n-1)th INVITe, so you do not have to wait for anything before sending the new INVITE. > Coming back to the original question, what are the conditions that an INVITE > can be received before 100 is sent for a pending INVITE, both bearing the > same call-ids but belonging to different dialogs. the only proposal I am aware of that uses the same Call-ID for different dialgogs is the overlap draft. Therefore, (if we forget about overlap) it is unlikely that you receive two INVITEs with the same Call-ID that belong to different dialogs. If both INVITEs come from different UACs, the Call-ID will be different, since they typically use the something@host format. And if both INVITEs come from the same UAC, it will make sure that the Call-IDs are different. Regards, 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 Nov 28 04:36:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23875 for ; Thu, 28 Nov 2002 04:36:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAS9cY908775 for sip-archive@odin.ietf.org; Thu, 28 Nov 2002 04:38: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 gAS9cDv08759; Thu, 28 Nov 2002 04:38: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 gAS9YBv07959 for ; Thu, 28 Nov 2002 04:34:11 -0500 Received: from fmis402r.omnitel.it (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA23809; Thu, 28 Nov 2002 04:31:14 -0500 (EST) From: loretosa@vizzavi.it Received: from fmis440.omnitel.it by fmis402r.omnitel.it via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 28 Nov 2002 09:33:59 UT Received: (private information removed) Received: (private information removed) Content-Class: urn:content-classes:message To: , , Date: Thu, 28 Nov 2002 10:22:42 +0100 Message-ID: <09a401c296bf$b4400690$5cde010a@omnitel.it> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft CDO for Windows 2000 Thread-Index: AcKWv7RAeXh5h/VxRNaStFQPlrT1hw== X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] use of a connection transport protocol 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 sometime ago, I've read some mails about the possibility of change UDP (connectionless) as "default" transport protocol with TCP (connection) transport protocol what about this proposal ? best regards sal _______________________________________________ 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 Nov 28 08:10:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27272 for ; Thu, 28 Nov 2002 08:10:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gASDCPW19646 for sip-archive@odin.ietf.org; Thu, 28 Nov 2002 08:12: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 gASDBrv19631; Thu, 28 Nov 2002 08:11: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 gASDAtv19595 for ; Thu, 28 Nov 2002 08:10:55 -0500 Received: from mtiwmhc13.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27243 for ; Thu, 28 Nov 2002 08:08:07 -0500 (EST) Received: from cs.columbia.edu ([12.84.225.123]) by mtiwmhc13.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20021128131051.FIGI24110.mtiwmhc13.worldnet.att.net@cs.columbia.edu>; Thu, 28 Nov 2002 13:10:51 +0000 Message-ID: <3DE6155B.7050301@cs.columbia.edu> Date: Thu, 28 Nov 2002 08:08:43 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Adam Roach , "'sip@ietf.org'" Subject: Re: [Sip] i18n issue: composed characters References: <9BF66EBF6BEFD942915B4D4D45C051F3A6434D@DYN-TX-EXCH-001.dynamicsoft.com> <3DE476B2.2010705@dynamicsoft.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 The work of the iDNS WG is applicable here, as in http://www.ietf.org/internet-drafts/draft-ietf-idn-nameprep-11.txt and references (stringprep). Jonathan Rosenberg wrote: > > > Adam Roach wrote: > >>> -----Original Message----- >>> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>> >>> I am surprised that the method of canonicalization is not addressed >>> by Unicode. After all, don't they specify rules for equality checking >>> (that is, after all, what we are after, just using canonicalization >>> for equality checking)? Don't those rules include such encoding >>> variations? I'm not a unicode expert, but this seems like a very >>> basic issue. >> >> >> >> I think my phrasing must have been a bit confusing. >> >> Unicode *definitely* specifies canonicalization. In fact, they >> care so much about it, they specified *two* ways to do it. >> >> We need to pick one of these methods. > > > From a skim of the relevant sections of Unicode, it wasn't clear to me > which one was appropriate for us. Anyone have an informed opinion? > > -Jonathan R. > _______________________________________________ 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 Nov 28 10:12:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28893 for ; Thu, 28 Nov 2002 10:12:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gASFEex25420 for sip-archive@odin.ietf.org; Thu, 28 Nov 2002 10:14: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 gASFEGv25405; Thu, 28 Nov 2002 10:14: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 gASFCXv25357 for ; Thu, 28 Nov 2002 10:12:33 -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 KAA28880 for ; Thu, 28 Nov 2002 10:09:42 -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 gASEpWi01135 for ; Thu, 28 Nov 2002 20:21:33 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256C7F.00533880 ; Thu, 28 Nov 2002 20:38:59 +0530 X-Lotus-FromDomain: HSSBLR To: sip@ietf.org Message-ID: <65256C7F.00533776.00@sampark.hss.hns.com> Date: Thu, 28 Nov 2002 20:38:56 +0530 Subject: SIPS related clarifications (was: [Sip] SIPS question) 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 all, There were couple of interesting questions raised in this thread by Christer earlier this month that perhaps got left out in the middle of the conversation. Wanted to get my understanding regarding inter-mingling of "sip:" and "sips:" URLs within the spec clear. Sorry if any questions had got resolved earlier and I missed the mail as I'm entering the discussion late. Any pointers are welcome. * Is it allowed for a SIP proxy that got a request on TLS to forward the request downstream on a non-TLS protocol? Jon Peterson had suggested that "sips" was designed to allow selective hops in the path to be secure, while Rosenberg had mentioned that the presence of "sips:" should imply that the end-to-end path is secure. I guess the way I understand the spec stands at present is that if the Req-URI is re-written to a "sips:" URL at any stage of the routing, then any hop downstream _from_this_hop_onwards_ has to forward the request on TLS. The entire path (from UA to UA) need not be secure. Is this correct? Or can the request path be set-up with some hops on TLS and others on non-TLS in any combination of them? * What is the response code to be used by a UAS to inform the UAC that it is not willing to accept insecure calls and that the UAC should retry the request on TLS? * Also, another question Christer had raised in the discussion was end-points should not be allowed to send REGISTER with AoR as "sip:" and Contacts as "sips:" since end-to-end security (if that's what "sips:" implies always) would not be assured if a request for that end-point came with Req-URI of "sip:". Is this the case? * Finally, the conclusion of the earlier thread seemed to be that the last sentence of Section 8.1.2 (paragraph 1) is incorrect and the UAC's choice for the transport protocol should not rest on the req-uri's scheme being "sips:" alone. But this was not logged into bugzilla for resolution? Did I miss something? Thanks for your time. Regards, 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 -------------------------------------------------------- _______________________________________________ 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 Nov 28 11:46:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00215 for ; Thu, 28 Nov 2002 11:46:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gASGnFk29911 for sip-archive@odin.ietf.org; Thu, 28 Nov 2002 11:49: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 gASGmkv29890; Thu, 28 Nov 2002 11:48: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 gASGkOv29839 for ; Thu, 28 Nov 2002 11:46:24 -0500 Received: from ihemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00166 for ; Thu, 28 Nov 2002 11:43:34 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gASGkHR07767 for ; Thu, 28 Nov 2002 11:46:17 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Nov 2002 16:46:16 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB006CCB0A5@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "George Foti (LMC)" , "'Jonathan Rosenberg'" , Adam Roach Cc: "'Dean Willis'" , sip@ietf.org Subject: RE: [Sip] DISCUSS on Service Route Discovery Date: Thu, 28 Nov 2002 16:46:12 -0000 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 would prefer to keep this requirement at the same level as RFC 3261. Failing that I would have to insist on an applicability statement that said that the MUST applied only if other security mechanisms were not available. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: George Foti (LMC) [mailto:George.Foti@ericsson.ca] > Sent: 27 November 2002 16:15 > To: 'Jonathan Rosenberg'; Adam Roach > Cc: 'Dean Willis'; sip@ietf.org > Subject: RE: [Sip] DISCUSS on Service Route Discovery > > > I have to agree with Jonathan & Adam. > Making this is MUST just to support service route *ONLY* is > inconistent with RFC 3261. > There are numerous things in RFC 3216 for which the same > argument can apply but it does not. > Lets be consistent. > Rgds/gf > > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Wednesday, November 27, 2002 9:28 AM > > To: Adam Roach > > Cc: 'Dean Willis'; sip@ietf.org > > Subject: Re: [Sip] DISCUSS on Service Route Discovery > > > > > > inline. > > > > Adam Roach wrote: > > >>-----Original Message----- > > >>From: Dean Willis [mailto:dean.willis@softarmor.com] > > >> > > >>The second concern seems to be more interesting. Is it > reasonable to > > >>mandate that registrars implementing the Service-Route header > > >>field also > > >>MUST implement S/MIME? This doesn't say they have to USE > > it, just that > > >>they must IMPLEMENT it. > > >> > > >>My personal feeling is that implementing this in a > > registrar is fairly > > >>straightforward, and even the key management is easy, so > it "does no > > >>harm" to include as a MUST. > > > > > > > > > I'm inclined to agree; first, though, I'd like to > > understand the threat > > > posed by a registrar that doesn't/can't use S/MIME versus one that > > > can. Not in the general context of registering, of course -- only > > > in the context of the extra functionality introduced by > srvrtdisco. > > > > > > It's not obvious to me that this point is addressing an > issue raised > > > by *this* draft, versus a general issue with SIP -- and it would > > > be Obviously Wrong (tm) to fix problems in the base spec in every > > > other document that mentions it, as opposed to just recording it > > > as a bug and fixing it next go round. > > > > I agree. I don't believe the threats specific to service > > route are worse > > than the general threats imposed through impersonating a registrar, > > which are explicitly called out in section 26.1.2 of bis. > Indeed, the > > insertion of a fake 301 response to a REGISTER request is much more > > damaging than a fake service route, I believe. > > > > So, if we think that S/MIME is a MUST to protect service > > route, then its > > also a MUST for rfc 3261. > > > > I suppose the counter-argument might be this. Bis more or > > less assumes > > that there is the possibility of a direct connection between > > the client > > and registrar, as it talks about using TLS to secure registrations > > (Section 26.3.2.1). Almost by definition, that approach > > doesn't work for > > the problem space of service route, because of the existence > > of proxies > > between the UA and the registrar, not a common case. Thus, > > this draft is > > addressing a specific architecture where the normal bis security > > recommendations don't apply, and thus a different > > recommendation is needed. > > > > I'm not entirely sure I believe this counter-argument.... > > > > -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 > > > _______________________________________________ > 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 Nov 28 13:45:46 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02293 for ; Thu, 28 Nov 2002 13:45:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gASIm6503425 for sip-archive@odin.ietf.org; Thu, 28 Nov 2002 13:48: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 gASIlVv03412; Thu, 28 Nov 2002 13:47: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 gASIjev03365 for ; Thu, 28 Nov 2002 13:45:40 -0500 Received: from dev1.dasecurenetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02219 for ; Thu, 28 Nov 2002 13:42:48 -0500 (EST) Received: from infravast.com (dev1.dasecurenetworks.com [192.168.0.151]) by dev1.dasecurenetworks.com (8.11.6/8.11.6) with ESMTP id gAS0lR704206; Wed, 27 Nov 2002 18:47:47 -0600 Message-ID: <3DE5679E.7B4EB343@infravast.com> Date: Wed, 27 Nov 2002 18:47:26 -0600 From: Chris Martin Reply-To: dallasace@infravast.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: "George Foti (LMC)" , "'Jonathan Rosenberg'" , Adam Roach , "'Dean Willis'" , sip@ietf.org Subject: Re: [Sip] DISCUSS on Service Route Discovery References: <475FF955A05DD411980D00508B6D5FB006CCB0A5@en0033exch001u.uk.lucent.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 "Drage, Keith (Keith)" wrote: > > I would prefer to keep this requirement at the same level as RFC 3261. > > Failing that I would have to insist on an applicability statement that said that the MUST applied only if other security mechanisms were not available. > > Keith > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > > -----Original Message----- > > From: George Foti (LMC) [mailto:George.Foti@ericsson.ca] > > Sent: 27 November 2002 16:15 > > To: 'Jonathan Rosenberg'; Adam Roach > > Cc: 'Dean Willis'; sip@ietf.org > > Subject: RE: [Sip] DISCUSS on Service Route Discovery > > > > > > I have to agree with Jonathan & Adam. > > Making this is MUST just to support service route *ONLY* is > > inconistent with RFC 3261. > > There are numerous things in RFC 3216 for which the same > > argument can apply but it does not. > > Lets be consistent. > > Rgds/gf > > > > > > > -----Original Message----- > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > Sent: Wednesday, November 27, 2002 9:28 AM > > > To: Adam Roach > > > Cc: 'Dean Willis'; sip@ietf.org > > > Subject: Re: [Sip] DISCUSS on Service Route Discovery > > > > > > > > > inline. > > > > > > Adam Roach wrote: > > > >>-----Original Message----- > > > >>From: Dean Willis [mailto:dean.willis@softarmor.com] > > > >> > > > >>The second concern seems to be more interesting. Is it > > reasonable to > > > >>mandate that registrars implementing the Service-Route header > > > >>field also > > > >>MUST implement S/MIME? This doesn't say they have to USE > > > it, just that > > > >>they must IMPLEMENT it. > > > >> > > > >>My personal feeling is that implementing this in a > > > registrar is fairly > > > >>straightforward, and even the key management is easy, so > > it "does no > > > >>harm" to include as a MUST. > > > > > > > > > > > > I'm inclined to agree; first, though, I'd like to > > > understand the threat > > > > posed by a registrar that doesn't/can't use S/MIME versus one that > > > > can. Not in the general context of registering, of course -- only > > > > in the context of the extra functionality introduced by > > srvrtdisco. > > > > > > > > It's not obvious to me that this point is addressing an > > issue raised > > > > by *this* draft, versus a general issue with SIP -- and it would > > > > be Obviously Wrong (tm) to fix problems in the base spec in every > > > > other document that mentions it, as opposed to just recording it > > > > as a bug and fixing it next go round. > > > > > > I agree. I don't believe the threats specific to service > > > route are worse > > > than the general threats imposed through impersonating a registrar, > > > which are explicitly called out in section 26.1.2 of bis. > > Indeed, the > > > insertion of a fake 301 response to a REGISTER request is much more > > > damaging than a fake service route, I believe. > > > > > > So, if we think that S/MIME is a MUST to protect service > > > route, then its > > > also a MUST for rfc 3261. > > > > > > I suppose the counter-argument might be this. Bis more or > > > less assumes > > > that there is the possibility of a direct connection between > > > the client > > > and registrar, as it talks about using TLS to secure registrations > > > (Section 26.3.2.1). Almost by definition, that approach > > > doesn't work for > > > the problem space of service route, because of the existence > > > of proxies > > > between the UA and the registrar, not a common case. Thus, > > > this draft is > > > addressing a specific architecture where the normal bis security > > > recommendations don't apply, and thus a different > > > recommendation is needed. > > > > > > I'm not entirely sure I believe this counter-argument.... > > > > > > -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 > > > > > _______________________________________________ > > 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 Nov 29 13:14:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04746 for ; Fri, 29 Nov 2002 13:14:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gATIH4u13716 for sip-archive@odin.ietf.org; Fri, 29 Nov 2002 13:17: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 gATIGIv13674; Fri, 29 Nov 2002 13:16: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 gATIBwv13546 for ; Fri, 29 Nov 2002 13:11:58 -0500 Received: from imo-d02.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04591 for ; Fri, 29 Nov 2002 13:09:07 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-d02.mx.aol.com (mail_out_v34.13.) id r.51.27e94654 (3699); Fri, 29 Nov 2002 13:07:52 -0500 (EST) Message-ID: <51.27e94654.2b1906f7@aol.com> Date: Fri, 29 Nov 2002 13:07:51 EST Subject: Re: [Sip] different messages with same call-id before 100 is sent out To: Gonzalo.Camarillo@lmf.ericsson.se, prasanna@huawei.com CC: rshiroor@aplion.stpn.soft.net, sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_51.27e94654.2b1906f7_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 51 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: , --part1_51.27e94654.2b1906f7_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 11/28/2002 5:08:11 AM Eastern Standard Time, Gonzalo.Camarillo@lmf.ericsson.se writes: > in the overlap case we do not care if the nth INVITE reaches the other > end before the (n-1)th INVITe, so you do not have to wait for anything > before sending the new INVITE. > > [MAP] This may be true as long as the "other end" knows to throw away the old INVITE (with fewer digits). However, I believe that the very fact that INVITE's can arrive out of order leads to significant difficulty, since their correct interpretation depends on the order. Going back to some earlier comments, I believe there must be a requirement that, for the PSTN-IP-PSTN case (which I think is the focus in this whole discussion), that a single IAM received on the ingress side (of IP) must result in exactly one IAM being sent on the egress side back to the PSTN. There may be fewer (or no) SAMs sent than received, for example, if the IP portion, at either the ingress or egress GW, does overlap to en-bloc operation, or simply has the smarts to put multiple digits (from SAMs) together. I believe that a solution to meeting this requirement (single IAM) has a significant impact on all the other discussions about out-of-order INVITES, same or different Call-IDs, etc. Therefore, unless it can be agreed that this is a requirement, all the other discussion is meaningless. I raise this point especially with relation to my proposals in IEPREP for a priority-based service for a military application which includes preemption in the circuit switched world using SS#7 (MLPP). Multiple IAMs (for high priority calls) would have the unacceptable result of preempting calls and then releasing the IAM when another arrived (or took another path). Is it possible to agree that this single IAM rule should be followed? Mike Pierce Artel --part1_51.27e94654.2b1906f7_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 11/28/2002 5:08:11 AM Eastern Standard Time, Gonzalo.Camarillo@lmf.ericsson.se writes:


in the overlap case we do not care if the nth INVITE reaches the other
end before the (n-1)th INVITe, so you do not have to wait for anything
before sending the new INVITE.



[MAP] This may be true as long as the "other end" knows to throw away the old INVITE (with fewer digits). However, I believe that the very fact that INVITE's can arrive out of order leads to significant difficulty, since their correct interpretation depends on the order.

Going back to some earlier comments, I believe there must be a requirement that, for the PSTN-IP-PSTN case (which I think is the focus in this whole discussion), that a single IAM received on the ingress side (of IP) must result in exactly one IAM being sent on the egress side back to the PSTN. There may be fewer (or no) SAMs sent than received, for example, if the IP portion, at either the ingress or egress GW, does overlap to en-bloc operation, or simply has the smarts to put multiple digits (from SAMs) together.

I believe that a solution to meeting this requirement (single IAM) has a significant impact on all the other discussions about out-of-order INVITES, same or different Call-IDs, etc. Therefore, unless it can be agreed that this is a requirement, all the other discussion is meaningless.

I raise this point especially with relation to my proposals in IEPREP for a priority-based service for a military application which includes preemption in the circuit switched world using SS#7 (MLPP). Multiple IAMs (for high priority calls) would have the unacceptable result of preempting calls and then releasing the IAM when another arrived (or took another path).

Is it possible to agree that this single IAM rule should be followed?

Mike Pierce
Artel


--part1_51.27e94654.2b1906f7_boundary-- _______________________________________________ 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 Nov 29 19:37:39 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12079 for ; Fri, 29 Nov 2002 19:37:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAU0e2N29129 for sip-archive@odin.ietf.org; Fri, 29 Nov 2002 19:40: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 gAU0dYv29074; Fri, 29 Nov 2002 19:39:34 -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 gAU0bMv29043 for ; Fri, 29 Nov 2002 19:37:22 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12050 for ; Fri, 29 Nov 2002 19:34:28 -0500 (EST) From: Stephane.Coulombe@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAU0bEU14907 for ; Fri, 29 Nov 2002 18:37:14 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 29 Nov 2002 18:37:12 -0600 Received: from daebe004.NOE.Nokia.com ([172.18.242.201]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 29 Nov 2002 16:37:12 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 29 Nov 2002 18:37:11 -0600 Message-ID: <97C16120D52CD249ADE310B69842D5B9011DC8CD@daebe004.americas.nokia.com> Thread-Topic: Caller Preferences and Callee Capabilities: comments on version 7 Thread-Index: AcKYCJ7skidJtFYBTD2aqCP+Z+xVyg== To: , Cc: X-OriginalArrivalTime: 30 Nov 2002 00:37:12.0154 (UTC) FILETIME=[9F6AEBA0:01C29808] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAU0bMv29044 Subject: [Sip] Caller Preferences and Callee Capabilities: comments on version 7 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 Jonathan and Henning, I would like to comment on the latest version of "Session Initiation Protocol (SIP) Caller Preferences and Callee Capabilities" document. The document significantly improved from the previous version. However, it still has many shortcomings, which I would like to address here. First, I am a bit concerned about the restricted way RFC 2533 is used, by saying: "The feature predicate constructed by a UA MUST be an AND of terms. Each term is either an OR of simple filters (called a disjunction), or a single simple filter. In the case of an OR of simple filters, each filter MUST indicate feature values for the same feature tag (i.e., the disjunction represents a set of values for a particular feature tag), and each element of the conjunction MUST be for a different feature tag. Each filter can be an equality, the negation of an equality, or in the case of numeric feature tags, an inequality or range" this pretty much cuts the legs of RFC 2533. Not only it has the restriction that it needs to be a serie of ORs inside a big AND. But the terms in the OR need to have same feature tags. This is very limiting especially if you want to deal with media content. A simple example from RFC 2533: (| (& (pix-x=750) (pix-y=500) (color=15) ) (& (dpi=300) (ua-media=stationery) (papersize=iso-A4) ) ) would not be acceptable according to the proposed document. To express caller's capabilities, "AND"ing terms is often sufficient (but not always) but certainly not for expressing callee capabilities which should be a big "OR" of supported features. RFC 2533 is full of "OR" examples. E.g. (| (& (| (& (pix-x<=640) (pix-y<=480) (color<=16777216) ) (& (pix-x<=800) (pix-y<=600) (color<=65535) ) (& (pix-x<=1024) (pix-y<=768) (color<=256) ) ) (ua-media=screen) ) (& (dpi=300) (ua-media=stationery) (papersize=iso-A4) ) ) How to interpret the following callee capabilities? Contact: sip:1.2.3.4;type="video/H263,image/jpeg,audio/amr";video="TRUE",audio="TRUE",resolution="#<200" According to the rule, (& (| (type=video/H263) (type-image/jpeg) (type=audio/amr) (video=TRUE) (audio=TRUE) (resolution < 200) ) This is not the way RFC 2533 would represent a terminal supporting audio OR video (the syntax here suggests that the received media MUST be video AND audio). According to the rule, (& (| (type=video/H263) (type-image/jpeg) (type=audio/amr) (video=TRUE) (audio=TRUE) (resolution < 200) ) This is not the way RFC 2533 would represent a terminal supporting audio OR video (the syntax here suggests that the received media MUST be video AND audio). According to the rule, (& (| (type=video/H263) (type-image/jpeg) (type=audio/amr) (video=TRUE) (audio=TRUE) (resolution < 200) ) This is not the way RFC 2533 would represent a terminal supporting audio OR video (the syntax here suggests that the received media MUST be video AND audio). According to the rule, (& (| (type=video/H263) (type-image/jpeg) (type=audio/amr) (video=TRUE) (audio=TRUE) (resolution < 200) ) This is not the way RFC 2533 would represent a terminal supporting audio OR video (the syntax here suggests that the received media MUST be video AND audio). Therefore, I also share the concern raised during the SIP meeting regarding the reference to RFC 2533 but definition of a new syntax in the document. The proposal should be better aligned with RFC 2533. The resolution attribute would better apply to the specific MIME type rather than be general for all media types. E.g. | (& (type=image/jpeg) (resolution<640)) & (type=video/h263) (resolution<176))) I am also concerned about the usage of a range in capabilities. For instance, if the caller uses resolution="#R5..100" as in the document. If callee capabilities are resolution="#R5..50", then I guess that terminal is acceptable because intersection is not zero. Then, what happens to the terminal if the sender sends 100 pixel image because system said it was okay? Same problem if callee capability resolution is 50 instead of a range. Caller should not use a range but a constraint like resolution > 100 if he wants to make sure 100pixel image can be sent. Presently, the document mostly focuses on callee capabilities that could be useful to a caller to set preferences on. Indeed callee capabilities include: methods, events, etc. But the scope is general and also applies to terminal characteristics which can be used in a broader range of situations and applications (the document indeed gives example of resolution, format types, etc.). Therefore, it would be good if these callee capabilities would not be limited to the REGISTER method but be part of other methods such as OPTIONS (for someone to learn about these capabilities), SUBSCRIBE (for presence server to be able to create appropriate presence messages), etc. In that manner, not only the specification can be used for message routing based on caller preferences but also based on knowledge of callee capabilities (either in routing stage or at the sending end). In summary, here are my recommendations: - Align the syntax and overall functionality to use full extent of RFC 2533. o Remove the restriction of having a serie of "OR" in a big "AND" in syntax. o Fix matching problem with ranges. o Fix other syntax problems outlined above. o Allow and add more detailed media capability description and preferences (e.g. resolution can apply to specific MIME types. - I suggest to add the descriptors used in draft-coulombe-message-adaptation-framework-00.txt : 1. length: maximum size of the entity specified. It could apply to the whole message or to specific MIME types. 2. media-pix-x: horizontal resolution of visual media (e.g. image or video). It could apply to all images or video or to specific MIME types. 3. media-pix-y: vertical resolution of visual media (e.g. image or video). It could apply to all images or video or to specific MIME types. As described in the document, it should be possible to associate "length" to the whole message or to specific MIME types. These feature tags are quite important for mobile terminals and some handheld devices. Note that the resolution is NOT necessarily the display resolution, but rather what the terminal can support (usually larger than the display resolution). For instance, I may want to route a message containing an image to a terminal that support high-enough resolution. - Extend the methods where the callee capabilities are provided (not just REGISTER but also SUBSCRIBE, OPTIONS, etc.) Stephane _______________________________________________ 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 Nov 29 23:02:29 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15701 for ; Fri, 29 Nov 2002 23:02:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAU44qG03948 for sip-archive@odin.ietf.org; Fri, 29 Nov 2002 23:04: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 gAU44Pv03938; Fri, 29 Nov 2002 23:04: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 gAU42ov03882 for ; Fri, 29 Nov 2002 23:02:50 -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 WAA15639 for ; Fri, 29 Nov 2002 22:59:54 -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 gAU42GQs028612; Fri, 29 Nov 2002 22:02:27 -0600 From: "Dean Willis" To: , Subject: RE: [Sip] B2BUA Date: Fri, 29 Nov 2002 22:02:10 -0600 Message-ID: <000f01c29825$4ed3a3e0$0100a8c0@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal 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 Juan-Carlos said: > Back-to-Back User Agent: A SIP element being able to handle a > collection of "n" User Agents (behaving each one as UAC and > UAS, according to SIP rules), which are linked by some > application logic that is fully independent of the SIP protocol rules. This seems like a reasonable definition. Poll: Would it be worth including this in 3261bis? Do we need to say N>1? -- 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