From exim@www1.ietf.org Tue Jul 1 08:52: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 IAA16706 for ; Tue, 1 Jul 2003 08:52:40 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h61CqEh16593 for sip-archive@odin.ietf.org; Tue, 1 Jul 2003 08:52:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XKc5-0004J1-VA; Tue, 01 Jul 2003 08: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 19XKbY-0004IY-KB for sip@optimus.ietf.org; Tue, 01 Jul 2003 08:51:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16582 for ; Tue, 1 Jul 2003 08:51:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XKbS-00048D-00 for sip@ietf.org; Tue, 01 Jul 2003 08:51:22 -0400 Received: from almso2.att.com ([192.128.166.71] helo=almso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 19XKb2-00047g-00 for sip@ietf.org; Tue, 01 Jul 2003 08:50:56 -0400 Received: from attrh0i.attrh.att.com ([135.37.94.54]) by almso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h61CmHfQ012327 for ; Tue, 1 Jul 2003 08:49:59 -0400 Received: from acclust02evs1.ugd.att.com (135.37.16.9) by attrh0i.attrh.att.com (6.5.032) id 3EFE074D0008293A; Tue, 1 Jul 2003 08:49:24 -0400 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] Jon Peterson exiting Chair role in SIP WG Date: Tue, 1 Jul 2003 08:49:53 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A04408890@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [Sip] Jon Peterson exiting Chair role in SIP WG Thread-Index: AcM/VqMtDblbv3cuSVK+4mYCTzKCeQAd8pww From: "Roy, Radhika R, ALABS" To: "Dean Willis" , Cc: , , 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 Inline [RRR] 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. [RRR] We also believe that it would be enormously helpful, if Jon continues to provides his insights in furthering the technical discussions as one of us as he has been doing for a long time, if possible. Radhika R. Roy rrroy@att.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 Tue Jul 1 10:06: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 KAA00473 for ; Tue, 1 Jul 2003 10:06:37 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h61E6Ap20965 for sip-archive@odin.ietf.org; Tue, 1 Jul 2003 10:06:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XLli-0005R3-Q2; Tue, 01 Jul 2003 10:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wrdh-0000WR-Mp for sip@optimus.ietf.org; Mon, 30 Jun 2003 01:56:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19571 for ; Mon, 30 Jun 2003 01:55:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Wrde-0003lC-00 for sip@ietf.org; Mon, 30 Jun 2003 01:55:42 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19WrdT-0003l9-00 for sip@ietf.org; Mon, 30 Jun 2003 01:55:31 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5U5tJw2000763; Mon, 30 Jun 2003 07:55:19 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 30 Jun 2003 07:55:35 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Hearty, John'" , sip@ietf.org, Jonathan Rosenberg Subject: RE: [Sip] Stuck in Proceeding after Cancel Date: Mon, 30 Jun 2003 07:55:04 +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, 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". 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...? Regards, Christer Holmberg Ericsson Finland > 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=706 > > > > 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 Tue Jul 1 10:54:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00474 for ; Tue, 1 Jul 2003 10:06:37 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h61E6AG20964 for sip-archive@odin.ietf.org; Tue, 1 Jul 2003 10:06:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XLlk-0005RE-1K; Tue, 01 Jul 2003 10:06:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XDbK-0003Rb-IJ for sip@optimus.ietf.org; Tue, 01 Jul 2003 01:22: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 BAA02107 for ; Tue, 1 Jul 2003 01:22:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XDbH-0007GC-00 for sip@ietf.org; Tue, 01 Jul 2003 01:22:43 -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 19XDb4-0007Fi-00 for sip@ietf.org; Tue, 01 Jul 2003 01:22:30 -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.6b) with ESMTP id h615L1G5028297; Tue, 1 Jul 2003 07:21:02 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 1 Jul 2003 07:21:21 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Hearty, John'" , sip@ietf.org, Jonathan Rosenberg Subject: RE: [Sip] Stuck in Proceeding after Cancel Date: Tue, 1 Jul 2003 07:20:54 +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 John, >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. Correct. However, I can't find any text saying that, and the bug description in bugzilla says it's pretty much an implementation issue. However, is it even said somewhere that/if/how timer B will be stopped when we receive a FINAL response, and go to the completed state? At that point we DO start timer D, but if we haven't stopped timer B it will most likely expire before timer D, so there would be no need for timer D in the first place, would there? >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. I agree. Reset it, or not touch it at all, but certainly not stop it. >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. Also, I wonder if it would be a good idea to also reset timer B when we get a provisional response, if we use PRACK, to equal time for the INVITE final response and PRACK final response. Regards, Christer Holmberg Ericsson Finland > > 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 > > > > > > Hi, > > > > 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". > > > > 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...? > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > > 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=706 > > > > > > > > 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 Tue Jul 1 13:49: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 NAA09075 for ; Tue, 1 Jul 2003 13:49:11 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QIcEF30576 for sip-archive@odin.ietf.org; Thu, 26 Jun 2003 14:38:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VbdB-0007ri-D0; Thu, 26 Jun 2003 14:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vbcu-0007rJ-Nd for sip@optimus.ietf.org; Thu, 26 Jun 2003 14:37: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 OAA13964 for ; Thu, 26 Jun 2003 14:37:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Vbcs-0004j6-00 for sip@ietf.org; Thu, 26 Jun 2003 14:37:42 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19Vbch-0004j1-00 for sip@ietf.org; Thu, 26 Jun 2003 14:37:31 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h5QIbPiu010545 for ; Thu, 26 Jun 2003 11:37:25 -0700 (MST) Received: from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h5QIbNxE030686 for ; Thu, 26 Jun 2003 13:37:24 -0500 Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2657.2) id ; Thu, 26 Jun 2003 13:37:23 -0500 Message-ID: <796456A0F96AD511A0AC009027B0F7410D009403@IL27EXM08.cig.mot.com> From: Idnani Ajaykumar-AIDNANI1 To: sip@ietf.org Date: Thu, 26 Jun 2003 13:37:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33C11.FB2D8C52" Subject: [Sip] Simple question about NOTIFY Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C33C11.FB2D8C52 Content-Type: text/plain Hi All, As I am reading through the two RFCs 3261, and 3265, I am just wondering if a SIP NOTIFY can be forked? My guess is it cannot be forked, but I would like to double check :-). 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. Appreciate your help. Thanks and Regards - Ajay ------_=_NextPart_001_01C33C11.FB2D8C52 Content-Type: text/html Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxucz0iaHR0 cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPE1FVEEgSFRUUC1FUVVJ Vj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0K DQoNCjxtZXRhIG5hbWU9UHJvZ0lkIGNvbnRlbnQ9V29yZC5Eb2N1bWVudD4NCjxtZXRhIG5hbWU9 R2VuZXJhdG9yIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEwIj4NCjxtZXRhIG5hbWU9T3JpZ2lu YXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMCI+DQo8bGluayByZWw9RmlsZS1MaXN0IGhy ZWY9ImNpZDpmaWxlbGlzdC54bWxAMDFDMzNCRTguMTFGQURBRDAiPg0KPCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQogPG86T2ZmaWNlRG9jdW1lbnRTZXR0aW5ncz4NCiAgPG86RG9Ob3RSZWx5T25D U1MvPg0KIDwvbzpPZmZpY2VEb2N1bWVudFNldHRpbmdzPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQogPHc6V29yZERvY3VtZW50Pg0KICA8dzpTcGVsbGluZ1N0 YXRlPkNsZWFuPC93OlNwZWxsaW5nU3RhdGU+DQogIDx3OkdyYW1tYXJTdGF0ZT5DbGVhbjwvdzpH cmFtbWFyU3RhdGU+DQogIDx3OkRvY3VtZW50S2luZD5Eb2N1bWVudEVtYWlsPC93OkRvY3VtZW50 S2luZD4NCiAgPHc6RW52ZWxvcGVWaXMvPg0KICA8dzpEaXNwbGF5SG9yaXpvbnRhbERyYXdpbmdH cmlkRXZlcnk+MDwvdzpEaXNwbGF5SG9yaXpvbnRhbERyYXdpbmdHcmlkRXZlcnk+DQogIDx3OkRp c3BsYXlWZXJ0aWNhbERyYXdpbmdHcmlkRXZlcnk+MDwvdzpEaXNwbGF5VmVydGljYWxEcmF3aW5n R3JpZEV2ZXJ5Pg0KICA8dzpVc2VNYXJnaW5zRm9yRHJhd2luZ0dyaWRPcmlnaW4vPg0KICA8dzpD b21wYXRpYmlsaXR5Pg0KICAgPHc6Rm9vdG5vdGVMYXlvdXRMaWtlV1c4Lz4NCiAgIDx3OlNoYXBl TGF5b3V0TGlrZVdXOC8+DQogICA8dzpBbGlnblRhYmxlc1Jvd0J5Um93Lz4NCiAgIDx3OkZvcmdl dExhc3RUYWJBbGlnbm1lbnQvPg0KICAgPHc6RG9Ob3RVc2VIVE1MUGFyYWdyYXBoQXV0b1NwYWNp bmcvPg0KICAgPHc6TGF5b3V0UmF3VGFibGVXaWR0aC8+DQogICA8dzpMYXlvdXRUYWJsZVJvd3NB cGFydC8+DQogICA8dzpVc2VXb3JkOTdMaW5lQnJlYWtpbmdSdWxlcy8+DQogIDwvdzpDb21wYXRp YmlsaXR5Pg0KICA8dzpCcm93c2VyTGV2ZWw+TWljcm9zb2Z0SW50ZXJuZXRFeHBsb3JlcjQ8L3c6 QnJvd3NlckxldmVsPg0KIDwvdzpXb3JkRG9jdW1lbnQ+DQo8L3htbD48IVtlbmRpZl0tLT4NCjxz dHlsZT4NCjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDsNCgltc28t Zm9udC1jaGFyc2V0OjI7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6YXV0bzsNCgltc28tZm9u dC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6MCAyNjg0MzU0NTYgMCAwIC0y MTQ3NDgzNjQ4IDA7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29Ob3JtYWwsIGxp Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttc28tc3R5bGUtcGFyZW50OiIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9y cGhhbjsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i Ow0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 DQoJdGV4dC11bmRlcmxpbmU6c2luZ2xlO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCgltc28tYmlkaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OkFyaWFsOw0KCW1zby1hc2NpaS1mb250LWZhbWlseTpBcmlhbDsNCgltc28taGFuc2kt Zm9udC1mYW1pbHk6QXJpYWw7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6QXJpYWw7DQoJY29sb3I6 d2luZG93dGV4dDt9DQpzcGFuLlNwZWxsRQ0KCXttc28tc3R5bGUtbmFtZToiIjsNCgltc28tc3Bs LWU6eWVzO30NCnNwYW4uR3JhbUUNCgl7bXNvLXN0eWxlLW5hbWU6IiI7DQoJbXNvLWdyYW0tZTp5 ZXM7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMjVpbiAxLjBpbiAxLjI1aW47DQoJbXNvLWhlYWRlci1tYXJnaW46LjVpbjsNCgltc28tZm9v dGVyLW1hcmdpbjouNWluOw0KCW1zby1wYXBlci1zb3VyY2U6MDt9DQpkaXYuU2VjdGlvbjENCgl7 cGFnZTpTZWN0aW9uMTt9DQotLT4NCjwvc3R5bGU+DQo8IS0tW2lmIGd0ZSBtc28gMTBdPg0KPHN0 eWxlPg0KIC8qIFN0eWxlIERlZmluaXRpb25zICovIA0KIHRhYmxlLk1zb05vcm1hbFRhYmxlDQoJ e21zby1zdHlsZS1uYW1lOiJUYWJsZSBOb3JtYWwiOw0KCW1zby10c3R5bGUtcm93YmFuZC1zaXpl OjA7DQoJbXNvLXRzdHlsZS1jb2xiYW5kLXNpemU6MDsNCgltc28tc3R5bGUtbm9zaG93OnllczsN Cgltc28tc3R5bGUtcGFyZW50OiIiOw0KCW1zby1wYWRkaW5nLWFsdDowaW4gNS40cHQgMGluIDUu NHB0Ow0KCW1zby1wYXJhLW1hcmdpbjowaW47DQoJbXNvLXBhcmEtbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCjwvc3R5bGU+DQo8IVtlbmRpZl0tLT4N CjwvaGVhZD4NCg0KPGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlIHN0eWxl PSd0YWItaW50ZXJ2YWw6LjVpbic+DQoNCjxkaXYgY2xhc3M9U2VjdGlvbjE+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz5IaSBBbGwsPG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBz aXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFt aWx5OkFyaWFsJz5BcyBJIGFtIHJlYWRpbmcgdGhyb3VnaCB0aGUgdHdvIDxzcGFuIGNsYXNzPVNw ZWxsRT5SRkNzPC9zcGFuPg0KMzI2MSwgYW5kIDMyNjUsIEkgYW0ganVzdCB3b25kZXJpbmcgaWYg YSBTSVAgTk9USUZZIGNhbiBiZSA8c3BhbiBjbGFzcz1HcmFtRT5mb3JrZWQ/PC9zcGFuPg0KTXkg Z3Vlc3MgaXMgaXQgY2Fubm90IGJlIGZvcmtlZCwgYnV0IEkgd291bGQgbGlrZSB0byBkb3VibGUg PHNwYW4gY2xhc3M9R3JhbUU+Y2hlY2sNCjwvc3Bhbj48L3NwYW4+PC9mb250Pjxmb250IGZhY2U9 V2luZ2RpbmdzPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTpXaW5nZGluZ3M7DQptc28tYXNjaWkt Zm9udC1mYW1pbHk6QXJpYWw7bXNvLWhhbnNpLWZvbnQtZmFtaWx5OkFyaWFsO21zby1iaWRpLWZv bnQtZmFtaWx5Og0KQXJpYWw7bXNvLWNoYXItdHlwZTpzeW1ib2w7bXNvLXN5bWJvbC1mb250LWZh bWlseTpXaW5nZGluZ3M7bXNvLW5vLXByb29mOnllcyc+PHNwYW4NCnN0eWxlPSdtc28tY2hhci10 eXBlOnN5bWJvbDttc28tc3ltYm9sLWZvbnQtZmFtaWx5OldpbmdkaW5ncyc+Sjwvc3Bhbj48L3Nw YW4+PC9mb250Pjxmb250DQpmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTpBcmlh bCc+LiBBbHNvIGlmIGl0IGNhbiBiZSBmb3JrZWQsIGNhbg0Kc29tZW9uZSBwbGVhc2UgZXhwbGFp biBob3cgd2lsbCB0aGF0IHdvcmssIHNpbmNlIE5PVElGWSB3b3VsZCBiZSBzZW50IGluIGENCmRp YWxvZywgYW5kIGFjY29yZGluZyB0byB0aGUgcnVsZXMgc2V0IGluIHNlY3Rpb24gMTIgb2YgUkZD IDMyNjEsIHRoZQ0KUmVxdWVzdC1VUkkgd291bGQgbmVlZCB0byBiZSBzZXQgdG8gdGhlIHJlbW90 ZSB0YXJnZXQgKHdoaWNoIGlzIHRoZSBjb250YWN0DQphZGRyZXNzIG9mIHRoZSBzdWJzY3JpYmVy KSwgYW5kIGEgUHJveHkgaXMganVzdCBzdXBwb3NlZCB0byBmb3J3YXJkIHRvIHRoYXQNCnRhcmdl dC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZv bnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250 LWZhbWlseTpBcmlhbCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPkFwcHJlY2lhdGUgeW91ciBoZWxwLjxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBz aXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFt aWx5OkFyaWFsJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+VGhhbmtzIGFuZCBSZWdhcmRzPG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBm YWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJp YWwnPi0gQWpheTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8L2Jv ZHk+DQoNCjwvaHRtbD4NCg== ------_=_NextPart_001_01C33C11.FB2D8C52-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 2 03:34:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27108 for ; Wed, 2 Jul 2003 03:34:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xc8A-00022Z-VJ for sip-archive@odin.ietf.org; Wed, 02 Jul 2003 03:34:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h627YIQW007844 for sip-archive@odin.ietf.org; Wed, 2 Jul 2003 03:34:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xc7t-00021O-TG; Wed, 02 Jul 2003 03:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xc7k-00020z-3Q for sip@optimus.ietf.org; Wed, 02 Jul 2003 03:33: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 DAA27086 for ; Wed, 2 Jul 2003 03:33:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xc7h-0006rW-00 for sip@ietf.org; Wed, 02 Jul 2003 03:33:49 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19Xc7b-0006rO-00 for sip@ietf.org; Wed, 02 Jul 2003 03:33:44 -0400 Received: from dynamicsoft.com ([63.113.46.115]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h627WPiB002728; Wed, 2 Jul 2003 03:32:37 -0400 (EDT) Message-ID: <3F028A80.9090209@dynamicsoft.com> Date: Wed, 02 Jul 2003 03:32:16 -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: Mary Barnes CC: Henning Schulzrinne , Paul Kyzivat , "'sip@ietf.org'" References: <1B54FA3A2709D51195C800508BF9386A09DABCE5@zrc2c000.us.nortel.com> In-Reply-To: <1B54FA3A2709D51195C800508BF9386A09DABCE5@zrc2c000.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Callerprefs: Additional Nit/editorial comments Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org 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 Mary, Now that I've finished splitting the document, I've been able to incorporate these nits which are still applicable. Responses below. Mary Barnes wrote: > I also did a detailed review of draft-ietf-sip-callerprefs-08.txt and beyond > some of the points already made by Ben and Bob, I had the following > additional minor NITs/Editorial comments. There also a couple of points > that I'll put in separate threads as they could invoke some additional > discussion. Also, I did try to avoid duplicating comments made by Ben and > Bob and apologize if I have inadvertently duplicated anything. > > Footing: > - there is no "." in the "et" of the phrase "et al." This is an error in the tool I was using. I've converted to xml2rfc in the process of the split, and so this problem is now gone. > > Section 3, page 7: > - Feature Preferences: "described" -> "describe" Fixed. > - Target Set: "URI" -> "URI(s)" Fixed. > > Section 5: > - Para 5: "instant of time" -> "instance of time" Fixed. > > Section 7.3: > - Last para: "featuer" -> "feature" Fixed. > > Section 7.4: > - Para 5: I know you have an example further down in section 7.4.1, but I'm > thinking an example after this paragraph might be useful. I had to read the > last few sentences many several times and I'm still not absolutely certain I > understand it given that the example in 7.4.1 has the "require" flag set. > So, I think another example here (or forward referenced to one in 7.4.1) > would be extremely helpful. I actually added a lot of text in the UA Behavior section of the new draft to elaborate the behaviors as they relate to "require" and "explicit". I think that this text, in conjunction with the example, should suffice. The use cases spec also provides a lot more examples, so I don't want to put too many into caller prefs itself. > > Section 9.6 Automata: > - Would IVR be considered here as well? Yes. I added a mention of it. > > Section 9.12 Priority: > - I would suggest changing the definition of "emergency" to "The device > supports calls in the case of an emergency situation" as I think the phrase > "emergency calls" tends to so closely associated with an E911 type of call, > whereas I think this is meant to be in terms of the device being one that > user wants to be the primary contact for personal emergency situations. Good point. Fixed. > > Section 9.15 Schemes: > - Example of typical use: "Choosing get" -> "Choosing to get" Fixed. > > Section 9.17 Message Server: > - Is this category intended to also apply to IVR? Or, would IVR just be > considered automata? No, an IVR is not a message server. > > Section 9.18 Is Focus: > - this is just a consistency thing, but it seems that this should just be > "Focus" rather than "isfocus" or 9.17 should be "ismsgserver". Its a legacy thing. We've been using isfocus in the conferencing stuff for a while, and people are already using that specific name. > > Section 17 Informative References: > - [27] needs to be updated with the RFC number: RFC 3515 This reference isn't there any more. There is no longer a need to enumerate the packages. I merely reference the IANA registry. 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 Wed Jul 2 03:43:16 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27382 for ; Wed, 2 Jul 2003 03:43:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XcGO-00032L-I7 for sip-archive@odin.ietf.org; Wed, 02 Jul 2003 03:42:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h627gmA8011673 for sip-archive@odin.ietf.org; Wed, 2 Jul 2003 03:42:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XcFe-0002qP-Mu; Wed, 02 Jul 2003 03:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XcF0-0002pc-Rz for sip@optimus.ietf.org; Wed, 02 Jul 2003 03:41:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27349 for ; Wed, 2 Jul 2003 03:41:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XcEy-0006ws-00 for sip@ietf.org; Wed, 02 Jul 2003 03:41:20 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19XcEx-0006wM-00 for sip@ietf.org; Wed, 02 Jul 2003 03:41:19 -0400 Received: from dynamicsoft.com ([63.113.46.115]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h627ediB002731; Wed, 2 Jul 2003 03:40:41 -0400 (EDT) Message-ID: <3F028C6D.4070304@dynamicsoft.com> Date: Wed, 02 Jul 2003 03:40:29 -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: "George Foti (LMC)" CC: sip@ietf.org References: <32CD630F6CBED411AE180008C7894CBC0C037E12@lmc37.lmc.ericsson.se> In-Reply-To: <32CD630F6CBED411AE180008C7894CBC0C037E12@lmc37.lmc.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Question Caller Preferences 08 draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I dont think I ever answered this. George Foti (LMC) wrote: > Quoting the 08 draft section 7.4 (Matching): > > Next, the proxy applies the predicates associated with the > Accept-Contact header field. For each contact that remains in the target > set, the proxy constructs a matching set, Ms. Initially, this set > contains all of the Accept-Contact predicates. Each of those predicates > is examined. It is matched to the contact predicate using the matching > operation of RFC 2533 [2]. If the result is not a match, and the > Accept-Contact predicate had its require flag set, the URI corresponding > to that contact predicate is discarded from the contact set. If the > result is not a match, but the Accept-Contact predicate removed from the > target set. The above text is not actually whats in -08. The actual text is: > Next, the proxy applies the predicates associated with the Accept- > Contact header field. For each contact that remains in the target > set, the proxy constructs a matching set, Ms. Initially, this set > contains all of the Accept-Contact predicates. Each of those > predicates is examined. It is matched to the contact predicate using > the matching operation of RFC 2533 [2]. If the result is not a match, > and the Accept-Contact predicate had its require flag set, the URI > corresponding to that contact predicate is discarded from the contact > set. If the result is not a match, but the Accept-Contact predicate > did not have its require flag set, that contact URI is not discarded > from the contact set, however, the Accept-Contact predicate is > removed from the matching set for that contact. but your question is still relevant: > > My question relates to the last statement in the above paragraph. > The objective of that step, as I understand it, is to remove from the > set all predicates, that don't have an equivalent in the contact. > > This step seems to be redundant, as it would not have an impact on the > score, since it would not change the score anyway (based on the way the > score is calculated) > > Is my understanding correct? In -08, I believe you are right. Setting the score to 0 is equivalent to removing the Accept-Contact predicate from the matching set. This algorithm has changed in -09, and with the new algorithm, it is not the case any longer. > > My next question relates to the usage of the cancel-directive. > Quoting the Draft : > > cancel-directive: This type of directive indicates whether the > caller would like each proxy server to send a CANCEL > request downstream ("cancel") in response to a 200 OK from > the downstream server (which is the normal mode of > operation, making it somewhat redundant), or whether this > function should be left to the caller ("no-cancel"). If a > proxy receives a request with this parameter set to "no- > cancel", it SHOULD NOT CANCEL any outstanding branches on > receipt of a 2xx. However, it would still send CANCEL on > any outstanding branches on receipt of a 6xx. > > The strength SHOULD NOT makes it unclear as to how the UAC can decide on > what to do, even if the proxy understands caller preferences. The caller will end up seeing more 2xx than it normally would. It can then do what it wants - BYE some of them, keep some of them, as desired. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer 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 Wed Jul 2 06:59:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03664 for ; Wed, 2 Jul 2003 06:59:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XfJw-0003oJ-7Y for sip-archive@odin.ietf.org; Wed, 02 Jul 2003 06:58:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62AweCh014644 for sip-archive@odin.ietf.org; Wed, 2 Jul 2003 06:58:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XfJN-0003Q3-7g; Wed, 02 Jul 2003 06:58:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XfIf-0003GF-KK for sip@optimus.ietf.org; Wed, 02 Jul 2003 06:57:21 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03200; Wed, 2 Jul 2003 06:57:18 -0400 (EDT) Message-Id: <200307021057.GAA03200@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, 02 Jul 2003 06:57:18 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-join-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 Session Inititation Protocol (SIP) 'Join' Header Author(s) : R. Mahy, D. Petrie Filename : draft-ietf-sip-join-02.txt Pages : 20 Date : 2003-7-1 This document defines a new header for use with SIP multi-party applications and call control. The Join header is used to logically join an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: 'Barge-In', answering-machine-style 'Message Screening' and 'Call Center Monitoring'. Note that definition of these example features is non- normative. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-join-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-join-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-join-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-7-1135003.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-join-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-join-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-1135003.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 Jul 2 07:44:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03665 for ; Wed, 2 Jul 2003 06:59:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XfJw-0003oM-7l for sip-archive@odin.ietf.org; Wed, 02 Jul 2003 06:58:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62AweKI014643 for sip-archive@odin.ietf.org; Wed, 2 Jul 2003 06:58:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XfJM-0003Pt-1u; Wed, 02 Jul 2003 06: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 19XfIa-0003GA-6R for sip@optimus.ietf.org; Wed, 02 Jul 2003 06:57:16 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03182; Wed, 2 Jul 2003 06:57:12 -0400 (EDT) Message-Id: <200307021057.GAA03182@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, 02 Jul 2003 06:57:12 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-mib-06.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Management Information Base for Session Initiation Protocol Author(s) : K. Lingle, J. Maeng, J. Mule, D. Walker Filename : draft-ietf-sip-mib-06.txt Pages : 104 Date : 2003-7-1 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Session Initiation Protocol (SIP) entities, which include User Agents, Proxy servers, Redirect servers and Registrars. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-mib-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-mib-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-1134952.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-mib-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-mib-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-1134952.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 Jul 2 11:53:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28248 for ; Wed, 2 Jul 2003 11:53:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xjv6-0001EK-Is for sip-archive@odin.ietf.org; Wed, 02 Jul 2003 11:53:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62FrKTL004727 for sip-archive@odin.ietf.org; Wed, 2 Jul 2003 11:53:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xjun-0001Bx-IK; Wed, 02 Jul 2003 11:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xju1-00018p-6N for sip@optimus.ietf.org; Wed, 02 Jul 2003 11:52: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 LAA28118 for ; Wed, 2 Jul 2003 11:52:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xju0-0002kW-00 for sip@ietf.org; Wed, 02 Jul 2003 11:52:12 -0400 Received: from host-133-208.is.dyncorp.com ([131.131.133.208] helo=chntex04.is.dyncorp.com) by ietf-mx with esmtp (Exim 4.12) id 19Xjtz-0002kQ-00 for sip@ietf.org; Wed, 02 Jul 2003 11:52:11 -0400 Received: by chntex04.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Jul 2003 11:50:05 -0400 Message-ID: <5EA16A28B747E34FB90B578E6C5DDE899E0E2B@chntex04.is.dyncorp.com> From: "Berg, Dennis" To: "'Henning Schulzrinne'" Cc: "'sip@ietf.org'" , "'Mpierce1@aol.com'" , "Gunn, Janet" Date: Wed, 2 Jul 2003 11:50:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C340B1.9B2ECAF0" Subject: [Sip] Namespace registration for SIP RPH Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C340B1.9B2ECAF0 Content-Type: text/plain Henning, Draft-ietf-sip-resource-priority-00.txt, Section 12, IANA Considerations, asks not only for registration of the basic components of the RPH, i.e., namespace, ordered labels for priority, and a default, but adds that "the registration MUST describe how SIP elements should treat requests from that namespace, e.g., whether preemption or only preferential queuing are allowed.". This requirement really amounts to a service description of the way the namespace is to be used. (As just a note, this position seems to be diametrically opposed to previous discussions in ieprep (when the ID was under submission there) that seemed to stress the protocol/policy distinction, in which the use of the namespace for a service as a matter of policy. However, I am glad to see the change.) As I read the exchange between Mike Pierce and you on 24/25 June, you concluded that assignments of namespaces should not be included in your RPH ID. I think that this is the right conclusion, particularly if the namespace value assignments have to have an accompanying service description. Am I correct in my understanding that you have agreed to take all the namespace registrations our of your ID, i.e. all of Appendix B? I would like to see the process conform to RFC 2434, "Guidelines for Writing IANA Considerations Sections in RFCs", which suggests that "One way to insure community review of prospective assignments is to have the requester submit a document for publication as an RFC". We have a new ID, http://www.ietf.org/internet-drafts/draft-mcgregor-ieprep-bridging-bcp-00.tx t , that proposes a different structure to cover what you have in B.3 for GETS. If you are dropping Appendix B from your ID, we do not have to further work that here. But, it does raise the question, if there should be an RFC developed for a RPH namespace to serve GETS, what working group should this be done under - SIP, ieprep? Dennis Berg CSC dennis.berg@dyncorp.com ------_=_NextPart_001_01C340B1.9B2ECAF0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Henning,

 

Draft-ietf-sip-resource-priority-00.txt, Section 12, IANA Considerations, asks not only for registration of the basic components = of the RPH, i.e., namespace, ordered labels for priority, and a default, but = adds that "the registration MUST describe how SIP elements should treat requests from that namespace, e.g., whether preemption or only preferential = queuing are allowed.".  This requirement really amounts to a service = description of the way the namespace is to be used. 

 

(As just a note, this position seems to be diametrically = opposed to previous discussions in ieprep (when the ID was under submission there) = that seemed to stress the protocol/policy distinction, in which the use of = the namespace for a service as a matter of policy.  However, I am glad = to see the change.)

 

As I read the exchange between Mike Pierce and you on 24/25 = June, you concluded that assignments of namespaces should not be included in your = RPH ID.  I think that this is the right conclusion, particularly if = the namespace value assignments have to have an accompanying service description. 

Am I correct in my understanding that you have agreed to take = all the namespace registrations our of your ID, i.e. all of Appendix = B?

 

I would like to see the process conform to RFC 2434, = "Guidelines for Writing IANA Considerations Sections in RFCs",  which suggests that "One way to insure community review of prospective assignments is = to have the requester submit a document for publication as an RFC".  =  We have a new ID, http://www.ietf.org/internet-drafts/draft-mcgregor-ieprep= -bridging-bcp-00.txt, that proposes a different structure to cover what you have in B.3 for GETS.  If you are dropping Appendix B from your ID, we do not have = to further work that here.

 

But, it does raise the question, if there should be an RFC = developed for a RPH namespace to serve GETS, what working group should this be = done under - SIP, ieprep?

 

Dennis Berg

CSC

dennis.berg@dyncorp.com

 

------_=_NextPart_001_01C340B1.9B2ECAF0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 2 16:36:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14225 for ; Wed, 2 Jul 2003 16:36:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoKb-0003Pc-MF for sip-archive@odin.ietf.org; Wed, 02 Jul 2003 16:35:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62KZvTU013089 for sip-archive@odin.ietf.org; Wed, 2 Jul 2003 16:35:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoJj-0003J8-G7; Wed, 02 Jul 2003 16: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 19XoIq-0002y7-Ic for sip@optimus.ietf.org; Wed, 02 Jul 2003 16:34:08 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13291; Wed, 2 Jul 2003 16:34:03 -0400 (EDT) Message-Id: <200307022034.QAA13291@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, 02 Jul 2003 16:34:03 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-authid-body-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 : SIP Authenticated Identity Body (AIB) Format Author(s) : J. Peterson Filename : draft-ietf-sip-authid-body-02.txt Pages : 12 Date : 2003-7-2 RFC3261 introduces the concept of adding an S/MIME body to a SIP request or response in order to provide reference integrity over its headers. This document provides a more specific mechanism to derive integrity and authentication properties from an 'authenticated identity body', a digitally-signed SIP message or message fragment. A standard format for such bodies (known as Authenticated Identity Bodies, or AIBs) is given in this document. Some considerations for the processing of AIBs by recipients of SIP messages with such bodies are also given. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-authid-body-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-authid-body-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-authid-body-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-7-2161937.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-authid-body-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-authid-body-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2161937.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 Jul 2 17:29:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14223 for ; Wed, 2 Jul 2003 16:36:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoKb-0003PI-L3 for sip-archive@odin.ietf.org; Wed, 02 Jul 2003 16:35:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62KZvvp013088 for sip-archive@odin.ietf.org; Wed, 2 Jul 2003 16:35:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoIo-0002xH-DD; Wed, 02 Jul 2003 16:34:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoIh-0002uQ-Ha for sip@optimus.ietf.org; Wed, 02 Jul 2003 16:33: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 QAA13222; Wed, 2 Jul 2003 16:33:54 -0400 (EDT) Message-Id: <200307022033.QAA13222@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, 02 Jul 2003 16:33:54 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-smime-aes-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : S/MIME AES Requirement for SIP Author(s) : J. Peterson Filename : draft-ietf-sip-smime-aes-01.txt Pages : 6 Date : 2003-7-2 RFC3261 currently specifies 3DES as the required minimum ciphersuite for implementations of S/MIME in SIP. This document updates the normative guidance of RFC3261 to require the Advanced Encryption Standard (AES) for S/MIME. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-smime-aes-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-smime-aes-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-smime-aes-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-7-2161917.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-smime-aes-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-smime-aes-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2161917.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 Jul 2 17:29:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14224 for ; Wed, 2 Jul 2003 16:36:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoKb-0003Pg-MS for sip-archive@odin.ietf.org; Wed, 02 Jul 2003 16:35:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62KZvm0013090 for sip-archive@odin.ietf.org; Wed, 2 Jul 2003 16:35:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoJi-0003IS-1D; Wed, 02 Jul 2003 16:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoIm-0002wX-C8 for sip@optimus.ietf.org; Wed, 02 Jul 2003 16:34:04 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13262; Wed, 2 Jul 2003 16:33:59 -0400 (EDT) Message-Id: <200307022033.QAA13262@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, 02 Jul 2003 16:33:58 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-session-timer-11.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Session Timers in the Session Initiation Protocol (SIP) Author(s) : S. Donovan, J. Rosenberg Filename : draft-ietf-sip-session-timer-11.txt Pages : 21 Date : 2003-7-2 This document defines an extension to the Session Initiation Protocol (SIP). This extension allows for a periodic refresh of SIP sessions through a re-INVITE or UPDATE request. The refresh allows both user agents and proxies to determine if the SIP session is still active. The extension defines two new header fields, Session- Expires, which conveys the lifetime of the session, and Min-SE, which conveys the minimum allowed value for the session timer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-session-timer-11.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-session-timer-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-session-timer-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-2161927.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-session-timer-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-session-timer-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2161927.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 Jul 2 22:34:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11486 for ; Wed, 2 Jul 2003 22:34:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XtvS-0001o5-LG for sip-archive@odin.ietf.org; Wed, 02 Jul 2003 22:34:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h632YMUg006941 for sip-archive@odin.ietf.org; Wed, 2 Jul 2003 22:34:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xtv7-0001nO-D3; Wed, 02 Jul 2003 22:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XtuO-0001mV-RW for sip@optimus.ietf.org; Wed, 02 Jul 2003 22:33: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 WAA11434 for ; Wed, 2 Jul 2003 22:33:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XtuL-0001eT-00 for sip@ietf.org; Wed, 02 Jul 2003 22:33:13 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19XtuK-0001eQ-00 for sip@ietf.org; Wed, 02 Jul 2003 22:33:12 -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 h632X7kM012999; Wed, 2 Jul 2003 22:33:07 -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 h632X5N14694; Wed, 2 Jul 2003 22:33:05 -0400 Message-ID: <3F0394F1.6050501@cs.columbia.edu> Date: Wed, 02 Jul 2003 22:29:05 -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: "Berg, Dennis" CC: "'sip@ietf.org'" , "'Mpierce1@aol.com'" , "Gunn, Janet" References: <5EA16A28B747E34FB90B578E6C5DDE899E0E2B@chntex04.is.dyncorp.com> In-Reply-To: <5EA16A28B747E34FB90B578E6C5DDE899E0E2B@chntex04.is.dyncorp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Namespace registration for SIP RPH Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org 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 Berg, Dennis wrote: > but adds that "the registration MUST describe how SIP elements should > treat requests from that namespace, e.g., whether preemption or only > preferential queuing are allowed.". This requirement really amounts to > a service description of the way the namespace is to be used. Correct. > > > > (As just a note, this position seems to be diametrically opposed to > previous discussions in ieprep (when the ID was under submission there) > that seemed to stress the protocol/policy distinction, in which the use > of the namespace for a service as a matter of policy. However, I am > glad to see the change.) Not really. The notion was that the protocol element itself would not express handling procedures, i.e., something like Resource-Handling: ;preemption=yes ;priority=strict would be encoding policy in the element itself. The algorithm has to be described somewhere, after all, if this is to be useful. Clearly, a description can say "it is up to the implementation/local administrative policy/local drunk driving laws/today's lottery numbers whether preemption is allowed". > > > > As I read the exchange between Mike Pierce and you on 24/25 June, you > concluded that assignments of namespaces should not be included in your > RPH ID. I think that this is the right conclusion, particularly if the > namespace value assignments have to have an accompanying service > description. You must be referring to a different exchange of emails than I remember. The exchange was in reference to currently ill-defined namespaces, such as the ETS/TDR/etc. namespace. While I don't see this as a big issue (I'm happy to include namespaces or not), I was primarily concerned about any registrations that, due to external gating conditions, would delay the progress of the draft. I would find it useful to include these initial registration if only to set an example of how we envision registrations to look like, while people are still paying attention to this. > > Am I correct in my understanding that you have agreed to take all the > namespace registrations our of your ID, i.e. all of Appendix B? I believe you misread our email exchange. > > > > I would like to see the process conform to RFC 2434, "Guidelines for > Writing IANA Considerations Sections in RFCs", which suggests that "One > way to insure community review of prospective assignments is to have the > requester submit a document for publication as an RFC". We have a new > ID, > http://www.ietf.org/internet-drafts/draft-mcgregor-ieprep-bridging-bcp-00.txt, > that proposes a different structure to cover what you have in B.3 for > GETS. If you are dropping Appendix B from your ID, we do not have to > further work that here. As discussed, B.3 will be dropped since it is currently insufficiently well defined to be documented. > > > > But, it does raise the question, if there should be an RFC developed for > a RPH namespace to serve GETS, what working group should this be done > under - SIP, ieprep? I think the goal should be that namespace registrations primarily require domain expertise, not protocol expertise. Thus, the important part is that the constituency for the namespace is well-represented in the review. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 2 23:06:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12613 for ; Wed, 2 Jul 2003 23:06:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XuQG-0002sQ-9D for sip-archive@odin.ietf.org; Wed, 02 Jul 2003 23:06:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6336C4l010935 for sip-archive@odin.ietf.org; Wed, 2 Jul 2003 23:06:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XuQA-0002pi-2I; Wed, 02 Jul 2003 23:06:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XuPM-0002p9-Cu for sip@optimus.ietf.org; Wed, 02 Jul 2003 23:05: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 XAA12569 for ; Wed, 2 Jul 2003 23:05:10 -0400 (EDT) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XuPI-000223-00 for sip@ietf.org; Wed, 02 Jul 2003 23:05:12 -0400 Received: from imo-r02.mx.aol.com ([152.163.225.98]) by ietf-mx with esmtp (Exim 4.12) id 19XuPH-00021j-00 for sip@ietf.org; Wed, 02 Jul 2003 23:05:11 -0400 Received: from Mpierce1@aol.com by imo-r02.mx.aol.com (mail_out_v36_r1.1.) id r.175.1d12549f (25098); Wed, 2 Jul 2003 23:04:22 -0400 (EDT) Message-ID: <175.1d12549f.2c34f736@aol.com> Date: Wed, 2 Jul 2003 23:04:22 EDT To: Dennis.Berg@DynCorp.com, hgs@cs.columbia.edu CC: sip@ietf.org, Janet.Gunn@DynCorp.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_175.1d12549f.2c34f736_boundary" X-Mailer: 6.0 for Windows XP sub 10501 Subject: [Sip] Re: Namespace registration for SIP RPH Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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_175.1d12549f.2c34f736_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 7/2/2003 11:52:47 AM Eastern Standard Time, Dennis.Berg@DynCorp.com writes (to Henning): > Draft-ietf-sip-resource-priority-00.txt, Section 12, IANA Considerations, > asks not only for registration of the basic components of the RPH, i.e., > namespace, ordered labels for priority, and a default, but adds that "the > registration MUST describe how SIP elements should treat requests from that > namespace, e.g., whether preemption or only preferential queuing are allowed.". This > requirement really amounts to a service description of the way the namespace > is to be used. > > (As just a note, this position seems to be diametrically opposed to previous > discussions in ieprep (when the ID was under submission there) that seemed > to stress the protocol/policy distinction, in which the use of the namespace > for a service as a matter of policy. However, I am glad to see the change.) > > As I read the exchange between Mike Pierce and you on 24/25 June, you > concluded that assignments of namespaces should not be included in your RPH ID. I > think that this is the right conclusion, particularly if the namespace value > assignments have to have an accompanying service description. > Am I correct in my understanding that you have agreed to take all the > namespace registrations our of your ID, i.e. all of Appendix B? > Dennis, I agree that we should be very careful on how much we try to put in the R-P header document or require to be submitted with a registration with regards to procedures (preemption, preferential queuing, etc.) These can be described separately, and in fact, do not really need to be in any RFC or registration if they are local actions. I agree that the header definition should be limited to just that, but we've been pushed into describing some of the procedures for the use of the header. My comments about definition of namespaces was to not include ones for ETS, GETS, TDR, 911, etc since there is a lot of uncertainty on what values were needed and how several namespaces would relate. On the other hand "Assured Service" (based on MLPP) is very clear so should be included. Mike Pierce --part1_175.1d12549f.2c34f736_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 7/2/2003 11:52:47 AM Eastern Standa= rd Time, Dennis.Berg@DynCorp.com writes (to Henning):


Draft-ietf-sip-resource-pri= ority-00.txt, Section 12, IANA Considerations, asks not only for registratio= n of the basic components of the RPH, i.e., namespace, ordered labels for pr= iority, and a default, but adds that "the registration MUST describe how SIP= elements should treat requests from that namespace, e.g., whether preemptio= n or only preferential queuing are allowed.".  This requirement really=20= amounts to a service description of the way the namespace is to be used. &nb= sp;
=20
(As just a note, this position seems to be diametrically opposed to prev= ious discussions in ieprep (when the ID was under submission there) that see= med to stress the protocol/policy distinction, in which the use of the names= pace for a service as a matter of policy.  However, I am glad to see th= e change.)
=20
As I read the exchange between Mike Pierce and you on 24/25 June, you co= ncluded that assignments of namespaces should not be included in your RPH ID= .  I think that this is the right conclusion, particularly if the names= pace value assignments have to have an accompanying service description. &nb= sp;
Am I correct in my understanding that you have agreed to take all the na= mespace registrations our of your ID, i.e. all of Appendix B?



Dennis,

I agree that we should be very careful on how much we try to put in the=20= R-P header document or require to be submitted with a registration with rega= rds to procedures (preemption, preferential queuing, etc.) These can be desc= ribed separately, and in fact, do not really need to be in any RFC or regist= ration if they are local actions. I agree that the header definition should=20= be limited to just that, but we've been pushed into describing some of the p= rocedures for the use of the header.

My comments about definition of namespaces was to not include ones for E= TS, GETS, TDR, 911, etc since there is a lot of uncertainty on what values w= ere needed and how several namespaces would relate. On the other hand "Assur= ed Service" (based on MLPP) is very clear so should be included.

Mike Pierce
--part1_175.1d12549f.2c34f736_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 Jul 3 01:54:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16810 for ; Thu, 3 Jul 2003 01:54:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xx2p-0006zt-HF for sip-archive@odin.ietf.org; Thu, 03 Jul 2003 01:54:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h635sBOj026859 for sip-archive@odin.ietf.org; Thu, 3 Jul 2003 01:54:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xx2f-0006yh-DB; Thu, 03 Jul 2003 01:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xx2R-0006y7-R1 for sip@optimus.ietf.org; Thu, 03 Jul 2003 01:53:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16794 for ; Thu, 3 Jul 2003 01:53:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xx2O-0003Gd-00 for sip@ietf.org; Thu, 03 Jul 2003 01:53:44 -0400 Received: from e-eihq01.eis.ernet.in ([202.41.97.131]) by ietf-mx with esmtp (Exim 4.12) id 19Xx23-0003GR-00 for sip@ietf.org; Thu, 03 Jul 2003 01:53:23 -0400 Received: from uucp-relay-delhi.ernet.in by e-eihq01.eis.ernet.in (8.10.2/1.1.2.10/13Jul01-0336PM) id h636IeO0000021549; Thu, 3 Jul 2003 11:18:40 +0500 (GMT+0500) Received: by uucp-relay-delhi.ernet.in (8.9.3+Sun/SMI-4.1-MHS-7.0) id LAA22935; Thu, 3 Jul 2003 11:29:05 -0500 (GMT) >Received: from virgo.cdotd.ernet.in by cdotd.cdotd.ernet.in (SMI-8.6/SMI-SVR4) id LAA04924; Thu, 3 Jul 2003 11:10:06 -0500 Date: Thu, 3 Jul 2003 11:10:30 +0530 (IST) From: Rinchen Tundup To: sip@ietf.org, osip@atsoc.org, sip@vovida.org cc: Satish Bansal! Message-ID: MIME-Version: 1.0 Received: from cdotd by vikram.eis.ernet.in; Thu, 3 Jul 2003 11:29 GMT Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] Authorization header's nonce value Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hello everyone, I want to send credentials of a user in the first REGISTER request ( in Authorization header), but for computing the response (with MD5) i guess we require the nonce value which is specified by the server in 401 or 407. So my question is what should be the nonce value or it should be always first REGISTER with no credentials , 401 ( get nonce ) , REGISTER with credentials , OK or am i missing something? Pls help . Greetings Rinchen Tundup Research Engineer (Intelligent Networking) C-DOT Akbar Bhawan Delhi 24677525 Ext-102,312 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 3 10:28:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13337 for ; Thu, 3 Jul 2003 10:28:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y54O-0005vD-3P for sip-archive@odin.ietf.org; Thu, 03 Jul 2003 10:28:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63ESKZ7022764 for sip-archive@odin.ietf.org; Thu, 3 Jul 2003 10:28:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y545-0005uX-Dh; Thu, 03 Jul 2003 10: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 19Y53e-0005uC-7j for sip@optimus.ietf.org; Thu, 03 Jul 2003 10:27:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13302 for ; Thu, 3 Jul 2003 10:27:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y53b-00077M-00 for sip@ietf.org; Thu, 03 Jul 2003 10:27:31 -0400 Received: from host-133-208.is.dyncorp.com ([131.131.133.208] helo=chntex04.is.dyncorp.com) by ietf-mx with esmtp (Exim 4.12) id 19Y53b-00077H-00 for sip@ietf.org; Thu, 03 Jul 2003 10:27:31 -0400 Received: by chntex04.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jul 2003 10:25:23 -0400 Message-ID: <5EA16A28B747E34FB90B578E6C5DDE8915AA42@chntex04.is.dyncorp.com> From: "Gunn, Janet" To: "'Mpierce1@aol.com'" , hgs@cs.columbia.edu, sip@ietf.org Cc: "Berg, Dennis" Date: Thu, 3 Jul 2003 10:25:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3416E.F0296AC0" Subject: [Sip] multiple namespaces for SIP RPH Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3416E.F0296AC0 Content-Type: text/plain; charset="iso-8859-1" > 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?" Mike, I think I provided some of the motivation for this. In the US PSTN, a call may be a GETS call AND a WPS call; a GETS call BUT NOT a WPS call; or a WPS call BUT NOT a GETS call. The "labels" for a GETS call and a WPS call are different (CPC parameter vs. Precedence parameter) Being a GETS call determines treatment in the landline network. Being a WPS call determines treatment in the wireless network. It seems plausible that a similar situation could occur in IP networks - especially if one treatment was relevant in one administrative domain, but another was available in a second administrative domain. ------_=_NextPart_001_01C3416E.F0296AC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable multiple namespaces for SIP RPH

> 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?"

Mike,

I think I provided some of the motivation for = this.

In the US PSTN, a call may be a GETS call AND a WPS = call; a GETS call BUT NOT a WPS call; or a WPS call BUT NOT a GETS = call.

The "labels" for a GETS call and a WPS call = are different (CPC parameter vs. Precedence parameter)

Being a GETS call determines treatment in the = landline network.  Being a WPS call determines treatment in the = wireless network.

It seems plausible that a similar situation could = occur in  IP networks - especially if one treatment was relevant = in one administrative domain, but another was available in a second = administrative domain.

------_=_NextPart_001_01C3416E.F0296AC0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 3 11:03:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14750 for ; Thu, 3 Jul 2003 11:03:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y5c1-0007nM-Pe for sip-archive@odin.ietf.org; Thu, 03 Jul 2003 11:03:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63F35Tk029947 for sip-archive@odin.ietf.org; Thu, 3 Jul 2003 11:03:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y5bw-0007mX-RJ; Thu, 03 Jul 2003 11:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y5bN-0007mA-Pw for sip@optimus.ietf.org; Thu, 03 Jul 2003 11:02:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14691 for ; Thu, 3 Jul 2003 11:02:22 -0400 (EDT) From: BenLev@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y5bL-0007eD-00 for sip@ietf.org; Thu, 03 Jul 2003 11:02:23 -0400 Received: from imo-r05.mx.aol.com ([152.163.225.101]) by ietf-mx with esmtp (Exim 4.12) id 19Y5bK-0007dd-00 for sip@ietf.org; Thu, 03 Jul 2003 11:02:22 -0400 Received: from BenLev@aol.com by imo-r05.mx.aol.com (mail_out_v36_r1.1.) id l.c.147f32b9 (4254) for ; Thu, 3 Jul 2003 11:01:36 -0400 (EDT) Message-ID: Date: Thu, 3 Jul 2003 11:01:35 EDT To: sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_c.147f32b9.2c359f4f_boundary" X-Mailer: 8.0 for Windows sub 6014 Subject: [Sip] Methods inventory Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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_c.147f32b9.2c359f4f_boundary Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable My first post to this list so please be nice! With the addition of "JOIN" does this make the total of valid methods 14?= =A0=20 I have: INVITE=A0 - RFC 2543 REGISTER - RFC 2543 BYE- RFC 2543 ACK- RFC 2543 CANCEL- RFC 2543 OPTIONS- RFC 2543 SUBSCRIBE - RFC 2848 UNSUBSCRIBE - RFC 2848 NOTIFY - RFC 2848 INFO - RFC 2976 PRACK - ?? UPDATE - RFC 3311 REFER - RFC 3515 JOIN -=A0 TBD Ben Levitan Raleigh, NC 919-782-7442 benlev@aol.com --part1_c.147f32b9.2c359f4f_boundary Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable My first post to this list so please be nice!
With the addition of "JOIN" does this make the total of valid methods 14?= =A0
I have:

INVITE=A0 - RFC 2543
REGISTER - RFC 2543
BYE- RFC 2543
ACK- RFC 2543
CANCEL- RFC 2543
OPTIONS- RFC 2543

SUBSCRIBE - RFC 2848
UNSUBSCRIBE - RFC 2848
NOTIFY - RFC 2848

INFO - RFC 2976
PRACK - ??

UPDATE - RFC 3311
REFER - RFC 3515

JOIN -=A0 TBD

Ben Levitan
Raleigh, NC
919-782-7442
benlev@aol.com
 --part1_c.147f32b9.2c359f4f_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 Jul 3 11:17:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15141 for ; Thu, 3 Jul 2003 11:17:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y5pk-0008T9-8k for sip-archive@odin.ietf.org; Thu, 03 Jul 2003 11:17:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63FHGJM032551 for sip-archive@odin.ietf.org; Thu, 3 Jul 2003 11:17:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y5oY-0008RK-LY; Thu, 03 Jul 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 19Y5nl-0008QT-OA for sip@optimus.ietf.org; Thu, 03 Jul 2003 11:15: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 LAA15027 for ; Thu, 3 Jul 2003 11:15:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y5nk-00001W-00 for sip@ietf.org; Thu, 03 Jul 2003 11:15:12 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19Y5nj-00001S-00 for sip@ietf.org; Thu, 03 Jul 2003 11:15:11 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Thu, 3 Jul 2003 16:17:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C34175.E52481B4" Subject: RE: [Sip] Methods inventory Date: Thu, 3 Jul 2003 16:15:10 +0100 Message-ID: <45730E094814E44488F789C1CDED27AE01E22C23@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Sip] Methods inventory Thread-Index: AcNBdDWqf2SJ0LejSOKP7vacsnScNwAAZAVw From: "Chris Boulton" To: , Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C34175.E52481B4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ben, Don't scare people on the list by using 2543. RFC 3261 is the current base line specification. =20 Chris. =20 =20 -----Original Message----- From: BenLev@aol.com [mailto:BenLev@aol.com]=20 Sent: 03 July 2003 16:02 To: sip@ietf.org Subject: [Sip] Methods inventory =20 My first post to this list so please be nice! With the addition of "JOIN" does this make the total of valid methods 14? =20 I have: INVITE - RFC 2543 REGISTER - RFC 2543 BYE- RFC 2543 ACK- RFC 2543 CANCEL- RFC 2543 OPTIONS- RFC 2543 SUBSCRIBE - RFC 2848 UNSUBSCRIBE - RFC 2848 NOTIFY - RFC 2848 INFO - RFC 2976 PRACK - ?? UPDATE - RFC 3311 REFER - RFC 3515 JOIN - TBD Ben Levitan Raleigh, NC 919-782-7442 benlev@aol.com ------_=_NextPart_001_01C34175.E52481B4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ben,

        = ;    Don’t scare people on the list by using 2543.  RFC 3261 is the current base line = specification.

 

Chris.

 

 

-----Original Message-----
From: BenLev@aol.com [mailto:BenLev@aol.com]
Sent: 03 July 2003 = 16:02
To: sip@ietf.org
Subject: [Sip] Methods = inventory

 

My first post to this list so please be nice!
With the addition of "JOIN" does this make the total of valid = methods 14? 
I have:

INVITE  - RFC 2543
REGISTER - RFC 2543
BYE- RFC 2543
ACK- RFC 2543
CANCEL- RFC 2543
OPTIONS- RFC 2543

SUBSCRIBE - RFC 2848
UNSUBSCRIBE - RFC 2848
NOTIFY - RFC 2848

INFO - RFC 2976
PRACK - ??

UPDATE - RFC 3311
REFER - RFC 3515

JOIN -  TBD

Ben Levitan
Raleigh, NC
919-782-7442
benlev@aol.com

=00 ------_=_NextPart_001_01C34175.E52481B4-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 3 11:19:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15206 for ; Thu, 3 Jul 2003 11:19:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y5ra-0000G4-9h for sip-archive@odin.ietf.org; Thu, 03 Jul 2003 11:19:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63FJAXB000989 for sip-archive@odin.ietf.org; Thu, 3 Jul 2003 11:19:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y5rR-0000FH-LD; Thu, 03 Jul 2003 11:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y5qW-0000Dj-Fe for sip@optimus.ietf.org; Thu, 03 Jul 2003 11:18: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 LAA15167 for ; Thu, 3 Jul 2003 11:18:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y5qV-000044-00 for sip@ietf.org; Thu, 03 Jul 2003 11:18:03 -0400 Received: from angelica.ulticom.com ([208.255.120.2] helo=chuckie.dgms.com) by ietf-mx with esmtp (Exim 4.12) id 19Y5qU-00003a-00 for sip@ietf.org; Thu, 03 Jul 2003 11:18:02 -0400 Received: from ulticom.com (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with ESMTP id LAA20750; Thu, 3 Jul 2003 11:17:20 -0400 (EDT) Message-ID: <3F0448FC.4030808@ulticom.com> Date: Thu, 03 Jul 2003 11:17:16 -0400 From: Steve Pellegrino User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: BenLev@aol.com CC: sip@ietf.org Subject: Re: [Sip] Methods inventory References: Content-Type: multipart/alternative; boundary="------------000605040603000909050403" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --------------000605040603000909050403 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Reference http://www.iana.org/assignments/sip-parameters for all SIP methods registered with IANA through standards track RFCs. BenLev@aol.com wrote: > My first post to this list so please be nice! > With the addition of "JOIN" does this make the total of valid methods > 14? > I have: > > INVITE - RFC 2543 > REGISTER - RFC 2543 > BYE- RFC 2543 > ACK- RFC 2543 > CANCEL- RFC 2543 > OPTIONS- RFC 2543 > > SUBSCRIBE - RFC 2848 > UNSUBSCRIBE - RFC 2848 > NOTIFY - RFC 2848 > > INFO - RFC 2976 > PRACK - ?? > > UPDATE - RFC 3311 > REFER - RFC 3515 > > JOIN - TBD > > Ben Levitan > Raleigh, NC > 919-782-7442 > benlev@aol.com --------------000605040603000909050403 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Reference http://www.iana.org/assignments/sip-parameters for all SIP methods registered with IANA through standards track RFCs.

BenLev@aol.com wrote:
My first post to this list so please be nice!
With the addition of "JOIN" does this make the total of valid methods 14? 
I have:

INVITE  - RFC 2543
REGISTER - RFC 2543
BYE- RFC 2543
ACK- RFC 2543
CANCEL- RFC 2543
OPTIONS- RFC 2543

SUBSCRIBE - RFC 2848
UNSUBSCRIBE - RFC 2848
NOTIFY - RFC 2848

INFO - RFC 2976
PRACK - ??

UPDATE - RFC 3311
REFER - RFC 3515

JOIN -  TBD

Ben Levitan
Raleigh, NC
919-782-7442
benlev@aol.com

--------------000605040603000909050403-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 3 11:31:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16623 for ; Thu, 3 Jul 2003 11:31:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y63R-0001ap-BL for sip-archive@odin.ietf.org; Thu, 03 Jul 2003 11:31:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63FVPPQ006118 for sip-archive@odin.ietf.org; Thu, 3 Jul 2003 11:31:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y636-0001Qh-1Q; Thu, 03 Jul 2003 11:31:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y62P-0001EI-OG for sip@optimus.ietf.org; Thu, 03 Jul 2003 11:30: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 LAA16048 for ; Thu, 3 Jul 2003 11:30:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y62O-0000FI-00 for sip@ietf.org; Thu, 03 Jul 2003 11:30:20 -0400 Received: from host-133-208.is.dyncorp.com ([131.131.133.208] helo=chntex04.is.dyncorp.com) by ietf-mx with esmtp (Exim 4.12) id 19Y62N-0000FA-00 for sip@ietf.org; Thu, 03 Jul 2003 11:30:20 -0400 Received: by chntex04.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jul 2003 11:28:12 -0400 Message-ID: <5EA16A28B747E34FB90B578E6C5DDE899E0EE8@chntex04.is.dyncorp.com> From: "Berg, Dennis" To: "'Henning Schulzrinne'" Cc: "'sip@ietf.org'" , "'Mpierce1@aol.com'" , "Gunn, Janet" Date: Thu, 3 Jul 2003 11:28:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C34177.B65F5300" Subject: [Sip] RE: Namespace registration for SIP RPH Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C34177.B65F5300 Content-Type: text/plain Henning Schulzrinne wrote: As discussed, B.3 will be dropped since it is currently insufficiently well defined to be documented. [Berg, Dennis] Ok, we will then submit an ID to address the ETS namespace. > Henning Schulzrinne wrote: I think the goal should be that namespace registrations primarily require domain expertise, not protocol expertise. Thus, the important part is that the constituency for the namespace is well-represented in the review. [Berg, Dennis] Fully agree. ------_=_NextPart_001_01C34177.B65F5300 Content-Type: text/html RE: Namespace registration for SIP RPH

Henning Schulzrinne wrote:
As discussed, B.3 will be dropped since it is currently insufficiently
well defined to be documented.

[Berg, Dennis] Ok, we will then submit an ID to address the ETS namespace.
>
Henning Schulzrinne wrote:
I think the goal should be that namespace registrations primarily
require domain expertise, not protocol expertise. Thus, the important
part is that the constituency for the namespace is well-represented in
the review.
[Berg, Dennis] Fully agree.




------_=_NextPart_001_01C34177.B65F5300-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 3 11:33:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17217 for ; Thu, 3 Jul 2003 11:33:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y65E-0002D9-Uy for sip-archive@odin.ietf.org; Thu, 03 Jul 2003 11:33:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63FXGwh008475 for sip-archive@odin.ietf.org; Thu, 3 Jul 2003 11:33:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y654-0002BE-Kh; Thu, 03 Jul 2003 11:33:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y64Z-000207-Sw for sip@optimus.ietf.org; Thu, 03 Jul 2003 11:32:35 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16863; Thu, 3 Jul 2003 11:32:33 -0400 (EDT) Message-Id: <200307031532.LAA16863@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, 03 Jul 2003 11:32:33 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-callerprefs-09.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 : Caller Preferences for the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg, H. Schulzrinne, P. Kyzivat Filename : draft-ietf-sip-callerprefs-09.txt Pages : 33 Date : 2003-7-3 This document describes a set of extensions to the Session Initiation Protocol (SIP) which allow a caller to express preferences about request handling in servers. These preferences include the ability to select which URIs a request gets routed to, and to specify certain request handling directives in proxies and redirect servers. It does so by defining four new request headers, Accept-Contact, Reject- Contact, Require-Contact and Request-Disposition, which specify the caller's preferences. The extension also defines new parameters for the Contact header that describe the capabilities and characteristics of a UA. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-callerprefs-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-callerprefs-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-callerprefs-09.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-7-3112335.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-callerprefs-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-callerprefs-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-3112335.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 Jul 3 11:36:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17542 for ; Thu, 3 Jul 2003 11:36:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y67N-0003EE-4K for sip-archive@odin.ietf.org; Thu, 03 Jul 2003 11:35:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63FZTv0012392 for sip-archive@odin.ietf.org; Thu, 3 Jul 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 19Y66w-000393-Sy; Thu, 03 Jul 2003 11:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y66p-00038J-EQ for sip@optimus.ietf.org; Thu, 03 Jul 2003 11:34:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17450 for ; Thu, 3 Jul 2003 11:34:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y66o-0000Qs-00 for sip@ietf.org; Thu, 03 Jul 2003 11:34:54 -0400 Received: from mail.anadolu.edu.tr ([193.140.20.20] helo=anadolu.edu.tr) by ietf-mx with esmtp (Exim 4.12) id 19Y66i-0000PK-00 for sip@ietf.org; Thu, 03 Jul 2003 11:34:53 -0400 Received: from [10.10.100.38] (account ) by anadolu.edu.tr (CommuniGate Pro WebUser 3.4.7) with HTTP id 19097709 for ; Thu, 03 Jul 2003 19:32:29 +0400 From: "ÖZGE GÜNER" To: sip@ietf.org X-Mailer: CommuniGate Pro Web Mailer v.3.4.7 Date: Thu, 03 Jul 2003 19:32:29 +0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-9" Content-Transfer-Encoding: 8bit Subject: [Sip] about communication requirement. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org 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 am interested in networked appliace control. So I started to examine the requirements for networked appliances control. I read the draft-tsang-appliances-reqs-01.txt draft, but I could not understand this requirement that is under "Communication Protocol Requirements" category : " 6.1 The communication protocol must provide a flexible payload capability which will allow the transport of commands to, and responses from, individual NAs or classes of NAs. More explicitly, there must be a separation of transport and data. " I could not undertand what "seperation of transport and data" means? What I understood from these sentences is that, since the networked appliaces have wide range of functionality, the payload must be flexible enough to define the data or commands for each aplliance easily. is it right? I know SIP is convenient for appliance control but at least could you please tell me how can it fulfill this requirement? Thanks, Ozge Guner Anadolu University / TURKIYE _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 3 11:57:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19769 for ; Thu, 3 Jul 2003 11:57:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y6SD-0004X6-Ob for sip-archive@odin.ietf.org; Thu, 03 Jul 2003 11:57:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63Fv17q017421 for sip-archive@odin.ietf.org; Thu, 3 Jul 2003 11:57:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y6RG-0004Vt-TS; Thu, 03 Jul 2003 11:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y6QZ-0004Rz-R8 for sip@optimus.ietf.org; Thu, 03 Jul 2003 11:55: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 LAA19701 for ; Thu, 3 Jul 2003 11:55:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y6QY-0001CR-00 for sip@ietf.org; Thu, 03 Jul 2003 11:55:18 -0400 Received: from host-133-208.is.dyncorp.com ([131.131.133.208] helo=chntex04.is.dyncorp.com) by ietf-mx with esmtp (Exim 4.12) id 19Y6QX-0001C4-00 for sip@ietf.org; Thu, 03 Jul 2003 11:55:17 -0400 Received: by chntex04.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jul 2003 11:53:00 -0400 Message-ID: <5EA16A28B747E34FB90B578E6C5DDE899E0EED@chntex04.is.dyncorp.com> From: "Berg, Dennis" To: "'Mpierce1@aol.com'" , "'hgs@cs.columbia.edu'" Cc: "'sip@ietf.org'" , "Gunn, Janet" Date: Thu, 3 Jul 2003 11:52:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3417B.2D8CF060" Subject: [Sip] RE: Namespace registration for SIP RPH Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3417B.2D8CF060 Content-Type: text/plain -----Original Message----- From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: Wednesday, July 02, 2003 11:04 PM To: Berg, Dennis; hgs@cs.columbia.edu Cc: sip@ietf.org; Gunn, Janet Subject: Re: Namespace registration for SIP RPH In a message dated 7/2/2003 11:52:47 AM Eastern Standard Time, Dennis.Berg@DynCorp.com writes (to Henning): Draft-ietf-sip-resource-priority-00.txt, Section 12, IANA Considerations, asks not only for registration of the basic components of the RPH, i.e., namespace, ordered labels for priority, and a default, but adds that "the registration MUST describe how SIP elements should treat requests from that namespace, e.g., whether preemption or only preferential queuing are allowed.". This requirement really amounts to a service description of the way the namespace is to be used. (As just a note, this position seems to be diametrically opposed to previous discussions in ieprep (when the ID was under submission there) that seemed to stress the protocol/policy distinction, in which the use of the namespace for a service as a matter of policy. However, I am glad to see the change.) As I read the exchange between Mike Pierce and you on 24/25 June, you concluded that assignments of namespaces should not be included in your RPH ID. I think that this is the right conclusion, particularly if the namespace value assignments have to have an accompanying service description. Am I correct in my understanding that you have agreed to take all the namespace registrations our of your ID, i.e. all of Appendix B? Dennis, I agree that we should be very careful on how much we try to put in the R-P header document or require to be submitted with a registration with regards to procedures (preemption, preferential queuing, etc.) These can be described separately, and in fact, do not really need to be in any RFC or registration if they are local actions. I agree that the header definition should be limited to just that, but we've been pushed into describing some of the procedures for the use of the header. My comments about definition of namespaces was to not include ones for ETS, GETS, TDR, 911, etc since there is a lot of uncertainty on what values were needed and how several namespaces would relate. On the other hand "Assured Service" (based on MLPP) is very clear so should be included. Mike Pierce [Berg, Dennis] What document is then the "official" service description for the DSN namespace? Henning references RFC 791 in the B1 DSN namespace section. That reference does not seem to be the most appropriate. James Polk in this requirements references the ITU document (ITU-T Recommendation I.255.3 (1990), "Multilevel precedence and preemption service (MLPP)") which would seem more relevant and complete. ------_=_NextPart_001_01C3417B.2D8CF060 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

 

 

-----Original = Message-----
From: Mpierce1@aol.com [mailto:Mpierce1@aol.com]
Sent: = Wednesday, July 02, 2003 11:04 = PM
To: Berg, Dennis; hgs@cs.columbia.edu
Cc: sip@ietf.org; Gunn, = Janet
Subject: Re: Namespace registration for SIP RPH

 

In a message dated = 7/2/2003 11:52:47 = AM Eastern Standard Time, Dennis.Berg@DynCorp.com writes (to Henning):



Draft-ietf-sip-resource-pri= ority-00.txt, Section 12, IANA Considerations, asks not only for registration of the = basic components of the RPH, i.e., namespace, ordered labels for priority, = and a default, but adds that "the registration MUST describe how SIP = elements should treat requests from that namespace, e.g., whether preemption or = only preferential queuing are allowed.".  This requirement really = amounts to a service description of the way the namespace is to be used. =  

(As just a note, this position seems to be diametrically opposed to = previous discussions in ieprep (when the ID was under submission there) that = seemed to stress the protocol/policy distinction, in which the use of the = namespace for a service as a matter of policy.  However, I am glad to see the = change.)

As I read the exchange between Mike Pierce and you on 24/25 June, you = concluded that assignments of namespaces should not be included in your RPH ID. =  I think that this is the right conclusion, particularly if the namespace = value assignments have to have an accompanying service description.   =
Am I correct in my understanding that you have agreed to take all the = namespace registrations our of your ID, i.e. all of Appendix B? =




Dennis,

I agree that we should be very careful on how much we try to put in the = R-P header document or require to be submitted with a registration with = regards to procedures (preemption, preferential queuing, etc.) These can be = described separately, and in fact, do not really need to be in any RFC or = registration if they are local actions. I agree that the header definition should be = limited to just that, but we've been pushed into describing some of the procedures = for the use of the header.

My comments about definition of namespaces was to not include ones for = ETS, GETS, TDR, 911, etc since there is a lot of uncertainty on what values = were needed and how several namespaces would relate. On the other hand = "Assured Service" (based on MLPP) is very clear so should be included.

Mike Pierce

[Berg, Dennis]

 

What document is then the "official" service description for the DSN namespace? =  Henning references RFC 791 in the B1  DSN namespace section.  That = reference does not seem to be the most appropriate. James Polk in this = requirements references the ITU document (ITU-T Recommendation I.255.3 (1990), "Multilevel precedence and preemption service (MLPP)") which would seem more relevant and complete. =  

------_=_NextPart_001_01C3417B.2D8CF060-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 3 12:19:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17215 for ; Thu, 3 Jul 2003 11:33:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y65E-0002D1-UW for sip-archive@odin.ietf.org; Thu, 03 Jul 2003 11:33:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63FXGoX008476 for sip-archive@odin.ietf.org; Thu, 3 Jul 2003 11:33:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y653-00029t-9R; Thu, 03 Jul 2003 11:33:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y64V-0001zh-Ou for sip@optimus.ietf.org; Thu, 03 Jul 2003 11:32:31 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16823; Thu, 3 Jul 2003 11:32:28 -0400 (EDT) Message-Id: <200307031532.LAA16823@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, 03 Jul 2003 11:32:28 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-symmetric-response-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-sip-symmetric-response-01.txt Pages : 19 Date : 2003-7-3 The Session Initiation Protocol (SIP) operates over UDP and TCP. When used with UDP, responses to requests are returned to the source address the request came from, and to the port written into the topmost Via header field value of the request. This behavior is not desirable in many cases, most notably, when the client is behind a Network Address Translator (NAT). This extension defines a new parameter for the Via header field, called 'rport', that allows a client to request that the server send the response back to the source IP address and port where the request came from. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-symmetric-response-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-symmetric-response-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-symmetric-response-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-7-3112324.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-symmetric-response-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-symmetric-response-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-3112324.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 Jul 3 13:38:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27449 for ; Thu, 3 Jul 2003 13:38:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y82Q-0001MT-HE for sip-archive@odin.ietf.org; Thu, 03 Jul 2003 13:38:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63HcUII005211 for sip-archive@odin.ietf.org; Thu, 3 Jul 2003 13:38:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y81y-0001JU-2z; Thu, 03 Jul 2003 13:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y81D-0000yg-Ib for sip@optimus.ietf.org; Thu, 03 Jul 2003 13:37:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27301 for ; Thu, 3 Jul 2003 13:37:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y81B-0004Tm-00 for sip@ietf.org; Thu, 03 Jul 2003 13:37:13 -0400 Received: from broadsoft.com ([198.104.184.110]) by ietf-mx with esmtp (Exim 4.12) id 19Y81A-0004TZ-00 for sip@ietf.org; Thu, 03 Jul 2003 13:37:12 -0400 Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.12.9) id h63Hb4rD007480; Thu, 3 Jul 2003 13:37:06 -0400 (EDT) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] Methods inventory Date: Thu, 3 Jul 2003 13:42:20 -0400 Message-ID: <000001c3418a$74988230$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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 > My first post to this list so please be nice! In case you are not aware, sip-implementors@cs.columbia.edu should be used for basic SIP questions. http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > With the addition of "JOIN" does this make > the total of valid methods 14? The following website contains information about the registered sip methods and headers. http://www.iana.org/assignments/sip-parameters I'm unaware of an official public repository of all SIP methods within current or expired drafts. However I guess that they could be culled from http://www.softarmor.com/sipwg/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 3 15:15:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02699 for ; Thu, 3 Jul 2003 15:15:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y9Y4-00057M-EZ for sip-archive@odin.ietf.org; Thu, 03 Jul 2003 15:15:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63JFGx2019666 for sip-archive@odin.ietf.org; Thu, 3 Jul 2003 15:15:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y9Xq-00056W-72; Thu, 03 Jul 2003 15: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 19Y9XA-00055j-6f for sip@optimus.ietf.org; Thu, 03 Jul 2003 15:14:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02577 for ; Thu, 3 Jul 2003 15:14:19 -0400 (EDT) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y9X9-0007YY-00 for sip@ietf.org; Thu, 03 Jul 2003 15:14:19 -0400 Received: from imo-m01.mx.aol.com ([64.12.136.4]) by ietf-mx with esmtp (Exim 4.12) id 19Y9X8-0007Xq-00 for sip@ietf.org; Thu, 03 Jul 2003 15:14:18 -0400 Received: from Mpierce1@aol.com by imo-m01.mx.aol.com (mail_out_v36_r1.1.) id r.1ec.c6bdb35 (4238); Thu, 3 Jul 2003 15:12:23 -0400 (EDT) Message-ID: <1ec.c6bdb35.2c35da16@aol.com> Date: Thu, 3 Jul 2003 15:12:22 EDT To: Janet.Gunn@DynCorp.com, hgs@cs.columbia.edu, sip@ietf.org CC: Dennis.Berg@DynCorp.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_1ec.c6bdb35.2c35da16_boundary" X-Mailer: 6.0 for Windows XP sub 10501 Subject: [Sip] Re: multiple namespaces for SIP RPH Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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_1ec.c6bdb35.2c35da16_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 7/3/2003 10:27:35 AM Eastern Standard Time, Janet.Gunn@DynCorp.com writes: > In the US PSTN, a call may be a GETS call AND a WPS call; a GETS call BUT > NOT a WPS call; or a WPS call BUT NOT a GETS call. > The "labels" for a GETS call and a WPS call are different (CPC parameter vs. > Precedence parameter) > Being a GETS call determines treatment in the landline network. Being a WPS > call determines treatment in the wireless network. > It seems plausible that a similar situation could occur in IP networks - > especially if one treatment was relevant in one administrative domain, but > another was available in a second administrative domain. > Yes, clearly a call can have multiple markings. It seems that we already have lots of possibilities, both in the circuit-switched world and IP. CPC, and its origins in SS#7 and US signaling, is one of them. I just think that the Resource-Priority header and its purpose require that only one value (namespace) be carried in any single call setup attempt. That single value may then cause different actions or results for a wireless access, a wired access, an IP access link, a core link, a gateway, etc. The point is that the definition of the value needs to take into account all the requirements. If the Wireless access portion needs the 5 levels defined for WPS but GETS only needs one level while a regular call needs a "normal" level then we could define 6 levels. Once the call setup gets beyond the wireless access portion, the 5 individual levels defined for WPS may be treated the same. For assigning priority in a network, the level for GETS needs to be assigned relative to the WPS levels. The R-P header should not be seen as a way to label the type of call (GETS, WPS, etc). It should just be a relative priority. If there is a need to label a call as WPS, or GETS, or something else, then there needs to be an explicit label for that (which allows either or both). The "namespace" should not be used for this. Mike Pierce --part1_1ec.c6bdb35.2c35da16_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 7/3/20= 03 10:27:35 AM Eastern Standard Time, Janet.Gunn@DynCorp.com writes:


In the US PSTN, a call may=20= be a GETS call AND a WPS call; a GETS call BUT NOT a WPS call; or a WPS call= BUT NOT a GETS call.
The "labels" for a GETS call and a WPS call are different (CPC parameter= vs. Precedence parameter)=20
Being a GETS call determines treatment in the landline network.  Be= ing a WPS call determines treatment in the wireless network.
It seems plausible that a similar situation could occur in  IP netw= orks - especially if one treatment was relevant in one administrative domain= , but another was available in a second administrative domain.


Yes, clearly a call can have multiple markings. It seems that we already= have lots of possibilities, both in the circuit-switched world and IP. CPC,= and its origins in SS#7 and US signaling, is one of them.

I just think that the Resource-Priority header and its purpose require t= hat only one value (namespace) be carried in any single call setup attempt.=20= That single value may then cause different actions or results for a wireless= access, a wired access, an IP access link, a core link, a gateway, etc. The= point is that the definition of the value needs to take into account all th= e requirements. If the Wireless access portion needs the 5 levels defined fo= r WPS but GETS only needs one level while a regular call needs a "normal" le= vel then we could define 6 levels. Once the call setup gets beyond the wirel= ess access portion, the 5 individual levels defined for WPS may be treated t= he same. For assigning priority in a network, the level for GETS needs to be= assigned relative to the WPS levels.

The R-P header should not be seen as a way to label the type of call (GE= TS, WPS, etc). It should just be a relative priority. If there is a need to=20= label a call as WPS, or GETS, or something else, then there needs to be an e= xplicit label for that (which allows either or both). The "namespace" should= not be used for this.

Mike Pierce
--part1_1ec.c6bdb35.2c35da16_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 Jul 3 15:31:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03291 for ; Thu, 3 Jul 2003 15:31:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y9nO-0005r8-2y for sip-archive@odin.ietf.org; Thu, 03 Jul 2003 15:31:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63JV5Uu022500 for sip-archive@odin.ietf.org; Thu, 3 Jul 2003 15:31:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y9nJ-0005qP-He; Thu, 03 Jul 2003 15:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y9mL-0005l2-8m for sip@optimus.ietf.org; Thu, 03 Jul 2003 15:30: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 PAA03188 for ; Thu, 3 Jul 2003 15:29:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y9mJ-00004r-00 for sip@ietf.org; Thu, 03 Jul 2003 15:30:00 -0400 Received: from marionberry.cc.columbia.edu ([128.59.59.100] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19Y9mJ-00004n-00 for sip@ietf.org; Thu, 03 Jul 2003 15:29:59 -0400 Received: from cs.columbia.edu (dhcp39.cs.columbia.edu [128.59.19.239]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h63JTtHX022524 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 3 Jul 2003 15:29:55 -0400 (EDT) Message-ID: <3F048424.6040506@cs.columbia.edu> Date: Thu, 03 Jul 2003 15:29:40 -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: Janet.Gunn@DynCorp.com, sip@ietf.org, Dennis.Berg@DynCorp.com Subject: Re: [Sip] Re: multiple namespaces for SIP RPH References: <1ec.c6bdb35.2c35da16@aol.com> In-Reply-To: <1ec.c6bdb35.2c35da16@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 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org 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 Are you suggesting something that is essentially the cross-product of all priority namespaces? That seems rather unworkable. There is no need to resolve the relative priority of A.X vs B.Y if they are not used by the same system (different administrations), i.e., they are orthogonal. If they are used by the same system, that system can presumably work out what it means if it receives a request containing both A.X and B.Y. This does not require standardization; in particular, there are any number of reasonable solutions, including a "virtual resource", so that the system sets aside some fraction for A.* and some fraction for B.*. It might do some internal ordering, but as long as the partial order with A.* and B.* is maintained, this doesn't seem to cause any difficulties. I think of this as analogous to having both a 2nd class train ticket and a business class airfare - you need to carry both tickets with you as you travel, but the train conductor doesn't care about your airline ticket and vice versa. Mpierce1@aol.com wrote: > In a message dated 7/3/2003 10:27:35 AM Eastern Standard Time, > Janet.Gunn@DynCorp.com writes: > > >> In the US PSTN, a call may be a GETS call AND a WPS call; a GETS call >> BUT NOT a WPS call; or a WPS call BUT NOT a GETS call. >> The "labels" for a GETS call and a WPS call are different (CPC >> parameter vs. Precedence parameter) >> Being a GETS call determines treatment in the landline network. Being >> a WPS call determines treatment in the wireless network. >> It seems plausible that a similar situation could occur in IP >> networks - especially if one treatment was relevant in one >> administrative domain, but another was available in a second >> administrative domain. > > > > Yes, clearly a call can have multiple markings. It seems that we already > have lots of possibilities, both in the circuit-switched world and IP. > CPC, and its origins in SS#7 and US signaling, is one of them. > > I just think that the Resource-Priority header and its purpose require > that only one value (namespace) be carried in any single call setup > attempt. That single value may then cause different actions or results > for a wireless access, a wired access, an IP access link, a core link, a > gateway, etc. The point is that the definition of the value needs to > take into account all the requirements. If the Wireless access portion > needs the 5 levels defined for WPS but GETS only needs one level while a > regular call needs a "normal" level then we could define 6 levels. Once > the call setup gets beyond the wireless access portion, the 5 individual > levels defined for WPS may be treated the same. For assigning priority > in a network, the level for GETS needs to be assigned relative to the > WPS levels. > > The R-P header should not be seen as a way to label the type of call > (GETS, WPS, etc). It should just be a relative priority. If there is a > need to label a call as WPS, or GETS, or something else, then there > needs to be an explicit label for that (which allows either or both). > The "namespace" should not be used for this. > > Mike Pierce _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 3 15:36:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03416 for ; Thu, 3 Jul 2003 15:36:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y9sD-0006EC-5f for sip-archive@odin.ietf.org; Thu, 03 Jul 2003 15:36:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63Ja5Si023934 for sip-archive@odin.ietf.org; Thu, 3 Jul 2003 15:36:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y9sA-0006Da-3m; Thu, 03 Jul 2003 15: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 19Y9s3-0006DL-Rj for sip@optimus.ietf.org; Thu, 03 Jul 2003 15:35:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03393 for ; Thu, 3 Jul 2003 15:35:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y9s2-0000Jb-00 for sip@ietf.org; Thu, 03 Jul 2003 15:35:54 -0400 Received: from host-133-208.is.dyncorp.com ([131.131.133.208] helo=chntex04.is.dyncorp.com) by ietf-mx with esmtp (Exim 4.12) id 19Y9s1-0000JY-00 for sip@ietf.org; Thu, 03 Jul 2003 15:35:53 -0400 Received: by chntex04.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jul 2003 15:33:49 -0400 Message-ID: <5EA16A28B747E34FB90B578E6C5DDE8915AA53@chntex04.is.dyncorp.com> From: "Gunn, Janet" To: "'Henning Schulzrinne'" , Mpierce1@aol.com Cc: sip@ietf.org, "Berg, Dennis" Subject: RE: [Sip] Re: multiple namespaces for SIP RPH Date: Thu, 3 Jul 2003 15:33:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3419A.05E63D90" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3419A.05E63D90 Content-Type: text/plain; charset="iso-8859-1" Yes, that is a good analogy to what I was referring to. And I want to make it clear that I am NOT interested in extending the WPS/GETS "and/or" situation to IP domains- it is a "historical artifact". Only that similar "artifacts" may arise in IP domains. -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Thursday, July 03, 2003 3:30 PM I think of this as analogous to having both a 2nd class train ticket and a business class airfare - you need to carry both tickets with you as you travel, but the train conductor doesn't care about your airline ticket and vice versa. ------_=_NextPart_001_01C3419A.05E63D90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Re: multiple namespaces for SIP RPH

Yes, that is a good analogy to what I was referring = to.

 And I want to make it clear that I am NOT = interested in extending the WPS/GETS "and/or" situation to IP = domains- it is a "historical artifact".  Only that = similar "artifacts" may arise in IP domains.

-----Original Message-----
From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
Sent: Thursday, July 03, 2003 3:30 PM

I think of this as analogous to having both a 2nd = class train ticket and
a business class airfare - you need to carry both = tickets with you as
you travel, but the train conductor doesn't care = about your airline
ticket and vice versa.

------_=_NextPart_001_01C3419A.05E63D90-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 3 17:03:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06352 for ; Thu, 3 Jul 2003 17:03:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YBE1-0001oI-Pn for sip-archive@odin.ietf.org; Thu, 03 Jul 2003 17:02:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63L2fO0006959 for sip-archive@odin.ietf.org; Thu, 3 Jul 2003 17:02:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YBDQ-0001ng-HG; Thu, 03 Jul 2003 17:02:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YBD5-0001nE-IF for sip@optimus.ietf.org; Thu, 03 Jul 2003 17:01: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 RAA06337 for ; Thu, 3 Jul 2003 17:01:40 -0400 (EDT) From: Mpierce1@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YBD3-0002a9-00 for sip@ietf.org; Thu, 03 Jul 2003 17:01:41 -0400 Received: from imo-d05.mx.aol.com ([205.188.157.37]) by ietf-mx with esmtp (Exim 4.12) id 19YBD2-0002Zs-00 for sip@ietf.org; Thu, 03 Jul 2003 17:01:40 -0400 Received: from Mpierce1@aol.com by imo-d05.mx.aol.com (mail_out_v36_r1.1.) id 7.ae.436fd492 (3988); Thu, 3 Jul 2003 17:00:58 -0400 (EDT) Message-ID: Date: Thu, 3 Jul 2003 17:00:58 EDT Subject: Re: [Sip] Re: multiple namespaces for SIP RPH To: hgs@cs.columbia.edu CC: Janet.Gunn@DynCorp.com, sip@ietf.org, Dennis.Berg@DynCorp.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_ae.436fd492.2c35f38a_boundary" X-Mailer: 6.0 for Windows XP sub 10501 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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_ae.436fd492.2c35f38a_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 7/3/2003 3:30:15 PM Eastern Standard Time, hgs@cs.columbia.edu writes: > Are you suggesting something that is essentially the cross-product of > all priority namespaces? That seems rather unworkable. > > There is no need to resolve the relative priority of A.X vs B.Y if they > are not used by the same system (different administrations), i.e., they > are orthogonal. If they are used by the same system, that system can > presumably work out what it means if it receives a request containing > both A.X and B.Y. This does not require standardization; in particular, > there are any number of reasonable solutions, including a "virtual > resource", so that the system sets aside some fraction for A.* and some > fraction for B.*. It might do some internal ordering, but as long as the > partial order with A.* and B.* is maintained, this doesn't seem to cause > any difficulties. > > No, I am not suggesting any relationship between namespaces. Each is defined and registered separately. On the other hand, if a network chooses to handle multiple namespaces (one per call), it must decide how to determine the relative priorities when used on different calls that may contend for the same resources. There would be no standard and it would not be a part of the registration of each namespace. But if there are multiple namespaces defined that are intended to be used in the same "domain" or environment or whatever you want to call it and on the same call, then I think it may become necessary to define the relative priority, maybe in registration. We need to avoid this. The inclusion of multiple namespaces (or priorities) in a single SIP call setup request leads to the need for defining additional procedures to deal with them, including how to decide the sequence in which to try to interpret them. > think of this as analogous to having both a 2nd class train ticket and > a business class airfare - you need to carry both tickets with you as > you travel, but the train conductor doesn't care about your airline > ticket and vice versa. > I love analogies. I think including two namespace.priority values in the SIP header is more analogous to having two airline tickets, one first class and one coach, handing both to the ticket agent, and expecting the agent to pick which one to use. The airline/train analogy would be more like having a header for SIP to use and a separate parameter which only ISUP looks at. ISUP knows that it shouldn't look at the SIP header, just like the train conductor doesn't look at the airline ticket. This makes good sense. Mike Pierce --part1_ae.436fd492.2c35f38a_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 7/3/20= 03 3:30:15 PM Eastern Standard Time, hgs@cs.columbia.edu writes:


Are you suggesting somethin= g that is essentially the cross-product of=20
all priority namespaces? That seems rather unworkable.

There is no need to resolve the relative priority of A.X vs B.Y if they=20
are not used by the same system (different administrations), i.e., they=20
are orthogonal. If they are used by the same system, that system can=20
presumably work out what it means if it receives a request containing=20
both A.X and B.Y. This does not require standardization; in particular,=20
there are any number of reasonable solutions, including a "virtual=20
resource", so that the system sets aside some fraction for A.* and some=20
fraction for B.*. It might do some internal ordering, but as long as the= =20
partial order with A.* and B.* is maintained, this doesn't seem to cause= =20
any difficulties.




No, I am not suggesting any relationship between namespaces. Each is def= ined and registered separately. On the other hand, if a network chooses to h= andle multiple namespaces (one per call), it must decide how to determine th= e relative priorities when used on different calls that may contend for the=20= same resources. There would be no standard and it would not be a part of the= registration of each namespace.

But if there are multiple namespaces defined that are intended to be use= d in the same "domain" or environment or whatever you want to call it and on= the same call, then I think it may become necessary to define the relative=20= priority, maybe in registration. We need to avoid this.

The inclusion of multiple namespaces (or priorities) in a single SIP cal= l setup request leads to the need for defining additional procedures to deal= with them, including how to decide the sequence in which to try to interpre= t them.

think of this as analogous= to having both a 2nd class train ticket and=20
a business class airfare - you need to carry both tickets with you as=20
you travel, but the train conductor doesn't care about your airline=20
ticket and vice versa.


I love analogies. I think including two namespace.priority values in the= SIP header is more analogous to having two airline tickets, one first class= and one coach, handing both to the ticket agent, and expecting the agent to= pick which one to use.

The airline/train analogy would be more like having a header for SIP to=20= use and a separate parameter which only ISUP looks at. ISUP knows that it sh= ouldn't look at the SIP header, just like the train conductor doesn't look a= t the airline ticket. This makes good sense.

Mike Pierce
--part1_ae.436fd492.2c35f38a_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 Jul 3 17:16:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07201 for ; Thu, 3 Jul 2003 17:16:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YBR4-0002T0-37 for sip-archive@odin.ietf.org; Thu, 03 Jul 2003 17:16:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63LGA7F009481 for sip-archive@odin.ietf.org; Thu, 3 Jul 2003 17:16:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YBQw-0002SV-1w; Thu, 03 Jul 2003 17: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 19YBQ3-0002Rn-UB for sip@optimus.ietf.org; Thu, 03 Jul 2003 17:15:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07085 for ; Thu, 3 Jul 2003 17:15:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YBPy-0003E6-00 for sip@ietf.org; Thu, 03 Jul 2003 17:15:02 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.59.238] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19YBPw-0003E1-00 for sip@ietf.org; Thu, 03 Jul 2003 17:15:01 -0400 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 h63LEs5p027925 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 3 Jul 2003 17:14:54 -0400 (EDT) Message-ID: <3F049CBE.9090403@cs.columbia.edu> Date: Thu, 03 Jul 2003 17:14:38 -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: Janet.Gunn@DynCorp.com, sip@ietf.org, Dennis.Berg@DynCorp.com Subject: Re: [Sip] Re: multiple namespaces for SIP RPH References: In-Reply-To: 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 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > The inclusion of multiple namespaces (or priorities) in a single SIP > call setup request leads to the need for defining additional procedures > to deal with them, including how to decide the sequence in which to try > to interpret them. Multiple priorities (A.X and A.Y) for the same namespace seem bad, but why would we have to define how a node handles R-P: A.X, B.Y ? There are any number of reasonable options: - Look for A; if A exists, ignore anything else. - Look first for A, then B, then C, then .... Once found, stop and ignore the rest. - Have some total order among the A and B priorities, defined strictly by local policy. Find A.X and B.Y and pick the "better" (or "worse") one. Anything else? If somebody really sees the need, we can't keep them from publishing such a total order ("If A and B are used in the same system, the following ordering ...."), but I don't see the need for this right now at the IETF standards level. > >> think of this as analogous to having both a 2nd class train ticket and >> a business class airfare - you need to carry both tickets with you as >> you travel, but the train conductor doesn't care about your airline >> ticket and vice versa. > > > > I love analogies. I think including two namespace.priority values in the > SIP header is more analogous to having two airline tickets, one first > class and one coach, handing both to the ticket agent, and expecting the > agent to pick which one to use. Not quite: Y and C tickets are from the same namespace. Think of having a Delta Gold/Silver Medaillon and a Business/Economy Ticket. > > The airline/train analogy would be more like having a header for SIP to > use and a separate parameter which only ISUP looks at. ISUP knows that > it shouldn't look at the SIP header, just like the train conductor > doesn't look at the airline ticket. This makes good sense. Again, a SIP request may visit any number of different administrations along the way to its destination, often unpredictable by the sender (due to name translations, among many other reasons). > > Mike Pierce _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 3 18:13:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10774 for ; Thu, 3 Jul 2003 18:13:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YCJe-0005rw-GO for sip-archive@odin.ietf.org; Thu, 03 Jul 2003 18:12:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63MCYaO022554 for sip-archive@odin.ietf.org; Thu, 3 Jul 2003 18:12:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YCJ8-0005fc-3x; Thu, 03 Jul 2003 18:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YCIj-0005bV-82 for sip@optimus.ietf.org; Thu, 03 Jul 2003 18:11: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 SAA10611 for ; Thu, 3 Jul 2003 18:11:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YCIg-0005VC-00 for sip@ietf.org; Thu, 03 Jul 2003 18:11:34 -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 19YCIe-0005V9-00 for sip@ietf.org; Thu, 03 Jul 2003 18:11:32 -0400 Received: from localhost (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h63MBS24017036; Thu, 3 Jul 2003 17:11:28 -0500 From: Dean Willis To: sip@ietf.org Cc: rohan@cisco.com Content-Type: text/plain Message-Id: <1057270288.16993.5.camel@bdsl.greycouncil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 03 Jul 2003 17:11:28 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Initial agenda for SIP Working Group meeting at IETF 57 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org 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 Here's the initial agenda for SIP at IETF 57. A pretty version with the reading-list hyperlinked in is available at: http://www.softarmor.com/sipwg/meets/ietf57/agenda.html Send me any issues with this initial agenda. We'll work out what we can. Of course, we'll probably make some last-minute adjustments, hence the "agenda bash" that is always the first thing on the agenda. -- Dean ------------- Draft Agenda, SIP WG, IETF 57 ________________________________________________________________________ Wednesay, July 16, 2003, 0900-1130 Hall IL 0900 Agenda Bash Chairs 0905 Status of Work Chairs IETF Last Calls draft-ietf-sip-content-indirect-mech-03.txt draft-ietf-sip-sctp-03.txt IESG Reviews draft-ietf-sip-scvrtdisco-04.txt draft-ietf-simple-event-list-04.txt draft-ietf-sip-replaces-03.txt draft-ietf-sip-symmetric-response-01.txt WGLCs draft-ietf-sip-authid-body-02.txt draft-ietf-sip-referredby-02.txt 0930 Discussion of PUBLISH (WG) Aki Niemi draft-ietf-simple-publish-01.txt 0945 Discussion of Resource Priority (WG) Henning Schulzrinne, James Polk draft-ietf-sip-resource-priority-00.txt 0955 Discussion of Caller-prefs (WG) Jonathan Rosenberg draft-ietf-sip-callerprefs-09.txt draft-ietf-sipping-callerprefs-usecases-00.txt draft-ietf-sip-callee-caps-00.txt 1010 Discussion of SIP Identity (WG) Jon Peterson draft-ietf-sip-asserted-identity-02.txt 1020 Discussion of SIP MIME (WG) Jon Peterson draft-ietf-sip-smime-aes-01.txt 1030 Discussion of History Info (WG) Mary Barnes draft-ietf-sip-history-info-00.txt 1040 Discussion of Sec-Inserted (Ind) Mary Barnes draft-barnes-sipping-sec-inserted-info-00.txt 1050 Discussion of Non-Invite transactions Robert Sparks draft-sparks-sip-noninvite-00.txt 1055 Discussion of Parameter Registry Gonzalo Camarillo draft-camarillo-sip-parameter-registry-01.txt draft-camarillo-sip-uri-parameter-reg-00.txt 1105 Discussion of Connection Reuse Rohan Mahy draft-mahy-sip-connect-reuse-00.txt draft-ietf-sipping-connect-reuse-reqs-00.txt 1115 Discussion of App Info Cullen Jennings draft-jennings-sip-app-info-01.txt ________________________________________________________________________ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sun Jul 6 09:02:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12391 for ; Sun, 6 Jul 2003 09:02:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Z990-0004iP-Ms for sip-archive@odin.ietf.org; Sun, 06 Jul 2003 09:01:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h66D1UHe018122 for sip-archive@odin.ietf.org; Sun, 6 Jul 2003 09:01:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Z98X-0004hq-3r; Sun, 06 Jul 2003 09: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 19Z98A-0004h3-BU for sip@optimus.ietf.org; Sun, 06 Jul 2003 09:00: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 JAA12365 for ; Sun, 6 Jul 2003 09:00:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Z988-0001wg-00 for sip@ietf.org; Sun, 06 Jul 2003 09:00:36 -0400 Received: from ierw.net.avaya.com ([198.152.13.101]) by ietf-mx with esmtp (Exim 4.12) id 19Z987-0001wc-00 for sip@ietf.org; Sun, 06 Jul 2003 09:00:36 -0400 Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02515 for ; Sun, 6 Jul 2003 08:57:47 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02504 for ; Sun, 6 Jul 2003 08:57:45 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C343BE.9370F8B2" Date: Sun, 6 Jul 2003 16:00:29 +0300 Message-ID: Thread-Topic: Comments on draft-ietf-sip-mib-06.txt Thread-Index: AcNDvpOC+vmSJJEYQ4alkraWdoj9bA== From: "Romascanu, Dan (Dan)" To: Cc: , , , , "Bert Wijnen (E-mail)" Subject: [Sip] Comments on draft-ietf-sip-mib-06.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C343BE.9370F8B2 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Here are my comments concerning the latest version of the SIP MIB. I = congratulate the authors for a much better document, and I thank them = for taking into account and including fixes to most of the problems that = were included in the review I did on the previous version.=20 There are still a few problems that need to be fixed: A1) smilint complains about the following: SIP-COMMON.txt:2014: [5] {integer-misuse} warning: use Integer32 instead = of INTEGER in SMIv2 -- for sipStatusCodeValue -- SIP-COMMON.txt:2940: [5] {group-unref} warning: current group = `sipCommonNotifObjectsGroup' is not referenced in this module A2) You would like to re-consider the OID place holders that you created = for sipRedirCfg, sipRedirStats, sipRegCfg, sipRegStats. This is not an SMI violation, but it creates for the time being a hole = in a MIB walk. If you need to add the definition of the respective = objects in the future, you will not be able to do it in the same = document, without the need to re-cycle the document at Proposed Standard = level.=20 A3) DESCRIPTION Clause of sipServiceNotifEnable - Saying that in case = notifications are not implemented, the value has 'no meaning and MUST be = 0', seems contradictory and inaccurate. The respective sentence should = read - 'The notifications are OPTIONAL, and if they are not implemented, = this object's value MUST be all 0s.' A4) How does sipNotifSequenceNumber work? It should probably be = increased once for each notification defined in the SIP MIBs, but not = for each notification target (in the case of multiple managers). I = suggest this to be detailed in the DESCRIPTION clause for clarity. =20 Minor editorial issues: B1) English syntax in section 4.1. It should probably read 'The data = type SipTransportProtocol is used as Textual Convention in this = document. Textual conventions have...' B2) Eliminate the commented text in the SIP compliance module of the UA = MIB. =20 Regards, Dan ------_=_NextPart_001_01C343BE.9370F8B2 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Comments on draft-ietf-sip-mib-06.txt

Here are my comments = concerning the latest version of the SIP MIB. I congratulate the authors = for a much better document, and I thank them for taking into account and = including fixes to most of the problems that were included in the review = I did on the previous version.

There are still a few = problems that need to be fixed:

A1) smilint complains about = the following:

SIP-COMMON.txt:2014: [5] = {integer-misuse} warning: use Integer32 instead of INTEGER in SMIv2 -- = for sipStatusCodeValue --

SIP-COMMON.txt:2940: [5] = {group-unref} warning: current group `sipCommonNotifObjectsGroup' is not = referenced in this module

A2) You would like to = re-consider the OID place holders that you created for sipRedirCfg, = sipRedirStats, sipRegCfg, sipRegStats.

This is not = an SMI violation, but it creates for the time being a hole in a MIB = walk. If you need to add the definition of the respective objects in the = future, you will not be able to do it in the same document, without the = need to re-cycle the document at Proposed Standard level. =

A3) = DESCRIPTION Clause of sipServiceNotifEnable -  Saying that in case = notifications are not implemented, the value has 'no meaning and MUST be = 0', seems contradictory and inaccurate. The respective sentence should = read - 'The notifications are OPTIONAL, and if they are not implemented, = this object's value MUST be all 0s.'

A4) How = does sipNotifSequenceNumber work? It should probably be increased once = for each notification defined in the SIP MIBs, but not for each = notification target (in the case of multiple managers). I suggest this = to be detailed in the DESCRIPTION clause for clarity.

 

Minor = editorial issues:

B1) English = syntax in section 4.1. It should probably read 'The data type = SipTransportProtocol is used as Textual Convention in this document. = Textual conventions have...'

B2) = Eliminate the commented text in the SIP compliance module of the UA = MIB. 

Regards,

Dan

------_=_NextPart_001_01C343BE.9370F8B2-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 7 03:51:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16574 for ; Mon, 7 Jul 2003 03:51:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZQmN-0003xl-GM for sip-archive@odin.ietf.org; Mon, 07 Jul 2003 03:51:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h677pJqi015233 for sip-archive@odin.ietf.org; Mon, 7 Jul 2003 03:51:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZQm7-0003wU-AR; Mon, 07 Jul 2003 03:51:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZQle-0003vl-DQ for sip@optimus.ietf.org; Mon, 07 Jul 2003 03:50:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16484; Mon, 7 Jul 2003 03:50:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZQlU-0001ca-00; Mon, 07 Jul 2003 03:50:24 -0400 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 19ZQlT-0001cW-00; Mon, 07 Jul 2003 03:50:23 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h677oM1R000384; Mon, 7 Jul 2003 16:50:22 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h677oL8E011473; Mon, 7 Jul 2003 16:50:21 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h677oKeH007805; Mon, 7 Jul 2003 16:50:21 +0900 (JST) Received: from ime.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id QAA15432; Mon, 7 Jul 2003 16:50:19 +0900 (JST) Received: from [127.0.0.1] by ime.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id QAA22703; Mon, 7 Jul 2003 16:50:19 +0900 (JST) Date: Mon, 07 Jul 2003 16:49:18 +0900 From: "NAKAMURA, Hidefumi" To: sip@ietf.org, mmusic@ietf.org Cc: hidefumi.nakamura@staff.east.ntt.co.jp Message-Id: <20030707134023.181C.NAKAMURA.HIDEFUMI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.11 Content-Transfer-Encoding: 7bit Subject: [Sip] Appropriate usage of SIP and RTSP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, all. I have a question about the relationship between SIP and RTSP. In RFC3261, there is a description that says "SIP is not a vertically integrated communications system. SIP is rather a component that can be used with other IETF protocols to build a complete multimedia architecture. Typically, these architectures will include protocols such as the Real-time Transport Protocol (RTP) (RFC 1889 [28]) for transporting real-time data and providing QoS feedback, the Real-Time streaming protocol (RTSP) (RFC 2326 [29]) for controlling delivery of streaming media, ..." (RFC3261 Section 2) However, my understanding is that both SIP and RTSP have the capability for "discovery of UAs or media streams." If I use SIP to establish a stream session and use RTSP to control the stream, there will be redundant sequences, i.e. INVITE-OK-ACK and SETUP-OK. Was there any discussion on how to use these two protocols appropriately? With SIP application server, network providers can provide various services on contents delivery while we will not be able to do so only with RTSP, I think. On the other hand, RTSP has enough capability for discovery of media streams and for negotiation of SDPs. So, I think, for the simple delivery of contents, RTSP is appropriate to use, and for various session control services regarding contents delivery, SIP with RTSP is appropriate to use. Any opinions? I wonder why no contents delivery server seems to prepare SIP stack now. Is it because, up to now, there exists only a simple contents delivery service? best regards, -- NAKAMURA, Hidefumi NTT ServiceIntegration /NetworkServiceSystems Labs. tel: +81(422)59 3904; fax:+81(422)60 4012 --- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 7 05:30:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18561 for ; Mon, 7 Jul 2003 05:30:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZSKH-0007ti-Kd for sip-archive@odin.ietf.org; Mon, 07 Jul 2003 05:30:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h679UPLT030354 for sip-archive@odin.ietf.org; Mon, 7 Jul 2003 05:30:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZSJu-0007pX-RL; Mon, 07 Jul 2003 05:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZSJO-0007oQ-GY for sip@optimus.ietf.org; Mon, 07 Jul 2003 05:29: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 FAA18518; Mon, 7 Jul 2003 05:29:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZSJL-0002am-00; Mon, 07 Jul 2003 05:29:27 -0400 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 19ZSJJ-0002aj-00; Mon, 07 Jul 2003 05:29:26 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h679TL1R016892; Mon, 7 Jul 2003 18:29:22 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h679TL8E027105; Mon, 7 Jul 2003 18:29:21 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h679TLeH001479; Mon, 7 Jul 2003 18:29:21 +0900 (JST) Received: from ime.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id SAA23972; Mon, 7 Jul 2003 18:29:20 +0900 (JST) Received: from [127.0.0.1] by ime.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id SAA02492; Mon, 7 Jul 2003 18:29:20 +0900 (JST) Date: Mon, 07 Jul 2003 18:28:19 +0900 From: "NAKAMURA, Hidefumi" To: Magnus Westerlund Cc: sip@ietf.org, mmusic@ietf.org In-Reply-To: <3F0930B4.8090202@ericsson.com> References: <20030707134023.181C.NAKAMURA.HIDEFUMI@lab.ntt.co.jp> <3F0930B4.8090202@ericsson.com> Message-Id: <20030707174715.1826.NAKAMURA.HIDEFUMI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.11 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [MMUSIC] Appropriate usage of SIP and RTSP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear Magnus, Thank you for your quick response. I wrote down my opinion after your comments. > Hi, > > See comments inline: > > NAKAMURA, Hidefumi wrote: > > Hi, all. > > > > I have a question about the relationship between SIP and RTSP. > > > > In RFC3261, there is a description that says > > "SIP is not a vertically integrated communications system. SIP is > > rather a component that can be used with other IETF protocols to > > build a complete multimedia architecture. Typically, these > > architectures will include protocols such as the Real-time Transport > > Protocol (RTP) (RFC 1889 [28]) for transporting real-time data and > > providing QoS feedback, the Real-Time streaming protocol (RTSP) (RFC > > 2326 [29]) for controlling delivery of streaming media, ..." > > (RFC3261 Section 2) > > > > However, my understanding is that both SIP and RTSP have the capability > > for "discovery of UAs or media streams." > > If I use SIP to establish a stream session and use RTSP to control > > the stream, there will be redundant sequences, i.e. INVITE-OK-ACK and > > SETUP-OK. > > > > Was there any discussion on how to use these two protocols appropriately? > > Not to my knowledge. The SIP and RTSP combination has not been explored, > however it seem to contain a number of use cases. For example inviting a > media server into a SIP session or a conference session. > > There are significant overlap in SIP and RTSP, mostly in regards to > session establishment that are done i different ways. > > > > With SIP application server, network providers can provide various > > services on contents delivery while we will not be able to do so only > > with RTSP, I think. On the other hand, RTSP has enough capability for > > discovery of media streams and for negotiation of SDPs. > > So, I think, for the simple delivery of contents, RTSP is appropriate to > > use, and for various session control services regarding contents > > delivery, SIP with RTSP is appropriate to use. > > What do you mean with "session control services regarding contents > delivery"? For example, if we establish a stream session via SIP application server owned by the network provider, the application server can redirect the session to the appropriate contents delivery server from the standpoint of location, bandwidth prepared between terminals and the server, or condition of contents server (i.e. in congestion, failure, and so on.) Say, we get a media stream URI from a portal server. The terminal(or set top box) requests a session initiation to the media stream URI to the SIP application server. The SIP application server routes the request to the contents delivery server that stores the media. However, if the server is in congestion and returns 503, the SIP application server can select and redirect the session to another contents delivery server instead. I do not think this is possible with only RTSP. (though the interaction among the portal server, contents delivery servers and the terminals might enable this type of service in some extent.) > > Any opinions? > > > > I wonder why no contents delivery server seems to prepare SIP stack now. > > Is it because, up to now, there exists only a simple contents delivery > > service? > > I believe that no one has looked into this and have had a need. I understand. Thank you very much for your comments. Maybe it is interesting to investigate the use case, anyway. > Best Regards > > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic -- NAKAMURA, Hidefumi NTT ServiceIntegration /NetworkServiceSystems Labs. tel: +81(422)59 3904; fax:+81(422)60 4012 --- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 7 08:47:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23188 for ; Mon, 7 Jul 2003 08:47:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZVOq-0007Do-0Y for sip-archive@odin.ietf.org; Mon, 07 Jul 2003 08:47:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67ClJUF027751 for sip-archive@odin.ietf.org; Mon, 7 Jul 2003 08:47:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZVOW-0007CE-W9; Mon, 07 Jul 2003 08:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZVNc-0007BE-6k for sip@optimus.ietf.org; Mon, 07 Jul 2003 08:46: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 IAA23173 for ; Mon, 7 Jul 2003 08:46:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZVNa-0003qj-00 for sip@ietf.org; Mon, 07 Jul 2003 08:46:02 -0400 Received: from bay9-f67.bay9.hotmail.com ([64.4.47.67] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19ZVNa-0003q7-00 for sip@ietf.org; Mon, 07 Jul 2003 08:46:02 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 7 Jul 2003 05:45:30 -0700 Received: from 80.74.106.2 by by9fd.bay9.hotmail.msn.com with HTTP; Mon, 07 Jul 2003 12:45:30 GMT X-Originating-IP: [80.74.106.2] X-Originating-Email: [johnloggan@hotmail.com] From: "John Loggan" To: sip@ietf.org Date: Mon, 07 Jul 2003 12:45:30 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 07 Jul 2003 12:45:30.0546 (UTC) FILETIME=[A627A120:01C34485] Subject: [Sip] Handling non-2xx response for BYE request Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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, What is the correct behavior of a uac that receives a non-2xx resposne for a BYE request sent on an exisiting dialog ? should it terminate the call ? According to rfc 3261 (15.1.1): "A BYE request is constructed as would any other request within a dialog, as described in Section 12. Once the BYE is constructed, the UAC core creates a new non-INVITE client transaction, and passes it the BYE request. The UAC MUST consider the session terminated (and therefore stop sending or listening for media) as soon as the BYE request is passed to the client transaction. If the response for the BYE is a 481 (Call/Transaction Does Not Exist) or a 408 (Request Timeout) or no response at all is received for the BYE (that is, a timeout is returned by the client transaction), the UAC MUST consider the session and the dialog terminated." From the uas side - what responses are reasonable for rejecting BYE, besides 401/407 and 481 ? should it keep the dialog or terminate it after rejecting a BYE ? if the uas reject the BYE but doesn't terminate the session, and the uac consider the session terminated as soon as it sent the BYE, then we might reach a-symetric situation where the uas has an active session but the uac already terminated the session. thanks, John. _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Jul 7 09:43:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24521 for ; Mon, 7 Jul 2003 09:43:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWGv-00013l-5w for sip-archive@odin.ietf.org; Mon, 07 Jul 2003 09:43:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67DhDso004068 for sip-archive@odin.ietf.org; Mon, 7 Jul 2003 09:43:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWGj-00012e-GQ; Mon, 07 Jul 2003 09:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWGB-00012G-7p for sip@optimus.ietf.org; Mon, 07 Jul 2003 09:42: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 JAA24485 for ; Mon, 7 Jul 2003 09:42:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZWG9-0004ES-00 for sip@ietf.org; Mon, 07 Jul 2003 09:42:25 -0400 Received: from mail.aastra.com ([216.94.98.95]) by ietf-mx with esmtp (Exim 4.12) id 19ZWG8-0004EF-00 for sip@ietf.org; Mon, 07 Jul 2003 09:42:24 -0400 Received: by mail.aastra.com with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Jul 2003 09:39:24 -0400 Message-ID: From: Marc Archer To: sip@ietf.org Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-mib-06.txt Date: Mon, 7 Jul 2003 09:27:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 comments on the draft TITLE: Has anyone come across a compilation error for not having a proper IANA assigned number? I am getting error during compilation (Sub-Id for item "sipTC" must be "number" or "name (number)" format) as it is Draft version & we do not have mib-2 number. We got to have a number for SIP-COMMON-MIB, SIP-TC & SIP-UA-MIB. ::= { mib-2 xx } -- RFC Ed: replace xx with actual IANA assigned number Any thoughts? TITLE: Error due to BITS usage I am experiencing a compilation error due to missing declaration of BITS in SIP-COMMON-MIB & SIP-TC. There is a BITS usage in the MIB files. SYNTAX BITS { other(0), -- none of the following udp(1), tcp(2), sctp(3), tls(4) } In the IMPORTS Section, it was not defined; I was getting the following Error message. SMI item "BITS" used in SIP-TC, but not defined or imported. Since "BITS" is defined in RFC1902.MIB (SNMPv2-SMI), which is already included in the *.INC file, I added "BITS" in the IMPORTS Section as below: IMPORTS MODULE-IDENTITY, mib-2, BITS FROM SNMPv2-SMI The compilation goes much further but it then comes up with the following error: expected a string, got BITS Any help will be very much appreciated. Regards, Marc Archer -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, July 02, 2003 6:57 AM Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-mib-06.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Management Information Base for Session Initiation Protocol Author(s) : K. Lingle, J. Maeng, J. Mule, D. Walker Filename : draft-ietf-sip-mib-06.txt Pages : 104 Date : 2003-7-1 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Session Initiation Protocol (SIP) entities, which include User Agents, Proxy servers, Redirect servers and Registrars. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-mib-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-mib-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon Jul 7 09:58:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25151 for ; Mon, 7 Jul 2003 09:58:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWVe-0001rP-Az for sip-archive@odin.ietf.org; Mon, 07 Jul 2003 09:58:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67DwQ05007140 for sip-archive@odin.ietf.org; Mon, 7 Jul 2003 09:58:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWVF-0001ok-6J; Mon, 07 Jul 2003 09:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWUy-0001o7-5f for sip@optimus.ietf.org; Mon, 07 Jul 2003 09:57: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 JAA25078 for ; Mon, 7 Jul 2003 09:57:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZWUv-0004R5-00 for sip@ietf.org; Mon, 07 Jul 2003 09:57:41 -0400 Received: from iere.net.avaya.com ([198.152.12.101]) by ietf-mx with esmtp (Exim 4.12) id 19ZWUu-0004Qx-00 for sip@ietf.org; Mon, 07 Jul 2003 09:57:40 -0400 Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h67DsKO16837 for ; Mon, 7 Jul 2003 09:54:20 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h67DsJ316813 for ; Mon, 7 Jul 2003 09:54:19 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-mib-06.txt Date: Mon, 7 Jul 2003 16:57:34 +0300 Message-ID: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-mib-06.txt Thread-Index: AcNEjcjm4ZAnf+CIQ9uZmvKoBwX/CwAAUFUA From: "Romascanu, Dan (Dan)" To: "Marc Archer" , 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 Marc, 1) The OID assignment for the MIB modules is being done by RFC Editor in = the final phases of releasing the RFC. Replace meantime xx with a number = of your choice, trying to avoid the already defined numbers, in order to = pass compilation. 2) RFC 2578 Section 3.2 specifies which symbols must be imported and = also lists certain pre-defined symbols that must not be imported. The = BITS construct must not be imported.=20 For more information about standard MIBs review procedures (including = compilation tools and options) see = http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-= 01.txt. Regards, Dan =20 > -----Original Message----- > From: Marc Archer [mailto:marcher@aastra.com] > Sent: 07 July, 2003 4:27 PM > To: sip@ietf.org > Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-mib-06.txt >=20 >=20 > Some comments on the draft >=20 > TITLE: Has anyone come across a compilation error for not=20 > having a proper > IANA assigned number? >=20 > I am getting error during compilation (Sub-Id for item "sipTC" must be > "number" or "name (number)" format) as it is Draft version &=20 > we do not have > mib-2 number. We got to have a number for SIP-COMMON-MIB, SIP-TC & > SIP-UA-MIB. >=20 > ::=3D { mib-2 xx }=20 > -- RFC Ed: replace xx with actual IANA assigned number =20 >=20 > Any thoughts?=20 >=20 > TITLE: Error due to BITS usage >=20 > I am experiencing a compilation error due to missing=20 > declaration of BITS in > SIP-COMMON-MIB & SIP-TC. >=20 > There is a BITS usage in the MIB files. >=20 > SYNTAX BITS { =20 > other(0), -- none of the=20 > following =20 > udp(1), =20 > tcp(2), =20 > sctp(3), =20 > tls(4) =20 > } =20 >=20 > In the IMPORTS Section, it was not defined; I was getting the=20 > following > Error message. >=20 > SMI item "BITS" used in SIP-TC, but not defined or imported. >=20 > Since "BITS" is defined in RFC1902.MIB (SNMPv2-SMI), which is already > included in the *.INC file, I added "BITS" in the IMPORTS=20 > Section as below: >=20 > IMPORTS =20 > MODULE-IDENTITY, =20 > mib-2, BITS =20 > FROM SNMPv2-SMI =20 >=20 > The compilation goes much further but it then comes up with=20 > the following > error: >=20 > expected a string, got BITS >=20 >=20 > Any help will be very much appreciated. >=20 > Regards, >=20 > Marc Archer >=20 > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Wednesday, July 02, 2003 6:57 AM > Cc: sip@ietf.org > Subject: [Sip] I-D ACTION:draft-ietf-sip-mib-06.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Session Initiation Protocol=20 > Working Group > of the IETF. >=20 > Title : Management Information Base for=20 > Session Initiation >=20 > Protocol > Author(s) : K. Lingle, J. Maeng, J. Mule, D. Walker > Filename : draft-ietf-sip-mib-06.txt > Pages : 104 > Date : 2003-7-1 > =09 > This memo defines a portion of the Management Information Base (MIB)=20 > for use with network management protocols in the Internet community. =20 > In particular, it describes a set of managed objects that are used=20 > to manage Session Initiation Protocol (SIP) entities, which include=20 > User Agents, Proxy servers, Redirect servers and Registrars. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-06.txt >=20 > To remove yourself from the IETF Announcement list, send a message to=20 > ietf-announce-request with the word unsubscribe in the body=20 > of the message. >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-sip-mib-06.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html=20 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sip-mib-06.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=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 >=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 From exim@www1.ietf.org Mon Jul 7 16:22:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13269 for ; Mon, 7 Jul 2003 16:22:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZcUP-0002QW-JO for sip-archive@odin.ietf.org; Mon, 07 Jul 2003 16:21:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67KLX3e009327 for sip-archive@odin.ietf.org; Mon, 7 Jul 2003 16:21:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZcTu-0002Pb-14; Mon, 07 Jul 2003 16:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZcTa-0002OI-On for sip@optimus.ietf.org; Mon, 07 Jul 2003 16:20: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 QAA13180 for ; Mon, 7 Jul 2003 16:20:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZcTY-0002BA-00 for sip@ietf.org; Mon, 07 Jul 2003 16:20:40 -0400 Received: from mail.aastra.com ([216.94.98.95]) by ietf-mx with esmtp (Exim 4.12) id 19ZcTX-0002AD-00 for sip@ietf.org; Mon, 07 Jul 2003 16:20:39 -0400 Received: by mail.aastra.com with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Jul 2003 16:17:33 -0400 Message-ID: From: Marc Archer To: sip@ietf.org Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-mib-06.txt Date: Mon, 7 Jul 2003 16:05:23 -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: , Hi, One more query: We are trying to integrate the Draft version for SIP MIBs ( http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-06.txt). In this, there is a BITS definition. BITS is not declared in the IMPORTS section (RFC 2578 Section 3.2) of the mib file. I have included RFC 1902 in the .INC file as below: #condInclude "rfc1902.inc" -- SNMPv2-SMI When I compile, I am getting the error ": f(sip_tc.mib), (3,1) SMI item "BITS" used in SIP-TC, but not defined or imported". I am using SMICng version 2.1.03(BOOK)(MS-DOS32), February 12, 1997. Could someone tell me a fix for this problem? Is there any switch option that can take care of this? Regards, Marc Archer -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Monday, July 07, 2003 9:58 AM To: Marc Archer; sip@ietf.org Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-mib-06.txt Marc, 1) The OID assignment for the MIB modules is being done by RFC Editor in the final phases of releasing the RFC. Replace meantime xx with a number of your choice, trying to avoid the already defined numbers, in order to pass compilation. 2) RFC 2578 Section 3.2 specifies which symbols must be imported and also lists certain pre-defined symbols that must not be imported. The BITS construct must not be imported. For more information about standard MIBs review procedures (including compilation tools and options) see http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-01. txt. Regards, Dan > -----Original Message----- > From: Marc Archer [mailto:marcher@aastra.com] > Sent: 07 July, 2003 4:27 PM > To: sip@ietf.org > Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-mib-06.txt > > > Some comments on the draft > > TITLE: Has anyone come across a compilation error for not > having a proper > IANA assigned number? > > I am getting error during compilation (Sub-Id for item "sipTC" must be > "number" or "name (number)" format) as it is Draft version & > we do not have > mib-2 number. We got to have a number for SIP-COMMON-MIB, SIP-TC & > SIP-UA-MIB. > > ::= { mib-2 xx } > -- RFC Ed: replace xx with actual IANA assigned number > > Any thoughts? > > TITLE: Error due to BITS usage > > I am experiencing a compilation error due to missing > declaration of BITS in > SIP-COMMON-MIB & SIP-TC. > > There is a BITS usage in the MIB files. > > SYNTAX BITS { > other(0), -- none of the > following > udp(1), > tcp(2), > sctp(3), > tls(4) > } > > In the IMPORTS Section, it was not defined; I was getting the > following > Error message. > > SMI item "BITS" used in SIP-TC, but not defined or imported. > > Since "BITS" is defined in RFC1902.MIB (SNMPv2-SMI), which is already > included in the *.INC file, I added "BITS" in the IMPORTS > Section as below: > > IMPORTS > MODULE-IDENTITY, > mib-2, BITS > FROM SNMPv2-SMI > > The compilation goes much further but it then comes up with > the following > error: > > expected a string, got BITS > > > Any help will be very much appreciated. > > Regards, > > Marc Archer > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Wednesday, July 02, 2003 6:57 AM > Cc: sip@ietf.org > Subject: [Sip] I-D ACTION:draft-ietf-sip-mib-06.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Session Initiation Protocol > Working Group > of the IETF. > > Title : Management Information Base for > Session Initiation > > Protocol > Author(s) : K. Lingle, J. Maeng, J. Mule, D. Walker > Filename : draft-ietf-sip-mib-06.txt > Pages : 104 > Date : 2003-7-1 > > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular, it describes a set of managed objects that are used > to manage Session Initiation Protocol (SIP) entities, which include > User Agents, Proxy servers, Redirect servers and Registrars. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-06.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body > of the message. > > Internet-Drafts are also available by anonymous FTP. Login > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-sip-mib-06.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sip-mib-06.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 7 17:11:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16133 for ; Mon, 7 Jul 2003 17:11:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZdGj-0006Qa-KX for sip-archive@odin.ietf.org; Mon, 07 Jul 2003 17:11:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67LBTbQ024704 for sip-archive@odin.ietf.org; Mon, 7 Jul 2003 17:11:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZdGH-0006Li-Bj; Mon, 07 Jul 2003 17:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZdFZ-0006Gl-Si for sip@optimus.ietf.org; Mon, 07 Jul 2003 17:10: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 RAA15965 for ; Mon, 7 Jul 2003 17:10:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZdFX-0002wN-00 for sip@ietf.org; Mon, 07 Jul 2003 17:10:15 -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 19ZdFW-0002vh-00 for sip@ietf.org; Mon, 07 Jul 2003 17:10:14 -0400 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h67L9b7F017420; Mon, 7 Jul 2003 14:09:37 -0700 (PDT) Received: from cisco.com (klingle-ultra.cisco.com [64.102.93.47]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AGF90418; Mon, 7 Jul 2003 14:09:36 -0700 (PDT) Message-ID: <3F09E190.8070709@cisco.com> Date: Mon, 07 Jul 2003 17:09:36 -0400 From: Kevin Lingle User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marc Archer CC: sip@ietf.org Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-mib-06.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit marc, we (cisco) used to have essentially the same problem due to older verison of smicng not recognizing BITS construct. i believe newer versions of smicng (i think we have v2.2.11 now) have fixed this afaik. i know that we used to have to "work around" this by commenting out BITS syntax and replacing it with OCTET STRING. i suggest you contact http://www.snmpinfo.com for a definitive answer on whether your version of smicng is deficient wrt BITS or whether there is a switch you can turn on to eliminate the compile problem. btw, i ran the mib modules though smicng before publishing and did not have any errors reported.... except for the mib numbers: xx, yy which are eliminated by putting in some arbitrary (high) mib-2 oid assigned numbers (per dan's earlier suggestion). kevin Marc Archer wrote: > Hi, > > One more query: > > We are trying to integrate the Draft version for SIP MIBs ( > http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-06.txt). In this, > there is a BITS definition. BITS is not declared in the IMPORTS section (RFC > 2578 Section 3.2) of the mib file. I have included RFC 1902 in the .INC file > as below: > > #condInclude "rfc1902.inc" -- SNMPv2-SMI > > When I compile, I am getting the error > > ": f(sip_tc.mib), (3,1) SMI item "BITS" used in SIP-TC, but not defined or > imported". > > I am using SMICng version 2.1.03(BOOK)(MS-DOS32), February 12, 1997. > > Could someone tell me a fix for this problem? Is there any switch option > that can take care of this? > > Regards, > > Marc Archer > > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Monday, July 07, 2003 9:58 AM > To: Marc Archer; sip@ietf.org > Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-mib-06.txt > > > Marc, > > 1) The OID assignment for the MIB modules is being done by RFC Editor in the > final phases of releasing the RFC. Replace meantime xx with a number of your > choice, trying to avoid the already defined numbers, in order to pass > compilation. > 2) RFC 2578 Section 3.2 specifies which symbols must be imported and also > lists certain pre-defined symbols that must not be imported. The BITS > construct must not be imported. > > For more information about standard MIBs review procedures (including > compilation tools and options) see > http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-01. > txt. > > Regards, > > Dan > > >>-----Original Message----- >>From: Marc Archer [mailto:marcher@aastra.com] >>Sent: 07 July, 2003 4:27 PM >>To: sip@ietf.org >>Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-mib-06.txt >> >> >>Some comments on the draft >> >>TITLE: Has anyone come across a compilation error for not >>having a proper >>IANA assigned number? >> >>I am getting error during compilation (Sub-Id for item "sipTC" must be >>"number" or "name (number)" format) as it is Draft version & >>we do not have >>mib-2 number. We got to have a number for SIP-COMMON-MIB, SIP-TC & >>SIP-UA-MIB. >> >> ::= { mib-2 xx } >> -- RFC Ed: replace xx with actual IANA assigned number >> >>Any thoughts? >> >>TITLE: Error due to BITS usage >> >>I am experiencing a compilation error due to missing >>declaration of BITS in >>SIP-COMMON-MIB & SIP-TC. >> >>There is a BITS usage in the MIB files. >> >> SYNTAX BITS { >> other(0), -- none of the >>following >> udp(1), >> tcp(2), >> sctp(3), >> tls(4) >> } >> >>In the IMPORTS Section, it was not defined; I was getting the >>following >>Error message. >> >>SMI item "BITS" used in SIP-TC, but not defined or imported. >> >>Since "BITS" is defined in RFC1902.MIB (SNMPv2-SMI), which is already >>included in the *.INC file, I added "BITS" in the IMPORTS >>Section as below: >> >> IMPORTS >> MODULE-IDENTITY, >> mib-2, BITS >> FROM SNMPv2-SMI >> >>The compilation goes much further but it then comes up with >>the following >>error: >> >>expected a string, got BITS >> >> >>Any help will be very much appreciated. >> >>Regards, >> >>Marc Archer >> >>-----Original Message----- >>From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >>Sent: Wednesday, July 02, 2003 6:57 AM >>Cc: sip@ietf.org >>Subject: [Sip] I-D ACTION:draft-ietf-sip-mib-06.txt >> >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >>This draft is a work item of the Session Initiation Protocol >>Working Group >>of the IETF. >> >> Title : Management Information Base for >>Session Initiation >> >> Protocol >> Author(s) : K. Lingle, J. Maeng, J. Mule, D. Walker >> Filename : draft-ietf-sip-mib-06.txt >> Pages : 104 >> Date : 2003-7-1 >> >>This memo defines a portion of the Management Information Base (MIB) >>for use with network management protocols in the Internet community. >>In particular, it describes a set of managed objects that are used >>to manage Session Initiation Protocol (SIP) entities, which include >>User Agents, Proxy servers, Redirect servers and Registrars. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-06.txt >> >>To remove yourself from the IETF Announcement list, send a message to >>ietf-announce-request with the word unsubscribe in the body >>of the message. >> >>Internet-Drafts are also available by anonymous FTP. Login >>with the username >>"anonymous" and a password of your e-mail address. After logging in, >>type "cd internet-drafts" and then >> "get draft-ietf-sip-mib-06.txt". >> >>A list of Internet-Drafts directories can be found in >>http://www.ietf.org/shadow.html >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >>Internet-Drafts can also be obtained by e-mail. >> >>Send a message to: >> mailserv@ietf.org. >>In the body type: >> "FILE /internet-drafts/draft-ietf-sip-mib-06.txt". >> >>NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant >>mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >>Below is the data which will enable a MIME compliant mail reader >>implementation to automatically retrieve the ASCII version of the >>Internet-Draft. >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kevin R. Lingle 919.392.2029 http://www.klove.com http://www.air1.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 Tue Jul 8 02:55:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12237 for ; Tue, 8 Jul 2003 02:55:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZmNg-0008QX-Kv for sip-archive@odin.ietf.org; Tue, 08 Jul 2003 02:55:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h686tGM0032389 for sip-archive@odin.ietf.org; Tue, 8 Jul 2003 02:55:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZmNS-0008Pj-My; Tue, 08 Jul 2003 02:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZmNC-0008PD-Ad for sip@optimus.ietf.org; Tue, 08 Jul 2003 02:54: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 CAA12204 for ; Tue, 8 Jul 2003 02:54:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZmN8-00073V-00 for sip@ietf.org; Tue, 08 Jul 2003 02:54:42 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ZmN7-00073A-00 for sip@ietf.org; Tue, 08 Jul 2003 02:54:41 -0400 Received: from dynamicsoft.com ([63.113.46.11]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h686sAiB005501 for ; Tue, 8 Jul 2003 02:54:15 -0400 (EDT) Message-ID: <3F0A6A8D.3040903@dynamicsoft.com> Date: Tue, 08 Jul 2003 02:54:05 -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: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] New I-D on callee capabilities Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, You may have noticed that I posted a new I-D on SIP callee capabilities: http://www.ietf.org/internet-drafts/draft-ietf-sip-callee-caps-00.txt http://www.jdrosen.net/papers/draft-ietf-sip-callee-caps-00.txt http://www.jdrosen.net/papers/draft-ietf-sip-callee-caps-00.html This represents one half of the split of the former caller preferences spec. The above draft considers only capabilities - setting the contact parameters in REGISTER, OPTIONS, target refresh requests. Functionally, there is no change from the capabilities aspects of caller-prefs-08. The document is substantially reorganized, however, and I think reads pretty well. The reason for the split was that we believed (and I still do believe), that we are going to continue to have a tough time with the caller preferences piece. However, several key documents are blocked on a reference to callerprefs. By doing this split, we can move forward quickly with the capabilities doc. Most of the current docs blocked on a reference are actually blocked on the capabilities piece. So, they will be able to proceed as well. Comments/questions welcome as always. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer 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 Tue Jul 8 03:17:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12653 for ; Tue, 8 Jul 2003 03:17:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zmis-0001D3-3Z for sip-archive@odin.ietf.org; Tue, 08 Jul 2003 03:17:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h687HAqd004643 for sip-archive@odin.ietf.org; Tue, 8 Jul 2003 03:17:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zmil-0001B3-6W; Tue, 08 Jul 2003 03:17:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zmi3-00019h-I3 for sip@optimus.ietf.org; Tue, 08 Jul 2003 03:16: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 DAA12605 for ; Tue, 8 Jul 2003 03:16:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zmi1-00079E-00 for sip@ietf.org; Tue, 08 Jul 2003 03:16:17 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19Zmi0-00079B-00 for sip@ietf.org; Tue, 08 Jul 2003 03:16:16 -0400 Received: from dynamicsoft.com ([63.113.46.11]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h687FbiB005511; Tue, 8 Jul 2003 03:15:37 -0400 (EDT) Message-ID: <3F0A6F93.5000305@dynamicsoft.com> Date: Tue, 08 Jul 2003 03:15:31 -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: sip@ietf.org CC: Ted Hardie Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Changes in caller prefs -09 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, You may have noticed that caller prefs -09 was posted: http://www.jdrosen.net/papers/draft-ietf-sip-callerprefs-09.txt http://www.jdrosen.net/papers/draft-ietf-sip-callerprefs-09.html http://www.ietf.org/internet-drafts/draft-ietf-sip-callerprefs-09.txt This document is substantially different from -08. First, the capabilities stuff has been yanked into a separate I-D (http://www.ietf.org/internet-drafts/draft-ietf-sip-callee-caps-00.txt). That includes REGISTER and OPTIONS processing, and all of the media feature tag definitions and registrations. The reason for the split, as I indicated in another note, was that we believed there were going to continue to be problems with the caller preferences piece of callerprefs (i.e., the Accept-Contact and Reject-Contact header fields). A big issue we encountered with -08 based on excellent input from Ted Hardie, was that q-value arithmetic is a no-no. Q-values as defined are ordinal, and you can't perform arithmetic on them, or compare them between different sources. We had been doing a lot of that in -08. So, in -09, the algorithm has changed. THe proxy computes the score for each Accept-Contact rule against each Contact, as before. The overall caller preference for a contact is then computed as the average of the scores across all Accept-Contacts for that contact. Previously, we had a really complex function instead of arithmetic average. The reason had a lot to do with quirks that arise when you try to do q-value arithmetic. Anyway, once the average (the caller preference) is computed, it is used in a specific way. For those contacts with EQUAL Q-VALUES AS SET BY THE CALLEE, the caller preference is used to order them. We never combine the caller and callee preferences; we merely use the caller preference to provide an order when the callee provides none. This algorithm is a lot simpler, and it never tries to do arithmetic on q-values. However, there is some loss of functionality. I tested the algorithm on all of the use cases, and found that a few failed. For example, Section 3.5 of http://www.jdrosen.net/papers/draft-ietf-sipping-callerprefs-usecases-00.txt describes a case. There, the caller wants the call to go to a videophone, but will take an audio-only device as a second choice. The callee prefers the audio-only phone. Because the caller preferences can't ever reorder callee contacts with differing q-values, there is no way to "override" the callee preference for the audio phone, and still fall back to it in the case where the videophone doesnt work or can't be reached. Section 3.12 describes a similar case, where a user wants to go right to voicemail, but will take a call with the user if there is no voicemail. We can't do that anymore. I welcome comments on whether this loss of functionality is substantial enough that we need to investigate ways of getting it back. I personally would prefer to just declare victory with what works and move on. Some of the other changes: * elimination of the q-values in the Accept-Contact; they were never needed in any of the use cases, so I removed them * Clarification on the purpose of Proxy-Require, based on comments by Mary and others during wglc. * A lot more discussion on how to set the require and explicit parameters. These can be confusing, and its hard to tell which of them you need. * when a proxy is redirecting, it sets the q-values for the contacts to anything which orders them based on the results of the above algorithm Comments and questions welcome. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer 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 Tue Jul 8 11:33:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27050 for ; Tue, 8 Jul 2003 11:33:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZuT5-0000Ny-Jf for sip-archive@odin.ietf.org; Tue, 08 Jul 2003 11:33:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68FXNPL001476 for sip-archive@odin.ietf.org; Tue, 8 Jul 2003 11:33:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZuSj-0000Jr-9q; Tue, 08 Jul 2003 11: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 19ZuRq-00009X-F1 for sip@optimus.ietf.org; Tue, 08 Jul 2003 11:32:06 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26901; Tue, 8 Jul 2003 11:31:59 -0400 (EDT) Message-Id: <200307081531.LAA26901@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , sip@ietf.org From: The IESG Date: Tue, 08 Jul 2003 11:31:59 -0400 Subject: [Sip] Protocol Action: An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing to Proposed Standard Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , The IESG has approved the Internet-Draft 'An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing' as a Proposed Standard. This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary The Session Initiation Protocol (SIP) operates over UDP and TCP. When used with UDP, responses to requests are returned to the source address the request came from, and to the port written into the topmost Via header field value of the request. This behavior is not desirable in many cases, most notably, when the client is behind a Network Address Translator (NAT). This extension defines a new parameter for the Via header field, called "rport", that allows a client to request that the server send the response back to the source IP address and port where the request came from. Working Group Summary The Working Group supported the advancement of this document. There were reviews by working group members. Protocol Quality The document includes an analysis of the work in the perspective of the IAB's UNSAF Considerations. The review for the IESG was carried out by Allison Mankin. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Tue Jul 8 16:42:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09435 for ; Tue, 8 Jul 2003 16:42:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZzIC-0004Sc-Th for sip-archive@odin.ietf.org; Tue, 08 Jul 2003 16:42:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68KgSSb017142 for sip-archive@odin.ietf.org; Tue, 8 Jul 2003 16:42:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZzHm-0004OA-8Z; Tue, 08 Jul 2003 16:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZzGv-0004NP-RA for sip@optimus.ietf.org; Tue, 08 Jul 2003 16:41: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 QAA09346; Tue, 8 Jul 2003 16:41:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZzGt-0006BT-00; Tue, 08 Jul 2003 16:41:07 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19ZzGs-0006Au-00; Tue, 08 Jul 2003 16:41:06 -0400 Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h68KePiB005887; Tue, 8 Jul 2003 16:40:30 -0400 (EDT) Message-ID: <3F0B2C34.6040709@dynamicsoft.com> Date: Tue, 08 Jul 2003 16:40:20 -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: "NAKAMURA, Hidefumi" CC: Magnus Westerlund , sip@ietf.org, mmusic@ietf.org References: <20030707134023.181C.NAKAMURA.HIDEFUMI@lab.ntt.co.jp> <3F0930B4.8090202@ericsson.com> <20030707174715.1826.NAKAMURA.HIDEFUMI@lab.ntt.co.jp> In-Reply-To: <20030707174715.1826.NAKAMURA.HIDEFUMI@lab.ntt.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [MMUSIC] Appropriate usage of SIP and RTSP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I agree that there is significant overlap between RTSP and SIP, and this is something that has been bothering more and more over time. I have had in mind to write a draft on the ways in which they could be better merged, but have not had the time. The primary place where they overlap is session establishment. In this area, I think SIP is much richer, in terms of features. SIP would allow connections to media servers running on PCs and other end-user devices. Its rich routing facilities could allow nice policy-based connection to content. It has had a lot of work on firewall/nat traversal which is now only getting repeated for RTSP. Plus, in many cases, you might initiate a session, but not know, in advance, that the session is to be connected to a content server. As an example, I'd like to be able to make a sip call to a user, and instead get connected to a voicemail greeting that I can control with RTSP. IMHO, the most obvious way to make this work is to use SIP to initiate a session. If the session is to a media server, then, using SDP negotiations, one can add an additional "media channel", which is actually RTSP, doing just media controls (play, fast-forward, etc.). Thus, SIP would set up an RTSP session to control the media that the SIP call connected to. I havent really fleshed this out much, but it seemed like a start. -Jonathan R. NAKAMURA, Hidefumi wrote: > Dear Magnus, > > Thank you for your quick response. > I wrote down my opinion after your comments. > > >>Hi, >> >>See comments inline: >> >>NAKAMURA, Hidefumi wrote: >> >>>Hi, all. >>> >>>I have a question about the relationship between SIP and RTSP. >>> >>>In RFC3261, there is a description that says >>> "SIP is not a vertically integrated communications system. SIP is >>> rather a component that can be used with other IETF protocols to >>> build a complete multimedia architecture. Typically, these >>> architectures will include protocols such as the Real-time Transport >>> Protocol (RTP) (RFC 1889 [28]) for transporting real-time data and >>> providing QoS feedback, the Real-Time streaming protocol (RTSP) (RFC >>> 2326 [29]) for controlling delivery of streaming media, ..." >>> (RFC3261 Section 2) >>> >>>However, my understanding is that both SIP and RTSP have the capability >>>for "discovery of UAs or media streams." >>>If I use SIP to establish a stream session and use RTSP to control >>>the stream, there will be redundant sequences, i.e. INVITE-OK-ACK and >>>SETUP-OK. >>> >>>Was there any discussion on how to use these two protocols appropriately? >> >>Not to my knowledge. The SIP and RTSP combination has not been explored, >>however it seem to contain a number of use cases. For example inviting a >>media server into a SIP session or a conference session. >> >>There are significant overlap in SIP and RTSP, mostly in regards to >>session establishment that are done i different ways. >> >>>With SIP application server, network providers can provide various >>>services on contents delivery while we will not be able to do so only >>>with RTSP, I think. On the other hand, RTSP has enough capability for >>>discovery of media streams and for negotiation of SDPs. >>>So, I think, for the simple delivery of contents, RTSP is appropriate to >>>use, and for various session control services regarding contents >>>delivery, SIP with RTSP is appropriate to use. >> >>What do you mean with "session control services regarding contents >>delivery"? > > > For example, if we establish a stream session via SIP application server > owned by the network provider, the application server can redirect the > session to the appropriate contents delivery server from the standpoint > of location, bandwidth prepared between terminals and the server, or > condition of contents server (i.e. in congestion, failure, and so on.) > Say, we get a media stream URI from a portal server. The terminal(or > set top box) requests a session initiation to the media stream URI to > the SIP application server. The SIP application server routes the > request to the contents delivery server that stores the media. However, > if the server is in congestion and returns 503, the SIP application > server can select and redirect the session to another contents delivery > server instead. > I do not think this is possible with only RTSP. > (though the interaction among the portal server, contents delivery > servers and the terminals might enable this type of service in some > extent.) > > >>>Any opinions? >>> >>>I wonder why no contents delivery server seems to prepare SIP stack now. >>>Is it because, up to now, there exists only a simple contents delivery >>>service? >> >>I believe that no one has looked into this and have had a need. > > > I understand. Thank you very much for your comments. > Maybe it is interesting to investigate the use case, anyway. > > >>Best Regards >> >> >>Magnus Westerlund >> >>Multimedia Technologies, Ericsson Research EAB/TVA/A >>---------------------------------------------------------------------- >>Ericsson AB | Phone +46 8 4048287 >>Torshamsgatan 23 | Fax +46 8 7575550 >>S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> >> >>_______________________________________________ >>mmusic mailing list >>mmusic@ietf.org >>https://www1.ietf.org/mailman/listinfo/mmusic > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer 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 Tue Jul 8 21:32:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18593 for ; Tue, 8 Jul 2003 21:32:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a3om-0007Sk-Ug for sip-archive@odin.ietf.org; Tue, 08 Jul 2003 21:32:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h691WO6S028682 for sip-archive@odin.ietf.org; Tue, 8 Jul 2003 21:32:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a3oQ-0007S1-JD; Tue, 08 Jul 2003 21:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a3oL-0007RX-MK for sip@optimus.ietf.org; Tue, 08 Jul 2003 21:31: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 VAA18565 for ; Tue, 8 Jul 2003 21:31:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a3oI-0002ci-00 for sip@ietf.org; Tue, 08 Jul 2003 21:31:54 -0400 Received: from eeca1.sogang.ac.kr ([163.239.140.151]) by ietf-mx with esmtp (Exim 4.12) id 19a3oH-0002cf-00 for sip@ietf.org; Tue, 08 Jul 2003 21:31:54 -0400 Received: from kutestar (eeca10.sogang.ac.kr [163.239.143.158]) by eeca1.sogang.ac.kr (8.11.7+Sun/8.9.1) with SMTP id h691XqE25937 for ; Wed, 9 Jul 2003 10:33:52 +0900 (KST) Message-ID: <002801c345ba$049d30f0$9e8fefa3@kutestar> From: "Derek Kim" To: Date: Wed, 9 Jul 2003 10:32:53 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01C34605.7471C620" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4920.2300 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Subject: [Sip] Sending ACK to the callee Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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_0025_01C34605.7471C620 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: base64 SGksIGFsbC4NCg0KDQoNCldoZW4gSGFycnkgd2FudHMgdG8gbWFrZSBhIHNlc3Npb24gd2l0aCBT YWxseSwgaG93IGNhbiBoZSBrbm93IGhlciBJUCBhZGRyZXNzPyAoQWZ0ZXIgaGUgcmVjZWl2ZXMg MjAwIE9LIGZyb20gaGVyLikNCk9yIGhvdyBjYW4gU2FsbHkgdGVsbCBoZXIgSVAgYWRkcmVzcyB0 byBIYXJyeT8gKHdpdGhpbiAyMDAgT0sgZnJvbSBoZXIuKQ0KDQpUaGFua3MgZm9yIHJlcGx5aW5n LiA6KQ0KDQoNCg0KQmVzdCBSZWdhcmRzLA0KDQoNCn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn4NCg0KRGVyZWsgS2ltDQoNClNlbmlv ciBFbmdpbmVlcg0KUmVhbCBUaW1lIEludGVybmV0IExhYi4NClNvZ2FuZyBVbml2ZXJzaXR5DQpv ZmZpY2UgOiArODItMi0zMjcyLTMyMjANCiANCn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn4NCg== ------=_NextPart_000_0025_01C34605.7471C620 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXdp bmRvd3MtMTI1MiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hU TUwgNS4wMC4zNTAyLjUzOTAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hF QUQ+DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPg0KPERJVj4NCjxESVY+PEZPTlQgc2l6 ZT0yPkhpLCBhbGwuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+V2hlbiBIYXJyeSB3 YW50cyB0byBtYWtlIGEgc2Vzc2lvbiB3aXRoIFNhbGx5LCBob3cgY2FuIGhlIGtub3cgDQpoZXIg SVAgYWRkcmVzcz8gKEFmdGVyIGhlIHJlY2VpdmVzIDIwMCBPSyBmcm9tIGhlci4pPEJSPk9yIGhv dyBjYW4gU2FsbHkgdGVsbCANCmhlciBJUCBhZGRyZXNzIHRvIEhhcnJ5PyAod2l0aGluIDIwMCBP SyBmcm9tIGhlci4pPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg c2l6ZT0yPlRoYW5rcyBmb3IgcmVwbHlpbmcuIDopPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBz aXplPTI+QmVzdCBSZWdhcmRzLDwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCANCnNpemU9Mj5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+PC9GT05UPjwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+DQo8RElWPjxGT05UIHNpemU9Mj5EZXJlayBLaW08L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48QlI+U2VuaW9yIEVuZ2luZWVyPC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBzaXplPTI+UmVhbCBUaW1lIEludGVybmV0IExhYi48L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj5Tb2dhbmcgVW5pdmVyc2l0eTwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yPm9mZmljZSA6ICs4Mi0yLTMyNzItMzIyMDwvRk9OVD48L0RJVj48L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgDQpzaXpl PTI+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fjwvRk9OVD48L0RJVj48L0RJVj48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0025_01C34605.7471C620-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 9 03:10:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21017 for ; Wed, 9 Jul 2003 03:10:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a95l-0000FI-Ge for sip-archive@odin.ietf.org; Wed, 09 Jul 2003 03:10:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h697AHZ9000843 for sip-archive@odin.ietf.org; Wed, 9 Jul 2003 03:10:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a95Y-0000A3-6W; Wed, 09 Jul 2003 03:10:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zai1-0002k2-SI for sip@optimus.ietf.org; Mon, 07 Jul 2003 14:27:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06448 for ; Mon, 7 Jul 2003 14:27:26 -0400 (EDT) From: Carlos.Gonzalez_De_Requena_Farre@alcatel.es Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zahz-0000KX-00 for sip@ietf.org; Mon, 07 Jul 2003 14:27:27 -0400 Received: from [194.224.48.69] (helo=sess01.rdp.asi.alcatel.es) by ietf-mx with esmtp (Exim 4.12) id 19Zahy-0000Jm-00 for sip@ietf.org; Mon, 07 Jul 2003 14:27:26 -0400 Received: from seslotq.rdp.asi.alcatel.es (localhost [127.0.0.1]) by sess01.rdp.asi.alcatel.es (8.12.9/8.12.9) with ESMTP id h67IQpB1005158 for ; Mon, 7 Jul 2003 20:26:52 +0200 (MEST) To: sip@ietf.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: Date: Mon, 7 Jul 2003 20:27:01 +0200 X-MIMETrack: Serialize by Router on ESMAIL02/ES/ALCATEL(Release 5.0.11 |July 24, 2002) at 07/07/2003 20:27:04 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Sip] question about mime mmutipart mixed, in case of SIP-T Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hello, I have a simple question about multipart bodies... Suppose the following message: S I P / 2 . 0 1 8 0 R i n g i n g M I M E - v e r s i o n : 1 . 0 C o n t e n t - T y p e : m u l t i p a r t / m i x e d ;b o u n d a r y = b o u n d a r y1 T o : < s i p : 0 2 1 4 4 4 4 1 0 4 1 @ 2 1 8 . 1 . 1 3 0 . 7 1 ; U s e r= p h o n e > ; t a g = 0 0 0 00 0 0 0 0 0 0 0 6 6 A F 8 9 5 50 D 0 0 F r o m : < s i p : 0 5 7 1 8 6 5 4 1 2 0 2 @ 6 1 .1 3 0 . 1 . 2 0 ; U s e r = p ho n e > ; t a g = 3 f 0 3 f e 52 - 2 3 c a - 3 d 8 2 0 1 1 4 V i a : S I P / 2 . 0 / U D P 6 1 . 1 3 0 . 1 . 2 0 : 5 0 6 0 ; b r a n c h = z 9 h G 4 b K 1 2 4 5 6 6 1 3 5 1 . C a l l - I D : 3 F 0 3 F E 5 2 - 0 0 0 0 0 0 0 0 @ J F S I P P C U 1 C S e q : 1 I N V I T E R e q u i r e : 1 0 0 r e l R S e q : 4 3 9 8 1 C o n t a c t : < s i p : 0 2 1 4 4 4 4 1 0 4 1 @ 2 1 8 . 1 . 1 3 0 . 7 1 : 5 0 6 0 > D a t e : T h u , 3 J u l 2 0 0 3 1 7 : 2 8 : 0 9 G M T T i m e s t a m p : 2 1 8 9 7 S u p p o r t e d : 1 0 0 r e l C o n t e n t - L e n g t h : 2 4 9 - - b o u n d a r y1 C o n t e n t - T y p e : a p p l i c a t i o n / S D P v = 0 o = - 1 2 1 2 I N I P 4 2 1 8 . 1 . 1 3 1 . 2 s = S D P D a t a c = I N I P 4 2 1 8 . 1 . 1 3 1 . 2 t = 0 0 m = a u d i o 4 0 0 0 R T P / A V P 8 - - b o u n d a r y1 C o n t e n t - T y p e : a p p l i c a t i o n / I S U P ; v e r s i o n = X - Q . 7 6 7 ^F ^T^D ^@ - - b o u n d a r y1 - - Checking between the sdp part and ISUP part, just after the line m= audio 4000 RTP/AVP 8 we find only one CRLF,and just after this the "- -boundary1" Checking in the rfc 2046 i could not clearly find wether this would be correct, or instead a double CRLF would need to be instead. In fact, in one of the examples of rfc 3204 i could see that the same format is followed and only one CRLF is applied. Could someone clarify this to me? Best regards and thanks, Carlos _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 9 03:10:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21032 for ; Wed, 9 Jul 2003 03:10:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a95l-0000F8-Fu for sip-archive@odin.ietf.org; Wed, 09 Jul 2003 03:10:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h697AHfB000842 for sip-archive@odin.ietf.org; Wed, 9 Jul 2003 03:10:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a95W-00009X-MB; Wed, 09 Jul 2003 03:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZRSo-0005jR-RZ for sip@optimus.ietf.org; Mon, 07 Jul 2003 04:35: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 EAA17358; Mon, 7 Jul 2003 04:35:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZRSl-00026o-00; Mon, 07 Jul 2003 04:35:07 -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 19ZRSk-00026j-00; Mon, 07 Jul 2003 04:35:07 -0400 Received: from esealnt613.al.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 h678Z7Ii004491; Mon, 7 Jul 2003 10:35:07 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id N8X2QR16; Mon, 7 Jul 2003 10:35:07 +0200 Message-ID: <3F0930B4.8090202@ericsson.com> Date: Mon, 07 Jul 2003 10:35:00 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "NAKAMURA, Hidefumi" CC: sip@ietf.org, mmusic@ietf.org, hidefumi.nakamura@staff.east.ntt.co.jp References: <20030707134023.181C.NAKAMURA.HIDEFUMI@lab.ntt.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [MMUSIC] Appropriate usage of SIP and RTSP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org 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, See comments inline: NAKAMURA, Hidefumi wrote: > Hi, all. > > I have a question about the relationship between SIP and RTSP. > > In RFC3261, there is a description that says > "SIP is not a vertically integrated communications system. SIP is > rather a component that can be used with other IETF protocols to > build a complete multimedia architecture. Typically, these > architectures will include protocols such as the Real-time Transport > Protocol (RTP) (RFC 1889 [28]) for transporting real-time data and > providing QoS feedback, the Real-Time streaming protocol (RTSP) (RFC > 2326 [29]) for controlling delivery of streaming media, ..." > (RFC3261 Section 2) > > However, my understanding is that both SIP and RTSP have the capability > for "discovery of UAs or media streams." > If I use SIP to establish a stream session and use RTSP to control > the stream, there will be redundant sequences, i.e. INVITE-OK-ACK and > SETUP-OK. > > Was there any discussion on how to use these two protocols appropriately? Not to my knowledge. The SIP and RTSP combination has not been explored, however it seem to contain a number of use cases. For example inviting a media server into a SIP session or a conference session. There are significant overlap in SIP and RTSP, mostly in regards to session establishment that are done i different ways. > > With SIP application server, network providers can provide various > services on contents delivery while we will not be able to do so only > with RTSP, I think. On the other hand, RTSP has enough capability for > discovery of media streams and for negotiation of SDPs. > So, I think, for the simple delivery of contents, RTSP is appropriate to > use, and for various session control services regarding contents > delivery, SIP with RTSP is appropriate to use. What do you mean with "session control services regarding contents delivery"? > > Any opinions? > > I wonder why no contents delivery server seems to prepare SIP stack now. > Is it because, up to now, there exists only a simple contents delivery > service? I believe that no one has looked into this and have had a need. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.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 Wed Jul 9 03:56:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22821 for ; Wed, 9 Jul 2003 03:56:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a9oP-0006ky-2c for sip-archive@odin.ietf.org; Wed, 09 Jul 2003 03:56:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h697uODG025966 for sip-archive@odin.ietf.org; Wed, 9 Jul 2003 03:56:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a9o2-0006jp-R9; Wed, 09 Jul 2003 03:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a9nj-0006is-40 for sip@optimus.ietf.org; Wed, 09 Jul 2003 03:55: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 DAA22789; Wed, 9 Jul 2003 03:55:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a9ng-0004ng-00; Wed, 09 Jul 2003 03:55:40 -0400 Received: from [193.205.242.5] (helo=nausicaa.coritel.it ident=root) by ietf-mx with esmtp (Exim 4.12) id 19a9nf-0004nc-00; Wed, 09 Jul 2003 03:55:39 -0400 Received: from cori8 (cori8.diiie.unisa.it [193.205.164.71]) by nausicaa.coritel.it (8.11.2/8.11.2) with ESMTP id h697taI25552; Wed, 9 Jul 2003 09:55:36 +0200 Message-ID: <000801c345ed$49699dd0$47a4cdc1@cori8> From: "Paolo Asprino" To: "NAKAMURA, Hidefumi" , , References: <20030707134023.181C.NAKAMURA.HIDEFUMI@lab.ntt.co.jp> Subject: Re: [Sip] Appropriate usage of SIP and RTSP Date: Wed, 9 Jul 2003 09:39:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 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: base64 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 SGkgYWxsDQoNCkknbSB0aGlua2luZyBhIHNvbHV0aW9uIHRvIGpvaW4gU0lQIGFuZCBSVFNQIGlu IHRoZSAzRyBJTVMgZG9tYWluLg0KSW4gcGFydGljdWxhciBpbiB0aGUgSU1TLCBJIHRoaW5rIHRo YXQgdG8gcHJvdmlkZSBtdWx0aWxtZWRpYQ0Kc2VydmljZSAoaS5lIHZpZGVvIG9uIGRlbWFuZCks IG9uZSBjYW4gZXN0YWJpbGlzaCBhIHN1YnNjcmlwdGlvbiB0byB0aGUgc2VydmljZSBieSBTSVAg YW5kIHRoZW4gYWN0aXZhdGUgdGhlIHNlcnZpY2Ugd2l0aCBSVFNQIGJ5IERJR0VTVCBhdXRlbnRp Y2F0aW9uIHdpdGggdGhlIA0KcGFyYW1ldGVycyBleGNoYW5nZWQgZWFybHkgZHVyaW5nIHRoZSBz dWJzY3JpcHRpb24gKHVzZXJuYW1lIGFuZCBwYXNzd29yZCkgDQoNCldoYXQgZG8geW91IHRoaW5r IGFib3V0IHRoYXQ/DQoNCkJlc3QgUmVnYXJkcyANCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAt LS0tLSANCkZyb206ICJOQUtBTVVSQSwgSGlkZWZ1bWkiIDxuYWthbXVyYS5oaWRlZnVtaUBsYWIu bnR0LmNvLmpwPg0KVG86IDxzaXBAaWV0Zi5vcmc+OyA8bW11c2ljQGlldGYub3JnPg0KQ2M6IDxo aWRlZnVtaS5uYWthbXVyYUBzdGFmZi5lYXN0Lm50dC5jby5qcD4NClNlbnQ6IE1vbmRheSwgSnVs eSAwNywgMjAwMyA5OjQ5IEFNDQpTdWJqZWN0OiBbU2lwXSBBcHByb3ByaWF0ZSB1c2FnZSBvZiBT SVAgYW5kIFJUU1ANCg0KDQo+IEhpLCBhbGwuDQo+IA0KPiBJIGhhdmUgYSBxdWVzdGlvbiBhYm91 dCB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gU0lQIGFuZCBSVFNQLiANCj4gDQo+IEluIFJGQzMy NjEsIHRoZXJlIGlzIGEgZGVzY3JpcHRpb24gdGhhdCBzYXlzIA0KPiAgICAiU0lQIGlzIG5vdCBh IHZlcnRpY2FsbHkgaW50ZWdyYXRlZCBjb21tdW5pY2F0aW9ucyBzeXN0ZW0uICBTSVAgaXMNCj4g ICAgcmF0aGVyIGEgY29tcG9uZW50IHRoYXQgY2FuIGJlIHVzZWQgd2l0aCBvdGhlciBJRVRGIHBy b3RvY29scyB0bw0KPiAgICBidWlsZCBhIGNvbXBsZXRlIG11bHRpbWVkaWEgYXJjaGl0ZWN0dXJl LiAgVHlwaWNhbGx5LCB0aGVzZQ0KPiAgICBhcmNoaXRlY3R1cmVzIHdpbGwgaW5jbHVkZSBwcm90 b2NvbHMgc3VjaCBhcyB0aGUgUmVhbC10aW1lIFRyYW5zcG9ydA0KPiAgICBQcm90b2NvbCAoUlRQ KSAoUkZDIDE4ODkgWzI4XSkgZm9yIHRyYW5zcG9ydGluZyByZWFsLXRpbWUgZGF0YSBhbmQNCj4g ICAgcHJvdmlkaW5nIFFvUyBmZWVkYmFjaywgdGhlIFJlYWwtVGltZSBzdHJlYW1pbmcgcHJvdG9j b2wgKFJUU1ApIChSRkMNCj4gICAgMjMyNiBbMjldKSBmb3IgY29udHJvbGxpbmcgZGVsaXZlcnkg b2Ygc3RyZWFtaW5nIG1lZGlhLCAuLi4iDQo+ICAgIChSRkMzMjYxIFNlY3Rpb24gMikNCj4gDQo+ IEhvd2V2ZXIsIG15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBib3RoIFNJUCBhbmQgUlRTUCBoYXZl IHRoZSBjYXBhYmlsaXR5DQo+IGZvciAiZGlzY292ZXJ5IG9mIFVBcyBvciBtZWRpYSBzdHJlYW1z LiINCj4gSWYgSSB1c2UgU0lQIHRvIGVzdGFibGlzaCBhIHN0cmVhbSBzZXNzaW9uIGFuZCB1c2Ug UlRTUCB0byBjb250cm9sDQo+IHRoZSBzdHJlYW0sIHRoZXJlIHdpbGwgYmUgcmVkdW5kYW50IHNl cXVlbmNlcywgaS5lLiBJTlZJVEUtT0stQUNLIGFuZA0KPiBTRVRVUC1PSy4NCj4gDQo+IFdhcyB0 aGVyZSBhbnkgZGlzY3Vzc2lvbiBvbiBob3cgdG8gdXNlIHRoZXNlIHR3byBwcm90b2NvbHMgYXBw cm9wcmlhdGVseT8NCj4gDQo+IFdpdGggU0lQIGFwcGxpY2F0aW9uIHNlcnZlciwgbmV0d29yayBw cm92aWRlcnMgY2FuIHByb3ZpZGUgdmFyaW91cw0KPiBzZXJ2aWNlcyBvbiBjb250ZW50cyBkZWxp dmVyeSB3aGlsZSB3ZSB3aWxsIG5vdCBiZSBhYmxlIHRvIGRvIHNvIG9ubHkNCj4gd2l0aCBSVFNQ LCBJIHRoaW5rLiAgT24gdGhlIG90aGVyIGhhbmQsIFJUU1AgaGFzIGVub3VnaCBjYXBhYmlsaXR5 IGZvcg0KPiBkaXNjb3Zlcnkgb2YgbWVkaWEgc3RyZWFtcyBhbmQgZm9yIG5lZ290aWF0aW9uIG9m IFNEUHMuDQo+IFNvLCBJIHRoaW5rLCBmb3IgdGhlIHNpbXBsZSBkZWxpdmVyeSBvZiBjb250ZW50 cywgUlRTUCBpcyBhcHByb3ByaWF0ZSB0bw0KPiB1c2UsIGFuZCBmb3IgdmFyaW91cyBzZXNzaW9u IGNvbnRyb2wgc2VydmljZXMgcmVnYXJkaW5nIGNvbnRlbnRzDQo+IGRlbGl2ZXJ5LCBTSVAgd2l0 aCBSVFNQIGlzIGFwcHJvcHJpYXRlIHRvIHVzZS4NCj4gDQo+IEFueSBvcGluaW9ucz8NCj4gDQo+ IEkgd29uZGVyIHdoeSBubyBjb250ZW50cyBkZWxpdmVyeSBzZXJ2ZXIgc2VlbXMgdG8gcHJlcGFy ZSBTSVAgc3RhY2sgbm93LiANCj4gSXMgaXQgYmVjYXVzZSwgdXAgdG8gbm93LCB0aGVyZSBleGlz dHMgb25seSBhIHNpbXBsZSBjb250ZW50cyBkZWxpdmVyeQ0KPiBzZXJ2aWNlPw0KPiANCj4gYmVz dCByZWdhcmRzLA0KPiANCj4gLS0gDQo+IE5BS0FNVVJBLCBIaWRlZnVtaSANCj4gTlRUIFNlcnZp Y2VJbnRlZ3JhdGlvbiAvTmV0d29ya1NlcnZpY2VTeXN0ZW1zIExhYnMuDQo+IHRlbDogKzgxKDQy Mik1OSAzOTA0OyBmYXg6KzgxKDQyMik2MCA0MDEyDQo+IC0tLQ0KPiANCj4gDQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBTaXAgbWFpbGlu ZyBsaXN0ICBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXANCj4gVGhp cyBsaXN0IGlzIGZvciBORVcgZGV2ZWxvcG1lbnQgb2YgdGhlIGNvcmUgU0lQIFByb3RvY29sDQo+ IFVzZSBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3IgcXVlc3Rpb25zIG9uIGN1 cnJlbnQgc2lwDQo+IFVzZSBzaXBwaW5nQGlldGYub3JnIGZvciBuZXcgZGV2ZWxvcG1lbnRzIG9u IHRoZSBhcHBsaWNhdGlvbiBvZiBzaXANCj4gDQoNCg0KLS0tDQpPdXRnb2luZyBtYWlsIGlzIGNl cnRpZmllZCBWaXJ1cyBGcmVlLg0KQ2hlY2tlZCBieSBBVkcgYW50aS12aXJ1cyBzeXN0ZW0gKGh0 dHA6Ly93d3cuZ3Jpc29mdC5jb20pLg0KVmVyc2lvbjogNi4wLjQ5NSAvIFZpcnVzIERhdGFiYXNl OiAyOTQgLSBSZWxlYXNlIERhdGU6IDMwLzA2LzIwMDM= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 9 04:55:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24518 for ; Wed, 9 Jul 2003 04:55:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aAjZ-000168-VW for sip-archive@odin.ietf.org; Wed, 09 Jul 2003 04:55:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h698tTQD004219 for sip-archive@odin.ietf.org; Wed, 9 Jul 2003 04:55:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aAjB-000152-0h; Wed, 09 Jul 2003 04:55:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aAia-0000yo-Oa for sip@optimus.ietf.org; Wed, 09 Jul 2003 04:54:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24461; Wed, 9 Jul 2003 04:54:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aAiX-0005CL-00; Wed, 09 Jul 2003 04:54:25 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19aAiW-0005C3-00; Wed, 09 Jul 2003 04:54:24 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h698rpw26363; Wed, 9 Jul 2003 03:53:51 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jul 2003 10:53:49 +0200 Message-ID: <5160DD6EC1C0D41196D700508B5C167101F805EF@it2020exch001u.it.lucent.com> From: "Pianigiani, Jacopo (Jacopo)" To: "'Paolo Asprino'" , "NAKAMURA, Hidefumi" , sip@ietf.org, mmusic@ietf.org Subject: RE: [Sip] Appropriate usage of SIP and RTSP Date: Wed, 9 Jul 2003 10:53:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 Hello all, In my undertanding RTSP is suitable for broadcast, unicast or multicast = streams distribution. The RTSP protocol was ideated for typical content = delivery, and in effect for this application could be more than = suitable. But referring to an IMS domain, in my point of view adopting = RSTP as media streams control, would imply adopting at least a double = protocol stack in the terminal equipment. The IMS concept was mainly = driven by the concept - in my understanding - of simplifying the = terminal (making it simpler from a protocol stack implementation means = lowering costs and increasing penetration on the market) by adopting a = single protocol stack in the terminal, and having the RAN and the core = evolving toward a unified transport mechanism for which an almost = unified level of control on the network resources allocated to a = session (whatever session we refer to, voice , multimedia p-t-t call, = web browsing, multimedia session with voice call and dynamic web = pages). So in this sense, my understanding is that the RTSP could be suitable = for media content, but it would imply again new complexity on the IMS = UMTS/CDMA terminal itself, which is against the idea of IMS of = enhancing the services the user can access by having an homogeneous = protocol stack on the terminal itself for all types of services. After all, the RTSP , apart from content delivery (of streams), could = not definitely handle appropriately sessions like Voice calls + = Interactive Web Pages.=20 Regards Jacopo Pianigiani Lucent Technologies - Italy =E839 335 7350536 -----Original Message----- From: Paolo Asprino [mailto:asprino@coritel.it] Sent: Wednesday, July 09, 2003 9:40 AM To: NAKAMURA, Hidefumi; sip@ietf.org; mmusic@ietf.org Subject: Re: [Sip] Appropriate usage of SIP and RTSP Hi all I'm thinking a solution to join SIP and RTSP in the 3G IMS domain. In particular in the IMS, I think that to provide multilmedia service (i.e video on demand), one can estabilish a subscription to the = service by SIP and then activate the service with RTSP by DIGEST = autentication with the=20 parameters exchanged early during the subscription (username and = password)=20 What do you think about that? Best Regards=20 ----- Original Message -----=20 From: "NAKAMURA, Hidefumi" To: ; Cc: Sent: Monday, July 07, 2003 9:49 AM Subject: [Sip] Appropriate usage of SIP and RTSP > Hi, all. >=20 > I have a question about the relationship between SIP and RTSP.=20 >=20 > In RFC3261, there is a description that says=20 > "SIP is not a vertically integrated communications system. SIP is > rather a component that can be used with other IETF protocols to > build a complete multimedia architecture. Typically, these > architectures will include protocols such as the Real-time = Transport > Protocol (RTP) (RFC 1889 [28]) for transporting real-time data and > providing QoS feedback, the Real-Time streaming protocol (RTSP) = (RFC > 2326 [29]) for controlling delivery of streaming media, ..." > (RFC3261 Section 2) >=20 > However, my understanding is that both SIP and RTSP have the = capability > for "discovery of UAs or media streams." > If I use SIP to establish a stream session and use RTSP to control > the stream, there will be redundant sequences, i.e. INVITE-OK-ACK and > SETUP-OK. >=20 > Was there any discussion on how to use these two protocols = appropriately? >=20 > With SIP application server, network providers can provide various > services on contents delivery while we will not be able to do so only > with RTSP, I think. On the other hand, RTSP has enough capability = for > discovery of media streams and for negotiation of SDPs. > So, I think, for the simple delivery of contents, RTSP is appropriate = to > use, and for various session control services regarding contents > delivery, SIP with RTSP is appropriate to use. >=20 > Any opinions? >=20 > I wonder why no contents delivery server seems to prepare SIP stack = now.=20 > Is it because, up to now, there exists only a simple contents = delivery > service? >=20 > best regards, >=20 > --=20 > NAKAMURA, Hidefumi=20 > NTT ServiceIntegration /NetworkServiceSystems Labs. > tel: +81(422)59 3904; fax:+81(422)60 4012 > --- >=20 >=20 >=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 >=20 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.495 / Virus Database: 294 - Release Date: = 30/06/2003J*fj)bz = b=B2=D8m=B6>?=FF=0C0=D6'=AD~S=E0=FEf=A2-f=A7=FEX=AC=B6)=DF=A3=FB"=A58b=B2= X=AC=B6+=1F=A2=B3DY=D7=AFzZ)(tm)=E9=ED=A1=FBay=CA+y"=0F>=BA-=A1=CA%R=C7=AC= S~=A6=A6W=A6z{h=AE=C7,r?n(tm)=B8sy=DBY=A2=BA=AEz=CBb=A2{(=9D=CB=AB=AD=E9= =ED=B2*T=B1=EB"=A6~=A7''=AD~S=E0~S=E7{=07^=BD=E9h=A6g=A7=B6=CA'=B6=17s=A6= (tm)bq=ABb=A2z=1F _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 9 05:17:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25018 for ; Wed, 9 Jul 2003 05:17:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aB4h-0002Uc-Ef for sip-archive@odin.ietf.org; Wed, 09 Jul 2003 05:17:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h699HJXh009560 for sip-archive@odin.ietf.org; Wed, 9 Jul 2003 05:17:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aB4R-0002Rs-JY; Wed, 09 Jul 2003 05:17:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aB4K-0002R1-78 for sip@optimus.ietf.org; Wed, 09 Jul 2003 05:16: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 FAA24970; Wed, 9 Jul 2003 05:16:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aB4G-0005Kz-00; Wed, 09 Jul 2003 05:16:52 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19aB4G-0005Kv-00; Wed, 09 Jul 2003 05:16:52 -0400 Received: from dynamicsoft.com ([63.113.46.9]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h699GGiB006258; Wed, 9 Jul 2003 05:16:17 -0400 (EDT) Message-ID: <3F0BDD5A.9030406@dynamicsoft.com> Date: Wed, 09 Jul 2003 05:16:10 -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: Paolo Asprino CC: "NAKAMURA, Hidefumi" , sip@ietf.org, mmusic@ietf.org Subject: Re: [Sip] Appropriate usage of SIP and RTSP References: <20030707134023.181C.NAKAMURA.HIDEFUMI@lab.ntt.co.jp> <000801c345ed$49699dd0$47a4cdc1@cori8> In-Reply-To: <000801c345ed$49699dd0$47a4cdc1@cori8> 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 Paolo Asprino wrote: > Hi all > > I'm thinking a solution to join SIP and RTSP in the 3G IMS domain. > In particular in the IMS, I think that to provide multilmedia > service (i.e video on demand), one can estabilish a subscription to the service by SIP and then activate the service with RTSP by DIGEST autentication with the > parameters exchanged early during the subscription (username and password) > > What do you think about that? I'm not sure I follow; it seems like you want SIP to be an enrollment protocol. I believe the right path forward is for SIP to setup the session. If you want to execute controls, it would be possible to open a control session (using an offer/answer exchange), where the control protocol is RTSP. In that usage you would only use the PLAY, PAUSE, RECORD, GET-PARAMTER and SET-PARAMETER methods. I think the others would not be needed. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer 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 Wed Jul 9 05:28:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25255 for ; Wed, 9 Jul 2003 05:28:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aBFD-0002rn-1v for sip-archive@odin.ietf.org; Wed, 09 Jul 2003 05:28:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h699SBq5011014 for sip-archive@odin.ietf.org; Wed, 9 Jul 2003 05:28:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aBF3-0002r9-BA; Wed, 09 Jul 2003 05: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 19aBEr-0002qH-Ut for sip@optimus.ietf.org; Wed, 09 Jul 2003 05:27: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 FAA25239; Wed, 9 Jul 2003 05:27:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aBEo-0005PE-00; Wed, 09 Jul 2003 05:27:46 -0400 Received: from [193.205.242.5] (helo=nausicaa.coritel.it ident=root) by ietf-mx with esmtp (Exim 4.12) id 19aBEm-0005PB-00; Wed, 09 Jul 2003 05:27:45 -0400 Received: from cori8 (cori8.diiie.unisa.it [193.205.164.71]) by nausicaa.coritel.it (8.11.2/8.11.2) with ESMTP id h699RVI26460; Wed, 9 Jul 2003 11:27:31 +0200 Message-ID: <002f01c345fa$20636030$47a4cdc1@cori8> From: "Paolo Asprino" To: "Pianigiani, Jacopo \(Jacopo\)" , "NAKAMURA, Hidefumi" , , References: <5160DD6EC1C0D41196D700508B5C167101F805EF@it2020exch001u.it.lucent.com> Subject: Re: [Sip] Appropriate usage of SIP and RTSP Date: Wed, 9 Jul 2003 11:11:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 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: base64 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 SW4gYSBJTVMgc2NlbmFyaW8gDQpJIHRoaW5rIHRoYXQgdGhlIHRlbWluYXQgaGF2ZSB0byBzdXBw b3J0IGEgU0lQIGFuZCAgUlRTUCBkb3VibGUgc3RhY2sgDQpvdGhlcndpc2UgdGhlIHVzZXIgY2Fu J3QgYWNjZXNzICBvdGhlcnMgc3RlYW1pbmcgc2VydmljZXMgKGkuZSBpbiBJbnRlcm5ldCksDQp0 aGVuIGluc3RlYWQgaW5jYXBzdWxpbmcgUlRTUCBjb21tYW5kIGluIFNJUCANCm1heWJlIGlzIGJl dHRlciB0aGF0IHRoZSB0ZXJtaW5hbCBzdXBwb3J0cyBhIGRvdWJsZSBzdGFjayANCg0KDQoNCg0K LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJQaWFuaWdpYW5pLCBKYWNvcG8g KEphY29wbykiIDxqcGlhbmlnaWFuaUBsdWNlbnQuY29tPg0KVG86ICInUGFvbG8gQXNwcmlubyci IDxhc3ByaW5vQGNvcml0ZWwuaXQ+OyAiTkFLQU1VUkEsIEhpZGVmdW1pIiA8bmFrYW11cmEuaGlk ZWZ1bWlAbGFiLm50dC5jby5qcD47IDxzaXBAaWV0Zi5vcmc+OyA8bW11c2ljQGlldGYub3JnPg0K U2VudDogV2VkbmVzZGF5LCBKdWx5IDA5LCAyMDAzIDEwOjUzIEFNDQpTdWJqZWN0OiBSRTogW1Np cF0gQXBwcm9wcmlhdGUgdXNhZ2Ugb2YgU0lQIGFuZCBSVFNQDQoNCg0KPiBIZWxsbyBhbGwsDQo+ IEluIG15IHVuZGVydGFuZGluZyBSVFNQIGlzIHN1aXRhYmxlIGZvciBicm9hZGNhc3QsIHVuaWNh c3Qgb3IgbXVsdGljYXN0IHN0cmVhbXMgZGlzdHJpYnV0aW9uLiBUaGUgUlRTUCBwcm90b2NvbCB3 YXMgaWRlYXRlZCBmb3IgdHlwaWNhbCBjb250ZW50IGRlbGl2ZXJ5LCBhbmQgaW4gZWZmZWN0IGZv ciB0aGlzIGFwcGxpY2F0aW9uIGNvdWxkIGJlIG1vcmUgdGhhbiBzdWl0YWJsZS4gQnV0IHJlZmVy cmluZyB0byBhbiBJTVMgZG9tYWluLCBpbiBteSBwb2ludCBvZiB2aWV3IGFkb3B0aW5nIFJTVFAg YXMgbWVkaWEgc3RyZWFtcyBjb250cm9sLCB3b3VsZCBpbXBseSBhZG9wdGluZyBhdCBsZWFzdCBh IGRvdWJsZSBwcm90b2NvbCBzdGFjayBpbiB0aGUgdGVybWluYWwgZXF1aXBtZW50LiBUaGUgSU1T IGNvbmNlcHQgd2FzIG1haW5seSBkcml2ZW4gYnkgdGhlIGNvbmNlcHQgLSBpbiBteSB1bmRlcnN0 YW5kaW5nIC0gb2Ygc2ltcGxpZnlpbmcgdGhlIHRlcm1pbmFsIChtYWtpbmcgaXQgc2ltcGxlciBm cm9tIGEgcHJvdG9jb2wgc3RhY2sgaW1wbGVtZW50YXRpb24gbWVhbnMgbG93ZXJpbmcgY29zdHMg YW5kIGluY3JlYXNpbmcgcGVuZXRyYXRpb24gb24gdGhlIG1hcmtldCkgYnkgYWRvcHRpbmcgYSBz aW5nbGUgcHJvdG9jb2wgc3RhY2sgaW4gdGhlIHRlcm1pbmFsLCBhbmQgaGF2aW5nIHRoZSBSQU4g YW5kIHRoZSBjb3JlIGV2b2x2aW5nIHRvd2FyZCBhIHVuaWZpZWQgdHJhbnNwb3J0IG1lY2hhbmlz bSBmb3Igd2hpY2ggYW4gYWxtb3N0IHVuaWZpZWQgbGV2ZWwgb2YgY29udHJvbCBvbiB0aGUgbmV0 d29yayByZXNvdXJjZXMgYWxsb2NhdGVkIHRvIGEgc2Vzc2lvbiAod2hhdGV2ZXIgc2Vzc2lvbiB3 ZSByZWZlciB0bywgdm9pY2UgLCBtdWx0aW1lZGlhIHAtdC10IGNhbGwsIHdlYiBicm93c2luZywg bXVsdGltZWRpYSBzZXNzaW9uIHdpdGggdm9pY2UgY2FsbCBhbmQgZHluYW1pYyB3ZWIgcGFnZXMp Lg0KPiBTbyBpbiB0aGlzIHNlbnNlLCBteSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhlIFJUU1Ag Y291bGQgYmUgc3VpdGFibGUgZm9yIG1lZGlhIGNvbnRlbnQsIGJ1dCBpdCB3b3VsZCBpbXBseSBh Z2FpbiBuZXcgY29tcGxleGl0eSBvbiB0aGUgSU1TIFVNVFMvQ0RNQSB0ZXJtaW5hbCBpdHNlbGYs IHdoaWNoIGlzIGFnYWluc3QgdGhlIGlkZWEgb2YgSU1TIG9mIGVuaGFuY2luZyB0aGUgc2Vydmlj ZXMgdGhlIHVzZXIgY2FuIGFjY2VzcyBieSBoYXZpbmcgYW4gaG9tb2dlbmVvdXMgcHJvdG9jb2wg c3RhY2sgb24gdGhlIHRlcm1pbmFsIGl0c2VsZiBmb3IgYWxsIHR5cGVzIG9mIHNlcnZpY2VzLg0K PiANCj4gQWZ0ZXIgYWxsLCB0aGUgUlRTUCAsIGFwYXJ0IGZyb20gY29udGVudCBkZWxpdmVyeSAo b2Ygc3RyZWFtcyksIGNvdWxkIG5vdCBkZWZpbml0ZWx5IGhhbmRsZSBhcHByb3ByaWF0ZWx5IHNl c3Npb25zIGxpa2UgVm9pY2UgY2FsbHMgKyBJbnRlcmFjdGl2ZSBXZWIgUGFnZXMuIA0KPiBSZWdh cmRzDQo+IA0KPiBKYWNvcG8gUGlhbmlnaWFuaQ0KPiBMdWNlbnQgVGVjaG5vbG9naWVzIC0gSXRh bHkNCj4g6DM5IDMzNSA3MzUwNTM2DQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBQYW9sbyBBc3ByaW5vIFttYWlsdG86YXNwcmlub0Bjb3JpdGVsLml0XQ0KPiBTZW50 OiBXZWRuZXNkYXksIEp1bHkgMDksIDIwMDMgOTo0MCBBTQ0KPiBUbzogTkFLQU1VUkEsIEhpZGVm dW1pOyBzaXBAaWV0Zi5vcmc7IG1tdXNpY0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW1NpcF0g QXBwcm9wcmlhdGUgdXNhZ2Ugb2YgU0lQIGFuZCBSVFNQDQo+IA0KPiANCj4gSGkgYWxsDQo+IA0K PiBJJ20gdGhpbmtpbmcgYSBzb2x1dGlvbiB0byBqb2luIFNJUCBhbmQgUlRTUCBpbiB0aGUgM0cg SU1TIGRvbWFpbi4NCj4gSW4gcGFydGljdWxhciBpbiB0aGUgSU1TLCBJIHRoaW5rIHRoYXQgdG8g cHJvdmlkZSBtdWx0aWxtZWRpYQ0KPiBzZXJ2aWNlIChpLmUgdmlkZW8gb24gZGVtYW5kKSwgb25l IGNhbiBlc3RhYmlsaXNoIGEgc3Vic2NyaXB0aW9uIHRvIHRoZSBzZXJ2aWNlIGJ5IFNJUCBhbmQg dGhlbiBhY3RpdmF0ZSB0aGUgc2VydmljZSB3aXRoIFJUU1AgYnkgRElHRVNUIGF1dGVudGljYXRp b24gd2l0aCB0aGUgDQo+IHBhcmFtZXRlcnMgZXhjaGFuZ2VkIGVhcmx5IGR1cmluZyB0aGUgc3Vi c2NyaXB0aW9uICh1c2VybmFtZSBhbmQgcGFzc3dvcmQpIA0KPiANCj4gV2hhdCBkbyB5b3UgdGhp bmsgYWJvdXQgdGhhdD8NCj4gDQo+IEJlc3QgUmVnYXJkcyANCj4gDQo+IC0tLS0tIE9yaWdpbmFs IE1lc3NhZ2UgLS0tLS0gDQo+IEZyb206ICJOQUtBTVVSQSwgSGlkZWZ1bWkiIDxuYWthbXVyYS5o aWRlZnVtaUBsYWIubnR0LmNvLmpwPg0KPiBUbzogPHNpcEBpZXRmLm9yZz47IDxtbXVzaWNAaWV0 Zi5vcmc+DQo+IENjOiA8aGlkZWZ1bWkubmFrYW11cmFAc3RhZmYuZWFzdC5udHQuY28uanA+DQo+ IFNlbnQ6IE1vbmRheSwgSnVseSAwNywgMjAwMyA5OjQ5IEFNDQo+IFN1YmplY3Q6IFtTaXBdIEFw cHJvcHJpYXRlIHVzYWdlIG9mIFNJUCBhbmQgUlRTUA0KPiANCj4gDQo+ID4gSGksIGFsbC4NCj4g PiANCj4gPiBJIGhhdmUgYSBxdWVzdGlvbiBhYm91dCB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4g U0lQIGFuZCBSVFNQLiANCj4gPiANCj4gPiBJbiBSRkMzMjYxLCB0aGVyZSBpcyBhIGRlc2NyaXB0 aW9uIHRoYXQgc2F5cyANCj4gPiAgICAiU0lQIGlzIG5vdCBhIHZlcnRpY2FsbHkgaW50ZWdyYXRl ZCBjb21tdW5pY2F0aW9ucyBzeXN0ZW0uICBTSVAgaXMNCj4gPiAgICByYXRoZXIgYSBjb21wb25l bnQgdGhhdCBjYW4gYmUgdXNlZCB3aXRoIG90aGVyIElFVEYgcHJvdG9jb2xzIHRvDQo+ID4gICAg YnVpbGQgYSBjb21wbGV0ZSBtdWx0aW1lZGlhIGFyY2hpdGVjdHVyZS4gIFR5cGljYWxseSwgdGhl c2UNCj4gPiAgICBhcmNoaXRlY3R1cmVzIHdpbGwgaW5jbHVkZSBwcm90b2NvbHMgc3VjaCBhcyB0 aGUgUmVhbC10aW1lIFRyYW5zcG9ydA0KPiA+ICAgIFByb3RvY29sIChSVFApIChSRkMgMTg4OSBb MjhdKSBmb3IgdHJhbnNwb3J0aW5nIHJlYWwtdGltZSBkYXRhIGFuZA0KPiA+ICAgIHByb3ZpZGlu ZyBRb1MgZmVlZGJhY2ssIHRoZSBSZWFsLVRpbWUgc3RyZWFtaW5nIHByb3RvY29sIChSVFNQKSAo UkZDDQo+ID4gICAgMjMyNiBbMjldKSBmb3IgY29udHJvbGxpbmcgZGVsaXZlcnkgb2Ygc3RyZWFt aW5nIG1lZGlhLCAuLi4iDQo+ID4gICAgKFJGQzMyNjEgU2VjdGlvbiAyKQ0KPiA+IA0KPiA+IEhv d2V2ZXIsIG15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBib3RoIFNJUCBhbmQgUlRTUCBoYXZlIHRo ZSBjYXBhYmlsaXR5DQo+ID4gZm9yICJkaXNjb3Zlcnkgb2YgVUFzIG9yIG1lZGlhIHN0cmVhbXMu Ig0KPiA+IElmIEkgdXNlIFNJUCB0byBlc3RhYmxpc2ggYSBzdHJlYW0gc2Vzc2lvbiBhbmQgdXNl IFJUU1AgdG8gY29udHJvbA0KPiA+IHRoZSBzdHJlYW0sIHRoZXJlIHdpbGwgYmUgcmVkdW5kYW50 IHNlcXVlbmNlcywgaS5lLiBJTlZJVEUtT0stQUNLIGFuZA0KPiA+IFNFVFVQLU9LLg0KPiA+IA0K PiA+IFdhcyB0aGVyZSBhbnkgZGlzY3Vzc2lvbiBvbiBob3cgdG8gdXNlIHRoZXNlIHR3byBwcm90 b2NvbHMgYXBwcm9wcmlhdGVseT8NCj4gPiANCj4gPiBXaXRoIFNJUCBhcHBsaWNhdGlvbiBzZXJ2 ZXIsIG5ldHdvcmsgcHJvdmlkZXJzIGNhbiBwcm92aWRlIHZhcmlvdXMNCj4gPiBzZXJ2aWNlcyBv biBjb250ZW50cyBkZWxpdmVyeSB3aGlsZSB3ZSB3aWxsIG5vdCBiZSBhYmxlIHRvIGRvIHNvIG9u bHkNCj4gPiB3aXRoIFJUU1AsIEkgdGhpbmsuICBPbiB0aGUgb3RoZXIgaGFuZCwgUlRTUCBoYXMg ZW5vdWdoIGNhcGFiaWxpdHkgZm9yDQo+ID4gZGlzY292ZXJ5IG9mIG1lZGlhIHN0cmVhbXMgYW5k IGZvciBuZWdvdGlhdGlvbiBvZiBTRFBzLg0KPiA+IFNvLCBJIHRoaW5rLCBmb3IgdGhlIHNpbXBs ZSBkZWxpdmVyeSBvZiBjb250ZW50cywgUlRTUCBpcyBhcHByb3ByaWF0ZSB0bw0KPiA+IHVzZSwg YW5kIGZvciB2YXJpb3VzIHNlc3Npb24gY29udHJvbCBzZXJ2aWNlcyByZWdhcmRpbmcgY29udGVu dHMNCj4gPiBkZWxpdmVyeSwgU0lQIHdpdGggUlRTUCBpcyBhcHByb3ByaWF0ZSB0byB1c2UuDQo+ ID4gDQo+ID4gQW55IG9waW5pb25zPw0KPiA+IA0KPiA+IEkgd29uZGVyIHdoeSBubyBjb250ZW50 cyBkZWxpdmVyeSBzZXJ2ZXIgc2VlbXMgdG8gcHJlcGFyZSBTSVAgc3RhY2sgbm93LiANCj4gPiBJ cyBpdCBiZWNhdXNlLCB1cCB0byBub3csIHRoZXJlIGV4aXN0cyBvbmx5IGEgc2ltcGxlIGNvbnRl bnRzIGRlbGl2ZXJ5DQo+ID4gc2VydmljZT8NCj4gPiANCj4gPiBiZXN0IHJlZ2FyZHMsDQo+ID4g DQo+ID4gLS0gDQo+ID4gTkFLQU1VUkEsIEhpZGVmdW1pIA0KPiA+IE5UVCBTZXJ2aWNlSW50ZWdy YXRpb24gL05ldHdvcmtTZXJ2aWNlU3lzdGVtcyBMYWJzLg0KPiA+IHRlbDogKzgxKDQyMik1OSAz OTA0OyBmYXg6KzgxKDQyMik2MCA0MDEyDQo+ID4gLS0tDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBTaXAg bWFpbGluZyBsaXN0ICBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXAN Cj4gPiBUaGlzIGxpc3QgaXMgZm9yIE5FVyBkZXZlbG9wbWVudCBvZiB0aGUgY29yZSBTSVAgUHJv dG9jb2wNCj4gPiBVc2Ugc2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUgZm9yIHF1ZXN0 aW9ucyBvbiBjdXJyZW50IHNpcA0KPiA+IFVzZSBzaXBwaW5nQGlldGYub3JnIGZvciBuZXcgZGV2 ZWxvcG1lbnRzIG9uIHRoZSBhcHBsaWNhdGlvbiBvZiBzaXANCj4gPiANCj4gDQo+IA0KPiAtLS0N Cj4gT3V0Z29pbmcgbWFpbCBpcyBjZXJ0aWZpZWQgVmlydXMgRnJlZS4NCj4gQ2hlY2tlZCBieSBB VkcgYW50aS12aXJ1cyBzeXN0ZW0gKGh0dHA6Ly93d3cuZ3Jpc29mdC5jb20pLg0KPiBWZXJzaW9u OiA2LjAuNDk1IC8gVmlydXMgRGF0YWJhc2U6IDI5NCAtIFJlbGVhc2UgRGF0ZTogMzAvMDYvMjAw M0oqZmopYnogYrLYbbY+P/8gMNYnrX5T4P5moi1mp/5YrLYp36P7IqU4YrJYrLYrH6KzRFnXr3pa KSh0bSnp7aH7YXnKK3kiDz66LaHKJVLHrFN+pqZXpnp7aK7HLHI/bih0bSm4c3nbWaK6rnrLYqJ7 KJ3Lq63p7bIqVLHrIqZ+pycnrX5T4H5T53sHXr3paKZnp7bKJ7YXc6YodG0pYnGrYqJ6Hw0KPiAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gU2lw IG1haWxpbmcgbGlzdCAgaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lw DQo+IFRoaXMgbGlzdCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRoZSBjb3JlIFNJUCBQcm90 b2NvbA0KPiBVc2Ugc2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUgZm9yIHF1ZXN0aW9u cyBvbiBjdXJyZW50IHNpcA0KPiBVc2Ugc2lwcGluZ0BpZXRmLm9yZyBmb3IgbmV3IGRldmVsb3Bt ZW50cyBvbiB0aGUgYXBwbGljYXRpb24gb2Ygc2lwDQo+IA0KDQoNCi0tLQ0KT3V0Z29pbmcgbWFp bCBpcyBjZXJ0aWZpZWQgVmlydXMgRnJlZS4NCkNoZWNrZWQgYnkgQVZHIGFudGktdmlydXMgc3lz dGVtIChodHRwOi8vd3d3LmdyaXNvZnQuY29tKS4NClZlcnNpb246IDYuMC40OTUgLyBWaXJ1cyBE YXRhYmFzZTogMjk0IC0gUmVsZWFzZSBEYXRlOiAzMC8wNi8yMDAz _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 9 05:55:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25805 for ; Wed, 9 Jul 2003 05:55:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aBfM-00045X-0R for sip-archive@odin.ietf.org; Wed, 09 Jul 2003 05:55:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h699tBar015698 for sip-archive@odin.ietf.org; Wed, 9 Jul 2003 05:55:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aBfC-00044d-K6; Wed, 09 Jul 2003 05:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aBeX-00042n-MV for sip@optimus.ietf.org; Wed, 09 Jul 2003 05:54: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 FAA25771 for ; Wed, 9 Jul 2003 05:54:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aBeU-0005Yt-00 for sip@ietf.org; Wed, 09 Jul 2003 05:54:18 -0400 Received: from e-eihq01.eis.ernet.in ([202.41.97.131]) by ietf-mx with esmtp (Exim 4.12) id 19aBeR-0005Ye-00 for sip@ietf.org; Wed, 09 Jul 2003 05:54:16 -0400 Received: from uucp-relay-delhi.ernet.in by e-eihq01.eis.ernet.in (8.10.2/1.1.2.10/13Jul01-0336PM) id h69AJIO0000010996; Wed, 9 Jul 2003 15:19:18 +0500 (GMT+0500) Received: by uucp-relay-delhi.ernet.in (8.9.3+Sun/SMI-4.1-MHS-7.0) id PAA28005; Wed, 9 Jul 2003 15:30:03 -0500 (GMT) >Received: from virgo.cdotd.ernet.in by cdotd.cdotd.ernet.in (SMI-8.6/SMI-SVR4) id PAA21506; Wed, 9 Jul 2003 15:00:24 -0500 Date: Wed, 9 Jul 2003 15:00:56 +0530 (IST) From: Rinchen Tundup To: sip@ietf.org Message-ID: MIME-Version: 1.0 Received: from cdotd by vikram.eis.ernet.in; Wed, 9 Jul 2003 15:30 GMT Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] Response calculation for Authorization header (fwd) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , hi all , I am using the HTTP Authentication RFC code to calculate "response" for Authorization header. I am using estara and SIEMENS proxy to cross check the generated result. estara and Siemens proxy works fine ( authentication works fine ) Message dumps between them :- SIP/2.0 407 Proxy Authentication Required Call-ID: 6822d081-8d7d-11d6-996d-0000e23bec27@192.168.6.114 CSeq: 7155859 INVITE From: ;tag=5f1878f0 To: sip:demo@192.168.6.7 Via: SIP/2.0/UDP 192.168.6.114:5060 Content-Length: 0 Proxy-Authenticate:Digest realm="cdot",nonce="1b8afbde897ce542346164da91a35b",opaque="IWUSipProxy",stale=FALSE,algorithm=MD5,qop="auth" INVITE sip:demo@192.168.6.7 SIP/2.0 Via: SIP/2.0/UDP 192.168.6.114:5060 From: ;tag=5f1878f0 To: sip:demo@192.168.6.7 Contact: sip:demo@192.168.6.114 Call-ID: 6822d081-8d7d-11d6-996d-0000e23bec27@192.168.6.114 CSeq: 7155860 INVITE Content-Length: 173 Content-Type: application/sdp User-Agent: eStara SoftPHONE Supported: com.estara.mux Proxy-Authorization: Digest username="123",realm="cdot",nonce="1b8afbde897ce542346164da91a35b",response="a016c94a34fd3516fe01177eb4dc4a9e",uri="sip:demo@192.168.6.7",opaque="IWUSipProxy" above works fine But using the HTTP auth code :- /* Get frm 401 */ char * pszNonce = "1b8afbde897ce542346164da91a35b"; /* client to choose cnonce */ char * pszCNonce = "a12"; /* what should be this ?? It can't be NULL i suppose */ /* ph no icw */ char * pszUser = "123"; char * pszRealm = "cdot"; char * pszPass = "123"; char * pszAlg = "MD5"; char szNonceCount[9] = "00000001"; /* ?????? what about this */ char * pszMethod = "INVITE"; char * pszQop = "auth"; /* request uri */ char * pszURI = "sip:demo@192.168.6.7"; HASHHEX HA1; HASHHEX HA2 = ""; HASHHEX Response; DigestCalcHA1(pszAlg, pszUser, pszRealm, pszPass, pszNonce, pszCNonce, HA1); DigestCalcResponse(HA1, pszNonce, szNonceCount, pszCNonce, pszQop, pszMethod, pszURI, HA2, Response); printf("Response = %s\n", Response); I get response as .. Response = 290050605274e103212bd3eac00b10df which is not correct ? My question is 1. what should be value of cnonce and nc(nonce count) , since this values are must for response calulation? 2.how estara is calculating response without them (as they are not forming any cnonce or nc parameters)? 3. how should a client choose cnonce and nc values ? 4. Am i going wrong some where ? 5. For a given username , passwd , nonce etc how can i check whether my generated response is corrrect or not ? any freely available tool to check that or any standard docs available ? pls help thanks in advance .. Greetings Rinchen Tundup Delhi _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 9 11:14:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05146 for ; Wed, 9 Jul 2003 11:14:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aGeC-0001we-DV for sip-archive@odin.ietf.org; Wed, 09 Jul 2003 11:14:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69FEKxB007470 for sip-archive@odin.ietf.org; Wed, 9 Jul 2003 11:14:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aGd5-000149-Qf; Wed, 09 Jul 2003 11:13:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aERz-00064X-0x for sip@optimus.ietf.org; Wed, 09 Jul 2003 08:53: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 IAA29146; Wed, 9 Jul 2003 08:53:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aERx-0006Oa-00; Wed, 09 Jul 2003 08:53:33 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19aERw-0006OX-00; Wed, 09 Jul 2003 08:53:32 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h69CrTGJ001262; Wed, 9 Jul 2003 14:53:29 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id N8XJCB70; Wed, 9 Jul 2003 14:53:29 +0200 Message-ID: <3F0C1049.4010103@ericsson.com> Date: Wed, 09 Jul 2003 14:53:29 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pianigiani, Jacopo (Jacopo)" CC: sip@ietf.org, mmusic@ietf.org Subject: Re: [Sip] Appropriate usage of SIP and RTSP References: <5160DD6EC1C0D41196D700508B5C167101F805EF@it2020exch001u.it.lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable 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, When it comes to IMS and 3G terminals, most will already before having=20 an IMS functionality have support for PSS. PSS is Packet-based Streaming = Service which is an umbrella kind of standard for streaming service=20 defined in 3GPP targeted at low bit-rates and mobile networks.=20 Specification available from Rel 4 in TS 26.233 and TS 26.234. Already=20 today there exist GSM/GPRS phones that has a PSS client. So I think that dual stack implementations will not be that impossible=20 to foresee. However I think the main issue in this discussion is to look at what=20 applications that has need for SIP-RTSP interactions. Based on this we=20 can see if there is solutions easily available or not. I can agree with Rosenberg that if we where going to design a RTSP=20 functionality protocol today, looking at SIP for session establishment=20 would be interesting. However that opportunity has passed as RTSP has=20 started to be deployed in increasing numbers. I think even the latest=20 Windows media player does support RTSP. Best Regards Magnus Westerlund Pianigiani, Jacopo (Jacopo) wrote: > Hello all, > In my undertanding RTSP is suitable for broadcast, unicast or multicast= streams distribution. The RTSP protocol was ideated for typical content = delivery, and in effect for this application could be more than suitable.= But referring to an IMS domain, in my point of view adopting RSTP as med= ia streams control, would imply adopting at least a double protocol stack= in the terminal equipment. The IMS concept was mainly driven by the conc= ept - in my understanding - of simplifying the terminal (making it simple= r from a protocol stack implementation means lowering costs and increasin= g penetration on the market) by adopting a single protocol stack in the t= erminal, and having the RAN and the core evolving toward a unified transp= ort mechanism for which an almost unified level of control on the network= resources allocated to a session (whatever session we refer to, voice , = multimedia p-t-t call, web browsing, multimedia session with voice call a= nd dynamic web pages). > So in this sense, my understanding is that the RTSP could be suitable f= or media content, but it would imply again new complexity on the IMS UMTS= /CDMA terminal itself, which is against the idea of IMS of enhancing the = services the user can access by having an homogeneous protocol stack on t= he terminal itself for all types of services. >=20 > After all, the RTSP , apart from content delivery (of streams), could n= ot definitely handle appropriately sessions like Voice calls + Interactiv= e Web Pages.=20 > Regards >=20 > Jacopo Pianigiani > Lucent Technologies - Italy > =E839 335 7350536 >=20 > -----Original Message----- > From: Paolo Asprino [mailto:asprino@coritel.it] > Sent: Wednesday, July 09, 2003 9:40 AM > To: NAKAMURA, Hidefumi; sip@ietf.org; mmusic@ietf.org > Subject: Re: [Sip] Appropriate usage of SIP and RTSP >=20 >=20 > Hi all >=20 > I'm thinking a solution to join SIP and RTSP in the 3G IMS domain. > In particular in the IMS, I think that to provide multilmedia > service (i.e video on demand), one can estabilish a subscription to the= service by SIP and then activate the service with RTSP by DIGEST autenti= cation with the=20 > parameters exchanged early during the subscription (username and passwo= rd)=20 >=20 > What do you think about that? >=20 > Best Regards=20 >=20 > ----- Original Message -----=20 > From: "NAKAMURA, Hidefumi" > To: ; > Cc: > Sent: Monday, July 07, 2003 9:49 AM > Subject: [Sip] Appropriate usage of SIP and RTSP >=20 >=20 >=20 >>Hi, all. >> >>I have a question about the relationship between SIP and RTSP.=20 >> >>In RFC3261, there is a description that says=20 >> "SIP is not a vertically integrated communications system. SIP is >> rather a component that can be used with other IETF protocols to >> build a complete multimedia architecture. Typically, these >> architectures will include protocols such as the Real-time Transport= >> Protocol (RTP) (RFC 1889 [28]) for transporting real-time data and >> providing QoS feedback, the Real-Time streaming protocol (RTSP) (RFC= >> 2326 [29]) for controlling delivery of streaming media, ..." >> (RFC3261 Section 2) >> >>However, my understanding is that both SIP and RTSP have the capability= >>for "discovery of UAs or media streams." >>If I use SIP to establish a stream session and use RTSP to control >>the stream, there will be redundant sequences, i.e. INVITE-OK-ACK and >>SETUP-OK. >> >>Was there any discussion on how to use these two protocols appropriatel= y? >> >>With SIP application server, network providers can provide various >>services on contents delivery while we will not be able to do so only >>with RTSP, I think. On the other hand, RTSP has enough capability for >>discovery of media streams and for negotiation of SDPs. >>So, I think, for the simple delivery of contents, RTSP is appropriate t= o >>use, and for various session control services regarding contents >>delivery, SIP with RTSP is appropriate to use. >> >>Any opinions? >> >>I wonder why no contents delivery server seems to prepare SIP stack now= =2E=20 >>Is it because, up to now, there exists only a simple contents delivery >>service? >> >>best regards, >> >>--=20 >>NAKAMURA, Hidefumi=20 >>NTT ServiceIntegration /NetworkServiceSystems Labs. >>tel: +81(422)59 3904; fax:+81(422)60 4012 >>--- >> >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> >=20 >=20 >=20 > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.495 / Virus Database: 294 - Release Date: 30/06/2003J*fj)b= z b=B2=D8m=B6>?=FF=0C0=D6'=AD~S=E0=FEf=A2-f=A7=FEX=AC=B6)=DF=A3=FB"=A58b=B2= X=AC=B6+=1F=A2=B3DY=D7=AFzZ)(tm)=E9=ED=A1=FBay=CA+y"=0F>=BA-=A1=CA%R=C7=AC= S~=A6=A6W=A6z{h=AE=C7,r?n(tm)=B8sy=DBY=A2=BA=AEz=CBb=A2{(=9D=CB=AB=AD=E9=ED= =B2*T=B1=EB"=A6~=A7''=AD~S=E0~S=E7{=07^=BD=E9h=A6g=A7=B6=CA'=B6=17s=A6(tm= )bq=ABb=A2z=1F >=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 >=20 --=20 Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.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 Wed Jul 9 12:05:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07706 for ; Wed, 9 Jul 2003 12:05:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aHRD-0008Ob-6z for sip-archive@odin.ietf.org; Wed, 09 Jul 2003 12:05:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69G4xR5032267 for sip-archive@odin.ietf.org; Wed, 9 Jul 2003 12:04:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aHQI-00081X-1C; Wed, 09 Jul 2003 12:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aHPV-0007yw-N7 for sip@optimus.ietf.org; Wed, 09 Jul 2003 12:03: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 MAA07540 for ; Wed, 9 Jul 2003 12:03:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aHPU-00005m-00 for sip@ietf.org; Wed, 09 Jul 2003 12:03:12 -0400 Received: from mail.aastra.com ([216.94.98.95]) by ietf-mx with esmtp (Exim 4.12) id 19aHPT-00005d-00 for sip@ietf.org; Wed, 09 Jul 2003 12:03:11 -0400 Received: by mail.aastra.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jul 2003 12:00:08 -0400 Message-ID: From: Marc Archer To: sip@ietf.org Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-mib-06.txt Date: Wed, 9 Jul 2003 11:47:48 -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: , Hi, One more query! While I was compiling the .MIB file, I got the following Warnings in all the places where I have Unsigned32. --- Warning: unhandled MIB syntax SYNuns32. I have it in the IMPORTS section of the .MIB file as below: IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, Gauge32, TimeTicks, Unsigned32, mib-2 FROM SNMPv2-SMI I have also included in the .INC file #condInclude "rfc1902.inc" -- SNMPv2-SMI It continue further & final stops due to error as it cannot reference any of those variables. I am using SMICng version 2.1.03(BOOK)(MS-DOS32), February 12, 1997 & epilogue 9.1 SNMP stack. Regards, Marc Archer -----Original Message----- From: Kevin Lingle [mailto:klingle@cisco.com] Sent: Monday, July 07, 2003 5:10 PM To: Marc Archer Cc: sip@ietf.org Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-mib-06.txt marc, we (cisco) used to have essentially the same problem due to older verison of smicng not recognizing BITS construct. i believe newer versions of smicng (i think we have v2.2.11 now) have fixed this afaik. i know that we used to have to "work around" this by commenting out BITS syntax and replacing it with OCTET STRING. i suggest you contact http://www.snmpinfo.com for a definitive answer on whether your version of smicng is deficient wrt BITS or whether there is a switch you can turn on to eliminate the compile problem. btw, i ran the mib modules though smicng before publishing and did not have any errors reported.... except for the mib numbers: xx, yy which are eliminated by putting in some arbitrary (high) mib-2 oid assigned numbers (per dan's earlier suggestion). kevin Marc Archer wrote: > Hi, > > One more query: > > We are trying to integrate the Draft version for SIP MIBs ( > http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-06.txt). In this, > there is a BITS definition. BITS is not declared in the IMPORTS section (RFC > 2578 Section 3.2) of the mib file. I have included RFC 1902 in the .INC file > as below: > > #condInclude "rfc1902.inc" -- SNMPv2-SMI > > When I compile, I am getting the error > > ": f(sip_tc.mib), (3,1) SMI item "BITS" used in SIP-TC, but not defined or > imported". > > I am using SMICng version 2.1.03(BOOK)(MS-DOS32), February 12, 1997. > > Could someone tell me a fix for this problem? Is there any switch option > that can take care of this? > > Regards, > > Marc Archer > > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Monday, July 07, 2003 9:58 AM > To: Marc Archer; sip@ietf.org > Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-mib-06.txt > > > Marc, > > 1) The OID assignment for the MIB modules is being done by RFC Editor in the > final phases of releasing the RFC. Replace meantime xx with a number of your > choice, trying to avoid the already defined numbers, in order to pass > compilation. > 2) RFC 2578 Section 3.2 specifies which symbols must be imported and also > lists certain pre-defined symbols that must not be imported. The BITS > construct must not be imported. > > For more information about standard MIBs review procedures (including > compilation tools and options) see > http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-01. > txt. > > Regards, > > Dan > > >>-----Original Message----- >>From: Marc Archer [mailto:marcher@aastra.com] >>Sent: 07 July, 2003 4:27 PM >>To: sip@ietf.org >>Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-mib-06.txt >> >> >>Some comments on the draft >> >>TITLE: Has anyone come across a compilation error for not >>having a proper >>IANA assigned number? >> >>I am getting error during compilation (Sub-Id for item "sipTC" must be >>"number" or "name (number)" format) as it is Draft version & >>we do not have >>mib-2 number. We got to have a number for SIP-COMMON-MIB, SIP-TC & >>SIP-UA-MIB. >> >> ::= { mib-2 xx } >> -- RFC Ed: replace xx with actual IANA assigned number >> >>Any thoughts? >> >>TITLE: Error due to BITS usage >> >>I am experiencing a compilation error due to missing >>declaration of BITS in >>SIP-COMMON-MIB & SIP-TC. >> >>There is a BITS usage in the MIB files. >> >> SYNTAX BITS { >> other(0), -- none of the >>following >> udp(1), >> tcp(2), >> sctp(3), >> tls(4) >> } >> >>In the IMPORTS Section, it was not defined; I was getting the >>following >>Error message. >> >>SMI item "BITS" used in SIP-TC, but not defined or imported. >> >>Since "BITS" is defined in RFC1902.MIB (SNMPv2-SMI), which is already >>included in the *.INC file, I added "BITS" in the IMPORTS >>Section as below: >> >> IMPORTS >> MODULE-IDENTITY, >> mib-2, BITS >> FROM SNMPv2-SMI >> >>The compilation goes much further but it then comes up with >>the following >>error: >> >>expected a string, got BITS >> >> >>Any help will be very much appreciated. >> >>Regards, >> >>Marc Archer >> >>-----Original Message----- >>From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >>Sent: Wednesday, July 02, 2003 6:57 AM >>Cc: sip@ietf.org >>Subject: [Sip] I-D ACTION:draft-ietf-sip-mib-06.txt >> >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >>This draft is a work item of the Session Initiation Protocol >>Working Group >>of the IETF. >> >> Title : Management Information Base for >>Session Initiation >> >> Protocol >> Author(s) : K. Lingle, J. Maeng, J. Mule, D. Walker >> Filename : draft-ietf-sip-mib-06.txt >> Pages : 104 >> Date : 2003-7-1 >> >>This memo defines a portion of the Management Information Base (MIB) >>for use with network management protocols in the Internet community. >>In particular, it describes a set of managed objects that are used >>to manage Session Initiation Protocol (SIP) entities, which include >>User Agents, Proxy servers, Redirect servers and Registrars. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-06.txt >> >>To remove yourself from the IETF Announcement list, send a message to >>ietf-announce-request with the word unsubscribe in the body >>of the message. >> >>Internet-Drafts are also available by anonymous FTP. Login >>with the username >>"anonymous" and a password of your e-mail address. After logging in, >>type "cd internet-drafts" and then >> "get draft-ietf-sip-mib-06.txt". >> >>A list of Internet-Drafts directories can be found in >>http://www.ietf.org/shadow.html >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >>Internet-Drafts can also be obtained by e-mail. >> >>Send a message to: >> mailserv@ietf.org. >>In the body type: >> "FILE /internet-drafts/draft-ietf-sip-mib-06.txt". >> >>NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant >>mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >>Below is the data which will enable a MIME compliant mail reader >>implementation to automatically retrieve the ASCII version of the >>Internet-Draft. >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kevin R. Lingle 919.392.2029 http://www.klove.com http://www.air1.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 Wed Jul 9 12:12:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08062 for ; Wed, 9 Jul 2003 12:12:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aHY9-00013U-F0 for sip-archive@odin.ietf.org; Wed, 09 Jul 2003 12:12:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69GC9h4004049 for sip-archive@odin.ietf.org; Wed, 9 Jul 2003 12:12:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aHY1-00010l-Gq; Wed, 09 Jul 2003 12:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aHX9-0000zy-Gx for sip@optimus.ietf.org; Wed, 09 Jul 2003 12:11:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07968 for ; Wed, 9 Jul 2003 12:11:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aHX8-0000Df-00 for sip@ietf.org; Wed, 09 Jul 2003 12:11:06 -0400 Received: from ierw.net.avaya.com ([198.152.13.101]) by ietf-mx with esmtp (Exim 4.12) id 19aHX7-0000Dc-00 for sip@ietf.org; Wed, 09 Jul 2003 12:11:05 -0400 Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17810 for ; Wed, 9 Jul 2003 12:08:19 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17773 for ; Wed, 9 Jul 2003 12:08:18 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-mib-06.txt Date: Wed, 9 Jul 2003 19:11:01 +0300 Message-ID: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-mib-06.txt Thread-Index: AcNGM9W0NbY78HczTZ+46o3yr3GUiQAACDZQ From: "Romascanu, Dan (Dan)" To: "Marc Archer" , 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 See section 4.6.1.1 in = http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-= 01.txt for the usage of Unsigned32, and Appendix C for the use of SMIng = for MIB modules compilation. Regards, Dan > -----Original Message----- > From: Marc Archer [mailto:marcher@aastra.com] > Sent: 09 July, 2003 6:48 PM > To: sip@ietf.org > Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-mib-06.txt >=20 >=20 > Hi, >=20 > One more query! >=20 > While I was compiling the .MIB file, I got the following=20 > Warnings in all the > places where I have Unsigned32.=20 >=20 > --- Warning: unhandled MIB syntax SYNuns32. >=20 >=20 > I have it in the IMPORTS section of the .MIB file as below: >=20 > IMPORTS =20 > MODULE-IDENTITY, =20 > OBJECT-TYPE, =20 > NOTIFICATION-TYPE, =20 > Counter32, =20 > Gauge32, =20 > TimeTicks, > Unsigned32, =20 > mib-2 > FROM SNMPv2-SMI =20 >=20 > I have also included in the .INC file=20 >=20 > #condInclude "rfc1902.inc" -- SNMPv2-SMI >=20 >=20 > It continue further & final stops due to error as it cannot=20 > reference any of > those variables. >=20 > I am using SMICng version 2.1.03(BOOK)(MS-DOS32), February 12, 1997 & > epilogue 9.1 SNMP stack. >=20 > Regards, >=20 > Marc Archer >=20 > -----Original Message----- > From: Kevin Lingle [mailto:klingle@cisco.com] > Sent: Monday, July 07, 2003 5:10 PM > To: Marc Archer > Cc: sip@ietf.org > Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-mib-06.txt >=20 >=20 > marc, >=20 > we (cisco) used to have essentially the same problem due to > older verison of smicng not recognizing BITS construct. > i believe newer versions of smicng (i think we have v2.2.11 now) > have fixed this afaik. i know that we used to have to "work around" > this by commenting out BITS syntax and replacing it with OCTET STRING. >=20 > i suggest you contact http://www.snmpinfo.com for a=20 > definitive answer on > whether your version of smicng is deficient wrt BITS or whether > there is a switch you can turn on to eliminate the compile problem. >=20 > btw, i ran the mib modules though smicng before publishing and did > not have any errors reported.... except for the mib numbers: xx, yy > which are eliminated by putting in some arbitrary (high) mib-2 oid > assigned numbers (per dan's earlier suggestion). >=20 > kevin >=20 > Marc Archer wrote: > > Hi, > >=20 > > One more query: > >=20 > > We are trying to integrate the Draft version for SIP MIBs ( > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-06.txt) > . In this, > > there is a BITS definition. BITS is not declared in the=20 > IMPORTS section > (RFC > > 2578 Section 3.2) of the mib file. I have included RFC 1902=20 > in the .INC > file > > as below: > >=20 > > #condInclude "rfc1902.inc" -- SNMPv2-SMI > >=20 > > When I compile, I am getting the error=20 > >=20 > > ": f(sip_tc.mib), (3,1) SMI item "BITS" used in SIP-TC, but=20 > not defined or > > imported". > >=20 > > I am using SMICng version 2.1.03(BOOK)(MS-DOS32), February 12, 1997. > >=20 > > Could someone tell me a fix for this problem? Is there any=20 > switch option > > that can take care of this? > >=20 > > Regards, > >=20 > > Marc Archer > >=20 > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: Monday, July 07, 2003 9:58 AM > > To: Marc Archer; sip@ietf.org > > Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-mib-06.txt > >=20 > >=20 > > Marc, > >=20 > > 1) The OID assignment for the MIB modules is being done by=20 > RFC Editor in > the > > final phases of releasing the RFC. Replace meantime xx with=20 > a number of > your > > choice, trying to avoid the already defined numbers, in=20 > order to pass > > compilation. > > 2) RFC 2578 Section 3.2 specifies which symbols must be=20 > imported and also > > lists certain pre-defined symbols that must not be=20 > imported. The BITS > > construct must not be imported.=20 > >=20 > > For more information about standard MIBs review procedures=20 > (including > > compilation tools and options) see > > > http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review- > guidelines-01. > > txt. > >=20 > > Regards, > >=20 > > Dan > > =20 > >=20 > >>-----Original Message----- > >>From: Marc Archer [mailto:marcher@aastra.com] > >>Sent: 07 July, 2003 4:27 PM > >>To: sip@ietf.org > >>Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-mib-06.txt > >> > >> > >>Some comments on the draft > >> > >>TITLE: Has anyone come across a compilation error for not=20 > >>having a proper > >>IANA assigned number? > >> > >>I am getting error during compilation (Sub-Id for item=20 > "sipTC" must be > >>"number" or "name (number)" format) as it is Draft version &=20 > >>we do not have > >>mib-2 number. We got to have a number for SIP-COMMON-MIB, SIP-TC & > >>SIP-UA-MIB. > >> > >> ::=3D { mib-2 xx }=20 > >> -- RFC Ed: replace xx with actual IANA assigned number =20 > >> > >>Any thoughts?=20 > >> > >>TITLE: Error due to BITS usage > >> > >>I am experiencing a compilation error due to missing=20 > >>declaration of BITS in > >>SIP-COMMON-MIB & SIP-TC. > >> > >>There is a BITS usage in the MIB files. > >> > >> SYNTAX BITS { =20 > >> other(0), -- none of the=20 > >>following =20 > >> udp(1), =20 > >> tcp(2), =20 > >> sctp(3), =20 > >> tls(4) =20 > >> } =20 > >> > >>In the IMPORTS Section, it was not defined; I was getting the=20 > >>following > >>Error message. > >> > >>SMI item "BITS" used in SIP-TC, but not defined or imported. > >> > >>Since "BITS" is defined in RFC1902.MIB (SNMPv2-SMI), which=20 > is already > >>included in the *.INC file, I added "BITS" in the IMPORTS=20 > >>Section as below: > >> > >> IMPORTS =20 > >> MODULE-IDENTITY, =20 > >> mib-2, BITS =20 > >> FROM SNMPv2-SMI =20 > >> > >>The compilation goes much further but it then comes up with=20 > >>the following > >>error: > >> > >>expected a string, got BITS > >> > >> > >>Any help will be very much appreciated. > >> > >>Regards, > >> > >>Marc Archer > >> > >>-----Original Message----- > >>From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > >>Sent: Wednesday, July 02, 2003 6:57 AM > >>Cc: sip@ietf.org > >>Subject: [Sip] I-D ACTION:draft-ietf-sip-mib-06.txt > >> > >> > >>A New Internet-Draft is available from the on-line Internet-Drafts > >>directories. > >>This draft is a work item of the Session Initiation Protocol=20 > >>Working Group > >>of the IETF. > >> > >> Title : Management Information Base for=20 > >>Session Initiation > >> > >> Protocol > >> Author(s) : K. Lingle, J. Maeng, J. Mule, D. Walker > >> Filename : draft-ietf-sip-mib-06.txt > >> Pages : 104 > >> Date : 2003-7-1 > >>=09 > >>This memo defines a portion of the Management Information=20 > Base (MIB)=20 > >>for use with network management protocols in the Internet=20 > community. =20 > >>In particular, it describes a set of managed objects that are used=20 > >>to manage Session Initiation Protocol (SIP) entities, which include=20 > >>User Agents, Proxy servers, Redirect servers and Registrars. > >> > >>A URL for this Internet-Draft is: > >>http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-06.txt > >> > >>To remove yourself from the IETF Announcement list, send a=20 > message to=20 > >>ietf-announce-request with the word unsubscribe in the body=20 > >>of the message. > >> > >>Internet-Drafts are also available by anonymous FTP. Login=20 > >>with the username > >>"anonymous" and a password of your e-mail address. After logging in, > >>type "cd internet-drafts" and then > >> "get draft-ietf-sip-mib-06.txt". > >> > >>A list of Internet-Drafts directories can be found in > >>http://www.ietf.org/shadow.html=20 > >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > >> > >>Internet-Drafts can also be obtained by e-mail. > >> > >>Send a message to: > >> mailserv@ietf.org. > >>In the body type: > >> "FILE /internet-drafts/draft-ietf-sip-mib-06.txt". > >>=09 > >>NOTE: The mail server at ietf.org can return the document in > >> MIME-encoded form by using the "mpack" utility. To use this > >> feature, insert the command "ENCODING mime" before the "FILE" > >> command. To decode the response(s), you will need "munpack" or > >> a MIME-compliant mail reader. Different MIME-compliant=20 > >>mail readers > >> exhibit different behavior, especially when dealing with > >> "multipart" MIME messages (i.e. documents which have been split > >> up into multiple messages), so check your local documentation on > >> how to manipulate these messages. > >> =09 > >> =09 > >>Below is the data which will enable a MIME compliant mail reader > >>implementation to automatically retrieve the ASCII version of the > >>Internet-Draft. > >> > >>_______________________________________________ > >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>This list is for NEW development of the core SIP Protocol > >>Use sip-implementors@cs.columbia.edu for questions on current sip > >>Use sipping@ietf.org for new developments on the application of sip > >> > >=20 > >=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 > >=20 >=20 >=20 > --=20 > = =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- > =3D-=3D-=3D-=3D-=3D > Kevin R. Lingle 919.392.2029 > http://www.klove.com =20 http://www.air1.com =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Jul 9 13:51:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11953 for ; Wed, 9 Jul 2003 13:51:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aJ6F-0007qE-Pk for sip-archive@odin.ietf.org; Wed, 09 Jul 2003 13:51:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69HpR8r030136 for sip-archive@odin.ietf.org; Wed, 9 Jul 2003 13:51:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aJ5q-0007p7-JP; Wed, 09 Jul 2003 13: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 19aJ5d-0007oW-SR for sip@optimus.ietf.org; Wed, 09 Jul 2003 13:50: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 NAA11929 for ; Wed, 9 Jul 2003 13:50:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aJ5b-0001Fo-00 for sip@ietf.org; Wed, 09 Jul 2003 13:50:47 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19aJ5a-0001Fg-00 for sip@ietf.org; Wed, 09 Jul 2003 13:50:46 -0400 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h69Ho9pt001321; Wed, 9 Jul 2003 10:50:13 -0700 (PDT) Received: from cisco.com (klingle-ultra.cisco.com [64.102.93.47]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AGL69607; Wed, 9 Jul 2003 10:50:08 -0700 (PDT) Message-ID: <3F0C55CF.4080009@cisco.com> Date: Wed, 09 Jul 2003 13:50:07 -0400 From: Kevin Lingle User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marc Archer CC: sip@ietf.org Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-mib-06.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit marc, i'm sorry for the trouble you are having, but i fail to see the problem with the mib module. Unsigned32 is defined in SNMPv2-SMI so the import is proper. my understanding is that SMICng inherently understands the "standard" constructs from the SMI - like Unsigned32. i don't really know what to tell you. i've never seen any such compiler warnings with any revision of these or other mibs where Unsigned32 syntax exists - even with our older version of SMIC. kevin Marc Archer wrote: > Hi, > > One more query! > > While I was compiling the .MIB file, I got the following Warnings in all the > places where I have Unsigned32. > > --- Warning: unhandled MIB syntax SYNuns32. > > > I have it in the IMPORTS section of the .MIB file as below: > > IMPORTS > MODULE-IDENTITY, > OBJECT-TYPE, > NOTIFICATION-TYPE, > Counter32, > Gauge32, > TimeTicks, > Unsigned32, > mib-2 > FROM SNMPv2-SMI > > I have also included in the .INC file > > #condInclude "rfc1902.inc" -- SNMPv2-SMI > > > It continue further & final stops due to error as it cannot reference any of > those variables. > > I am using SMICng version 2.1.03(BOOK)(MS-DOS32), February 12, 1997 & > epilogue 9.1 SNMP stack. > > Regards, > > Marc Archer > > -----Original Message----- > From: Kevin Lingle [mailto:klingle@cisco.com] > Sent: Monday, July 07, 2003 5:10 PM > To: Marc Archer > Cc: sip@ietf.org > Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-mib-06.txt > > > marc, > > we (cisco) used to have essentially the same problem due to > older verison of smicng not recognizing BITS construct. > i believe newer versions of smicng (i think we have v2.2.11 now) > have fixed this afaik. i know that we used to have to "work around" > this by commenting out BITS syntax and replacing it with OCTET STRING. > > i suggest you contact http://www.snmpinfo.com for a definitive answer on > whether your version of smicng is deficient wrt BITS or whether > there is a switch you can turn on to eliminate the compile problem. > > btw, i ran the mib modules though smicng before publishing and did > not have any errors reported.... except for the mib numbers: xx, yy > which are eliminated by putting in some arbitrary (high) mib-2 oid > assigned numbers (per dan's earlier suggestion). > > kevin > > Marc Archer wrote: > >>Hi, >> >>One more query: >> >>We are trying to integrate the Draft version for SIP MIBs ( >>http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-06.txt). In this, >>there is a BITS definition. BITS is not declared in the IMPORTS section > > (RFC > >>2578 Section 3.2) of the mib file. I have included RFC 1902 in the .INC > > file > >>as below: >> >>#condInclude "rfc1902.inc" -- SNMPv2-SMI >> >>When I compile, I am getting the error >> >>": f(sip_tc.mib), (3,1) SMI item "BITS" used in SIP-TC, but not defined or >>imported". >> >>I am using SMICng version 2.1.03(BOOK)(MS-DOS32), February 12, 1997. >> >>Could someone tell me a fix for this problem? Is there any switch option >>that can take care of this? >> >>Regards, >> >>Marc Archer >> >>-----Original Message----- >>From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] >>Sent: Monday, July 07, 2003 9:58 AM >>To: Marc Archer; sip@ietf.org >>Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-mib-06.txt >> >> >>Marc, >> >>1) The OID assignment for the MIB modules is being done by RFC Editor in > > the > >>final phases of releasing the RFC. Replace meantime xx with a number of > > your > >>choice, trying to avoid the already defined numbers, in order to pass >>compilation. >>2) RFC 2578 Section 3.2 specifies which symbols must be imported and also >>lists certain pre-defined symbols that must not be imported. The BITS >>construct must not be imported. >> >>For more information about standard MIBs review procedures (including >>compilation tools and options) see >> > > http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-01. > >>txt. >> >>Regards, >> >>Dan >> >> >> >>>-----Original Message----- >>>From: Marc Archer [mailto:marcher@aastra.com] >>>Sent: 07 July, 2003 4:27 PM >>>To: sip@ietf.org >>>Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-mib-06.txt >>> >>> >>>Some comments on the draft >>> >>>TITLE: Has anyone come across a compilation error for not >>>having a proper >>>IANA assigned number? >>> >>>I am getting error during compilation (Sub-Id for item "sipTC" must be >>>"number" or "name (number)" format) as it is Draft version & >>>we do not have >>>mib-2 number. We got to have a number for SIP-COMMON-MIB, SIP-TC & >>>SIP-UA-MIB. >>> >>> ::= { mib-2 xx } >>> -- RFC Ed: replace xx with actual IANA assigned number >>> >>>Any thoughts? >>> >>>TITLE: Error due to BITS usage >>> >>>I am experiencing a compilation error due to missing >>>declaration of BITS in >>>SIP-COMMON-MIB & SIP-TC. >>> >>>There is a BITS usage in the MIB files. >>> >>> SYNTAX BITS { >>> other(0), -- none of the >>>following >>> udp(1), >>> tcp(2), >>> sctp(3), >>> tls(4) >>> } >>> >>>In the IMPORTS Section, it was not defined; I was getting the >>>following >>>Error message. >>> >>>SMI item "BITS" used in SIP-TC, but not defined or imported. >>> >>>Since "BITS" is defined in RFC1902.MIB (SNMPv2-SMI), which is already >>>included in the *.INC file, I added "BITS" in the IMPORTS >>>Section as below: >>> >>> IMPORTS >>> MODULE-IDENTITY, >>> mib-2, BITS >>> FROM SNMPv2-SMI >>> >>>The compilation goes much further but it then comes up with >>>the following >>>error: >>> >>>expected a string, got BITS >>> >>> >>>Any help will be very much appreciated. >>> >>>Regards, >>> >>>Marc Archer >>> >>>-----Original Message----- >>>From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >>>Sent: Wednesday, July 02, 2003 6:57 AM >>>Cc: sip@ietf.org >>>Subject: [Sip] I-D ACTION:draft-ietf-sip-mib-06.txt >>> >>> >>>A New Internet-Draft is available from the on-line Internet-Drafts >>>directories. >>>This draft is a work item of the Session Initiation Protocol >>>Working Group >>>of the IETF. >>> >>> Title : Management Information Base for >>>Session Initiation >>> >>> Protocol >>> Author(s) : K. Lingle, J. Maeng, J. Mule, D. Walker >>> Filename : draft-ietf-sip-mib-06.txt >>> Pages : 104 >>> Date : 2003-7-1 >>> >>>This memo defines a portion of the Management Information Base (MIB) >>>for use with network management protocols in the Internet community. >>>In particular, it describes a set of managed objects that are used >>>to manage Session Initiation Protocol (SIP) entities, which include >>>User Agents, Proxy servers, Redirect servers and Registrars. >>> >>>A URL for this Internet-Draft is: >>>http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-06.txt >>> >>>To remove yourself from the IETF Announcement list, send a message to >>>ietf-announce-request with the word unsubscribe in the body >>>of the message. >>> >>>Internet-Drafts are also available by anonymous FTP. Login >>>with the username >>>"anonymous" and a password of your e-mail address. After logging in, >>>type "cd internet-drafts" and then >>> "get draft-ietf-sip-mib-06.txt". >>> >>>A list of Internet-Drafts directories can be found in >>>http://www.ietf.org/shadow.html >>>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> >>>Internet-Drafts can also be obtained by e-mail. >>> >>>Send a message to: >>> mailserv@ietf.org. >>>In the body type: >>> "FILE /internet-drafts/draft-ietf-sip-mib-06.txt". >>> >>>NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or >>> a MIME-compliant mail reader. Different MIME-compliant >>>mail readers >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been split >>> up into multiple messages), so check your local documentation on >>> how to manipulate these messages. >>> >>> >>>Below is the data which will enable a MIME compliant mail reader >>>implementation to automatically retrieve the ASCII version of the >>>Internet-Draft. >>> >>>_______________________________________________ >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>This list is for NEW development of the core SIP Protocol >>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>Use sipping@ietf.org for new developments on the application of sip >>> >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> > > > -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kevin R. Lingle 919.392.2029 http://www.klove.com http://www.air1.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 Wed Jul 9 14:43:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13555 for ; Wed, 9 Jul 2003 14:42:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aJtg-0002A8-UP for sip-archive@odin.ietf.org; Wed, 09 Jul 2003 14:42:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69IgWsR008306 for sip-archive@odin.ietf.org; Wed, 9 Jul 2003 14:42:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aJtC-00027E-Qy; Wed, 09 Jul 2003 14:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aJsq-00026a-7m for sip@optimus.ietf.org; Wed, 09 Jul 2003 14:41: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 OAA13489; Wed, 9 Jul 2003 14:41:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aJsn-0001fz-00; Wed, 09 Jul 2003 14:41:37 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19aJsl-0001fl-00; Wed, 09 Jul 2003 14:41:36 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA26636; Wed, 9 Jul 2003 14:41:00 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA09953; Wed, 9 Jul 2003 14:41:01 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <3P1MQBM7>; Wed, 9 Jul 2003 14:41:01 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5BB7@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Yutaka Takeda'" , sip@ietf.org, mmusic@ietf.org Subject: RE: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP Date: Wed, 9 Jul 2003 14:40:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mailgate.pit.comms.marconi.com id OAA26636 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 I've been thinking for a long time about what an appropriate mechanism to provide a voice/videomail client on a sipphone would be. It's really clear that you record and play messages with VCR like functionality. For that, you need start/stop/pause/ rewind/fast forward, and so I was thinking RTSP. On the other hand, you surely establish the session to the voicemail server with a sip call. Thus, I like the way Jonathan is thinking, but you also need message selection/creation/deletion functions, and for those I was thinking KPML, and then you wonder if you just use that as the signalling mechanism for the record/play, and I get confused. Brian > -----Original Message----- > From: Yutaka Takeda [mailto:takeday@kmerl.com] > Sent: Wednesday, July 09, 2003 2:11 PM > To: sip@ietf.org; mmusic@ietf.org > Subject: RE: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP >=20 >=20 > The applications that have need for SIP and RTSP features I > can imagine are: >=20 > - Voice&video mail (similar to 'sipum' but VM server is in=20 > the SIP phone) > - Personal broadcast station from my PC at home. > - Watching video recorded with VCR at home or office from remote... >=20 > What I am not sure is if RTSP has any solution or a framework for a > RTSP server behind a NAT. If not, the solution is likely to=20 > be a repeat > of what SIP provides. I thought TURN could be used in order=20 > for signaling > message to reach RTSP server behind a NAT, but I noticed that=20 > it is not=20 > applicable (purposefully) for a server running behind a NAT because of > a security consideration. Lots of issues for RTSP in this area alone? >=20 > I believe a lot of people are interested in this discussion. >=20 > Best regards, > Yutaka >=20 >=20 > > -----Original Message----- > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Sent: Wednesday, July 09, 2003 5:53 AM > > To: Pianigiani, Jacopo (Jacopo) > > Cc: sip@ietf.org; mmusic@ietf.org > > Subject: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP > >=20 > >=20 > > Hi, > >=20 > > When it comes to IMS and 3G terminals, most will already=20 > > before having=20 > > an IMS functionality have support for PSS. PSS is=20 > > Packet-based Streaming=20 > > Service which is an umbrella kind of standard for streaming service=20 > > defined in 3GPP targeted at low bit-rates and mobile networks.=20 > > Specification available from Rel 4 in TS 26.233 and TS=20 > > 26.234. Already=20 > > today there exist GSM/GPRS phones that has a PSS client. > >=20 > > So I think that dual stack implementations will not be that=20 > > impossible=20 > > to foresee. > >=20 > > However I think the main issue in this discussion is to=20 > look at what=20 > > applications that has need for SIP-RTSP interactions. Based=20 > > on this we=20 > > can see if there is solutions easily available or not. > >=20 > > I can agree with Rosenberg that if we where going to design a RTSP=20 > > functionality protocol today, looking at SIP for session=20 > > establishment=20 > > would be interesting. However that opportunity has passed=20 > as RTSP has=20 > > started to be deployed in increasing numbers. I think even=20 > the latest=20 > > Windows media player does support RTSP. > >=20 > >=20 > > Best Regards > >=20 > > Magnus Westerlund > >=20 > >=20 > > Pianigiani, Jacopo (Jacopo) wrote: > > > Hello all, > > > In my undertanding RTSP is suitable for broadcast, unicast=20 > > or multicast streams distribution. The RTSP protocol was=20 > > ideated for typical content delivery, and in effect for this=20 > > application could be more than suitable. But referring to an=20 > > IMS domain, in my point of view adopting RSTP as media=20 > > streams control, would imply adopting at least a double=20 > > protocol stack in the terminal equipment. The IMS concept was=20 > > mainly driven by the concept - in my understanding - of=20 > > simplifying the terminal (making it simpler from a protocol=20 > > stack implementation means lowering costs and increasing=20 > > penetration on the market) by adopting a single protocol=20 > > stack in the terminal, and having the RAN and the core=20 > > evolving toward a unified transport mechanism for which an=20 > > almost unified level of control on the network resources=20 > > allocated to a session (whatever session we refer to, voice ,=20 > > multimedia p-t-t call, web browsing, multimedia session with=20 > > voice call and dynamic web pages). > > > So in this sense, my understanding is that the RTSP could=20 > > be suitable for media content, but it would imply again new=20 > > complexity on the IMS UMTS/CDMA terminal itself, which is=20 > > against the idea of IMS of enhancing the services the user=20 > > can access by having an homogeneous protocol stack on the=20 > > terminal itself for all types of services. > > >=20 > > > After all, the RTSP , apart from content delivery (of=20 > > streams), could not definitely handle appropriately sessions=20 > > like Voice calls + Interactive Web Pages.=20 > > > Regards > > >=20 > > > Jacopo Pianigiani > > > Lucent Technologies - Italy > > > =E839 335 7350536 > > >=20 > > > -----Original Message----- > > > From: Paolo Asprino [mailto:asprino@coritel.it] > > > Sent: Wednesday, July 09, 2003 9:40 AM > > > To: NAKAMURA, Hidefumi; sip@ietf.org; mmusic@ietf.org > > > Subject: Re: [Sip] Appropriate usage of SIP and RTSP > > >=20 > > >=20 > > > Hi all > > >=20 > > > I'm thinking a solution to join SIP and RTSP in the 3G IMS domain. > > > In particular in the IMS, I think that to provide multilmedia > > > service (i.e video on demand), one can estabilish a=20 > > subscription to the service by SIP and then activate the=20 > > service with RTSP by DIGEST autentication with the=20 > > > parameters exchanged early during the subscription=20 > > (username and password)=20 > > >=20 > > > What do you think about that? > > >=20 > > > Best Regards=20 > > >=20 > > > ----- Original Message -----=20 > > > From: "NAKAMURA, Hidefumi" > > > To: ; > > > Cc: > > > Sent: Monday, July 07, 2003 9:49 AM > > > Subject: [Sip] Appropriate usage of SIP and RTSP > > >=20 > > >=20 > > >=20 > > >>Hi, all. > > >> > > >>I have a question about the relationship between SIP and RTSP.=20 > > >> > > >>In RFC3261, there is a description that says=20 > > >> "SIP is not a vertically integrated communications=20 > > system. SIP is > > >> rather a component that can be used with other IETF=20 > protocols to > > >> build a complete multimedia architecture. Typically, these > > >> architectures will include protocols such as the=20 > > Real-time Transport > > >> Protocol (RTP) (RFC 1889 [28]) for transporting=20 > > real-time data and > > >> providing QoS feedback, the Real-Time streaming protocol=20 > > (RTSP) (RFC > > >> 2326 [29]) for controlling delivery of streaming media, ..." > > >> (RFC3261 Section 2) > > >> > > >>However, my understanding is that both SIP and RTSP have=20 > > the capability > > >>for "discovery of UAs or media streams." > > >>If I use SIP to establish a stream session and use RTSP to control > > >>the stream, there will be redundant sequences, i.e.=20 > > INVITE-OK-ACK and > > >>SETUP-OK. > > >> > > >>Was there any discussion on how to use these two protocols=20 > > appropriately? > > >> > > >>With SIP application server, network providers can provide various > > >>services on contents delivery while we will not be able to=20 > > do so only > > >>with RTSP, I think. On the other hand, RTSP has enough=20 > > capability for > > >>discovery of media streams and for negotiation of SDPs. > > >>So, I think, for the simple delivery of contents, RTSP is=20 > > appropriate to > > >>use, and for various session control services regarding contents > > >>delivery, SIP with RTSP is appropriate to use. > > >> > > >>Any opinions? > > >> > > >>I wonder why no contents delivery server seems to prepare=20 > > SIP stack now.=20 > > >>Is it because, up to now, there exists only a simple=20 > > contents delivery > > >>service? > > >> > > >>best regards, > > >> > > >>--=20 > > >>NAKAMURA, Hidefumi=20 > > >>NTT ServiceIntegration /NetworkServiceSystems Labs. > > >>tel: +81(422)59 3904; fax:+81(422)60 4012 > > >>--- > > >> > > >> > > >> > > >>_______________________________________________ > > >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > >>This list is for NEW development of the core SIP Protocol > > >>Use sip-implementors@cs.columbia.edu for questions on current sip > > >>Use sipping@ietf.org for new developments on the=20 > application of sip > > >> > > >=20 > > >=20 > > >=20 > > > --- > > > Outgoing mail is certified Virus Free. > > > Checked by AVG anti-virus system (http://www.grisoft.com). > > > Version: 6.0.495 / Virus Database: 294 - Release Date:=20 > > 30/06/2003J*fj)bz b=B2=D8m=B6>?=FF=0C> > 0=D6'=AD~S=E0=FEf=A2-f=A7=FE= X=AC=B6)=DF=A3=FB"=A58b=B2X=AC=B6+=1F=A2=B3DY=D7=AF > > zZ)(tm)=E9=ED=A1=FBay=CA+y"=0F>=BA-=A1=CA%R=C7=ACS~=A6=A6W=A6z{h=AE=C7= ,r?n(tm)=B8sy=DBY=A2=BA=AEz=CBb=A2{(=9D=CB=AB > > =AD=E9=ED=B2*T=B1=EB"=A6~=A7''=AD~S=E0~S=E7{=07^=BD=E9h=A6g=A7=B6=CA'= =B6=17s=A6(tm)bq=ABb=A2z=1F > > >=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=20 > application of sip > > >=20 > >=20 > >=20 > > --=20 > >=20 > > Magnus Westerlund > >=20 > > Multimedia Technologies, Ericsson Research EAB/TVA/A > >=20 > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 8 4048287 > > Torshamsgatan 23 | Fax +46 8 7575550 > > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > >=20 > >=20 > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=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 From exim@www1.ietf.org Wed Jul 9 14:55:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14404 for ; Wed, 9 Jul 2003 14:55:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aK61-0003HI-3O for sip-archive@odin.ietf.org; Wed, 09 Jul 2003 14:55:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69ItHJL012594 for sip-archive@odin.ietf.org; Wed, 9 Jul 2003 14:55:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aK5m-0003Da-UG; Wed, 09 Jul 2003 14:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aK54-00038r-4q for sip@optimus.ietf.org; Wed, 09 Jul 2003 14:54:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14276; Wed, 9 Jul 2003 14:54:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aK51-0001sH-00; Wed, 09 Jul 2003 14:54:15 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19aK4z-0001rJ-00; Wed, 09 Jul 2003 14:54:14 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 09 Jul 2003 11:56:34 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h69IrepZ005290; Wed, 9 Jul 2003 11:53:40 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AFW13842; Wed, 9 Jul 2003 11:53:39 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA11010; Wed, 9 Jul 2003 11:53:39 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <16140.25779.138519.619908@thomasm-u1.cisco.com> Date: Wed, 9 Jul 2003 11:53:39 -0700 (PDT) To: "Rosen, Brian" Cc: "'Yutaka Takeda'" , sip@ietf.org, mmusic@ietf.org Subject: RE: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP In-Reply-To: <313680C9A886D511A06000204840E1CF070B5BB7@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF070B5BB7@whq-msgusr-02.pit.comms.marconi.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 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 Hmm. I'd always thought of SIP as a rendezvous protocol so this seems perfectly natural to me. Is the general problem here that the SDP announcement for an RTSP controlled session isn't defined? Or is the issue that people would like to piggyback both the RTSP and RTP session information in the SIP SDP? Or both?=20 Of course if the announcement for RTSP is not specified, it sort of begs the question of why you'd want to just define RTSP semantics... why not HTTP semantics, etc too? (in which case, it seems to me that an over-loaded SIP SDP announcment is probably the wrong thing to do). =09 Mike Rosen, Brian writes: > I've been thinking for a long time about what an appropriate > mechanism to provide a voice/videomail client on a sipphone > would be. It's really clear that you record and play messages > with VCR like functionality. For that, you need start/stop/pause/ > rewind/fast forward, and so I was thinking RTSP. On the other > hand, you surely establish the session to the voicemail server > with a sip call. >=20 > Thus, I like the way Jonathan is thinking, but you also need > message selection/creation/deletion functions, and for those > I was thinking KPML, and then you wonder if you just use that > as the signalling mechanism for the record/play, and I get > confused. >=20 > Brian >=20 > > -----Original Message----- > > From: Yutaka Takeda [mailto:takeday@kmerl.com] > > Sent: Wednesday, July 09, 2003 2:11 PM > > To: sip@ietf.org; mmusic@ietf.org > > Subject: RE: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP > >=20 > >=20 > > The applications that have need for SIP and RTSP features I > > can imagine are: > >=20 > > - Voice&video mail (similar to 'sipum' but VM server is in=20 > > the SIP phone) > > - Personal broadcast station from my PC at home. > > - Watching video recorded with VCR at home or office from remote..= . > >=20 > > What I am not sure is if RTSP has any solution or a framework for = a > > RTSP server behind a NAT. If not, the solution is likely to=20 > > be a repeat > > of what SIP provides. I thought TURN could be used in order=20 > > for signaling > > message to reach RTSP server behind a NAT, but I noticed that=20 > > it is not=20 > > applicable (purposefully) for a server running behind a NAT becaus= e of > > a security consideration. Lots of issues for RTSP in this area alo= ne? > >=20 > > I believe a lot of people are interested in this discussion. > >=20 > > Best regards, > > Yutaka > >=20 > >=20 > > > -----Original Message----- > > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > > Sent: Wednesday, July 09, 2003 5:53 AM > > > To: Pianigiani, Jacopo (Jacopo) > > > Cc: sip@ietf.org; mmusic@ietf.org > > > Subject: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP > > >=20 > > >=20 > > > Hi, > > >=20 > > > When it comes to IMS and 3G terminals, most will already=20 > > > before having=20 > > > an IMS functionality have support for PSS. PSS is=20 > > > Packet-based Streaming=20 > > > Service which is an umbrella kind of standard for streaming serv= ice=20 > > > defined in 3GPP targeted at low bit-rates and mobile networks.=20= > > > Specification available from Rel 4 in TS 26.233 and TS=20 > > > 26.234. Already=20 > > > today there exist GSM/GPRS phones that has a PSS client. > > >=20 > > > So I think that dual stack implementations will not be that=20 > > > impossible=20 > > > to foresee. > > >=20 > > > However I think the main issue in this discussion is to=20 > > look at what=20 > > > applications that has need for SIP-RTSP interactions. Based=20 > > > on this we=20 > > > can see if there is solutions easily available or not. > > >=20 > > > I can agree with Rosenberg that if we where going to design a RT= SP=20 > > > functionality protocol today, looking at SIP for session=20 > > > establishment=20 > > > would be interesting. However that opportunity has passed=20 > > as RTSP has=20 > > > started to be deployed in increasing numbers. I think even=20 > > the latest=20 > > > Windows media player does support RTSP. > > >=20 > > >=20 > > > Best Regards > > >=20 > > > Magnus Westerlund > > >=20 > > >=20 > > > Pianigiani, Jacopo (Jacopo) wrote: > > > > Hello all, > > > > In my undertanding RTSP is suitable for broadcast, unicast=20 > > > or multicast streams distribution. The RTSP protocol was=20 > > > ideated for typical content delivery, and in effect for this=20 > > > application could be more than suitable. But referring to an=20 > > > IMS domain, in my point of view adopting RSTP as media=20 > > > streams control, would imply adopting at least a double=20 > > > protocol stack in the terminal equipment. The IMS concept was=20= > > > mainly driven by the concept - in my understanding - of=20 > > > simplifying the terminal (making it simpler from a protocol=20 > > > stack implementation means lowering costs and increasing=20 > > > penetration on the market) by adopting a single protocol=20 > > > stack in the terminal, and having the RAN and the core=20 > > > evolving toward a unified transport mechanism for which an=20 > > > almost unified level of control on the network resources=20 > > > allocated to a session (whatever session we refer to, voice ,=20= > > > multimedia p-t-t call, web browsing, multimedia session with=20 > > > voice call and dynamic web pages). > > > > So in this sense, my understanding is that the RTSP could=20 > > > be suitable for media content, but it would imply again new=20 > > > complexity on the IMS UMTS/CDMA terminal itself, which is=20 > > > against the idea of IMS of enhancing the services the user=20 > > > can access by having an homogeneous protocol stack on the=20 > > > terminal itself for all types of services. > > > >=20 > > > > After all, the RTSP , apart from content delivery (of=20 > > > streams), could not definitely handle appropriately sessions=20 > > > like Voice calls + Interactive Web Pages.=20 > > > > Regards > > > >=20 > > > > Jacopo Pianigiani > > > > Lucent Technologies - Italy > > > > =E839 335 7350536 > > > >=20 > > > > -----Original Message----- > > > > From: Paolo Asprino [mailto:asprino@coritel.it] > > > > Sent: Wednesday, July 09, 2003 9:40 AM > > > > To: NAKAMURA, Hidefumi; sip@ietf.org; mmusic@ietf.org > > > > Subject: Re: [Sip] Appropriate usage of SIP and RTSP > > > >=20 > > > >=20 > > > > Hi all > > > >=20 > > > > I'm thinking a solution to join SIP and RTSP in the 3G IMS dom= ain. > > > > In particular in the IMS, I think that to provide multilmedia > > > > service (i.e video on demand), one can estabilish a=20 > > > subscription to the service by SIP and then activate the=20 > > > service with RTSP by DIGEST autentication with the=20 > > > > parameters exchanged early during the subscription=20 > > > (username and password)=20 > > > >=20 > > > > What do you think about that? > > > >=20 > > > > Best Regards=20 > > > >=20 > > > > ----- Original Message -----=20 > > > > From: "NAKAMURA, Hidefumi" > > > > To: ; > > > > Cc: > > > > Sent: Monday, July 07, 2003 9:49 AM > > > > Subject: [Sip] Appropriate usage of SIP and RTSP > > > >=20 > > > >=20 > > > >=20 > > > >>Hi, all. > > > >> > > > >>I have a question about the relationship between SIP and RTSP.= =20 > > > >> > > > >>In RFC3261, there is a description that says=20 > > > >> "SIP is not a vertically integrated communications=20 > > > system. SIP is > > > >> rather a component that can be used with other IETF=20 > > protocols to > > > >> build a complete multimedia architecture. Typically, these= > > > >> architectures will include protocols such as the=20 > > > Real-time Transport > > > >> Protocol (RTP) (RFC 1889 [28]) for transporting=20 > > > real-time data and > > > >> providing QoS feedback, the Real-Time streaming protocol=20= > > > (RTSP) (RFC > > > >> 2326 [29]) for controlling delivery of streaming media, ...= " > > > >> (RFC3261 Section 2) > > > >> > > > >>However, my understanding is that both SIP and RTSP have=20 > > > the capability > > > >>for "discovery of UAs or media streams." > > > >>If I use SIP to establish a stream session and use RTSP to con= trol > > > >>the stream, there will be redundant sequences, i.e.=20 > > > INVITE-OK-ACK and > > > >>SETUP-OK. > > > >> > > > >>Was there any discussion on how to use these two protocols=20 > > > appropriately? > > > >> > > > >>With SIP application server, network providers can provide var= ious > > > >>services on contents delivery while we will not be able to=20 > > > do so only > > > >>with RTSP, I think. On the other hand, RTSP has enough=20 > > > capability for > > > >>discovery of media streams and for negotiation of SDPs. > > > >>So, I think, for the simple delivery of contents, RTSP is=20 > > > appropriate to > > > >>use, and for various session control services regarding conten= ts > > > >>delivery, SIP with RTSP is appropriate to use. > > > >> > > > >>Any opinions? > > > >> > > > >>I wonder why no contents delivery server seems to prepare=20 > > > SIP stack now.=20 > > > >>Is it because, up to now, there exists only a simple=20 > > > contents delivery > > > >>service? > > > >> > > > >>best regards, > > > >> > > > >>--=20 > > > >>NAKAMURA, Hidefumi=20 > > > >>NTT ServiceIntegration /NetworkServiceSystems Labs. > > > >>tel: +81(422)59 3904; fax:+81(422)60 4012 > > > >>--- > > > >> > > > >> > > > >> > > > >>_______________________________________________ > > > >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > >>This list is for NEW development of the core SIP Protocol > > > >>Use sip-implementors@cs.columbia.edu for questions on current = sip > > > >>Use sipping@ietf.org for new developments on the=20 > > application of sip > > > >> > > > >=20 > > > >=20 > > > >=20 > > > > --- > > > > Outgoing mail is certified Virus Free. > > > > Checked by AVG anti-virus system (http://www.grisoft.com). > > > > Version: 6.0.495 / Virus Database: 294 - Release Date:=20 > > > 30/06/2003J*fj)bz=09b=B2=D8m=B6>?=FF=0C> > 0=D6'=AD~S=E0=FEf=A2-= f=A7=FEX=AC=B6)=DF=A3=FB"=A58b=B2X=AC=B6+=1F=A2=B3DY=D7=AF > > > zZ)(tm)=E9=ED=A1=FBay=CA+y"=0F>=BA-=A1=CA%R=C7=ACS~=A6=A6W=A6z{h= =AE=C7,r?n(tm)=B8sy=DBY=A2=BA=AEz=CBb=A2{(=9D=CB=AB > > > =AD=E9=ED=B2*T=B1=EB"=A6~=A7''=AD~S=E0~S=E7{=07^=BD=E9h=A6g=A7=B6= =CA'=B6=17s=A6(tm)bq=ABb=A2z=1F > > > >=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=20 > > application of sip > > > >=20 > > >=20 > > >=20 > > > --=20 > > >=20 > > > Magnus Westerlund > > >=20 > > > Multimedia Technologies, Ericsson Research EAB/TVA/A > > >=20 > > ------------------------------------------------------------------= ---- > > > Ericsson AB | Phone +46 8 4048287 > > > Torshamsgatan 23 | Fax +46 8 7575550 > > > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.= com > > >=20 > > >=20 > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mmusic > > >=20 > >=20 > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > >=20 >=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 Wed Jul 9 15:02:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14905 for ; Wed, 9 Jul 2003 15:02:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aKCh-00042S-3T for sip-archive@odin.ietf.org; Wed, 09 Jul 2003 15:02:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69J2BCe015503 for sip-archive@odin.ietf.org; Wed, 9 Jul 2003 15:02:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aKCY-0003zr-3L; Wed, 09 Jul 2003 15:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aKCK-0003zB-D1 for sip@optimus.ietf.org; Wed, 09 Jul 2003 15:01:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14811; Wed, 9 Jul 2003 15:01:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aKCH-00020T-00; Wed, 09 Jul 2003 15:01:45 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19aKCG-00020O-00; Wed, 09 Jul 2003 15:01:44 -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 h69IxxB14240; Wed, 9 Jul 2003 13:59:59 -0500 From: Robert Sparks To: sip-implementors@cs.columbia.edu Cc: sip@ietf.org, simple@ietf.org In-Reply-To: <1056657212.1916.82.camel@RjS.localdomain> References: <1056657212.1916.82.camel@RjS.localdomain> Content-Type: text/plain Message-Id: <1057777197.940.42.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 09 Jul 2003 13:59:57 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Sip-implementors] 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 closes next week. If you have not already registered, please do so now. Thanks, RjS On Thu, 2003-06-26 at 14:53, Robert Sparks wrote: > 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-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Jul 9 16:44:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21123 for ; Wed, 9 Jul 2003 16:44:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aLn5-0002hh-Uh for sip-archive@odin.ietf.org; Wed, 09 Jul 2003 16:43:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69Khpm6010385 for sip-archive@odin.ietf.org; Wed, 9 Jul 2003 16:43:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aLmH-0002M4-Ee; Wed, 09 Jul 2003 16:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aLlY-0002J7-AS for sip@optimus.ietf.org; Wed, 09 Jul 2003 16:42: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 QAA20971; Wed, 9 Jul 2003 16:42:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aLlW-0003An-00; Wed, 09 Jul 2003 16:42:14 -0400 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx with esmtp (Exim 4.12) id 19aLlU-0003AW-00; Wed, 09 Jul 2003 16:42:13 -0400 Received: by fox.iptel.org (Postfix, from userid 103) id 6C73C686; Wed, 9 Jul 2003 22:39:48 +0200 (CEST) Received: from jku07.iptel.org (port-212-202-40-87.reverse.qsc.de [212.202.40.87]) by fox.iptel.org (Postfix) with ESMTP id E211A683; Wed, 9 Jul 2003 22:39:47 +0200 (CEST) Message-Id: <5.2.0.9.0.20030709222843.0307c5f8@localhost> X-Sender: jiri@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 09 Jul 2003 22:38:11 +0200 To: sip@ietf.org, sipping@ietf.org From: Jiri Kuthan Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Subject: [Sip] text conferencing at ietf57 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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: there is a sip2jabber service that connects SIP users to jabber chat rooms in the upcoming IETF meeting. More information can be found at http://www.iptel.org/ietf54/ -jiri -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Jul 9 17:18:14 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22722 for ; Wed, 9 Jul 2003 17:18:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMJv-0006NS-EE for sip-archive@odin.ietf.org; Wed, 09 Jul 2003 17:17:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69LHlJp024501 for sip-archive@odin.ietf.org; Wed, 9 Jul 2003 17:17:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMJC-0005zm-Fq; Wed, 09 Jul 2003 17:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMIG-0005ve-LY for sip@optimus.ietf.org; Wed, 09 Jul 2003 17:16: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 RAA22645; Wed, 9 Jul 2003 17:16:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aMIE-0003bb-00; Wed, 09 Jul 2003 17:16:02 -0400 Received: from fox.iptel.org ([195.37.77.101]) by ietf-mx with esmtp (Exim 4.12) id 19aMID-0003bY-00; Wed, 09 Jul 2003 17:16:01 -0400 Received: by fox.iptel.org (Postfix, from userid 103) id 3688C6B2; Wed, 9 Jul 2003 23:13:43 +0200 (CEST) Received: from jku07.iptel.org (port-212-202-40-87.reverse.qsc.de [212.202.40.87]) by fox.iptel.org (Postfix) with ESMTP id 9960A683; Wed, 9 Jul 2003 23:13:42 +0200 (CEST) Message-Id: <5.2.0.9.0.20030709231136.00b370d0@localhost> X-Sender: jiri@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 09 Jul 2003 23:12:05 +0200 To: sip@ietf.org, sipping@ietf.org From: Jiri Kuthan In-Reply-To: <5.2.0.9.0.20030709222843.0307c5f8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-1.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Subject: [Sip] Re: text conferencing at ietf57 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , At 10:38 PM 7/9/2003, Jiri Kuthan wrote: >FYI: there is a sip2jabber service that connects SIP users to jabber chat rooms >in the upcoming IETF meeting. More information can be found >at http://www.iptel.org/ietf54/ typo: correct address is http://www.iptel.org/ietf57/ sorry, -jiri _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Jul 11 07:03:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24743 for ; Fri, 11 Jul 2003 07:03:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19avgN-0006tV-LB for sip-archive@odin.ietf.org; Fri, 11 Jul 2003 07:03:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BB3JYu026488 for sip-archive@odin.ietf.org; Fri, 11 Jul 2003 07:03:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19avg6-0006sX-DY; Fri, 11 Jul 2003 07:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19avfq-0006s9-K3 for sip@optimus.ietf.org; Fri, 11 Jul 2003 07:02: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 HAA24715 for ; Fri, 11 Jul 2003 07:02:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19avfm-0004ep-00 for sip@ietf.org; Fri, 11 Jul 2003 07:02:42 -0400 Received: from mail.cit.ie ([157.190.14.15]) by ietf-mx with esmtp (Exim 4.12) id 19avfl-0004eT-00 for sip@ietf.org; Fri, 11 Jul 2003 07:02:41 -0400 Received: from EEB174W2Kvk (unverified [157.190.81.172]) by cit.ie (Rockliffe SMTPRA 5.3.4) with SMTP id for ; Fri, 11 Jul 2003 11:59:42 +0100 Reply-To: From: "Valerie Kenneally" To: Date: Fri, 11 Jul 2003 12:01:35 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] SIP, Presence & Instant messaging Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org 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, Does anyone know of any document(s) which describe exactly why SIP is suitable for IM & P? Cheers, Valerie Kenneally -------------------Legal Disclaimer--------------------------------------- The above electronic mail transmission is confidential and intended only for the person to whom it is addressed. Its contents may be protected by legal and/or professional privilege. Should it be received by you in error please contact the sender at the above quoted email address. Any unauthorised form of reproduction of this message is strictly prohibited. The Institute does not guarantee the security of any information electronically transmitted and is not liable if the information contained in this communication is not a proper and complete record of the message as transmitted by the sender nor for any delay in its receipt. ---------------------------------------------------------------------------------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri Jul 11 10:17:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01028 for ; Fri, 11 Jul 2003 10:17:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ayi9-0005Dl-C7 for sip-archive@odin.ietf.org; Fri, 11 Jul 2003 10:17:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BEHLvC020065 for sip-archive@odin.ietf.org; Fri, 11 Jul 2003 10:17:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ayhq-0005BO-Af; Fri, 11 Jul 2003 10:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ayhk-0005Au-US for sip@optimus.ietf.org; Fri, 11 Jul 2003 10:16: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 KAA00946; Fri, 11 Jul 2003 10:16:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ayhi-0005vP-00; Fri, 11 Jul 2003 10:16:54 -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 19ayhh-0005vL-00; Fri, 11 Jul 2003 10:16:53 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6BEGL7F003667; Fri, 11 Jul 2003 07:16:21 -0700 (PDT) Received: from [10.0.1.6] (sjc-vpn2-563.cisco.com [10.21.114.51]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFY09875; Fri, 11 Jul 2003 07:16:19 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 11 Jul 2003 07:16:17 -0700 Subject: Re: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP From: Cullen Jennings To: Brian Rosen , "'Yutaka Takeda'" , , Message-ID: In-Reply-To: <313680C9A886D511A06000204840E1CF070B5BB7@whq-msgusr-02.pit.comms.marconi.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable 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 In many ways, this problem is similar to the far end camera control issues. Real time responses is needed, It is a 1:1 relationship between the controller and controlee, the control protocol needs to be extensible. On 7/9/03 11:40, "Rosen, Brian" wrote: > I've been thinking for a long time about what an appropriate > mechanism to provide a voice/videomail client on a sipphone > would be. It's really clear that you record and play messages > with VCR like functionality. For that, you need start/stop/pause/ > rewind/fast forward, and so I was thinking RTSP. On the other > hand, you surely establish the session to the voicemail server > with a sip call. >=20 > Thus, I like the way Jonathan is thinking, but you also need > message selection/creation/deletion functions, and for those > I was thinking KPML, and then you wonder if you just use that > as the signalling mechanism for the record/play, and I get > confused. >=20 > Brian >=20 >> -----Original Message----- >> From: Yutaka Takeda [mailto:takeday@kmerl.com] >> Sent: Wednesday, July 09, 2003 2:11 PM >> To: sip@ietf.org; mmusic@ietf.org >> Subject: RE: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP >>=20 >>=20 >> The applications that have need for SIP and RTSP features I >> can imagine are: >>=20 >> - Voice&video mail (similar to 'sipum' but VM server is in >> the SIP phone) >> - Personal broadcast station from my PC at home. >> - Watching video recorded with VCR at home or office from remote... >>=20 >> What I am not sure is if RTSP has any solution or a framework for a >> RTSP server behind a NAT. If not, the solution is likely to >> be a repeat >> of what SIP provides. I thought TURN could be used in order >> for signaling >> message to reach RTSP server behind a NAT, but I noticed that >> it is not=20 >> applicable (purposefully) for a server running behind a NAT because of >> a security consideration. Lots of issues for RTSP in this area alone? >>=20 >> I believe a lot of people are interested in this discussion. >>=20 >> Best regards, >> Yutaka >>=20 >>=20 >>> -----Original Message----- >>> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >>> Sent: Wednesday, July 09, 2003 5:53 AM >>> To: Pianigiani, Jacopo (Jacopo) >>> Cc: sip@ietf.org; mmusic@ietf.org >>> Subject: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP >>>=20 >>>=20 >>> Hi, >>>=20 >>> When it comes to IMS and 3G terminals, most will already >>> before having=20 >>> an IMS functionality have support for PSS. PSS is >>> Packet-based Streaming >>> Service which is an umbrella kind of standard for streaming service >>> defined in 3GPP targeted at low bit-rates and mobile networks. >>> Specification available from Rel 4 in TS 26.233 and TS >>> 26.234. Already >>> today there exist GSM/GPRS phones that has a PSS client. >>>=20 >>> So I think that dual stack implementations will not be that >>> impossible=20 >>> to foresee. >>>=20 >>> However I think the main issue in this discussion is to >> look at what=20 >>> applications that has need for SIP-RTSP interactions. Based >>> on this we=20 >>> can see if there is solutions easily available or not. >>>=20 >>> I can agree with Rosenberg that if we where going to design a RTSP >>> functionality protocol today, looking at SIP for session >>> establishment=20 >>> would be interesting. However that opportunity has passed >> as RTSP has=20 >>> started to be deployed in increasing numbers. I think even >> the latest=20 >>> Windows media player does support RTSP. >>>=20 >>>=20 >>> Best Regards >>>=20 >>> Magnus Westerlund >>>=20 >>>=20 >>> Pianigiani, Jacopo (Jacopo) wrote: >>>> Hello all, >>>> In my undertanding RTSP is suitable for broadcast, unicast >>> or multicast streams distribution. The RTSP protocol was >>> ideated for typical content delivery, and in effect for this >>> application could be more than suitable. But referring to an >>> IMS domain, in my point of view adopting RSTP as media >>> streams control, would imply adopting at least a double >>> protocol stack in the terminal equipment. The IMS concept was >>> mainly driven by the concept - in my understanding - of >>> simplifying the terminal (making it simpler from a protocol >>> stack implementation means lowering costs and increasing >>> penetration on the market) by adopting a single protocol >>> stack in the terminal, and having the RAN and the core >>> evolving toward a unified transport mechanism for which an >>> almost unified level of control on the network resources >>> allocated to a session (whatever session we refer to, voice , >>> multimedia p-t-t call, web browsing, multimedia session with >>> voice call and dynamic web pages). >>>> So in this sense, my understanding is that the RTSP could >>> be suitable for media content, but it would imply again new >>> complexity on the IMS UMTS/CDMA terminal itself, which is >>> against the idea of IMS of enhancing the services the user >>> can access by having an homogeneous protocol stack on the >>> terminal itself for all types of services. >>>>=20 >>>> After all, the RTSP , apart from content delivery (of >>> streams), could not definitely handle appropriately sessions >>> like Voice calls + Interactive Web Pages. >>>> Regards >>>>=20 >>>> Jacopo Pianigiani >>>> Lucent Technologies - Italy >>>> =E839 335 7350536 >>>>=20 >>>> -----Original Message----- >>>> From: Paolo Asprino [mailto:asprino@coritel.it] >>>> Sent: Wednesday, July 09, 2003 9:40 AM >>>> To: NAKAMURA, Hidefumi; sip@ietf.org; mmusic@ietf.org >>>> Subject: Re: [Sip] Appropriate usage of SIP and RTSP >>>>=20 >>>>=20 >>>> Hi all >>>>=20 >>>> I'm thinking a solution to join SIP and RTSP in the 3G IMS domain. >>>> In particular in the IMS, I think that to provide multilmedia >>>> service (i.e video on demand), one can estabilish a >>> subscription to the service by SIP and then activate the >>> service with RTSP by DIGEST autentication with the >>>> parameters exchanged early during the subscription >>> (username and password) >>>>=20 >>>> What do you think about that? >>>>=20 >>>> Best Regards=20 >>>>=20 >>>> ----- Original Message ----- >>>> From: "NAKAMURA, Hidefumi" >>>> To: ; >>>> Cc: >>>> Sent: Monday, July 07, 2003 9:49 AM >>>> Subject: [Sip] Appropriate usage of SIP and RTSP >>>>=20 >>>>=20 >>>>=20 >>>>> Hi, all. >>>>>=20 >>>>> I have a question about the relationship between SIP and RTSP. >>>>>=20 >>>>> In RFC3261, there is a description that says >>>>> "SIP is not a vertically integrated communications >>> system. SIP is >>>>> rather a component that can be used with other IETF >> protocols to >>>>> build a complete multimedia architecture. Typically, these >>>>> architectures will include protocols such as the >>> Real-time Transport >>>>> Protocol (RTP) (RFC 1889 [28]) for transporting >>> real-time data and >>>>> providing QoS feedback, the Real-Time streaming protocol >>> (RTSP) (RFC >>>>> 2326 [29]) for controlling delivery of streaming media, ..." >>>>> (RFC3261 Section 2) >>>>>=20 >>>>> However, my understanding is that both SIP and RTSP have >>> the capability >>>>> for "discovery of UAs or media streams." >>>>> If I use SIP to establish a stream session and use RTSP to control >>>>> the stream, there will be redundant sequences, i.e. >>> INVITE-OK-ACK and >>>>> SETUP-OK. >>>>>=20 >>>>> Was there any discussion on how to use these two protocols >>> appropriately? >>>>>=20 >>>>> With SIP application server, network providers can provide various >>>>> services on contents delivery while we will not be able to >>> do so only >>>>> with RTSP, I think. On the other hand, RTSP has enough >>> capability for >>>>> discovery of media streams and for negotiation of SDPs. >>>>> So, I think, for the simple delivery of contents, RTSP is >>> appropriate to >>>>> use, and for various session control services regarding contents >>>>> delivery, SIP with RTSP is appropriate to use. >>>>>=20 >>>>> Any opinions? >>>>>=20 >>>>> I wonder why no contents delivery server seems to prepare >>> SIP stack now.=20 >>>>> Is it because, up to now, there exists only a simple >>> contents delivery >>>>> service? >>>>>=20 >>>>> best regards, >>>>>=20 >>>>> --=20 >>>>> NAKAMURA, Hidefumi >>>>> NTT ServiceIntegration /NetworkServiceSystems Labs. >>>>> tel: +81(422)59 3904; fax:+81(422)60 4012 >>>>> --- >>>>>=20 >>>>>=20 >>>>>=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 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> --- >>>> Outgoing mail is certified Virus Free. >>>> Checked by AVG anti-virus system (http://www.grisoft.com). >>>> Version: 6.0.495 / Virus Database: 294 - Release Date: >>> 30/06/2003J*fj)bz b=B2=D8m=B6>?=FF=0C> > 0=D6'=AD~S=E0=FEf=A2-f=A7=FEX=AC=B6)=DF=A3=FB"=A58b=B2X=AC=B6+=1F=A2=B3DY=D7=AF >>> zZ)(tm)=E9=ED=A1=FBay=CA+y"=0F>=BA-=A1=CA%R=C7=ACS~=A6=A6W=A6z{h=AE=C7,r?n(tm)=B8sy=DBY=A2=BA=AEz=CBb=A2{(=9D=CB=AB >>> =AD=E9=ED=B2*T=B1=EB"=A6~=A7''=AD~S=E0~S=E7{=07^=BD=E9h=A6g=A7=B6=CA'=B6=17s=A6(tm)bq=ABb=A2z=1F >>>>=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 >>>>=20 >>>=20 >>>=20 >>> --=20 >>>=20 >>> Magnus Westerlund >>>=20 >>> Multimedia Technologies, Ericsson Research EAB/TVA/A >>>=20 >> ---------------------------------------------------------------------- >>> Ericsson AB | Phone +46 8 4048287 >>> Torshamsgatan 23 | Fax +46 8 7575550 >>> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >>>=20 >>>=20 >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mmusic >>>=20 >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic >>=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=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 From exim@www1.ietf.org Mon Jul 14 05:20:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03454 for ; Mon, 14 Jul 2003 05:20:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bzVC-0005iU-Ct for sip-archive@odin.ietf.org; Mon, 14 Jul 2003 05:20:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6E9KAZV021946 for sip-archive@odin.ietf.org; Mon, 14 Jul 2003 05:20:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bzU5-0005O8-Qo; Mon, 14 Jul 2003 05:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bzT7-0005NI-T8 for sip@optimus.ietf.org; Mon, 14 Jul 2003 05:18: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 FAA03332 for ; Mon, 14 Jul 2003 05:17:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bzT4-0003Dk-00 for sip@ietf.org; Mon, 14 Jul 2003 05:17:58 -0400 Received: from mail1.telekom.de ([62.225.183.202]) by ietf-mx with esmtp (Exim 4.12) id 19bzT2-0003DS-00 for sip@ietf.org; Mon, 14 Jul 2003 05:17:57 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 14 Jul 2003 09:53:24 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id <37AYYHD3>; Mon, 14 Jul 2003 09:53:20 +0200 Message-Id: <953B9B08F98DD61183F8000347AE660102862B1E@G8PPV.blf01.telekom.de> From: "Jesske, R" To: gonzalo.camarillo@ericsson.com Cc: sip@ietf.org Date: Mon, 14 Jul 2003 09:53:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Reason Header RFC 3326 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 Gonzalo et all, I have a question with regard to the Reason Header RFC3326. In RFC 3326 the Reason header includes a reason-text parameter element. In combination with the Q.850 Cause Value which text should be in the "reason-text" parameter? Should it be the Q.850 definition text or could it be something else? Best Regards Roland Deutsche Telekom AG T Com Zentrale Roland Jesske, T38-12 Section T38; Signalling, Gateways and Switching Systems Am Kavalleriesand 3, 64295 Darmstadt, Germany Phone: +49 6151 83-5940 Fax: +49 6151 83-4577 email: r.jesske@telekom.de _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 14 06:00:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04598 for ; Mon, 14 Jul 2003 06:00:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c083-00077h-H7 for sip-archive@odin.ietf.org; Mon, 14 Jul 2003 06:00:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EA0JLj027317 for sip-archive@odin.ietf.org; Mon, 14 Jul 2003 06:00:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c07o-00075c-Qp; Mon, 14 Jul 2003 06:00:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMDh-0005Ld-Tg for sip@optimus.ietf.org; Wed, 09 Jul 2003 17:11: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 RAA22444; Wed, 9 Jul 2003 17:11:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aMDf-0003Y4-00; Wed, 09 Jul 2003 17:11:19 -0400 Received: from mxsmta02.inithost.com ([209.235.30.104] helo=mxsmta02.dellhost.com) by ietf-mx with esmtp (Exim 4.12) id 19aMDe-0003Xv-00; Wed, 09 Jul 2003 17:11:18 -0400 Received: from garbagedump.com ([24.128.102.183]) by mxsmta02.dellhost.com (InterMail vM.5.01.03.06 201-253-122-118-106-20010523) with ESMTP id <20030709210916.MEGY7659.mxsmta02.dellhost.com@garbagedump.com>; Wed, 9 Jul 2003 17:09:16 -0400 Message-ID: <3F0C84FC.6070000@garbagedump.com> Date: Wed, 09 Jul 2003 17:11:24 -0400 From: "C. Wegrzyn" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a; MultiZilla v1.4.0.4A) Gecko/20030612 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jiri Kuthan CC: sip@ietf.org, sipping@ietf.org References: <5.2.0.9.0.20030709222843.0307c5f8@localhost> In-Reply-To: <5.2.0.9.0.20030709222843.0307c5f8@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Sipping] text conferencing at ietf57 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org 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 don't see anything at the provided URL. Chuck Wegrzyn Jiri Kuthan wrote: >FYI: there is a sip2jabber service that connects SIP users to jabber chat rooms >in the upcoming IETF meeting. More information can be found >at http://www.iptel.org/ietf54/ > >-jiri > >-- >Jiri Kuthan http://iptel.org/~jiri/ > > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 14 06:00:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04613 for ; Mon, 14 Jul 2003 06:00:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c083-00077I-I7 for sip-archive@odin.ietf.org; Mon, 14 Jul 2003 06:00:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EA0JC9027318 for sip-archive@odin.ietf.org; Mon, 14 Jul 2003 06:00:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c07n-00075S-5G; Mon, 14 Jul 2003 06:00:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aJPN-0000gq-Ra for sip@optimus.ietf.org; Wed, 09 Jul 2003 14:11: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 OAA12615; Wed, 9 Jul 2003 14:11:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aJPL-0001Qh-00; Wed, 09 Jul 2003 14:11:11 -0400 Received: from 67.105.118.114.ptr.us.xo.net ([67.105.118.114] helo=mail.kmerl.com) by ietf-mx with esmtp (Exim 4.12) id 19aJPK-0001QZ-00; Wed, 09 Jul 2003 14:11:10 -0400 content-class: urn:content-classes:message Subject: RE: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 9 Jul 2003 11:10:39 -0700 Message-ID: Thread-Topic: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP Thread-Index: AcNGLV4de+FJnurnRWaKHIBOOZMeaQAEiCBA From: "Yutaka Takeda" To: , 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 The applications that have need for SIP and RTSP features I can imagine are: - Voice&video mail (similar to 'sipum' but VM server is in the SIP = phone) - Personal broadcast station from my PC at home. - Watching video recorded with VCR at home or office from remote... What I am not sure is if RTSP has any solution or a framework for a RTSP server behind a NAT. If not, the solution is likely to be a repeat of what SIP provides. I thought TURN could be used in order for = signaling message to reach RTSP server behind a NAT, but I noticed that it is not=20 applicable (purposefully) for a server running behind a NAT because of a security consideration. Lots of issues for RTSP in this area alone? I believe a lot of people are interested in this discussion. Best regards, Yutaka > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Wednesday, July 09, 2003 5:53 AM > To: Pianigiani, Jacopo (Jacopo) > Cc: sip@ietf.org; mmusic@ietf.org > Subject: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP >=20 >=20 > Hi, >=20 > When it comes to IMS and 3G terminals, most will already=20 > before having=20 > an IMS functionality have support for PSS. PSS is=20 > Packet-based Streaming=20 > Service which is an umbrella kind of standard for streaming service=20 > defined in 3GPP targeted at low bit-rates and mobile networks.=20 > Specification available from Rel 4 in TS 26.233 and TS=20 > 26.234. Already=20 > today there exist GSM/GPRS phones that has a PSS client. >=20 > So I think that dual stack implementations will not be that=20 > impossible=20 > to foresee. >=20 > However I think the main issue in this discussion is to look at what=20 > applications that has need for SIP-RTSP interactions. Based=20 > on this we=20 > can see if there is solutions easily available or not. >=20 > I can agree with Rosenberg that if we where going to design a RTSP=20 > functionality protocol today, looking at SIP for session=20 > establishment=20 > would be interesting. However that opportunity has passed as RTSP has=20 > started to be deployed in increasing numbers. I think even the latest=20 > Windows media player does support RTSP. >=20 >=20 > Best Regards >=20 > Magnus Westerlund >=20 >=20 > Pianigiani, Jacopo (Jacopo) wrote: > > Hello all, > > In my undertanding RTSP is suitable for broadcast, unicast=20 > or multicast streams distribution. The RTSP protocol was=20 > ideated for typical content delivery, and in effect for this=20 > application could be more than suitable. But referring to an=20 > IMS domain, in my point of view adopting RSTP as media=20 > streams control, would imply adopting at least a double=20 > protocol stack in the terminal equipment. The IMS concept was=20 > mainly driven by the concept - in my understanding - of=20 > simplifying the terminal (making it simpler from a protocol=20 > stack implementation means lowering costs and increasing=20 > penetration on the market) by adopting a single protocol=20 > stack in the terminal, and having the RAN and the core=20 > evolving toward a unified transport mechanism for which an=20 > almost unified level of control on the network resources=20 > allocated to a session (whatever session we refer to, voice ,=20 > multimedia p-t-t call, web browsing, multimedia session with=20 > voice call and dynamic web pages). > > So in this sense, my understanding is that the RTSP could=20 > be suitable for media content, but it would imply again new=20 > complexity on the IMS UMTS/CDMA terminal itself, which is=20 > against the idea of IMS of enhancing the services the user=20 > can access by having an homogeneous protocol stack on the=20 > terminal itself for all types of services. > >=20 > > After all, the RTSP , apart from content delivery (of=20 > streams), could not definitely handle appropriately sessions=20 > like Voice calls + Interactive Web Pages.=20 > > Regards > >=20 > > Jacopo Pianigiani > > Lucent Technologies - Italy > > =E839 335 7350536 > >=20 > > -----Original Message----- > > From: Paolo Asprino [mailto:asprino@coritel.it] > > Sent: Wednesday, July 09, 2003 9:40 AM > > To: NAKAMURA, Hidefumi; sip@ietf.org; mmusic@ietf.org > > Subject: Re: [Sip] Appropriate usage of SIP and RTSP > >=20 > >=20 > > Hi all > >=20 > > I'm thinking a solution to join SIP and RTSP in the 3G IMS domain. > > In particular in the IMS, I think that to provide multilmedia > > service (i.e video on demand), one can estabilish a=20 > subscription to the service by SIP and then activate the=20 > service with RTSP by DIGEST autentication with the=20 > > parameters exchanged early during the subscription=20 > (username and password)=20 > >=20 > > What do you think about that? > >=20 > > Best Regards=20 > >=20 > > ----- Original Message -----=20 > > From: "NAKAMURA, Hidefumi" > > To: ; > > Cc: > > Sent: Monday, July 07, 2003 9:49 AM > > Subject: [Sip] Appropriate usage of SIP and RTSP > >=20 > >=20 > >=20 > >>Hi, all. > >> > >>I have a question about the relationship between SIP and RTSP.=20 > >> > >>In RFC3261, there is a description that says=20 > >> "SIP is not a vertically integrated communications=20 > system. SIP is > >> rather a component that can be used with other IETF protocols to > >> build a complete multimedia architecture. Typically, these > >> architectures will include protocols such as the=20 > Real-time Transport > >> Protocol (RTP) (RFC 1889 [28]) for transporting=20 > real-time data and > >> providing QoS feedback, the Real-Time streaming protocol=20 > (RTSP) (RFC > >> 2326 [29]) for controlling delivery of streaming media, ..." > >> (RFC3261 Section 2) > >> > >>However, my understanding is that both SIP and RTSP have=20 > the capability > >>for "discovery of UAs or media streams." > >>If I use SIP to establish a stream session and use RTSP to control > >>the stream, there will be redundant sequences, i.e.=20 > INVITE-OK-ACK and > >>SETUP-OK. > >> > >>Was there any discussion on how to use these two protocols=20 > appropriately? > >> > >>With SIP application server, network providers can provide various > >>services on contents delivery while we will not be able to=20 > do so only > >>with RTSP, I think. On the other hand, RTSP has enough=20 > capability for > >>discovery of media streams and for negotiation of SDPs. > >>So, I think, for the simple delivery of contents, RTSP is=20 > appropriate to > >>use, and for various session control services regarding contents > >>delivery, SIP with RTSP is appropriate to use. > >> > >>Any opinions? > >> > >>I wonder why no contents delivery server seems to prepare=20 > SIP stack now.=20 > >>Is it because, up to now, there exists only a simple=20 > contents delivery > >>service? > >> > >>best regards, > >> > >>--=20 > >>NAKAMURA, Hidefumi=20 > >>NTT ServiceIntegration /NetworkServiceSystems Labs. > >>tel: +81(422)59 3904; fax:+81(422)60 4012 > >>--- > >> > >> > >> > >>_______________________________________________ > >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>This list is for NEW development of the core SIP Protocol > >>Use sip-implementors@cs.columbia.edu for questions on current sip > >>Use sipping@ietf.org for new developments on the application of sip > >> > >=20 > >=20 > >=20 > > --- > > Outgoing mail is certified Virus Free. > > Checked by AVG anti-virus system (http://www.grisoft.com). > > Version: 6.0.495 / Virus Database: 294 - Release Date:=20 > 30/06/2003J*fj)bz b=B2=D8m=B6>?=FF=0C> = 0=D6'=AD~S=E0=FEf=A2-f=A7=FEX=AC=B6)=DF=A3=FB"=A58b=B2X=AC=B6+=1F=A2=B3DY= =D7=AF > = zZ)(tm)=E9=ED=A1=FBay=CA+y"=0F>=BA-=A1=CA%R=C7=ACS~=A6=A6W=A6z{h=AE=C7,r?= n(tm)=B8sy=DBY=A2=BA=AEz=CBb=A2{(=9D=CB=AB > = =AD=E9=ED=B2*T=B1=EB"=A6~=A7''=AD~S=E0~S=E7{=07^=BD=E9h=A6g=A7=B6=CA'=B6=17= s=A6(tm)bq=ABb=A2z=1F > >=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 > >=20 >=20 >=20 > --=20 >=20 > Magnus Westerlund >=20 > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=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 From exim@www1.ietf.org Wed Jul 16 02:53:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17291 for ; Wed, 16 Jul 2003 02:53:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cg9a-0004DG-60 for sip-archive@odin.ietf.org; Wed, 16 Jul 2003 02:52:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G6qgh7016193 for sip-archive@odin.ietf.org; Wed, 16 Jul 2003 02:52:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cg8z-0003vT-Ng; Wed, 16 Jul 2003 02:52:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cg8b-0003rz-69 for sip@optimus.ietf.org; Wed, 16 Jul 2003 02:51: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 CAA17155 for ; Wed, 16 Jul 2003 02:51:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cg8X-0003f8-00 for sip@ietf.org; Wed, 16 Jul 2003 02:51:37 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19cg8M-0003eo-00 for sip@ietf.org; Wed, 16 Jul 2003 02:51:26 -0400 Received: from dynamicsoft.com ([63.113.46.64]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6G6omiB010718 for ; Wed, 16 Jul 2003 02:50:49 -0400 (EDT) Message-ID: <3F14A336.7040504@dynamicsoft.com> Date: Tue, 15 Jul 2003 20:58:30 -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: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] comments on history-info-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mary, Here are some comments on history-info. I suspect many apply to prior versions as well. My apologies if they have been discussed, I have not really followed the work closely. Many of my comments are asking for much more precision in the document. Generally, I found it to be very imprecise, with lots of undefined terminology and vague procedures. That aside, I have some major issues with the privacy mechanisms, with the usage of history-info by redirect servers, with sending a 183 with history information, and with the backwards compatibility implications. So, here we go: Firstly, the draft says in many places that applications need to document the impact of things. For example, Section 1.1 says: Thus, it is highly recommended that all applications making use of the request history information clearly define the impact of the information not being available and specify the processing of such a request. Does this mean there is some kind of application registry where such documentation will exist? Does it mean that applications won't be interoperable because they will depend on the presence of these headers? The text in 1.1 makes it sound like the information would only be present if some local policy prevented its insertion. What about cases where the proxy doesn't support it? Even if it does, your draft reads very much like it is now going to require every proxy to insert this header. Is that so? Second, section 1.3 talks about the use of the Privacy header. There are a few problems here. First, the privacy header gets stripped once the privacy service finishes execution. Thus, a downstream proxy would not be able to know privacy was requested. To a large degree, this is because the privacy header in a request is about privacy of the caller. Request history is about the current target (i.e., called party). So, in fact, the issue is that if the *called* party requests privacy (using a privacy header in a response), the history info headers should not be propagated backwards in a response. I dont think your draft does that. Local policy might also play a role, when it is representing the privacy interests of a user that is retargeting. In that case, it was unclear to me how the proxy prevents downstream elements from inserting history-info? Your draft makes it sound like the privacy requirements are met if just this one hop avoids insertion. But seeing the contact from downstream retargets will often reveal sensitive information about a target further upstream. Section 2.1: > Targeted-to-URI: the Request URI captured as the Request is > targeted. By capturing a copy of the Request URI in the initial > request, the Retargeted-from-URI is already captured when a > request is retargeted and the Retargeted-to-URI is being > captured. > I read this many times and could not make sense of it. What does it mean? Section 2.3.1: > The UAC SHOULD include the HistInfo option tag in the Supported > header in any request not associated with an established dialog for > which the UAC would like the History-Info in the Response. In > addition, the UAC should initiate the capturing of the History > Information by capturing the Request-URI as the hi-targeted-to-uri > and initializing the index to 1. What if the UAC doesn't support this extension? Can the UAS get history info? My understanding is that most, if not all, evnisioned applications were for the UAS. This means the UAS can't get information unless the caller and many, if not all, proxies along the path support it. Section 2.3.2: > The processing of History-Info by a UAS in a Request depends upon > local policy and specific applications at the UAS which might make > use of the information. If the HistInfo option tag is received in a > request, the UAS should include any History-Info received in the > request in the subsequent response. I think you mean SHOULD in the last sentence. Also, I think you mean that "If the request contained the histinfo option tag in the Supported header field of the request, the UAS....". Also, you've capitalized the H and I in HistInfo. Please don't. Option tags are not case sensitive. Section 2.3.3: The wording about when to capture is really vague. You need to be much more precise in your wording of when the proxy is and isnt going to capture history information. Section 2.3.3.1: > If the proxy supports History-Info, the proxy SHOULD add any History- > Info collected as it retargets a Request. For retargets that are the > result of an explicit SIP response, the SIP Response Code that > triggered the retargeting MUST be included in the Reason header of > the Targeted-to-URI. This needs to be more precise. What does it mean "..collected as it retargets a request"? How is this information collected? Also, when you say "explicit SIP response" - all responses are explicit as far as I know. Perhaps you mean when a 3xx response is received? Also, you say "Reason header of the Targeted-to-URI". I believe reason is a parameter, not a header, in this instance. and then: > For retargets as a result of timeouts or > internal events, a Reason header MAY be included in the Reason header > of the Targeted-to-URI. what are internal events? What value does the reason parameter have in the case of timeout? In the case of internal events? and then: > Additionally, if a request is received that doesn't include a > captured Request URI from the previous entity, the proxy MAY add an > additional entry, effectively capturing the retargeted-from-URI in > the Request. What does it mean for a request to "not include a captured Request-URI"? You need to define that. What is contained in the additional entry? I may sound like I am being nit-picky, but in my experience specifications need to be very precise in what you want people to do. I am confused about what is implied here, and I would imagine many others would be confused too. and then: > In order to maintain ordering and accurately reflect the nesting and > retargeting of the request, an index MUST be included along with the > Targeted-to-URI being captured. The basic rule for adding the index > are to read the value from the previous History-Info, if available, > and capture the index.n as the index for the History-Info being > captured, where n would typically be 1 for a forwarded request. Thus, > the level of nesting of the index reflects the number of hops. define previous. what does it mean to "capture the index.n"? what is index? what is .n? You say its "typically 1". When is it 1, and when is it not one? and then: > For > retargets within a proxy, the proxy MUST maintain the current level > of nesting by incrementing the lowest/last digit of the index for > each instance of retargeting, thus reflecting the number of retargets > within the proxy. I cannot understand this at all. and then: > n index MUST NOT be added > in the scenario whereby the received request had no History-Info > header and the retargeted-from-URI is being captured for > completeness. what does "for completeness" mean? You need to be precise. > The lack of Reason headers in the captured Request-URIs should be > indicative of the parallel nature of forking (i.e the Request-URIs > are not the result of retargets, but are rather all simultaneous > Targeted-To URIs.) should be indicative? Is it, or isnt it? > A proxy that receives a Request with the HistInfo option tag in the > Supported header, and depending upon a local policy supporting the > capture of History-Info, SHOULD return captured History-Info in > subsequent, provisional and final responses to the Request. A 183 > response MAY be sent explicitly for the purposes of conveying > History-Info prior to the final response. I think the first sentence means that the proxy does nothing to responses - any history-info in those responses is just passed on. But I'm not sure. The sentence says "should return", and return seems like an active operation to me. The next sentence actually implies that the proxy generate a 183 provisional responses. This means that a UA making a call with N proxies will get N extra provisional responses, where the first has one history-info value, the next 2, the next 3, and so on. The first history info is transmitted to the UAC N times. Is that really what we want? It seems very expensive for the UAC. > It MAY be advantageous for redirect servers to support the receipt of > History-Info in requests. You can you assign a protocol strength to being advantageous? I think you mean "A redirect server MAY use information in the History-Info header field in a request to determine the URIs that it will retarget to.". > By receiving it in the request, the > Redirect Server MAY be able to optimize the information it sends in > responses by looking at the already targeted-to-URIs. and what optimization is that? I think you mean that the redirect server shouldnt redirect to somewhere that the request has already visited. If so, please say that. However, are we sure about that? Redirection to a URI already visited can be appropriate in cases where there is a spiral, and not a loop. Unless a redirect server is maintaining state, how can it make this determiantionabout whether this is a spiral or a loop? > HistInfo When used with the Supported header, [RFCXXXX] > this option tag indicates support > for the History Information to be > captured for requests and returned in > subsequent responses. This tag is not > used in a Proxy-Require or Requires > header field since support of > History-Info is optional. Require header field, not Requires. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer 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 Wed Jul 16 04:18:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20491 for ; Wed, 16 Jul 2003 04:18:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19chUW-0001Pf-6y for sip-archive@odin.ietf.org; Wed, 16 Jul 2003 04:18:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G8IOI7005377 for sip-archive@odin.ietf.org; Wed, 16 Jul 2003 04:18:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19chUC-0001Nx-Id; Wed, 16 Jul 2003 04:18:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19chTO-0001NJ-FI for sip@optimus.ietf.org; Wed, 16 Jul 2003 04:17: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 EAA20462 for ; Wed, 16 Jul 2003 04:17:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19chTK-0004V1-00 for sip@ietf.org; Wed, 16 Jul 2003 04:17:10 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19chTA-0004Uq-00 for sip@ietf.org; Wed, 16 Jul 2003 04:17:00 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 16 Jul 2003 01:20:33 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6G8Fv8B008967 for ; Wed, 16 Jul 2003 01:15:59 -0700 (PDT) Received: from ORANLT.ietf57.telekom.at (rtp-vpn2-23.cisco.com [10.82.240.23]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGC04701; Wed, 16 Jul 2003 01:15:56 -0700 (PDT) Date: Wed, 16 Jul 2003 04:15:54 -0400 From: "David R. Oran" To: sip@ietf.org Message-ID: <136171394.1058328954@ORANLT.ietf57.telekom.at> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [Sip] Treatment of q values on contacts returned in redirects Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The proposal Jonathan made on this is to effectively replace the contact that returned the redirect with the contacts in the redirect, and then try them in the order of their q values - essentially a depth-first search. In the SIP meeting, I questioned that this was too restrictive and that there was no need to actually mandate that behavior. That is one possibility, but not the only one. As an alternative, what one could do is to go back the the original set of registered contacts, eliminate the ones already tried and the one that returned the redirect, add the ones in the redirect response and treat them as if they were directly registered contacts for the AoR. You throw away the results of the current caller-prefs calculation, and rerun it from scratch on this set of contacts. Why is this alternative needed? Imagine a contact which does "Call forward no answer" by timing out an alert state and sends back a redirect to some random place before the upstream proxy gives up. What if the callee's policy is to try other of his registered contacts first before inviting to a CFNA number returned by a contact? Sorry for the terseness of this - wanted to get this out right away before I forget what the issue is. Dave. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 16 06:21:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24204 for ; Wed, 16 Jul 2003 06:21:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cjPU-0008IJ-QU for sip-archive@odin.ietf.org; Wed, 16 Jul 2003 06:21:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GALKrL031829 for sip-archive@odin.ietf.org; Wed, 16 Jul 2003 06:21:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cjPC-0008Gr-8e; Wed, 16 Jul 2003 06:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cjOC-0008CM-Q1 for sip@optimus.ietf.org; Wed, 16 Jul 2003 06:20:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24165 for ; Wed, 16 Jul 2003 06:19:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cjO8-0005X1-00 for sip@ietf.org; Wed, 16 Jul 2003 06:19:57 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19cjNy-0005WC-00 for sip@ietf.org; Wed, 16 Jul 2003 06:19:46 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Wed, 16 Jul 2003 11:22:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 16 Jul 2003 11:18:20 +0100 Message-ID: <45730E094814E44488F789C1CDED27AE0219B039@gbnewp0758m.eu.ubiquity.net> Thread-Topic: draft-ietf-sip-resource-priority-00.txt Thread-Index: AcNLg5TCH3VTjHKmTCyfaQqzZun7og== From: "Chris Boulton" To: Cc: Content-Transfer-Encoding: base64 Subject: [Sip] 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: , Content-Transfer-Encoding: base64 SGVubmluZywNCiANCiAgICAgICAgICAgIEkgcmV2aWV3ZWQgdGhpcyBmb3IgdGhlIElFVEYgU0lQ IG1lZXRpbmcgYW5kIGhhZCBqdXN0IGEgc21hbGwgb2JzZXJ2YXRpb24uICBUaGUgdXNlIG9mIHRo ZSAnVVBEQVRFJyBtZXRob2QgaXMgbWVudGlvbmVkIGFzIGEgc3VwcG9ydGVkIG1ldGhvZCAoNC4x KSwgeWV0IGl0IGRvZXMgbm90IGFwcGVhciBpbiB0aGUgdGFibGUgaW4gc2VjdGlvbiAzLCBhcyBh IHN1cHBvcnRlZCBtZXRob2QuDQogDQpSZWdhcmRzLA0KIA0KQ2hyaXMuDQogDQo= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 16 07:52:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26660 for ; Wed, 16 Jul 2003 07:52:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ckpN-0005gd-N0 for sip-archive@odin.ietf.org; Wed, 16 Jul 2003 07:52:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GBq9Nb021844 for sip-archive@odin.ietf.org; Wed, 16 Jul 2003 07:52:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ckpF-0005fm-Tt; Wed, 16 Jul 2003 07: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 19ckp9-0005fY-Gh for sip@optimus.ietf.org; Wed, 16 Jul 2003 07:51:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26648 for ; Wed, 16 Jul 2003 07:51:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ckp8-0006Kd-00 for sip@ietf.org; Wed, 16 Jul 2003 07:51:54 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19ckoy-0006KO-00 for sip@ietf.org; Wed, 16 Jul 2003 07:51:44 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 16 Jul 2003 04:50:38 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6GBp689016574; Wed, 16 Jul 2003 04:51:07 -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.6-GR) with ESMTP id AJF29545; Wed, 16 Jul 2003 04:48:05 -0700 (PDT) Date: Wed, 16 Jul 2003 04:52:00 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Jonathan Rosenberg , Dean Willis , rohan@cisco.com To: sip@ietf.org From: Rohan Mahy Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Sip] Comment Period on Callee Capabilities Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org 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, After the split between caller preferences and callee capabilities, we need to have a short review period on the callee capabilities draft (draft-ietf-sip-callee-caps-00.txt). This draft has already been through detailed review and 2 WGLCs as part of its original parent document, but we want to make sure that the draft holds together in its present form. There will be a separate thread (Jonathan will start this thread) about the possibility of adding a device-id to the draft. Please send your comments to the sip list or to authors. This comment period will close on Friday August 1st. Barring catastrophe, the chairs would like to send this document to the IESG shortly after the review period expires, as many other documents (including several documents in other working groups (IPTEL, SIMPLE, SIPPING)) depend on this document. many thanks, -rohan co-chair SIP and SIPPING _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 16 09:21:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28997 for ; Wed, 16 Jul 2003 09:21:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cmDV-00023j-5i for sip-archive@odin.ietf.org; Wed, 16 Jul 2003 09:21:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GDL9SO007906 for sip-archive@odin.ietf.org; Wed, 16 Jul 2003 09:21:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cmDO-00022Q-2p; Wed, 16 Jul 2003 09:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cmCp-00021w-1H for sip@optimus.ietf.org; Wed, 16 Jul 2003 09:20: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 JAA28966 for ; Wed, 16 Jul 2003 09:20:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cmCn-0006yN-00 for sip@ietf.org; Wed, 16 Jul 2003 09:20:25 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 19cmCc-0006y0-00 for sip@ietf.org; Wed, 16 Jul 2003 09:20:14 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.9/8.12.9) with ESMTP id h6GDJNAP026136; Wed, 16 Jul 2003 08:19:24 -0500 (CDT) Received: from lmf.ericsson.se (sealwa04-244.sw.ericsson.se [130.100.249.244]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 317299D2; Wed, 16 Jul 2003 08:19:01 -0500 Message-ID: <3F1550CE.A03A3172@lmf.ericsson.se> Date: Wed, 16 Jul 2003 16:19:10 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Jesske, R" CC: gonzalo.camarillo@ericsson.com, sip@ietf.org References: <953B9B08F98DD61183F8000347AE660102862B1E@G8PPV.blf01.telekom.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Reason Header RFC 3326 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org 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 Like the reason text in SIP responses, the reason text is intened for human consumption. Therefore, you can put whatever you want there. Gonzalo "Jesske, R" wrote: > > Hi Gonzalo et all, > I have a question with regard to the Reason Header RFC3326. > In RFC 3326 the Reason header includes a reason-text parameter element. In combination with the Q.850 Cause Value which text should be in the "reason-text" parameter? > Should it be the Q.850 definition text or could it be something else? > > Best Regards > > Roland > > Deutsche Telekom AG > T Com Zentrale > Roland Jesske, T38-12 > Section T38; Signalling, Gateways and Switching Systems > Am Kavalleriesand 3, 64295 Darmstadt, Germany > Phone: +49 6151 83-5940 > Fax: +49 6151 83-4577 > email: r.jesske@telekom.de -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Jul 16 09:40:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29710 for ; Wed, 16 Jul 2003 09:40:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cmVv-0003Al-Bz for sip-archive@odin.ietf.org; Wed, 16 Jul 2003 09:40:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GDeBZn012144 for sip-archive@odin.ietf.org; Wed, 16 Jul 2003 09:40:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cmVm-00039Q-Qx; Wed, 16 Jul 2003 09:40:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cmVA-00036h-Kw for sip@optimus.ietf.org; Wed, 16 Jul 2003 09:39:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29675 for ; Wed, 16 Jul 2003 09:39:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cmV8-0007AU-00 for sip@ietf.org; Wed, 16 Jul 2003 09:39:22 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 19cmUx-0007AR-00 for sip@ietf.org; Wed, 16 Jul 2003 09:39:12 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id h6GDcx918425 for ; Wed, 16 Jul 2003 15:38:59 +0200 (MEST) Received: from mchh9ega.mchh.siemens.de (mchh9ega.mchh.siemens.de [139.21.194.56]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id h6GDcxl02267 for ; Wed, 16 Jul 2003 15:38:59 +0200 (MEST) Received: by mchh9ega.mchh.siemens.de with Internet Mail Service (5.5.2653.19) id <3GB5B0R6>; Wed, 16 Jul 2003 15:38:59 +0200 Message-ID: From: Werkstudent8 SAL To: "'sip@ietf.org'" Subject: [SIP] Replaces header and REFER Date: Wed, 16 Jul 2003 15:38:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , From: "Stefan Mecke" Hi all, I have a question about draft-ietf-sip-replaces-03.txt: Section 2 says: ... the Replaces header is frequently used in combination with the REFER [4] method ... but section 3 contains: ... if a Replaces header field is present in a request other than INVITE, the UAS MUST reject the request .. I think it makes a lot of sense to allow replaces with REFER; e.g. in the call park scenario you could have a web page with all call and make a "click to retrieve from park" to have it on your desk phone. And that is similar to what's described in draft-ietf-sipping-cc-transfer-01.txt, although I have a notion that there is some difference but I don't manage to get it out of the draft. Thanks _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed Jul 16 11:19:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05636 for ; Wed, 16 Jul 2003 11:19:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19co3h-00019D-DB for sip-archive@odin.ietf.org; Wed, 16 Jul 2003 11:19:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GFJ9Dw004407 for sip-archive@odin.ietf.org; Wed, 16 Jul 2003 11:19:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19co3Z-00018f-RU; Wed, 16 Jul 2003 11:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19co2v-00018A-HO for sip@optimus.ietf.org; Wed, 16 Jul 2003 11:18: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 LAA05602 for ; Wed, 16 Jul 2003 11:18:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19co2u-0000PL-00 for sip@ietf.org; Wed, 16 Jul 2003 11:18:20 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19co2j-0000P9-00 for sip@ietf.org; Wed, 16 Jul 2003 11:18:09 -0400 Received: from dynamicsoft.com ([63.113.46.64]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h6GFHXiB010925 for ; Wed, 16 Jul 2003 11:17:34 -0400 (EDT) Message-ID: <3F156C87.5070409@dynamicsoft.com> Date: Wed, 16 Jul 2003 11:17:27 -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: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Device ID callee capabilitiy Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, One of the issues I raised today during the meeting was on the utility of the uri-user and uri-domain parameters in draft-ietf-sip-callee-caps. The primary purpose that these serve is a means of identifying a UA instance. In order to accomplish applicaitons like assisted call transfer, a UA would send INVITE to the AOR of the transfer target, and include an Accept-Contact with the uri-user and uri-domain equal to those of the UA instance. Now, it turns out that uri-user and uri-domain are not very helpful when used this way. GRUU is a better approach. However, thats almost a secondary issue. The primary issue is that uri-user and uri-domain are ugly, and they repeat information already in the registration. The suggestion, made by Paul, was to instead define a device-id attribute. This ID would be long lived - burned into firmware of a device, perhaps. It would be included in a registration as a unique ID for the device or software instance, as the case may be. You could use this callee capability attribute for the assisted transfer just as you could use uri-user and uri-domain. It has the same problems that still make GRUU a better solution. However, during the meeting, folks like the idea of a device-id attribute as something useful for lots of other applications. So, I would like to invite comment and discussion on (1) whether you like the idea of replacing the uri-user and uri-domain attributes with device-id (a better name may be needed, like instance-id), (2) what kind of usages you had in mind for it, for good or for evil. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer 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 Thu Jul 17 08:45:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04175 for ; Thu, 17 Jul 2003 08:45:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d88N-00074Y-12 for sip-archive@odin.ietf.org; Thu, 17 Jul 2003 08:45:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HCjJu0027182 for sip-archive@odin.ietf.org; Thu, 17 Jul 2003 08:45:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d886-00073r-P3; Thu, 17 Jul 2003 08: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 19d87I-000734-F3 for sip@optimus.ietf.org; Thu, 17 Jul 2003 08:44: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 IAA04117 for ; Thu, 17 Jul 2003 08:44:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d87H-0005wa-00 for sip@ietf.org; Thu, 17 Jul 2003 08:44:11 -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 19d876-0005vd-00 for sip@ietf.org; Thu, 17 Jul 2003 08:44:00 -0400 Received: from txdwillis (tx-dwillis.ietf57.telekom.at [81.160.170.141] (may be forged)) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h6HCgl2n009906 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 17 Jul 2003 07:42:52 -0500 From: "Dean Willis" To: Cc: , Date: Thu, 17 Jul 2003 07:42:35 -0500 Message-ID: <004a01c34c60$ea2090c0$8daaa051@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] Draft SIP Minutes, IETF 57 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org 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 Please review and send any needed corrections. This text (or revisions thereof) will be maintained at: http://www.softarmor.com/sipwg/meets/ietf57/notes/minutes.html Draft Minutes, SIPWG IETF57 Recorded by Alan Johnston (alan.johnston@mci.com) Edited by Dean Willis (dean.willis@softarmor.com) Revised 17Jul2003 Meeting July 16, 2003, 0900 Start ------- Meeting called to order by chairs. Proposed agenda reviewed and accepted. Announcement: Jon Peterson has retired as SIP co-chair. Brian Rosen volunteered as chat room moderator. Alan Johnston volunteered as scribe. Status of Drafts - Chairs --------------------------------- New Pubs: RFC 3515 REFER published MIB: Volunteers to review a section of MIB: Orit Levin, Mary Barnes, = Cullen Jennings, and Kent (Rohan has his info). Rohan will assign some more volunteers. congest-safe: Proposal for author to remove UDP kludge. No objections = or discussion. PUBLISH - Aki Niemi ------------------------------ Open Issue: collision recovery. Proposed solution: query principle, may subscribe to package. No objections or discussion. Open Issue: PUBLISH and dialogs. Proposed solution: add text about = dialogs, discourage reuse. No objections or discussion. Open Issue: atomicity. Proposed solution: relax restriction about overlapping requests. Comment: Go with a simpler model - all tuples are independent. Solve = using composition and authorization instead of publication. Or, most recent publisher overrides any others. Comment: Agree with comment. Don't reinvent WebDAV. Don't make endpoint behavior too complex.=20 Comment: Agree with comment that this is an authorization problem. Comment: Not clear we can relax overlap with congestion issues. Conclusion: Author will take to the list for more discussion. Resource Priority - Henning Schulzrinne ------------------------------------------------------- Issue: error handling. Proposed solution: 503 or 403 or 417 (Unknown Resource Priority - only if Require is used. No objections or = discussion. Believed to be ready for WGLC Comment: Pointers to name spaces are in draft. Comment: Role based authorization is still moving forward. Volunteers to review the next draft: Paul Kyzivat, Ben Campbell Caller Prefs - Jonathan Rosenberg ----------------------------------------------- Issue in Callee Caps - URI-user and URI-domain - duplication: Suggested = Use a Device ID (Contact URI attribute) instead? No conclusion in this discussion. Comment: Device ID is interesting, but could be overloaded. Should = recommend GRUU for attended transfer. Comment: Expiration of device ID is unpredictable. Conclusion: Quick list consensus on adding device ID. Recommend GRUU instead for transfer case. Caller Prefs Comment: Enumeration is better Open Issue: redirection - RFC 3261 proxy merging q-values is broken. Proposal: include text saying this. Question: Do we need to mandate this? Questioner will send a short use = case to mailing list. Open Issue: lost use cases due to changes. Comment: This is a feature. Comment: Can be done with multiple requests. Conclusion: no changes needed. Open Issues in Use Cases: No discussion. Comment: Does basing on RFC 2533 provide any value? Comment: Should RFC 2533 reference just be an informational reference? SIP Identity - Jon Peterson ------------------------------------- Topic: AIB No issues or comments. Topic: AES and S/MIME Question: Should we redo S/MIME examples in RFC 3261? Proposal: Cullen Jennings could do some examples.=20 Comment: Base-64 encoding issue causes interoperability problems. = (Binary encoding is better) Comment: No commercial SIP stacks support S/MIME and TLS. Comment: There were 2 implementations of S/MIME at last SIPit. History Info - Mary Barnes ------------------------------------- Open Issue: Index. Proposal: Make it mandatory and clarify loose = routing behavior. Open Issue: Internal Retargeting. Proposal: Include some normative text = and examples. Open Issue: Privacy. Proposal: Add text. Comment: Draft needs major clarification on privacy, redirection, = backwards compatibility, others. Will discuss on list. Comment: Include in security section - this header solves a useful = problem that a requestor could verify that appropriate proxies have retargeted a request. Conclusion: Much more work needed. Securing SIP Identity Headers - Mary Barnes -------------------------------------------------------------- (SIPPING draft but discussed here for convenience) Comment: Question on question not solution. Do we need to do this? Comment: This is a type of middle-to-end security problem. We need to = solve this problem. Comment: If we redid Proxy-Auth header, we would use a body instead of a header. Parameter Registry - Gonzalo Camarillo -------------------------------------------------------- Open Issue: Which URI parameters should be registered? Comment: Do we want p-parameters? Comment: Lets not make the same mistake twice. Comment: Want to increase interoperability and avoid collisions. Comment: To prevent conflicts during Internet-Draft stage, should use = this registry. Comment: C language analogy -- this is like requiring C developers to go back to Standard C committee and register every variable name they use = as a language keyword. The registry could be flooded with requests. Propose = that we should only register URI parameters that are global in nature. Comment: Have informal non-IANA registry instead (webpage) Comment: Should do the same thing for parameters (headers and URIs) as headers. Comment: Similar to standardization of headers across protocols effort. Conclusion: A Hum was taken which supported the creation of an IANA registry for parameters defined by RFCs. No consensus on the rest of = the issue - more list discussion needed. Connection Reuse - Rohan Mahy --------------------------------------------- Open Issue: Clarity on which is original and which is alias. Open Issue: Security - explaining Mutual TLS and digest A Hum was taken which supported that people care about the work. A Hum was taken which supported that this mechanism is reasonable. Comment: Need to describe how to handle when multiple parties claim the = same alias (10.1.1.1). Conclusion: A Hum was taken which supported that the chairs request a charter modification to adopt as a WG item. SIP Security and S/MIME - Cullen Jennings ------------------------------------------------------------ Comment: Mechanism could be used for certificate or raw keys. Comment: Identity work avoided UAS having to do any PKI operation. = Identity document also only identifies the domain, not the individual user. Question: Does this work in both ways? Answer: Yes, but not exactly. Many more comments until we ran out of time. Hum taken on interest of working group in solving this problem. Strong interest indicated. Conclusion: The WG will continue discussion of this topic. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 22 14:46:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22284 for ; Tue, 22 Jul 2003 14:46:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f29U-0003EM-HX for sip-archive@odin.ietf.org; Tue, 22 Jul 2003 14:46:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MIkKtl012413 for sip-archive@odin.ietf.org; Tue, 22 Jul 2003 14:46:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f29B-0003DH-Sn; Tue, 22 Jul 2003 14:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f28d-0003Ci-PV for sip@optimus.ietf.org; Tue, 22 Jul 2003 14:45: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 OAA22265 for ; Tue, 22 Jul 2003 14:45:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f28b-0006cU-00 for sip@ietf.org; Tue, 22 Jul 2003 14:45:25 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19f28Q-0006c0-00 for sip@ietf.org; Tue, 22 Jul 2003 14:45:14 -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 h6MIiMpp013715; Tue, 22 Jul 2003 11:44:22 -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.6-GR) with ESMTP id AJL79388; Tue, 22 Jul 2003 11:40:27 -0700 (PDT) Date: Tue, 22 Jul 2003 20:46:28 +0200 Subject: Re: [SIP] Replaces header and REFER Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'sip@ietf.org'" To: Werkstudent8 SAL From: Rohan Mahy In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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 Wednesday, July 16, 2003, at 03:38 PM, Werkstudent8 SAL wrote: > From: "Stefan Mecke" > > Hi all, > > I have a question about draft-ietf-sip-replaces-03.txt: > Section 2 says: > ... the Replaces header is > frequently used in combination with the REFER [4] method ... it is frequently used in combination with the REFER method, by embedding the Replaces header in the Refer-To URI. The Replaces header NEVER appears in the header section of a REFER request. > but section 3 contains: > ... if > a Replaces header field is present in a request other than INVITE, > the UAS MUST reject the request .. > > I think it makes a lot of sense to allow replaces with REFER; e.g. in > the > call park scenario you could have a web page with all call and make a > "click > to retrieve from park" to have it on your desk phone. > And that is similar to what's described in > draft-ietf-sipping-cc-transfer-01.txt, although I have a notion that > there > is some difference but I don't manage to get it out of the draft. check out draft-ietf-sipping-service-examples this draft describes several solutions including call park/retrieve. thanks, -rohan > Thanks > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 22 15:39:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24670 for ; Tue, 22 Jul 2003 15:39:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f2yk-0005qh-0q for sip-archive@odin.ietf.org; Tue, 22 Jul 2003 15:39:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MJdHob022479 for sip-archive@odin.ietf.org; Tue, 22 Jul 2003 15:39:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f2yT-0005pw-G7; Tue, 22 Jul 2003 15: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 19f2xa-0005mg-P7 for sip@optimus.ietf.org; Tue, 22 Jul 2003 15:38: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 PAA24638 for ; Tue, 22 Jul 2003 15:38:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f2xZ-0006vO-00 for sip@ietf.org; Tue, 22 Jul 2003 15:38:05 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19f2xO-0006vH-00 for sip@ietf.org; Tue, 22 Jul 2003 15:37:54 -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 h6MJam624610 for ; Tue, 22 Jul 2003 14:36:48 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <301TZ3Q3>; Tue, 22 Jul 2003 14:36:47 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF578AC3@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'sip@ietf.org'" Subject: FW: [Sip] comments on history-info-00 Date: Tue, 22 Jul 2003 14:35:57 -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: , This email appears to have gotten lost somewhere, so I'm resending (I apologize if it ends up being a duplicate). -----Original Message----- From: Barnes, Mary [NGC:B602:EXCH] Sent: Monday, July 21, 2003 1:42 PM To: 'Jonathan Rosenberg' Cc: sip@ietf.org Subject: RE: [Sip] comments on history-info-00 Jonathan, Some initial responses are embedded below [MB]. I do, however, have some more general comments that might also address your concerns as follows: - In general, it seems that alot of your confusion around the fundamental processing of History-Info is around the fact that we've optimized to only capturing a single URI, which adds to some of the terminology concerns that you have. I'm beginning to wonder if it wouldn't be better to go back to capturing both the retargeted-from and retargeted-to URIs? The advantage of this is that it doesn't introduce this "seeding" or "kickstarting" of HI when a proxy receives a request with no HI, which introduces these special cases in the fundamental processing. What this also might be highlighting is the need to bring some of the background text on the solution options from appendix D into a background section that precedes the normative text for HI. - As I mentioned during the discussion, I fully agree that there is a general lack of clarity (and as you suggest a need for more precision) around the fundmental normative processing after discussions with folks that are planning on implementing this draft. In particular, the processing around the Index is quite unclear; I think adding the index to all the examples and adding additional example flows will also help with the concern here. Regards, Mary H. Barnes mbarnes@nortelnetworks.com -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Tuesday, July 15, 2003 7:58 PM To: sip@ietf.org Subject: [Sip] comments on history-info-00 Mary, Here are some comments on history-info. I suspect many apply to prior versions as well. My apologies if they have been discussed, I have not really followed the work closely. Many of my comments are asking for much more precision in the document. Generally, I found it to be very imprecise, with lots of undefined terminology and vague procedures. That aside, I have some major issues with the privacy mechanisms, with the usage of history-info by redirect servers, with sending a 183 with history information, and with the backwards compatibility implications. So, here we go: Firstly, the draft says in many places that applications need to document the impact of things. For example, Section 1.1 says: Thus, it is highly recommended that all applications making use of the request history information clearly define the impact of the information not being available and specify the processing of such a request. Does this mean there is some kind of application registry where such documentation will exist? [MB]: No, I think the use of History-Info is no different than any other optional SIP header and that application scenarios in the form of call flows will be needed in Informational (or as has become the trend BCPs) to effectively document the use of the header. Does it mean that applications won't be interoperable because they will depend on the presence of these headers? [MB]: Ditto my previous comment. The text in 1.1 makes it sound like the information would only be present if some local policy prevented its insertion. [MB] I think you mean "didn't prevent" rather than "prevented" in this preceeding sentence. And, yes,local policy is one factor that determines whether the History-Info is inserted. What about cases where the proxy doesn't support it? [MB]: Then, the information isn't captured for any retargeting by that proxy, but any previous HI entries should remain, since proxies should not remove headers. Even if it does, your draft reads very much like it is now going to require every proxy to insert this header. Is that so? [MB]: No, it's an optional header. However, for systems where this isn't supported, the functionality of an end application might be limited. Second, section 1.3 talks about the use of the Privacy header. There are a few problems here. First, the privacy header gets stripped once the privacy service finishes execution. Thus, a downstream proxy would not be able to know privacy was requested. To a large degree, this is because the privacy header in a request is about privacy of the caller. Request history is about the current target (i.e., called party). So, in fact, the issue is that if the *called* party requests privacy (using a privacy header in a response), the history info headers should not be propagated backwards in a response. I dont think your draft does that. [MB]: This is similar to several threads of discussion we had around the requirements about 6 months ago: http://www1.ietf.org/mail-archive/working-groups/sipping/current/msg03695.ht ml which I believe was addressed in a subsequent revision to the requirements (although, I'll have to dig for the details on that as I don't see that readily visible in the archives or cached in my email archives at this time). Local policy might also play a role, when it is representing the privacy interests of a user that is retargeting. In that case, it was unclear to me how the proxy prevents downstream elements from inserting history-info? Your draft makes it sound like the privacy requirements are met if just this one hop avoids insertion. But seeing the contact from downstream retargets will often reveal sensitive information about a target further upstream. [MB]: I agree, I think local policy is this primary mechanism for the privacy solution for HI and per the email discussion. As I highlighted in the meeting, the privacy aspects of the solution are indeed incomplete and hopefully will be addressed adequately in the next version. Section 2.1: > Targeted-to-URI: the Request URI captured as the Request is > targeted. By capturing a copy of the Request URI in the initial > request, the Retargeted-from-URI is already captured when a > request is retargeted and the Retargeted-to-URI is being > captured. > I read this many times and could not make sense of it. What does it mean? [MB] This has to be read in context of the definitions for Retargeted-from-URI and Retargeted-to-URI in the Definitions section. Because we're optimizing by capturing only a single URI (the "new" URI in the request being retargeted) rather than capturing both the "old" and "new" URIs for each retargeting (and thus duplicating information since the "new" of the previous HI entry would become the "old" for the next entry). Section 2.3.1: > The UAC SHOULD include the HistInfo option tag in the Supported > header in any request not associated with an established dialog for > which the UAC would like the History-Info in the Response. In > addition, the UAC should initiate the capturing of the History > Information by capturing the Request-URI as the hi-targeted-to-uri > and initializing the index to 1. What if the UAC doesn't support this extension? Can the UAS get history info? My understanding is that most, if not all, evnisioned applications were for the UAS. This means the UAS can't get information unless the caller and many, if not all, proxies along the path support it. [MB] If the UAC doesn't include the option tag, then that means that it won't get the History-Info in any responses. Whether the proxy captures History-Info is local policy; the text is attempting to state that if the proxy is planning on capturing History-Info then it goes ahead and creates the "zero-th" entry. We originally were capturing 2 URIs, the original request URI and the retargeted-to URI. However, to minimize the overhead and duplicate data, we made the change in the -01 individual draft to only capture one URI, so that you basically need to "seed" the chain of URIs to capture the History, by capturing the original URI at the time of the first re-targeting that you're intending to capture. So, the UAS can get the information even if the caller doesn't want it in responses. You are correct that for many applications, it would be necessary for many of the proxies along the path to support it. Section 2.3.2: > The processing of History-Info by a UAS in a Request depends upon > local policy and specific applications at the UAS which might make > use of the information. If the HistInfo option tag is received in a > request, the UAS should include any History-Info received in the > request in the subsequent response. I think you mean SHOULD in the last sentence. Also, I think you mean that "If the request contained the histinfo option tag in the Supported header field of the request, the UAS....". [MB] Correct. Also, you've capitalized the H and I in HistInfo. Please don't. Option tags are not case sensitive. [MB] Noted. Section 2.3.3: The wording about when to capture is really vague. You need to be much more precise in your wording of when the proxy is and isnt going to capture history information. [MB]: As I mentioned during my presentation of issues during the WG meeting, this was the same feedback I had received from some folks that in the process of implementing this and I do improve this in the next version. However, this section was intended to be a higher level overview of the processing with the subsequent sub-sections intended to provide the details of the normative processing. Section 2.3.3.1: > If the proxy supports History-Info, the proxy SHOULD add any History- > Info collected as it retargets a Request. For retargets that are the > result of an explicit SIP response, the SIP Response Code that > triggered the retargeting MUST be included in the Reason header of > the Targeted-to-URI. This needs to be more precise. What does it mean "..collected as it retargets a request"? How is this information collected? Also, when you say "explicit SIP response" - all responses are explicit as far as I know. Perhaps you mean when a 3xx response is received? Also, you say "Reason header of the Targeted-to-URI". I believe reason is a parameter, not a header, in this instance. and then: > For retargets as a result of timeouts or > internal events, a Reason header MAY be included in the Reason header > of the Targeted-to-URI. what are internal events? [MB]: This was also something I mentioned at the meeting and has to do with "internal retargeting" which can be the result of things like selecting the route in a route list, etc. ****************************************** What value does the reason parameter have in the case of timeout? In the case of internal events? [MB]: It lets an application or end user know why the retargeting occurred. and then: > Additionally, if a request is received that doesn't include a > captured Request URI from the previous entity, the proxy MAY add an > additional entry, effectively capturing the retargeted-from-URI in > the Request. What does it mean for a request to "not include a captured Request-URI"? You need to define that. What is contained in the additional entry? [MB]: Per my general comment at the beginning of my email response, this has to do with the current mechanism of only capturing a single URI. I may sound like I am being nit-picky, but in my experience specifications need to be very precise in what you want people to do. I am confused about what is implied here, and I would imagine many others would be confused too. [MB]: Again, as I mentioned during the meeting, this is an open issue with the draft that I plan to correct on the next version. and then: > In order to maintain ordering and accurately reflect the nesting and > retargeting of the request, an index MUST be included along with the > Targeted-to-URI being captured. The basic rule for adding the index > are to read the value from the previous History-Info, if available, > and capture the index.n as the index for the History-Info being > captured, where n would typically be 1 for a forwarded request. Thus, > the level of nesting of the index reflects the number of hops. define previous. what does it mean to "capture the index.n"? what is index? what is .n? You say its "typically 1". When is it 1, and when is it not one? and then: > For > retargets within a proxy, the proxy MUST maintain the current level > of nesting by incrementing the lowest/last digit of the index for > each instance of retargeting, thus reflecting the number of retargets > within the proxy. I cannot understand this at all. and then: > n index MUST NOT be added > in the scenario whereby the received request had no History-Info > header and the retargeted-from-URI is being captured for > completeness. what does "for completeness" mean? You need to be precise. [MB]: Another issue related to the general mechanism of capturing a single URI that I mentioned at the beginning of my email response. > The lack of Reason headers in the captured Request-URIs should be > indicative of the parallel nature of forking (i.e the Request-URIs > are not the result of retargets, but are rather all simultaneous > Targeted-To URIs.) should be indicative? Is it, or isnt it? [MB] Correct. I'll change this from "should be" to "is" > A proxy that receives a Request with the HistInfo option tag in the > Supported header, and depending upon a local policy supporting the > capture of History-Info, SHOULD return captured History-Info in > subsequent, provisional and final responses to the Request. A 183 > response MAY be sent explicitly for the purposes of conveying > History-Info prior to the final response. I think the first sentence means that the proxy does nothing to responses - any history-info in those responses is just passed on. But I'm not sure. The sentence says "should return", and return seems like an active operation to me. [MB]: The use of HI does not at all change the messaging, but rather just adds the captured information to the response in the scenarios where it has been captured. It is not intended to be an "active" operation. The next sentence actually implies that the proxy generate a 183 provisional responses. [MB]: No, that's not what was intended. This sentence was added in response to a concern raised that HI didn't appear to be allowed to be sent in provisional responses. This means that a UA making a call with N proxies will get N extra provisional responses, where the first has one history-info value, the next 2, the next 3, and so on. The first history info is transmitted to the UAC N times. Is that really what we want? It seems very expensive for the UAC. [MB]: Per my response to a previous comment above, HI does not at all change the fundamental messaging, but rather just adds the captured information to the response in the scenarios where it has been captured. > It MAY be advantageous for redirect servers to support the receipt of > History-Info in requests. You can you assign a protocol strength to being advantageous? I think you mean "A redirect server MAY use information in the History-Info header field in a request to determine the URIs that it will retarget to.". [MB] Agreed; your suggested wording is a more accurate representation of the intent of the original statement. > By receiving it in the request, the > Redirect Server MAY be able to optimize the information it sends in > responses by looking at the already targeted-to-URIs. and what optimization is that? I think you mean that the redirect server shouldnt redirect to somewhere that the request has already visited. If so, please say that. However, are we sure about that? Redirection to a URI already visited can be appropriate in cases where there is a spiral, and not a loop. Unless a redirect server is maintaining state, how can it make this determiantionabout whether this is a spiral or a loop? [MB]: You bring up a valid point that should be clarified. It might be better to just remove that statement since it really is an implementation decision and as you suggest such "optimizations" could be problematic in some scenarios. (Although, it might be better to highlight the cautions should someone want to make such an optimization or highlight perhaps that it's better not to do such an optimization). > HistInfo When used with the Supported header, [RFCXXXX] > this option tag indicates support > for the History Information to be > captured for requests and returned in > subsequent responses. This tag is not > used in a Proxy-Require or Requires > header field since support of > History-Info is optional. Require header field, not Requires. [MB]: Noted. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 23 09:00:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10341 for ; Wed, 23 Jul 2003 09:00:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJDT-0007v8-Ea for sip-archive@odin.ietf.org; Wed, 23 Jul 2003 08:59:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NCxZ14030445 for sip-archive@odin.ietf.org; Wed, 23 Jul 2003 08:59:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJCv-0007ta-J1; Wed, 23 Jul 2003 08:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJCW-0007tE-BP for sip@optimus.ietf.org; Wed, 23 Jul 2003 08:58: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 IAA10236 for ; Wed, 23 Jul 2003 08:58:33 -0400 (EDT) From: hspark@etri.re.kr Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fJCU-0004LX-00 for sip@ietf.org; Wed, 23 Jul 2003 08:58:34 -0400 Received: from cms3.etri.re.kr ([129.254.16.13] helo=cms3.cms.etri.re.kr) by ietf-mx with esmtp (Exim 4.12) id 19fJCJ-0004LT-00 for sip@ietf.org; Wed, 23 Jul 2003 08:58:23 -0400 Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jul 2003 21:58:11 +0900 Message-ID: <9E664A0522ABD711827B00D0B7A8AC4A375BA1@cms3.etri.re.kr> To: sip@ietf.org Date: Wed, 23 Jul 2003 21:58:11 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3511A.1245A6E0" Subject: [Sip] When does "Re-INVITE" take effect ? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3511A.1245A6E0 Content-Type: text/plain Hello, If IP/port in SDP changes, when does "Re-INVITE" take effect ? from Sip-Implementors mail archive http://lists.cs.columbia.edu/pipermail/sip-implementors/2001-May/001211.html from RFC3312 Integration of Resource Management and Session Initiation Protocol (SIP) 13. 1 End-to-End Status Type http://www.zvon.org/tmRFC/RFC3312/Output/chapter13.html from RFC3264 An Offer/Answer Model Session Description Protocol 8.3.1 Modifying Address, Port or Transport http://www.zvon.org/tmRFC/RFC3264/Output/chapter8.html Alice Proxy 2 Bob | Both Way RTP Media Established | |<=======================================>| | | | Bob changes IP address | | | | F9 INVITE | |<----------------------------------------| | F10 200 OK | |---------------------------------------->| | F11 ACK | |<----------------------------------------| | New RTP Media Stream | |<=======================================>| 1) In above flows, Alice may continue sending media to Bob's old address during "Re-INVITE". Alice may start sending media to Bob's new address before sending 200 OK, if "Re-INVITE" is accepted by Alice. Bob may continue sending media to Alice during "Re-INVITE" ? Am I right ? 2) If RTCP timeout occurs on Alice and there is no active media session with Bob, does Alice terminate SIP session with Bob ? 3) If Bob sends RTCP with new SSRC and new address before "Re-INVITE" is accepted by Alice, is there any problem in that ? Thanks in advance. Brad Park ------_=_NextPart_001_01C3511A.1245A6E0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable 메시지
Hello,
 
If IP/port in=20 SDP changes, when does "Re-INVITE" take effect = ?
 
from Sip-Implementors=20 mail archive
http://lists.cs.columbia.edu/pipermail/sip-implementors/20= 01-May/001211.html
 
from=20 RFC3312
Integration of Resource Management and Session = Initiation Protocol=20 (SIP)
13. 1 End-to-End Status=20 Type
http://= www.zvon.org/tmRFC/RFC3312/Output/chapter13.html
=
 
from RFC3264=20
An=20 Offer/Answer Model Session Description = Protocol
8.3.1=20 Modifying Address, Port or Transport
http://w= ww.zvon.org/tmRFC/RFC3264/Output/chapter8.html
 

       =20 Alice           &= nbsp;   =20 Proxy 2           &= nbsp;   =20 Bob

          =20 |     =20 Both Way RTP Media Established     |=20

          =20 |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|=20

          =20 |           &= nbsp;           &= nbsp;           &= nbsp;    =20 |

          =20 |          =20 Bob changes IP address        = |=20

          =20 |           &= nbsp;           &= nbsp;           &= nbsp;    =20 |

          =20 |           &= nbsp;    =20 F9 INVITE           &= nbsp;  =20 |

          =20 |<----------------------------------------|=20

          =20 |           &= nbsp;   =20 F10 200 OK           &= nbsp;  =20 |

          =20 |---------------------------------------->|   =

          =20 |           &= nbsp;    =20 F11  ACK           &= nbsp;   =20 |

          =20 |<----------------------------------------|=20

          =20 |        =20 New RTP Media Stream            = |

          =20 |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|=20

 

1) In above flows,=20

Alice may continue sending = media to Bob's=20 old address during "Re-INVITE".

Alice may start sending media = to Bob's new=20 address

before sending 200 OK, = if "Re-INVITE"=20 is accepted by Alice.

Bob may continue sending = media to Alice=20 during "Re-INVITE" ?

Am I right = ?

 

2) If RTCP timeout = occurs on Alice=20 and there is no active media session with Bob, =

does Alice terminate SIP = session with Bob=20 ?

 

3) If Bob sends RTCP with new = SSRC and new=20 address before "Re-INVITE" is accepted by Alice, =

is there any problem in that=20 ?

 

Thanks in=20 advance.

 

Brad Park

------_=_NextPart_001_01C3511A.1245A6E0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 23 10:08:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13782 for ; Wed, 23 Jul 2003 10:08:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKHo-0003Nj-Uz for sip-archive@odin.ietf.org; Wed, 23 Jul 2003 10:08:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NE88XU012977 for sip-archive@odin.ietf.org; Wed, 23 Jul 2003 10:08:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKHi-0003Le-70; Wed, 23 Jul 2003 10: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 19fKGv-00036X-K6 for sip@optimus.ietf.org; Wed, 23 Jul 2003 10:07: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 KAA13630 for ; Wed, 23 Jul 2003 10:07:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fKGt-0004vk-00 for sip@ietf.org; Wed, 23 Jul 2003 10:07:11 -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 19fKGi-0004vV-00 for sip@ietf.org; Wed, 23 Jul 2003 10:07:01 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6NE68Qk026748; Wed, 23 Jul 2003 07:06:09 -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.6-GR) with ESMTP id AJM79439; Wed, 23 Jul 2003 07:02:07 -0700 (PDT) Date: Wed, 23 Jul 2003 16:08:16 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'Robert Sparks'" To: sip@ietf.org From: Rohan Mahy Content-Transfer-Encoding: 7bit Message-Id: <1B22D2CF-BD17-11D7-B1E0-0003938AF740@cisco.com> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Sip] non-INVITE transaction issues Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Folks, Last week in Vienna we skipped over a presentation from Robert Sparks about non-INVITE transactions, as he was very ill at the time. I'd like to start up a thread about the non-INVITE transaction draft that he wrote and the issues discussed there. This is important work, and some documents will depend on our solutions (guidelines, and new methods). Please review the document, and provide comments. Also, Robert may provide the presentation he was going to give which should offer some guidance. many thanks, -rohan co-chair SIP and SIPPING (Note: I will send my own comments as an individual as a separate response to this message.) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 23 12:11:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18371 for ; Wed, 23 Jul 2003 12:11:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fMD2-000116-Sr for sip-archive@odin.ietf.org; Wed, 23 Jul 2003 12:11:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NGBKkB003886 for sip-archive@odin.ietf.org; Wed, 23 Jul 2003 12:11:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fMCk-0000zy-5g; Wed, 23 Jul 2003 12: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 19fMC5-0000zW-Lk for sip@optimus.ietf.org; Wed, 23 Jul 2003 12:10:21 -0400 Received: from cc26-01.idc1.level3.com.level3.com (machine77.Level3.com [209.244.4.106]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18318 for ; Wed, 23 Jul 2003 12:10:17 -0400 (EDT) Received: from cc26-01.idc1.level3.com.level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id B44B1FB595 for ; Wed, 23 Jul 2003 16:04:49 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.7.194]) by cc26-01.idc1.level3.com.level3.com (Postfix) with SMTP id D4D4EFB594 for ; Wed, 23 Jul 2003 16:04:48 +0000 (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); Wed, 23 Jul 2003 10:04:48 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Jul 2003 10:04:48 -0600 Message-ID: <3DB099919328BA41905F651A6EF8397608CE00@idc1exc0004.corp.global.level3.com> Thread-Topic: Is there any standard SIP/SDP for communicating echo cancellation ? Thread-Index: AcNRNCPkW4h+cxIlSRGXv/w4xvJGIg== From: "Hashmi, Mohamed Hadi" To: X-OriginalArrivalTime: 23 Jul 2003 16:04:48.0840 (UTC) FILETIME=[24767C80:01C35134] Content-Transfer-Encoding: quoted-printable Subject: [Sip] Is there any standard SIP/SDP for communicating echo cancellation ? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org 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 For transmitting FAX or Modem call over VoIP ( RTP- preferably G.711) = in PSTN-SIP-PSTN call it is required that echo cancellation be turned = off at both end Gateways. There are specific standards for FAX (T.38) = and MoIP (V.150.1) to deal with these issues, but not every vendor has = implemented those standards in their Media Gateways.=20 In such a situation G.711 with echo cancellation turned off at both end = will help transmitting such calls like FAX or MoIP. Gateway control = protocols such as MGCP, Megaco, IPDC etc do have specific tags to = handle this case. But don't know how this information can be = communicated between two Gateway Controllers using SIP. Is anybody = aware of any standard SDP for such a functionality? Although an SDP = can be custom designed for this purpose but this wouldn't help = interoperation between two different vendors.=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 From exim@www1.ietf.org Wed Jul 23 18:31:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06217 for ; Wed, 23 Jul 2003 18:31:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fS8l-0002gG-FD for sip-archive@odin.ietf.org; Wed, 23 Jul 2003 18:31:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NMVJiv010302 for sip-archive@odin.ietf.org; Wed, 23 Jul 2003 18:31:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fS8U-0002fQ-O9; Wed, 23 Jul 2003 18:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fS80-0002ej-AR for sip@optimus.ietf.org; Wed, 23 Jul 2003 18:30:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06185 for ; Wed, 23 Jul 2003 18:30:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fS7x-0001Lg-00 for sip@ietf.org; Wed, 23 Jul 2003 18:30:29 -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 19fS7m-0001LD-00 for sip@ietf.org; Wed, 23 Jul 2003 18:30:18 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6NMTCuG006594; Wed, 23 Jul 2003 15:29:12 -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.6-GR) with ESMTP id AJN45834; Wed, 23 Jul 2003 15:25:08 -0700 (PDT) Date: Thu, 24 Jul 2003 00:31:20 +0200 Subject: Re: [Sip] Is there any standard SIP/SDP for communicating echo cancellation ? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Hashmi, Mohamed Hadi" From: Rohan Mahy In-Reply-To: <3DB099919328BA41905F651A6EF8397608CE00@idc1exc0004.corp.global.level3.com> Message-Id: <625402E4-BD5D-11D7-B1E0-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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, It would probably help if you took a look at draft-ietf-sipping-realtimefax-01.txt and its references. If you still have questions, please post your question to the MMUSIC WG mailing list. many thanks, -rohan co-chair SIP and SIPPING On Wednesday, July 23, 2003, at 06:04 PM, Hashmi, Mohamed Hadi wrote: > For transmitting FAX or Modem call over VoIP ( RTP- preferably G.711) > in PSTN-SIP-PSTN call it is required that echo cancellation be turned > off at both end Gateways. There are specific standards for FAX (T.38) > and MoIP (V.150.1) to deal with these issues, but not every vendor has > implemented those standards in their Media Gateways. > > In such a situation G.711 with echo cancellation turned off at both > end will help transmitting such calls like FAX or MoIP. Gateway > control protocols such as MGCP, Megaco, IPDC etc do have specific > tags to handle this case. But don't know how this information can be > communicated between two Gateway Controllers using SIP. Is anybody > aware of any standard SDP for such a functionality? Although an SDP > can be custom designed for this purpose but this wouldn't help > interoperation between two different vendors. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Jul 23 18:32:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06266 for ; Wed, 23 Jul 2003 18:32:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fS9U-0002ic-T0 for sip-archive@odin.ietf.org; Wed, 23 Jul 2003 18:32:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NMW466010416 for sip-archive@odin.ietf.org; Wed, 23 Jul 2003 18:32:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fS9S-0002hb-Ao; Wed, 23 Jul 2003 18:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fS8U-0002fI-Dz for sip@optimus.ietf.org; Wed, 23 Jul 2003 18:31:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06191 for ; Wed, 23 Jul 2003 18:30:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fS8R-0001Lm-00 for sip@ietf.org; Wed, 23 Jul 2003 18:30:59 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19fS8G-0001LC-00 for sip@ietf.org; Wed, 23 Jul 2003 18:30:48 -0400 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h6NMT5iJ017937; Wed, 23 Jul 2003 18:29:05 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jul 2003 17:29:04 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86240@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Rohan Mahy'" , sip@ietf.org Cc: Robert Sparks Subject: RE: [Sip] non-INVITE transaction issues Date: Wed, 23 Jul 2003 17:29:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I think it would be useful for anyone interested in this topic to review the minutes from the ad-hoc meeting we had on this topic in San Francisco. Please see: /a > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Wednesday, July 23, 2003 9:08 > To: sip@ietf.org > Cc: 'Robert Sparks' > Subject: [Sip] non-INVITE transaction issues > > > Hi Folks, > > Last week in Vienna we skipped over a presentation from Robert Sparks > about non-INVITE transactions, as he was very ill at the time. I'd > like to start up a thread about the non-INVITE transaction draft that > he wrote and the issues discussed there. This is important work, and > some documents will depend on our solutions (guidelines, and new > methods). Please review the document, and provide comments. Also, > Robert may provide the presentation he was going to give which should > offer some guidance. > > many thanks, > -rohan > co-chair SIP and SIPPING > > > (Note: I will send my own comments as an individual as a separate > response to this message.) > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Jul 24 10:33:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09031 for ; Thu, 24 Jul 2003 10:33:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fh91-0000RT-1O for sip-archive@odin.ietf.org; Thu, 24 Jul 2003 10:32:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OEWYT3001630 for sip-archive@odin.ietf.org; Thu, 24 Jul 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 19fh7Y-00008n-HE; Thu, 24 Jul 2003 10:31:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19efdE-0000fH-Pm for sip@optimus.ietf.org; Mon, 21 Jul 2003 14:43:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06607 for ; Mon, 21 Jul 2003 14:43:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19efdB-0005Lv-00 for sip@ietf.org; Mon, 21 Jul 2003 14:43:30 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19efd0-0005Le-00 for sip@ietf.org; Mon, 21 Jul 2003 14:43:18 -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 h6LIgJt27534; Mon, 21 Jul 2003 13:42:19 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <301TY7QL>; Mon, 21 Jul 2003 13:42:20 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF578AB5@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Jonathan Rosenberg'" Cc: sip@ietf.org Subject: RE: [Sip] comments on history-info-00 Date: Mon, 21 Jul 2003 13:42:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C34FB7.D05D5394" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C34FB7.D05D5394 Content-Type: text/plain; charset="iso-8859-1" Jonathan, Some initial responses are embedded below [MB]. I do, however, have some more general comments that might also address your concerns as follows: - In general, it seems that alot of your confusion around the fundamental processing of History-Info is around the fact that we've optimized to only capturing a single URI, which adds to some of the terminology concerns that you have. I'm beginning to wonder if it wouldn't be better to go back to capturing both the retargeted-from and retargeted-to URIs? The advantage of this is that it doesn't introduce this "seeding" or "kickstarting" of HI when a proxy receives a request with no HI, which introduces these special cases in the fundamental processing. What this also might be highlighting is the need to bring some of the background text on the solution options from appendix D into a background section that precedes the normative text for HI. - As I mentioned during the discussion, I fully agree that there is a general lack of clarity (and as you suggest a need for more precision) around the fundmental normative processing after discussions with folks that are planning on implementing this draft. In particular, the processing around the Index is quite unclear; I think adding the index to all the examples and adding additional example flows will also help with the concern here. Regards, Mary H. Barnes mbarnes@nortelnetworks.com -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Tuesday, July 15, 2003 7:58 PM To: sip@ietf.org Subject: [Sip] comments on history-info-00 Mary, Here are some comments on history-info. I suspect many apply to prior versions as well. My apologies if they have been discussed, I have not really followed the work closely. Many of my comments are asking for much more precision in the document. Generally, I found it to be very imprecise, with lots of undefined terminology and vague procedures. That aside, I have some major issues with the privacy mechanisms, with the usage of history-info by redirect servers, with sending a 183 with history information, and with the backwards compatibility implications. So, here we go: Firstly, the draft says in many places that applications need to document the impact of things. For example, Section 1.1 says: Thus, it is highly recommended that all applications making use of the request history information clearly define the impact of the information not being available and specify the processing of such a request. Does this mean there is some kind of application registry where such documentation will exist? [MB]: No, I think the use of History-Info is no different than any other optional SIP header and that application scenarios in the form of call flows will be needed in Informational (or as has become the trend BCPs) to effectively document the use of the header. Does it mean that applications won't be interoperable because they will depend on the presence of these headers? [MB]: Ditto my previous comment. The text in 1.1 makes it sound like the information would only be present if some local policy prevented its insertion. [MB] I think you mean "didn't prevent" rather than "prevented" in this preceeding sentence. And, yes,local policy is one factor that determines whether the History-Info is inserted. What about cases where the proxy doesn't support it? [MB]: Then, the information isn't captured for any retargeting by that proxy, but any previous HI entries should remain, since proxies should not remove headers. Even if it does, your draft reads very much like it is now going to require every proxy to insert this header. Is that so? [MB]: No, it's an optional header. However, for systems where this isn't supported, the functionality of an end application might be limited. Second, section 1.3 talks about the use of the Privacy header. There are a few problems here. First, the privacy header gets stripped once the privacy service finishes execution. Thus, a downstream proxy would not be able to know privacy was requested. To a large degree, this is because the privacy header in a request is about privacy of the caller. Request history is about the current target (i.e., called party). So, in fact, the issue is that if the *called* party requests privacy (using a privacy header in a response), the history info headers should not be propagated backwards in a response. I dont think your draft does that. [MB]: This is similar to several threads of discussion we had around the requirements about 6 months ago: http://www1.ietf.org/mail-archive/working-groups/sipping/current/msg03695.ht ml which I believe was addressed in a subsequent revision to the requirements (although, I'll have to dig for the details on that as I don't see that readily visible in the archives or cached in my email archives at this time). Local policy might also play a role, when it is representing the privacy interests of a user that is retargeting. In that case, it was unclear to me how the proxy prevents downstream elements from inserting history-info? Your draft makes it sound like the privacy requirements are met if just this one hop avoids insertion. But seeing the contact from downstream retargets will often reveal sensitive information about a target further upstream. [MB]: I agree, I think local policy is this primary mechanism for the privacy solution for HI and per the email discussion. As I highlighted in the meeting, the privacy aspects of the solution are indeed incomplete and hopefully will be addressed adequately in the next version. Section 2.1: > Targeted-to-URI: the Request URI captured as the Request is > targeted. By capturing a copy of the Request URI in the initial > request, the Retargeted-from-URI is already captured when a > request is retargeted and the Retargeted-to-URI is being > captured. > I read this many times and could not make sense of it. What does it mean? [MB] This has to be read in context of the definitions for Retargeted-from-URI and Retargeted-to-URI in the Definitions section. Because we're optimizing by capturing only a single URI (the "new" URI in the request being retargeted) rather than capturing both the "old" and "new" URIs for each retargeting (and thus duplicating information since the "new" of the previous HI entry would become the "old" for the next entry). Section 2.3.1: > The UAC SHOULD include the HistInfo option tag in the Supported > header in any request not associated with an established dialog for > which the UAC would like the History-Info in the Response. In > addition, the UAC should initiate the capturing of the History > Information by capturing the Request-URI as the hi-targeted-to-uri > and initializing the index to 1. What if the UAC doesn't support this extension? Can the UAS get history info? My understanding is that most, if not all, evnisioned applications were for the UAS. This means the UAS can't get information unless the caller and many, if not all, proxies along the path support it. [MB] If the UAC doesn't include the option tag, then that means that it won't get the History-Info in any responses. Whether the proxy captures History-Info is local policy; the text is attempting to state that if the proxy is planning on capturing History-Info then it goes ahead and creates the "zero-th" entry. We originally were capturing 2 URIs, the original request URI and the retargeted-to URI. However, to minimize the overhead and duplicate data, we made the change in the -01 individual draft to only capture one URI, so that you basically need to "seed" the chain of URIs to capture the History, by capturing the original URI at the time of the first re-targeting that you're intending to capture. So, the UAS can get the information even if the caller doesn't want it in responses. You are correct that for many applications, it would be necessary for many of the proxies along the path to support it. Section 2.3.2: > The processing of History-Info by a UAS in a Request depends upon > local policy and specific applications at the UAS which might make > use of the information. If the HistInfo option tag is received in a > request, the UAS should include any History-Info received in the > request in the subsequent response. I think you mean SHOULD in the last sentence. Also, I think you mean that "If the request contained the histinfo option tag in the Supported header field of the request, the UAS....". [MB] Correct. Also, you've capitalized the H and I in HistInfo. Please don't. Option tags are not case sensitive. [MB] Noted. Section 2.3.3: The wording about when to capture is really vague. You need to be much more precise in your wording of when the proxy is and isnt going to capture history information. [MB]: As I mentioned during my presentation of issues during the WG meeting, this was the same feedback I had received from some folks that in the process of implementing this and I do improve this in the next version. However, this section was intended to be a higher level overview of the processing with the subsequent sub-sections intended to provide the details of the normative processing. Section 2.3.3.1: > If the proxy supports History-Info, the proxy SHOULD add any History- > Info collected as it retargets a Request. For retargets that are the > result of an explicit SIP response, the SIP Response Code that > triggered the retargeting MUST be included in the Reason header of > the Targeted-to-URI. This needs to be more precise. What does it mean "..collected as it retargets a request"? How is this information collected? Also, when you say "explicit SIP response" - all responses are explicit as far as I know. Perhaps you mean when a 3xx response is received? Also, you say "Reason header of the Targeted-to-URI". I believe reason is a parameter, not a header, in this instance. and then: > For retargets as a result of timeouts or > internal events, a Reason header MAY be included in the Reason header > of the Targeted-to-URI. what are internal events? [MB]: This was also something I mentioned at the meeting and has to do with "internal retargeting" which can be the result of things like selecting the route in a route list, etc. ****************************************** What value does the reason parameter have in the case of timeout? In the case of internal events? [MB]: It lets an application or end user know why the retargeting occurred. and then: > Additionally, if a request is received that doesn't include a > captured Request URI from the previous entity, the proxy MAY add an > additional entry, effectively capturing the retargeted-from-URI in > the Request. What does it mean for a request to "not include a captured Request-URI"? You need to define that. What is contained in the additional entry? [MB]: Per my general comment at the beginning of my email response, this has to do with the current mechanism of only capturing a single URI. I may sound like I am being nit-picky, but in my experience specifications need to be very precise in what you want people to do. I am confused about what is implied here, and I would imagine many others would be confused too. [MB]: Again, as I mentioned during the meeting, this is an open issue with the draft that I plan to correct on the next version. and then: > In order to maintain ordering and accurately reflect the nesting and > retargeting of the request, an index MUST be included along with the > Targeted-to-URI being captured. The basic rule for adding the index > are to read the value from the previous History-Info, if available, > and capture the index.n as the index for the History-Info being > captured, where n would typically be 1 for a forwarded request. Thus, > the level of nesting of the index reflects the number of hops. define previous. what does it mean to "capture the index.n"? what is index? what is .n? You say its "typically 1". When is it 1, and when is it not one? and then: > For > retargets within a proxy, the proxy MUST maintain the current level > of nesting by incrementing the lowest/last digit of the index for > each instance of retargeting, thus reflecting the number of retargets > within the proxy. I cannot understand this at all. and then: > n index MUST NOT be added > in the scenario whereby the received request had no History-Info > header and the retargeted-from-URI is being captured for > completeness. what does "for completeness" mean? You need to be precise. [MB]: Another issue related to the general mechanism of capturing a single URI that I mentioned at the beginning of my email response. > The lack of Reason headers in the captured Request-URIs should be > indicative of the parallel nature of forking (i.e the Request-URIs > are not the result of retargets, but are rather all simultaneous > Targeted-To URIs.) should be indicative? Is it, or isnt it? [MB] Correct. I'll change this from "should be" to "is" > A proxy that receives a Request with the HistInfo option tag in the > Supported header, and depending upon a local policy supporting the > capture of History-Info, SHOULD return captured History-Info in > subsequent, provisional and final responses to the Request. A 183 > response MAY be sent explicitly for the purposes of conveying > History-Info prior to the final response. I think the first sentence means that the proxy does nothing to responses - any history-info in those responses is just passed on. But I'm not sure. The sentence says "should return", and return seems like an active operation to me. [MB]: The use of HI does not at all change the messaging, but rather just adds the captured information to the response in the scenarios where it has been captured. It is not intended to be an "active" operation. The next sentence actually implies that the proxy generate a 183 provisional responses. [MB]: No, that's not what was intended. This sentence was added in response to a concern raised that HI didn't appear to be allowed to be sent in provisional responses. This means that a UA making a call with N proxies will get N extra provisional responses, where the first has one history-info value, the next 2, the next 3, and so on. The first history info is transmitted to the UAC N times. Is that really what we want? It seems very expensive for the UAC. [MB]: Per my response to a previous comment above, HI does not at all change the fundamental messaging, but rather just adds the captured information to the response in the scenarios where it has been captured. > It MAY be advantageous for redirect servers to support the receipt of > History-Info in requests. You can you assign a protocol strength to being advantageous? I think you mean "A redirect server MAY use information in the History-Info header field in a request to determine the URIs that it will retarget to.". [MB] Agreed; your suggested wording is a more accurate representation of the intent of the original statement. > By receiving it in the request, the > Redirect Server MAY be able to optimize the information it sends in > responses by looking at the already targeted-to-URIs. and what optimization is that? I think you mean that the redirect server shouldnt redirect to somewhere that the request has already visited. If so, please say that. However, are we sure about that? Redirection to a URI already visited can be appropriate in cases where there is a spiral, and not a loop. Unless a redirect server is maintaining state, how can it make this determiantionabout whether this is a spiral or a loop? [MB]: You bring up a valid point that should be clarified. It might be better to just remove that statement since it really is an implementation decision and as you suggest such "optimizations" could be problematic in some scenarios. (Although, it might be better to highlight the cautions should someone want to make such an optimization or highlight perhaps that it's better not to do such an optimization). > HistInfo When used with the Supported header, [RFCXXXX] > this option tag indicates support > for the History Information to be > captured for requests and returned in > subsequent responses. This tag is not > used in a Proxy-Require or Requires > header field since support of > History-Info is optional. Require header field, not Requires. [MB]: Noted. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer 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 ------_=_NextPart_001_01C34FB7.D05D5394 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] comments on history-info-00

Jonathan,

Some initial responses are embedded below [MB].  = I do, however, have some more general comments that might also address = your concerns as follows:

- In general, it seems that alot of your confusion = around the fundamental processing of History-Info is around the fact = that we've optimized to only capturing a single URI, which adds to some = of the terminology concerns that you have. I'm beginning to wonder if = it wouldn't be better to go back to capturing both the retargeted-from = and retargeted-to URIs?  The advantage of this is that it doesn't = introduce this "seeding" or "kickstarting" of HI = when a proxy receives a request with no HI, which introduces these = special cases in the fundamental processing. What this also might be = highlighting is the need to bring some of the background text on the = solution options from appendix D into a background section that = precedes the normative text for HI.

- As I mentioned during the discussion, I fully agree = that there is a general lack of clarity (and as you suggest a need for = more precision) around the fundmental normative processing after = discussions with folks that are planning on implementing this draft. In = particular, the processing around the Index is quite unclear; I think = adding the index to all the examples and adding additional example = flows will also help with the concern here.

Regards,
Mary H. Barnes
mbarnes@nortelnetworks.com

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Tuesday, July 15, 2003 7:58 PM
To: sip@ietf.org
Subject: [Sip] comments on history-info-00


Mary,

Here are some comments on history-info. I suspect = many apply to prior
versions as well. My apologies if they have been = discussed, I have not
really followed the work closely. Many of my = comments are asking for
much more precision in the document. Generally, I = found it to be very
imprecise, with lots of undefined terminology and = vague procedures.

That aside, I have some major issues with the privacy = mechanisms, with
the usage of history-info by redirect servers, with = sending a 183 with
history information, and with the backwards = compatibility
implications. So, here we go:

Firstly, the draft says in many places that = applications need to
document the impact of things. For example, Section = 1.1 says:

    Thus, it is highly
    recommended that all applications = making use of the request history
    information clearly define the = impact of the information not being
    available and specify the = processing of such a request.

Does this mean there is some kind of application = registry where such
documentation will exist?
[MB]: No, I think the use of History-Info is no = different than any other optional SIP header and that application = scenarios in the form of call flows will be needed in Informational (or = as has become the trend BCPs) to effectively document the use of the = header.

Does it mean that applications won't be
interoperable because they will depend on the = presence of these
headers?
[MB]: Ditto my previous comment.

The text in 1.1 makes it sound like the information = would
only be present if some local policy prevented its = insertion.
[MB] I think you mean "didn't prevent" = rather than "prevented" in this preceeding sentence.  = And, yes,local policy is one factor that determines whether the = History-Info is inserted.

What about cases where the proxy doesn't support it? =
[MB]: Then, the information isn't captured for any = retargeting by that proxy, but any previous HI entries should remain, = since proxies should not remove headers.

Even if it does, your
draft reads very much like it is now going to = require every proxy to
insert this header. Is that so?
[MB]: No, it's an optional header. However, for = systems where this isn't supported, the functionality of an end = application might be limited.

Second, section 1.3 talks about the use of the = Privacy header. There
are a few problems here. First, the privacy header = gets stripped once
the privacy service finishes execution. Thus, a = downstream proxy would
not be able to know privacy was requested. To a = large degree, this is
because the privacy header in a request is about = privacy of the
caller. Request history is about the current target = (i.e., called
party). So, in fact, the issue is that if the = *called* party requests
privacy (using a privacy header in a response), the = history info
headers should not be propagated backwards in a = response. I dont think
your draft does that.

[MB]: This is similar to several threads of = discussion we had around the requirements about 6 months ago:
http://www1.ietf.org/mail-archive/working-groups/sippi= ng/current/msg03695.html
which I believe was addressed in a subsequent = revision to the requirements (although, I'll have to dig for the = details on that as I don't see that readily visible in the archives or = cached in my email archives at this = time).       

Local policy might also play a role, when it is = representing the
privacy interests of a user that is retargeting. In = that case, it was
unclear to me how the proxy prevents downstream = elements from
inserting history-info? Your draft makes it sound = like the privacy
requirements are met if just this one hop avoids = insertion. But seeing
the contact from downstream retargets will often = reveal sensitive
information about a target further upstream.

[MB]: I agree, I think local policy is this primary = mechanism for the privacy solution for HI and per the email = discussion.  As I highlighted in the meeting, the privacy aspects = of the solution are indeed incomplete and hopefully will be addressed = adequately in the next version.

Section 2.1:

> Targeted-to-URI: the Request URI captured as the = Request is
>         = targeted. By capturing a copy of the Request URI in the initial
>         = request, the Retargeted-from-URI is already captured when a
>         = request is retargeted and the Retargeted-to-URI is being
>         = captured.  
> 

I read this many times and could not make sense of = it. What does it mean?

[MB] This has to be read in context of the = definitions for Retargeted-from-URI and Retargeted-to-URI in the = Definitions section.  Because we're optimizing by capturing only a = single URI (the "new" URI in the request being retargeted) = rather than capturing both the "old" and "new" URIs = for each retargeting (and thus duplicating information since the = "new" of the previous HI entry would become the = "old" for the next entry).

Section 2.3.1:

> The UAC SHOULD include the HistInfo option tag = in the Supported
>    header in any request not = associated with an established dialog for
>    which the UAC would like the = History-Info in the Response.  In
>    addition, the UAC should = initiate the capturing of the History
>    Information by capturing the = Request-URI as the hi-targeted-to-uri
>    and initializing the index to = 1. 

What if the UAC doesn't support this extension? Can = the UAS get
history info? My understanding is that most, if not = all, evnisioned
applications were for the UAS. This means the UAS = can't get
information unless the caller and many, if not all, = proxies along the
path support it.

[MB] If the UAC doesn't include the option tag, then = that means that it won't get the History-Info in any responses.  = Whether the proxy captures History-Info is local policy; the text is = attempting to state that if the proxy is planning on capturing = History-Info then it goes ahead and creates the "zero-th" = entry.  We originally were capturing 2 URIs, the original request = URI and the retargeted-to URI. However, to minimize the overhead and = duplicate data, we made the change in the -01 individual draft to only = capture one URI, so that you basically need to "seed" the = chain of URIs to capture the History, by capturing the original URI at = the time of the first re-targeting that you're intending to = capture.  So, the UAS can get the information even if the caller = doesn't want it in responses.  You are correct that for many = applications, it would be necessary for many of the proxies along the = path to support it. 

Section 2.3.2:

> The processing of History-Info by a UAS in a = Request depends upon
>    local policy and specific = applications at the UAS which might make
>    use of the information.  = If the HistInfo option tag is received in a
>    request, the UAS should = include any History-Info received in the
>    request in the subsequent resp= onse.    

I think you mean SHOULD in the last sentence. Also, I = think you mean
that "If the request contained the histinfo = option tag in the
Supported header field of the request, the = UAS....".

[MB] Correct.

Also, you've capitalized the H and I in HistInfo. = Please don't. Option
tags are not case sensitive.

[MB] Noted.

Section 2.3.3:

The wording about when to capture is really vague. = You need to be much
more precise in your wording of when the proxy is = and isnt going to
capture history information.

[MB]: As I mentioned during my presentation of issues = during the WG meeting, this was the same feedback I had received from = some folks that in the process of implementing this and I do improve = this in the next version. However, this section was intended to be a = higher level overview of the processing with the subsequent = sub-sections intended to provide the details of the normative = processing.

Section 2.3.3.1:

>  If the proxy supports History-Info, the = proxy SHOULD add any History-
>    Info collected as it = retargets a Request. For retargets that are the
>    result of an explicit SIP = response, the SIP Response Code that
>    triggered the retargeting = MUST be included in the Reason header of
>    the Targeted-to-URI.

This needs to be more precise. What does it mean = "..collected as it
retargets a request"? How is this information = collected? Also, when
you say "explicit SIP response" - all = responses are explicit as far as
I know. Perhaps you mean when a 3xx response is = received? Also, you
say "Reason header of the = Targeted-to-URI". I believe reason is a
parameter, not a header, in this instance.

and then:
> For retargets as a result of timeouts or =
>    internal events, a Reason = header MAY be included in the Reason header
>    of the Targeted-to-URI. =

what are internal events?

[MB]: This was also something I mentioned at the = meeting and has to do with "internal retargeting" which can = be the result of things like selecting the route in a route list, etc. = ******************************************

What value does the reason parameter have in the case = of timeout? In
the case of internal events?

[MB]: It lets an application or end user know why the = retargeting occurred.

and then:
>  Additionally, if a request is received = that doesn't include a
>    captured Request URI from the = previous entity, the proxy MAY add an
>    additional entry, effectively = capturing the retargeted-from-URI in
>    the Request.   =


What does it mean for a request to "not include = a captured
Request-URI"? You need to define that. What is = contained in the
additional entry?

[MB]: Per my general comment at the beginning of my = email response, this has to do with the current mechanism of only = capturing a single URI.

I may sound like I am being nit-picky, but in my = experience
specifications need to be very precise in what you = want people to do.
I am confused about what is implied here, and I = would imagine many
others would be confused too.

[MB]: Again, as I mentioned during the meeting, this = is an open issue with the draft that I plan to correct on the next = version.

and then:

> In order to maintain ordering and accurately = reflect the nesting and
>    retargeting of the request, = an index MUST be included along with the
>    Targeted-to-URI being = captured. The basic rule for adding the index
>    are to read the value from = the previous History-Info, if available,
>    and capture the index.n as = the index for the History-Info being
>    captured, where n would = typically be 1 for a forwarded request. Thus,
>    the level of nesting of the = index reflects the number of hops.

define previous.

what does it mean to "capture the index.n"? = what is index? what is .n?
  You say its "typically 1". When is = it 1, and when is it not one?

and then:
> For
>    retargets within a proxy, the = proxy MUST maintain the current level
>    of nesting by incrementing = the lowest/last digit of the index for
>    each instance of retargeting, = thus reflecting the number of retargets
>    within the proxy.

I cannot understand this at all.

and then:
> n index MUST NOT be added
>    in the scenario whereby the = received request had no History-Info
>    header and the = retargeted-from-URI is being captured for
>    completeness.

what does "for completeness" mean? You need = to be precise.

[MB]: Another issue related to the general mechanism = of capturing a single URI that I mentioned at the beginning of my email = response.

> The lack of Reason headers in the captured = Request-URIs should be
>    indicative of the parallel = nature of forking (i.e the Request-URIs
>    are not the result of = retargets, but are rather all simultaneous
>    Targeted-To URIs.)  =

should be indicative? Is it, or isnt it?

[MB] Correct. I'll change this from "should = be" to "is"

> A proxy that receives a Request with the = HistInfo option tag in the
>    Supported header, and = depending upon a local policy supporting the
>    capture of History-Info, = SHOULD return captured History-Info in
>    subsequent, provisional and = final responses to the Request.  A 183
>    response MAY be sent = explicitly for the purposes of conveying
>    History-Info prior to the = final response.

I think the first sentence means that the proxy does = nothing to
responses - any history-info in those responses is = just passed on. But
I'm not sure. The sentence says "should = return", and return seems like
an active operation to me.
[MB]: The use of HI does not at all change the = messaging, but rather just adds the captured information to the = response in the scenarios where it has been captured. It is not = intended to be an "active" operation. 

The next sentence actually implies that the
proxy generate a 183 provisional responses.
[MB]: No, that's not what was intended.  This = sentence was added in response to a concern raised that HI didn't = appear to be allowed to be sent in provisional responses.  =

This means that a UA
making a call with N proxies will get N extra = provisional responses,
where the first has one history-info value, the next = 2, the next 3,
and so on. The first history info is transmitted to = the UAC N times.
Is that really what we want? It seems very expensive = for the UAC.
[MB]: Per my response to a previous comment above, = HI does not at all change the fundamental messaging, but rather just = adds the captured information to the response in the scenarios where it = has been captured.


> It MAY be advantageous for redirect servers to = support the receipt of
>    History-Info in = requests.

You can you assign a protocol strength to being = advantageous?

I think you mean "A redirect server MAY use = information in the
History-Info header field in a request to determine = the URIs that it
will retarget to.".

[MB] Agreed; your suggested wording is a more = accurate representation of the intent of the original statement. =

> By receiving it in the request, the
>    Redirect Server MAY be able = to optimize the information it sends in
>    responses by looking at the = already targeted-to-URIs.

and what optimization is that? I think you mean that = the redirect
server shouldnt redirect to somewhere that the = request has already
visited. If so, please say that. However, are we = sure about that?
Redirection to a URI already visited can be = appropriate in cases where
there is a spiral, and not a loop. Unless a redirect = server is
maintaining state, how can it make this = determiantionabout whether
this is a spiral or a loop?

[MB]: You bring up a valid point that should be = clarified.  It might be better to just remove that statement since = it really is an implementation decision and as you suggest such = "optimizations" could be problematic in some scenarios.  = (Although, it might be better to highlight the cautions should someone = want to make such an optimization or highlight perhaps that it's better = not to do such an optimization).



> HistInfo      When used = with the Supported header, [RFCXXXX]
>          = ;        this option tag indicates = support
>          = ;        for the History Information = to be 
>          = ;        captured for requests and = returned in
>          = ;        subsequent responses. This = tag is not
>          = ;        used in a Proxy-Require or = Requires 
>          = ;        header field since support = of 
>          = ;        History-Info is = optional.      


Require header field, not Requires.

[MB]: Noted.


Thanks,
Jonathan R.

--
Jonathan D. Rosenberg, = Ph.D.           &= nbsp;    600 Lanidex Plaza
Chief Technology = Officer           = ;         Parsippany, NJ = 07054-2711
dynamicsoft
jdrosen@dynamicsoft.com      &nbs= p;           &nbs= p;  FAX:   (973) 952-5050
http://www.jdrosen.net    &nbs= p;           &nbs= p;     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

------_=_NextPart_001_01C34FB7.D05D5394-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 24 10:33:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09037 for ; Thu, 24 Jul 2003 10:33:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fh91-0000RN-1C for sip-archive@odin.ietf.org; Thu, 24 Jul 2003 10:32:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OEWYQP001629 for sip-archive@odin.ietf.org; Thu, 24 Jul 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 19fh7X-000085-7q; Thu, 24 Jul 2003 10: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 19dTB0-0001eN-M6 for sip@optimus.ietf.org; Fri, 18 Jul 2003 07:13: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 HAA27082 for ; Fri, 18 Jul 2003 07:13:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dTB0-000042-00 for sip@ietf.org; Fri, 18 Jul 2003 07:13:26 -0400 Received: from e-eihq01.eis.ernet.in ([202.41.97.131]) by ietf-mx with esmtp (Exim 4.12) id 19dTAo-00003X-00 for sip@ietf.org; Fri, 18 Jul 2003 07:13:14 -0400 Received: from uucp-relay-delhi.ernet.in by e-eihq01.eis.ernet.in (8.10.2/1.1.2.10/13Jul01-0336PM) id h6IBbkk0000027531; Fri, 18 Jul 2003 16:37:46 +0500 (GMT+0500) Received: by uucp-relay-delhi.ernet.in (8.9.3+Sun/SMI-4.1-MHS-7.0) id QAA21742; Fri, 18 Jul 2003 16:49:04 -0500 (GMT) >Received: from cancer.cdotd.ernet.in by cdotd.cdotd.ernet.in (SMI-8.6/SMI-SVR4) id QAA25978; Fri, 18 Jul 2003 16:24:24 -0500 Message-ID: <3F17D442.3344F21E@cdotd.ernet.in> Date: Fri, 18 Jul 2003 16:34:34 +0530 From: Manish Rathi X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.11.00 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Received: from cdotd by vikram.eis.ernet.in; Fri, 18 Jul 2003 16:49 GMT Content-Type: multipart/alternative; boundary="------------6694E02067B363CACD1A716E" Subject: [Sip] sip implementation Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --------------6694E02067B363CACD1A716E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Can anybody tell me abt sip implementation framework. Manish -- Things work out best for those who make the best use of it. --------------6694E02067B363CACD1A716E Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,
Can anybody tell me abt sip implementation framework.

Manish 

-- 
Things work out best for those who make the best use of it.
  --------------6694E02067B363CACD1A716E-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Jul 28 11:09:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05040 for ; Mon, 28 Jul 2003 11:09:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h9cN-0001MI-05 for sip-archive@odin.ietf.org; Mon, 28 Jul 2003 11:08:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SF8s3R005218 for sip-archive@odin.ietf.org; Mon, 28 Jul 2003 11:08:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h9bW-0001IQ-RN; Mon, 28 Jul 2003 11: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 19h9bF-0001Co-QA for sip@optimus.ietf.org; Mon, 28 Jul 2003 11:07:45 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04831; Mon, 28 Jul 2003 11:07:40 -0400 (EDT) Message-Id: <200307281507.LAA04831@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 28 Jul 2003 11:07:39 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-resource-priority-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Communications Resource Priority for the Session Initiation Protocol (SIP) Author(s) : H. Schulzrinne, J. Polk Filename : draft-ietf-sip-resource-priority-01.txt Pages : 24 Date : 2003-7-28 This document defines two new SIP header fields for communications resource priority, namely 'Resource-Priority' and 'Accept-Resource- Priority'. The Resource-Priority header field can influence the behavior of SIP UAs, such as GSTN gateways, and SIP proxies. It does not directly 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-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-resource-priority-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-resource-priority-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-7-28111447.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-resource-priority-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-resource-priority-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-28111447.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 Mon Jul 28 14:11:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14651 for ; Mon, 28 Jul 2003 14:11:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hCT1-00019H-Um for sip-archive@odin.ietf.org; Mon, 28 Jul 2003 14:11:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SIBRBq004394 for sip-archive@odin.ietf.org; Mon, 28 Jul 2003 14:11:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hCSd-00017x-An; Mon, 28 Jul 2003 14:11:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hCS4-00016f-6S for sip@optimus.ietf.org; Mon, 28 Jul 2003 14:10:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14604 for ; Mon, 28 Jul 2003 14:10:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hCS1-0006Jn-00 for sip@ietf.org; Mon, 28 Jul 2003 14:10:25 -0400 Received: from marionberry.cc.columbia.edu ([128.59.59.100] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19hCS0-0006Jk-00 for sip@ietf.org; Mon, 28 Jul 2003 14:10:25 -0400 Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h6SIAGUr015088 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 28 Jul 2003 14:10:23 -0400 (EDT) Message-ID: <3F256707.5040306@cs.columbia.edu> Date: Mon, 28 Jul 2003 14:10:15 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 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-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Subject: [Sip] draft-ietf-resource-priority-01 draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The revised version of the draft, based on discussions in Vienna, is now in the archives. I would appreciate comments http://www.ietf.org/internet-drafts/draft-ietf-sip-resource-priority-01.txt Thanks. 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 Wed Jul 30 17:28:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18866 for ; Wed, 30 Jul 2003 17:28:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hyUK-0005SV-Ty for sip-archive@odin.ietf.org; Wed, 30 Jul 2003 17:28:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ULS0O2020960 for sip-archive@odin.ietf.org; Wed, 30 Jul 2003 17:28:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hyTN-0005H6-H0; Wed, 30 Jul 2003 17:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hySx-0005GR-Gj for sip@optimus.ietf.org; Wed, 30 Jul 2003 17:26: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 RAA18756 for ; Wed, 30 Jul 2003 17:26:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hySv-0003q0-00 for sip@ietf.org; Wed, 30 Jul 2003 17:26:33 -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 19hySu-0003pC-00 for sip@ietf.org; Wed, 30 Jul 2003 17:26:32 -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 h6ULPrJn002514 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 30 Jul 2003 16:25:53 -0500 From: "Dean Willis" To: Cc: Date: Wed, 30 Jul 2003 16:25:43 -0500 Message-ID: <005801c356e1$225b8780$ee036e3f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Slides from SIP meeting posted Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I THINK I have all slides from the recent SIP WG meeting posted at: http://www.softarmor.com/sipwg/meets/ietf57/slides/index.html If you presented slides please check and make sure they're there. If I'm missing something please let me know. Thanks, -- 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 Wed Jul 30 17:40:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19229 for ; Wed, 30 Jul 2003 17:40:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hyfg-0006K3-AQ for sip-archive@odin.ietf.org; Wed, 30 Jul 2003 17:39:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ULditF024304 for sip-archive@odin.ietf.org; Wed, 30 Jul 2003 17:39:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hyez-00068b-VN; Wed, 30 Jul 2003 17: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 19hyeL-000683-Op for sip@optimus.ietf.org; Wed, 30 Jul 2003 17:38:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19174 for ; Wed, 30 Jul 2003 17:38:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hyeJ-0003uz-00 for sip@ietf.org; Wed, 30 Jul 2003 17:38:19 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19hyeI-0003um-00 for sip@ietf.org; Wed, 30 Jul 2003 17:38:18 -0400 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6ULbPpp026449; Wed, 30 Jul 2003 14:37:25 -0700 (PDT) Received: from cisco.com (klingle-linux.cisco.com [64.102.93.48]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIY12371; Wed, 30 Jul 2003 14:37:24 -0700 (PDT) Message-ID: <3F283A94.1000901@cisco.com> Date: Wed, 30 Jul 2003 17:37:24 -0400 From: Kevin Lingle User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" CC: sip@ietf.org, jmaeng@ipdialog.com, drwalker@ss8.com, jf.mule@cablelabs.com, "Bert Wijnen (E-mail)" References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Comments on draft-ietf-sip-mib-06.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit dan, thanks for the comments. see responses/questions inline... Romascanu, Dan (Dan) wrote: > Here are my comments concerning the latest version of the SIP MIB. I > congratulate the authors for a much better document, and I thank them > for taking into account and including fixes to most of the problems that > were included in the review I did on the previous version. > > There are still a few problems that need to be fixed: > > A1) smilint complains about the following: > > SIP-COMMON.txt:2014: [5] {integer-misuse} warning: use Integer32 instead > of INTEGER in SMIv2 -- for sipStatusCodeValue -- done. used Unsigned32 actually as the range is postive. > > SIP-COMMON.txt:2940: [5] {group-unref} warning: current group > `sipCommonNotifObjectsGroup' is not referenced in this module i presume adding a GROUP clause to the module-compliance will fix this. i can do that. however, my understanding is that if a group is not mentioned, it's considered optional. at any rate, i'll add the GROUP clause - as there's one for each other optional group. > > A2) You would like to re-consider the OID place holders that you created > for sipRedirCfg, sipRedirStats, sipRegCfg, sipRegStats. > > This is not an SMI violation, but it creates for the time being a hole > in a MIB walk. If you need to add the definition of the respective > objects in the future, you will not be able to do it in the same > document, without the need to re-cycle the document at Proposed Standard > level. ok. as this has come up at least a couple of times now, i'll remove them. > > A3) DESCRIPTION Clause of sipServiceNotifEnable - Saying that in case > notifications are not implemented, the value has 'no meaning and MUST be > 0', seems contradictory and inaccurate. The respective sentence should > read - 'The notifications are OPTIONAL, and if they are not implemented, > this object's value MUST be all 0s.' > > A4) How does sipNotifSequenceNumber work? It should probably be > increased once for each notification defined in the SIP MIBs, but not > for each notification target (in the case of multiple managers). I > suggest this to be detailed in the DESCRIPTION clause for clarity. > > > > Minor editorial issues: > > B1) English syntax in section 4.1. It should probably read 'The data > type SipTransportProtocol is used as Textual Convention in this > document. Textual conventions have...' done. > > B2) Eliminate the commented text in the SIP compliance module of the UA > MIB. you mean where it says "SMIC compiler problems"? realize that OBJECT refinement was added in response to one of your previous comments on rev -05... "B9 - If only a subset of the values of a TC is supported, like in the case of sipUACfgSipServerAddrStatus, this needs to be reflected in the compliance clauses. See Section 4.8 of http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-01.txt for an example" so remove it completely?? kevin > > Regards, > > Dan > -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kevin R. Lingle 919.392.2029 http://www.klove.com http://www.air1.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 Wed Jul 30 17:54:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19712 for ; Wed, 30 Jul 2003 17:54:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hytF-0006y2-Cx for sip-archive@odin.ietf.org; Wed, 30 Jul 2003 17:53:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ULrjv4026733 for sip-archive@odin.ietf.org; Wed, 30 Jul 2003 17:53:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hysX-0006lZ-HF; Wed, 30 Jul 2003 17:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hyrY-0006i9-43 for sip@optimus.ietf.org; Wed, 30 Jul 2003 17:52: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 RAA19632 for ; Wed, 30 Jul 2003 17:51:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hyrV-00044X-00 for sip@ietf.org; Wed, 30 Jul 2003 17:51: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 19hyrU-00044E-00 for sip@ietf.org; Wed, 30 Jul 2003 17:51:57 -0400 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6ULpLuG019114; Wed, 30 Jul 2003 14:51:22 -0700 (PDT) Received: from cisco.com (klingle-linux.cisco.com [64.102.93.48]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIY15766; Wed, 30 Jul 2003 14:51:20 -0700 (PDT) Message-ID: <3F283DD8.8090502@cisco.com> Date: Wed, 30 Jul 2003 17:51:20 -0400 From: Kevin Lingle User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" CC: sip@ietf.org, jmaeng@ipdialog.com, drwalker@ss8.com, jf.mule@cablelabs.com, "Bert Wijnen (E-mail)" References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Comments on draft-ietf-sip-mib-06.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit one mistake... Romascanu, Dan (Dan) wrote: > A2) You would like to re-consider the OID place holders that you created > for sipRedirCfg, sipRedirStats, sipRegCfg, sipRegStats. sipRegCfg and sipRegStats aren't placeholders. they have actual objects defined under them. i'll remove the redirect related placeholders though. kevin -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kevin R. Lingle 919.392.2029 http://www.klove.com http://www.air1.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 Wed Jul 30 18:48:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22388 for ; Wed, 30 Jul 2003 18:48:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hzk2-0000la-9P for sip-archive@odin.ietf.org; Wed, 30 Jul 2003 18:48:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UMmIqJ002929 for sip-archive@odin.ietf.org; Wed, 30 Jul 2003 18:48:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hzjl-0000kp-Tn; Wed, 30 Jul 2003 18: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 19hzj0-0000kZ-2X for sip@optimus.ietf.org; Wed, 30 Jul 2003 18:47: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 SAA22342 for ; Wed, 30 Jul 2003 18:47:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hzix-0004me-00 for sip@ietf.org; Wed, 30 Jul 2003 18:47:11 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19hziw-0004lk-00 for sip@ietf.org; Wed, 30 Jul 2003 18:47:10 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 30 Jul 2003 15:48:39 -0700 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6UMjdLH028853; Wed, 30 Jul 2003 15:45:39 -0700 (PDT) Received: from cisco.com (klingle-linux.cisco.com [64.102.93.48]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIY28431; Wed, 30 Jul 2003 15:45:38 -0700 (PDT) Message-ID: <3F284A92.8050207@cisco.com> Date: Wed, 30 Jul 2003 18:45:38 -0400 From: Kevin Lingle User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" CC: Kevin Lingle , sip@ietf.org, jmaeng@ipdialog.com, drwalker@ss8.com, jf.mule@cablelabs.com, "Bert Wijnen (E-mail)" References: <3F283A94.1000901@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Comments on draft-ietf-sip-mib-06.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit dan, other question... Kevin Lingle wrote: >> >> B2) Eliminate the commented text in the SIP compliance module of the >> UA MIB. > > > you mean where it says "SMIC compiler problems"? if you do mean this... there is an occurrence in the SIP-COMMON-MIB as well. remove it as well?? kevin > > realize that OBJECT refinement was added in response to one of your > previous comments on rev -05... > > "B9 - If only a subset of the values of a TC is supported, like in > the case of sipUACfgSipServerAddrStatus, this needs to be reflected > in the compliance clauses. See Section 4.8 of > http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-01.txt > > for an example" > > so remove it completely?? > > kevin > >> >> Regards, >> >> Dan >> > > -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kevin R. Lingle 919.392.2029 http://www.klove.com http://www.air1.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 Wed Jul 30 19:39:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23498 for ; Wed, 30 Jul 2003 19:39:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i0XL-0002Op-Vm for sip-archive@odin.ietf.org; Wed, 30 Jul 2003 19:39:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UNdFrg009217 for sip-archive@odin.ietf.org; Wed, 30 Jul 2003 19:39:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i0X7-0002OE-7p; Wed, 30 Jul 2003 19: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 19i0WR-0002Nv-Bv for sip@optimus.ietf.org; Wed, 30 Jul 2003 19:38: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 TAA23391; Wed, 30 Jul 2003 19:38:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i0WP-0005Ez-00; Wed, 30 Jul 2003 19:38:17 -0400 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 19i0WO-0005Eu-00; Wed, 30 Jul 2003 19:38:16 -0400 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h6UNcGJ10514; Wed, 30 Jul 2003 16:38:16 -0700 (PDT) Message-Id: <200307302338.h6UNcGJ10514@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, sip@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 30 Jul 2003 16:38:16 -0700 Subject: [Sip] RFC 3319 on Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (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: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3319 Title: Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers Author(s): H. Schulzrinne, B. Volz Status: Standards Track Date: July 2003 Mailbox: schulzrinne@cs.columbia.edu, volz@metrocast.net Pages: 7 Characters: 14444 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sip-dhcpv6-01.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3319.txt This document defines a Dynamic Host Configuration Protocol version 6 (DHCPv6) option that contains a list of domain names or IPv6 addresses that can be mapped to one or more Session Initiation Protocol (SIP) outbound proxy servers. This is one of the many methods that a SIP client can use to obtain the addresses of such a local SIP server. This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030730163622.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3319 --OtherAccess Content-Type: Message/External-body; name="rfc3319.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030730163622.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip