From mailnull@www1.ietf.org Sun Jun 1 22:14:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09490 for ; Sun, 1 Jun 2003 22:14:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h522E3n16922 for sip-archive@odin.ietf.org; Sun, 1 Jun 2003 22:14:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h522BUB16777; Sun, 1 Jun 2003 22:11:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5224iB15672 for ; Sun, 1 Jun 2003 22:04:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09223 for ; Sun, 1 Jun 2003 22:04:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Meez-0006hD-00 for sip@ietf.org; Sun, 01 Jun 2003 22:02:54 -0400 Received: from [61.144.161.2] (helo=mta0.huawei.com) by ietf-mx with esmtp (Exim 4.12) id 19Meey-0006gw-00 for sip@ietf.org; Sun, 01 Jun 2003 22:02:53 -0400 Received: from p70008 (mta0.huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HFU006DQ0CAV9@mta0.huawei.com> for sip@ietf.org; Mon, 02 Jun 2003 10:02:37 +0800 (CST) Date: Mon, 02 Jun 2003 10:03:51 +0800 From: Prasanna Venkatesh Subject: RE: [Sip] Why do we need 3-way handshake for INVITE transaction.... In-reply-to: <006501c326e8$f7622b60$5d02120a@in.huawei.com> To: "Nataraju A.B." , Arjun Roychowdhury , Vishal Phirke Cc: sip@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi, One of the simplest policies could be accept the first 200. After the UA receives the first 200, it sends a ACK+BYE for all subsequent 200 responses. However for a very intelligent UA (C&s) pair, it could use Call-Info to determine the selection, the call-info being a part of the 200 response. The call-info could either containing a link to a URL on reaching which the UAC could determine the type of callee or it could be a business-card using which it could determien the type of callee. There are crude ways of doing this also, like using say the URL or display name of the Contact, though it is not advisable. But I do not know a clean way where the callee mentions to the caller the kind of device it is or the identity of the person answering the call (as the display name of the To is also fixed by the UAC). Any solution to do this? Cheers, Prasanna -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Nataraju A.B. Sent: Saturday, May 31, 2003 4:21 AM To: Arjun Roychowdhury; Vishal Phirke Cc: sip@ietf.org; sip-admin@ietf.org; Sip-implementors@cs.columbia.edu Subject: Re: [Sip] Why do we need 3-way handshake for INVITE transaction.... ----- Original Message ----- From: "Arjun Roychowdhury" To: "Vishal Phirke" Cc: "Nataraju A.B." ; ; Sent: Saturday, May 31, 2003 1:27 AM Subject: Re: [Sip] Why do we need 3-way handshake for INVITE transaction.... > On 05/30/2003 03:03:53 PM, "Vishal Phirke" wrote: > > > 2. Invites can be forked. And if multiple destinations send > > 200 OK, you > > don't want to end up with multiple connections. Instead, 3-way > > handshake > > allows the decision of accepting one of them delayed till Ack > > is sent by > > the originator of the request. > > > > I dont think this is a valid reason for 3-way handshakes. By definition, > all 200 OKs are proxied back. Its upto the caller UA > to then send BYE/OK to callees that it does not want to talk to due to > forking. Therefore, the ACK is sent to all of them and doesnt > help in delaying the decision. [ABN] what could be the logic which the application might use to reject the responses, I mean which one out of 'n' 200-OK response for INVITE will be accepted and rest all will be rejected. The application only intended to contact the calle, but it does not have any information about the callee information (which one to select). will this be driven by a local policy ???? Regards, -Nataraju A.B. > > regds > arjun > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Jun 2 01:40:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12665 for ; Mon, 2 Jun 2003 01:40:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h525eSG30866 for sip-archive@odin.ietf.org; Mon, 2 Jun 2003 01:40:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h525bpB30690; Mon, 2 Jun 2003 01:37:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h525XkB29680 for ; Mon, 2 Jun 2003 01:33:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12588 for ; Mon, 2 Jun 2003 01:33:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MhvJ-0007RH-00 for sip@ietf.org; Mon, 02 Jun 2003 01:31:57 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19MhvI-0007RE-00 for sip@ietf.org; Mon, 02 Jun 2003 01:31:56 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h525XZ0J029661; Mon, 2 Jun 2003 07:33:35 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 2 Jun 2003 07:34:27 +0200 Message-ID: From: "Christer Holmberg (LMF)" To: "'Jonathan Rosenberg'" Cc: Sanjay Sinha , sip@ietf.org Subject: RE: [Sip] Question on RFC 3263 Date: Mon, 2 Jun 2003 07:33:27 +0200 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: , Hi Jonathan, >>>but in any case, the UAS shouldnt terminate the call just because >>>the 18x never got a PRACK. >> >>What if the UAS includes an SDP in the reliable 18x? Shall it >>assume that the UAC will terminate the call if it doesn't receive >>an SDP when it expect to do so? > >Why would the UAC expect an SDP? Eg if the INVITE did not contain SDP. Also, assume we have a pre-condition scenario, where multiple offer/answer transactions are needed before the called party is even alerted. The pre-condition setup will be "halted" if SDPs aren't received. Now, I don't know if pre-condition setups really require SDPs to be sent in specific messages, but at least the nodes expect to receive SDPs, so then the question is how long they shall "wait" for them before taking actions (ie releasing the setup). >In any case, as I said genreally a call is not terminated because a 18x never gets a prack. I didn't see the word "generally" :) Anyway, I think (and I guess that's what you meant too) nodes have make that decission case-by-case. After all, the major reason PRACK is used in the first place is to make sure that 18x provisional responses really DO reach the UAC. If one didn't "care", or if the information (SDP, encapslulated ISUP... whatever) carried in the 18x response had no meaning for the session, why use PRACK in the first place? Regards, Christer Holmberg Ericsson Finland > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Scientist Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 2 03:59:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27087 for ; Mon, 2 Jun 2003 03:59:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h527wuU20060 for sip-archive@odin.ietf.org; Mon, 2 Jun 2003 03:58:56 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h527uPB19943; Mon, 2 Jun 2003 03:56:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RDjoB20341 for ; Tue, 27 May 2003 09:45:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11460; Tue, 27 May 2003 09:45:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KekO-0004Kj-00; Tue, 27 May 2003 09:44:12 -0400 Received: from tssg.wit.ie ([193.1.185.11] helo=mail.tssg.org) by ietf-mx with esmtp (Exim 4.12) id 19KekK-0004KW-00; Tue, 27 May 2003 09:44:08 -0400 Received: from boolard (unknown [10.37.1.56]) by mail.tssg.org (Postfix) with SMTP id 689801809A; Tue, 27 May 2003 14:46:26 +0100 (IST) From: "Shane McCormack" To: , Date: Tue, 27 May 2003 14:50:08 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Subject: [Sip] Number of registered UAs Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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, Is it possible to calculate how many UA's a particular user in the network has either through registration details or otherwise? Regards Shane Shane McCormack Research Assistant, TSSG, Confederation House, Waterford Business Park, Cork Road, Waterford, Co. Waterford. Phone: +353 51 302927 Fax: +353 51 302901 Mobile: +353 87 9955505 http://www.tssg.org MSN: mccormackshane@hotmail.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 2 04:03:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27176 for ; Mon, 2 Jun 2003 04:03:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5283UW20659 for sip-archive@odin.ietf.org; Mon, 2 Jun 2003 04:03:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5280iB20210; Mon, 2 Jun 2003 04:00:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RFoeB30129 for ; Tue, 27 May 2003 11:50:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17755; Tue, 27 May 2003 11:50:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KghE-0005eA-00; Tue, 27 May 2003 11:49:04 -0400 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by ietf-mx with esmtp (Exim 4.12) id 19KghD-0005dv-00; Tue, 27 May 2003 11:49:03 -0400 Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0HFJ0084JYNJX4@firewall.wcom.com>; Tue, 27 May 2003 15:50:07 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HFJ00701YJRL5@dgismtp04.wcomnet.com>; Tue, 27 May 2003 15:50:07 +0000 (GMT) Received: from hsinnreich2 ([166.35.136.36]) by dgismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HFJ005P7YMQYU@dgismtp04.wcomnet.com>; Tue, 27 May 2003 15:49:43 +0000 (GMT) Date: Tue, 27 May 2003 10:49:39 -0500 From: Henry Sinnreich Subject: RE: [Sip] RE: [Sipping] RE: SIP mobility in WLAN In-reply-to: To: "'Prabhas Ranjan Sinha'" , "'Henry Sinnreich'" Cc: "'Santharam, Arun [NTWK SVCS]'" , "'Rajarshi Chakraborty'" , drage@lucent.com, ashishn@mahindrabt.com, sip@ietf.org, sipping@ietf.org Message-id: <000301c32467$97b24520$248823a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 check www.research.telcordia.com/sip-mobile and http://www.cs.columbia.edu/~hgs/papers/Schu0007_Application.pdf Thanks, Henry > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Prabhas Ranjan Sinha > Sent: Tuesday, May 27, 2003 6:00 AM > To: Henry Sinnreich > Cc: 'Santharam, Arun [NTWK SVCS]'; 'Rajarshi Chakraborty'; > drage@lucent.com; ashishn@mahindrabt.com; sip@ietf.org; > sipping@ietf.org > Subject: Re: [Sip] RE: [Sipping] RE: SIP mobility in WLAN > > > > > > > The other alternative is to have application layer mobility > for SIP as > > published in several papers at Columbia University and Telcordia. I > > don't believe you need mobile IP for all scenarios or that > is the best > > option under all circumstances. > > > > The last word on this may not be over yet. > > > > Henry > > Henry, > Could you please elaborate on it more w.r.t pros and cons or > refer me to to any publication which can talk about it ? I > have read that people forsee that Mobile IP could be the most > suitable mechanism for mobility across multiple subnets of > WLAN network. > > Prabhas > > > > > > > > > > > -----Original Message----- > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On > > > Behalf Of Santharam, Arun [NTWK SVCS] > > > Sent: Monday, May 19, 2003 1:35 PM > > > To: Rajarshi Chakraborty; drage@lucent.com; > ashishn@mahindrabt.com; > > > sip@ietf.org > > > Cc: sipping@ietf.org > > > Subject: [Sipping] RE: SIP mobility in WLAN > > > > > > > > > > > > If we follow the SIP implementation on Mobile IP then the > SIP stack > > > should not have to bother about the mobility aspect. The > SIP stack > > > should be notified of IP changes/handoff information (if relevant > > > for the SIP stack) by the underlying stack. This may prompt a SIP > > > registration and subsequent call flows. > > > > > > My 2 cents ... > > > arun > > > > > > > > > > -----Original Message----- > > > > From: Rajarshi Chakraborty > > > > [mailto:rajarshi_chakraborty@hotmail.com] > > > > Sent: Sunday, May 18, 2003 11:42 PM > > > > To: drage@lucent.com; ashishn@mahindrabt.com; Santharam, Arun > > > > [NTWK SVCS]; sip@ietf.org > > > > Cc: sipping@ietf.org > > > > Subject: SIP mobility in WLAN > > > > > > > > > > > > Hi, > > > > > > > > Where can I get call-flows for SIP session management in a > > > > wireless LAN (802.11)? 3GPP only addresses the issues > for cellular > > > > networks. Or are they > > > > too trivial to be addressed specially? I am specially > interested in > > > > situations of handoffs (in this case, the IP changes as soon > > > > as the host > > > > shifts from the zone around one hotspot to another). Should > > > > SIP bother at > > > > all to detect IP changes or should the control be completely > > > > outside SIP? I > > > > mean should it be some other module that has the > > > > responsibility of informing > > > > the SIP stack in the mobile host about the IP changes, so > > > > that the host may > > > > then send a re-INVITE with a new SDP but the call still > > > > remains active? > > > > > > > > regards > > > > Rajarshi > > > > > > > > > > > > Rajarshi Chakraborty > > > > B-196, IIT Campus, > > > > Kharagpur, > > > > West Bengal, India > > > > PIN-721302 > > > > > > > > > > > > > > > > > > > > > > > > ----Original Message Follows---- > > > > From: "Drage, Keith (Keith)" > > > > To: "'Ashish Naik'" , "Santharam, > > > > Arun [CC]" > > > > , "Sip@Ietf. Org" > > > > Subject: RE: [Sip] Session Mobility in SIP > > > > Date: Thu, 8 May 2003 14:42:24 +0100 > > > > > > > > Your best starting point to see the architecture is 3GPP TS > > > > 23.228, with reference to 3GPP TS 23.002 to see how > these entities > > > > fit together into the > > > > entire 3GPP architecture. > > > > > > > > The SIP protocol application is covered in 3GPP TS 24.229 with > > > > example flows in 3GPP TS 24.228. > > > > > > > > These documents may be found at: > > > > > > > > ftp://ftp.3gpp.org/Specs/latest/Rel-5/ > > > > > > > > > > > > 3GPP uses these specifications over GPRS to provide mobility. > > > > > > > > There is a parallel set of 3GPP2 specifications, > substantially of > > > > common text, that uses the same architecture over mobile IP, > > > > instead of GPRS. These > > > > documents are currently in 3GPP2 comment and review. > > > > > > > > regards > > > > > > > > Keith > > > > > > > > > > > > > > > > > > > > Keith Drage > > > > Lucent Technologies > > > > Tel: +44 1793 776249 > > > > Email: drage@lucent.com > > > > > > > > -----Original Message----- > > > > From: Ashish Naik [mailto:ashishn@mahindrabt.com] > > > > Sent: 08 May 2003 06:23 > > > > To: Santharam, Arun [CC]; Sip@Ietf. Org > > > > Subject: RE: [Sip] Session Mobility in SIP > > > > > > > > > > > > ok. Is there any specific document on IETF and 3GPP that can > > > > explain how it is being addressed ? > > > > > > > > > > > > Ragards, > > > > Ashish Naik > > > > CoE Mobile Computing > > > > ----------------------------------- > > > > Phone 4018100 Ext 3070 > > > > > > > > > > > > -----Original Message----- > > > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On > Behalf Of > > > > Santharam, Arun [CC] > > > > Sent: Wednesday, April 09, 2003 9:42 PM > > > > To: Ashish Naik; Sip@Ietf. Org > > > > Subject: RE: [Sip] Session Mobility in SIP > > > > > > > > > > > > > > > > Ashish, > > > > > > > > > > > > > > > > Please find comments inline. > > > > > > > > > > > > > > > > Thank you > > > > > > > > arun > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Ashish Naik [mailto:ashishn@mahindrabt.com] > > > > Sent: Wednesday, April 09, 2003 4:01 AM > > > > To: Sip@Ietf. Org > > > > Subject: [Sip] Session Mobility in SIP > > > > > > > > > > > > > > > > How is SIP going to address session mobility ? Is there any > > > > initiative taken up for this ? > > > > > > > > > > > > > > > > > This has been addressed in 3GPP standards. Please > refer to the > > > > 3GPP All IP architecture specifications. > > > > > > > > > > > > > > > > SIP is said to be a better alternative than Mobile IP. > Can I have > > > > some latest development document references ? > > > > > > > > > > > > > > > > > > > > > > > > > SIP is not going to replace Mobile IP. It is going > to leverage > > > > Mobile IP for session management in 3G wireless networks. > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > Ashish Naik > > > > ------------------- > > > > CoE Mobile Computing > > > > Phone: 4018100 Ext 3070 > > > > > > > > > > > > > > > > > > > > ********************************************************* > > > > Disclaimer > > > > > > > > This message (including any attachments) contains confidential > > > > information intended for a specific individual and > purpose, and is > > > > protected by law. If you are not the intended recipient, you > > > > should delete this message and are hereby notified that any > > > > disclosure, copying, or distribution of this message, or the > > > > taking of any action based on it, is strictly prohibited. > > > > > > > > ********************************************************* > > > > Visit us at http://www.mahindrabt.com > > > > > > > > > > > > > > > > > > > > ********************************************************* > > > > Disclaimer > > > > > > > > This message (including any attachments) contains confidential > > > > information intended for a specific individual and > purpose, and is > > > > protected by law. If you are not the intended recipient, you > > > > should delete this message and are hereby notified that any > > > > disclosure, copying, or distribution of this message, or the > > > > taking of any action based on it, is strictly prohibited. > > > > > > > > ********************************************************* > > > > Visit us at http://www.mahindrabt.com > > > > > > > > > _________________________________________________________________ > > > > Mobile, masti, magic! Cool ringtones & logos. > > > > http://www.msn.co.in/mobile/ Get noticed > > > > > > > > > > > _______________________________________________ > > > Sipping mailing list > https://www1.ietf.org/mailman/listi> nfo/sipping > > > This list > is for NEW development of the > application of SIP Use > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > sip@ietf.org for new developments of core SIP > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on > current sip Use > > sipping@ietf.org for new developments on the application of sip > > > > Prabhas > +++++++++++++ > CSEL Technology Enterprise Programme > London Business School > Baker Street, London NW1 6DD > ***************************************** > There is no wisdom greater than kindness. > ***************************************** > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 2 11:29:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12006 for ; Mon, 2 Jun 2003 11:29:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h52FTEX24555 for sip-archive@odin.ietf.org; Mon, 2 Jun 2003 11:29:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52FQaB24363; Mon, 2 Jun 2003 11:26:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52FKsB24084 for ; Mon, 2 Jun 2003 11:20:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11754 for ; Mon, 2 Jun 2003 11:20:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Mr5X-0003wz-00 for sip@ietf.org; Mon, 02 Jun 2003 11:19:07 -0400 Received: from broadsoft.com ([198.104.184.110]) by ietf-mx with esmtp (Exim 4.12) id 19Mr5X-0003wv-00 for sip@ietf.org; Mon, 02 Jun 2003 11:19:07 -0400 Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.12.9) id h52FKqYq089731; Mon, 2 Jun 2003 11:20:52 -0400 (EDT) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] Question on RFC 3263 Date: Mon, 2 Jun 2003 11:25:28 -0400 Message-ID: <000001c3291b$33007670$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: <3ED844A8.5040802@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 > >> Actually, before that even happens the client > >> transaction will simply terminate at the UAC. See: > >> > >> > http://www.ietf.org/internet-drafts/draft-sparks-sip-noninvite-00.txt > >> > >> > >> but in any case, the UAS shouldnt terminate the > >> call just because the 18x never got a PRACK. > > > > > > What if the UAS includes an SDP in the reliable 18x? > > Shall it assume that the UAC will terminate the call > > if it doesn't receive an SDP when it expect to do so? > > Why would the UAC expect an SDP? The following is from RFC 3262 section 5: "If the UAC receives a reliable provisional response with an offer (this would occur if the UAC sent an INVITE without an offer, in which case the first reliable provisional response will contain the offer), it MUST generate an answer in the PRACK. If the UAC receives a reliable provisional response with an answer, it MAY generate an additional offer in the PRACK. If the UAS receives a PRACK with an offer, it MUST place the answer in the 2xx to the PRACK." > In any case, as I said genreally a call is not > terminated because a 18x never gets a prack. The following is from RFC 3262 section 3: "If a reliable provisional response is retransmitted for 64*T1 seconds without reception of a corresponding PRACK, the UAS SHOULD reject the original request with a 5xx response." _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 2 12:55:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15005 for ; Mon, 2 Jun 2003 12:55:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h52GtGv32433 for sip-archive@odin.ietf.org; Mon, 2 Jun 2003 12:55:16 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52GqdB32265; Mon, 2 Jun 2003 12:52:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52GkjB32039 for ; Mon, 2 Jun 2003 12:46:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14726 for ; Mon, 2 Jun 2003 12:46:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MsQa-0004eT-00 for sip@ietf.org; Mon, 02 Jun 2003 12:44:56 -0400 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19MsQY-0004eH-00 for sip@ietf.org; Mon, 02 Jun 2003 12:44:55 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by auemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h52Gk5g22986 for ; Mon, 2 Jun 2003 11:46:06 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Jun 2003 17:46:04 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB008AC8F3B@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Dean Willis'" , "'Prabhas Ranjan Sinha'" , "'sip@ietf.org'" Subject: RE: [Sip] WLAN & SIP Date: Mon, 2 Jun 2003 17:46:02 +0100 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: , To clarify what 3GPP is currently doing. 1) 3GPP is looking at the integration of Wireless LAN and 3GPP systems. These do not change the wireless LAN specifications, or give indications on how thet are put together. That work is divided into a number of scenarios, each of which has a different degree of integration. They are more fully described in ftp://ftp.3gpp.org/Specs/latest/Rel-6/22_series/22934-610.zip Scenario 1 requires no specification work, and otherwise only scenario 2 and 3 will be supported at release 6. 2) 3GPP is taking its existing IM CN subsystem specifications, which include its SIP documents, and making some of them more access independent in release 6. This means principally changing terminology rather than technical requirements. There will need to be some extensions for the 3GPP defined bits of some P-headers to cover other access mechanisms. In conclusion 3GPP is not really defining SIP over wireless LAN, rather assuming that it will work, and if it is used, it can be used to access the IM CN subsystem of 3GPP. regards Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 27 May 2003 17:09 > To: 'Prabhas Ranjan Sinha'; sip@ietf.org > Subject: RE: [Sip] WLAN & SIP > > > > Prabhas asked: > > > > Is there any draft on SIP usage in WLAN arena ? > > Any help would be appreciated. > > > > I suppose "Just use it -- we don't really care whether the IP > traffic is > over WLAN, ethernet, frame relay, barbed wired, or avian > carrier" isn't the > answer you're looking for. But really, the IETF (outside of > task specific > areas like the Performance Implications of Link Characteistics working > group) isn't generally concerned with specific lower-layer aspects. > > The short answer is that SIP works just fine over 802.11b > (I'm using it that > way right now) and should work over "a" and "g" just fine too. > > 3GPP (www.3gpp.org) is doing some work on extending IMS > Release 6 (Internet > Multimedia Subsystem) which uses SIP onto WLAN. However, I'm not yet > completely certain that what they mean by WLAN and what you > mean by WLAN are > the same thing -- they seem to be mostly worred about the > sort of WLAN that > would be installed by mobile operators in hotspots and tied > to one's mobile > phone account. Consequently, they're interested in things > like using the > mobile's SIM card for authentication over WLAN, differential > access pricing > by service, Q0S interworking with UMTS, and all of the usual > 3G-mobile-phone > type things. > > -- > 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 4 08:12:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13736 for ; Wed, 4 Jun 2003 08:12:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54CCUS09853 for sip-archive@odin.ietf.org; Wed, 4 Jun 2003 08:12:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54C7oB09682; Wed, 4 Jun 2003 08:07:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54BwMB08163 for ; Wed, 4 Jun 2003 07:58:22 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13111; Wed, 4 Jun 2003 07:58:20 -0400 (EDT) Message-Id: <200306041158.HAA13111@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, 04 Jun 2003 07:58:20 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-content-indirect-mech-03.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages Author(s) : S. Olson Filename : draft-ietf-sip-content-indirect-mech-03.txt Pages : 19 Date : 2003-6-3 This document 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-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-content-indirect-mech-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-content-indirect-mech-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-3151602.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-content-indirect-mech-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-content-indirect-mech-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-3151602.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Thu Jun 5 00:50:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25394 for ; Thu, 5 Jun 2003 00:50:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h554oCD18942 for sip-archive@odin.ietf.org; Thu, 5 Jun 2003 00:50:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h554k1B18822; Thu, 5 Jun 2003 00:46:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h554hRB18747 for ; Thu, 5 Jun 2003 00:43:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25333; Thu, 5 Jun 2003 00:43:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NmZB-0002st-00; Thu, 05 Jun 2003 00:41:33 -0400 Received: from law12-f89.law12.hotmail.com ([64.4.19.89] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19NmZA-0002se-00; Thu, 05 Jun 2003 00:41:33 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 4 Jun 2003 21:42:53 -0700 Received: from 193.220.224.9 by lw12fd.law12.hotmail.msn.com with HTTP; Thu, 05 Jun 2003 04:42:53 GMT X-Originating-IP: [193.220.224.9] X-Originating-Email: [rajarshi_chakraborty@hotmail.com] From: "Rajarshi Chakraborty" To: sip@ietf.org, sipping@ietf.org Date: Thu, 05 Jun 2003 04:42:53 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 05 Jun 2003 04:42:53.0590 (UTC) FILETIME=[ED3ECB60:01C32B1C] Subject: [Sip] reference to papers on SIP mobility Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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, Would any sort of discussion on mobility using SIP, in reference to external papers, be appreciated in the SIP or SIPPING group? By external, I mean papers which are not simply IETF drafts n RFCs, but those maintained in sites like Telcordia, universities, etc. regards Rajarshi Rajarshi Chakraborty B-196, IIT Campus, Kharagpur, West Bengal, India PIN-721302 _________________________________________________________________ Staying fit. It's about being happy! http://server1.msn.co.in/features/stayingfit/index.asp Check out the new mantra. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 5 03:10:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09407 for ; Thu, 5 Jun 2003 03:10:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h557AW207297 for sip-archive@odin.ietf.org; Thu, 5 Jun 2003 03:10:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5576UB06270; Thu, 5 Jun 2003 03:06:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5574sB06169 for ; Thu, 5 Jun 2003 03:04:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09274 for ; Thu, 5 Jun 2003 03:04:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nom1-0003gZ-00 for sip@ietf.org; Thu, 05 Jun 2003 03:02:57 -0400 Received: from [212.143.185.10] (helo=nt-mail.radvision.com) by ietf-mx with esmtp (Exim 4.12) id 19Nom0-0003gW-00 for sip@ietf.org; Thu, 05 Jun 2003 03:02:56 -0400 Received: from nt-mail.radvision.com [172.20.2.100] by nt-mail.radvision.com with XWall v3.26 ; Thu, 5 Jun 2003 10:01:56 +0300 Received: by nt-mail.radvision.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Jun 2003 10:01:56 +0300 Message-ID: From: Udi Weintrob To: sip@ietf.org Date: Thu, 5 Jun 2003 10:01:53 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Subject: [Sip] Question on rfc3263 - locating sip servers Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 have a question regarding RFC3263. from the RFC (4): Because the ACK request for 2xx responses to INVITE constitutes a different transaction, there is no requirement that it be delivered to the same server that received the original request (indeed, if that server did not record-route, it will not get the ACK). Does that mean that for ACK on 2xx responses, I need to re-query the DNS server (assuming a non IP uri)? Do I need to query the DNS even if the URI of the ACK is the same as the URI of the initial INVITE request? thanks, Udi J. Tirosh. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 5 03:57:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10578 for ; Thu, 5 Jun 2003 03:57:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h557vDn10190 for sip-archive@odin.ietf.org; Thu, 5 Jun 2003 03:57:13 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h557r0B10010; Thu, 5 Jun 2003 03:53:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h557mLB09809 for ; Thu, 5 Jun 2003 03:48:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10362 for ; Thu, 5 Jun 2003 03:48:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NpS8-0003yi-00 for sip@ietf.org; Thu, 05 Jun 2003 03:46:28 -0400 Received: from [61.144.161.2] (helo=mta0.huawei.com) by ietf-mx with esmtp (Exim 4.12) id 19NpS4-0003yT-00 for sip@ietf.org; Thu, 05 Jun 2003 03:46:25 -0400 Received: from Natarajucl1127 (mta0.huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HG00069T05YR1@mta0.huawei.com> for sip@ietf.org; Thu, 05 Jun 2003 15:44:26 +0800 (CST) Date: Thu, 05 Jun 2003 13:15:49 +0530 From: "Nataraju A.B." Subject: Re: [Sip] Question on rfc3263 - locating sip servers To: Udi Weintrob , sip@ietf.org Message-id: <00c201c32b36$7c212080$3802120a@in.huawei.com> Organization: HTIPL MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: multipart/alternative; boundary="Boundary_(ID_OjabOKKSbUfzU6NZ3atOdQ)" X-Priority: 3 X-MSMail-priority: Normal References: Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_OjabOKKSbUfzU6NZ3atOdQ) Content-type: text/plain; charset=windows-1255 Content-Transfer-Encoding: 7BIT The basic requirement for ACK for 2xx of INVOTE is to make sure the UAS that 2xx been received by UAC. Also ACK may not pass through the same route which the INVITE passed through to UAS. UAC while sending the ACK request will use the route header in the 2xx(INVITE) response and the Req-URI will be set with teh contact address in teh 2xx response. more comments inline.. Regards, -Nataraju A.B. May you live as long as you wish and love as long as you live. --Robert A. Heinlein Time Enough for Love. ----- Original Message ----- From: Udi Weintrob To: sip@ietf.org Sent: Thursday, June 05, 2003 12:31 PM Subject: [Sip] Question on rfc3263 - locating sip servers Hi, I have a question regarding RFC3263. from the RFC (4): Because the ACK request for 2xx responses to INVITE constitutes a different transaction, there is no requirement that it be delivered to the same server that received the original request (indeed, if that server did not record-route, it will not get the ACK). Does that mean that for ACK on 2xx responses, I need to re-query the DNS server (assuming a non IP uri)? Do I need to query the DNS even if the URI of the ACK is the same as the URI of the initial INVITE request? [Nataraju A.B.] U may need to query the DNS server if u have not cached the domain name and FQDN mapping. [Nataraju A.B.] In the first place There is no point in sending ACK to some one else also. thanks, Udi J. Tirosh. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --Boundary_(ID_OjabOKKSbUfzU6NZ3atOdQ) Content-type: text/html; charset=windows-1255 Content-Transfer-Encoding: 7BIT
The basic requirement for ACK for 2xx of INVOTE is to make sure the UAS that 2xx been received by UAC.
 
Also ACK may not pass through the same route which the INVITE passed through to UAS.
 
UAC while sending the ACK request will use the route header in the 2xx(INVITE) response and the Req-URI will be set with teh contact address in teh 2xx response.
 
more comments inline..
 
Regards,
-Nataraju A.B.
May you live as long as you wish and love as long as you live.
--Robert A. Heinlein Time Enough for Love.
 
----- Original Message -----
Sent: Thursday, June 05, 2003 12:31 PM
Subject: [Sip] Question on rfc3263 - locating sip servers

Hi,
I have a question regarding RFC3263.

from the RFC (4):
Because the ACK request for 2xx responses to INVITE constitutes a
different transaction, there is no requirement that it be delivered
to the same server that received the original request (indeed, if
that server did not record-route, it will not get the ACK).

Does that mean that for ACK on 2xx responses, I need to re-query the DNS
server (assuming a non IP uri)?
Do I need to query the DNS even if the URI of the ACK is the same as the URI
of the initial INVITE request?
 
[Nataraju A.B.]
U may need to query the DNS server if u have not cached the domain name and FQDN mapping.
 
[Nataraju A.B.]
In the first place There is no point in sending ACK to some one else also.

thanks,
Udi J. Tirosh.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--Boundary_(ID_OjabOKKSbUfzU6NZ3atOdQ)-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 5 05:52:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12971 for ; Thu, 5 Jun 2003 05:52:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h559pbN18879 for sip-archive@odin.ietf.org; Thu, 5 Jun 2003 05:51:37 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h559lRB18746; Thu, 5 Jun 2003 05:47:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52I4uB05833 for ; Mon, 2 Jun 2003 14:04:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17464 for ; Mon, 2 Jun 2003 14:04:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MteD-0005DK-00 for sip@ietf.org; Mon, 02 Jun 2003 14:03:05 -0400 Received: from [200.36.33.2] (helo=mail.kbtel.com) by ietf-mx with esmtp (Exim 4.12) id 19MteC-0005DH-00 for sip@ietf.org; Mon, 02 Jun 2003 14:03:04 -0400 Received: from aislas ([10.10.4.170]) by mail.kbtel.com ([200.36.33.2]) with SMTP (MDaemon.PRO.v6.7.5.R) for ; Mon, 02 Jun 2003 13:00:14 -0500 Message-ID: <001901c32930$ad7b16c0$aa040a0a@cuicuilco.kbtel.com> Reply-To: "Alejandro Islas" From: "Alejandro Islas" To: Date: Mon, 2 Jun 2003 12:59:13 -0500 Organization: Kb/TEL MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C32906.C461EB40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Authenticated-Sender: aislas@mail.kbtel.com X-MDRemoteIP: 10.10.4.170 X-Return-Path: aislas@kbtel.com X-MDaemon-Deliver-To: sip@ietf.org Subject: [Sip] Sip and flash function Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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_0016_01C32906.C461EB40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I=B4m new to SIP so I was wondering is there some official = document (draft or RFC) towards the behaviour of a SIP UA after = receiving a FLASH from the end user??? In other words, how do SIP = interacts with digitally services such as "transfer call" that needs a = FLASH+number undestanding??? Alejandro Islas Kb/TEL=20 MEXICO ------=_NextPart_000_0016_01C32906.C461EB40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all, I=B4m new to SIP so I was = wondering is there=20 some official document (draft or RFC) towards the behaviour of a SIP UA = after=20 receiving a FLASH from the end user??? In other words, how do SIP = interacts with=20 digitally services such as "transfer call" that needs a = FLASH+number=20 undestanding???
 Alejandro Islas
 Kb/TEL =
MEXICO
------=_NextPart_000_0016_01C32906.C461EB40-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 5 11:00:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29452 for ; Thu, 5 Jun 2003 11:00:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55F0Qw11267 for sip-archive@odin.ietf.org; Thu, 5 Jun 2003 11:00:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55Ew3B11028; Thu, 5 Jun 2003 10:58:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55EpNB10571 for ; Thu, 5 Jun 2003 10:51:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29050 for ; Thu, 5 Jun 2003 10:51:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nw3R-0007ZO-00 for sip@ietf.org; Thu, 05 Jun 2003 10:49:25 -0400 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19Nw3Q-0007Z1-00 for sip@ietf.org; Thu, 05 Jun 2003 10:49:24 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h55EocP27746 for ; Thu, 5 Jun 2003 09:50:39 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Jun 2003 15:50:37 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00439ED4B@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Alejandro Islas'" , sip@ietf.org Subject: RE: [Sip] Sip and flash function Date: Thu, 5 Jun 2003 15:50:35 +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 h55EpNB10572 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 FLASH + number is stimulus signalling, i.e. the sending terminal does not understand the service that is being requested. This type of signalling is inappropriate to SIP entities (although potentially could in some limited circumstances be passed transparently through the SIP system to some remote entity, e.g. a voice mail server). You need some entity in the way (before SIP is reached) that interprets that FLASH + number as the call transfer service, or whatever and implements the rest of call transfer in a stimulus fashion back to the non-SIP user, and implements call transfer towards the SIP entities. This is exactly the same function as is performed in the PSTN between the user access and SS7. As this entity is not in SIP, it is out of scope of the SIP/SIPPING groups. You will find example descriptions of a number of services provided by SIP in SIPPING group drafts e.g. http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-transfer-01.txt http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-examples-04.txt http://www.ietf.org/internet-drafts/draft-ietf-sipping-basic-call-flows-02.txt http://www.ietf.org/internet-drafts/draft-ietf-sipping-pstn-call-flows-02.txt http://www.ietf.org/internet-drafts/draft-ietf-mmusic-offer-answer-examples-00.txt Some of these are obviously more relevent to you than others. regards Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com -----Original Message----- From: Alejandro Islas [mailto:aislas@kbtel.com] Sent: 02 June 2003 18:59 To: sip@ietf.org Subject: [Sip] Sip and flash function Hi all, I´m new to SIP so I was wondering is there some official document (draft or RFC) towards the behaviour of a SIP UA after receiving a FLASH from the end user??? In other words, how do SIP interacts with digitally services such as "transfer call" that needs a FLASH+number undestanding??? Alejandro Islas Kb/TEL MEXICO _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 5 15:13:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12438 for ; Thu, 5 Jun 2003 15:13:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55JDRD00671 for sip-archive@odin.ietf.org; Thu, 5 Jun 2003 15:13:27 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55JArB00420; Thu, 5 Jun 2003 15:10:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55J05B31442 for ; Thu, 5 Jun 2003 15:00:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10941 for ; Thu, 5 Jun 2003 14:59:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nzw7-0002F4-00 for sip@ietf.org; Thu, 05 Jun 2003 14:58:07 -0400 Received: from defender.ccpu.com ([216.54.134.34] helo=smtp.ccpu.com) by ietf-mx with esmtp (Exim 4.12) id 19Nzw6-0002F0-00 for sip@ietf.org; Thu, 05 Jun 2003 14:58:06 -0400 Received: from [172.16.1.199] (helo=CCPU00174) by smtp.ccpu.com with smtp (Exim 4.20 #1 (Debian)) id 19Nzxk-0005fJ-5U; Thu, 05 Jun 2003 11:59:48 -0700 From: "Bang Du" To: "Udi Weintrob" , Subject: RE: [Sip] Question on rfc3263 - locating sip servers Date: Thu, 5 Jun 2003 12:02:01 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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 Hi Udi, In either case, you need to do the dns query. Regards, Bang -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Udi Weintrob Sent: Thursday, June 05, 2003 12:02 AM To: sip@ietf.org Subject: [Sip] Question on rfc3263 - locating sip servers Hi, I have a question regarding RFC3263. from the RFC (4): Because the ACK request for 2xx responses to INVITE constitutes a different transaction, there is no requirement that it be delivered to the same server that received the original request (indeed, if that server did not record-route, it will not get the ACK). Does that mean that for ACK on 2xx responses, I need to re-query the DNS server (assuming a non IP uri)? Do I need to query the DNS even if the URI of the ACK is the same as the URI of the initial INVITE request? thanks, Udi J. Tirosh. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Jun 5 16:35:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16018 for ; Thu, 5 Jun 2003 16:35:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55KZCN07059 for sip-archive@odin.ietf.org; Thu, 5 Jun 2003 16:35:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55KWLB06923; Thu, 5 Jun 2003 16:32:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55KSiB06614 for ; Thu, 5 Jun 2003 16:28:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15776 for ; Thu, 5 Jun 2003 16:28:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19O1Jx-0003DB-00 for sip@ietf.org; Thu, 05 Jun 2003 16:26:49 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19O1Jx-0003D1-00 for sip@ietf.org; Thu, 05 Jun 2003 16:26:49 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h55KS7we000790; Thu, 5 Jun 2003 13:28:10 -0700 (PDT) Received: from bhadoria-lnx.cisco.com (bhadoria-lnx.cisco.com [128.107.140.160]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIA96391; Thu, 5 Jun 2003 13:28:07 -0700 (PDT) Date: Thu, 5 Jun 2003 13:28:07 -0700 (PDT) From: Amit Bhadoria To: Udi Weintrob cc: sip@ietf.org Subject: Re: [Sip] Question on rfc3263 - locating sip servers In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , udi, its not a MUST to do a DNS querry for subsequent messages, you could cache the results from last successfull querry and use it. however, in case of failover, or to handle some non-trivial case, you may have to do DNS querry again -- and thats exactly what these guidelines are for, to give a standard/open procedure. as a side note, the Record-route inserted by each intermediate hop gives a little hint on how it wants to be resolved for subsequent messages. for example, it may choose to insert its domain only, in which case you may have to do NAPTR/SRV querries. regards, -amit. -- Amit Bhadoria Software Engineer http://www.cisco.com On Thu, 5 Jun 2003, Udi Weintrob wrote: > Hi, > I have a question regarding RFC3263. > > from the RFC (4): > Because the ACK request for 2xx responses to INVITE constitutes a > different transaction, there is no requirement that it be delivered > to the same server that received the original request (indeed, if > that server did not record-route, it will not get the ACK). > > Does that mean that for ACK on 2xx responses, I need to re-query the DNS > server (assuming a non IP uri)? > Do I need to query the DNS even if the URI of the ACK is the same as the URI > of the initial INVITE request? > > thanks, > Udi J. Tirosh. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Jun 6 20:34:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19537 for ; Fri, 6 Jun 2003 20:34:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h570Y1L11673 for sip-archive@odin.ietf.org; Fri, 6 Jun 2003 20:34:01 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h570VOB11592; Fri, 6 Jun 2003 20:31:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h570SNB11381 for ; Fri, 6 Jun 2003 20:28:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19432 for ; Fri, 6 Jun 2003 20:28:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ORXN-00004j-00 for sip@ietf.org; Fri, 06 Jun 2003 20:26:25 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19ORXM-00004Z-00 for sip@ietf.org; Fri, 06 Jun 2003 20:26:24 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h570RfCL007412; Fri, 6 Jun 2003 17:27:42 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHW68947; Fri, 6 Jun 2003 17:23:27 -0700 (PDT) Date: Fri, 6 Jun 2003 17:28:34 -0700 Subject: Re: [Sip] UPDATE and P-Asserted-ID Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'Michael Thomas'" , Jonathan Rosenberg , "Elwell, John" , "'Drage, Keith (Keith)'" , "'sip@ietf.org'" To: "Mark Watson" From: Rohan Mahy In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h570SOB11382 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 Friday, May 23, 2003, at 03:21 AM, Mark Watson wrote: > Jonathan's approach seems reasonable, and since P-Asserted-Id just > represents the identity of the originator of the *message* i think you are correct, that the spec means the originator of the message, but I do not this is especially clear. i was not sure about this. i thought it was just the initiator of the dialog. After reading through RFC 3325 three times, the only thing that strongly indicated this was the case was the list of which methods could contain the header. It is unfortunate that UPDATE was not included, since this is one of the places using P-Asserted-Id makes the most sense. thanks, -rohan > we could expect it to change during a dialog - I suppose there is a > philosphical question that if the identity of the SIP UAS changes, > does that mean it is now a logically different UAS and so a new dialog > should be established ? even if it's the same physical device so that > all the state needed to maintain a single dialog is still available ?? > I guess this is the case when call forward/transfer happens downstream > of a SIP->X gateway. > > Equally, were a device to de-register and re-register with a new > Address Of Record, does this represent an 'identity change' for that > UA ? Could it meaningfully update its identity in any ongoing dialogs > > ? > > I think there should be scope for individual headers to specify that > their state cannot be updated mid-dialog. Not having looked through > all the 'such headers' referred to by Jonathan (not even knowing what > this list is!) we can't rule out that the meaning of a mid-dialog > update for one of these might not be well-defined i.e. it has no > sensible meaning or is ambiguous. In those cases we would need to rule > out mid-dialog updates, or define the meaning of them for that header. > > ...Mark > > > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: 19 May 2003 21:18 > > To: Jonathan Rosenberg > > Cc: Elwell, John; 'Rohan Mahy'; 'Drage, Keith (Keith)'; > 'sip@ietf.org' > > Subject: Re: [Sip] UPDATE and P-Asserted-ID > > > > > > Jonathan Rosenberg writes: > >  > 1. Each header field that conveys dialog-associated state would > >  > indicate whether or not that state is updated by a target > > refresh request. > >  > > >  > 2. We specify a blanket rule for all such headers that > > their state is > >  > updated by a target refresh request (absence of a header > > would imply > >  > no update). > >  > > >  > 3. We specify a blanket rule for all such headers that > > their state is > >  > never updated by a target refresh request. > >  > > >  > 4. We specify a default rule for all such headers, but allow > >  > individual headers to override it. > >  > > >  > > >  > In the interests of simplicity I would tend to lean > > towards (2). The > >  > best place for this, of course, is rfc 3261, in which case > > we should > >  > treat this as a bug against the spec. > > > > This seems quite reasonable to me as well -- > > special casing "initial" from subsequent dialog > > seems pretty fraught. The only reason that I can > > think of why you might want to do that is when the > > state assembly/teardown of a mid-session change > > was so onerous and/or ambiguous to other state > > that it was prudent to set up the state once and > > leave it be. It doesn't seem to me that that's the > > case here, but I'm hardly an expert. > > > >        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 > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 7 03:53:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08299 for ; Sat, 7 Jun 2003 03:53:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h577qmE15382 for sip-archive@odin.ietf.org; Sat, 7 Jun 2003 03:52:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h577oHB15326; Sat, 7 Jun 2003 03:50:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h577llB15251 for ; Sat, 7 Jun 2003 03:47:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08113 for ; Sat, 7 Jun 2003 03:47:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OYOb-0002DY-00 for sip@ietf.org; Sat, 07 Jun 2003 03:45:49 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19OYOa-0002DO-00 for sip@ietf.org; Sat, 07 Jun 2003 03:45:48 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h577mIbj022848; Sat, 7 Jun 2003 09:48:18 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Sat, 7 Jun 2003 09:48:48 +0200 Message-ID: From: "Christer Holmberg (LMF)" To: "'Rohan Mahy'" , Mark Watson Cc: "'Michael Thomas'" , Jonathan Rosenberg , "Elwell, John" , "'Drage, Keith (Keith)'" , "'sip@ietf.org'" Subject: RE: [Sip] UPDATE and P-Asserted-ID Date: Sat, 7 Jun 2003 09:47:23 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h577llB15252 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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, There currently are a number of headers where the sender or a request, and the initiator of a dialog, can insert some kind of identity of themselves. They are: Contact From In-Reply-To Reply-To P-Asserted-Identity etc In most cases the spec(s) do define what they can be used for, but not really what they identify (user, device, etc). Maybe some clarification is needed for that? I also agree that we need to define which headers are allowed to be changed/updated during a session, and what it really means from a dialog point of view. Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: 7. kesäkuuta 2003 3:29 > To: Mark Watson > Cc: 'Michael Thomas'; Jonathan Rosenberg; Elwell, John; 'Drage, Keith > (Keith)'; 'sip@ietf.org' > Subject: Re: [Sip] UPDATE and P-Asserted-ID > > > > On Friday, May 23, 2003, at 03:21 AM, Mark Watson wrote: > > > Jonathan's approach seems reasonable, and since P-Asserted-Id just > > represents the identity of the originator of the *message* > > i think you are correct, that the spec means the originator of the > message, but I do not this is especially clear. i was not sure about > this. i thought it was just the initiator of the dialog. > After reading > through RFC 3325 three times, the only thing that strongly indicated > this was the case was the list of which methods could contain the > header. It is unfortunate that UPDATE was not included, > since this is > one of the places using P-Asserted-Id makes the most sense. > > thanks, > -rohan > > > > we could expect it to change during a dialog - I suppose there is a > > philosphical question that if the identity of the SIP UAS changes, > > does that mean it is now a logically different UAS and so a > new dialog > > should be established ? even if it's the same physical > device so that > > all the state needed to maintain a single dialog is still > available ?? > > I guess this is the case when call forward/transfer happens > downstream > > of a SIP->X gateway. > > > > Equally, were a device to de-register and re-register with a new > > Address Of Record, does this represent an 'identity change' > for that > > UA ? Could it meaningfully update its identity in any > ongoing dialogs > > > ? > > > > I think there should be scope for individual headers to > specify that > > their state cannot be updated mid-dialog. Not having looked through > > all the 'such headers' referred to by Jonathan (not even > knowing what > > this list is!) we can't rule out that the meaning of a mid-dialog > > update for one of these might not be well-defined i.e. it has no > > sensible meaning or is ambiguous. In those cases we would > need to rule > > out mid-dialog updates, or define the meaning of them for > that header. > > > > ...Mark > > > > > > > > > -----Original Message----- > > > From: Michael Thomas [mailto:mat@cisco.com] > > > Sent: 19 May 2003 21:18 > > > To: Jonathan Rosenberg > > > Cc: Elwell, John; 'Rohan Mahy'; 'Drage, Keith (Keith)'; > > 'sip@ietf.org' > > > Subject: Re: [Sip] UPDATE and P-Asserted-ID > > > > > > > > > Jonathan Rosenberg writes: > > >  > 1. Each header field that conveys dialog-associated state would > > >  > indicate whether or not that state is updated by a target > > > refresh request. > > >  > > > >  > 2. We specify a blanket rule for all such headers that > > > their state is > > >  > updated by a target refresh request (absence of a header > > > would imply > > >  > no update). > > >  > > > >  > 3. We specify a blanket rule for all such headers that > > > their state is > > >  > never updated by a target refresh request. > > >  > > > >  > 4. We specify a default rule for all such headers, but allow > > >  > individual headers to override it. > > >  > > > >  > > > >  > In the interests of simplicity I would tend to lean > > > towards (2). The > > >  > best place for this, of course, is rfc 3261, in which case > > > we should > > >  > treat this as a bug against the spec. > > > > > > This seems quite reasonable to me as well -- > > > special casing "initial" from subsequent dialog > > > seems pretty fraught. The only reason that I can > > > think of why you might want to do that is when the > > > state assembly/teardown of a mid-session change > > > was so onerous and/or ambiguous to other state > > > that it was prudent to set up the state once and > > > leave it be. It doesn't seem to me that that's the > > > case here, but I'm hardly an expert. > > > > > >        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 > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Jun 7 23:06:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00013 for ; Sat, 7 Jun 2003 23:06:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5835rX14503 for sip-archive@odin.ietf.org; Sat, 7 Jun 2003 23:05:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5833bB14427; Sat, 7 Jun 2003 23:03:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h582v0B14242 for ; Sat, 7 Jun 2003 22:57:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29812 for ; Sat, 7 Jun 2003 22:56:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OqKe-00007C-00 for sip@ietf.org; Sat, 07 Jun 2003 22:54:56 -0400 Received: from [65.200.90.207] (helo=mailserver.sylantro.com) by ietf-mx with smtp (Exim 4.12) id 19OqKd-000078-00 for sip@ietf.org; Sat, 07 Jun 2003 22:54:55 -0400 Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Sat, 07 Jun 2003 19:56:15 -0700 X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Received: by mailserver.sylantro.com with Internet Mail Service ( 5.5.2653.19) id ; Sat, 7 Jun 2003 19:56:14 -0700 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD023BCA90@mailserver.sylantro.com> From: "Venkatesh Venkataramanan" To: "'sip@ietf.org'" Date: Sat, 7 Jun 2003 19:56:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 12FC7A4513784-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] P-Asserted-Identity and Called Party Name Delivery Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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: There has been some discussion in the mailing list about using the P-Asserted-Identity header in requests like UPDATE to enable updating the identity of the caller mid-call. I was thinking anyone has considered enabling this header in SIP response messages as well? There are a few features that would need updating the calling party, the identity of the target while the called target is still being alerted. While 3261 allows the UAS to use the Contact header, there are a couple scenarios that need something more than the contact, a header a proxy in the middle can update in responses. 1) In the case of calls to numbers like hunt-groups and/or ACD, every UAS that receives the INVITE will place its local contact information in the response to this request. All that may be expected for these calls is that the calling party see information they called a name corresponding to the hunt group or ACD number they called; like "United Airlines" and not "Agent John Doe". Arguably this may be achieved by local configuration of some sort at the UAS that is a part of the ACD group; but there can be call flows where the UAS receiving an INVITE might not even be aware that it is being reached as a part of some application. For example an implementation might choose to store hunt group information in a proxy and have the proxy fork sequentially or round-robin or whatever, and not having the UAS know about it. Another example might be a find me-follow me type service where the calling party may not need to know the list of targets that is being looked up or which of these targets answered the call. 2) A proxy providing called name lookup services for a user community whereby it looks up a centralized directory database of some sort and update the calling UA of the called party's name; this is useful if the called number is a PSTN number. 3) An UAS might not even place it's display name in a SIP response. Enabling a proxy to add this information gurantees a end user of this feature regardless of the capabilities and/or preferences of the UAS. 4) Display language preferences: A end user might have preferences to display called names in English. The UAS called might have preferences that makes it send the called display name in different language. A proxy might want to provide a directory look up service based on the called number and provide the information to the end user in a language preferred by the calling UA. Is it worth considering enabling proxies to insert the P-Asserted-Identity header in SIP response message for the same?? regards, Venkatesh _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 9 05:56:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25624 for ; Mon, 9 Jun 2003 05:56:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h599uJX18026 for sip-archive@odin.ietf.org; Mon, 9 Jun 2003 05:56:19 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h599rGB17879; Mon, 9 Jun 2003 05:53:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h599nUB17782 for ; Mon, 9 Jun 2003 05:49:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25441 for ; Mon, 9 Jun 2003 05:49:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PJFN-00016g-00 for sip@ietf.org; Mon, 09 Jun 2003 05:47:25 -0400 Received: from mailgate.siemenscomms.co.uk ([194.129.217.115]) by ietf-mx with esmtp (Exim 4.12) id 19PJFM-00016c-00 for sip@ietf.org; Mon, 09 Jun 2003 05:47:24 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #45905) id <0HG700M01KKFA8@siemenscomms.co.uk> for sip@ietf.org; Mon, 09 Jun 2003 10:48:15 +0100 (BST) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #45905) with ESMTP id <0HG700M2BKKF8V@siemenscomms.co.uk>; Mon, 09 Jun 2003 10:48:15 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Mon, 09 Jun 2003 10:48:53 +0100 Content-return: allowed Date: Mon, 09 Jun 2003 10:49:16 +0100 From: "Elwell, John" Subject: RE: [Sip] UPDATE and P-Asserted-ID To: "'Rohan Mahy'" , Mark Watson Cc: "'Michael Thomas'" , Jonathan Rosenberg , "'Drage, Keith (Keith)'" , "'sip@ietf.org'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h599nUB17783 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 Section 5 of RFC3325 states: "If the proxy receives a message (request or response) from a node that it trusts, it can use the information in the P-Asserted-Identity header field, if any, as if it had authenticated the user itself. If there is no P-Asserted-Identity header field present, a proxy MAY add one containing...." I take this as meaning that P-Asserted-Id can be sent in requests or responses. This capability is made use of in draft-ietf-sipping-qsig2sip-02 sections 9.1.3 and 9.2.3. John Elwell (john.elwell@siemens.com) > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: 07 June 2003 01:29 > To: Mark Watson > Cc: 'Michael Thomas'; Jonathan Rosenberg; Elwell, John; 'Drage, Keith > (Keith)'; 'sip@ietf.org' > Subject: Re: [Sip] UPDATE and P-Asserted-ID > > > > On Friday, May 23, 2003, at 03:21 AM, Mark Watson wrote: > > > Jonathan's approach seems reasonable, and since P-Asserted-Id just > > represents the identity of the originator of the *message* > > i think you are correct, that the spec means the originator of the > message, but I do not this is especially clear. i was not sure about > this. i thought it was just the initiator of the dialog. > After reading > through RFC 3325 three times, the only thing that strongly indicated > this was the case was the list of which methods could contain the > header. It is unfortunate that UPDATE was not included, > since this is > one of the places using P-Asserted-Id makes the most sense. > > thanks, > -rohan > > > > we could expect it to change during a dialog - I suppose there is a > > philosphical question that if the identity of the SIP UAS changes, > > does that mean it is now a logically different UAS and so a > new dialog > > should be established ? even if it's the same physical > device so that > > all the state needed to maintain a single dialog is still > available ?? > > I guess this is the case when call forward/transfer happens > downstream > > of a SIP->X gateway. > > > > Equally, were a device to de-register and re-register with a new > > Address Of Record, does this represent an 'identity change' > for that > > UA ? Could it meaningfully update its identity in any > ongoing dialogs > > > ? > > > > I think there should be scope for individual headers to > specify that > > their state cannot be updated mid-dialog. Not having looked through > > all the 'such headers' referred to by Jonathan (not even > knowing what > > this list is!) we can't rule out that the meaning of a mid-dialog > > update for one of these might not be well-defined i.e. it has no > > sensible meaning or is ambiguous. In those cases we would > need to rule > > out mid-dialog updates, or define the meaning of them for > that header. > > > > ...Mark > > > > > > > > > -----Original Message----- > > > From: Michael Thomas [mailto:mat@cisco.com] > > > Sent: 19 May 2003 21:18 > > > To: Jonathan Rosenberg > > > Cc: Elwell, John; 'Rohan Mahy'; 'Drage, Keith (Keith)'; > > 'sip@ietf.org' > > > Subject: Re: [Sip] UPDATE and P-Asserted-ID > > > > > > > > > Jonathan Rosenberg writes: > > >  > 1. Each header field that conveys dialog-associated state would > > >  > indicate whether or not that state is updated by a target > > > refresh request. > > >  > > > >  > 2. We specify a blanket rule for all such headers that > > > their state is > > >  > updated by a target refresh request (absence of a header > > > would imply > > >  > no update). > > >  > > > >  > 3. We specify a blanket rule for all such headers that > > > their state is > > >  > never updated by a target refresh request. > > >  > > > >  > 4. We specify a default rule for all such headers, but allow > > >  > individual headers to override it. > > >  > > > >  > > > >  > In the interests of simplicity I would tend to lean > > > towards (2). The > > >  > best place for this, of course, is rfc 3261, in which case > > > we should > > >  > treat this as a bug against the spec. > > > > > > This seems quite reasonable to me as well -- > > > special casing "initial" from subsequent dialog > > > seems pretty fraught. The only reason that I can > > > think of why you might want to do that is when the > > > state assembly/teardown of a mid-session change > > > was so onerous and/or ambiguous to other state > > > that it was prudent to set up the state once and > > > leave it be. It doesn't seem to me that that's the > > > case here, but I'm hardly an expert. > > > > > >        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 > > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 9 08:18:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29648 for ; Mon, 9 Jun 2003 08:18:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h59CITs28715 for sip-archive@odin.ietf.org; Mon, 9 Jun 2003 08:18:29 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59CG3B28636; Mon, 9 Jun 2003 08:16:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59CEVB28551 for ; Mon, 9 Jun 2003 08:14:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29541 for ; Mon, 9 Jun 2003 08:14:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PLVk-000289-00 for sip@ietf.org; Mon, 09 Jun 2003 08:12:28 -0400 Received: from mx5.aruba.it ([62.149.128.134]) by ietf-mx with smtp (Exim 4.12) id 19PLVj-000280-00 for sip@ietf.org; Mon, 09 Jun 2003 08:12:27 -0400 Received: (qmail 28968 invoked by uid 8002); 9 Jun 2003 12:13:40 -0000 Received: from unknown (HELO braies.giandrea.com) (217.57.90.125) by mx5.aruba.it with SMTP; 9 Jun 2003 12:13:40 -0000 Message-Id: <5.2.1.1.0.20030609135742.00b4dcf0@pop.icon.it> X-Sender: andrea/giandrea.com@pop3.giandrea.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 09 Jun 2003 14:13:31 +0200 To: sip@ietf.org From: giAndrea Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_2762101==.ALT" X-Spam-Rating: mx5.aruba.it 1.6.2 0/1000/N Subject: [Sip] SIP and Java Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --=====================_2762101==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Hi all, I=B4m new to SIP. Where can i found some official documents (draft= or=20 RFC) for use Java (and applets) SIP methods? thanks. Andrea (andrea@giandrea.com)=20 --=====================_2762101==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all, I=B4m new to SIP. Where can i found so= me official documents (draft or RFC) for use Java (and applets) SIP methods?

thanks.

Andrea (andrea@giandrea.com) --=====================_2762101==.ALT-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 9 10:39:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07085 for ; Mon, 9 Jun 2003 10:39:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h59EcsE06870 for sip-archive@odin.ietf.org; Mon, 9 Jun 2003 10:38:54 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59EYlB05827; Mon, 9 Jun 2003 10:34:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59EW0B05720 for ; Mon, 9 Jun 2003 10:32:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06842; Mon, 9 Jun 2003 10:31:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PNek-0003sL-00; Mon, 09 Jun 2003 10:29:54 -0400 Received: from [61.144.161.2] (helo=mta0.huawei.com) by ietf-mx with esmtp (Exim 4.12) id 19PNei-0003sG-00; Mon, 09 Jun 2003 10:29:53 -0400 Received: from Natarajucl1127 (mta0.huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HG700FVCXJQYU@mta0.huawei.com>; Mon, 09 Jun 2003 22:28:40 +0800 (CST) Date: Mon, 09 Jun 2003 19:59:58 +0530 From: "Nataraju A.B." To: SIP , SIPPING Message-id: <003c01c32e93$9b6c44a0$3802120a@in.huawei.com> Organization: HTIPL MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: multipart/alternative; boundary="Boundary_(ID_qTOuGtaSXpaO8PJIpnUV2g)" X-Priority: 3 X-MSMail-priority: Normal Subject: [Sip] Fw: Is there a freeeware available for conversion between feature predicate and feature parameters........... Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_qTOuGtaSXpaO8PJIpnUV2g) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Regards, -Nataraju A.B. May you live as long as you wish and love as long as you live. --Robert A. Heinlein Time Enough for Love. ----- Original Message ----- From: Nataraju A.B. To: SIP Implementors Sent: Monday, June 09, 2003 5:04 PM Subject: Is there a freeeware available for conversion between feature predicate and feature parameters........... Hi All, is there a freeware or general guidelines available for converion between feature predicate and feature parameters. Thanx in advance, Regards, -Nataraju A.B. --Boundary_(ID_qTOuGtaSXpaO8PJIpnUV2g) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
 
Regards,
-Nataraju A.B.
May you live as long as you wish and love as long as you live.
--Robert A. Heinlein Time Enough for Love.
----- Original Message -----
Sent: Monday, June 09, 2003 5:04 PM
Subject: Is there a freeeware available for conversion between feature predicate and feature parameters...........

 
Hi All,
 
is there a freeware or general guidelines available for converion between feature predicate and feature parameters.
 
Thanx in advance,
 
Regards,
-Nataraju A.B.
--Boundary_(ID_qTOuGtaSXpaO8PJIpnUV2g)-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 9 10:55:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07573 for ; Mon, 9 Jun 2003 10:55:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h59Esw107484 for sip-archive@odin.ietf.org; Mon, 9 Jun 2003 10:54:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59EqaB07396; Mon, 9 Jun 2003 10:52:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59EpkB07351 for ; Mon, 9 Jun 2003 10:51:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07486 for ; Mon, 9 Jun 2003 10:51:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PNxs-00040X-00 for sip@ietf.org; Mon, 09 Jun 2003 10:49:40 -0400 Received: from mail.mailsnare.net ([216.127.80.39]) by ietf-mx with esmtp (Exim 4.12) id 19PNxs-00040U-00 for sip@ietf.org; Mon, 09 Jun 2003 10:49:40 -0400 Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by dummy.domain.name (Postfix) with SMTP id 09D6658015E for ; Mon, 9 Jun 2003 14:53:04 +0000 (UTC) Received: from acm.org (12-234-8-147.client.attbi.com [12.234.8.147]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.mailsnare.net (Postfix) with ESMTP id 87813580158 for ; Mon, 9 Jun 2003 14:53:03 +0000 (UTC) Message-ID: <3EE49ECB.90807@acm.org> Date: Mon, 09 Jun 2003 07:50:51 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030527 Debian/1.3.1-2 X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Subject: Re: [Sip] SIP and Java References: <5.2.1.1.0.20030609135742.00b4dcf0@pop.icon.it> In-Reply-To: <5.2.1.1.0.20030609135742.00b4dcf0@pop.icon.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h59EpkB07352 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 giAndrea wrote: > > Hi all, I´m new to SIP. Where can i found some official documents (draft > or RFC) for use Java (and applets) SIP methods? http://java.sun.com/products/jain/api_specs.html > > thanks. > > Andrea (andrea@giandrea.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 Jun 9 15:44:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18948 for ; Mon, 9 Jun 2003 15:44:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h59Ji5b31188 for sip-archive@odin.ietf.org; Mon, 9 Jun 2003 15:44:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59JhQB31120; Mon, 9 Jun 2003 15:43:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59JfZB31057 for ; Mon, 9 Jun 2003 15:41:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18838 for ; Mon, 9 Jun 2003 15:41:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PSUO-0006WY-00 for sip@ietf.org; Mon, 09 Jun 2003 15:39:32 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19PSUN-0006WI-00 for sip@ietf.org; Mon, 09 Jun 2003 15:39:31 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h59JeZ614524; Mon, 9 Jun 2003 14:40:35 -0500 Subject: Re: [Sip] WGLC for auth-id body From: Robert Sparks To: Rohan Mahy Cc: sip@ietf.org, "'Dean Willis'" , Gonzalo.Camarillo@ericsson.com, Jon Peterson In-Reply-To: <9131FA75-85A4-11D7-8E16-0003938AF740@cisco.com> References: <9131FA75-85A4-11D7-8E16-0003938AF740@cisco.com> Content-Type: text/plain Message-Id: <1055187632.936.121.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 09 Jun 2003 14:40:33 -0500 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've reviewed this document (with revision of referredby particularly in mind) and have the following minor comments: - It would help section 4 to more explicitly note that it is discussing using AIBs to do something beyond(besides?) providing integrity protection/authentication for the request it appears in. It would also help to capture that the presence of these other things don't preclude the section 2 use of an AIB. Perhaps this text at end of the first paragraph of section 4: Such information might be carried in one or more supplemental AIBs. The presence of these supplemental AIBs does not preclude the use of AIB as specified in this document to protect the message in which they appear. - Instead of a special case of INVITE (see the heading of section 4), I think this simply a different use of an AIB. This document constrains the use of AIBs for providing integrity protection of messages and authenticating their sender regardless of method type. Section 4 is trying to note that other AIBs might appear that do something different. Perhaps this section could be titled "Potential additional uses of AIBs"? - Section 10 (Security Considerations): The first sentence needs to be scoped to the section 2 use of AIBs, not all uses of AIBs with message/sipfrag in them. - Spelling Nits: * Second sentence, last paragraph Page 4: s/SHOULD be added it to/SHOULD be added to/ * Second sentence, last paragraph, section 4, Page 6: s/harder to correlated an AIB/harder to correlate an AIB/ Other than that, I believe this document is ready to go. RjS On Tue, 2003-05-13 at 19:39, Rohan Mahy wrote: > Hello Everyone, > > I would like to begin Working Group Last Call on > > http://www.ietf.org/internet-drafts/draft-ietf-sip-authid-body-01.txt > > WGLC will end on Friday, June 13, 2003. > > 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 Jun 9 16:02:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19517 for ; Mon, 9 Jun 2003 16:02:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h59K1uE31923 for sip-archive@odin.ietf.org; Mon, 9 Jun 2003 16:01:56 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59K1QB31886; Mon, 9 Jun 2003 16:01:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59K0jB31785 for ; Mon, 9 Jun 2003 16:00:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19425 for ; Mon, 9 Jun 2003 16:00:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PSmw-0006cs-00 for sip@ietf.org; Mon, 09 Jun 2003 15:58:42 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19PSmv-0006cd-00 for sip@ietf.org; Mon, 09 Jun 2003 15:58:41 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h59K0B614725; Mon, 9 Jun 2003 15:00:11 -0500 From: Robert Sparks To: sip@ietf.org Cc: Jon Peterson Content-Type: text/plain Message-Id: <1055188807.936.142.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 09 Jun 2003 15:00:07 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Use of AIB in referredby Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 Several weeks ago, Pekka made a suggestion that I would like to follow up on now (sorry for the very long delay Pekka). His suggestion was to use a different Content-Disposition disposition-type for referredby-tokens. This draws attention to what the "aib" value means. Is it merely a synonym for "signed message/sipfrag"? If so, the authid-body draft defines the value _and_ specifies one particular use of a body with that disposition type (providing integrity and authentication of sender for a single message). Other uses are valid, so we should reuse it and not add noise to the IANA registry. If, instead, "aib" means "signed message/sipfrag with these particular security implications", then our referredby token is _not_ an aib. It's something _like_ an aib, but with slightly different requirements, and artifacts in the protocol (like the disposition-type) should probably reflect that. If this is the case, referredby could register something like "RBIB" (ReferredBy Identity Body), or, treading much more dangerous ground, "TPIB" (Third Party Identity Body). So, which of the above meanings for AIB is auth-id body establishing? 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 Jun 10 12:29:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07820 for ; Tue, 10 Jun 2003 12:29:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AGSkK05512 for sip-archive@odin.ietf.org; Tue, 10 Jun 2003 12:28:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AGS5B05465; Tue, 10 Jun 2003 12:28:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AGPHB05315 for ; Tue, 10 Jun 2003 12:25:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07652 for ; Tue, 10 Jun 2003 12:25:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pltv-00009c-00 for sip@ietf.org; Tue, 10 Jun 2003 12:23:11 -0400 Received: from terra.polito.it ([130.192.3.81] helo=polito.it) by ietf-mx with esmtp (Exim 4.12) id 19Pltq-00009Y-00 for sip@ietf.org; Tue, 10 Jun 2003 12:23:06 -0400 Received: from [130.192.1.182] (account d004316 HELO polito.it) by polito.it (CommuniGate Pro SMTP 4.1b7) with ESMTP-TLS id 8176794; Tue, 10 Jun 2003 18:18:03 +0200 Message-ID: <3EE60565.8060000@polito.it> Date: Tue, 10 Jun 2003 18:20:53 +0200 From: Marco Aime User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jon.peterson@neustar.biz CC: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Question on draft-ietf-sip-identity-01 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 Jon, regarding draft-ietf-sip-identity-01, I'm wondering what can be the problems trying to place the authentication token into a SIP header rather than the body: has the consequences of this option been investigated already? Thanks in advance Bye Marco Aime -- ------------------------------------------------------------------ Marco AIME Dipartimento di Automatica e Informatica Politecnico di Torino Addr: Via Cardinal Massaia 83, Torino, Italy Tel: +39 011 22102-44 Fax: +39 011 22102-29 Mail: m.aime@polito.it (marcodomenico.aime@polito.it) ------------------------------------------------------------------ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 12 02:04:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20090 for ; Thu, 12 Jun 2003 02:04:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5C63lb08866 for sip-archive@odin.ietf.org; Thu, 12 Jun 2003 02:03:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C63Bm08850; Thu, 12 Jun 2003 02:03:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C60Dm08544 for ; Thu, 12 Jun 2003 02:00:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15840 for ; Thu, 12 Jun 2003 02:00:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QL65-0006mb-00 for sip@ietf.org; Thu, 12 Jun 2003 01:58:05 -0400 Received: from wiprom2mx1.wipro.com ([203.197.164.41]) by ietf-mx with esmtp (Exim 4.12) id 19QL63-0006mV-00 for sip@ietf.org; Thu, 12 Jun 2003 01:58:04 -0400 Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id h5C5xYC24868 for ; Thu, 12 Jun 2003 11:29:34 +0530 (IST) Received: from blr-m1-msg.wipro.com ([10.115.50.99]) by blr-m1-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 12 Jun 2003 11:29:29 +0530 Received: from wipro.com ([10.115.6.218]) by blr-m1-msg.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 12 Jun 2003 11:29:29 +0530 Message-ID: <3EE816F2.4020109@wipro.com> Date: Thu, 12 Jun 2003 11:30:18 +0530 From: Vijay Kamath User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030314 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 X-OriginalArrivalTime: 12 Jun 2003 05:59:30.0002 (UTC) FILETIME=[C9CFDB20:01C330A7] Content-Transfer-Encoding: 7bit Subject: [Sip] Replaces header query Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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, As per "draft-ietf-sip-replaces-03.txt", the Replaces header can only be present in an INVITE request. I was wondering if this invite request MUST always be a new request or can it also be a re-invite. Re-invites are mentioned nowhere in the draft. Regards... Vijay _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 12 02:22:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27847 for ; Thu, 12 Jun 2003 02:22:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5C6Lwr21121 for sip-archive@odin.ietf.org; Thu, 12 Jun 2003 02:21:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C6LNm20712; Thu, 12 Jun 2003 02:21:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C6Kam20586 for ; Thu, 12 Jun 2003 02:20:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27787 for ; Thu, 12 Jun 2003 02:20:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QLPn-0006ro-00 for sip@ietf.org; Thu, 12 Jun 2003 02:18:27 -0400 Received: from smtp011.mail.yahoo.com ([216.136.173.31]) by ietf-mx with smtp (Exim 4.12) id 19QLPm-0006rl-00 for sip@ietf.org; Thu, 12 Jun 2003 02:18:26 -0400 Received: from 12-235-146-159.client.attbi.com (HELO cranberry) (seancolson@12.235.146.159 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 12 Jun 2003 06:20:31 -0000 Reply-To: From: "Sean Olson" To: "'Vijay Kamath'" , Subject: RE: [Sip] Replaces header query Date: Wed, 11 Jun 2003 23:20:49 -0700 Message-ID: <001d01c330aa$c4e0b460$6801a8c0@cranberry> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <3EE816F2.4020109@wipro.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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 Replaces: header in a re-INVITE would be a bit odd, but I don't see any reason to disallow it. -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Vijay Kamath Sent: Wednesday, June 11, 2003 11:00 PM To: sip@ietf.org Subject: [Sip] Replaces header query Hi all, As per "draft-ietf-sip-replaces-03.txt", the Replaces header can only be present in an INVITE request. I was wondering if this invite request MUST always be a new request or can it also be a re-invite. Re-invites are mentioned nowhere in the draft. Regards... Vijay _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Jun 12 06:48:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02823 for ; Thu, 12 Jun 2003 06:48:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CAmYA08270 for sip-archive@odin.ietf.org; Thu, 12 Jun 2003 06:48:34 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CAmCm08241; Thu, 12 Jun 2003 06:48:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CAiJm08135 for ; Thu, 12 Jun 2003 06:44:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02757 for ; Thu, 12 Jun 2003 06:44:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QPX0-0000ZT-00 for sip@ietf.org; Thu, 12 Jun 2003 06:42:10 -0400 Received: from [203.197.15.67] (helo=gatekeeper2.mahindrabt.com) by ietf-mx with esmtp (Exim 4.12) id 19QPWz-0000ZQ-00 for sip@ietf.org; Thu, 12 Jun 2003 06:42:09 -0400 Received: from thisdomain (mailscan.mahindrabt.com [10.2.0.50]) by gatekeeper2.mahindrabt.com (8.12.9/8.12.9) with ESMTP id h5CAi353025157 for ; Thu, 12 Jun 2003 16:14:07 +0530 Received: from intranet.sharda.mahindrabt.com by mahindrabt.com ; Thu, 12 Jun 2003 15:48:18 +0530 Date: Thu, 12 Jun 2003 15:48:18 +0530 X-Originating-IP: 10.5.0.15 X-Auth-User: shail@mahindrabt.com Received: from dscp00947 ([10.5.12.184]) by intranet.sharda.mahindrabt.com (8.9.3/8.9.3) with ESMTP id QAA09621; Thu, 12 Jun 2003 16:13:52 +0530 Message-ID: <008e01c330cf$ddf09180$b80c050a@mahindrabt.com> Reply-To: "Shailendra" From: "Shailendra" To: "Sip@Ietf. Org" Cc: "Tasos Dagiouklas" References: Subject: Re: [Sip] Of-hook and On-hook @ sip? Date: Thu, 12 Jun 2003 16:16:20 +0530 Organization: Mahibdra - British Telecom MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1253" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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, INVITE will map to SETUP ( Q-931). but if you ask precisely about PSTN then INVITE is equivalent of (OFFHOOK + Sizure + dialed digits ) BYE will map to ONHOOK in PSTN and REL in Q-931 /Shailendra ----- Original Message ----- From: "F.S.Salloum" To: "Sip@Ietf. Org" Cc: "Tasos Dagiouklas" Sent: Wednesday, February 26, 2003 6:01 PM Subject: [Sip] Of-hook and On-hook @ sip? > Dear all, > > One simple question is there a similar message > in SIP which works like on-hook and off-hook on > the PSTN world (Q-931)? > > I know that this can be implemented playing with > the state machines of the hard-sip-phone but we were > wondering if this has been investigated from you guys. > > Thanks > F.S.Salloum > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ********************************************************* Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 12 09:41:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10004 for ; Thu, 12 Jun 2003 09:41:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CDeor22224 for sip-archive@odin.ietf.org; Thu, 12 Jun 2003 09:40:50 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CDZvm21159; Thu, 12 Jun 2003 09:35:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CDWim21013 for ; Thu, 12 Jun 2003 09:32:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09841; Thu, 12 Jun 2003 09:32:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QS9z-0002N0-00; Thu, 12 Jun 2003 09:30:35 -0400 Received: from [202.62.83.99] (helo=gateway.blr.dlink.com) by ietf-mx with esmtp (Exim 4.12) id 19QS9x-0002Mq-00; Thu, 12 Jun 2003 09:30:34 -0400 Received: from userbvyungtdgz (localhost [127.0.0.1]) by gateway.blr.dlink.com (8.11.0/8.11.0) with SMTP id h5CDeqo23306; Thu, 12 Jun 2003 19:10:52 +0530 Message-ID: <000d01c330e7$7afc9ca0$6064a8c0@userbvyungtdgz> From: "debanjan" To: , Date: Thu, 12 Jun 2003 19:05:25 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C33115.947E1130" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: [Sip] Message Body format for INFO method carrying DTMF Digits Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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_000A_01C33115.947E1130 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ----------------------------------------- (on the network)---------------- email-body was scanned and no virus found email-body was scanned and no virus found -----------------------------------------D-Link R & D E-Mail Traffic----------- ------=_NextPart_000_000A_01C33115.947E1130 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Anyone has any idea regarding what should be message body of SIP = Info method that carries the DTMF digits. Is there any standard RFC or = draft implementation. Any suggestions are welcome. Regards Debanjan =20 D-Link India Ltd Software and R & D Center ------=_NextPart_000_000A_01C33115.947E1130 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
    Anyone has any idea = regarding=20 what should be message body of SIP Info method that carries the DTMF = digits. Is=20 there any standard RFC or draft implementation.
    Any suggestions are=20 welcome.
 
    Regards
    = Debanjan
   
    D-Link India = Ltd
    Software and R & = D=20 Center
------=_NextPart_000_000A_01C33115.947E1130-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 13 07:40:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28580 for ; Fri, 13 Jun 2003 07:40:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DBeNA01469 for sip-archive@odin.ietf.org; Fri, 13 Jun 2003 07:40:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D5K5a25704; Fri, 13 Jun 2003 01:20:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D5J8m25657 for ; Fri, 13 Jun 2003 01:19:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09328 for ; Fri, 13 Jun 2003 01:19:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qgvq-0001Ia-00 for sip@ietf.org; Fri, 13 Jun 2003 01:16:58 -0400 Received: from law12-f85.law12.hotmail.com ([64.4.19.85] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19Qgvp-0001IQ-00 for sip@ietf.org; Fri, 13 Jun 2003 01:16:57 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 12 Jun 2003 22:18:35 -0700 Received: from 193.220.224.9 by lw12fd.law12.hotmail.msn.com with HTTP; Fri, 13 Jun 2003 05:18:34 GMT X-Originating-IP: [193.220.224.9] X-Originating-Email: [rajarshi_chakraborty@hotmail.com] From: "Rajarshi Chakraborty" To: sip@ietf.org Date: Fri, 13 Jun 2003 05:18:34 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Jun 2003 05:18:35.0556 (UTC) FILETIME=[3D42DE40:01C3316B] Subject: [Sip] Question on draft-schulzrinne-sip-register-01 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, The draft in reference to which I have a doubt has already expired long back (October 2001). So are questions in reference to outdated drafts entertained in these mailing lists? It would help me a lot if someone responds to this email. My doubt is regarding the second model of registration called "Outbound proxy intercept"... It has been proposed in this model that the foreign outbound proxy must maintain a temporary ID for the visiting mobile host. But who is supposed to store this ID? Also I understand that the Local proxy will only forward the register msg to the Local registrar only after it receives a 200 OK from the home proxy, either with local proxy's contact or with the real local contact. But what about the SIP URI in the To and From headers of the regiater msg that the local proxy will forward to the local registrar? If A is the home proxy's domain and B is the local proxy's domain and 1000 is the user name, would the SIP URI in the To and From header of this register msg be 1000%40A@B ? Ofcourse the SIP URI in the register msg that is forwarded to the home proxy should be 1000@A. I guess the canonical visitor name is useful for the local proxy to handle incoming requests meant for the visiting mobile host. But for the Register I think the ID corresponding to the visiting host should be 1000%40A, i.e. the first part. This has not been mentioned in the draft. Or is it supposed to be understood from the way the model has been proposed in the draft? regards, Rajarshi Rajarshi Chakraborty B-196, IIT Campus, Kharagpur, West Bengal, India PIN-721302 _________________________________________________________________ Looking for love? Yearning for friendship? http://www.msn.co.in/Romance/ You're in the right place _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 13 08:30:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00192 for ; Fri, 13 Jun 2003 08:30:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DCTVN04733 for sip-archive@odin.ietf.org; Fri, 13 Jun 2003 08:29:31 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D627a28235; Fri, 13 Jun 2003 02:02:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D61rm28190 for ; Fri, 13 Jun 2003 02:01:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12026 for ; Fri, 13 Jun 2003 02:01:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QhbC-0001V4-00 for sip@ietf.org; Fri, 13 Jun 2003 01:59:42 -0400 Received: from 205-158-62-158.outblaze.com ([205.158.62.158] helo=spf1.us.outblaze.com) by ietf-mx with smtp (Exim 4.12) id 19QhbB-0001UW-00 for sip@ietf.org; Fri, 13 Jun 2003 01:59:41 -0400 Received: (qmail 29164 invoked from network); 13 Jun 2003 06:00:44 -0000 Received: from unknown (205.158.62.68) by spf1.us.outblaze.com with QMQP; 13 Jun 2003 06:00:44 -0000 Received: (qmail 7241 invoked from network); 13 Jun 2003 06:01:18 -0000 Received: from unknown (HELO ws1-9.us4.outblaze.com) (205.158.62.37) by 205-158-62-153.outblaze.com with SMTP; 13 Jun 2003 06:01:18 -0000 Received: (qmail 78837 invoked by uid 1001); 13 Jun 2003 06:01:18 -0000 Message-ID: <20030613060118.78836.qmail@mail.com> Content-Type: text/html; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [202.54.26.125] by ws1-9.us4.outblaze.com with http for umsharma@techie.com; Fri, 13 Jun 2003 01:01:18 -0500 From: "Umesh Sharma" To: "debanjan" , sip@ietf.org, sipping@ietf.org Date: Fri, 13 Jun 2003 01:01:18 -0500 Subject: Re: [Sip] Message Body format for INFO method carrying DTMF Digits X-Originating-Ip: 202.54.26.125 X-Originating-Server: ws1-9.us4.outblaze.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

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

Umesh

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

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

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

_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 13 09:51:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05167 for ; Fri, 13 Jun 2003 09:51:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DDpFv12377 for sip-archive@odin.ietf.org; Fri, 13 Jun 2003 09:51:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D7I4a13318; Fri, 13 Jun 2003 03:18:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D7Ham13289 for ; Fri, 13 Jun 2003 03:17:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23687 for ; Fri, 13 Jun 2003 03:17:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QimV-0002Hp-00 for sip@ietf.org; Fri, 13 Jun 2003 03:15:27 -0400 Received: from pine.neustar.com ([209.173.57.70]) by ietf-mx with esmtp (Exim 4.12) id 19QimV-0002Hj-00 for sip@ietf.org; Fri, 13 Jun 2003 03:15:27 -0400 Received: from chiimc01.npac.com ([10.32.90.4]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id h5D7GxN07836; Fri, 13 Jun 2003 07:16:59 GMT Received: by CHIIMC01 with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Jun 2003 02:19:40 -0500 Message-ID: <0449D80A0E9B614A83FA9031B07E8D3B257B2C@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Robert Sparks'" , sip@ietf.org Date: Fri, 13 Jun 2003 02:17:23 -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: Use of AIB in referredby Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 look at the AIB as the application of sipfrags to the problem described in RFC3261 23.4 - the tunneling of integrity and authentication properties within the MIME bodies of SIP messages. In the AIB, these properties are intended to provide identity, hence the name 'authenticated identity body'. I think that the usage in referredby is sufficiently close to that purpose, providing authenticated identity within a body, that I don't think we have a problem with reuse of the term. The real question, I think, is whether or not there is any value in differentiating an AIB resulting from a REFER from any other AIB (such as a 'normal' one representing the sender of an INVITE) that might be in a request. Surely these need to be differentiated somehow - the signature on the AIB itself would be one indicator, as would the headers in the body, but Content-Disposition is another point at which the two could be distinguished. I don't have a strong intuition about whether or not the use of a different Content-Disposition would be valuable. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Monday, June 09, 2003 1:00 PM > To: sip@ietf.org > Cc: Jon Peterson > Subject: Use of AIB in referredby > > > Several weeks ago, Pekka made a suggestion that I would like to > follow up on now (sorry for the very long delay Pekka). His > suggestion was to use a different Content-Disposition > disposition-type for referredby-tokens. > > This draws attention to what the "aib" value means. > > Is it merely a synonym for "signed message/sipfrag"? If so, the > authid-body draft defines the value _and_ specifies one particular > use of a body with that disposition type (providing integrity and > authentication of sender for a single message). Other uses are valid, > so we should reuse it and not add noise to the IANA registry. > > If, instead, "aib" means "signed message/sipfrag with these > particular security implications", then our referredby token > is _not_ an aib. It's something _like_ an aib, but with > slightly different requirements, and artifacts in the protocol > (like the disposition-type) should probably reflect that. If this > is the case, referredby could register something like "RBIB" > (ReferredBy Identity Body), or, treading much more dangerous ground, > "TPIB" (Third Party Identity Body). > > So, which of the above meanings for AIB is auth-id body establishing? > > 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 Fri Jun 13 10:51:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08641 for ; Fri, 13 Jun 2003 10:51:46 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DEpJF17471 for sip-archive@odin.ietf.org; Fri, 13 Jun 2003 10:51:19 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D7a6a14183; Fri, 13 Jun 2003 03:36:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D7Zhm14167 for ; Fri, 13 Jun 2003 03:35:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23998 for ; Fri, 13 Jun 2003 03:35:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qj41-0002OY-00 for sip@ietf.org; Fri, 13 Jun 2003 03:33:33 -0400 Received: from pine.neustar.com ([209.173.57.70]) by ietf-mx with esmtp (Exim 4.12) id 19Qj41-0002OT-00 for sip@ietf.org; Fri, 13 Jun 2003 03:33:33 -0400 Received: from chiimc01.npac.com ([10.32.90.4]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id h5D7YWN07922; Fri, 13 Jun 2003 07:34:35 GMT Received: by CHIIMC01 with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Jun 2003 02:37:13 -0500 Message-ID: <0449D80A0E9B614A83FA9031B07E8D3B257B2D@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Marco Aime'" Cc: sip@ietf.org Date: Fri, 13 Jun 2003 02:34:56 -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: Question on draft-ietf-sip-identity-01 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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, Yes, the consequences of placing an authentication token into a SIP header have been considered in the past. There were really three significant factors that led to the architecture used in draft-ietf-sip-identity (in which the authentication token appears in a body instead): - The tokens themselves can be quite large and complicated. Following the recommendation in the AIB draft (draft-ietf-sip-authid-body), a token might contain numerous headers which are required for reference integrity. Compound that with a digital signature. Compound that with an appended certificate for verifying the signature (common in CMS applications). All together, the size of one of these tokens would be considerably larger that conventional SIP headers. While technically, headers are unbounded in size, from a practical perspective chunks of data over a certain threshhold are more suitable for the body of a message than a header. A proxy handling a header that was, say, over 1K in size could conceivably hiccup. Encoding a header that contained multiple SIP headers and a digital signature and a certificate could also be challenging. - For additional reference integrity, some tokens may want to place signatures around actual message bodies, notably SDP. This is a general motivation for the use of S/MIME for identity. Replicating bodies in headers would be... silly. - Headers are frequently manipulated by proxy servers - bodies, however, MUST NOT be modified by proxy servers (per RFC3261 16.6). A great deal of emphasis in the SIP security work was placed on end-to-end security properties. While headers can be marked unmodifiable (by omitting the 'amd's in the famous Table 2 of RFC3261), the guidelines for bodies are more strict. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Marco Aime [mailto:m.aime@polito.it] > Sent: Tuesday, June 10, 2003 9:21 AM > To: jon.peterson@neustar.biz > Cc: sip@ietf.org > Subject: Question on draft-ietf-sip-identity-01 > > > Hi Jon, > > regarding draft-ietf-sip-identity-01, I'm wondering what can be the > problems trying to place the authentication token into a SIP header > rather than the body: has the consequences of this option been > investigated already? > > Thanks in advance > Bye > Marco Aime > > -- > ------------------------------------------------------------------ > Marco AIME > Dipartimento di Automatica e Informatica > Politecnico di Torino > Addr: Via Cardinal Massaia 83, Torino, Italy > Tel: +39 011 22102-44 > Fax: +39 011 22102-29 > Mail: m.aime@polito.it (marcodomenico.aime@polito.it) > ------------------------------------------------------------------ > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 13 11:48:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10276 for ; Fri, 13 Jun 2003 11:48:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DFlqF22681 for sip-archive@odin.ietf.org; Fri, 13 Jun 2003 11:47:52 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D745a11814; Fri, 13 Jun 2003 03:04:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D73fm11795 for ; Fri, 13 Jun 2003 03:03:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23460 for ; Fri, 13 Jun 2003 03:03:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QiZ1-0002CH-00 for sip@ietf.org; Fri, 13 Jun 2003 03:01:31 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx with esmtp (Exim 4.12) id 19QiZ0-0002CD-00 for sip@ietf.org; Fri, 13 Jun 2003 03:01:30 -0400 Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h5D72rC25510; Fri, 13 Jun 2003 07:02:53 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Jun 2003 03:03:18 -0400 Message-ID: <0449D80A0E9B614A83FA9031B07E8D3B257B2B@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Robert Sparks'" , Rohan Mahy Cc: sip@ietf.org, "'Dean Willis'" , Gonzalo.Camarillo@ericsson.com Subject: RE: [Sip] WGLC for auth-id body Date: Fri, 13 Jun 2003 03:03:16 -0400 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: , Thanks for these comments. A few notes below. Jon Peterson NeuStar, Inc. [snip] > I've reviewed this document (with revision of referredby > particularly in mind) and have the following minor comments: > > - It would help section 4 to more explicitly note that it > is discussing using AIBs to do something beyond(besides?) > providing integrity protection/authentication for the > request it appears in. It would also help to capture that > the presence of these other things don't preclude the section > 2 use of an AIB. Perhaps this text at end of the first paragraph > of section 4: > > Such information might be carried in one or more supplemental > AIBs. The presence of these supplemental AIBs does not preclude > the use of AIB as specified in this document to protect the > message in which they appear. > Yes, I do think it is important to capture the idea that there may be multiple AIBs in a SIP message that identify different parties. The text given above looks good to me. > - Instead of a special case of INVITE (see the heading of section 4), I > think this simply a different use of an AIB. This document constrains > the use of AIBs for providing integrity protection of messages and > authenticating their sender regardless of method type. Section 4 is > trying to note that other AIBs might appear that do something > different. Perhaps this section could be titled "Potential additional > uses of AIBs"? > Well, although REFER-instigated INVITEs might not be a special case as such, most would probably say that 3PCC is a special case. But still, we need a section title that accommodates both, so I think that's fair; a better title for this section is probably in order. I think we need something with the sense "Use of AIBs to express the identity of someone other than the sender of the INVITE". I'll try to figure out a way to compress that to header-size. > - Section 10 (Security Considerations): The first sentence needs to > be scoped to the section 2 use of AIBs, not all uses of AIBs with > message/sipfrag in them. > Okay, fine. > - Spelling Nits: > * Second sentence, last paragraph Page 4: > s/SHOULD be added it to/SHOULD be added to/ > * Second sentence, last paragraph, section 4, Page 6: > s/harder to correlated an AIB/harder to correlate an AIB/ > Thanks, I'll take care of all of those. > Other than that, I believe this document is ready to go. > > RjS > > On Tue, 2003-05-13 at 19:39, Rohan Mahy wrote: > > Hello Everyone, > > > > I would like to begin Working Group Last Call on > > > > > http://www.ietf.org/internet-drafts/draft-ietf-sip-authid-body-01.txt > > > > WGLC will end on Friday, June 13, 2003. > > > > 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 Fri Jun 13 12:56:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12088 for ; Fri, 13 Jun 2003 12:56:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DGuFG31281 for sip-archive@odin.ietf.org; Fri, 13 Jun 2003 12:56:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DES3a15428; Fri, 13 Jun 2003 10:28:03 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DERem15398 for ; Fri, 13 Jun 2003 10:27:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07892; Fri, 13 Jun 2003 10:27:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QpUf-0005o0-00; Fri, 13 Jun 2003 10:25:29 -0400 Received: from law12-f46.law12.hotmail.com ([64.4.19.46] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19QpUe-0005nl-00; Fri, 13 Jun 2003 10:25:28 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 13 Jun 2003 07:27:03 -0700 Received: from 193.220.224.9 by lw12fd.law12.hotmail.msn.com with HTTP; Fri, 13 Jun 2003 14:27:02 GMT X-Originating-IP: [193.220.224.9] X-Originating-Email: [rajarshi_chakraborty@hotmail.com] From: "Rajarshi Chakraborty" To: sip@ietf.org, sipping@ietf.org Date: Fri, 13 Jun 2003 14:27:02 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Jun 2003 14:27:03.0026 (UTC) FILETIME=[DBA44D20:01C331B7] Subject: [Sip] Using SUBSCRIBE/NOTIFY in mobility Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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, This mail is kind of a follow-up to the earlier mail where I posted a couple of doubts regarding registration models in draft-schulzrinne-register-01. In the second design called "Outbound proxy intercept", could we not use SUBSCRIBE and NOTIFY between the mobile user agent and the outbound proxy server in the foriegn domain to indicate the former's departure from that domain into some other domain? And this would be followed by the local registrar unbinding the temporary canonical ID of the mobile host just upon receiving the NOTIFY, if it is co-located with the local proxy or the latter could send a de-register to the registrar if not co-located with it. According to this design the mobile host doesn't register with the foreign proxy/registrar. Hence I think SUBSCRIBE/NOTIFY would be of good use. The local proxy would SUBSCRIBE to the mobile user agent, and just before the latter departs it sends a NOTIFY back to the local proxy. Is this feasible? regards, Rajarshi Rajarshi Chakraborty B-196, IIT Campus, Kharagpur, West Bengal, India PIN-721302 _________________________________________________________________ Dress up your desktop! Get the best wallpapers. http://server1.msn.co.in/msnchannels/Entertainment/wallpaperhome.asp Just click here! _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From mailnull@www1.ietf.org Fri Jun 13 13:07:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13211 for ; Fri, 13 Jun 2003 13:07:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DH70709551 for sip-archive@odin.ietf.org; Fri, 13 Jun 2003 13:07:00 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DFx3a23333; Fri, 13 Jun 2003 11:59:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DFw9m23259 for ; Fri, 13 Jun 2003 11:58:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10473 for ; Fri, 13 Jun 2003 11:58:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QquF-0006MK-00 for sip@ietf.org; Fri, 13 Jun 2003 11:55:59 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19QquE-0006Le-00 for sip@ietf.org; Fri, 13 Jun 2003 11:55:58 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5DFvIE15779; Fri, 13 Jun 2003 10:57:18 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Jun 2003 11:01:38 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF5789D6@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Peterson, Jon'" , "'Robert Sparks'" , sip@ietf.org Subject: RE: [Sip] RE: Use of AIB in referredby Date: Fri, 13 Jun 2003 10:58:39 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , My general preference is to be more explicit and towards that end I would think a different Content-Disposition disposition-type could be useful. That said, if AIB were as general as Robert suggested initially, then it could possibly be reused even for the Inserted headers (like History-Info), where I'm currently modeling the solution after AIB, but was planning on a new Content-Disposition disposition-type. However, even I would agree that the Inserted Headers are more different than the original intent of AIB than the Referred-by use and again I do prefer to be more explicit. Mary. -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Friday, June 13, 2003 2:17 AM To: 'Robert Sparks'; sip@ietf.org Subject: [Sip] RE: Use of AIB in referredby I look at the AIB as the application of sipfrags to the problem described in RFC3261 23.4 - the tunneling of integrity and authentication properties within the MIME bodies of SIP messages. In the AIB, these properties are intended to provide identity, hence the name 'authenticated identity body'. I think that the usage in referredby is sufficiently close to that purpose, providing authenticated identity within a body, that I don't think we have a problem with reuse of the term. The real question, I think, is whether or not there is any value in differentiating an AIB resulting from a REFER from any other AIB (such as a 'normal' one representing the sender of an INVITE) that might be in a request. Surely these need to be differentiated somehow - the signature on the AIB itself would be one indicator, as would the headers in the body, but Content-Disposition is another point at which the two could be distinguished. I don't have a strong intuition about whether or not the use of a different Content-Disposition would be valuable. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Monday, June 09, 2003 1:00 PM > To: sip@ietf.org > Cc: Jon Peterson > Subject: Use of AIB in referredby > > > Several weeks ago, Pekka made a suggestion that I would like to > follow up on now (sorry for the very long delay Pekka). His > suggestion was to use a different Content-Disposition > disposition-type for referredby-tokens. > > This draws attention to what the "aib" value means. > > Is it merely a synonym for "signed message/sipfrag"? If so, the > authid-body draft defines the value _and_ specifies one particular > use of a body with that disposition type (providing integrity and > authentication of sender for a single message). Other uses are valid, > so we should reuse it and not add noise to the IANA registry. > > If, instead, "aib" means "signed message/sipfrag with these > particular security implications", then our referredby token > is _not_ an aib. It's something _like_ an aib, but with > slightly different requirements, and artifacts in the protocol > (like the disposition-type) should probably reflect that. If this > is the case, referredby could register something like "RBIB" > (ReferredBy Identity Body), or, treading much more dangerous ground, > "TPIB" (Third Party Identity Body). > > So, which of the above meanings for AIB is auth-id body establishing? > > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 13 13:17:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13684 for ; Fri, 13 Jun 2003 13:17:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DHGpq29528 for sip-archive@odin.ietf.org; Fri, 13 Jun 2003 13:16:51 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DGA4a25752; Fri, 13 Jun 2003 12:10:04 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DG9Bm25721 for ; Fri, 13 Jun 2003 12:09:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10789 for ; Fri, 13 Jun 2003 12:09:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qr4u-0006QA-00 for sip@ietf.org; Fri, 13 Jun 2003 12:07:00 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19Qr4u-0006Q7-00 for sip@ietf.org; Fri, 13 Jun 2003 12:07:00 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5DG8HE26015; Fri, 13 Jun 2003 11:08:18 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Jun 2003 11:12:38 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF5789D7@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Peterson, Jon'" , "'Robert Sparks'" , Rohan Mahy Cc: sip@ietf.org, "'Dean Willis'" , Gonzalo.Camarillo@ericsson.com Subject: RE: [Sip] WGLC for auth-id body Date: Fri, 13 Jun 2003 11:09:38 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , There's one more nit that I noticed that doesn't appear to be mentioned by Robert. In the second paragraph of section 4, the 2nd clause of the last sentence needs rewording. I think it should read: " ..., the From header of the INVITE would indicate the referee, whereas a separate header would indicate the referrer." Regards, Mary. -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Friday, June 13, 2003 2:03 AM To: 'Robert Sparks'; Rohan Mahy Cc: sip@ietf.org; 'Dean Willis'; Gonzalo.Camarillo@ericsson.com Subject: RE: [Sip] WGLC for auth-id body Thanks for these comments. A few notes below. Jon Peterson NeuStar, Inc. [snip] > I've reviewed this document (with revision of referredby > particularly in mind) and have the following minor comments: > > - It would help section 4 to more explicitly note that it > is discussing using AIBs to do something beyond(besides?) > providing integrity protection/authentication for the > request it appears in. It would also help to capture that > the presence of these other things don't preclude the section > 2 use of an AIB. Perhaps this text at end of the first paragraph > of section 4: > > Such information might be carried in one or more supplemental > AIBs. The presence of these supplemental AIBs does not preclude > the use of AIB as specified in this document to protect the > message in which they appear. > Yes, I do think it is important to capture the idea that there may be multiple AIBs in a SIP message that identify different parties. The text given above looks good to me. > - Instead of a special case of INVITE (see the heading of section 4), I > think this simply a different use of an AIB. This document constrains > the use of AIBs for providing integrity protection of messages and > authenticating their sender regardless of method type. Section 4 is > trying to note that other AIBs might appear that do something > different. Perhaps this section could be titled "Potential additional > uses of AIBs"? > Well, although REFER-instigated INVITEs might not be a special case as such, most would probably say that 3PCC is a special case. But still, we need a section title that accommodates both, so I think that's fair; a better title for this section is probably in order. I think we need something with the sense "Use of AIBs to express the identity of someone other than the sender of the INVITE". I'll try to figure out a way to compress that to header-size. > - Section 10 (Security Considerations): The first sentence needs to > be scoped to the section 2 use of AIBs, not all uses of AIBs with > message/sipfrag in them. > Okay, fine. > - Spelling Nits: > * Second sentence, last paragraph Page 4: > s/SHOULD be added it to/SHOULD be added to/ > * Second sentence, last paragraph, section 4, Page 6: > s/harder to correlated an AIB/harder to correlate an AIB/ > Thanks, I'll take care of all of those. > Other than that, I believe this document is ready to go. > > RjS > > On Tue, 2003-05-13 at 19:39, Rohan Mahy wrote: > > Hello Everyone, > > > > I would like to begin Working Group Last Call on > > > > > http://www.ietf.org/internet-drafts/draft-ietf-sip-authid-body-01.txt > > > > WGLC will end on Friday, June 13, 2003. > > > > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 13 13:18:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13808 for ; Fri, 13 Jun 2003 13:18:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DHHYY19183 for sip-archive@odin.ietf.org; Fri, 13 Jun 2003 13:17:34 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DH54a08832; Fri, 13 Jun 2003 13:05:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DH4Jm08479 for ; Fri, 13 Jun 2003 13:04:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13007 for ; Fri, 13 Jun 2003 13:04:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QrwG-0006uT-00 for sip@ietf.org; Fri, 13 Jun 2003 13:02:08 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx with esmtp (Exim 4.12) id 19QrwG-0006ts-00 for sip@ietf.org; Fri, 13 Jun 2003 13:02:08 -0400 Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h5DH3LC00841; Fri, 13 Jun 2003 17:03:21 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Jun 2003 13:03:47 -0400 Message-ID: <0449D80A0E9B614A83FA9031B07E8D3B257B33@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Mary Barnes'" , "'Robert Sparks'" , Rohan Mahy Cc: sip@ietf.org, "'Dean Willis'" , Gonzalo.Camarillo@ericsson.com Subject: RE: [Sip] WGLC for auth-id body Date: Fri, 13 Jun 2003 13:03:45 -0400 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: , Noted - yes, your text is superior. It'll be fixed. Thanks! Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Mary Barnes [mailto:mbarnes@nortelnetworks.com] > Sent: Friday, June 13, 2003 9:10 AM > To: 'Peterson, Jon'; 'Robert Sparks'; Rohan Mahy > Cc: sip@ietf.org; 'Dean Willis'; Gonzalo.Camarillo@ericsson.com > Subject: RE: [Sip] WGLC for auth-id body > > > There's one more nit that I noticed that doesn't appear to be mentioned by > Robert. > > In the second paragraph of section 4, the 2nd clause of the > last sentence > needs rewording. I think it should read: > " ..., the From header > of the INVITE would indicate the referee, whereas a separate header > would indicate the referrer." > > Regards, > Mary. > > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Friday, June 13, 2003 2:03 AM > To: 'Robert Sparks'; Rohan Mahy > Cc: sip@ietf.org; 'Dean Willis'; Gonzalo.Camarillo@ericsson.com > Subject: RE: [Sip] WGLC for auth-id body > > > > Thanks for these comments. A few notes below. > > Jon Peterson > NeuStar, Inc. > > [snip] > > I've reviewed this document (with revision of referredby > > particularly in mind) and have the following minor comments: > > > > - It would help section 4 to more explicitly note that it > > is discussing using AIBs to do something beyond(besides?) > > providing integrity protection/authentication for the > > request it appears in. It would also help to capture that > > the presence of these other things don't preclude the section > > 2 use of an AIB. Perhaps this text at end of the first paragraph > > of section 4: > > > > Such information might be carried in one or more supplemental > > AIBs. The presence of these supplemental AIBs does not preclude > > the use of AIB as specified in this document to protect the > > message in which they appear. > > > > Yes, I do think it is important to capture the idea that there may be > multiple AIBs in a SIP message that identify different > parties. The text > given above looks good to me. > > > - Instead of a special case of INVITE (see the heading of > section 4), I > > think this simply a different use of an AIB. This > document constrains > > the use of AIBs for providing integrity protection of messages and > > authenticating their sender regardless of method type. > Section 4 is > > trying to note that other AIBs might appear that do something > > different. Perhaps this section could be titled > "Potential additional > > uses of AIBs"? > > > > Well, although REFER-instigated INVITEs might not be a > special case as such, > most would probably say that 3PCC is a special case. But > still, we need a > section title that accommodates both, so I think that's fair; > a better title > for this section is probably in order. I think we need > something with the > sense "Use of AIBs to express the identity of someone other > than the sender > of the INVITE". I'll try to figure out a way to compress that to > header-size. > > > - Section 10 (Security Considerations): The first sentence needs to > > be scoped to the section 2 use of AIBs, not all uses of AIBs with > > message/sipfrag in them. > > > > Okay, fine. > > > - Spelling Nits: > > * Second sentence, last paragraph Page 4: > > s/SHOULD be added it to/SHOULD be added to/ > > * Second sentence, last paragraph, section 4, Page 6: > > s/harder to correlated an AIB/harder to correlate an AIB/ > > > > Thanks, I'll take care of all of those. > > > Other than that, I believe this document is ready to go. > > > > RjS > > > > On Tue, 2003-05-13 at 19:39, Rohan Mahy wrote: > > > Hello Everyone, > > > > > > I would like to begin Working Group Last Call on > > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-sip-authid-body-01.txt > > > > > > WGLC will end on Friday, June 13, 2003. > > > > > > 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 15 07:26:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28553 for ; Sun, 15 Jun 2003 07:26:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5FBQCv25339 for sip-archive@odin.ietf.org; Sun, 15 Jun 2003 07:26:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5F8f3a16931; Sun, 15 Jun 2003 04:41:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5F8ewm16918 for ; Sun, 15 Jun 2003 04:40:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26218 for ; Sun, 15 Jun 2003 04:40:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RT2D-0002Y6-00 for sip@ietf.org; Sun, 15 Jun 2003 04:38:45 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19RT2C-0002Y3-00 for sip@ietf.org; Sun, 15 Jun 2003 04:38:44 -0400 Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5F8etG5020967 for ; Sun, 15 Jun 2003 10:40:55 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP8FT1G; Sun, 15 Jun 2003 10:41:07 +0200 Received: from lmf.ericsson.se (sealwp01-12.sw.ericsson.se [153.88.142.12]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h5F8edB8003123 for ; Sun, 15 Jun 2003 11:40:40 +0300 (EET DST) Message-ID: <3EEC310D.50686502@lmf.ericsson.se> Date: Sun, 15 Jun 2003 11:40:45 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] TEST - 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: , Content-Transfer-Encoding: 7bit TESTING the mailing list. Please ignore. 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 Jun 15 07:53:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28862 for ; Sun, 15 Jun 2003 07:53:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5FBqVN26845 for sip-archive@odin.ietf.org; Sun, 15 Jun 2003 07:52:31 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5F9E5a18597; Sun, 15 Jun 2003 05:14:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5F9D1m18550 for ; Sun, 15 Jun 2003 05:13:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26774 for ; Sun, 15 Jun 2003 05:12:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RTXC-0002gG-00 for sip@ietf.org; Sun, 15 Jun 2003 05:10:47 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19RTXC-0002gD-00 for sip@ietf.org; Sun, 15 Jun 2003 05:10:46 -0400 Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5F9Dkcv023175 for ; Sun, 15 Jun 2003 11:13:46 +0200 Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYPWPJH; Sun, 15 Jun 2003 11:14:18 +0200 Received: from lmf.ericsson.se (sealwp01-12.sw.ericsson.se [153.88.142.12]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h5F9CgB8004565 for ; Sun, 15 Jun 2003 12:12:42 +0300 (EET DST) Message-ID: <3EEC388E.B0BBEE36@lmf.ericsson.se> Date: Sun, 15 Jun 2003 12:12:46 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] TEST II - 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: , Content-Transfer-Encoding: 7bit TESTING the mailing list. Please ignore. 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 Jun 16 01:15:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19671 for ; Mon, 16 Jun 2003 01:15:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5G5EaR22976 for sip-archive@odin.ietf.org; Mon, 16 Jun 2003 01:14:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G2L3a12580; Sun, 15 Jun 2003 22:21:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G2KNm12564 for ; Sun, 15 Jun 2003 22:20:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17032 for ; Sun, 15 Jun 2003 22:20:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RjZP-0006Y2-00 for sip@ietf.org; Sun, 15 Jun 2003 22:18:07 -0400 Received: from david.siemens.com.cn ([194.138.202.3]) by ietf-mx with esmtp (Exim 4.12) id 19RjZN-0006Xz-00 for sip@ietf.org; Sun, 15 Jun 2003 22:18:06 -0400 X-Envelope-Sender-Is: zaifeng.chen@BISC.SIEMENS.COM.CN (at relayer david.siemens.com.cn) Received: from ns.siemens.com.cn (ns.siemens.com.cn [194.138.237.52]) by david.siemens.com.cn (8.11.6/8.11.6) with ESMTP id h5G2KpD15691 for ; Mon, 16 Jun 2003 10:20:51 +0800 (CST) Received: from pekw096e.cn001.siemens.net (pekw096e.cn001.siemens.net [140.231.51.134]) by ns.siemens.com.cn (8.11.7/8.11.7) with ESMTP id h5G2KF523431 for ; Mon, 16 Jun 2003 10:20:16 +0800 (CST) Received: by pekw096e with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Jun 2003 10:20:15 +0800 Message-ID: <23BCA2174A77D111A52D00A0C967A6E2042016D2@HP5> From: "Chen Zaifeng,BISC R&D SA(BJ)" To: "'sip@ietf.org'" Date: Mon, 16 Jun 2003 09:40:32 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Complex status info transfer in SIP presence service Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Dear All: I have questions about SIP based presence service: 1. If a Registar is used to be a source of original presence info, how to transfer complex or multiple status info (not only Online and Offline), e.g. Busy, Idle, No Disturb, from Presentity to Registar? Can these status info be contained in an extension parameter of Contact header of Register message? 2. How about the solution that no Registar is used and Presentity push presence info directly to Presence Server by sending of NOTIFY message? Any of your ideas or answers will be highly appreciated! Thanks! Sincerely yours, Chen Zaifeng -------------------------------------------------------------------------- Beijing International Switching System Corporation Ltd. TD/DEW No. 14 Jiu Xian Qiao Road Beijing 100016, P. R. China Tel: +86-10-8457 1921 Fax: +86-10-6436 7732 E-mail: _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 16 01:26:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19906 for ; Mon, 16 Jun 2003 01:26:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5G5QBw23259 for sip-archive@odin.ietf.org; Mon, 16 Jun 2003 01:26:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G1m3a10782; Sun, 15 Jun 2003 21:48:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G1lCm10691 for ; Sun, 15 Jun 2003 21:47:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16457 for ; Sun, 15 Jun 2003 21:47:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Rj3I-0006QF-00 for sip@ietf.org; Sun, 15 Jun 2003 21:44:56 -0400 Received: from david.siemens.com.cn ([194.138.202.3]) by ietf-mx with esmtp (Exim 4.12) id 19Rj3H-0006QC-00 for sip@ietf.org; Sun, 15 Jun 2003 21:44:55 -0400 X-Envelope-Sender-Is: zaifeng.chen@BISC.SIEMENS.COM.CN (at relayer david.siemens.com.cn) Received: from ns.siemens.com.cn (ns.siemens.com.cn [194.138.237.52]) by david.siemens.com.cn (8.11.6/8.11.6) with ESMTP id h5G1lXD10832; Mon, 16 Jun 2003 09:47:33 +0800 (CST) Received: from pekw096e.cn001.siemens.net (pekw096e.cn001.siemens.net [140.231.51.134]) by ns.siemens.com.cn (8.11.7/8.11.7) with ESMTP id h5G1kr517427; Mon, 16 Jun 2003 09:46:53 +0800 (CST) Received: by pekw096e with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Jun 2003 09:46:53 +0800 Message-ID: <23BCA2174A77D111A52D00A0C967A6E2042016D1@HP5> From: "Chen Zaifeng,BISC R&D SA(BJ)" To: "'sip@ietf.org'" Cc: "'Jonathan Rosenberg'" Date: Mon, 16 Jun 2003 09:18:30 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Never can a proxy modify SIP message 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: , Dear All: I found two statements in rfc3261 which seem to conflict each other: 1. In page 23, in the definition of "Proxy, Proxy Server", it says that "A proxy interprets, and, if necessary, rewrites specific parts of a request message before forwarding it." 2. In page 100, under the title of "1. Copy request", it says that "The proxy MUST NOT add to, modify, or remove the message body." On the other hand, there are scenarios that need a proxy to modify a SIP message body, e.g. for SIP<-->PSTN/ISDN calls, it is dangerous to delivery ISUP MIME content encapsulated in SIP message body to SIP user client, or receive such ISUP content from SIP user client (in such cases the ISUP content might be mostly for malicious usage) and forward it to somewhere like SIP-PSTN gateways, then a proxy might have to screen/remove ISUP MIME content encapsulated in SIP message body. Any of your ideas or clarifications to my puzzles are highly appreciated. Thanks! Sincerely yours, Chen Zaifeng -------------------------------------------------------------------------- Beijing International Switching System Corporation Ltd. TD/DEW No. 14 Jiu Xian Qiao Road Beijing 100016, P. R. China Tel: +86-10-8457 1921 Fax: +86-10-6436 7732 E-mail: _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Jun 16 10:07:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14643 for ; Mon, 16 Jun 2003 10:07:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5GE7DK05296 for sip-archive@odin.ietf.org; Mon, 16 Jun 2003 10:07:13 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G9F3a18265; Mon, 16 Jun 2003 05:15:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G9Ecm18241 for ; Mon, 16 Jun 2003 05:14:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06090 for ; Mon, 16 Jun 2003 05:14:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Rq2I-0000tq-00 for sip@ietf.org; Mon, 16 Jun 2003 05:12:22 -0400 Received: from pine.neustar.com ([209.173.57.70]) by ietf-mx with esmtp (Exim 4.12) id 19Rq2I-0000tn-00 for sip@ietf.org; Mon, 16 Jun 2003 05:12:22 -0400 Received: from chiimc01.npac.com ([10.32.90.4]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id h5G9DkN10367; Mon, 16 Jun 2003 09:13:47 GMT Received: by CHIIMC01 with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Jun 2003 04:16:28 -0500 Message-ID: <0449D80A0E9B614A83FA9031B07E8D3B257B40@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Chen Zaifeng,BISC R&D SA(BJ)'" , "'sip@ietf.org'" Subject: RE: [Sip] Never can a proxy modify SIP message body? Date: Mon, 16 Jun 2003 04:14:15 -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: , Some notes below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Chen Zaifeng,BISC R&D SA(BJ) > [mailto:zaifeng.chen@bisc.siemens.com.cn] > Sent: Sunday, June 15, 2003 6:19 PM > To: 'sip@ietf.org' > Cc: 'Jonathan Rosenberg' > Subject: [Sip] Never can a proxy modify SIP message body? > > > Dear All: > I found two statements in rfc3261 which seem to conflict each other: > 1. In page 23, in the definition of "Proxy, Proxy Server", it > says that "A proxy interprets, and, if necessary, rewrites > specific parts of a request message before forwarding it." > 2. In page 100, under the title of "1. Copy request", it says > that "The proxy MUST NOT add to, modify, or remove the > message body." > I don't believe these conflict with one another. The first says that a proxy can rewrite "specific parts" of a request message. Those "specific parts" do not include the message body. The rules for proxy processing make it quite clear, I think, which parts proxy servers operate on. > On the other hand, there are scenarios that need a proxy to > modify a SIP message body, e.g. for SIP<-->PSTN/ISDN > calls, it is dangerous to delivery ISUP MIME content > encapsulated in SIP message body to SIP user client, or receive > such ISUP content from SIP user client (in such cases the > ISUP content might be mostly for malicious usage) and > forward it to somewhere like SIP-PSTN gateways, then a proxy > might have to screen/remove ISUP MIME content > encapsulated in SIP message body. > At the risk of rehashing old issues, I agree that there are risks associated with the dissemination of RFC3204 ISUP MIME bodies. However, there are alternatives to mitigating these risks by violating the operational guidelines for proxy servers. For example, S/MIME, which is mandatory-to-implement for user agents that support SIP-T, can be used both to encrypt ISUP MIME bodies (so these bodies cannot be inspected by any old UAS) and to sign ISUP MIME bodies (so that a recipient can verify that the ISUP was not created by any old UAC). I believe it is more secure, overall, to manage these constraints with cryptography than it is to deploy "screening" proxy servers that are not RFC3261-compliant. > Any of your ideas or clarifications to my puzzles are highly > appreciated. Thanks! > > Sincerely yours, > Chen Zaifeng > -------------------------------------------------------------- > ------------ > Beijing International Switching System Corporation Ltd. > TD/DEW > No. 14 Jiu Xian Qiao Road > Beijing 100016, P. R. China > Tel: +86-10-8457 1921 > Fax: +86-10-6436 7732 > E-mail: > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Jun 16 15:37:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27771 for ; Mon, 16 Jun 2003 15:37:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5GJbO929725 for sip-archive@odin.ietf.org; Mon, 16 Jun 2003 15:37:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GCQ3a30561; Mon, 16 Jun 2003 08:26:03 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GCPUm30541 for ; Mon, 16 Jun 2003 08:25:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10136 for ; Mon, 16 Jun 2003 08:25:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Rt10-0001ig-00 for sip@ietf.org; Mon, 16 Jun 2003 08:23:14 -0400 Received: from mail.xl.com ([208.236.123.100] helo=exch01.Corp.xl.com) by ietf-mx with esmtp (Exim 4.12) id 19Rt10-0001gk-00 for sip@ietf.org; Mon, 16 Jun 2003 08:23:14 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Never can a proxy modify SIP message body? X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 16 Jun 2003 08:26:39 -0400 Message-ID: <656BE56E7D48F6419054CC1C8111492720CB0D@exch01.corp.xl.com> Thread-Topic: [Sip] Never can a proxy modify SIP message body? Thread-Index: AcMzzqjljHU2C1RiSwGfZK+hypdJogAMjoBA From: "Jain, Rajnish" To: "Chen Zaifeng,BISC R&D SA(BJ)" , Cc: "Jonathan Rosenberg" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5GCPVm30543 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 ISUP encapsulation w/in SIP is relevant to PSTN backhaul over an intermediary SIP network (not the other way round) such as the following: PSTN <-----> SIP Network <-----> PSTN The PSTN/SIP gateways at the two ends here are UAs. The SIP network in the middle is perhaps comprised of a chain of proxy servers. Your requirements may lead you to a B2BUA approach which are entitled to do anything to the SIP messages at their discretion. - Rajnish -----Original Message----- From: Chen Zaifeng,BISC R&D SA(BJ) [mailto:zaifeng.chen@BISC.SIEMENS.COM.CN] Sent: Sunday, June 15, 2003 9:19 PM To: 'sip@ietf.org' Cc: 'Jonathan Rosenberg' Subject: [Sip] Never can a proxy modify SIP message body? Dear All: I found two statements in rfc3261 which seem to conflict each other: 1. In page 23, in the definition of "Proxy, Proxy Server", it says that "A proxy interprets, and, if necessary, rewrites specific parts of a request message before forwarding it." 2. In page 100, under the title of "1. Copy request", it says that "The proxy MUST NOT add to, modify, or remove the message body." On the other hand, there are scenarios that need a proxy to modify a SIP message body, e.g. for SIP<-->PSTN/ISDN calls, it is dangerous to delivery ISUP MIME content encapsulated in SIP message body to SIP user client, or receive such ISUP content from SIP user client (in such cases the ISUP content might be mostly for malicious usage) and forward it to somewhere like SIP-PSTN gateways, then a proxy might have to screen/remove ISUP MIME content encapsulated in SIP message body. Any of your ideas or clarifications to my puzzles are highly appreciated. Thanks! Sincerely yours, Chen Zaifeng -------------------------------------------------------------------------- Beijing International Switching System Corporation Ltd. TD/DEW No. 14 Jiu Xian Qiao Road Beijing 100016, P. R. China Tel: +86-10-8457 1921 Fax: +86-10-6436 7732 E-mail: _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Jun 16 21:51:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12364 for ; Mon, 16 Jun 2003 21:51:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5H1oqi24700 for sip-archive@odin.ietf.org; Mon, 16 Jun 2003 21:50:52 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GFS4a11563; Mon, 16 Jun 2003 11:28:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GFRfm11542 for ; Mon, 16 Jun 2003 11:27:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17845 for ; Mon, 16 Jun 2003 11:27:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RvrJ-0003MD-00 for sip@ietf.org; Mon, 16 Jun 2003 11:25:25 -0400 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by ietf-mx with esmtp (Exim 4.12) id 19RvrI-0003M4-00 for sip@ietf.org; Mon, 16 Jun 2003 11:25:24 -0400 Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HGK00J8RYRHOM@firewall.wcom.com> for sip@ietf.org; Mon, 16 Jun 2003 15:23:41 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HGK00A01YLCA0@pmismtp03.wcomnet.com>; Mon, 16 Jun 2003 15:23:41 +0000 (GMT) Received: from hsinnreich2 ([166.35.136.36]) by pmismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HGK00A5KYOYGP@pmismtp03.wcomnet.com>; Mon, 16 Jun 2003 15:22:11 +0000 (GMT) Date: Mon, 16 Jun 2003 10:22:10 -0500 From: Henry Sinnreich Subject: RE: [Sip] Complex status info transfer in SIP presence service In-reply-to: <23BCA2174A77D111A52D00A0C967A6E2042016D2@HP5> To: "'Chen Zaifeng,BISC R&D SA(BJ)'" , sip@ietf.org Message-id: <000001c3341b$0f0ac030$248823a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 see the I-D at the ietf.org archive. Henry Henry Sinnreich MCI 400 International Parkway Richardson, Texas 75081 USA > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Chen Zaifeng,BISC R&D SA(BJ) > Sent: Sunday, June 15, 2003 8:41 PM > To: 'sip@ietf.org' > Subject: [Sip] Complex status info transfer in SIP presence service > > > Dear All: > I have questions about SIP based presence service: > > 1. If a Registar is used to be a source of original presence > info, how to transfer complex or multiple status > info (not only Online and Offline), e.g. Busy, Idle, No > Disturb, from Presentity to Registar? Can these > status info be contained in an extension parameter of > Contact header of Register message? 2. How about the solution > that no Registar is used and Presentity push presence info > directly to Presence > Server by sending of NOTIFY message? > > Any of your ideas or answers will be highly appreciated! Thanks! > > Sincerely yours, > Chen Zaifeng > -------------------------------------------------------------- > ------------ > Beijing International Switching System Corporation Ltd. > TD/DEW > No. 14 Jiu Xian Qiao Road > Beijing 100016, P. R. China > Tel: +86-10-8457 1921 > Fax: +86-10-6436 7732 > E-mail: > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Jun 16 23:28:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14856 for ; Mon, 16 Jun 2003 23:28:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5H3SS331552 for sip-archive@odin.ietf.org; Mon, 16 Jun 2003 23:28:28 -0400 Received: from www1.ietf.org (a.mx.viagraonlinenow.biz [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GJ14a26805; Mon, 16 Jun 2003 15:01:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GJ0Bm26744 for ; Mon, 16 Jun 2003 15:00:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25478 for ; Mon, 16 Jun 2003 15:00:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RzAu-0005FR-00 for sip@ietf.org; Mon, 16 Jun 2003 14:57:52 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 19RzAt-0005FA-00 for sip@ietf.org; Mon, 16 Jun 2003 14:57:51 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5GIxDT11962; Mon, 16 Jun 2003 14:59:14 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NAMN084Z; Mon, 16 Jun 2003 14:59:14 -0400 Received: from nortelnetworks.com (acart1bd.ca.nortel.com [47.129.129.23]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA042X; Mon, 16 Jun 2003 14:59:14 -0400 Message-ID: <3EEE1379.507@nortelnetworks.com> Date: Mon, 16 Jun 2003 14:59:05 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: "Chen Zaifeng,BISC R&D SA(BJ)" CC: "'sip@ietf.org'" Subject: Re: [Sip] Never can a proxy modify SIP message body? References: <23BCA2174A77D111A52D00A0C967A6E2042016D1@HP5> In-Reply-To: <23BCA2174A77D111A52D00A0C967A6E2042016D1@HP5> 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 two possibilities here: the SIP UA can legitimately send encapsulated ISUP to the network, but that ISUP has to be checked for valid and legitimate content, or the SIP UA has no right to send encapsulated ISUP. In the first case, you need a UA to do the checking. This can be a B2BUA or a SIP-to-ISUP gateway, with the former being the more likely solution. If the SIP UA has no right to send encapsulated ISUP, a proxy can reject the message on the basis of the Content-Type header field. Chen Zaifeng,BISC R&D SA(BJ) wrote: > Dear All: > I found two statements in rfc3261 which seem to conflict each other: > 1. In page 23, in the definition of "Proxy, Proxy Server", it says that "A proxy interprets, and, if necessary, rewrites > specific parts of a request message before forwarding it." > 2. In page 100, under the title of "1. Copy request", it says that "The proxy MUST NOT add to, modify, or remove the > message body." > > On the other hand, there are scenarios that need a proxy to modify a SIP message body, e.g. for SIP<-->PSTN/ISDN > calls, it is dangerous to delivery ISUP MIME content encapsulated in SIP message body to SIP user client, or receive > such ISUP content from SIP user client (in such cases the ISUP content might be mostly for malicious usage) and > forward it to somewhere like SIP-PSTN gateways, then a proxy might have to screen/remove ISUP MIME content > encapsulated in SIP message body. > > Any of your ideas or clarifications to my puzzles are highly appreciated. Thanks! > > Sincerely yours, > Chen Zaifeng > -------------------------------------------------------------------------- > Beijing International Switching System Corporation Ltd. > TD/DEW > No. 14 Jiu Xian Qiao Road > Beijing 100016, P. R. China > Tel: +86-10-8457 1921 > Fax: +86-10-6436 7732 > E-mail: > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Jun 17 14:20:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00479 for ; Tue, 17 Jun 2003 14:20:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HIJn614497 for sip-archive@odin.ietf.org; Tue, 17 Jun 2003 14:19:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HDA4a27123; Tue, 17 Jun 2003 09:10:04 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HD9qm27097 for ; Tue, 17 Jun 2003 09:09:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13002 for ; Tue, 17 Jun 2003 09:09:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SGBR-0006Nm-00 for sip@ietf.org; Tue, 17 Jun 2003 09:07:33 -0400 Received: from em.njupt.edu.cn ([202.119.230.11]) by ietf-mx with smtp (Exim 4.12) id 19SGBP-0006Nh-00 for sip@ietf.org; Tue, 17 Jun 2003 09:07:32 -0400 Received: (qmail 32326 invoked from network); 17 Jun 2003 13:01:49 -0000 Received: from unknown (HELO toto) (10.10.3.123) by em.njupt.edu.cn with SMTP; 17 Jun 2003 13:01:49 -0000 Date: Tue, 17 Jun 2003 21:10:3 +0800 From: FengZhang Reply-To: y01317@njupt.edu.cn To: "sip@ietf.org" Organization: NUPT X-mailer: FoxMail 4.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h5HD9qm27098 Subject: [Sip] Bug? Matching rules of Server Transaction Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit sipHi all, When I fulfill "Call pickup" service , I meet a problem about Server Transaction matching rules. As RFC3261 says in section 17.2.3: The branch parameter in the topmost Via header field of the request is examined. If it is present and begins with the magic cookie "z9hG4bK", the request was generated by a client transaction compliant to this specification. Therefore, the branch parameter will be unique across all transactions sent by that client. The request matches a transaction if: 1. the branch parameter in the request is equal to the one in the top Via header field of the request that created the transaction, and 2. the sent-by value in the top Via of the request is equal to the one in the request that created the transaction, and 3. the method of the request matches the one that created the transaction, except for ACK, where the method of the request that created the transaction is INVITE. This matching rule applies to both INVITE and non-INVITE transactions alike. So, if the notifier notifies subscriber the resources state in two NOTIFY messages, as below: notifier subscriber | ............ | |-------NOTIFY (F1)----------->| |<------200 OK (F2)------------| | | the interval is less Timer J, J does not fire yet. | | |-------NOTIFY (F3)----------->| |<------200 OK (F4)------------| | | the message is : NOTIFY sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP Bob.biloxi.example.com:5060;branch=z9hG4bK74bf Max-Forwards: 70 From: Bob ;tag=31451098 To: Carol ;tag=8675309 Call-ID: rt4353gs2egg@pc.biloxi.example.com CSeq: 1 NOTIFY Contact: Event: dialog Subscription-State: active;expires=3600 Content-Type: application/dialog-info+xml Content-Length: ... NOTIFY sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP Bob.biloxi.example.com:5060;branch=z9hG4bK74bf Max-Forwards: 70 From: Bob ;tag=31451098 To: Carol ;tag=8675309 Call-ID: rt4353gs2egg@pc.biloxi.example.com CSeq: 2 NOTIFY Contact: Event: dialog Subscription-State: active;expires=3600 Content-Type: application/dialog-info+xml Content-Length: ... Notice that the two NOTIFY have the SAME branch & the magic cookie "z9hG4bK", using the matching rules in 17.2.3, all the three rules MATCH! So I can judge F3 belongs to the same transaction which created by F1, because timer J does not fire, and F2 is sent to response F1 , as per 17.2.2 of RFC3261, when F3 comes, I will think F3 is the retransmision of F2! But they are not the same indeed: different CSeq and report different resource's state! Maybe I missing somthing, but I'm really puzzled . Thanks a lot to clarify! _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Jun 18 10:06:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08071 for ; Wed, 18 Jun 2003 10:06:25 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IE5ws10114 for sip-archive@odin.ietf.org; Wed, 18 Jun 2003 10:05:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SdBP-0001Jz-1C; Wed, 18 Jun 2003 09:41:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sd4q-0000mp-Mf for sip@optimus.ietf.org; Wed, 18 Jun 2003 09:34:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06248 for ; Wed, 18 Jun 2003 09:34:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sd2a-0004eY-00 for sip@ietf.org; Wed, 18 Jun 2003 09:31:56 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19Sd2Z-0004eE-00 for sip@ietf.org; Wed, 18 Jun 2003 09:31:55 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h5IDXhi20550 for ; Wed, 18 Jun 2003 08:33:43 -0500 From: Robert Sparks To: sip@ietf.org Content-Type: text/plain Message-Id: <1055943222.923.17.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 18 Jun 2003 08:33:43 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Referredby revision Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I've just submitted http://www.nostrum.com/~rjsparks/draft-ietf-sip-referredby-02.txt to the repository. I believe this document is ready for last call. 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 exim@www1.ietf.org Wed Jun 18 10:33:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09886 for ; Wed, 18 Jun 2003 10:33:01 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IEWYg14897 for sip-archive@odin.ietf.org; Wed, 18 Jun 2003 10:32:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SdVh-0002Dp-VT; Wed, 18 Jun 2003 10:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SdBM-0001Jf-CQ for sip@optimus.ietf.org; Wed, 18 Jun 2003 09:41:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06527 for ; Wed, 18 Jun 2003 09:40:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sd8H-0004iA-00 for sip@ietf.org; Wed, 18 Jun 2003 09:37:49 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19Sd8G-0004h1-00 for sip@ietf.org; Wed, 18 Jun 2003 09:37:48 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h5IDdGi20624; Wed, 18 Jun 2003 08:39:21 -0500 Subject: RE: [Sip] RE: Use of AIB in referredby From: Robert Sparks To: Mary Barnes Cc: "'Peterson, Jon'" , sip@ietf.org In-Reply-To: <870397D7C140C84DB081B88396458DAF5789D6@zrc2c000.us.nortel.com> References: <870397D7C140C84DB081B88396458DAF5789D6@zrc2c000.us.nortel.com> Content-Type: text/plain Message-Id: <1055943555.923.24.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 18 Jun 2003 08:39:16 -0500 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 It turns out that we already have an identifier that distinguishes the AIB used for the refer token - it is called out explicitly by the cid parameter to the Referred-By header field itself. A consumer won't be scanning all the AIBs in a message wondering which one is the referred-by token. So, I left it as 'aib' in referred-by-02. RjS On Fri, 2003-06-13 at 10:58, Mary Barnes wrote: > My general preference is to be more explicit and towards that end I would > think a different Content-Disposition disposition-type could be useful. > That said, if AIB were as general as Robert suggested initially, then it > could possibly be reused even for the Inserted headers (like History-Info), > where I'm currently modeling the solution after AIB, but was planning on a > new Content-Disposition disposition-type. However, even I would agree that > the Inserted Headers are more different than the original intent of AIB than > the Referred-by use and again I do prefer to be more explicit. > > Mary. > > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Friday, June 13, 2003 2:17 AM > To: 'Robert Sparks'; sip@ietf.org > Subject: [Sip] RE: Use of AIB in referredby > > > > I look at the AIB as the application of sipfrags to the problem described in > RFC3261 23.4 - the tunneling of integrity and authentication properties > within the MIME bodies of SIP messages. In the AIB, these properties are > intended to provide identity, hence the name 'authenticated identity body'. > I think that the usage in referredby is sufficiently close to that purpose, > providing authenticated identity within a body, that I don't think we have a > problem with reuse of the term. > > The real question, I think, is whether or not there is any value in > differentiating an AIB resulting from a REFER from any other AIB (such as a > 'normal' one representing the sender of an INVITE) that might be in a > request. Surely these need to be differentiated somehow - the signature on > the AIB itself would be one indicator, as would the headers in the body, but > Content-Disposition is another point at which the two could be > distinguished. > > I don't have a strong intuition about whether or not the use of a different > Content-Disposition would be valuable. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > Sent: Monday, June 09, 2003 1:00 PM > > To: sip@ietf.org > > Cc: Jon Peterson > > Subject: Use of AIB in referredby > > > > > > Several weeks ago, Pekka made a suggestion that I would like to > > follow up on now (sorry for the very long delay Pekka). His > > suggestion was to use a different Content-Disposition > > disposition-type for referredby-tokens. > > > > This draws attention to what the "aib" value means. > > > > Is it merely a synonym for "signed message/sipfrag"? If so, the > > authid-body draft defines the value _and_ specifies one particular > > use of a body with that disposition type (providing integrity and > > authentication of sender for a single message). Other uses are valid, > > so we should reuse it and not add noise to the IANA registry. > > > > If, instead, "aib" means "signed message/sipfrag with these > > particular security implications", then our referredby token > > is _not_ an aib. It's something _like_ an aib, but with > > slightly different requirements, and artifacts in the protocol > > (like the disposition-type) should probably reflect that. If this > > is the case, referredby could register something like "RBIB" > > (ReferredBy Identity Body), or, treading much more dangerous ground, > > "TPIB" (Third Party Identity Body). > > > > So, which of the above meanings for AIB is auth-id body establishing? > > > > 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 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 exim@www1.ietf.org Wed Jun 18 13:36:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17561 for ; Wed, 18 Jun 2003 13:36:13 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IHZic17348 for sip-archive@odin.ietf.org; Wed, 18 Jun 2003 13:35:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SgPi-0003JY-6L; Wed, 18 Jun 2003 13:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SfXA-0000yw-9t for sip@optimus.ietf.org; Wed, 18 Jun 2003 12:11:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14648 for ; Wed, 18 Jun 2003 12:11:37 -0400 (EDT) From: x.chen@fle.fujitsu.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SfUu-0006Js-00 for sip@ietf.org; Wed, 18 Jun 2003 12:09:20 -0400 Received: from [193.122.18.249] (helo=emily.fle.fujitsu.com) by ietf-mx with smtp (Exim 4.12) id 19SfUt-0006Jp-00 for sip@ietf.org; Wed, 18 Jun 2003 12:09:19 -0400 Received: from 10.142.50.249 by emily.fle.fujitsu.com (InterScan E-Mail VirusWall NT); Wed, 18 Jun 2003 17:01:09 +0100 Received: by fle2.fle.fujitsu.com with Internet Mail Service (5.5.2656.59) id ; Wed, 18 Jun 2003 17:04:01 +0100 Message-ID: To: sip@ietf.org Date: Wed, 18 Jun 2003 17:03:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-4202d687-5243-403b-9254-e32580fe6dcc" Subject: [Sip] SLP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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. ------=_NextPartTM-000-4202d687-5243-403b-9254-e32580fe6dcc Content-Type: text/plain Hi all, Sorry to use this list for SLP. SIP server can be located by using SLP (service location protocol), is there any mailing list for SLP related topic? I tried srvloc-request@srvloc.org, but failed. Is this list still operating or using another one instead? Thanks Xin Chen Fujitsu Laboratories of Europe ------=_NextPartTM-000-4202d687-5243-403b-9254-e32580fe6dcc Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit This e-mail has been scanned by Trend InterScan Software. This e-mail (and its attachment(s) if any) is intended for the named addressee(s) only. It may contain information which is privileged and confidential within the meaning of the applicable law. Unauthorised use, copying or disclosure is strictly prohibited and may be unlawful. If you are not the intended recipient please delete this email and contact the sender via email return. Fujitsu Laboratories of Europe Ltd (FLE) does not accept responsibility for changes made to this email after it was sent. The views expressed in this email may not necessarily be the views held by FLE. Unless expressly stated otherwise, this email does not form part of a legally binding contract or agreement between the recipient and Fujitsu Laboratories of Europe Ltd (FLE). ------=_NextPartTM-000-4202d687-5243-403b-9254-e32580fe6dcc-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jun 19 00:38:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15319 for ; Thu, 19 Jun 2003 00:38:56 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5J4cTV24085 for sip-archive@odin.ietf.org; Thu, 19 Jun 2003 00:38:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SqpC-0005CB-4H; Thu, 19 Jun 2003 00:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SqWm-0004My-8Q for sip@optimus.ietf.org; Wed, 18 Jun 2003 23:56:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13839 for ; Wed, 18 Jun 2003 23:55:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SqUV-0005u1-00 for sip@ietf.org; Wed, 18 Jun 2003 23:53:39 -0400 Received: from [203.196.146.242] (helo=Mistralsoftware.com) by ietf-mx with esmtp (Exim 4.12) id 19SqUT-0005tW-00 for sip@ietf.org; Wed, 18 Jun 2003 23:53:38 -0400 Received: from gauthamL ([192.168.11.26]) by mistralsoftware.com ([192.168.10.12]) with SMTP (MDaemon.PRO.v6.7.9.R) for ; Thu, 19 Jun 2003 09:31:08 +0530 Date: Thu, 19 Jun 2003 09:35:01 +0530 From: "A. N. Gautham" To: y01317@njupt.edu.cn Cc: sip@ietf.org Subject: Re: [Sip] Bug? Matching rules of Server Transaction Message-Id: <20030619093501.715009c9.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, If an entity inserts a branch parameter that begins with the magic cookie, then it is 3261 compliant. In 3261, the branch parameter has to be unique. As given in Section 8.1.1.7 of 3261, " The branch parameter value MUST be unique across space and time for all requests sent by the UA. The exceptions to this rule are CANCEL and ACK for non-2xx responses." Thus, the two NOTIFY requests (F1) and (F3) MUST have different branch parameters since they belong to different transactions. Since this has not been followed by the 'notifier', you are finding that F3 gets treated as a retransmission of F1. Hope this helps -Gautham. On Tue, 17 Jun 2003 21:10:3 +0800 FengZhang wrote: > sipHi all, > > When I fulfill "Call pickup" service , I meet a problem about Server Transaction matching rules. As RFC3261 says in section 17.2.3: > > The branch parameter in the topmost Via header field of the request > is examined. If it is present and begins with the magic cookie > "z9hG4bK", the request was generated by a client transaction > compliant to this specification. Therefore, the branch parameter > will be unique across all transactions sent by that client. The > request matches a transaction if: > > 1. the branch parameter in the request is equal to the one in the > top Via header field of the request that created the > transaction, and > > 2. the sent-by value in the top Via of the request is equal to the > one in the request that created the transaction, and > > 3. the method of the request matches the one that created the > transaction, except for ACK, where the method of the request > that created the transaction is INVITE. > > This matching rule applies to both INVITE and non-INVITE transactions > alike. > > > So, if the notifier notifies subscriber the resources state in two NOTIFY messages, as below: > > notifier subscriber > | ............ | > |-------NOTIFY (F1)----------->| > |<------200 OK (F2)------------| > | | the interval is less Timer J, J does not fire yet. > | | > |-------NOTIFY (F3)----------->| > |<------200 OK (F4)------------| > | | > > the message is : > > > NOTIFY sip:bob@biloxi.example.com SIP/2.0 > Via: SIP/2.0/UDP Bob.biloxi.example.com:5060;branch=z9hG4bK74bf > Max-Forwards: 70 > From: Bob ;tag=31451098 > To: Carol ;tag=8675309 > Call-ID: rt4353gs2egg@pc.biloxi.example.com > CSeq: 1 NOTIFY > Contact: > Event: dialog > Subscription-State: active;expires=3600 > Content-Type: application/dialog-info+xml > Content-Length: ... > > > > > > NOTIFY sip:bob@biloxi.example.com SIP/2.0 > Via: SIP/2.0/UDP Bob.biloxi.example.com:5060;branch=z9hG4bK74bf > Max-Forwards: 70 > From: Bob ;tag=31451098 > To: Carol ;tag=8675309 > Call-ID: rt4353gs2egg@pc.biloxi.example.com > CSeq: 2 NOTIFY > Contact: > Event: dialog > Subscription-State: active;expires=3600 > Content-Type: application/dialog-info+xml > Content-Length: ... > > > > Notice that the two NOTIFY have the SAME branch & the magic cookie "z9hG4bK", using the matching rules in 17.2.3, all the three rules MATCH! So I can judge F3 belongs to the same transaction which created by F1, because timer J does not fire, and F2 is sent to response F1 , as per 17.2.2 of RFC3261, when F3 comes, I will think F3 is the retransmision of F2! > But they are not the same indeed: different CSeq and report different resource's state! > > Maybe I missing somthing, but I'm really puzzled . > > Thanks a lot to clarify! > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 exim@www1.ietf.org Thu Jun 19 08:33:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13387 for ; Thu, 19 Jun 2003 08:33:21 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JCWrb18862 for sip-archive@odin.ietf.org; Thu, 19 Jun 2003 08:32:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SxyQ-0002ss-Qo; Thu, 19 Jun 2003 07:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sxdi-0001ja-BV for sip@optimus.ietf.org; Thu, 19 Jun 2003 07:31:38 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09386; Thu, 19 Jun 2003 07:31:36 -0400 (EDT) Message-Id: <200306191131.HAA09386@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 19 Jun 2003 07:31:36 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-referredby-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 : The SIP Referred-By Mechanism Author(s) : R. Sparks Filename : draft-ietf-sip-referredby-02.txt Pages : 26 Date : 2003-6-18 The SIP REFER method [2] provides a mechanism where one party (the referrer) gives a second party (the referree) an arbitrary URI to reference. If that URI is a SIP URI, the referree will send a SIP request, often an INVITE, to that URI (the refer target). This document extends the REFER method allowing the referrer to provide information about the reference to the refer target using the referree as an intermediary. This information includes the identity of the referrer and the URI to which the referrer referred. The mechanism utilizes S/MIME to help protect this information from a malicious intermediary. This protection is optional, but a recipient may refuse to accept a request unless it is present. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-referredby-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-referredby-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-referredby-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: <2003-6-18122110.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-referredby-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-referredby-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-18122110.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 exim@www1.ietf.org Thu Jun 19 12:22:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28906 for ; Thu, 19 Jun 2003 12:22:40 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JGMDN13994 for sip-archive@odin.ietf.org; Thu, 19 Jun 2003 12:22:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T2Ak-0003cy-0I; Thu, 19 Jun 2003 12:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T29u-0003UR-Or for sip@optimus.ietf.org; Thu, 19 Jun 2003 12:21:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28760 for ; Thu, 19 Jun 2003 12:21:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T27c-0006c0-00 for sip@ietf.org; Thu, 19 Jun 2003 12:18:48 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19T27b-0006bx-00 for sip@ietf.org; Thu, 19 Jun 2003 12:18:47 -0400 Received: from localhost ([127.0.0.1] helo=psg.com ident=mankin) by psg.com with esmtp (Exim 4.14) id 19T29q-000CDd-EG; Thu, 19 Jun 2003 16:21:06 +0000 To: jdrosen@dynamicsoft.com Cc: rohan@cisco.com, dwillis@dynamicsoft.com, sip@ietf.org, jon.peterson@neustar.biz, hardie@qualcomm.com, erik.nordmark@sun.com Reply-To: mankin@psg.com Date: Thu, 19 Jun 2003 09:21:05 -0700 From: Allison Mankin Message-Id: Subject: [Sip] IESG Discuss Comments on Symmetric Response Routing Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 reviewed draft-ietf-sip-symmetric-response-00.txt and there were two sets of Discuss comments. They do not seem too hard to address. In addition, the FQDNs in the draft need to be changed to example.com. Below are the comments. They are also in the ID tracker. Allison Comments: Ted Hardie: First, let me say that a large number of the issues I had with the document turned out to be very well documented in the IAB considerations section of the draft. A few other issues: In Section 3: When the client sends the request, if the request is sent using UDP, the client MUST be prepared to receive the response on the same socket the request was sent on. Specifically, it MUST be prepared to receive the response on the same IP address and port present in the source IP address and source port of the request. For backwards compatibility, the client MUST still be prepared to receive a response on the port indicated in the sent-by field of the topmost Via header field value, as specified in Section 18.1.1 of SIP [1]. It seems pretty clear from the "on the same socket" that the following sentence means the IP address and port present in the source IP and port of the request _when it is sent_. I think it would be clearer, though, to use phrasing like "it MUST be prepared to receive the response on the same IP address and port it used to populate the source IP address and source port of the request.". Also in Section 3: To keep the binding fresh, the client SHOULD retransmit its INVITE every 20 seconds or so. These retransmissions will need to take place even after receiving a provisional response. based on the idea the one minute seems to be a common UDP binding lifetime. Section 9.3 notes, however, that there is no way to determine the UDP binding lifetime. Is there anyway to introduce a growing/shrinking algorithm to this for cases where the binding lifetime is much longer (to avoid the aggressiveness of 20 seconds for an arbitrary period of time) or to handle the cases where the binding lifetime is shorter than 20+transmission time to the NAT (since this has to handle the NAT being at some arbitrary place in the topology). In the initial section of 9: The client can then perform an additional registration, using this address in a Contact header. This would allow a client to receive incoming requests, such as INVITE, on the socket through which the registration was sent. As is noted below that point, there are cases in which the port binding is only valid for the server to which the original registration was sent. Will the Contact header "leak" that so that a direction connection between a different sip agent (user or proxy) might attempt to use it? If so, a forward pointer to the limitation might be useful here. I would personally consider the UNSAF document a normative reference, but this is not a big deal. Erik Nordmark: The security considerations section doesn't set a very good example. It could easily be read as "we didn't look hard for security issues". Thus I'd like it to provide the reasoning that lead to thinking that there are no added security issues. Presumably a paragraph or two would suffice. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jun 19 14:39:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08597 for ; Thu, 19 Jun 2003 14:39:34 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JId7h22443 for sip-archive@odin.ietf.org; Thu, 19 Jun 2003 14:39:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T4JJ-0005pU-QQ; Thu, 19 Jun 2003 14:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T4IX-0005oz-CJ for sip@optimus.ietf.org; Thu, 19 Jun 2003 14:38:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08535 for ; Thu, 19 Jun 2003 14:38:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T4GD-0001FJ-00 for sip@ietf.org; Thu, 19 Jun 2003 14:35:50 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19T4GD-0001FA-00 for sip@ietf.org; Thu, 19 Jun 2003 14:35:49 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h5JIbQaZ015961; Thu, 19 Jun 2003 11:37:26 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIH59380; Thu, 19 Jun 2003 11:31:17 -0700 (PDT) Date: Thu, 19 Jun 2003 11:38:39 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: rohan@cisco.com, Jon Peterson , Dean Willis , "'Robert Sparks'" To: sip@ietf.org From: Rohan Mahy Content-Transfer-Encoding: 7bit Message-Id: <3E62FE80-A285-11D7-8E0D-0003938AF740@cisco.com> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Sip] WGLC for referred-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: 7bit Hello Everyone, I would like to begin a Working Group last call on: http://www.ietf.org/internet-drafts/draft-ietf-sip-referredby-02.txt WGLC will end on Friday July 18th. 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 exim@www1.ietf.org Thu Jun 19 15:25:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13489 for ; Thu, 19 Jun 2003 15:25:36 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JJP8I03261 for sip-archive@odin.ietf.org; Thu, 19 Jun 2003 15:25:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T51q-0000q8-Cv; Thu, 19 Jun 2003 15:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T50x-0000pS-BK for sip@optimus.ietf.org; Thu, 19 Jun 2003 15:24:07 -0400 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13407 for ; Thu, 19 Jun 2003 15:24:05 -0400 (EDT) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 19T4xK-0003o1-Jh; Thu, 19 Jun 2003 15:20:22 -0400 To: IETF-Announce :; Dcc: all-ietf Cc: sip@ietf.org From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Thu, 19 Jun 2003 15:20:22 -0400 Subject: [Sip] Last Call: A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages to a 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 Session Initiation Protocol WG to consider the following Internet-Draft(s) as a Proposed Standard. o Session Initiation Protocol (SIP): A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages 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 2003-07-03. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-content-indirect-mech-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 exim@www1.ietf.org Thu Jun 19 15:48:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15125 for ; Thu, 19 Jun 2003 15:48:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JJm7011276 for sip-archive@odin.ietf.org; Thu, 19 Jun 2003 15:48:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T5O6-0002tB-Da; Thu, 19 Jun 2003 15:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T5Nc-0002s0-Me for sip@optimus.ietf.org; Thu, 19 Jun 2003 15:47:32 -0400 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15069 for ; Thu, 19 Jun 2003 15:47:30 -0400 (EDT) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 19T5LI-0001Sx-8b; Thu, 19 Jun 2003 15:45:08 -0400 To: IETF-Announce :; Dcc: all-ietf Cc: sip@ietf.org From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Thu, 19 Jun 2003 15:45:08 -0400 Subject: [Sip] Last Call: The Stream Control Transmission Protocol as a Transport for for the Session Initiation Protocol to a 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 Session Initiation Protocol WG to consider the following Internet-Draft(s) as a Proposed Standard. o Session Initiation Protocol (SIP): The Stream Control Transmission Protocol as a Transport for for the Session Initiation Protocol 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 2003-07-03. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-sctp-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 exim@www1.ietf.org Fri Jun 20 07:35:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26454 for ; Fri, 20 Jun 2003 07:35:41 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KBZBU18373 for sip-archive@odin.ietf.org; Fri, 20 Jun 2003 07:35:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TKAZ-0004jm-T9; Fri, 20 Jun 2003 07:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TKAQ-0004ie-GB for sip@optimus.ietf.org; Fri, 20 Jun 2003 07:34:54 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26253; Fri, 20 Jun 2003 07:34:52 -0400 (EDT) Message-Id: <200306201134.HAA26253@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, 20 Jun 2003 07:34:52 -0400 Subject: [Sip] I-D ACTION:draft-camarillo-sip-parameter-registry-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. Title : The Internet Assigned Number Authority Header Field Parameter Registry for the Session Initiation Protocol Author(s) : G. Camarillo Filename : draft-camarillo-sip-parameter-registry-01.txt Pages : 6 Date : 2003-6-19 This document creates an IANA registry for SIP header field parameters. It also lists the already existing parameters to be used as initial values for that registry. . A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-camarillo-sip-parameter-registry-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-camarillo-sip-parameter-registry-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-camarillo-sip-parameter-registry-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-19154311.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-camarillo-sip-parameter-registry-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-camarillo-sip-parameter-registry-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-19154311.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 exim@www1.ietf.org Fri Jun 20 08:22:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26455 for ; Fri, 20 Jun 2003 07:35:41 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KBZBV18372 for sip-archive@odin.ietf.org; Fri, 20 Jun 2003 07:35:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TKAa-0004kH-U8; Fri, 20 Jun 2003 07:35:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TKAV-0004il-Py for sip@optimus.ietf.org; Fri, 20 Jun 2003 07:34:59 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26269; Fri, 20 Jun 2003 07:34:58 -0400 (EDT) Message-Id: <200306201134.HAA26269@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, 20 Jun 2003 07:34:58 -0400 Subject: [Sip] I-D ACTION:draft-camarillo-sip-uri-parameter-reg-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 : The Internet Assigned Number Authority Universal Resource Identifier Parameter Registry for the Session Initiation Protocol Author(s) : G. Camarillo Filename : draft-camarillo-sip-uri-parameter-reg-00.txt Pages : 5 Date : 2003-6-19 This document creates an IANA registry for SIP URI and SIPS URI parameters. It also lists the already existing parameters to be used as initial values for that registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-camarillo-sip-uri-parameter-reg-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-camarillo-sip-uri-parameter-reg-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-camarillo-sip-uri-parameter-reg-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-19154320.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-camarillo-sip-uri-parameter-reg-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-camarillo-sip-uri-parameter-reg-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-19154320.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 exim@www1.ietf.org Fri Jun 20 12:37:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16623 for ; Fri, 20 Jun 2003 12:37:37 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KGbAV10064 for sip-archive@odin.ietf.org; Fri, 20 Jun 2003 12:37:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TOso-0002bJ-Gh; Fri, 20 Jun 2003 12:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TOsl-0002Zl-AA for sip@optimus.ietf.org; Fri, 20 Jun 2003 12:36:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16596 for ; Fri, 20 Jun 2003 12:36:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TOsj-0006X3-00 for sip@ietf.org; Fri, 20 Jun 2003 12:36:57 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19TOsj-0006Wj-00 for sip@ietf.org; Fri, 20 Jun 2003 12:36:57 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5KGaEx20585; Fri, 20 Jun 2003 11:36:14 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Jun 2003 11:36:14 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF578A07@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Robert Sparks'" , sip@ietf.org Cc: Jon Peterson , Dean Willis , "'Rohan Mahy'" Subject: RE: [Sip] WGLC for referred-by Date: Fri, 20 Jun 2003 11:36:12 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , There were a couple points that I made on the list around the -01 version that don't seem to have been addressed http://www1.ietf.org/mail-archive/working-groups/sip/current/msg07955.html and I couldn't find that they had been responded to on the list in the archives: Editorial Nits: ------------------- - References: authid-body and cc-transfer need upversioning. Other items: -------------------------------------- - Section 2.3: Last paragraph: should this be a MUST (reject an otherwise well-formed request with an invalid token)? Reasonably, one should, but perhaps there are users that would still like to be able to decide themselves, thus I would suggest this be stated similar to the previous paragraph as: "The refer target SHOULD reject an otherwise well-formed request with an invalid Referred-By token (see Section 4) with a 429 error response. If the agent chooses to proceed with the request and provides any information from the Referred-By header to its user as part of processing the request, it MUST notify the user that the information was determined to be invalid." My reasoning is that it just seems that if an optional parm is mucked up (in general or from a security perspective), then following the adage of being generous in what you accept ...that whether to accept the request, provided that it is warned that it's bad, should still be up to the user. This also seems consistent with the MAYs in the previous 2 paragraphs. I do understand the reasoning that you'd want to let the Referrer know and that by allowing the request, you're actually bypassing the security put in place to keep the bad guys from mucking with the messages, but again since it's optional, it just seems that you can't make it stronger than a SHOULD. - Section 4.1: 2nd paragraph suggesting that "A target SHOULD verify the request...". I don't think this is useful since retargeting makes this check not meaningful. UNLESS, of course, you're using History-Info. With History-Info, you could verify that the Refer-To matches one of the Targeted-to-URIs (and of course, this implies that this information has all been sent securely, not mucked with by the proxies, etc.). Regards, Mary. -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com] Sent: Thursday, June 19, 2003 1:39 PM To: sip@ietf.org Cc: rohan@cisco.com; Jon Peterson; Dean Willis; 'Robert Sparks' Subject: [Sip] WGLC for referred-by Hello Everyone, I would like to begin a Working Group last call on: http://www.ietf.org/internet-drafts/draft-ietf-sip-referredby-02.txt WGLC will end on Friday July 18th. 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 exim@www1.ietf.org Fri Jun 20 15:20:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01668 for ; Fri, 20 Jun 2003 15:20:27 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KJJxe20153 for sip-archive@odin.ietf.org; Fri, 20 Jun 2003 15:19:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TRPa-0005Cn-6d; Fri, 20 Jun 2003 15:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TRPF-0005CR-5y for sip@optimus.ietf.org; Fri, 20 Jun 2003 15:18:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01262 for ; Fri, 20 Jun 2003 15:18:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TRPE-0001TI-00 for sip@ietf.org; Fri, 20 Jun 2003 15:18:40 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19TRPC-0001Rq-00 for sip@ietf.org; Fri, 20 Jun 2003 15:18:39 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h5KJHri04862; Fri, 20 Jun 2003 14:17:53 -0500 Subject: RE: [Sip] WGLC for referred-by From: Robert Sparks To: Mary Barnes Cc: sip@ietf.org, Jon Peterson , Dean Willis , "'Rohan Mahy'" In-Reply-To: <870397D7C140C84DB081B88396458DAF578A07@zrc2c000.us.nortel.com> References: <870397D7C140C84DB081B88396458DAF578A07@zrc2c000.us.nortel.com> Content-Type: text/plain Message-Id: <1056136667.936.116.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 20 Jun 2003 14:17:48 -0500 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 On Fri, 2003-06-20 at 11:36, Mary Barnes wrote: > There were a couple points that I made on the list around the -01 version > that don't seem to have been addressed > http://www1.ietf.org/mail-archive/working-groups/sip/current/msg07955.html > and I couldn't find that they had been responded to on the list in the > archives: > > Editorial Nits: > ------------------- > - References: authid-body and cc-transfer need upversioning. Hmm - I'm generating this using the xmlrefs stuff from xml2rfc and I _did_ update my copy of that content before building this doc. Something is broken. I'll fix it when I cut the version that pulls out the "changes since" section. I failed to respond to the following two points on list. This was not intentional, and I apologize. > Other items: > -------------------------------------- > - Section 2.3: Last paragraph: should this be a MUST (reject an otherwise > well-formed request with an invalid token)? Reasonably, one should, but > perhaps there are users that would still like to be able to decide > themselves, thus I would suggest this be stated similar to the previous > paragraph as: > "The refer target SHOULD reject an otherwise well-formed request with an > invalid Referred-By token (see Section 4) with a 429 error response. If the > agent chooses to proceed with the request and provides any information from > the Referred-By header to its user as part of processing the request, it > MUST notify the user that the information was determined to be invalid." > > My reasoning is that it just seems that if an optional parm is mucked up (in > general or from a security perspective), then following the adage of being > generous in what you accept ...that whether to accept the request, provided > that it is warned that it's bad, should still be up to the user. This also > seems consistent with the MAYs in the previous 2 paragraphs. I do understand > the reasoning that you'd want to let the Referrer know and that by allowing > the request, you're actually bypassing the security put in place to keep the > bad guys from mucking with the messages, but again since it's optional, it > just seems that you can't make it stronger than a SHOULD. This situation for this clause is different from the preceding MAYs. Here, you _know_ you've got something invalid, where the two earlier paragraphs deal with the case that you have data that you have no indication of its integrity one way or another. If the token is invalid, something's gone wrong and it will be sufficiently hard to tell whether that's due to attack or implementation error, that the action needs to be to return an error. Diving into this just a little more deeply: Well, you've got two classes of possible "invalidity". 1) The signature is not valid. Here, you have now way to know what got mucked with. No way to know if the failure is related to an optional parameter or something important. Clearly, this condition warrants only rejection. 2) The signature is valid, but the contents of the token don't match the request. You or I might be able to inspect the message and make an educated decision about the safety of accepting the request. Ordinary people won't have that skill. (Ordinary devices currently aren't making it easy for me to get the information I would need to make that educated decision anyhow). So, again, rejection is warranted. > > - Section 4.1: 2nd paragraph suggesting that "A target SHOULD verify the > request...". I don't think this is useful since retargeting makes this > check not meaningful. UNLESS, of course, you're using History-Info. With > History-Info, you could verify that the Refer-To matches one of the > Targeted-to-URIs (and of course, this implies that this information has all > been sent securely, not mucked with by the proxies, etc.). There is a lot of information present than just the Request-URI that can be validated. The method, requested end-to-end headers, etc. > > Regards, > Mary. > > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Thursday, June 19, 2003 1:39 PM > To: sip@ietf.org > Cc: rohan@cisco.com; Jon Peterson; Dean Willis; 'Robert Sparks' > Subject: [Sip] WGLC for referred-by > > > Hello Everyone, > > I would like to begin a Working Group last call on: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-referredby-02.txt > > WGLC will end on Friday July 18th. > > 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 exim@www1.ietf.org Fri Jun 20 16:00:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05503 for ; Fri, 20 Jun 2003 16:00:57 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KK0Tg27148 for sip-archive@odin.ietf.org; Fri, 20 Jun 2003 16:00:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TS3G-00072y-Kz; Fri, 20 Jun 2003 16:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TS2s-00071S-Na for sip@optimus.ietf.org; Fri, 20 Jun 2003 15:59:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05417 for ; Fri, 20 Jun 2003 15:59:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TS2r-0002b1-00 for sip@ietf.org; Fri, 20 Jun 2003 15:59:37 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19TS2p-0002an-00 for sip@ietf.org; Fri, 20 Jun 2003 15:59:35 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5KJwox11348; Fri, 20 Jun 2003 14:58:50 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Jun 2003 14:58:50 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF578A0A@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Robert Sparks'" Cc: sip@ietf.org, Jon Peterson , Dean Willis , "'Rohan Mahy'" Subject: RE: [Sip] WGLC for referred-by Date: Fri, 20 Jun 2003 14:58:45 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Robert, Thanks for your response; I just have a couple of final comments embedded below [MB]. Mary. -----Original Message----- From: Robert Sparks [mailto:rsparks@dynamicsoft.com] Sent: Friday, June 20, 2003 2:18 PM To: Barnes, Mary [NGC:B602:EXCH] Cc: sip@ietf.org; Jon Peterson; Dean Willis; 'Rohan Mahy' Subject: RE: [Sip] WGLC for referred-by On Fri, 2003-06-20 at 11:36, Mary Barnes wrote: > There were a couple points that I made on the list around the -01 version > that don't seem to have been addressed > http://www1.ietf.org/mail-archive/working-groups/sip/current/msg07955.html > and I couldn't find that they had been responded to on the list in the > archives: > > Editorial Nits: > ------------------- > - References: authid-body and cc-transfer need upversioning. Hmm - I'm generating this using the xmlrefs stuff from xml2rfc and I _did_ update my copy of that content before building this doc. Something is broken. I'll fix it when I cut the version that pulls out the "changes since" section. I failed to respond to the following two points on list. This was not intentional, and I apologize. > Other items: > -------------------------------------- > - Section 2.3: Last paragraph: should this be a MUST (reject an otherwise > well-formed request with an invalid token)? Reasonably, one should, but > perhaps there are users that would still like to be able to decide > themselves, thus I would suggest this be stated similar to the previous > paragraph as: > "The refer target SHOULD reject an otherwise well-formed request with an > invalid Referred-By token (see Section 4) with a 429 error response. If the > agent chooses to proceed with the request and provides any information from > the Referred-By header to its user as part of processing the request, it > MUST notify the user that the information was determined to be invalid." > > My reasoning is that it just seems that if an optional parm is mucked up (in > general or from a security perspective), then following the adage of being > generous in what you accept ...that whether to accept the request, provided > that it is warned that it's bad, should still be up to the user. This also > seems consistent with the MAYs in the previous 2 paragraphs. I do understand > the reasoning that you'd want to let the Referrer know and that by allowing > the request, you're actually bypassing the security put in place to keep the > bad guys from mucking with the messages, but again since it's optional, it > just seems that you can't make it stronger than a SHOULD. This situation for this clause is different from the preceding MAYs. Here, you _know_ you've got something invalid, where the two earlier paragraphs deal with the case that you have data that you have no indication of its integrity one way or another. If the token is invalid, something's gone wrong and it will be sufficiently hard to tell whether that's due to attack or implementation error, that the action needs to be to return an error. Diving into this just a little more deeply: Well, you've got two classes of possible "invalidity". 1) The signature is not valid. Here, you have now way to know what got mucked with. No way to know if the failure is related to an optional parameter or something important. Clearly, this condition warrants only rejection. 2) The signature is valid, but the contents of the token don't match the request. You or I might be able to inspect the message and make an educated decision about the safety of accepting the request. Ordinary people won't have that skill. (Ordinary devices currently aren't making it easy for me to get the information I would need to make that educated decision anyhow). So, again, rejection is warranted. [MB]: I do understand your point, but I'm still wondering whether it shouldn't be a SHOULD or perhaps RECOMMENDED rather than a MUST (to allow for devices that might be able to provide a different level of user interface for that scenario). I do realize that the user interface should not require a high level of technical knowledge, but I still think that a specific implementation shouldn't be limited by the protocol (eg there may be an "Advanced User" mode whereby this can be appropriately handled and a user wants to know when they're being "attacked"). > > - Section 4.1: 2nd paragraph suggesting that "A target SHOULD verify the > request...". I don't think this is useful since retargeting makes this > check not meaningful. UNLESS, of course, you're using History-Info. With > History-Info, you could verify that the Refer-To matches one of the > Targeted-to-URIs (and of course, this implies that this information has all > been sent securely, not mucked with by the proxies, etc.). There is a lot of information present than just the Request-URI that can be validated. The method, requested end-to-end headers, etc. [MB]: I agree. I think my point initially arose because I read that Note as directly coupled with the first, so it might be useful to add a 2nd sentence between the current two and RECOMMEND some of the comparisons that should be done to verify the identity, since you cannot rely on the Request-URI. > > Regards, > Mary. > > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Thursday, June 19, 2003 1:39 PM > To: sip@ietf.org > Cc: rohan@cisco.com; Jon Peterson; Dean Willis; 'Robert Sparks' > Subject: [Sip] WGLC for referred-by > > > Hello Everyone, > > I would like to begin a Working Group last call on: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-referredby-02.txt > > WGLC will end on Friday July 18th. > > 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 exim@www1.ietf.org Mon Jun 23 01:37:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27328 for ; Mon, 23 Jun 2003 01:37:28 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5N5axH26591 for sip-archive@odin.ietf.org; Mon, 23 Jun 2003 01:36:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UJzm-0006mA-JO; Mon, 23 Jun 2003 01:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sb5h-0003mq-G9 for sip@optimus.ietf.org; Wed, 18 Jun 2003 07:27:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27227; Wed, 18 Jun 2003 07:27:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sb3S-0002Cx-00; Wed, 18 Jun 2003 07:24:42 -0400 Received: from pop.tuwien.ac.at ([128.130.2.60]) by ietf-mx with esmtp (Exim 4.12) id 19Sb3R-0002Cu-00; Wed, 18 Jun 2003 07:24:41 -0400 Received: from Philemon (philemon.ikn.tuwien.ac.at [128.131.88.118]) by pop.tuwien.ac.at (8.12.8/8.12.8) with ESMTP id h5IBQvjw023678; Wed, 18 Jun 2003 13:26:57 +0200 (MEST) Content-Type: text/plain; charset="iso-8859-1" From: Klaus Umschaden Date: Wed, 18 Jun 2003 13:27:15 +0200 User-Agent: KMail/1.4.3 To: midcom@ietf.org, sip@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200306181326.15569.Klaus.Umschaden@tuwien.ac.at> X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Content-Transfer-Encoding: quoted-printable Subject: [Sip] Fwd: I-D ACTION:draft-umschaden-smime-midcom-sip-proxy-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I think that this draft may be of interest for this mailing group. Best regards, =09Klaus ---------- Forwarded Message ---------- Subject: I-D ACTION:draft-umschaden-smime-midcom-sip-proxy-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. =09Title=09=09: End-to-end Security for Firewall/NAT Traversal within the Session Initiation Protocol (SIP) =09Author(s)=09: K. Umschaden et al. =09Filename=09: draft-umschaden-smime-midcom-sip-proxy-00.txt =09Pages=09=09: 37 =09Date=09=09: 2003-5-6 This document describes an extension for the Session Initiation Protocol (SIP), which enables end-to-end security of the Session Description Protocol (SDP) together with firewall/Network Address Translation (NAT) traversal. This solution relies on Secure Multipurpose Internet Mail Extension (S/MIME) and the middlebox communications (MIDCOM) protocol. The user authorises a proxy server to encrypt the session description on behalf of the user. The proxy determines the capabilities of the receiving party and encrypts the SDP for a SIP proxy server in the receiving domain. Using MIDCOM, each proxy can dynamically control its firewall to open pinholes or request NAT bindings for the media flows. As long as each end-user may contact its trustworthy SIP proxy via a secure connection and authorise this proxy to encrypt the signalling data, the session information is secured end-to-end. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-umschaden-smime-midcom-sip-prox= y-00 =2Etxt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the messag= e. Internet-Drafts are also available by anonymous FTP. Login with the usern= ame "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then =09"get draft-umschaden-smime-midcom-sip-proxy-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.= txt Internet-Drafts can also be obtained by e-mail. Send a message to: =09mailserv@ietf.org. In the body type: =09"FILE /internet-drafts/draft-umschaden-smime-midcom-sip-proxy-00.txt". NOTE:=09The mail server at ietf.org can return the document in =09MIME-encoded form by using the "mpack" utility. To use this =09feature, insert the command "ENCODING mime" before the "FILE" =09command. To decode the response(s), you will need "munpack" or =09a MIME-compliant mail reader. Different MIME-compliant mail readers =09exhibit different behavior, especially when dealing with =09"multipart" MIME messages (i.e. documents which have been split =09up into multiple messages), so check your local documentation on =09how 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 exim@www1.ietf.org Mon Jun 23 03:02:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11100 for ; Mon, 23 Jun 2003 03:02:46 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5N72JT18610 for sip-archive@odin.ietf.org; Mon, 23 Jun 2003 03:02:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ULKz-0004pf-RV; Mon, 23 Jun 2003 03:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ULKZ-0004oQ-Uw for sip@optimus.ietf.org; Mon, 23 Jun 2003 03:01:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11057 for ; Mon, 23 Jun 2003 03:01:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ULKV-00009m-00 for sip@ietf.org; Mon, 23 Jun 2003 03:01:31 -0400 Received: from law15-f19.law15.hotmail.com ([64.4.23.19] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19ULJP-000094-00 for sip@ietf.org; Mon, 23 Jun 2003 03:00:23 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 22 Jun 2003 23:57:40 -0700 Received: from 212.143.185.30 by lw15fd.law15.hotmail.msn.com with HTTP; Mon, 23 Jun 2003 06:57:39 GMT X-Originating-IP: [212.143.185.30] X-Originating-Email: [james_s_ford@hotmail.com] From: "James Ford" To: sip@ietf.org Date: Mon, 23 Jun 2003 06:57:39 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Jun 2003 06:57:40.0803 (UTC) FILETIME=[BD091130:01C33954] Subject: [Sip] Implementing Kerberos in SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, The draft draft-wagle-sip-kerbpki-00 has already expired. Does any one know of updates to this or new drafts about implementation of Kerberos in SIP. James _________________________________________________________________ The new MSN 8: smart spam 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 exim@www1.ietf.org Mon Jun 23 05:53:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14313 for ; Mon, 23 Jun 2003 05:53:14 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5N9qmJ05905 for sip-archive@odin.ietf.org; Mon, 23 Jun 2003 05:52:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UNzV-0001Lx-Sr; Mon, 23 Jun 2003 05:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UNyW-0001JV-OK for sip@optimus.ietf.org; Mon, 23 Jun 2003 05:51:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14273 for ; Mon, 23 Jun 2003 05:50:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UNyT-0000uo-00 for sip@ietf.org; Mon, 23 Jun 2003 05:50:57 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19UNy5-0000uR-00 for sip@ietf.org; Mon, 23 Jun 2003 05:50:33 -0400 Received: from cisco.com (171.68.223.138) by sj-iport-1.cisco.com with ESMTP; 23 Jun 2003 02:51:47 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h5N9nvRJ028360 for ; Mon, 23 Jun 2003 02:49:57 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIK11049; Mon, 23 Jun 2003 02:43:16 -0700 (PDT) Date: Mon, 23 Jun 2003 02:51:15 -0700 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed From: Rohan Mahy To: sip@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <3AB61CA5-A560-11D7-8E0D-0003938AF740@cisco.com> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Sip] new connection reuse draft 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 Hello, I just submitted an updated version of my connection reuse draft to SIP as an individual submission. In the interim, it is available at the links below. I tried to clarify the proposed mechanism which was in the requirements draft, and for the next revision I will write real Client Behavior/Server Behavior sections. My hope is that this mechanism draft can become the basis for a WG item in SIP. thanks, -rohan (as an individual WG member/contributor) http://www.softarmor.com/sipwg/drafts/draft-mahy-sip-connect-reuse- 00.html http://www.softarmor.com/sipwg/drafts/draft-mahy-sip-connect-reuse- 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 exim@www1.ietf.org Tue Jun 24 00:33:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20949 for ; Tue, 24 Jun 2003 00:33:40 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5O4XE830450 for sip-archive@odin.ietf.org; Tue, 24 Jun 2003 00:33:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UfUL-0007uc-Bo; Tue, 24 Jun 2003 00:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UfSI-0007s8-58 for sip@optimus.ietf.org; Tue, 24 Jun 2003 00:32:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20908 for ; Tue, 24 Jun 2003 00:30:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UfS0-00007p-00 for sip@ietf.org; Tue, 24 Jun 2003 00:30:36 -0400 Received: from [203.254.224.33] (helo=mailout3.samsung.com) by ietf-mx with esmtp (Exim 4.12) id 19UfRp-00007R-00 for sip@ietf.org; Tue, 24 Jun 2003 00:30:26 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HGY00B01XSM1M@mailout3.samsung.com> for sip@ietf.org; Tue, 24 Jun 2003 13:29:10 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HGY00IROXSLGZ@mailout3.samsung.com> for sip@ietf.org; Tue, 24 Jun 2003 13:29:09 +0900 (KST) Received: from RANJITKUMAR ([107.108.7.233]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTPA id <0HGY006UTXSITZ@mmp1.samsung.com> for sip@ietf.org; Tue, 24 Jun 2003 13:29:08 +0900 (KST) Date: Tue, 24 Jun 2003 09:54:09 +0530 From: Ranjit Avasarala Subject: RE: [Sip] SDP doubts In-reply-to: <0C674B14EAEBD61196D900B0D03DB49F04FDE1@blrw502w.blr.infineon.com> To: "'Shetty Bharathraj (IFIN DC COM)'" , sip@ietf.org Reply-to: ranjitk@samsung.com Message-id: <000801c33a08$765d6f10$e9076c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 As per SDP grammer, \r\n ie CRLF is mandatory at the end of each SDp field. Also connection field is mandatory. So any standard SDP parser / builder should contain be able to interpret and buid them. So in ur case provide the required values for c= and provide CRLF at the end of each SDP line to test ur SDP implementation Ranjit -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Shetty Bharathraj (IFIN DC COM) Sent: Monday, June 23, 2003 5:57 PM To: 'sip@ietf.org' Subject: [Sip] SDP doubts HI I have some questions on implementation of SDP decoder. We are doing interoperable testing our SIP stack with RADVISION prolab manager, the SDP test scripts available with this tools are not consistent with the syntax of RFC 2327. Some of them are as follows. * In Some of SDP test scripts, CRLF or LF is missing at the end of SDP script(Last field). * The connection field(c=) and time(t=) are not mandatory in scripts available in prolab manager. * The order of the fields, email field and phone fields are not as per the RFC2327(e-mail field should come before the phone field). How do we go ahead with the testing of SDP with these kind of test cases?. Regards Bharath Bharathraj Shetty A.N. Software Engineer, Infineon Technologies India Pvt.Ltd. 10th Floor, Discoverer Block, International Tech Park, Whitefield Road, Bangalore - 560 066. India. Tel :+91-80-8410017/18 (Extn.2039) Fax :+91-80-8410012 email : bharathraj.shetty@infineon.com *Disclaimer* This e-mail and any attachments are confidential and may be subject to legal or some other professional privilege. They are intended solely for the attention and use of the named addressee(s). They must not be disclosed to any person without authorization. This e-mail and any attachments are also subject to copyright. They may only be copied or distributed with the consent of the copyright owner. If you are not a named addressee you must not use, disclose, retain or reproduce all or any part of the information contained in this e-mail or any attachments. If you have received this email by mistake please notify the sender immediately by return email and delete or destroy all copies of the email. Any confidentiality, privilege or copyright is not waived or lost because this email has been sent to you by mistake _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 exim@www1.ietf.org Tue Jun 24 07:01:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11454 for ; Tue, 24 Jun 2003 07:01:48 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OB1M623053 for sip-archive@odin.ietf.org; Tue, 24 Jun 2003 07:01:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UlXq-0005sh-K7; Tue, 24 Jun 2003 07:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UlXg-0005qK-Pp for sip@optimus.ietf.org; Tue, 24 Jun 2003 07:00:52 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11304; Tue, 24 Jun 2003 07:00:47 -0400 (EDT) Message-Id: <200306241100.HAA11304@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, 24 Jun 2003 07:00:47 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-history-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. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : An Extension to the Session Initiation Protocol for Request History Information Author(s) : M. Barnes Filename : draft-ietf-sip-history-info-00.txt Pages : 23 Date : 2003-6-23 This draft defines a standard mechanism for capturing the history information associated with a SIP request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This draft defines a new optional SIP header, History-Info, for capturing the history information in requests. A new option tag, HistInfo, to be included in the Supported header is defined to allow UAs to indicate whether the HistInfo should be returned in responses to a request which has captured the history information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-history-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-ietf-sip-history-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-ietf-sip-history-info-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-23142546.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-history-info-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-history-info-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-23142546.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 exim@www1.ietf.org Tue Jun 24 13:04:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24210 for ; Tue, 24 Jun 2003 13:04:47 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OH4KR13495 for sip-archive@odin.ietf.org; Tue, 24 Jun 2003 13:04:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UrD7-0003P1-Vp; Tue, 24 Jun 2003 13:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UrCo-0003OJ-7p for sip@optimus.ietf.org; Tue, 24 Jun 2003 13:03:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24124 for ; Tue, 24 Jun 2003 13:03:38 -0400 (EDT) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UrCm-0004Nt-00 for sip@ietf.org; Tue, 24 Jun 2003 13:03:40 -0400 Received: from imo-r02.mx.aol.com ([152.163.225.98]) by ietf-mx with esmtp (Exim 4.12) id 19UrCW-0004ML-00 for sip@ietf.org; Tue, 24 Jun 2003 13:03:24 -0400 Received: from Mpierce1@aol.com by imo-r02.mx.aol.com (mail_out_v36.3.) id l.1e4.bd0cbeb (3866) for ; Tue, 24 Jun 2003 13:00:33 -0400 (EDT) Message-ID: <1e4.bd0cbeb.2c29ddb1@aol.com> Date: Tue, 24 Jun 2003 13:00:33 EDT To: sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_1e4.bd0cbeb.2c29ddb1_boundary" X-Mailer: 6.0 for Windows XP sub 10501 Subject: [Sip] Comments of Resource Priority 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: , --part1_1e4.bd0cbeb.2c29ddb1_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit To all, Comments on draft-ietf-sip-resource-priority-00: The abstract says "defines a new SIP header field ... called Resource-Priority", but the draft then defines two headers. If the second header is included (see comments below), references should be added in the abstract and throughout the Introduction. In the statement in the abstract that this header "does not influence the forwarding behavior of IP routers", it needs to be made clear that, while there is no "direct" influence, it is certainly possible for such influence to exist, based on procedures and processes not described in this document. For example, the descriptions for "Assured Service" have always presumed that this Resource-Priority header in the session (call) setup signaling could be used to cause preferential treatment of media packet forwarding, including multiple drop precedences in an EF queue. I believe the sentence should read: "While it does not directly influence the forwarding behavior of IP routers, procedures for using this header to cause such influence may be defined in other documents." 3. The definition of the Resource-Priority header should not allow multiple resource values to be carried. I am unaware of any requirement for this. The use described always needs exactly one value within one namespace. Anything beyond this will bring on questions like "Which priority has priority?" Note: REQ-13 says that "Some UAs will need to support multiple different priority schemes". It does not say that the indication (header) needs to support a "list of names". 3. Instead of defining a separate Accept header, it seems that there could be a single Resource-priority Header which is then included in specific messages (responses) to mean "accept". (I'm trying to find an existing example of a header that is used like this.) The example of the originator requesting "q735.1, gets.enabled" and the response indicating which dsn values are supported is invalid. The dsn would not function this way. If it understands the value received based on interworking arrangements (e.g., gets.enabled), it may convert it to its equivalent dsn value, according to the interworking rules. Or if it is set up to understand and support multiple namespaces (e.g., gets and dsn), then it would respond to either and internally would know how to prioritize values from the two namespaces. Otherwise it simply processes the call setup attempt as if it didn't have a Resource-Priority header. (see 4.2 below). When one defines the specific procedures for specific namespaces (not in this document), the only possible response to a request should be to indicate "accepted" priority values within the same namespace as the request. Otherwise, it seems to contradict the point of defining namespaces. 4.2 "Unknown namespace" error: The sentence with "it MAY serve ... if and only if" seems strange. The "if and only if" appears to be indicating a "MUST" situation. The rest of the sentence is confusing, since it is saying that it depends on "if the request would ... experience treatment no different than a non-labeled request", but the whole point of the sentence is that it's treated "as if it had no priority indication", that is, is non-labeled. Also, it seems that there should be different treatment when the namespace is recognized but the priority value isn't. I believe the whole sentence should be replaced with: "If an element receives a request with a namespace that it does not recognize, it SHOULD serve the request as if it had no Resource-Priority header. If an element receives a request with a namespace it recognizes but a priority value that it does not recognize, it SHOULD serve the request as if it had the default value specified for that namespace." (Section 12 says what is in this last sentence.) The 2nd paragraph (beginning "If an unknown resource ...") continue to be a problem, since it seems to mandate an impossible operation: the element must make a decision based on the operation that should have occurred for a namespace that it does not recognize. It must be assumed that the phrase "or would get a different treatment" intends to say "than if the namespace were recognized". This second paragraph should be deleted. The 3rd paragraph gives the incorrect meanings for the response code 417. Section 11 defines it as "Unknown Resource-Priority". (Also wrong in 4.4 and 7.2.) 4.4 The text here limits the UAC to sending one Resource-Priority Header field. However, Section 3 contained the statement that "There may be multiple resource values or, equivalently, multiple Resource-Priority header fields." I believe Section 3 is incorrect. The description in the 2nd paragraph would not be the allowed operation in any case that I am aware of. For any use of this Resource-Priority header, the user specifies the appropriate priority value for the call being attempted. Therefore, no device (UAC) is allowed to reattempt a failed call at a different (presumably higher) level. If the call is rejected due to the attempted unauthorized use of a level or if the call is blocked when attempted at a particular level, the only option is to notify the user of this fact. If the user decides to reattempt the call with a higher level, the UAC can not prevent this. But no UAC can be allowed to automatically use a higher level. In any case, the rules for use of this Resource-Priority header should be left to documents describing specific uses (namespaces). B.1 Reference to "critic-ecp" should be added before "flash-override" in the list. The reference to "critic-ecp" should be deleted from the 2nd paragraph since it was added to the 1st. A relative order needs to be explicitly specified as requires by Section 12. This should specify that "Routine" is the default. The following is suggested for the 1st paragraph: This document defines the namespace "dsn". The namespace "dsn" (Defense Switched Network) contains the following priority values in the relative order listed: "critic-ecp", "flash-override", "flash", immediate", "priority", "and "routine", with "critic-ecp as the highest and "routine" as the lowest. The default is "routine". B.3 and B.4 There is a confusion here since GETS and TDR are really the same thing. These can not be split into separate namespaces. Since the IANA considerations states that "the registration must indicate the default", it is not possible to have a namespace with only one value. It is necessary to define a second value which can be designated as the default even if that value is never used in signaling. B.4 The current defined value is incorrect. "Authorized_emergency" is not the same as 911 or 112 calls placed by the general public. "Authorized emergency" belongs with GETS. In the previous drafts, authorized emergency and 911 were intended as two distinct values within one namespace that covered GETS-type calls, 911-type calls, and normal calls (i.e., the regular "public network"). I believe the correct approach is to define a single namespace for the "public network" environment with the following values (at a minimum): - Authorized emergency (GETS, etc.) - Public emergency (911, 112, etc.) - Normal Of course, "normal" is the default. Further, I know that there are some who believe that multiple "Authorized emergency" levels are needed, similar to what is defined for the Wireless Priority System mentioned in Section 3. If this issue of the definition of multiple values to support authorized emergency (GETS or TDR), public emergency calling (e.g., 911), and various other priority schemes that might reside in the same "public" network can't be quickly resolved, these should be removed from this draft, to be added later by IANA registration. B.4 I'm not sure why the second paragraph under B.4 for the Defense Red Switched Network was added. (This should have been a new section number.) If kept, it also should specify that "Routine" is the default. We're looking into whether this new "FOO" precedence level is needed and whether it should simply be added to the existing dsn namespace. Reference 11 needs to be updated to read RFC 3487. Mike Pierce Artel --part1_1e4.bd0cbeb.2c29ddb1_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable To all,

Comments on draft-ietf-sip-resource-priority-00:

The abstract says "defines a new SIP header field ... called Resource-Pr= iority", but the draft then defines two headers. If the second header is inc= luded (see comments below), references should be added in the abstract and t= hroughout the Introduction.

In the statement in the abstract that this header "does not influence th= e forwarding behavior of IP routers", it needs to be made clear that, while=20= there is no "direct" influence, it is certainly possible for such influence=20= to exist, based on procedures and processes not described in this document.=20= For example, the descriptions for "Assured Service" have always presumed tha= t this Resource-Priority header in the session (call) setup signaling could=20= be used to cause preferential treatment of media packet forwarding, includin= g multiple drop precedences in an EF queue. I believe the sentence should re= ad: "While it does not directly influence the forwarding behavior of IP rout= ers, procedures for using this header to cause such influence may be defined= in other documents."

3. The definition of the Resource-Priority header should not allow multi= ple resource values to be carried. I am unaware of any requirement for this.= The use described always needs exactly one value within one namespace. Anyt= hing beyond this will bring on questions like "Which priority has priority?"

Note: REQ-13 says that "Some UAs will need to support multiple different= priority schemes". It does not say that the indication (header) needs to su= pport a "list of names".

3. Instead of defining a separate Accept header, it seems that there cou= ld be a single Resource-priority Header which is then included in specific m= essages (responses) to mean "accept". (I'm trying to find an existing exampl= e of a header that is used like this.)

The example of the originator requesting "q735.1, gets.enabled" and the=20= response indicating which dsn values are supported is invalid. The dsn would= not function this way. If it understands the value received based on interw= orking arrangements (e.g., gets.enabled), it may convert it to its equivalen= t dsn value, according to the interworking rules. Or if it is set up to unde= rstand and support multiple namespaces (e.g., gets and dsn), then it would r= espond to either and internally would know how to prioritize values from the= two namespaces. Otherwise it simply processes the call setup attempt as if=20= it didn't have a Resource-Priority header. (see 4.2 below).

When one defines the specific procedures for specific namespaces (not in= this document), the only possible response to a request should be to indica= te "accepted" priority values within the same namespace as the request. Othe= rwise, it seems to contradict the point of defining namespaces.

4.2 "Unknown namespace" error: The sentence with "it MAY serve ... if an= d only if" seems strange. The "if and only if" appears to be indicating a "M= UST" situation. The rest of the sentence is confusing, since it is saying th= at it depends on "if the request would ... experience treatment no different= than a non-labeled request", but the whole point of the sentence is that it= 's treated "as if it had no priority indication", that is, is non-labeled. A= lso, it seems that there should be different treatment when the namespace is= recognized but the priority value isn't. I believe the whole sentence shoul= d be replaced with: "If an element receives a request with a namespace that=20= it does not recognize, it SHOULD serve the request as if it had no Resource-= Priority header. If an element receives a request with a namespace it recogn= izes but a priority value that it does not recognize, it SHOULD serve the re= quest as if it had the default value specified for that namespace." (Section= 12 says what is in this last sentence.)

The 2nd paragraph (beginning "If an unknown resource ...") continue to b= e a problem, since it seems to mandate an impossible operation: the element=20= must make a decision based on the operation that should have occurred for a=20= namespace that it does not recognize. It must be assumed that the phrase "or= would get a different treatment" intends to say "than if the namespace were= recognized". This second paragraph should be deleted.

The 3rd paragraph gives the incorrect meanings for the response code 417= . Section 11 defines it as "Unknown Resource-Priority". (Also wrong in 4.4 a= nd 7.2.)
=20
4.4 The text here limits the UAC to sending one Resource-Priority Header= field. However, Section 3 contained the statement that "There may be multip= le resource values or, equivalently, multiple Resource-Priority header field= s." I believe Section 3 is incorrect.

The description in the 2nd paragraph would not be the allowed operation=20= in any case that I am aware of. For any use of this Resource-Priority header= , the user specifies the appropriate priority value for the call being attem= pted. Therefore, no device (UAC) is allowed to reattempt a failed call at a=20= different (presumably higher) level. If the call is rejected due to the atte= mpted unauthorized use of a level or if the call is blocked when attempted a= t a particular level, the only option is to notify the user of this fact. If= the user decides to reattempt the call with a higher level, the UAC can not= prevent this. But no UAC can be allowed to automatically use a higher level= .

In any case, the rules for use of this Resource-Priority header should b= e left to documents describing specific uses (namespaces).

B.1 Reference to "critic-ecp" should be added before "flash-override" in= the list. The reference to "critic-ecp" should be deleted from the 2nd para= graph since it was added to the 1st. A relative order needs to be explicitly= specified as requires by Section 12. This should specify that "Routine" is=20= the default. The following is suggested for the 1st paragraph:

This document defines the namespace "dsn". The namespace "dsn" (Defense=20= Switched Network) contains the following priority values in the relative ord= er listed: "critic-ecp", "flash-override", "flash", immediate", "priority",=20= "and "routine", with "critic-ecp as the highest and "routine" as the lowest.= The default is "routine".

B.3 and B.4
There is a confusion here since GETS and TDR are really the same thing.=20= These can not be split into separate namespaces.
Since the IANA considerations states that "the registration must indicat= e the default", it is not possible to have a namespace with only one value.=20= It is necessary to define a second value which can be designated as the defa= ult even if that value is never used in signaling.

B.4 The current defined value is incorrect. "Authorized_emergency" is no= t the same as 911 or 112 calls placed by the general public. "Authorized eme= rgency" belongs with GETS. In the previous drafts, authorized emergency and=20= 911 were intended as two distinct values within one namespace that covered G= ETS-type calls, 911-type calls, and normal calls (i.e., the regular "public=20= network").

I believe the correct approach is to define a single namespace for the "= public network" environment with the following values (at a minimum):
- Authorized emergency (GETS, etc.)
- Public emergency (911, 112, etc.)
- Normal
Of course, "normal" is the default. Further, I know that there are some=20= who believe that multiple "Authorized emergency" levels are needed, similar=20= to what is defined for the Wireless Priority System mentioned in Section 3.

If this issue of the definition of multiple values to support authorized= emergency (GETS or TDR), public emergency calling (e.g., 911), and various=20= other priority schemes that might reside in the same "public" network can't=20= be quickly resolved, these should be removed from this draft, to be added la= ter by IANA registration.

B.4 I'm not sure why the second paragraph under B.4 for the Defense Red=20= Switched Network was added. (This should have been a new section number.) If= kept, it also should specify that "Routine" is the default. We're looking i= nto whether this new "FOO" precedence level is needed and whether it should=20= simply be added to the existing dsn namespace.

Reference 11 needs to be updated to read RFC 3487.

Mike Pierce
Artel
--part1_1e4.bd0cbeb.2c29ddb1_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 exim@www1.ietf.org Tue Jun 24 14:45:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02663 for ; Tue, 24 Jun 2003 14:45:36 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OIj9r32765 for sip-archive@odin.ietf.org; Tue, 24 Jun 2003 14:45:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Usms-0008W1-B3; Tue, 24 Jun 2003 14:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UsmX-0008VT-Tl for sip@optimus.ietf.org; Tue, 24 Jun 2003 14:44:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02608 for ; Tue, 24 Jun 2003 14:44:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UsmV-0005qz-00 for sip@ietf.org; Tue, 24 Jun 2003 14:44:39 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19UsmK-0005qH-00 for sip@ietf.org; Tue, 24 Jun 2003 14:44:28 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5OIhDo04789 for ; Tue, 24 Jun 2003 13:43:14 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jun 2003 13:43:14 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF578A21@zrc2c000.us.nortel.com> From: "Mary Barnes" To: sip@ietf.org Date: Tue, 24 Jun 2003 13:43:13 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [Sip] RE: I-D ACTION:draft-ietf-sip-history-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: , Hi all, The most significant change to this version of the document (from draft-barnes-sipping-history-info-02) was per the discussion at IETF-56 to make the INDEX a MUST. I see the only major open issue to be the security solution, for which I do have a separate draft that I've submitted to the SIPPING WG. Since, it wasn't submitted until Sunday afternoon, it will probably be a couple days before it appears. For folks that would like to review it now, it is cached on my server at: http://home.attbi.com/~mbarnes42/IETF/draft-barnes-sipping-sec-inserted-info -00.txt This draft definitely needs more work, however, I think fundamental agreement on the problem being solved and the approach detailed up to and including section 3 is first necessary prior to completing section 4 and beyond. Until the WG has agreed whether this document belongs in the SIP WG, I would suggest questions/comments on the security draft be sent to the SIPPING WG mailing list. Regards, Mary H. Barnes mbarnes@nortelnetworks.com -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, June 24, 2003 6:01 AM Cc: sip@ietf.org Subject: I-D ACTION:draft-ietf-sip-history-info-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : An Extension to the Session Initiation Protocol for Request History Information Author(s) : M. Barnes Filename : draft-ietf-sip-history-info-00.txt Pages : 23 Date : 2003-6-23 This draft defines a standard mechanism for capturing the history information associated with a SIP request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This draft defines a new optional SIP header, History-Info, for capturing the history information in requests. A new option tag, HistInfo, to be included in the Supported header is defined to allow UAs to indicate whether the HistInfo should be returned in responses to a request which has captured the history information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-history-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-ietf-sip-history-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-ietf-sip-history-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. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Jun 24 15:18:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05352 for ; Tue, 24 Jun 2003 15:18:34 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OJI5E06448 for sip-archive@odin.ietf.org; Tue, 24 Jun 2003 15:18:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UtIp-0001f4-0T; Tue, 24 Jun 2003 15:18:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UtIX-0001dp-I7 for sip@optimus.ietf.org; Tue, 24 Jun 2003 15:17:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05171 for ; Tue, 24 Jun 2003 15:17:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UtIH-0006Bu-00 for sip@ietf.org; Tue, 24 Jun 2003 15:17:29 -0400 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by ietf-mx with esmtp (Exim 4.12) id 19UtI6-0006BA-00 for sip@ietf.org; Tue, 24 Jun 2003 15:17:18 -0400 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HH0009DD2UZKE@firewall.wcom.com> for sip@ietf.org; Tue, 24 Jun 2003 19:16:11 +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 <0HH000B012UZ9Y@pmismtp01.wcomnet.com>; Tue, 24 Jun 2003 19:16:11 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.122.248]) by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HH0009422UXNT@pmismtp01.wcomnet.com>; Tue, 24 Jun 2003 19:16:11 +0000 (GMT) Date: Tue, 24 Jun 2003 14:16:07 -0500 From: Alan Johnston X-Sender: Alan.Johnston@pop.mcit.com To: sip@ietf.org Cc: Adam Roach Message-id: <5.2.1.1.0.20030624141243.023b8ab8@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed Subject: [Sip] Centralized Conferencing (xcon) BOF Announcement Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , FYI. Centralized Conferencing BOF (xcon) Tuesday, July 15 at 1700-1800 ============================== CHAIRS: Alan Johnston (alan.johnston@mci.com) Adam Roach (adam@dynamicsoft.com) AGENDA: - Intro and Agenda Bashing (5 min) - Problem Statement and Overview of Scope (10 min) - Charter Discussion (15 min) - Open Discussion (30 min) Description of Proposed Working Group The focus of this working group is to develop a standardized suite of protocols for tightly-coupled multimedia conferences, where strong security and authorization requirements are integral to the solution. Tightly-coupled conferences have a central point of control and authorization so they can enforce specific media and membership relationships, and provide an accurate roster of participants. The media mixing or combining function of a tightly-coupled conference need not be performed centrally, however. Unlike previous attempts at standardizing conferencing-related activities, the scope of this effort is intentionally very narrow, and is intended to enable interoperability in a commercial environment which already has a number of implementations. Privacy, security, and authorization mechanisms are integral to the solution generated by the working group. This includes allowing participants to be completely invisible or to be visible but participate anonymously with respect to some or all of the other participants. Authorization rules allow for participants and non-participants to have roles (ex: speaker, moderator, owner), and to be otherwise authorized to perform membership and media manipulation for or on behalf of other participants. In order to preserve these properties, the protocols used will require implementation of channel security and authentication services. Initially this combination of protocols will be specified with respect to session setup with SIP, but most of the specific components would be applicable to conferences setup using other protocols. [None of the protocols defined by this group will be SIP or require SIP extensions.] The group will use the high-level requirements and framework already described by documents published by the SIPPING WG. The deliverables for the group will be: - A mechanism for membership and authorization control - A mechanism to manipulate and describe media "layout" or "topology" for multiple media types (audio, video, text) - A mechanism for notification of conference related events/changes (for example a roster) - A basic floor control protocol - Peer-to-peer cascading of conferences (one conference is a participant in another and vice versa) The following items are specifically out-of-scope: - Voting - Multicast media (due to security concerns) - Fully distributed conferences - Loosely-coupled conferences (no central point of control) - Far-end device control - Protocol used between the conference controller and the mixer(s) - Capabilities negotiation of the mixer(s) - Master-slave cascaded conferences The working group will coordinate closely with the SIPPING and MMUSIC working groups. In addition the working group will cooperate with other groups as needed, including SIP, AVT, and the W3C SMIL working groups. In addition, the working group will consider a number of existing drafts (a non-exhaustive list is included below) as input to the working group. Related documents in other working groups: - draft-ietf-sipping-conferencing-requirements-00.txt - draft-ietf-sipping-conferencing-framework-00.txt - draft-ietf-sipping-cc-conferencing-00.txt - draft-ietf-sipping-cc-framework-02.txt - draft-ietf-sipping-conference-package-00.txt Partial list of input documents: (All documents available at http://ee.wustl.edu/~alan/xcon/ until they appear in the IETF archives.) - draft-even-xcon-conference-scenarios-00.txt - draft-koskelainen-xcon-cpcp-reqs-00.txt - draft-even-xcon-media-policy-requirements-00.txt - draft-koskelainen-xcon-floor-control-req-00.txt - draft-koskelainen-xcon-xcap-cpcp-usage-00.txt - draft-levin-xcon-cpcp-00.txt - draft-mahy-xcon-media-policy-control-00.txt Comments on the above drafts are welcome on the xcon mailing list: Mailing-List: xcon@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Jun 25 11:35:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16046 for ; Wed, 25 Jun 2003 11:35:56 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFZTH06001 for sip-archive@odin.ietf.org; Wed, 25 Jun 2003 11:35:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCIn-0001IP-5d; Wed, 25 Jun 2003 11:35:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBpi-0006YL-Jt for sip@optimus.ietf.org; Wed, 25 Jun 2003 11:05:14 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12778; Wed, 25 Jun 2003 10:52:21 -0400 (EDT) Message-Id: <200306251452.KAA12778@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org, sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 25 Jun 2003 10:52:21 -0400 Subject: [Sip] I-D ACTION:draft-melanchuk-sipping-moml-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 : Media Objects Markup Language (MOML) Author(s) : T. Melanchuk, G. Sharratt Filename : draft-melanchuk-sipping-moml-00.txt Pages : 42 Date : 2003-6-24 The Media Objects Markup Language (MOML) is used to define media processing objects which execute on media servers. It defines a set of primitive media objects (called primitives) and provides tools to group primitives together and specify how they interact with each other. Clients use MOML to create precisely tailored media processing objects which may be used as parts of application interactions with users or conferences or to transform media flowing internal to a media server. IVR is an example of an application interaction with a user. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-melanchuk-sipping-moml-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-melanchuk-sipping-moml-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-melanchuk-sipping-moml-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-25103219.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-melanchuk-sipping-moml-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-melanchuk-sipping-moml-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-25103219.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Jun 25 11:35:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16047 for ; Wed, 25 Jun 2003 11:35:56 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFZTC06002 for sip-archive@odin.ietf.org; Wed, 25 Jun 2003 11:35:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCIe-0000zX-22; Wed, 25 Jun 2003 11:35:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBpA-0006YL-Ug for sip@optimus.ietf.org; Wed, 25 Jun 2003 11:04:40 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13296; Wed, 25 Jun 2003 10:54:54 -0400 (EDT) Message-Id: <200306251454.KAA13296@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, 25 Jun 2003 10:54:54 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-resource-priority-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 : Communications Resource Priority for the Session Initiation Protocol (SIP) Author(s) : H. Schulzrinne, J. Polk Filename : draft-ietf-sip-resource-priority-00.txt Pages : 24 Date : 2003-6-24 This document defines a new SIP header field for communications resource priority, called 'Resource-Priority'. This header field can influence the behavior of SIP UAs, such as GSTN gateways, and SIP proxies. It does not influence the forwarding behavior of IP routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-resource-priority-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-resource-priority-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-resource-priority-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-25103702.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-resource-priority-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-resource-priority-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-25103702.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 exim@www1.ietf.org Wed Jun 25 11:35:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16070 for ; Wed, 25 Jun 2003 11:35:57 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFZTR06184 for sip-archive@odin.ietf.org; Wed, 25 Jun 2003 11:35:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCIy-0001YI-Px; Wed, 25 Jun 2003 11:35:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBxC-0008AG-3d for sip@optimus.ietf.org; Wed, 25 Jun 2003 11:12:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05283 for ; Wed, 25 Jun 2003 05:09:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19V6HQ-0002v9-00 for sip@ietf.org; Wed, 25 Jun 2003 05:09:28 -0400 Received: from mx4.aruba.it ([62.149.128.133]) by ietf-mx with smtp (Exim 4.12) id 19V6HG-0002ut-00 for sip@ietf.org; Wed, 25 Jun 2003 05:09:18 -0400 Received: (qmail 2616 invoked from network); 25 Jun 2003 09:08:25 -0000 Received: from unknown (HELO braies.giandrea.com) (217.57.90.125) by mx4.aruba.it with SMTP; 25 Jun 2003 09:08:25 -0000 Message-Id: <5.2.1.1.0.20030625110804.00baeb98@pop3.giandrea.com> X-Sender: andrea/giandrea.com@pop3.giandrea.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 25 Jun 2003 11:08:18 +0200 To: sip@ietf.org From: giAndrea Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Rating: mx4.aruba.it 1.6.2 0/1000/N Subject: [Sip] [Serusers] Problems with ser Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi all i have some problems with ser. I've configurated ser with mysql. When I register a user with serctl it add to ser database but this is the only information that i can see on ser database. How can i register all information about ser activities on database? Where can i found some log of sip activities? I can't use my server sip with MSN. When I configure user for communication services MSN can't found server. How can i configure server for use with MSN? thanks, andrea _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Jun 25 12:22:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16072 for ; Wed, 25 Jun 2003 11:35:57 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFZTL06187 for sip-archive@odin.ietf.org; Wed, 25 Jun 2003 11:35:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCIw-0001Us-D3; Wed, 25 Jun 2003 11:35:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBxC-0008AG-1P for sip@optimus.ietf.org; Wed, 25 Jun 2003 11:12:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05486 for ; Wed, 25 Jun 2003 05:25:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19V6X3-0002zE-00 for sip@ietf.org; Wed, 25 Jun 2003 05:25:37 -0400 Received: from mx4.aruba.it ([62.149.128.133]) by ietf-mx with smtp (Exim 4.12) id 19V6Ws-0002z2-00 for sip@ietf.org; Wed, 25 Jun 2003 05:25:27 -0400 Received: (qmail 16754 invoked from network); 25 Jun 2003 09:24:51 -0000 Received: from unknown (HELO braies.giandrea.com) (217.57.90.125) by mx4.aruba.it with SMTP; 25 Jun 2003 09:24:51 -0000 Message-Id: <5.2.1.1.0.20030625110804.00baeb98@pop3.giandrea.com> X-Sender: andrea/giandrea.com@pop3.giandrea.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 25 Jun 2003 11:18:26 +0200 To: sip@ietf.org From: giAndrea Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Rating: mx4.aruba.it 1.6.2 0/1000/N Subject: [Sip] [Serusers] Problems with ser Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi all i have some problems with ser. I've configurated ser with mysql. When I register a user with serctl it add to ser database but this is the only information that i can see on ser database. How can i register all information about ser activities on database? Where can i found some log of sip activities? I can't use my server sip with MSN. When I configure user for communication services MSN can't found server. How can i configure server for use with MSN? thanks, andrea _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Jun 25 12:22:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16048 for ; Wed, 25 Jun 2003 11:35:56 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFZTL05996 for sip-archive@odin.ietf.org; Wed, 25 Jun 2003 11:35:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCIZ-0000vE-Cl; Wed, 25 Jun 2003 11:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBpi-0006YL-Pt for sip@optimus.ietf.org; Wed, 25 Jun 2003 11:05:14 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12794; Wed, 25 Jun 2003 10:52:26 -0400 (EDT) Message-Id: <200306251452.KAA12794@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org, sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 25 Jun 2003 10:52:25 -0400 Subject: [Sip] I-D ACTION:draft-melanchuk-sipping-msml-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 : Media Sessions Markup Language (MSML) Author(s) : T. Melanchuk, G. Sharratt Filename : draft-melanchuk-sipping-msml-00.txt Pages : 31 Date : 2003-6-24 The Media Sessions Markup Language (MSML) is used to control and invoke many different types of services on IP media servers. Clients can use it define how media sessions interact on a media server and to apply services to individual or groups of users. MSML can be used, for example, to control media server advanced conferencing features, create sidebars, and insert media processing objects into media streams. As well, clients can use it with other languages such as the Media Objects Markup Language (MOML) or VoiceXML to interact with individual users or with groups of conference participants. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-melanchuk-sipping-msml-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-melanchuk-sipping-msml-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-melanchuk-sipping-msml-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-25103228.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-melanchuk-sipping-msml-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-melanchuk-sipping-msml-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-25103228.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Jun 25 14:00:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23115 for ; Wed, 25 Jun 2003 14:00:40 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PI0C526893 for sip-archive@odin.ietf.org; Wed, 25 Jun 2003 14:00:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VEYs-0006yq-Nk; Wed, 25 Jun 2003 14:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VEYI-0006xL-3w for sip@optimus.ietf.org; Wed, 25 Jun 2003 13:59:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23062 for ; Wed, 25 Jun 2003 13:59:24 -0400 (EDT) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VEYH-0005iG-00 for sip@ietf.org; Wed, 25 Jun 2003 13:59:25 -0400 Received: from imo-r03.mx.aol.com ([152.163.225.99]) by ietf-mx with esmtp (Exim 4.12) id 19VEY1-0005i5-00 for sip@ietf.org; Wed, 25 Jun 2003 13:59:09 -0400 Received: from Mpierce1@aol.com by imo-r03.mx.aol.com (mail_out_v36.3.) id 7.145.146d1100 (4184); Wed, 25 Jun 2003 13:58:03 -0400 (EDT) Message-ID: <145.146d1100.2c2b3caa@aol.com> Date: Wed, 25 Jun 2003 13:58:02 EDT To: hgs@cs.columbia.edu CC: sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_145.146d1100.2c2b3caa_boundary" X-Mailer: 6.0 for Windows XP sub 10501 Subject: [Sip] Resource Priority header - multiple namespaces Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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_145.146d1100.2c2b3caa_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 6/25/2003 7:13:23 AM Eastern Standard Time, hgs@cs.columbia.edu writes: > > > > 3. The definition of the Resource-Priority header should not allow > > multiple resource values to be carried. I am unaware of any requirement > > for this. The use described always needs exactly one value within one > > namespace. Anything beyond this will bring on questions like "Which > > priority has priority?" > > > > Note: REQ-13 says that "Some UAs will need to support multiple different > > priority schemes". It does not say that the indication (header) needs to > > support a "list of names". > > The only reason that I can think of is to support the case where I'm > operating in a multi-namespace environment and where I want to say > "please use namespace X if you can, or Y if that suits you". I don't > know whether this is likely to occur in practice. The priority > resolution is easy - the entity receiving the header ignores the stuff > it doesn't know and picks the highest priority among those it does. > However, I agree that this is probably more complication than warranted. > The Accept-R-P header can achieve roughly the same thing, with less > trouble, albeit more round-trips. > This seems to be a very significant conceptual difference of ideas on what the namespace is used for and how. I believe the "namespace" exists only to allow an easy-to-manage way to define different sets of priority levels for different cases. Definition of a priority level "high" for one case is independent from "high" for the other. Namespace does not exist for use by the user. In practice, in actual use, the orginator does not select (and then maybe change, as you wrote) a namespace. The device is configured to use the right one, while the person selects the proper priority level. If there are cases in which one of several namespaces could be used, it is not the human who selects the "namespace", except indirectly by what is dialed. The human in unaware of this concept. For example, if a military phone is setup and authorized to handle MLPP priorities, an emergency worker with GETS access may use the phone, perform the magic procedures to get such GETS authorization, which may result in a Resource-Priority header being sent with namespace=gets, priority=enabled (to use the values currently in the draft). It does not result in sending two different priority values with some other entity being given the chance to decide which is better. In fact, the treatments may be different, with one using preemption and the other queuing for resources. No, it should never happen that the user would ask "please use namespace X if you can, or Y if that suits you". The request is always "use namespace X with priority level Z and do the best you can", (with the actual user being unaware of the namespace). If the call is blocked, the user may do something else (which might not have anything to do with a namespace). I'm mostly afraid that any attempts to describe use of multiple namespaces will cause significant difficulty in moving this draft forward, since there are lots of unexplained interactions. Mike Pierce Artel --part1_145.146d1100.2c2b3caa_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 6/25/2= 003 7:13:23 AM Eastern Standard Time, hgs@cs.columbia.edu writes:


>=20
> 3. The definition of the Resource-Priority header should not allow=20
> multiple resource values to be carried. I am unaware of any require= ment=20
> for this. The use described always needs exactly one value within o= ne=20
> namespace. Anything beyond this will bring on questions like "Which= =20
> priority has priority?"
>=20
> Note: REQ-13 says that "Some UAs will need to support multiple diff= erent=20
> priority schemes". It does not say that the indication (header) nee= ds to=20
> support a "list of names".

The only reason that I can think of is to support the case where I'm=20
operating in a multi-namespace environment and where I want to say=20
"please use namespace X if you can, or Y if that suits you". I don't=20
know whether this is likely to occur in practice. The priority=20
resolution is easy - the entity receiving the header ignores the stuff=20
it doesn't know and picks the highest priority among those it does.=20
However, I agree that this is probably more complication than warranted.= =20
The Accept-R-P header can achieve roughly the same thing, with less=20
trouble, albeit more round-trips.




This seems to be a very significant conceptual difference of ideas on wh= at the namespace is used for and how. I believe the "namespace" exists only=20= to allow an easy-to-manage way to define different sets of priority levels f= or different cases. Definition of a priority level "high" for one case is in= dependent from "high" for the other. Namespace does not exist for use by the= user.

In practice, in actual use, the orginator does not select (and then mayb= e change, as you wrote) a namespace. The device is configured to use the rig= ht one, while the person selects the proper priority level. If there are cas= es in which one of several namespaces could be used, it is not the human who= selects the "namespace", except indirectly by what is dialed. The human in=20= unaware of this concept. For example, if a military phone is setup and autho= rized to handle MLPP priorities, an emergency worker with GETS access may us= e the phone, perform the magic procedures to get such GETS authorization, wh= ich may result in a Resource-Priority header being sent with namespace=3Dget= s, priority=3Denabled (to use the values currently in the draft). It does no= t result in sending two different priority values with some other entity bei= ng given the chance to decide which is better. In fact, the treatments may b= e different, with one using preemption and the other queuing for resources.

No, it should never happen that the user would ask "please use namespace= X if you can, or Y if that suits you". The request is always "use namespace= X with priority level Z and do the best you can", (with the actual user bei= ng unaware of the namespace). If the call is blocked, the user may do someth= ing else (which might not have anything to do with a namespace).

I'm mostly afraid that any attempts to describe use of multiple namespac= es will cause significant difficulty in moving this draft forward, since the= re are lots of unexplained interactions.

Mike Pierce
Artel

--part1_145.146d1100.2c2b3caa_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 exim@www1.ietf.org Wed Jun 25 14:01:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23161 for ; Wed, 25 Jun 2003 14:01:31 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PI12p27534 for sip-archive@odin.ietf.org; Wed, 25 Jun 2003 14:01:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VEZp-00079u-Ri; Wed, 25 Jun 2003 14:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VEYq-0006yD-Jw for sip@optimus.ietf.org; Wed, 25 Jun 2003 14:00:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23072 for ; Wed, 25 Jun 2003 13:59:58 -0400 (EDT) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VEYp-0005iP-00 for sip@ietf.org; Wed, 25 Jun 2003 13:59:59 -0400 Received: from imo-r06.mx.aol.com ([152.163.225.102]) by ietf-mx with esmtp (Exim 4.12) id 19VEYZ-0005i6-00 for sip@ietf.org; Wed, 25 Jun 2003 13:59:43 -0400 Received: from Mpierce1@aol.com by imo-r06.mx.aol.com (mail_out_v36.3.) id 7.54.14345e76 (4184); Wed, 25 Jun 2003 13:58:05 -0400 (EDT) Message-ID: <54.14345e76.2c2b3cad@aol.com> Date: Wed, 25 Jun 2003 13:58:05 EDT To: hgs@cs.columbia.edu CC: sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_54.14345e76.2c2b3cad_boundary" X-Mailer: 6.0 for Windows XP sub 10501 Subject: [Sip] Resource Priority header - unknown namespace Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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_54.14345e76.2c2b3cad_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 6/24/2003 11:54:45 PM Eastern Standard Time, hgs@cs.columbia.edu writes: > > 4.2 "Unknown namespace" error: The sentence with "it MAY serve ... if > > and only if" seems strange. The "if and only if" appears to be > > indicating a "MUST" situation. The rest of the sentence is confusing, > > since it is saying that it depends on "if the request would ... > > experience treatment no different than a non-labeled request", but the > > whole point of the sentence is that it's treated "as if it had no > > priority indication", that is, is non-labeled. Also, it seems that there > > I rephrased it, but basically the intent was that if, at the time of > arrival of the request, labeled and non-labeled requests are treated the > same, there doesn't seem to be a point to say "sorry, don't know this > (but it wouldn't make any difference in any event)". In other words, > under normal, no-overload operations conditions, where all requests are > served, there is no need to reject requests that have the wrong label. > > I don't think treating unknown namespaces the same as no R-P is right if > the treatment differs. Rather than being routed into some inferior > corner of the network if I guessed the wrong namespace, I should be told > that I should be using a different namespace. > I'm still confused. By definition, labeled and non-labeled requests may be treated differently someplace in the network at any time. In any case, an entity could make such a distinction between labels that it understands and requests without labels. But it is impossible to make decisions based on a label it does not understand, since it would have no way of knowing whether the request might be treated differently at this moment if it understood the label. What if, at the specific moment, one label would result in different treatment while a second would not? Then what would be the decision for a 3rd, unknown label? I would hate to think that deciding how to process the incoming unknown label would depend on whether there is currently overload, especially since that question itself (is there overload) may depend on what the label is. This again relates to my comments about the concept and use of "namespace". We are not concerned with someone "guessing" the wrong namespace, since the user doesn't select it directly. In a message dated 6/24/2003 11:54:45 PM Eastern Standard Time, hgs@cs.columbia.edu writes: > > > > The 2nd paragraph (beginning "If an unknown resource ...") continue to > > be a problem, since it seems to mandate an impossible operation: the > > element must make a decision based on the operation that should have > > occurred for a namespace that it does not recognize. It must be assumed > > that the phrase "or would get a different treatment" intends to say > > "than if the namespace were recognized". This second paragraph should be > > deleted. > > I disagree. It simply says that if the treatment is different I ask for > X, but you don't know X, and if the current treatment for some > priorities is better than for default, I should be given a chance to > apply for this better treatment rather than being silently sent into the > long queue. > > I don't understand the point. It seems too complicated and unecessary. As an alternative to what I suggested (treat the request as if it had no R-P header), it would be possible instead to always reject with "Unknown Resource-Priority", except that code does not indicate that it was the namespace that was unknown. Always rejecting for an unknown namespace would be okay, since this can only happen due to misconfiguration in the originating device. Mike Pierce Artel --part1_54.14345e76.2c2b3cad_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 6/24/2= 003 11:54:45 PM Eastern Standard Time, hgs@cs.columbia.edu writes:


> 4.2 "Unknown namespace= " error: The sentence with "it MAY serve ... if=20
> and only if" seems strange. The "if and only if" appears to be=20
> indicating a "MUST" situation. The rest of the sentence is confusin= g,=20
> since it is saying that it depends on "if the request would ...=20
> experience treatment no different than a non-labeled request", but=20= the=20
> whole point of the sentence is that it's treated "as if it had no=20
> priority indication", that is, is non-labeled. Also, it seems that=20= there=20

I rephrased it, but basically the intent was that if, at the time of=20
arrival of the request, labeled and non-labeled requests are treated the= =20
same, there doesn't seem to be a point to say "sorry, don't know this=20
(but it wouldn't make any difference in any event)". In other words,=20
under normal, no-overload operations conditions, where all requests are=20
served, there is no need to reject requests that have the wrong label.

I don't think treating unknown namespaces the same as no R-P is right if= =20
the treatment differs. Rather than being routed into some inferior=20
corner of the network if I guessed the wrong namespace, I should be told= =20
that I should be using a different namespace.





I'm still confused. By definition, labeled and non-labeled requests may=20= be treated differently someplace in the network at any time. In any case, an= entity could make such a distinction between labels that it understands and= requests without labels. But it is impossible to make decisions based on a=20= label it does not understand, since it would have no way of knowing whether=20= the request might be treated differently at this moment if it understood the= label. What if, at the specific moment, one label would result in different= treatment while a second would not? Then what would be the decision for a 3= rd, unknown label?

I would hate to think that deciding how to process the incoming unknown=20= label would depend on whether there is currently overload, especially since=20= that question itself (is there overload) may depend on what the label is.

This again relates to my comments about the concept and use of "namespac= e". We are not concerned with someone "guessing" the wrong namespace, since=20= the user doesn't select it directly.

In a message dated 6/24/2003 11:54:45 PM Eastern Standard Time, hgs@cs.c= olumbia.edu writes:


>=20
> The 2nd paragraph (beginning "If an unknown resource ...") continue= to=20
> be a problem, since it seems to mandate an impossible operation: th= e=20
> element must make a decision based on the operation that should hav= e=20
> occurred for a namespace that it does not recognize. It must be ass= umed=20
> that the phrase "or would get a different treatment" intends to say= =20
> "than if the namespace were recognized". This second paragraph shou= ld be=20
> deleted.

I disagree. It simply says that if the treatment is different I ask for=20
X, but you don't know X, and if the current treatment for some=20
priorities is better than for default, I should be given a chance to=20
apply for this better treatment rather than being silently sent into the= =20
long queue.




I don't understand the point. It seems too complicated and unecessary. A= s an alternative to what I suggested (treat the request as if it had no R-P=20= header), it would be possible instead to always reject with "Unknown Resourc= e-Priority", except that code does not indicate that it was the namespace th= at was unknown. Always rejecting for an unknown namespace would be okay, sin= ce this can only happen due to misconfiguration in the originating device.


Mike Pierce
Artel
--part1_54.14345e76.2c2b3cad_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 exim@www1.ietf.org Thu Jun 26 04:25:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12217 for ; Thu, 26 Jun 2003 04:25:18 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5Q8Ooc23631 for sip-archive@odin.ietf.org; Thu, 26 Jun 2003 04:24:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VS3L-0005xI-8p; Thu, 26 Jun 2003 04:24:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VRxA-0005MA-PH for sip@optimus.ietf.org; Thu, 26 Jun 2003 04:18:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11823 for ; Thu, 26 Jun 2003 04:17:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VRws-0006YJ-00 for sip@ietf.org; Thu, 26 Jun 2003 04:17:42 -0400 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 19VRwi-0006Y6-00 for sip@ietf.org; Thu, 26 Jun 2003 04:17:32 -0400 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 9052E33AE9 for ; Thu, 26 Jun 2003 10:16:35 +0200 (CEST) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 824ED3F434 for ; Thu, 26 Jun 2003 10:28:49 +0200 (CEST) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003062610163428358 for ; Thu, 26 Jun 2003 10:16:34 +0200 Received: from molure.int-evry.fr (molure.int-evry.fr [157.159.10.18]) by sparte.int-evry.fr (Postfix) with ESMTP id 642B33F434 for ; Thu, 26 Jun 2003 10:28:49 +0200 (CEST) Received: from int-evry.fr (unknown [157.159.10.13]) by molure.int-evry.fr (Postfix) with ESMTP id 2D322C2182 for ; Thu, 26 Jun 2003 10:16:35 +0200 (CEST) Date: Thu, 26 Jun 2003 10:16:35 +0300 From: Hassan CHOUMAR X-Originating-IP: [157.159.230.20] User-Agent: IMHO/0.98.3 (Webmail for Roxen) To: sip@ietf.org Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=us-ascii In-Reply-To: <5.2.1.1.0.20030625110804.00baeb98@pop3.giandrea.com> MIME-Version: 1.0 Message-Id: <20030626081635.2D322C2182@molure.int-evry.fr> Content-Transfer-Encoding: 8bit Subject: [Sip] Problems with URL of serweb Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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, I installed server SER in my work, and I configured the SERWEB to use the graphic interface but I have a problem and that during launch of web page, I do not know which is the URL( www....) address to be put to see the graphic interface of SERWEB. Thank you in advance if anybody knows the answer Hassan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jun 26 04:25:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12216 for ; Thu, 26 Jun 2003 04:25:17 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5Q8Oop23630 for sip-archive@odin.ietf.org; Thu, 26 Jun 2003 04:24:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VS3K-0005x8-5A; Thu, 26 Jun 2003 04:24:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VRxA-0005MB-PE for sip@optimus.ietf.org; Thu, 26 Jun 2003 04:18:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11822 for ; Thu, 26 Jun 2003 04:17:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VRws-0006YG-00 for sip@ietf.org; Thu, 26 Jun 2003 04:17:42 -0400 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 19VRwh-0006Y5-00 for sip@ietf.org; Thu, 26 Jun 2003 04:17:32 -0400 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 93AA533AC2 for ; Thu, 26 Jun 2003 10:16:32 +0200 (CEST) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 8890D3F435 for ; Thu, 26 Jun 2003 10:28:46 +0200 (CEST) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003062610163118115 for ; Thu, 26 Jun 2003 10:16:31 +0200 Received: from molure.int-evry.fr (molure.int-evry.fr [157.159.10.18]) by sparte.int-evry.fr (Postfix) with ESMTP id 6C8B23F425 for ; Thu, 26 Jun 2003 10:28:46 +0200 (CEST) Received: from int-evry.fr (unknown [157.159.10.13]) by molure.int-evry.fr (Postfix) with ESMTP id EEB05C2181 for ; Thu, 26 Jun 2003 10:16:31 +0200 (CEST) Date: Thu, 26 Jun 2003 10:16:22 +0300 From: Hassan CHOUMAR X-Originating-IP: [157.159.230.20] User-Agent: IMHO/0.98.3 (Webmail for Roxen) To: sip@ietf.org Content-Type: text/plain; charset=iso-8859-1 In-Reply-To: <5.2.1.1.0.20030625110804.00baeb98@pop3.giandrea.com> MIME-Version: 1.0 Message-Id: <20030626081631.EEB05C2181@molure.int-evry.fr> Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA11827 Subject: [Sip] Problems with URL of serweb Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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: quoted-printable Hello,=20 I installed server SER in my work, and I configured the SERWEB to use the graphic interface but I have a problem and that during launch of web page, I do not know which is the URL( www....) address to be put to see the graphic interface of SERWEB. Thank you in advance if anybody knows the answer Hassan ------------------- > >Hi all > >i have some problems with ser. > >I've configurated ser with mysql. When I register a user with serctl it add=20 >to ser database but this is the only information that i can see on ser=20 >database. How can i register all information about ser activities on=20 >database? Where can i found some log of sip activities? > >I can't use my server sip with MSN. When I configure user for communication=20 >services MSN can't found server. How can i configure server for use with MSN? > > >thanks, >andrea=20 > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > CHOUMAR Hassan =20 cit=E9 universitaire de la pacaterie (chambre459) 91400 Orsay =20 Por :33/0675909977 Email: hmchoumar@hotmail.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 exim@www1.ietf.org Thu Jun 26 07:28:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15679 for ; Thu, 26 Jun 2003 07:28:41 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QBSCL18813 for sip-archive@odin.ietf.org; Thu, 26 Jun 2003 07:28:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VUv3-0004qO-Jz; Thu, 26 Jun 2003 07:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VUuR-0004mr-80 for sip@optimus.ietf.org; Thu, 26 Jun 2003 07:27:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15665 for ; Thu, 26 Jun 2003 07:27:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VUuQ-0007Y8-00 for sip@ietf.org; Thu, 26 Jun 2003 07:27:22 -0400 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 19VUuF-0007Xu-00 for sip@ietf.org; Thu, 26 Jun 2003 07:27:11 -0400 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 2E08733BF9; Thu, 26 Jun 2003 13:25:58 +0200 (CEST) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 944333F416; Thu, 26 Jun 2003 13:38:14 +0200 (CEST) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003062613255727400 ; Thu, 26 Jun 2003 13:25:57 +0200 Received: from molure.int-evry.fr (molure.int-evry.fr [157.159.10.18]) by sparte.int-evry.fr (Postfix) with ESMTP id 5DF1D3F405; Thu, 26 Jun 2003 13:38:14 +0200 (CEST) Received: from int-evry.fr (unknown [157.159.10.13]) by molure.int-evry.fr (Postfix) with ESMTP id 3CC4DC2181; Thu, 26 Jun 2003 13:25:57 +0200 (CEST) Date: Thu, 26 Jun 2003 13:25:57 +0300 From: Hassan CHOUMAR X-Originating-IP: [157.159.15.145] Subject: Re: [Sip] [Serusers] Problems with ser User-Agent: IMHO/0.98.3 (Webmail for Roxen) Cc: sip@ietf.org To: giAndrea Content-Type: text/plain; charset=iso-8859-1 In-Reply-To: <5.2.1.1.0.20030625110804.00baeb98@pop3.giandrea.com> MIME-Version: 1.0 Message-Id: <20030626112557.3CC4DC2181@molure.int-evry.fr> Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA15666 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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: quoted-printable Hello, When you add the users through (serctl), it is necessary to make the following points: - Activation of the data base mysql by commands: > / etc. / init.d / mysqld start - Enter the following directory: cd / usr / sbin/ - Type the command: =20 usr/sbin> Serctl add < use > < password > < mail > Later return on the basis of data of SER by: > Mysql Mysql > show databases; Mysql > uses(wears out) ser; Mysql > show tables; Mysql > select * from subscribers; Hassan=20 ------------------- > >Hi all > >i have some problems with ser. > >I've configurated ser with mysql. When I register a user with serctl it add=20 >to ser database but this is the only information that i can see on ser=20 >database. How can i register all information about ser activities on=20 >database? Where can i found some log of sip activities? > >I can't use my server sip with MSN. When I configure user for communication=20 >services MSN can't found server. How can i configure server for use with MSN? > > >thanks, >andrea=20 > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > CHOUMAR Hassan =20 cit=E9 universitaire de la pacaterie (chambre459) 91400 Orsay =20 Por :33/0675909977 Email: hmchoumar@hotmail.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 exim@www1.ietf.org Thu Jun 26 08:04:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16714 for ; Thu, 26 Jun 2003 08:04:36 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QC47G30467 for sip-archive@odin.ietf.org; Thu, 26 Jun 2003 08:04:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VVTt-0007qk-QD; Thu, 26 Jun 2003 08:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VVTG-0007q8-W5 for sip@optimus.ietf.org; Thu, 26 Jun 2003 08:03:23 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16414; Thu, 26 Jun 2003 08:03:20 -0400 (EDT) Message-Id: <200306261203.IAA16414@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org, sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 26 Jun 2003 08:03:20 -0400 Subject: [Sip] I-D ACTION:draft-mahy-sip-connect-reuse-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 : Connection Reuse in the Session Initiation Protocol (SIP) Author(s) : R. Mahy Filename : draft-mahy-sip-connect-reuse-00.txt Pages : 12 Date : 2003-6-25 When SIP entities use a connection oriented protocol to send a request, they typically originate their connections from an ephemeral port. The SIP protocol includes mechanisms which insure that responses to a request, and new requests sent in the original direction reuse an existing connection. However, new requests sent in the opposite direction are unlikely to reuse the existing connection. This frequently causes a pair of SIP entities to use one connection for requests sent in each direction, and can result in potential scaling and performance problems. This document proposes requirements and a mechanism which address this deficiency. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mahy-sip-connect-reuse-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mahy-sip-connect-reuse-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mahy-sip-connect-reuse-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-26080228.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mahy-sip-connect-reuse-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mahy-sip-connect-reuse-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-26080228.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jun 26 11:11:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00839 for ; Thu, 26 Jun 2003 11:11:37 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QFBBB00985 for sip-archive@odin.ietf.org; Thu, 26 Jun 2003 11:11:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYOs-0000Bp-36; Thu, 26 Jun 2003 11:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VYNt-0008M5-NP for sip@optimus.ietf.org; Thu, 26 Jun 2003 11:10:01 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00429; Thu, 26 Jun 2003 11:09:56 -0400 (EDT) Message-Id: <200306261509.LAA00429@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 26 Jun 2003 11:09:56 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-callee-caps-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 : Indicating User Agent Capabilities in the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg et al. Filename : draft-ietf-sip-callee-caps-00.txt Pages : 40 Date : 2003-6-26 This specification defines mechanisms by which a Session Initiation Protocol (SIP) user agent can convey its capabilities and characteristics to other user agents. These capabilities are conveyed as parameters of the Contact header field. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-callee-caps-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-callee-caps-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-callee-caps-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-26100803.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-callee-caps-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-callee-caps-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-26100803.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 exim@www1.ietf.org Thu Jun 26 14:26:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13208 for ; Thu, 26 Jun 2003 14:26:26 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NGOBq02018 for sip-archive@odin.ietf.org; Mon, 23 Jun 2003 12:24:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UU6q-0000W6-Vz; Mon, 23 Jun 2003 12:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UQX3-0006kz-JO for sip@optimus.ietf.org; Mon, 23 Jun 2003 08:34:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18076 for ; Mon, 23 Jun 2003 08:34:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UQWn-0001nP-00 for sip@ietf.org; Mon, 23 Jun 2003 08:34:33 -0400 Received: from mail5.infineon.com ([203.126.245.197] helo=mail5-i.infineon.com) by ietf-mx with esmtp (Exim 4.12) id 19UQWb-0001nD-00 for sip@ietf.org; Mon, 23 Jun 2003 08:34:22 -0400 Received: from sinse004.ap.infineon.com (sgpk993a.sin.infineon.com [172.17.65.75]) by mail5-i.infineon.com (8.11.7+Sun/8.11.6) with ESMTP id h5NCXo028687 for ; Mon, 23 Jun 2003 20:33:51 +0800 (SGT) Received: from blrw502w.blr.infineon.com ([172.29.142.21]) by sinse004.ap.infineon.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N36F6VDH; Mon, 23 Jun 2003 20:33:50 +0800 Received: by blrw502w.blr.infineon.com with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Jun 2003 17:56:51 +0530 Message-ID: <0C674B14EAEBD61196D900B0D03DB49F04FDE1@blrw502w.blr.infineon.com> From: "Shetty Bharathraj (IFIN DC COM)" To: "'sip@ietf.org'" Date: Mon, 23 Jun 2003 17:56:43 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Sip] SDP doubts Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 have some questions on implementation of SDP decoder. We are doing interoperable testing our SIP stack with RADVISION prolab manager, the SDP test scripts available with this tools are not consistent with the syntax of RFC 2327. Some of them are as follows. * In Some of SDP test scripts, CRLF or LF is missing at the end of SDP script(Last field). * The connection field(c=) and time(t=) are not mandatory in scripts available in prolab manager. * The order of the fields, email field and phone fields are not as per the RFC2327(e-mail field should come before the phone field). How do we go ahead with the testing of SDP with these kind of test cases?. Regards Bharath Bharathraj Shetty A.N. Software Engineer, Infineon Technologies India Pvt.Ltd. 10th Floor, Discoverer Block, International Tech Park, Whitefield Road, Bangalore - 560 066. India. Tel :+91-80-8410017/18 (Extn.2039) Fax :+91-80-8410012 email : bharathraj.shetty@infineon.com *Disclaimer* This e-mail and any attachments are confidential and may be subject to legal or some other professional privilege. They are intended solely for the attention and use of the named addressee(s). They must not be disclosed to any person without authorization. This e-mail and any attachments are also subject to copyright. They may only be copied or distributed with the consent of the copyright owner. If you are not a named addressee you must not use, disclose, retain or reproduce all or any part of the information contained in this e-mail or any attachments. If you have received this email by mistake please notify the sender immediately by return email and delete or destroy all copies of the email. Any confidentiality, privilege or copyright is not waived or lost because this email has been sent to you by mistake _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jun 26 14:49:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14563 for ; Thu, 26 Jun 2003 14:49:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QIn5X02801 for sip-archive@odin.ietf.org; Thu, 26 Jun 2003 14:49:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vbnp-0000ik-7Z; Thu, 26 Jun 2003 14:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vbn2-0000iF-Oa for sip@optimus.ietf.org; Thu, 26 Jun 2003 14:48:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14452 for ; Thu, 26 Jun 2003 14:47:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Vbml-0004oh-00 for sip@ietf.org; Thu, 26 Jun 2003 14:47:55 -0400 Received: from machine77.level3.com ([209.244.4.106] helo=f1ee40-19.idc1.level3.com) by ietf-mx with esmtp (Exim 4.12) id 19Vbma-0004oT-00 for sip@ietf.org; Thu, 26 Jun 2003 14:47:44 -0400 Received: from idc1exc0001.corp.global.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8p2+Sun/8.8.8) with SMTP id SAA28510 for ; Thu, 26 Jun 2003 18:47:09 GMT Received: from idc1exc0004.corp.global.level3.com ([10.1.8.20]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 26 Jun 2003 12:47:09 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Thu, 26 Jun 2003 12:47:09 -0600 Message-ID: <3DB099919328BA41905F651A6EF83976B4DDB2@idc1exc0004.corp.global.level3.com> Thread-Topic: Stuck in Proceeding after Cancel Thread-Index: AcM8E1iAgX/+fUrRS2CdwOWVygIaAQ== From: "Hearty, John" To: X-OriginalArrivalTime: 26 Jun 2003 18:47:09.0182 (UTC) FILETIME=[590179E0:01C33C13] Content-Transfer-Encoding: quoted-printable Subject: [Sip] Stuck in Proceeding after Cancel Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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: quoted-printable We have come across what may be a bug in RFC 3261. The following bug is closely related, but it is not clear to me it is the same. http://bugs.sipit.net/sipwg/show_bug.cgi?id=3D706 The issue involves the Invite client transaction state machine. As the above bug describes, there is no timer to exit the Proceeding state. This is normally fine, as it is an application decision when give up. However, when the application does give up and sends a Cancel, we still rely on the UAS to return the forced 487 to properly exit the Proceeding state. If the 487 (or any final response) is never returned for whatever reason, we remain stuck in Proceeding. I am not clear if there should be a timer specified in the spec to allow exit from this state in this particular scenario, or if this should also be considered an application layer problem and covered under the existing bug. John Hearty Level3 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jun 26 14:51:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14713 for ; Thu, 26 Jun 2003 14:51:53 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFirp20512 for sip-archive@odin.ietf.org; Wed, 25 Jun 2003 11:44:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCS0-0005Di-IQ; Wed, 25 Jun 2003 11:44:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBz1-0008Bp-MT for sip@optimus.ietf.org; Wed, 25 Jun 2003 11:14:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04909 for ; Tue, 24 Jun 2003 23:40:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19V18m-0001no-00 for sip@ietf.org; Tue, 24 Jun 2003 23:40:12 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19V18X-0001na-00 for sip@ietf.org; Tue, 24 Jun 2003 23:39:57 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h5P3dNkM011953; Tue, 24 Jun 2003 23:39:24 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h5P3dKN30979; Tue, 24 Jun 2003 23:39:21 -0400 Message-ID: <3EF91880.2090002@cs.columbia.edu> Date: Tue, 24 Jun 2003 23:35:28 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030603 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: sip@ietf.org Subject: Re: [Sip] Comments of Resource Priority header References: <1e4.bd0cbeb.2c29ddb1@aol.com> In-Reply-To: <1e4.bd0cbeb.2c29ddb1@aol.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 Mpierce1@aol.com wrote: > 4.2 "Unknown namespace" error: The sentence with "it MAY serve ... if > and only if" seems strange. The "if and only if" appears to be > indicating a "MUST" situation. The rest of the sentence is confusing, > since it is saying that it depends on "if the request would ... > experience treatment no different than a non-labeled request", but the > whole point of the sentence is that it's treated "as if it had no > priority indication", that is, is non-labeled. Also, it seems that there I rephrased it, but basically the intent was that if, at the time of arrival of the request, labeled and non-labeled requests are treated the same, there doesn't seem to be a point to say "sorry, don't know this (but it wouldn't make any difference in any event)". In other words, under normal, no-overload operations conditions, where all requests are served, there is no need to reject requests that have the wrong label. I don't think treating unknown namespaces the same as no R-P is right if the treatment differs. Rather than being routed into some inferior corner of the network if I guessed the wrong namespace, I should be told that I should be using a different namespace. > > The 2nd paragraph (beginning "If an unknown resource ...") continue to > be a problem, since it seems to mandate an impossible operation: the > element must make a decision based on the operation that should have > occurred for a namespace that it does not recognize. It must be assumed > that the phrase "or would get a different treatment" intends to say > "than if the namespace were recognized". This second paragraph should be > deleted. I disagree. It simply says that if the treatment is different I ask for X, but you don't know X, and if the current treatment for some priorities is better than for default, I should be given a chance to apply for this better treatment rather than being silently sent into the long queue. > The description in the 2nd paragraph would not be the allowed operation > in any case that I am aware of. For any use of this Resource-Priority > header, the user specifies the appropriate priority value for the call > being attempted. Therefore, no device (UAC) is allowed to reattempt a > failed call at a different (presumably higher) level. If the call is > rejected due to the attempted unauthorized use of a level or if the call > is blocked when attempted at a particular level, the only option is to > notify the user of this fact. If the user decides to reattempt the call > with a higher level, the UAC can not prevent this. But no UAC can be > allowed to automatically use a higher level. While I can see that 'upgrading' priority is unlikely to be useful (although maybe human nature...), changing namespaces will be common. > > In any case, the rules for use of this Resource-Priority header should > be left to documents describing specific uses (namespaces). This is just a MAY and simply describes UAC behavior. > > B.1 Reference to "critic-ecp" should be added before "flash-override" in > the list. The reference to "critic-ecp" should be deleted from the 2nd > paragraph since it was added to the 1st. A relative order needs to be > explicitly specified as requires by Section 12. This should specify that > "Routine" is the default. The following is suggested for the 1st paragraph: > > This document defines the namespace "dsn". The namespace "dsn" (Defense > Switched Network) contains the following priority values in the relative > order listed: "critic-ecp", "flash-override", "flash", immediate", > "priority", "and "routine", with "critic-ecp as the highest and > "routine" as the lowest. The default is "routine". Maybe you and James can get together and figure out whether critic-ecp exists or not. He told me to remove it; I'm not familiar enough with the DSN to make the call. > > B.3 and B.4 > There is a confusion here since GETS and TDR are really the same thing. > These can not be split into separate namespaces. Again, please discuss with my co-author. He insisted on two. > Since the IANA considerations states that "the registration must > indicate the default", it is not possible to have a namespace with only > one value. It is necessary to define a second value which can be > designated as the default even if that value is never used in signaling. Noted. > > B.4 The current defined value is incorrect. "Authorized_emergency" is > not the same as 911 or 112 calls placed by the general public. > "Authorized emergency" belongs with GETS. In the previous drafts, > authorized emergency and 911 were intended as two distinct values within > one namespace that covered GETS-type calls, 911-type calls, and normal > calls (i.e., the regular "public network"). > > I believe the correct approach is to define a single namespace for the > "public network" environment with the following values (at a minimum): > - Authorized emergency (GETS, etc.) > - Public emergency (911, 112, etc.) > - Normal > Of course, "normal" is the default. Further, I know that there are some > who believe that multiple "Authorized emergency" levels are needed, > similar to what is defined for the Wireless Priority System mentioned in > Section 3. > > If this issue of the definition of multiple values to support authorized > emergency (GETS or TDR), public emergency calling (e.g., 911), and > various other priority schemes that might reside in the same "public" > network can't be quickly resolved, these should be removed from this > draft, to be added later by IANA registration. Since this doesn't seem like a topic that is likely to be resolved soon, I would agree that punting on all of them seems the right thing. I don't want to further delay this while this is being hashed out by third parties. > > B.4 I'm not sure why the second paragraph under B.4 for the Defense Red > Switched Network was added. (This should have been a new section > number.) If kept, it also should specify that "Routine" is the default. Section heading was omitted by accident; added. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu Jun 26 15:25:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17254 for ; Thu, 26 Jun 2003 15:25:36 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QJP8f21017 for sip-archive@odin.ietf.org; Thu, 26 Jun 2003 15:25:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VcMg-0005Mq-3x; Thu, 26 Jun 2003 15:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VcM1-0005J7-8V for sip@optimus.ietf.org; Thu, 26 Jun 2003 15:24:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17123 for ; Thu, 26 Jun 2003 15:24:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VcLj-000594-00 for sip@ietf.org; Thu, 26 Jun 2003 15:24:03 -0400 Received: from broadsoft.com ([198.104.184.110]) by ietf-mx with esmtp (Exim 4.12) id 19VcLZ-00057X-00 for sip@ietf.org; Thu, 26 Jun 2003 15:23:53 -0400 Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.12.9) id h5QJMI2m054973; Thu, 26 Jun 2003 15:22:18 -0400 (EDT) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] Simple question about NOTIFY Date: Thu, 26 Jun 2003 15:27:25 -0400 Message-ID: <000201c33c18$f9cfc250$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: <796456A0F96AD511A0AC009027B0F7410D009403@IL27EXM08.cig.mot.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 > As I am reading through the two RFCs 3261, > and 3265, I am just wondering if a > SIP NOTIFY can be forked? Yes a NOTIFY can be forked. > Also if it can be forked, can someone please > explain how will that work, since NOTIFY > would be sent in a dialog, and according to > the rules set in section 12 of RFC 3261, > the Request-URI would need to be set to the > remote target (which is the contact address > of the subscriber), and a Proxy is just > supposed to forward to that target. Requests can fork within a dialog during fault-tolerant/redundancy situations where a device's added Contact or Record-Route entry resolves to multiple address. ICMP errors or retry exhaustion can trigger the target advancing. The NOTIFY can also fork outside of dialog when the "subscription" was not established through the typical SIP mechanisms. RFC 3265 section 3.2 discusses subscriptions created by not using a 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 exim@www1.ietf.org Thu Jun 26 15:59:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18902 for ; Thu, 26 Jun 2003 15:59:11 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QJwhl00846 for sip-archive@odin.ietf.org; Thu, 26 Jun 2003 15:58:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vcse-0008RO-3d; Thu, 26 Jun 2003 15:58:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vcro-0008JK-OW for sip@optimus.ietf.org; Thu, 26 Jun 2003 15:57:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18676; Thu, 26 Jun 2003 15:56:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VcpW-0005Og-00; Thu, 26 Jun 2003 15:54:50 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19VcpL-0005OR-00; Thu, 26 Jun 2003 15:54:39 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h5QJrZP22914; Thu, 26 Jun 2003 14:53:35 -0500 From: Robert Sparks To: sip-implementors@cs.columbia.edu, sip@ietf.org, simple@ietf.org Content-Type: text/plain Message-Id: <1056657212.1916.82.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 26 Jun 2003 14:53:33 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] SIPIT 13 Registration Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 Registration for SIPIT 13 is open. The event will be hosted by Mitel in the brand-new Brookstreet Hotel and Conference Center in Ottawa August 18-24th. Information about the event and facilities as well as online registration can be found at: http://www.mitel.com/sipit/index.cfm Registration through the website will close on July 18th. See you there, 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 exim@www1.ietf.org Thu Jun 26 16:52:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20973 for ; Thu, 26 Jun 2003 16:52:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QKq8u24491 for sip-archive@odin.ietf.org; Thu, 26 Jun 2003 16:52:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vdis-0006HK-5T; Thu, 26 Jun 2003 16:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vdip-0006H4-7X for sip@optimus.ietf.org; Thu, 26 Jun 2003 16:51:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20963 for ; Thu, 26 Jun 2003 16:51:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Vdin-0005ru-00 for sip@ietf.org; Thu, 26 Jun 2003 16:51:57 -0400 Received: from broadsoft.com ([198.104.184.110]) by ietf-mx with esmtp (Exim 4.12) id 19Vdic-0005rS-00 for sip@ietf.org; Thu, 26 Jun 2003 16:51:46 -0400 Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.12.9) id h5QKpMaC061476; Thu, 26 Jun 2003 16:51:25 -0400 (EDT) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] Simple question about NOTIFY Date: Thu, 26 Jun 2003 16:56:28 -0400 Message-ID: <000801c33c25$6a64bff0$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: <796456A0F96AD511A0AC009027B0F7410D009404@IL27EXM08.cig.mot.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 a NOTIFY can fork, then it should be > possible to fork a re-INVITE also. > Should not it? Yes most requests can fork within a dialog. > Assuming the same reasoning as you provided > for NOTIFY in a dialog. In which case the > following text in RFC 3261 is not really true. > > **** > Section 14.1, Pg 87 in RFC 3261. > > Unlike an INVITE, which can fork, a re-INVITE > will never fork, and > therefore, only ever generate a single final > response. The reason a > re-INVITE will never fork is that the > Request-URI identifies the > target as the UA instance it established the > dialog with, rather than > identifying an address-of-record for the user. > **** I agree; the text does not appear to be true. > Regards > - Ajay > > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: Thursday, June 26, 2003 2:27 PM > To: sip@ietf.org > Subject: RE: [Sip] Simple question about NOTIFY > > > As I am reading through the two RFCs 3261, > > and 3265, I am just wondering if a > > SIP NOTIFY can be forked? > > Yes a NOTIFY can be forked. > > > Also if it can be forked, can someone please > > explain how will that work, since NOTIFY > > would be sent in a dialog, and according to > > the rules set in section 12 of RFC 3261, > > the Request-URI would need to be set to the > > remote target (which is the contact address > > of the subscriber), and a Proxy is just > > supposed to forward to that target. > > Requests can fork within a dialog during > fault-tolerant/redundancy situations where > a device's added Contact or Record-Route entry > resolves to multiple address. ICMP errors > or retry exhaustion can trigger the target > advancing. > > The NOTIFY can also fork outside of dialog > when the "subscription" was not established > through the typical SIP mechanisms. RFC 3265 > section 3.2 discusses subscriptions created > by not using a 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 > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Jun 27 18:31:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23854 for ; Fri, 27 Jun 2003 18:31:27 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RMV1v30787 for sip-archive@odin.ietf.org; Fri, 27 Jun 2003 18:31:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W1jK-0007Iz-As; Fri, 27 Jun 2003 18:30:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W0FO-0001Wn-6n for sip@optimus.ietf.org; Fri, 27 Jun 2003 16:55:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20347 for ; Fri, 27 Jun 2003 16:54:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19W0F7-0006Kv-00 for sip@ietf.org; Fri, 27 Jun 2003 16:54:49 -0400 Received: from machine77.level3.com ([209.244.4.106] helo=f1ee40-19.idc1.level3.com) by ietf-mx with esmtp (Exim 4.12) id 19W0Ew-0006KZ-00 for sip@ietf.org; Fri, 27 Jun 2003 16:54:38 -0400 Received: from idc1exc0001.corp.global.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8p2+Sun/8.8.8) with SMTP id SAA25108; Fri, 27 Jun 2003 18:44:51 GMT Received: from idc1exc0004.corp.global.level3.com ([10.1.8.20]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 27 Jun 2003 12:44:51 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [Sip] Stuck in Proceeding after Cancel Date: Fri, 27 Jun 2003 12:44:50 -0600 Message-ID: <3DB099919328BA41905F651A6EF83976B4DDB5@idc1exc0004.corp.global.level3.com> Thread-Topic: [Sip] Stuck in Proceeding after Cancel Thread-Index: AcM8E1iAgX/+fUrRS2CdwOWVygIaAQAxxnRA From: "Hearty, John" To: , "Jonathan Rosenberg" X-OriginalArrivalTime: 27 Jun 2003 18:44:51.0237 (UTC) FILETIME=[31327D50:01C33CDC] Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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: quoted-printable Jonathan, I found the following text that covers this scenario, so it may not be considered a bug. I don't particularly like the idea of an unnamed timer though, and the below text could be a bit more explicit about when to start the unnamed timer (upon sending Cancel). I would appreciate this scenario being added to the existing bugzilla bug so it is also included in some future clarification of the Invite client transaction section. Note that both the transaction corresponding to the original request and the CANCEL transaction will complete independently. However, a UAC canceling a request cannot rely on receiving a 487 (Request Terminated) response for the original request, as an RFC 2543- compliant UAS will not generate such a response. If there is no final response for the original request in 64*T1 seconds (T1 is Rosenberg, et. al. Standards Track [Page 54] =20 RFC 3261 SIP: Session Initiation Protocol June 2002 defined in Section 17.1.1.1), the client SHOULD then consider the original transaction cancelled and SHOULD destroy the client transaction handling the original request. John Hearty Level3 > -----Original Message----- > From: Hearty, John > Sent: Thursday, June 26, 2003 12:47 PM > To: sip@ietf.org > Subject: [Sip] Stuck in Proceeding after Cancel >=20 > We have come across what may be a bug in RFC 3261. The following bug is > closely related, but it is not clear to me it is the same. >=20 > http://bugs.sipit.net/sipwg/show_bug.cgi?id=3D706 >=20 > The issue involves the Invite client transaction state machine. As the > above bug describes, there is no timer to exit the Proceeding state. > This is normally fine, as it is an application decision when give up. >=20 > However, when the application does give up and sends a Cancel, we still > rely on the UAS to return the forced 487 to properly exit the Proceeding > state. If the 487 (or any final response) is never returned for > whatever reason, we remain stuck in Proceeding. >=20 > I am not clear if there should be a timer specified in the spec to allow > exit from this state in this particular scenario, or if this should also > be considered an application layer problem and covered under the > existing bug. >=20 > John Hearty > Level3 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 exim@www1.ietf.org Fri Jun 27 18:39:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24333 for ; Fri, 27 Jun 2003 18:39:51 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RMdPh07173 for sip-archive@odin.ietf.org; Fri, 27 Jun 2003 18:39:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W1ry-0001js-4C; Fri, 27 Jun 2003 18:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W1rs-0001jW-1C for sip@optimus.ietf.org; Fri, 27 Jun 2003 18:38:56 -0400 Received: from jalapeno.cc.columbia.edu (IDENT:cu41754@jalapeno.cc.columbia.edu [128.59.59.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24287 for ; Fri, 27 Jun 2003 18:38:36 -0400 (EDT) Received: from cs.columbia.edu (dhcp39.cs.columbia.edu [128.59.19.239]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h5RMbsJ7004908 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 27 Jun 2003 18:37:54 -0400 (EDT) Message-ID: <3EFCC73C.3060003@cs.columbia.edu> Date: Fri, 27 Jun 2003 18:37:48 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: sip@ietf.org References: <145.146d1100.2c2b3caa@aol.com> In-Reply-To: <145.146d1100.2c2b3caa@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Resource Priority header - multiple namespaces Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 Mpierce1@aol.com wrote: > one case is independent from "high" for the other. Namespace does not > exist for use by the user. Why not? > > In practice, in actual use, the orginator does not select (and then > maybe change, as you wrote) a namespace. The device is configured to use > the right one, while the person selects the proper priority level. If While this may be true in current devices, I see no reason that this has to be true in the future. If I have a generic SIP device, why shouldn't this be usable in, say, a Q.735 network and a GETS-enabled network or, most likely, a network where I can reach both? > there are cases in which one of several namespaces could be used, it is > not the human who selects the "namespace", except indirectly by what is > dialed. The human in unaware of this concept. For example, if a military > phone is setup and authorized to handle MLPP priorities, an emergency > worker with GETS access may use the phone, perform the magic procedures > to get such GETS authorization, which may result in a Resource-Priority > header being sent with namespace=gets, priority=enabled (to use the > values currently in the draft). It does not result in sending two > different priority values with some other entity being given the chance > to decide which is better. In fact, the treatments may be different, > with one using preemption and the other queuing for resources. I'm not arguing that there should be two simultaneously, in the same request. That was removed a few email iterations ago... > > No, it should never happen that the user would ask "please use namespace > X if you can, or Y if that suits you". The request is always "use > namespace X with priority level Z and do the best you can", (with the > actual user being unaware of the namespace). If the call is blocked, the > user may do something else (which might not have anything to do with a > namespace). > > I'm mostly afraid that any attempts to describe use of multiple > namespaces will cause significant difficulty in moving this draft > forward, since there are lots of unexplained interactions. Namespaces are only used sequentially, not simultaneously. If you reach a device that understands namespace X, but you supply Y, it helps if the device tells you that you should be using X. After all, you might well have authorization for both or just forgotten to reconfigure the phone from one mode to another. I fail to see the problem. > > Mike Pierce > Artel > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Jun 27 18:50:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24673 for ; Fri, 27 Jun 2003 18:50:34 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RMo8X11391 for sip-archive@odin.ietf.org; Fri, 27 Jun 2003 18:50:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W22c-0002xC-QF; Fri, 27 Jun 2003 18:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W229-0002wj-JN for sip@optimus.ietf.org; Fri, 27 Jun 2003 18:49:48 -0400 Received: from motgate6.mot.com (motgate6.mot.com [144.189.100.106]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24659 for ; Fri, 27 Jun 2003 18:49:13 -0400 (EDT) Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id h5QJxq4S004707 for ; Thu, 26 Jun 2003 12:59:52 -0700 (MST) Received: from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h5QJxojL002784 for ; Thu, 26 Jun 2003 14:59:51 -0500 Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2657.2) id ; Thu, 26 Jun 2003 14:59:50 -0500 Message-ID: <796456A0F96AD511A0AC009027B0F7410D009404@IL27EXM08.cig.mot.com> From: Idnani Ajaykumar-AIDNANI1 To: "'brett@broadsoft.com'" , sip@ietf.org Subject: RE: [Sip] Simple question about NOTIFY Date: Thu, 26 Jun 2003 14:59:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) 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: , If a NOTIFY can fork, then it should be possible to fork a re-INVITE also. Should not it? Assuming the same reasoning as you provided for NOTIFY in a dialog. In which case the following text in RFC 3261 is not really true. **** Section 14.1, Pg 87 in RFC 3261. Unlike an INVITE, which can fork, a re-INVITE will never fork, and therefore, only ever generate a single final response. The reason a re-INVITE will never fork is that the Request-URI identifies the target as the UA instance it established the dialog with, rather than identifying an address-of-record for the user. **** Regards - Ajay -----Original Message----- From: Brett Tate [mailto:brett@broadsoft.com] Sent: Thursday, June 26, 2003 2:27 PM To: sip@ietf.org Subject: RE: [Sip] Simple question about NOTIFY > As I am reading through the two RFCs 3261, > and 3265, I am just wondering if a > SIP NOTIFY can be forked? Yes a NOTIFY can be forked. > Also if it can be forked, can someone please > explain how will that work, since NOTIFY > would be sent in a dialog, and according to > the rules set in section 12 of RFC 3261, > the Request-URI would need to be set to the > remote target (which is the contact address > of the subscriber), and a Proxy is just > supposed to forward to that target. Requests can fork within a dialog during fault-tolerant/redundancy situations where a device's added Contact or Record-Route entry resolves to multiple address. ICMP errors or retry exhaustion can trigger the target advancing. The NOTIFY can also fork outside of dialog when the "subscription" was not established through the typical SIP mechanisms. RFC 3265 section 3.2 discusses subscriptions created by not using a 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Jun 27 19:32:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26094 for ; Fri, 27 Jun 2003 19:32:04 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RNVMM25368 for sip-archive@odin.ietf.org; Fri, 27 Jun 2003 19:31:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W2gJ-0006Tv-JM; Fri, 27 Jun 2003 19:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W2g1-0006SO-PZ for sip@optimus.ietf.org; Fri, 27 Jun 2003 19:30:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26041 for ; Fri, 27 Jun 2003 19:30:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19W2g0-0007NP-00 for sip@ietf.org; Fri, 27 Jun 2003 19:30:44 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19W2fo-0007MD-00 for sip@ietf.org; Fri, 27 Jun 2003 19:30:32 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5RNTu2K020495; Fri, 27 Jun 2003 16:29:56 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIP33903; Fri, 27 Jun 2003 16:22:33 -0700 (PDT) Date: Fri, 27 Jun 2003 16:31:19 -0700 Subject: Re: [Sip] Problems with URL of serweb Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: sip@ietf.org To: Hassan CHOUMAR From: Rohan Mahy In-Reply-To: <20030626081631.EEB05C2181@molure.int-evry.fr> Message-Id: <74476E1D-A8F7-11D7-8BFD-0003938AF740@cisco.com> Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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: quoted-printable Hi, Please direct your questions directly to iptel.org. This mailing list=20= is for discussion of development of the SIP protocol, not usage of a=20 specific implementation. thank you. -rohan mahy co-chair SIP WG On Thursday, June 26, 2003, at 12:16 AM, Hassan CHOUMAR wrote: > Hello, > I installed server SER in my work, and I configured the SERWEB to use > the graphic interface but I have a problem and that during launch of > web page, I do not know which is the URL( www....) address to be put > to see the graphic interface of SERWEB. > Thank you in advance if anybody knows the answer > Hassan > ------------------- >> >> Hi all >> >> i have some problems with ser. >> >> I've configurated ser with mysql. When I register a user with serctl > it add >> to ser database but this is the only information that i can see on > ser >> database. How can i register all information about ser activities on >> database? Where can i found some log of sip activities? >> >> I can't use my server sip with MSN. When I configure user for > communication >> services MSN can't found server. How can i configure server for use > with MSN? >> >> >> thanks, >> andrea >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > CHOUMAR Hassan > cit=E9 universitaire de la pacaterie (chambre459) > 91400 Orsay > Por :33/0675909977 > Email: hmchoumar@hotmail.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 exim@www1.ietf.org Fri Jun 27 19:48:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26621 for ; Fri, 27 Jun 2003 19:48:36 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RNm7532224 for sip-archive@odin.ietf.org; Fri, 27 Jun 2003 19:48:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W2wj-0008Mj-ER; Fri, 27 Jun 2003 19:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W2wL-0008Ge-Ss for sip@optimus.ietf.org; Fri, 27 Jun 2003 19:47:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26600 for ; Fri, 27 Jun 2003 19:47:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19W2wK-0007Tr-00 for sip@ietf.org; Fri, 27 Jun 2003 19:47:36 -0400 Received: from [206.171.8.220] (helo=dev1.mbird.com) by ietf-mx with esmtp (Exim 4.12) id 19W2w8-0007TB-00 for sip@ietf.org; Fri, 27 Jun 2003 19:47:24 -0400 Received: from abollineni (dhcp10-102.mbird.com [192.168.10.102]) by dev1.mbird.com (8.11.1/8.11.1) with SMTP id h5RNjQW13351 for ; Fri, 27 Jun 2003 16:45:26 -0700 (PDT) From: "Anilkumar Bollineni" To: Date: Fri, 27 Jun 2003 16:45:37 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Information on SIP user alias Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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, Can any body tell me answer to the following question. When a user who has ALIAS, sending INVITE can include his alias number?. Thanks in advance, -Anil _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Jun 27 21:52:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29633 for ; Fri, 27 Jun 2003 21:52:50 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5S1p9m30149 for sip-archive@odin.ietf.org; Fri, 27 Jun 2003 21:51:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W4rm-0007pq-Hs; Fri, 27 Jun 2003 21:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W4qn-0007pb-50 for sip@optimus.ietf.org; Fri, 27 Jun 2003 21:50:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29558 for ; Fri, 27 Jun 2003 21:49:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19W4qV-0000PD-00 for sip@ietf.org; Fri, 27 Jun 2003 21:49:43 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19W4qF-0000P4-00 for sip@ietf.org; Fri, 27 Jun 2003 21:49:27 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h5S1n3kM023196; Fri, 27 Jun 2003 21:49:03 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h5S1n1N03609; Fri, 27 Jun 2003 21:49:01 -0400 Message-ID: <3EFCF322.9060902@cs.columbia.edu> Date: Fri, 27 Jun 2003 21:45:06 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com CC: sip@ietf.org References: <54.14345e76.2c2b3cad@aol.com> In-Reply-To: <54.14345e76.2c2b3cad@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Resource Priority header - unknown namespace Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 Mpierce1@aol.com wrote: > I'm still confused. By definition, labeled and non-labeled requests may > be treated differently someplace in the network at any time. In any If there's no overload and no PSTN labeling (e.g., simple gateway priority), during normal operation, all requests will effectively be treated the same. I've updated the draft with a more structured presentation of the error cases. I'm not sure all three error modes (lenient, semi-strict, strict) are necessary, but I think they span the gamut of what's plausible. We can either - enumerate all three (as in this revision) - pick one - or remain silent on the issue and leave it up to the implementation to do what makes sense. 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 exim@www1.ietf.org Mon Jun 30 11:16:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00403 for ; Mon, 30 Jun 2003 11:16:55 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5UFGRB17847 for sip-archive@odin.ietf.org; Mon, 30 Jun 2003 11:16:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X0Nu-0004b6-LI; Mon, 30 Jun 2003 11:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X0NQ-0004a5-N3 for sip@optimus.ietf.org; Mon, 30 Jun 2003 11:15:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00306 for ; Mon, 30 Jun 2003 11:15:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X0N9-0001iY-00 for sip@ietf.org; Mon, 30 Jun 2003 11:15:15 -0400 Received: from machine77.level3.com ([209.244.4.106] helo=f1ee40-19.idc1.level3.com) by ietf-mx with esmtp (Exim 4.12) id 19X0Mv-0001hu-00 for sip@ietf.org; Mon, 30 Jun 2003 11:15:01 -0400 Received: from idc1exc0001.corp.global.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8p2+Sun/8.8.8) with SMTP id PAA28399; Mon, 30 Jun 2003 15:13:56 GMT Received: from idc1exc0004.corp.global.level3.com ([10.1.8.20]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 30 Jun 2003 09:13:55 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [Sip] Stuck in Proceeding after Cancel Date: Mon, 30 Jun 2003 09:13:55 -0600 Message-ID: <3DB099919328BA41905F651A6EF83976B4DDB9@idc1exc0004.corp.global.level3.com> Thread-Topic: [Sip] Stuck in Proceeding after Cancel Thread-Index: AcM+zDyEenkYciyrSoGxTq7rX5OcJwAS2SCA From: "Hearty, John" To: "Christer Holmberg (JO/LMF)" , , "Jonathan Rosenberg" X-OriginalArrivalTime: 30 Jun 2003 15:13:55.0849 (UTC) FILETIME=[393CC790:01C33F1A] Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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: quoted-printable From the duration, it sounds like timer B, though I didn't want to presume anything. However, the text is not clear when said timer gets set. Also, if it actually is timer B which is set when the original request is sent, it could be stopped or ignored (exact action regarding the timer is not specified) once a provisional response is received. The below text appears to suggest said timer continues to run in this specific scenario. This just seems like another of the countless clarifications that the evolving specification may need. If I had to make the clarification, it would be to reset timer B for the Invite Client Transaction upon sending a Cancel for that Invite. That would fix it, and provide an equal time for a 487 response that a provisional response or other non-2xx final response had. I think 487 is a special case compared to other non-2xx final responses. John Hearty Level3 > -----Original Message----- > From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com] > Sent: Sunday, June 29, 2003 11:55 PM > To: Hearty, John; sip@ietf.org; Jonathan Rosenberg > Subject: RE: [Sip] Stuck in Proceeding after Cancel >=20 >=20 > Hi, >=20 > Isn't the timer you are talking about timer B? I agree that it would be > more clear to write "timer B" instead of "64*T1 seconds". >=20 > I also think it is important to remember that timer B may expire AFTER > CANCEL has been sent, but BEFORE 487 has been received, and since the > transaction will be terminated there is no guarantee an ACK will be sent > when 487 eventually arrives. But, I guess this is similar to any case > where the final response is sent too late by the UAS...? >=20 > Regards, >=20 > Christer Holmberg > Ericsson Finland >=20 >=20 >=20 > > I found the following text that covers this scenario, so it > > may not be > > considered a bug. I don't particularly like the idea of an unnamed > > timer though, and the below text could be a bit more explicit > > about when > > to start the unnamed timer (upon sending Cancel). I would appreciate > > this scenario being added to the existing bugzilla bug so it is also > > included in some future clarification of the Invite client transaction > > section. > > > > Note that both the transaction corresponding to the > > original request > > and the CANCEL transaction will complete independently. However, a > > UAC canceling a request cannot rely on receiving a 487 (Request > > Terminated) response for the original request, as an RFC 2543- > > compliant UAS will not generate such a response. If there is no > > final response for the original request in 64*T1 seconds (T1 is > > > > > > > > > > Rosenberg, et. al. Standards Track > > [Page 54] > > > > > > RFC 3261 SIP: Session Initiation Protocol > > June 2002 > > > > > > defined in Section 17.1.1.1), the client SHOULD then consider the > > original transaction cancelled and SHOULD destroy the client > > transaction handling the original request. > > > > > > John Hearty > > Level3 > > > > > -----Original Message----- > > > From: Hearty, John > > > Sent: Thursday, June 26, 2003 12:47 PM > > > To: sip@ietf.org > > > Subject: [Sip] Stuck in Proceeding after Cancel > > > > > > We have come across what may be a bug in RFC 3261. The > > following bug > > is > > > closely related, but it is not clear to me it is the same. > > > > > > http://bugs.sipit.net/sipwg/show_bug.cgi?id=3D706 > > > > > > The issue involves the Invite client transaction state machine. As > > the > > > above bug describes, there is no timer to exit the Proceeding state. > > > This is normally fine, as it is an application decision > > when give up. > > > > > > However, when the application does give up and sends a Cancel, we > > still > > > rely on the UAS to return the forced 487 to properly exit the > > Proceeding > > > state. If the 487 (or any final response) is never returned for > > > whatever reason, we remain stuck in Proceeding. > > > > > > I am not clear if there should be a timer specified in the spec to > > allow > > > exit from this state in this particular scenario, or if this should > > also > > > be considered an application layer problem and covered under the > > > existing bug. > > > > > > John Hearty > > > Level3 > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP 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 exim@www1.ietf.org Mon Jun 30 12:22:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04063 for ; Mon, 30 Jun 2003 12:22:40 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5UGMDb05288 for sip-archive@odin.ietf.org; Mon, 30 Jun 2003 12:22:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X1Pl-0001Mm-2q; Mon, 30 Jun 2003 12:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X1PS-0001MF-8K for sip@optimus.ietf.org; Mon, 30 Jun 2003 12:21:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04031 for ; Mon, 30 Jun 2003 12:21:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X1PQ-0002M3-00 for sip@ietf.org; Mon, 30 Jun 2003 12:21:40 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19X1PE-0002L4-00 for sip@ietf.org; Mon, 30 Jun 2003 12:21:29 -0400 Received: from dynamicsoft.com ([63.113.46.50]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h5UGIfiB002055; Mon, 30 Jun 2003 12:18:42 -0400 (EDT) Message-ID: <3F0062DC.2080401@dynamicsoft.com> Date: Mon, 30 Jun 2003 12:18:36 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mankin@psg.com CC: rohan@cisco.com, dwillis@dynamicsoft.com, sip@ietf.org, jon.peterson@neustar.biz, hardie@qualcomm.com, erik.nordmark@sun.com References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: IESG Discuss Comments on Symmetric Response Routing Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 My apologies for the delay. I managed to get in a revision to the draft before the deadline which addresses these comments. Until it appears in the archives, you can find it at: http://www.jdrosen.net/papers/draft-ietf-sip-symmetric-response-01.txt I also converted to xml while I was at it, so the general formatting should be better. Responses below. Allison Mankin wrote: > The IESG reviewed draft-ietf-sip-symmetric-response-00.txt and there were > two sets of Discuss comments. They do not seem too hard to address. In > addition, the FQDNs in the draft need to be changed to example.com. OK, fixed. I also changed public addresses to be within 192.0.2/24. The private addresses remain with 10/8. > > Below are the comments. They are also in the ID tracker. > > Allison > > Comments: > > Ted Hardie: > First, let me say that a large number of the issues I had > with the document turned out to be very well documented > in the IAB considerations section of the draft. A few > other issues: > > In Section 3: > > When the client sends the request, if the request is sent using UDP, > the client MUST be prepared to receive the response on the same > socket the request was sent on. Specifically, it MUST be prepared to > receive the response on the same IP address and port present in the > source IP address and source port of the request. For backwards > compatibility, the client MUST still be prepared to receive a > response on the port indicated in the sent-by field of the topmost > Via header field value, as specified in Section 18.1.1 of SIP [1]. > > > It seems pretty clear from the "on the same socket" that the following > sentence means the IP address and port present in the source IP > and port of the request _when it is sent_. I think it would be clearer, > though, to use phrasing like "it MUST be prepared to receive the > response on the same IP address and port it used to populate > the source IP address and source port of the request.". OK, I changed the wording to the text you suggest. I made this change everywhere the term "socket" was used, in order to be explicit about what is meant. > > Also in Section 3: > > To keep the binding fresh, the client SHOULD retransmit its INVITE every 20 > seconds or so. These retransmissions will need to take place even > after receiving a provisional response. > > based on the idea the one minute seems to be a common UDP binding lifetime. > Section 9.3 notes, however, that there is no way to determine the UDP binding > lifetime. Is there anyway to introduce a growing/shrinking algorithm > to this for cases where the binding lifetime is much longer (to avoid the > aggressiveness of 20 seconds for an arbitrary period of time) or to handle > the cases where the binding lifetime is shorter than 20+transmission time to > the NAT (since this has to handle the NAT being at some arbitrary place in > the topology). Yes. STUN describes a binary search algorithm for trying to detect the lifetime. That is not without peril as well, and the issues there are documented in STUN. I added the following text: A UA MAY execute the binding lifetime discovery algorithm in Section 10.2 of RFC 3489 to determine the actual binding lifetime in the NAT. If it is longer than 1 minute, the client SHOULD increase the interval for request retransmissions up to half of the discovered lifetime. If it is shorter than one minute, it SHOULD decrease the interval for request retransmissions to half of the discovered lifetime. Note that discovery of binding lifetimes can be unreliable. See Section 14.3 of RFC 3489. > > In the initial section of 9: > > The client can then perform an additional registration, > using this address in a Contact header. This would allow a client to > receive incoming requests, such as INVITE, on the socket through > which the registration was sent. > > As is noted below that point, there are cases in which the port binding > is only valid for the server to which the original registration was sent. > Will the Contact header "leak" that so that a direction connection between a > different sip agent (user or proxy) might attempt to use it? If so, a forward > pointer to the limitation might be useful here. This is possible with the Path extension to SIP (RFC 3327). That spec allows for servers between the client and the registrar to indicate that they need to be on the path of requests from the registrar to the client. Its a good idea to include a reference to that and a brief discussion. Here is what I added: In many cases, the server to whom the registration is sent won't be the registrar itself, but rather, a proxy which then sends the request to the registrar. In such a case, any incoming requests for the client must traverse the proxy to whom the registration was directly sent. The Path header extension to SIP allows the proxy to indicate that it must be on the path of such requests. and this introduced some additional brittleness that I documented: If the registrar and the server to whom the client sent its REGISTER request are not the same, the approach will only work if the server uses the Path header field. There is not an easy and reliable way for the server to determine that the Path header should be used for a registration. Using Path when the address in the topmost Via header field is a private address will usually work, but may result in usage of Path when it is not actually needed. > > I would personally consider the UNSAF document a normative reference, > but this is not a big deal. RFC 3424 is informational. I dont think you can have a normative reference to an informational document. As such, I have kept the UNSAF reference as informational. > > Erik Nordmark: > The security considerations section doesn't set a very good example. > It could easily be read as "we didn't look hard for security issues". > > Thus I'd like it to provide the reasoning that lead to thinking > that there are no added security issues. Presumably a paragraph or two would > suffice. OK. Here is the text I put in there: When a server uses this specification, responses that it sends will now include the source port where the request came from. In some instances, the source address and port of a request are sensitive information. If they are sensitive, requests SHOULD be protected by using SIP over TLS . In such a case, this specification does not provide any response routing functions (as these only work with TCP); it merely provides the client with information about the source port as seen by the server. It is possible that an attacker might try to disrupt service to a client by acting as a man-in-the-middle, modifying the rport parameter in a Via header in a request sent by a client. Removal of this parameter will prevent clients from behind NATs from receiving service. Addition of the parameter will generally have no impact. Of course, if an attacker is capable of launching a man-in-the-middle attack, there are many other ways of denying service, such as merely discarding the request. Therefore, this attack does not seem significant. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Jun 30 18:25:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19676 for ; Mon, 30 Jun 2003 18:25:38 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5UMPBm21880 for sip-archive@odin.ietf.org; Mon, 30 Jun 2003 18:25:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X754-0005gP-4W; Mon, 30 Jun 2003 18:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X74Y-0005cp-Re for sip@optimus.ietf.org; Mon, 30 Jun 2003 18:24:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19658 for ; Mon, 30 Jun 2003 18:24:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X74V-0004oR-00 for sip@ietf.org; Mon, 30 Jun 2003 18:24:28 -0400 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 19X74L-0004o3-00 for sip@ietf.org; Mon, 30 Jun 2003 18:24:17 -0400 Received: from txdwillis (bdsl.66.12.12.254.gte.net [66.12.12.254]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h5UMNR24012724 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 30 Jun 2003 17:23:28 -0500 From: "Dean Willis" To: Cc: , , Date: Mon, 30 Jun 2003 17:23:16 -0500 Message-ID: <000301c33f56$346ad5e0$ee036e3f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: quoted-printable Subject: [Sip] Jon Peterson exiting Chair role in SIP WG Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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: quoted-printable You've probably noticed that Jon Peterson was recently selected to serve = on the IESG as an Area Director for the Transport Area. Of course, the SIP Working Group is in the Transport Area. As it is slightly unusual for someone to be their own AD on an ongoing basis, Jon is retiring from his role as a co-chair of the SIP working = group, effective immediately. Rohan and I will continue as co-chairs. I believe Allison Mankin will be continuing as the primary AD for SIP, but we can expect that Jon will be very able to assist in the IESG review and supervision of our work. Jon has been a big help to the SIP community during his time as a = co-chair of our working group, and I think we all owe him a big "Thank You!" for = his efforts. Of course, we'll probably owe him one even more for the hard = work he'll be putting in on the IESG. As I understand it, that's not exactly = an easy job. So, I hope my ASCII art skills hold up . . . TTTTTTTT H H A N N K K SSSSS =20 T H H A A NN N K K S =20 T HHHHHH AAAAA N N N KKK SSSSS =20 T H H A A N NN K K S =20 T H H A A N N K K SSSSS =20 J OOO N N J O O NN N J O O N N N J J O O N NN JJJJ OOO N N -- 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 exim@www1.ietf.org Mon Jun 30 20:35:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23964 for ; Mon, 30 Jun 2003 20:35:38 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h610Z9F16139 for sip-archive@odin.ietf.org; Mon, 30 Jun 2003 20:35:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X96r-0004Bh-NF; Mon, 30 Jun 2003 20:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X96M-0004B8-HH for sip@optimus.ietf.org; Mon, 30 Jun 2003 20:34:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23927 for ; Mon, 30 Jun 2003 20:34:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X96F-0005al-00 for sip@ietf.org; Mon, 30 Jun 2003 20:34:23 -0400 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by ietf-mx with esmtp (Exim 4.12) id 19X964-0005a9-00 for sip@ietf.org; Mon, 30 Jun 2003 20:34:12 -0400 Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HHB00F0LLJ74R@firewall.wcom.com> for sip@ietf.org; Tue, 01 Jul 2003 00:33:07 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HHB00C01LJ79J@dgismtp03.wcomnet.com>; Tue, 01 Jul 2003 00:33:07 +0000 (GMT) Received: from hsinnreich2 ([166.50.104.170]) by dgismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HHB00997LJ06F@dgismtp03.wcomnet.com>; Tue, 01 Jul 2003 00:33:06 +0000 (GMT) Date: Mon, 30 Jun 2003 19:33:00 -0500 From: Henry Sinnreich Subject: RE: [Sip] Jon Peterson exiting Chair role in SIP WG In-reply-to: <000301c33f56$346ad5e0$ee036e3f@txdwillis> To: "'Dean Willis'" , sip@ietf.org Cc: rohan@cisco.com, jon.peterson@neustar.biz, mankin@psg.com Message-id: <000201c33f68$573e3870$aa6832a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 Thanks Jon! And please contribute to the IETF getting its act finally together and making SIMPLE _THE_ presence and IM standard. It is much overdue. Henry Henry Sinnreich MCI 400 International Parkway Richardson, Texas 75081 USA Have you disconnected the PBX? > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Dean Willis > Sent: Monday, June 30, 2003 5:23 PM > To: sip@ietf.org > Cc: rohan@cisco.com; jon.peterson@neustar.biz; mankin@psg.com > Subject: [Sip] Jon Peterson exiting Chair role in SIP WG > > > > You've probably noticed that Jon Peterson was recently > selected to serve on the IESG as an Area Director for the > Transport Area. Of course, the SIP Working Group is in the > Transport Area. > > As it is slightly unusual for someone to be their own AD on > an ongoing basis, Jon is retiring from his role as a co-chair > of the SIP working group, effective immediately. Rohan and I > will continue as co-chairs. I believe Allison Mankin will be > continuing as the primary AD for SIP, but we can expect that > Jon will be very able to assist in the IESG review and > supervision of our work. > > Jon has been a big help to the SIP community during his time > as a co-chair of our working group, and I think we all owe > him a big "Thank You!" for his efforts. Of course, we'll > probably owe him one even more for the hard work he'll be > putting in on the IESG. As I understand it, that's not > exactly an easy job. > > So, I hope my ASCII art skills hold up . . . > > > TTTTTTTT H H A N N K K SSSSS > T H H A A NN N K K S > T HHHHHH AAAAA N N N KKK SSSSS > T H H A A N NN K K S > T H H A A N N K K SSSSS > > J OOO N N > J O O NN N > J O O N N N > J J O O N NN > JJJJ OOO N N > > > -- > 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip