From exim@www1.ietf.org Mon May 3 05:33:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17029 for ; Mon, 3 May 2004 05:33:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKZlk-0001CP-Vx for sip-archive@odin.ietf.org; Mon, 03 May 2004 05:29:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i439TmFs004541 for sip-archive@odin.ietf.org; Mon, 3 May 2004 05:29:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKZfF-0007WR-7T; Mon, 03 May 2004 05:23:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKZYx-0004qb-8z for sip@optimus.ietf.org; Mon, 03 May 2004 05:16: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 FAA16043 for ; Mon, 3 May 2004 05:16:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKZYu-0002it-1J for sip@ietf.org; Mon, 03 May 2004 05:16:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKZVv-0002Bb-00 for sip@ietf.org; Mon, 03 May 2004 05:13:28 -0400 Received: from [80.74.106.125] (helo=rvil-mail.RADVISION.com) by ietf-mx with esmtp (Exim 4.12) id 1BKZSD-0001WL-00 for sip@ietf.org; Mon, 03 May 2004 05:09:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 May 2004 12:11:15 +0300 Message-ID: <10DA2C035FE3BC4FA8D73EC55FC43D9B047A6C@rvil-mail.radvision.com> Thread-Topic: Session Timer - Terminology is no clear Thread-Index: AcQw7pZWAR3d0RSkRiaUJjaGuGx13g== From: "Sarit Galanos" To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Sip] Session Timer - Terminology is no clear Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org 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, The session timer draft uses the term "Initial Session Refresh Request". The draft defines that=20 "Session Refresh Request: An INVITE or UPDATE request = within a dialog." >From that I understand that "Initial Session Refresh Request" is the = first re-Invite or Update inside that dialog. But, If the dialog was established with session timer parameters and = after the first INVITE-200-ACK session time is already active, why is there a difference between the initial refresh and further = refreshes. Or is that the "Initial Session Refresh Request" is the first request = that has session timer parameters and it can also be the initial INVITE? Thanks, Sarit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 3 10:43:50 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05834 for ; Mon, 3 May 2004 10:43: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 1BKeXt-0004S7-Hv for sip-archive@odin.ietf.org; Mon, 03 May 2004 10:35:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43EZnw2017116 for sip-archive@odin.ietf.org; Mon, 3 May 2004 10:35:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKeNU-0001t2-OP; Mon, 03 May 2004 10:25:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKeIB-0007sJ-DR for sip@optimus.ietf.org; Mon, 03 May 2004 10:19: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 KAA03698 for ; Mon, 3 May 2004 10:19:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKeI9-00049J-5m for sip@ietf.org; Mon, 03 May 2004 10:19:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKeDG-0003MU-00 for sip@ietf.org; Mon, 03 May 2004 10:14:32 -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 1BKe5U-0001yz-00 for sip@ietf.org; Mon, 03 May 2004 10:06:28 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i43E5sSu009149; Mon, 3 May 2004 07:05:55 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIC38746; Mon, 3 May 2004 10:05:53 -0400 (EDT) Message-ID: <409651C0.20209@cisco.com> Date: Mon, 03 May 2004 10:05:52 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sarit Galanos CC: sip@ietf.org Subject: Re: [Sip] Session Timer - Terminology is no clear References: <10DA2C035FE3BC4FA8D73EC55FC43D9B047A6C@rvil-mail.radvision.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 language in this is at times obscure. I think in part this results from the age of the document. (It has been in progress for years, I think since before 2543bis. So terminology has changed around it.) Part of the problem is that it is written as if a reINVITE or UPDATE is done solely for the purpose of session timer refresh. But in reality things are not that simple. A reINVITE or an UPDATE does a bunch of stuff. If session-timer is supported then refreshing, or cancelling, a session timer is one of the things it does. Any time a reINVITE or UPDATE is sent, it will affect the session timer one way or another, whether that was the primary intent in sending the message, or not. There also isn't anything special about the "first" refresh. The request that first establishes a dialog also establishes some kind of session timer state - either leaving it disabled, or running. Every subsequent reINVITE, UPDATE (and reSUBSCRIBE too) does the same thing - restablishes a new session timer or else leaves the dialog with none. There is no need to consider what the previous state was - the new state is not affected by that. All that the session timer mechanism does is force a reINVITE or UPDATE to happen by a particular time if one hasn't happened for any other reason. Paul Sarit Galanos wrote: > Hi, > The session timer draft uses the term "Initial Session Refresh Request". > > The draft defines that > "Session Refresh Request: An INVITE or UPDATE request within a dialog." > >>From that I understand that "Initial Session Refresh Request" is the first re-Invite or Update inside that dialog. > > But, If the dialog was established with session timer parameters and after the first INVITE-200-ACK session time is already active, > why is there a difference between the initial refresh and further refreshes. > Or is that the "Initial Session Refresh Request" is the first request that has session timer parameters > and it can also be the initial INVITE? > > Thanks, > Sarit > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 May 4 15:11:48 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22278 for ; Tue, 4 May 2004 15:11: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 1BL5GS-0007St-OX for sip-archive@odin.ietf.org; Tue, 04 May 2004 15:07:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44J7ag5028695 for sip-archive@odin.ietf.org; Tue, 4 May 2004 15:07:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL58A-0007J6-1i; Tue, 04 May 2004 14:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKwaK-0006j3-KY for sip@optimus.ietf.org; Tue, 04 May 2004 05:51: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 FAA19194 for ; Tue, 4 May 2004 05:51:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKwaG-0001kw-P5 for sip@ietf.org; Tue, 04 May 2004 05:51:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKwZJ-0001aB-00 for sip@ietf.org; Tue, 04 May 2004 05:50:30 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 1BKwYk-0001PN-00 for sip@ietf.org; Tue, 04 May 2004 05:49:55 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 4 May 2004 11:49:52 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C431BD.25E72676" X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Subject: [Sip] Bug in RFC3261 ? Date: Tue, 4 May 2004 11:49:52 +0200 Message-ID: Thread-Topic: [Sip] Bug in RFC3261 ? Thread-Index: AcQxvSWF3bxn2sxPRD2+QvE/eXZlPQ== From: =?iso-8859-1?Q?PROUVOST_S=E9bastien_FTRD/DAC/ISS?= To: X-OriginalArrivalTime: 04 May 2004 09:49:52.0975 (UTC) FILETIME=[260665F0:01C431BD] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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_01C431BD.25E72676 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi,=20 In RFC 3261, it is written (section 8.1.3.3 for UAC Core procedures) : = "If more than one Via header field value is present in a response, the = UAC SHOULD discard the message." However if the UAC Core layer discards the response and if this response = was the only one sent (for example a 200 OK to an UPDATE), then this = leads to a situation when the transaction is terminated (the transaction = layer received the response and passed it to the UA Core) but the UA = Core is still waiting for a response (it discarded the 200 OK because of = the presence of two Via header field values and so is still waiting for = the response). I believe there shall be procedures that tells the UAC Core when to stop = waiting for the response. Or am I misunderstanding something ?=20 Thanks for your clarifications,=20 S=E9bastien Prouvost France Telecom R&D ------_=_NextPart_001_01C431BD.25E72676 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Sip] Bug in RFC3261 ?

Hi,
In RFC 3261, it is written = (section 8.1.3.3 for UAC Core procedures) : "If more than one Via = header field value is present in a response, the UAC SHOULD discard the = message."

However if the UAC Core layer = discards the response and if this response was the only one sent (for = example a 200 OK to an UPDATE), then this leads to a situation when the = transaction is terminated (the transaction layer received the response = and passed it to the UA Core) but the UA Core is still waiting for a = response (it discarded the 200 OK because of the presence of two Via = header field values and so is still waiting for the = response).

I believe there shall be = procedures that tells the UAC Core when to stop waiting for the = response. Or am I misunderstanding something ?

Thanks for your = clarifications,

S=E9bastien Prouvost
France Telecom R&D


------_=_NextPart_001_01C431BD.25E72676-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 4 18:48:58 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05204 for ; Tue, 4 May 2004 18:48:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL8gF-0005uS-6q for sip-archive@odin.ietf.org; Tue, 04 May 2004 18:46:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44MkR2j022716 for sip-archive@odin.ietf.org; Tue, 4 May 2004 18:46:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL8Z5-00049M-GE; Tue, 04 May 2004 18:39:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL8X6-0003KR-CM for sip@optimus.ietf.org; Tue, 04 May 2004 18:37: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 SAA04724 for ; Tue, 4 May 2004 18:36:55 -0400 (EDT) From: Ben.Gatewood@didata.com.au Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL8X3-0002vA-74 for sip@ietf.org; Tue, 04 May 2004 18:36:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL8WC-0002p1-00 for sip@ietf.org; Tue, 04 May 2004 18:36:05 -0400 Received: from nwynmime1.didata.com.au ([148.182.16.79]) by ietf-mx with esmtp (Exim 4.12) id 1BL8VK-0002cl-00; Tue, 04 May 2004 18:35:10 -0400 Received: from internet.didata.com.au (unverified [148.182.20.65]) by nwynmime1.didata.com.au (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Wed, 5 May 2004 08:33:15 +1000 To: PROUVOST =?iso-8859-1?Q?S=E9bastien_FTRD=2FDAC=2FISS?= Cc: sip@ietf.org, sip-admin@ietf.org Subject: Re: [Sip] Bug in RFC3261 ? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: Date: Wed, 5 May 2004 08:33:12 +1000 X-MIMETrack: Serialize by Router on SYDMTA/Sydney/Com Tech/AU (Release 5.0.9a |January 7, 2002) at 05/05/2004 08:33:13, Serialize complete at 05/05/2004 08:33:13 Content-Type: multipart/alternative; boundary="=_alternative 007BE3DBCA256E8A_=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,EXCUSE_16,HTML_20_30, HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 007BE3DBCA256E8A_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi S=E9bastien, There are procedures and timers for this situation in 3261. Have a look at= Section 17.1.1.2 and 17.1.2.2.=20 Basically the UA should wait 64*T1 (Timer 1). T1, by default, should be=20 500ms so your UA should wait 32 seconds for a valid response. HTH, B Ben Gatewood Dimension Data SIP Wookie Level 1 10 Dorcas Street South Melbourne +61 3 9626 0735 +61 419 885 762 ben.gatewood@didata.com.au PROUVOST S=E9bastien FTRD/DAC/ISS Sent by: sip-admin@ietf.org 04/05/2004 07:49 PM =20 To: cc:=20 Subject: [Sip] Bug in RFC3261 ? Hi,=20 In RFC 3261, it is written (section 8.1.3.3 for UAC Core procedures) : "If= more than one Via header field value is present in a response, the UAC=20 SHOULD discard the message." However if the UAC Core layer discards the response and if this response=20 was the only one sent (for example a 200 OK to an UPDATE), then this leads= to a situation when the transaction is terminated (the transaction layer= received the response and passed it to the UA Core) but the UA Core is=20 still waiting for a response (it discarded the 200 OK because of the=20 presence of two Via header field values and so is still waiting for the=20 response). I believe there shall be procedures that tells the UAC Core when to stop=20 waiting for the response. Or am I misunderstanding something ?=20 Thanks for your clarifications,=20 S=E9bastien Prouvost=20 France Telecom R&D=20 ***************************************************************************= *** - NOTICE FROM DIMENSION DATA AUSTRALIA This message is confidential, and may contain proprietary or legally privil= eged information. If you have received this email in error, please notify = the sender and delete it immediately. Internet communications are not secure. You should scan this message and an= y attachments for viruses. Under no circumstances do we accept liability f= or any loss or damage which may result from your receipt of this message or= any attachments. ***************************************************************************= *** --=_alternative 007BE3DBCA256E8A_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi S=E9bastien,

There are procedures and timers for = this situation in 3261. Have a look at Section 17.1.1.2 and 17.1.2.2.

Basically the UA should wait 64*T1 (= Timer 1). T1, by default, should be 500ms so your UA should wait 32 seconds= for a valid response.

HTH,

B

Ben Gatewood
Dimension Data
SIP Wookie
Level 1 10 Dorcas Street South Melbourne
+61 3 9626 0735
+61 419 885 762
ben.gatewood@didata.com.au


PROUVOST S=E9bastien FTRD/DAC/ISS= <sebastien.prouvost@francetelecom.com>
Sent by: sip-admin@ietf.org

04/05/2004 07:49 PM

       
        To: &nbs= p;      <sip@ietf.org>
        cc: &nbs= p;      
        Subject:=        [Sip] Bug in RFC3261 ?



Hi,
In RFC 3261, it is written (section 8.1.3.3 for UAC Core procedures) : &quo= t;If more than one Via header field value is present in a response, the UAC= SHOULD discard the message."

However if the UAC Core layer discar= ds the response and if this response was the only one sent (for example a 2= 00 OK to an UPDATE), then this leads to a situation when the transaction is= terminated (the transaction layer received the response and passed it to t= he UA Core) but the UA Core is still waiting for a response (it discarded t= he 200 OK because of the presence of two Via header field values and so is = still waiting for the response).

I believe there shall be procedures = that tells the UAC Core when to stop waiting for the response. Or am I misu= nderstanding something ?

Thanks for your clarifications,

S=E9bastien Prouvost
France Telecom R&D



***************************************************************************= ***
- NOTICE FROM DIMENSION DATA AUSTRALIA
This message is confidential, and may contain proprietary or legally privil= eged information. If you have received this email in error, please notify = the sender and delete it immediately.

Internet communications are not secure. You should scan this message and an= y attachments for viruses. Under no circumstances do we accept liability f= or any loss or damage which may result from your receipt of this message or= any attachments.
***************************************************************************= ***
 --=_alternative 007BE3DBCA256E8A_=-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 4 20:20:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09912 for ; Tue, 4 May 2004 20: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 1BLA78-0003gg-Jf for sip-archive@odin.ietf.org; Tue, 04 May 2004 20:18:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i450IIsh014169 for sip-archive@odin.ietf.org; Tue, 4 May 2004 20:18:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL9z9-0001df-Jx; Tue, 04 May 2004 20:10:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL9tI-0008Qg-J5 for sip@optimus.ietf.org; Tue, 04 May 2004 20:04:03 -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 UAA09319 for ; Tue, 4 May 2004 20:03:58 -0400 (EDT) From: Ben.Gatewood@didata.com.au Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL9tG-000691-MI for sip@ietf.org; Tue, 04 May 2004 20:03:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL9sK-00061r-00 for sip@ietf.org; Tue, 04 May 2004 20:03:01 -0400 Received: from nwynmime1.didata.com.au ([148.182.16.79]) by ietf-mx with esmtp (Exim 4.12) id 1BL9rd-0005ou-00; Tue, 04 May 2004 20:02:17 -0400 Received: from internet.didata.com.au (unverified [148.182.20.65]) by nwynmime1.didata.com.au (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Wed, 5 May 2004 10:01:38 +1000 To: PROUVOST =?iso-8859-1?Q?S=E9bastien_FTRD=2FDAC=2FISS?= Cc: sip@ietf.org, sip-admin@ietf.org Subject: Re: [Sip] Bug in RFC3261 ? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: Date: Wed, 5 May 2004 10:01:36 +1000 X-MIMETrack: Serialize by Router on SYDMTA/Sydney/Com Tech/AU(Release 5.0.9a |January 7, 2002) at 05/05/2004 10:01:36, Serialize complete at 05/05/2004 10:01:36 Content-Type: multipart/alternative; boundary="=_alternative 000025B7CA256E8B_=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,EXCUSE_16,HTML_30_40, HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 000025B7CA256E8B_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi S=E9bastien, I just re-read your question and realised it's more complicated than I=20 thought :-) Hmmm......I'm not sure what it should do either. I'm sure someone smarter than me will be along shortly though :-) B Ben Gatewood Dimension Data SIP Wookie Level 1 10 Dorcas Street South Melbourne +61 3 9626 0735 +61 419 885 762 ben.gatewood@didata.com.au Ben.Gatewood@didata.com.au Sent by: sip-admin@ietf.org 05/05/2004 08:33 AM =20 To: PROUVOST S=E9bastien FTRD/DAC/ISS cc: sip@ietf.org, sip-admin@ietf.org Subject: Re: [Sip] Bug in RFC3261 ? Hi S=E9bastien,=20 There are procedures and timers for this situation in 3261. Have a look at = Section 17.1.1.2 and 17.1.2.2.=20 Basically the UA should wait 64*T1 (Timer 1). T1, by default, should be=20 500ms so your UA should wait 32 seconds for a valid response.=20 HTH,=20 B Ben Gatewood Dimension Data SIP Wookie Level 1 10 Dorcas Street South Melbourne +61 3 9626 0735 +61 419 885 762 ben.gatewood@didata.com.au=20 PROUVOST S=E9bastien FTRD/DAC/ISS =20 Sent by: sip-admin@ietf.org=20 04/05/2004 07:49 PM=20 =20 To: =20 cc: =20 Subject: [Sip] Bug in RFC3261 ? Hi,=20 In RFC 3261, it is written (section 8.1.3.3 for UAC Core procedures) : "If = more than one Via header field value is present in a response, the UAC=20 SHOULD discard the message."=20 However if the UAC Core layer discards the response and if this response=20 was the only one sent (for example a 200 OK to an UPDATE), then this leads = to a situation when the transaction is terminated (the transaction layer=20 received the response and passed it to the UA Core) but the UA Core is=20 still waiting for a response (it discarded the 200 OK because of the=20 presence of two Via header field values and so is still waiting for the=20 response).=20 I believe there shall be procedures that tells the UAC Core when to stop=20 waiting for the response. Or am I misunderstanding something ?=20 Thanks for your clarifications,=20 S=E9bastien Prouvost=20 France Telecom R&D=20 ***************************************************************************= *** - NOTICE FROM DIMENSION DATA AUSTRALIA This message is confidential, and may contain proprietary or legally=20 privileged information. If you have received this email in error, please=20 notify the sender and delete it immediately. Internet communications are not secure. You should scan this message and=20 any attachments for viruses. Under no circumstances do we accept liability = for any loss or damage which may result from your receipt of this message=20 or any attachments. ***************************************************************************= *** --=_alternative 000025B7CA256E8B_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi S=E9bastien,

I just re-read your question and rea= lised it's more complicated than I thought :-)

Hmmm......I'm not sure what it shoul= d do either.

I'm sure someone smarter than me wil= l be along shortly though :-)

B

Ben Gatewood
Dimension Data
SIP Wookie
Level 1 10 Dorcas Street South Melbourne
+61 3 9626 0735
+61 419 885 762
ben.gatewood@didata.com.au


Ben.Gatewood@didata.com.au
Sent by: sip-admin@ietf.org

05/05/2004 08:33 AM

       
        To: &nbs= p;      PROUVOST S=E9bastien FTRD/DAC/ISS <sebastien.prou= vost@francetelecom.com>
        cc: &nbs= p;      sip@ietf.org, sip-admin@ietf.org
        Subject:=        Re: [Sip] Bug in RFC3261 ?




Hi S=E9bastien,

There are procedures and timers for this situation in 3261. Have a look at = Section 17.1.1.2 and 17.1.2.2.

Basically the UA should wait 64*T1 (Timer 1). T1, by default, should be 500= ms so your UA should wait 32 seconds for a valid response.

HTH,

B

Ben Gatewood
Dimension Data
SIP Wookie
Level 1 10 Dorcas Street South Melbourne
+61 3 9626 0735
+61 419 885 762
ben.gatewood@didata.com.au <= br>
PROUVOST S=E9bastien = FTRD/DAC/ISS <sebastien.prouvost@francetelecom.com>
Sent by: sip-admin@ietf.org =

04/05/2004 07:49 PM

        <= /font>
       To:        <sip@ietf.org= >
       cc:         <= br>        Subject:        [Sip] Bug i= n RFC3261 ?




Hi,
In RFC 3261, it is written (section 8.1.3.3 for UAC Core procedures) : &quo= t;If more than one Via header field value is present in a response, the UAC= SHOULD discard the message."

However if the UAC Core layer discar= ds the response and if this response was the only one sent (for example a 2= 00 OK to an UPDATE), then this leads to a situation when the transaction is= terminated (the transaction layer received the response and passed it to t= he UA Core) but the UA Core is still waiting for a response (it discarded t= he 200 OK because of the presence of two Via header field values and so is = still waiting for the response).

I believe there shall be procedures = that tells the UAC Core when to stop waiting for the response. Or am I misu= nderstanding something ?

Thanks for your clarifications,

S=E9bastien Prouvost
France Telecom R&D



***************************************************************************= ***
- NOTICE FROM DIMENSION DATA AUSTRALIA
This message is confidential, and may contain proprietary or legally privil= eged information. If you have received this email in error, please notify t= he sender and delete it immediately.

Internet communications are not secure. You should scan this message and an= y attachments for viruses. Under no circumstances do we accept liability fo= r any loss or damage which may result from your receipt of this message or = any attachments.
***************************************************************************= ***

--=_alternative 000025B7CA256E8B_=-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 4 21:33:53 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13589 for ; Tue, 4 May 2004 21:33: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 1BLBFZ-00044f-Tr for sip-archive@odin.ietf.org; Tue, 04 May 2004 21:31:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i451V5V7015653 for sip-archive@odin.ietf.org; Tue, 4 May 2004 21: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 1BLB8k-0002I5-T2; Tue, 04 May 2004 21:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLB58-0001OP-OQ for sip@optimus.ietf.org; Tue, 04 May 2004 21:20: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 VAA12770 for ; Tue, 4 May 2004 21:20:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLB56-0000Vq-3O for sip@ietf.org; Tue, 04 May 2004 21:20:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLB46-0000MY-00 for sip@ietf.org; Tue, 04 May 2004 21:19:15 -0400 Received: from ns2.nec.com.au ([147.76.180.2]) by ietf-mx with esmtp (Exim 4.12) id 1BLB3N-0000C5-00 for sip@ietf.org; Tue, 04 May 2004 21:18:30 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by ns2.nec.com.au (Postfix) with ESMTP id 43403377C5 for ; Wed, 5 May 2004 11:14:48 +1000 (EST) Received: from ns2.nec.com.au ([127.0.0.1]) by localhost (ns2.nec.com.au [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 18870-01-7 for ; Wed, 5 May 2004 11:14:48 +1000 (EST) Received: from smtp2.nec.com.au (smtp2.internal.nec.com.au [172.31.8.19]) by ns2.nec.com.au (Postfix) with ESMTP id 3334B37796 for ; Wed, 5 May 2004 11:14:48 +1000 (EST) Received: from mis-exchange.neca.nec.com.au (localhost.localdomain [127.0.0.1]) by smtp2.nec.com.au (8.12.8/8.12.8) with ESMTP id i451Hv6e004166 for ; Wed, 5 May 2004 11:17:58 +1000 Received: by mis-exchange.neca.nec.com.au with Internet Mail Service (5.5.2653.19) id ; Wed, 5 May 2004 11:14:54 +1000 Message-ID: <8D011699C220D411A266009027AF327D03247AD6@mis-exchange.neca.nec.com.au> From: Keith Anderson To: sip@ietf.org Subject: [Sip] UA CANCEL Date: Wed, 5 May 2004 11:14:53 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL autolearn=no version=2.60 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, Can someone please let me know how the UAS should handle the Cancel in = this call scenario. In this scenario the UAC wishes to cancel the call = before it is answered and a 2xx has not been received. My understanding is that = the UAC only needs to send a BYE if the INVITE returns a 2xx.=20 =A0147.76.36.65 147.76.36.205 147.76.36.69 | | |

Well,=20 you were pointing at the right sections. 17.1.1.2 and 17.1.2.2 specify = that when=20 Timer B (for INVITE) and Timer F (for non-INVITE) fire, "the client transaction SHOULD inform the TU about = the
  =20 timeout, and then it SHOULD enter the "Terminated"=20 state"
 
Hisham
-----Original Message-----
From: sip-admin@ietf.org = [mailto:sip-admin@ietf.org]On Behalf Of ext=20 Ben.Gatewood@didata.com.au
Sent: 05.May.2004 = 03:02
To:=20 PROUVOST S=E9bastien FTRD/DAC/ISS
Cc: sip@ietf.org;=20 sip-admin@ietf.org
Subject: Re: [Sip] Bug in RFC3261=20 ?


Hi = S=E9bastien,=20

I just re-read your question = and realised=20 it's more complicated than I thought :-)

Hmmm......I'm not sure what it should do either. =

I'm sure someone smarter than me will be = along shortly=20 though :-)

B

Ben=20 Gatewood
Dimension Data
SIP Wookie
Level 1 10 Dorcas Street = South=20 Melbourne
+61 3 9626 0735
+61 419 885=20 762
ben.gatewood@didata.com.au


Ben.Gatewood@didata.com.au
Sent by: sip-admin@ietf.org=20

05/05/2004 08:33 AM =

        =
        To: =    =20    PROUVOST S=E9bastien FTRD/DAC/ISS=20 <sebastien.prouvost@francetelecom.com>
        cc: =    =20    sip@ietf.org, sip-admin@ietf.org
        Subject: =  =20      Re: [Sip] Bug in RFC3261=20 ?




Hi=20 S=E9bastien, =

There are procedures and timers for = this situation=20 in 3261. Have a look at Section 17.1.1.2 and 17.1.2.2.

Basically the UA should wait 64*T1 (Timer 1). T1, by = default,=20 should be 500ms so your UA should wait 32 seconds for a valid=20 response. =

HTH,=20

B

Ben = Gatewood
Dimension=20 Data
SIP Wookie
Level 1 10 Dorcas Street South Melbourne
+61 = 3 9626=20 0735
+61 419 885 762
ben.gatewood@didata.com.au

PROUVOST = S=E9bastien=20 FTRD/DAC/ISS=20 <sebastien.prouvost@francetelecom.com>
Sent by: sip-admin@ietf.org

04/05/2004 07:49 = PM

      =  =20
      =  To:=20        <sip@ietf.org>
       cc:       =   =
      =  Subject:  =20      [Sip] Bug in RFC3261=20 ?




Hi, =
In RFC 3261,=20 it is written (section 8.1.3.3 for UAC Core procedures) : "If more = than one=20 Via header field value is present in a response, the UAC SHOULD = discard the=20 message."

However if the UAC Core layer = discards the=20 response and if this response was the only one sent (for example a 200 = OK to=20 an UPDATE), then this leads to a situation when the transaction is = terminated=20 (the transaction layer received the response and passed it to the UA = Core) but=20 the UA Core is still waiting for a response (it discarded the 200 OK = because=20 of the presence of two Via header field values and so is still waiting = for the=20 response).

I believe there shall be = procedures that=20 tells the UAC Core when to stop waiting for the response. Or am I=20 misunderstanding something ?=20

Thanks for your = clarifications,

S=E9bastien Prouvost
France=20 Telecom R&D



********************************************************= **********************
-=20 NOTICE FROM DIMENSION DATA AUSTRALIA
This message is confidential, = and may=20 contain proprietary or legally privileged information. If you have = received=20 this email in error, please notify the sender and delete it=20 immediately.

Internet communications are not secure. You should = scan=20 this message and any attachments for viruses. Under no circumstances = do we=20 accept liability for any loss or damage which may result from your = receipt of=20 this message or any=20 = attachments.
*********************************************************= *********************=20

------_=_NextPart_001_01C43278.98398C0F-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 5 05:31:48 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02467 for ; Wed, 5 May 2004 05:31: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 1BLIbQ-00028F-Q5 for sip-archive@odin.ietf.org; Wed, 05 May 2004 05:22:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i459M8IR008191 for sip-archive@odin.ietf.org; Wed, 5 May 2004 05:22:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLIQi-0007Lr-Ek; Wed, 05 May 2004 05:11:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLILD-0005RG-Nl for sip@optimus.ietf.org; Wed, 05 May 2004 05:05:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01180 for ; Wed, 5 May 2004 05:05:20 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLILA-0006R2-Jg for sip@ietf.org; Wed, 05 May 2004 05:05:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLIKE-0006F3-00 for sip@ietf.org; Wed, 05 May 2004 05:04:24 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BLIJH-000647-00; Wed, 05 May 2004 05:03:23 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4593MB19790; Wed, 5 May 2004 12:03:22 +0300 (EET DST) X-Scanned: Wed, 5 May 2004 12:02:43 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i4592hFC001336; Wed, 5 May 2004 12:02:43 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00xLsoTc; Wed, 05 May 2004 12:02:40 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4592eH01957; Wed, 5 May 2004 12:02:40 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 5 May 2004 12:02:40 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 5 May 2004 12:02:40 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4327F.B1FB89FE" Subject: RE: RE : [Sip] Bug in RFC3261 ? Date: Wed, 5 May 2004 12:02:30 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797A35@esebe019.ntc.nokia.com> Thread-Topic: [Sip] Bug in RFC3261 ? Thread-Index: AcQyNezx/egRPTdQRUmZJzLUfwOJqgAQmWlgAADQn4AAAO/6wA== To: , Cc: , X-OriginalArrivalTime: 05 May 2004 09:02:40.0548 (UTC) FILETIME=[B82E1640:01C4327F] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,EXCUSE_16,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,HTML_TAG_EXISTS_TBODY,NO_REAL_NAME autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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_01C4327F.B1FB89FE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable OK, now I get your question. =20 UAC core does not wait. What it can do is issue the request again. =20 /Hisham -----Original Message----- From: ext PROUVOST S=E9bastien FTRD/DAC/ISS = [mailto:sebastien.prouvost@francetelecom.com] Sent: 05.May.2004 11:49 To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); Ben.Gatewood@didata.com.au Cc: sip@ietf.org; sip-admin@ietf.org Subject: RE : [Sip] Bug in RFC3261 ? This does not really correspond to what I am saying. What I am saying is = the following:=20 =20 - I send a request (UPDATE for example) - I receive a 200 OK for this request. At this point the transaction = enters the state "Completed" and then "Terminated". Then the transaction = is destroyed and no more transaction layer timer is running for this = transaction. - The 200 OK is passed to the UAC Core layer. But this 200 OK contains = two Via headers. Section 8.1.3.3 (that handles UAC Core procedures) says = : "If more than one Via header field value is present in a response, the = UAC SHOULD discard the message."" So the UAC Core discards the message. = But the UAC Core is still waiting for a response (although the = corresponding transaction is terminated from the transaction layer point = of view).=20 =20 When does the UAC Core stop waiting for a response ? =20 S=E9bastien. =20 -----Message d'origine----- De : hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]=20 Envoy=E9 : mercredi 5 mai 2004 10:12 =C0 : Ben.Gatewood@didata.com.au; PROUVOST S=E9bastien FTRD/DAC/ISS Cc : sip@ietf.org; sip-admin@ietf.org Objet : RE: [Sip] Bug in RFC3261 ? Well, you were pointing at the right sections. 17.1.1.2 and 17.1.2.2 = specify that when Timer B (for INVITE) and Timer F (for non-INVITE) = fire, "the client transaction SHOULD inform the TU about the timeout, and then it SHOULD enter the "Terminated" state" =20 Hisham -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext = Ben.Gatewood@didata.com.au Sent: 05.May.2004 03:02 To: PROUVOST S=E9bastien FTRD/DAC/ISS Cc: sip@ietf.org; sip-admin@ietf.org Subject: Re: [Sip] Bug in RFC3261 ? Hi S=E9bastien,=20 I just re-read your question and realised it's more complicated than I = thought :-)=20 Hmmm......I'm not sure what it should do either.=20 I'm sure someone smarter than me will be along shortly though :-)=20 B Ben Gatewood Dimension Data SIP Wookie Level 1 10 Dorcas Street South Melbourne +61 3 9626 0735 +61 419 885 762 ben.gatewood@didata.com.au=20 Ben.Gatewood@didata.com.au=20 Sent by: sip-admin@ietf.org=20 05/05/2004 08:33 AM=20 =20 To: PROUVOST S=E9bastien FTRD/DAC/ISS = =20 cc: sip@ietf.org, sip-admin@ietf.org=20 Subject: Re: [Sip] Bug in RFC3261 ?=09 Hi S=E9bastien,=20 There are procedures and timers for this situation in 3261. Have a look = at Section 17.1.1.2 and 17.1.2.2.=20 Basically the UA should wait 64*T1 (Timer 1). T1, by default, should be = 500ms so your UA should wait 32 seconds for a valid response.=20 HTH,=20 B Ben Gatewood Dimension Data SIP Wookie Level 1 10 Dorcas Street South Melbourne +61 3 9626 0735 +61 419 885 762 ben.gatewood@didata.com.au=20 PROUVOST S=E9bastien FTRD/DAC/ISS = =20 Sent by: sip-admin@ietf.org=20 04/05/2004 07:49 PM=20 =20 To: =20 cc: =20 Subject: [Sip] Bug in RFC3261 ?=09 Hi,=20 In RFC 3261, it is written (section 8.1.3.3 for UAC Core procedures) : = "If more than one Via header field value is present in a response, the = UAC SHOULD discard the message."=20 However if the UAC Core layer discards the response and if this response = was the only one sent (for example a 200 OK to an UPDATE), then this = leads to a situation when the transaction is terminated (the transaction = layer received the response and passed it to the UA Core) but the UA = Core is still waiting for a response (it discarded the 200 OK because of = the presence of two Via header field values and so is still waiting for = the response).=20 I believe there shall be procedures that tells the UAC Core when to stop = waiting for the response. Or am I misunderstanding something ?=20 Thanks for your clarifications,=20 S=E9bastien Prouvost=20 France Telecom R&D=20 *************************************************************************= ***** - NOTICE FROM DIMENSION DATA AUSTRALIA This message is confidential, and may contain proprietary or legally = privileged information. If you have received this email in error, please = notify the sender and delete it immediately. Internet communications are not secure. You should scan this message and = any attachments for viruses. Under no circumstances do we accept = liability for any loss or damage which may result from your receipt of = this message or any attachments. *************************************************************************= *****=20 ------_=_NextPart_001_01C4327F.B1FB89FE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
OK,=20 now I get your question.
 
UAC=20 core does not wait. What it can do is issue the request=20 again.
 
/Hisham
-----Original Message-----
From: ext PROUVOST = S=E9bastien=20 FTRD/DAC/ISS = [mailto:sebastien.prouvost@francetelecom.com]
Sent:=20 05.May.2004 11:49
To: Khartabil Hisham = (Nokia-TP-MSW/Helsinki);=20 Ben.Gatewood@didata.com.au
Cc: sip@ietf.org;=20 sip-admin@ietf.org
Subject: RE : [Sip] Bug in RFC3261=20 ?

This=20 does not really correspond to what I am saying. What I am saying is = the=20 following:
 
- I send a request (UPDATE for = example)
- I=20 receive a 200 OK for this request. At this point the transaction = enters the=20 state "Completed" and then "Terminated". Then the transaction is = destroyed and=20 no more transaction layer timer is running for this=20 transaction.
-=20 The 200 OK is passed to the UAC Core layer. But this 200 OK contains = two Via=20 headers. Section 8.1.3.3 (that handles UAC Core procedures) says : = "If more than one Via header = field value is=20 present in a response, the UAC SHOULD discard the message."" So = the UAC=20 Core discards the message. But the UAC Core is still waiting for a = response=20 (although the corresponding transaction is terminated from the = transaction=20 layer point of view).
 
When=20 does the UAC Core stop waiting for a response ?
 
S=E9bastien.
 
-----Message d'origine-----
De :=20 hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]=20
Envoy=E9 : mercredi 5 mai 2004 = 10:12
=C0 :=20 Ben.Gatewood@didata.com.au; PROUVOST S=E9bastien=20 FTRD/DAC/ISS
Cc : sip@ietf.org;=20 sip-admin@ietf.org
Objet : RE: [Sip] Bug in RFC3261=20 ?

Well, you were pointing at the right sections. 17.1.1.2 and = 17.1.2.2=20 specify that when Timer B (for INVITE) and Timer F (for non-INVITE) = fire,=20 "the client transaction SHOULD inform = the TU=20 about the
   timeout, and then it SHOULD enter the = "Terminated"=20 state"
 
Hisham
-----Original Message-----
From: = sip-admin@ietf.org=20 [mailto:sip-admin@ietf.org]On Behalf Of ext=20 Ben.Gatewood@didata.com.au
Sent: 05.May.2004 = 03:02
To:=20 PROUVOST S=E9bastien FTRD/DAC/ISS
Cc: sip@ietf.org;=20 sip-admin@ietf.org
Subject: Re: [Sip] Bug in RFC3261=20 ?


Hi=20 S=E9bastien,

I = just re-read your=20 question and realised it's more complicated than I thought = :-)=20

Hmmm......I'm not sure = what it should=20 do either.

I'm = sure someone=20 smarter than me will be along shortly though :-) =

B

Ben Gatewood
Dimension = Data
SIP=20 Wookie
Level 1 10 Dorcas Street South Melbourne
+61 3 9626=20 0735
+61 419 885 762
ben.gatewood@didata.com.au =


Ben.Gatewood@didata.com.au
Sent by: = sip-admin@ietf.org=20

05/05/2004 08:33 = AM

       =20
    =    =20 To:        PROUVOST S=E9bastien = FTRD/DAC/ISS=20 <sebastien.prouvost@francetelecom.com> =
        cc: =    =20    sip@ietf.org, sip-admin@ietf.org =
        = Subject:  =20      Re: [Sip] Bug in RFC3261=20 ?




Hi S=E9bastien,=20

There are = procedures and=20 timers for this situation in 3261. Have a look at Section 17.1.1.2 = and=20 17.1.2.2.

Basically the UA should wait 64*T1 = (Timer 1).=20 T1, by default, should be 500ms so your UA should wait 32 seconds = for a=20 valid response.=20

HTH,

B

Ben Gatewood
Dimension Data
SIP = Wookie
Level=20 1 10 Dorcas Street South Melbourne
+61 3 9626 0735
+61 419 = 885=20 762
ben.gatewood@didata.com.au

PROUVOST = S=E9bastien=20 FTRD/DAC/ISS=20 <sebastien.prouvost@francetelecom.com>
Sent by: sip-admin@ietf.org

04/05/2004 07:49 = PM

    =    =20
    =  =20  To:      =20  <sip@ietf.org>
  =    =20  cc:        
       Subject:   =    =20  [Sip] Bug in RFC3261 = ?




Hi,
In RFC 3261, it is written (section 8.1.3.3 = for UAC=20 Core procedures) : "If more than one Via header field value is = present in=20 a response, the UAC SHOULD discard the message."

However if the UAC Core = layer discards=20 the response and if this response was the only one sent (for = example a 200=20 OK to an UPDATE), then this leads to a situation when the = transaction is=20 terminated (the transaction layer received the response and passed = it to=20 the UA Core) but the UA Core is still waiting for a response (it = discarded=20 the 200 OK because of the presence of two Via header field values = and so=20 is still waiting for the response).

I believe there shall be = procedures=20 that tells the UAC Core when to stop waiting for the response. Or = am I=20 misunderstanding something ?=20

Thanks for your=20 clarifications, =

S=E9bastien Prouvost
France=20 Telecom R&D =



********************************************************= **********************
-=20 NOTICE FROM DIMENSION DATA AUSTRALIA
This message is = confidential, and=20 may contain proprietary or legally privileged information. If you = have=20 received this email in error, please notify the sender and delete = it=20 immediately.

Internet communications are not secure. You = should=20 scan this message and any attachments for viruses. Under no = circumstances=20 do we accept liability for any loss or damage which may result = from your=20 receipt of this message or any=20 = attachments.
*********************************************************= *********************=20

------_=_NextPart_001_01C4327F.B1FB89FE-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 5 11:05:44 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18841 for ; Wed, 5 May 2004 11:05: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 1BLNrr-0007no-7C for sip-archive@odin.ietf.org; Wed, 05 May 2004 10:59:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45ExRPH029984 for sip-archive@odin.ietf.org; Wed, 5 May 2004 10:59:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLNb0-0000kN-1y; Wed, 05 May 2004 10: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 1BLNU1-0006lu-7a for sip@optimus.ietf.org; Wed, 05 May 2004 10:34:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16447 for ; Wed, 5 May 2004 10:34:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLNTy-00017N-Sf for sip@ietf.org; Wed, 05 May 2004 10:34:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLNSz-0000rg-00 for sip@ietf.org; Wed, 05 May 2004 10:33:46 -0400 Received: from smail4.alcatel.fr ([62.23.212.167]) by ietf-mx with esmtp (Exim 4.12) id 1BLNSQ-0000dN-00 for sip@ietf.org; Wed, 05 May 2004 10:33:10 -0400 Received: from bsf.alcatel.fr (mail205.dit.sxb.bsf.alcatel.fr [155.132.205.115]) by smail4.alcatel.fr (ALCANET/NETFR) with ESMTP id i45EgXEZ014937 for ; Wed, 5 May 2004 16:42:33 +0200 Received: from mail (mail-bsf-alcatel-fr.dit.sxb.bsf.alcatel.fr [155.132.205.91]) by bsf.alcatel.fr (8.8.8+Sun/8.9.3) with ESMTP id QAA15657 for ; Wed, 5 May 2004 16:33:09 +0200 (MET DST) Received: from frilld0023456.dit.sxb.bsf.alcatel.fr (frilld0023456 [172.25.49.146]) by mail (8.8.8+Sun/) with ESMTP id QAA15653 for ; Wed, 5 May 2004 16:33:09 +0200 (MET DST) From: Martin =?ISO-8859-1?Q?Andr=E9?= To: sip@ietf.org Content-Type: text/plain Message-Id: <1083766713.27359.385.camel@Frill023456x> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 05 May 2004 16:18:34 +0200 Content-Transfer-Encoding: 7bit X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Unregistering UA Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear all, My question is about Expires duration and unregistrations. Let us imagine a case where the unregistration is not initiated by the client (is this allowed ?). Are there any mean to notify the UA that its registration has been removed ? As far as I understood RFC3261, the Registrar doesn't generate SIP requests by its own. So, is it possible to lower registration duration just like it is possible with subscription duration ? This way, we could shorten registration duration (during registration process or with proxy intervention) and wait until it expires. I didn't see anything about control on Expires duration. Did I miss something ? Thanks in advance for your clarifications, Martin _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 5 11:24:24 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20647 for ; Wed, 5 May 2004 11:24:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLODO-0001Oi-74 for sip-archive@odin.ietf.org; Wed, 05 May 2004 11:21:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45FLgJv005372 for sip-archive@odin.ietf.org; Wed, 5 May 2004 11:21:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLNyN-00045H-8w; Wed, 05 May 2004 11:06:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLNsX-00089C-Dw for sip@optimus.ietf.org; Wed, 05 May 2004 11:00: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 LAA18309 for ; Wed, 5 May 2004 11:00:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLNsU-0000IT-3y for sip@ietf.org; Wed, 05 May 2004 11:00:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLNrK-0007jr-00 for sip@ietf.org; Wed, 05 May 2004 10:58:56 -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 1BLNqH-00079L-00 for sip@ietf.org; Wed, 05 May 2004 10:57:50 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 05 May 2004 07:11:48 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i45EvHW9015366; Wed, 5 May 2004 07:57:17 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AID99761; Wed, 5 May 2004 10:57:15 -0400 (EDT) Message-ID: <409900CB.1060506@cisco.com> Date: Wed, 05 May 2004 10:57:15 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sarit Galanos CC: sip@ietf.org, Jonathan Rosenberg Subject: Re: [Sip] Session Timer - Terminology is no clear References: <10DA2C035FE3BC4FA8D73EC55FC43D9B047A71@rvil-mail.radvision.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 Sarit, I just went back and reread the text. I agree it is confusing. Stepping back a moment, lets look at what kind of session refresh requests can be either INVITE or UPDATE. INVITE could also be establishing a dialog, or it could be within an existing dialog. UPDATE can only be within an existing dialog. (I note that this draft is now behind the times in that it doesn't address other dialog establishing requests. It would make perfect sense to want to use session timer within a dialog established with a SUBSCRIBE. But that is a subject for another time.) Session timers intimately connected to dialogs. But some of the action may happen before a dialog is established. The behavior before and after a dialog is established is intertwined in the text. It is probably worth looking at separately: Suppose the UAC is sending a new INVITE that will hopefully establish a dialog. And the UAC wants to use session timer, so it inserts a Supported: timer. It may also insert Session-Expires and/or Min-SE. This could fail with a 422, indicating that the Session-Expires inserted by the UAC or some proxy on the path was too small for the UAS or some proxy on the path. This clearly doesn't affect dialog state, because there isn't any dialog yet. So it can only affect pending call state in the UAC - altering how further attempts to establish the call are done. The invite could have forked, and some other fork could have succeeded. In that case this is moot. But if all the forks fail, then the UAC may attempt to recover, retrying the invite. To have this try come out differently, it follows 7.4 and inserts a Min-SE that is the max of all those it received in 422 responses. The UAC may also include a Session-Expires in the retry, constrained by the Min-SE value. Presumably it would do this iff it had included one in the initial request. Doing that ensures that proxies along all fork paths will use Session-Expires values large enough to be acceptable to all candidate forked UASs, so that there should be no 422 responses on the 2nd try. Of course there may be other problems, but eventually this will hopefully result in one or more responses that establish dialogs. And each dialog then may or may not have a session timer in operation according to the response. Each dialog is then an independent entity for purposes of session timer. It is possible that a dialog would be established without a session timer, and then later, an initial session refresh could be sent within the dialog. That isn't a very interesting case, so I will ignore it for now. Once in a dialog with a session timer, one of the participants might send an INVITE or UPDATE. This could be because the time to refresh the session timer has come, or it could be for some entirely unrelated reason. It doesn't matter, because the rules must be followed if the message is sent, regardless of reason. Parts of 7.4 apply to this case. The key requirement here has to do with Min-SE: The value of the Min-SE header field present in a session refresh request MUST be the largest value amongst all Min-SE header field values ... received in session refresh requests, on the same dialog, if a dialog has been established. ... A result of this rule is that the maximum value of the Min-SE is effectively 'cleared' once the dialog is established, and from that point on, only the values from proxies known to be on the proxy path will end up being used. The point here is that the Min-SE in the initial request might have been larger than necessary due to the needs of servers on forks not taken. Now that a dialog has been established, the goal is to constrain the session-expires value only by the needs of the currently involved parties. In the simple case where there was no forking, and the initial request succeeded in establishing a dialog, the Min-SE value used in the "subsequent session refresh request" would normally be the same value received in the response to the initial session refresh request. The rules about the relationship of the Session-Expires to the Min-SE are a separate story. The UAC is never required to insert a Session-Expires at all. The session timer mechanism is really for the benefit of the proxies along the path rather than the UAC and UAS. (The UAC and UAS are free to send INVITE or UPDATE any time they want to test the liveness of the other end. They don't need session timer for this.) So there is no particular benefit in the UAC providing a value other than to express a preference as the refresher or not. So in general it would be silly for a UAC to insert a Session-Expires into an initial session refresh request. Once a session timer has been established, it will presumably be a normal case to want to preserve it for the life of the dialog, even as other things change in the dialog. I really don't know why 7.4 says the UAC SHOULD include Session-Expires. If it just included Min-SE the right thing would happen, and other options would be preserved for the other participants in the dialog. One reason to include it is to specify the uac/uas parameter, but the UAS for the request could handle that. If the Session-Expires header is included, its syntax requires that delta-time be provided. The requirement that this equal Min-SE guarantees that the value can't be altered anywhere in the path. This means that once a time value has been established it won't ever change. Possibly the recommentation to include Session-Expires in this case was motivated by a desire for the session timer not to be accidentally lost from the call. But I think a rule on the UAS is sufficient for that. So I think I would be inclined to violate the SHOULD, and omit the Session-Expires in this case. I may have forgotten something about the rationale here. Maybe Jonathan will comment on this. Paul Sarit Galanos wrote: > Hi Paul, > Thanks for you answer. > I'm still not clear about the following: > The draft includes two different sections: > 7.1 Generating an Initial Session Refresh Request > 7.4 Generating Subsequent Session Refresh Requests > Each section includes different rules regarding the session timer. > When should I apply the behavior of 7.1 and when should I use 7.4? > > Thanks, > Sarit. > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, May 03, 2004 5:06 PM > To: Sarit Galanos > Cc: sip@ietf.org > Subject: Re: [Sip] Session Timer - Terminology is no clear > > > The language in this is at times obscure. I think in part this results > from the age of the document. (It has been in progress for years, I > think since before 2543bis. So terminology has changed around it.) > > Part of the problem is that it is written as if a reINVITE or UPDATE is > done solely for the purpose of session timer refresh. But in reality > things are not that simple. > > A reINVITE or an UPDATE does a bunch of stuff. If session-timer is > supported then refreshing, or cancelling, a session timer is one of the > things it does. Any time a reINVITE or UPDATE is sent, it will affect > the session timer one way or another, whether that was the primary > intent in sending the message, or not. > > There also isn't anything special about the "first" refresh. The request > that first establishes a dialog also establishes some kind of session > timer state - either leaving it disabled, or running. Every subsequent > reINVITE, UPDATE (and reSUBSCRIBE too) does the same thing - > restablishes a new session timer or else leaves the dialog with none. > There is no need to consider what the previous state was - the new state > is not affected by that. > > All that the session timer mechanism does is force a reINVITE or UPDATE > to happen by a particular time if one hasn't happened for any other reason. > > Paul > > Sarit Galanos wrote: > >>Hi, >>The session timer draft uses the term "Initial Session Refresh Request". >> >>The draft defines that >> "Session Refresh Request: An INVITE or UPDATE request within a dialog." >> >>>From that I understand that "Initial Session Refresh Request" is the first re-Invite or Update inside that dialog. >> >>But, If the dialog was established with session timer parameters and after the first INVITE-200-ACK session time is already active, >>why is there a difference between the initial refresh and further refreshes. >>Or is that the "Initial Session Refresh Request" is the first request that has session timer parameters >>and it can also be the initial INVITE? >> >>Thanks, >>Sarit >> >> >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP 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 May 5 12:52:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25304 for ; Wed, 5 May 2004 12:52: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 1BLPTl-0007yF-DY for sip-archive@odin.ietf.org; Wed, 05 May 2004 12:42:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45Ggfo9030631 for sip-archive@odin.ietf.org; Wed, 5 May 2004 12:42:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLPJS-0003mV-C9; Wed, 05 May 2004 12: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 1BLPCc-00016D-8m for sip@optimus.ietf.org; Wed, 05 May 2004 12:24:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23476 for ; Wed, 5 May 2004 12:24:55 -0400 (EDT) From: nataraju.alilaghatta@wipro.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLPCa-0007Cy-Oe for sip@ietf.org; Wed, 05 May 2004 12:24:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLPBZ-0006vj-00 for sip@ietf.org; Wed, 05 May 2004 12:23:54 -0400 Received: from wiproecmx2.wipro.com ([164.164.31.6]) by ietf-mx with esmtp (Exim 4.12) id 1BLPAf-0006QX-00 for sip@ietf.org; Wed, 05 May 2004 12:22:58 -0400 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx2.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i45GMOxB016864 for ; Wed, 5 May 2004 21:52:24 +0530 (IST) Received: from blr-ec-bh3.wipro.com ([10.200.50.93]) by ec-vwall-wd with InterScan Messaging Security Suite; Wed, 05 May 2004 21:52:23 +0530 Received: from blr-ec-msg04.wipro.com ([10.200.53.99]) by blr-ec-bh3.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 5 May 2004 21:52:22 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C432BD.253DA66E" Subject: RE: [Sip] Unregistering UA Date: Wed, 5 May 2004 21:52:22 +0530 Message-ID: <10C4348A1BA43A4FA8D5B767E052CEADBD48F3@blr-ec-msg04.wipro.com> Thread-Topic: [Sip] Unregistering UA Thread-Index: AcQysY6yhLw1/u5EQ2Wpo57yMyfB3AACus4b To: , X-OriginalArrivalTime: 05 May 2004 16:22:22.0293 (UTC) FILETIME=[24ECE850:01C432BD] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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_01C432BD.253DA66E Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 CS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIA0KCUZyb206IHNpcC1hZG1pbkBpZXRmLm9yZyBv biBiZWhhbGYgb2YgTWFydGluIEFuZHLDqSANCglTZW50OiBXZWQgNS81LzIwMDQgNzo0OCBQTSAN CglUbzogc2lwQGlldGYub3JnIA0KCUNjOiANCglTdWJqZWN0OiBbU2lwXSBVbnJlZ2lzdGVyaW5n IFVBDQoJDQoJDQoNCglEZWFyIGFsbCwNCgkNCglNeSBxdWVzdGlvbiBpcyBhYm91dCBFeHBpcmVz IGR1cmF0aW9uIGFuZCB1bnJlZ2lzdHJhdGlvbnMuIExldCB1cw0KCWltYWdpbmUgYSBjYXNlIHdo ZXJlIHRoZSB1bnJlZ2lzdHJhdGlvbiBpcyBub3QgaW5pdGlhdGVkIGJ5IHRoZSBjbGllbnQNCgko aXMgdGhpcyBhbGxvd2VkID8pLiBBcmUgdGhlcmUgYW55IG1lYW4gdG8gbm90aWZ5IHRoZSBVQSB0 aGF0IGl0cw0KCXJlZ2lzdHJhdGlvbiBoYXMgYmVlbiByZW1vdmVkID8gQXMgZmFyIGFzIEkgdW5k ZXJzdG9vZCBSRkMzMjYxLCB0aGUNCglSZWdpc3RyYXIgZG9lc24ndCBnZW5lcmF0ZSBTSVAgcmVx dWVzdHMgYnkgaXRzIG93bi4NCgkNCg0KCVtBQk5dIFJlZ2lzdHJhciBpcyBub3QgcmVxdWlyZWQg dG8gc2VuZCB0aGUgZGVyZWdpc3RyYXRpb24gcmVxdWVzdC4gSXQgd2lsbCBqdXN0IHJlbW9yZSB0 aGUgcmVnaXN0cmF0aW9uIGVudHJ5IGluIGl0cyBkYXRhYmFzZSBmb3IgdGhhdCBwYXJ0aWN1bGFy IGNvbnRhY3QgYWRkcmVzcyBhZnRlciB0aGUgc3BlY2lmaWVkIHRpbWUgZWxhcHNlZC4gc2VuZGlu ZyBkZXJlZ2lzdHJhdGlvbiByZXF1ZXN0IGFwcGxpY2FibGUgb25seSBmb3IgdGhlIGNsaWVudCBu b3QgdGhlIHJlZ2lzdHJhci4gDQoNCgkNCglTbywgaXMgaXQgcG9zc2libGUgdG8gbG93ZXIgcmVn aXN0cmF0aW9uIGR1cmF0aW9uIGp1c3QgbGlrZSBpdCBpcw0KCXBvc3NpYmxlIHdpdGggc3Vic2Ny aXB0aW9uIGR1cmF0aW9uID8gVGhpcyB3YXksIHdlIGNvdWxkIHNob3J0ZW4NCglyZWdpc3RyYXRp b24gZHVyYXRpb24gKGR1cmluZyByZWdpc3RyYXRpb24gcHJvY2VzcyBvciB3aXRoIHByb3h5DQoJ aW50ZXJ2ZW50aW9uKSBhbmQgd2FpdCB1bnRpbCBpdCBleHBpcmVzLg0KCQ0KDQoJW0FCTl0gY2xp ZW50IGNhbiBzZW5kIGFuIGFkZGl0aW9uYWwgcmVnaXN0cmF0aW9uIHJlcXVlc3Qgd2l0aCB0aGUg cmVkdWNlZCBFeHBpcmVzIHZhbHVlLi4uDQoNCgkNCglJIGRpZG4ndCBzZWUgYW55dGhpbmcgYWJv dXQgY29udHJvbCBvbiBFeHBpcmVzIGR1cmF0aW9uLiBEaWQgSSBtaXNzDQoJc29tZXRoaW5nID8N CgkNCglUaGFua3MgaW4gYWR2YW5jZSBmb3IgeW91ciBjbGFyaWZpY2F0aW9ucywNCgkNCglNYXJ0 aW4NCgkNCgkNCgkNCglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KCVNpcCBtYWlsaW5nIGxpc3QgIGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NpcA0KCVRoaXMgbGlzdCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRoZSBjb3Jl IFNJUCBQcm90b2NvbA0KCVVzZSBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3Ig cXVlc3Rpb25zIG9uIGN1cnJlbnQgc2lwDQoJVXNlIHNpcHBpbmdAaWV0Zi5vcmcgZm9yIG5ldyBk ZXZlbG9wbWVudHMgb24gdGhlIGFwcGxpY2F0aW9uIG9mIHNpcA0KCQ0KDQo= ------_=_NextPart_001_01C432BD.253DA66E Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPgo8IURPQ1RZUEUgSFRNTCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgMy4yLy9F TiI+CjxIVE1MPgo8SEVBRD4KCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMgRXhj aGFuZ2UgU2VydmVyIHZlcnNpb24gNi4wLjY0ODcuMSI+CjxUSVRMRT5bU2lwXSBVbnJlZ2lzdGVy aW5nIFVBPC9USVRMRT4KPC9IRUFEPgo8Qk9EWSBkaXI9bHRyPgo8QkxPQ0tRVU9URSBkaXI9bHRy IHN0eWxlPSJNQVJHSU4tUklHSFQ6IDBweCI+CiAgPERJVj48Rk9OVCBzaXplPTI+LS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0gPEJSPjxCPkZyb206PC9CPiAKICBzaXAtYWRtaW5AaWV0Zi5vcmcm bmJzcDtvbiBiZWhhbGYgb2YmbmJzcDtNYXJ0aW4gQW5kcsOpIDxCUj48Qj5TZW50OjwvQj4gV2Vk IAogIDUvNS8yMDA0IDc6NDggUE0gPEJSPjxCPlRvOjwvQj4gc2lwQGlldGYub3JnIDxCUj48Qj5D Yzo8L0I+IAogIDxCUj48Qj5TdWJqZWN0OjwvQj4gW1NpcF0gVW5yZWdpc3RlcmluZyBVQTxCUj48 QlI+PC9GT05UPjwvRElWPgogIDxQPjxGT05UIHNpemU9Mj5EZWFyIGFsbCw8QlI+PEJSPk15IHF1 ZXN0aW9uIGlzIGFib3V0IEV4cGlyZXMgZHVyYXRpb24gYW5kIAogIHVucmVnaXN0cmF0aW9ucy4g TGV0IHVzPEJSPmltYWdpbmUgYSBjYXNlIHdoZXJlIHRoZSB1bnJlZ2lzdHJhdGlvbiBpcyBub3Qg CiAgaW5pdGlhdGVkIGJ5IHRoZSBjbGllbnQ8QlI+KGlzIHRoaXMgYWxsb3dlZCA/KS4gQXJlIHRo ZXJlIGFueSBtZWFuIHRvIG5vdGlmeSAKICB0aGUgVUEgdGhhdCBpdHM8QlI+cmVnaXN0cmF0aW9u IGhhcyBiZWVuIHJlbW92ZWQgPyBBcyBmYXIgYXMgSSB1bmRlcnN0b29kIAogIFJGQzMyNjEsIHRo ZTxCUj5SZWdpc3RyYXIgZG9lc24ndCBnZW5lcmF0ZSBTSVAgcmVxdWVzdHMgYnkgaXRzIAogIG93 bi48QlI+PC9GT05UPjxGT05UIHNpemU9Mj48L0ZPTlQ+PC9QPgogIDxQPjxGT05UIHNpemU9Mj5b QUJOXSBSZWdpc3RyYXIgaXMgbm90IHJlcXVpcmVkIHRvIHNlbmQgdGhlIGRlcmVnaXN0cmF0aW9u IAogIHJlcXVlc3QuIEl0IHdpbGwganVzdCByZW1vcmUgdGhlIHJlZ2lzdHJhdGlvbiBlbnRyeSBp biBpdHMgZGF0YWJhc2UgZm9yIHRoYXQgCiAgcGFydGljdWxhciBjb250YWN0IGFkZHJlc3MgYWZ0 ZXIgdGhlIHNwZWNpZmllZCB0aW1lIGVsYXBzZWQuIHNlbmRpbmcgCiAgZGVyZWdpc3RyYXRpb24g cmVxdWVzdCBhcHBsaWNhYmxlIG9ubHkgZm9yIHRoZSBjbGllbnQgbm90IHRoZSByZWdpc3RyYXIu IAogIDwvRk9OVD48L1A+PEZPTlQgc2l6ZT0yPjwvRk9OVD48Rk9OVCBzaXplPTI+CiAgPFA+PEJS PlNvLCBpcyBpdCBwb3NzaWJsZSB0byBsb3dlciByZWdpc3RyYXRpb24gZHVyYXRpb24ganVzdCBs aWtlIGl0IAogIGlzPEJSPnBvc3NpYmxlIHdpdGggc3Vic2NyaXB0aW9uIGR1cmF0aW9uID8gVGhp cyB3YXksIHdlIGNvdWxkIAogIHNob3J0ZW48QlI+cmVnaXN0cmF0aW9uIGR1cmF0aW9uIChkdXJp bmcgcmVnaXN0cmF0aW9uIHByb2Nlc3Mgb3Igd2l0aCAKICBwcm94eTxCUj5pbnRlcnZlbnRpb24p IGFuZCB3YWl0IHVudGlsIGl0IGV4cGlyZXMuPEJSPjwvUD4KICA8UD5bQUJOXSBjbGllbnQgY2Fu IHNlbmQgYW4gYWRkaXRpb25hbCByZWdpc3RyYXRpb24gcmVxdWVzdCB3aXRoIHRoZSByZWR1Y2Vk IAogIEV4cGlyZXMgdmFsdWUuLi48L1A+CiAgPFA+PEJSPkkgZGlkbid0IHNlZSBhbnl0aGluZyBh Ym91dCBjb250cm9sIG9uIEV4cGlyZXMgZHVyYXRpb24uIERpZCBJIAogIG1pc3M8QlI+c29tZXRo aW5nID88QlI+PEJSPlRoYW5rcyBpbiBhZHZhbmNlIGZvciB5b3VyIAogIGNsYXJpZmljYXRpb25z LDxCUj48QlI+TWFydGluPEJSPjxCUj48QlI+PEJSPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPEJSPlNpcCAKICBtYWlsaW5nIGxpc3QmbmJzcDsgPEEgCiAg aHJlZj0iaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwIj5odHRwczov L3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXA8L0E+PEJSPlRoaXMgCiAgbGlzdCBp cyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRoZSBjb3JlIFNJUCBQcm90b2NvbDxCUj5Vc2UgCiAg c2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUgZm9yIHF1ZXN0aW9ucyBvbiBjdXJyZW50 IHNpcDxCUj5Vc2UgCiAgc2lwcGluZ0BpZXRmLm9yZyBmb3IgbmV3IGRldmVsb3BtZW50cyBvbiB0 aGUgYXBwbGljYXRpb24gb2YgCnNpcDxCUj48L1A+PC9GT05UPjwvQkxPQ0tRVU9URT4KCjwvQk9E WT4KPC9IVE1MPg== ------_=_NextPart_001_01C432BD.253DA66E-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 5 13:29:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27820 for ; Wed, 5 May 2004 13:29: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 1BLQAB-0007zM-3Z for sip-archive@odin.ietf.org; Wed, 05 May 2004 13:26:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45HQVYH030709 for sip-archive@odin.ietf.org; Wed, 5 May 2004 13:26:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLPvD-0001bJ-Iv; Wed, 05 May 2004 13: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 1BLPnM-0006R6-3E for sip@optimus.ietf.org; Wed, 05 May 2004 13:02: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 NAA26156 for ; Wed, 5 May 2004 13:02:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLPnK-0002Hs-9T for sip@ietf.org; Wed, 05 May 2004 13:02:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLPmO-0001zq-00 for sip@ietf.org; Wed, 05 May 2004 13:01:56 -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 1BLPlX-0001SF-00 for sip@ietf.org; Wed, 05 May 2004 13:01:03 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i45H0UW9013291; Wed, 5 May 2004 10:00:31 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIE11218; Wed, 5 May 2004 13:00:08 -0400 (EDT) Message-ID: <40991D98.70401@cisco.com> Date: Wed, 05 May 2004 13:00:08 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Martin_Andr=E9?= CC: sip@ietf.org Subject: Re: [Sip] Unregistering UA References: <1083766713.27359.385.camel@Frill023456x> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA26157 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org 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 Martin Andr=E9 wrote: > Dear all, >=20 > My question is about Expires duration and unregistrations. Let us > imagine a case where the unregistration is not initiated by the client > (is this allowed ?). Are there any mean to notify the UA that its > registration has been removed ? As far as I understood RFC3261, the > Registrar doesn't generate SIP requests by its own. You are right that the client doesn't get told about this. If it wants to know that sort of thing, the client can subscribe to the=20 "reg" event package on the registrar. Then it will be told about any=20 registration change. > So, is it possible to lower registration duration just like it is > possible with subscription duration ? This way, we could shorten > registration duration (during registration process or with proxy > intervention) and wait until it expires. To reduce the expiration time of a registration, a new registration can=20 be made, replacing the old one. But if that is done by a third party it=20 won't help the client to learn about the change. > I didn't see anything about control on Expires duration. Did I miss > something ? The reg package is probably what you missed. Paul > Thanks in advance for your clarifications, >=20 > Martin >=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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 5 16:25:49 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10075 for ; Wed, 5 May 2004 16:25:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLStG-0002YL-Do for sip-archive@odin.ietf.org; Wed, 05 May 2004 16:21:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45KLEAl009814 for sip-archive@odin.ietf.org; Wed, 5 May 2004 16:21:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLSkM-0007Sq-3L; Wed, 05 May 2004 16: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 1BLSeO-0004zq-6H for sip@optimus.ietf.org; Wed, 05 May 2004 16:05: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 QAA08943 for ; Wed, 5 May 2004 16:05:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLSeM-0000K0-Ga for sip@ietf.org; Wed, 05 May 2004 16:05:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLSdO-000017-00 for sip@ietf.org; Wed, 05 May 2004 16:04:50 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1BLScI-0007I8-00 for sip@ietf.org; Wed, 05 May 2004 16:03:42 -0400 Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i45K3ZIN001778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 5 May 2004 16:03:36 -0400 (EDT) Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i45K3ZTl062111 for ; Wed, 5 May 2004 16:03:35 -0400 (EDT) (envelope-from lennox@cnr.cs.columbia.edu) Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.12.10/8.12.10/Submit) id i45K3Yds062108; Wed, 5 May 2004 16:03:34 -0400 (EDT) (envelope-from lennox) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16537.18582.331777.319059@cnr.cs.columbia.edu> Date: Wed, 5 May 2004 16:03:34 -0400 To: sip@ietf.org X-Mailer: VM 7.18 under Emacs 21.3.1 X-PMX-Version: 4.6.0.97784, Antispam-Core: 4.6.0.97340, Antispam-Data: 2004.5.5.99874 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report='__MIME_VERSION 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, __HAS_MSGID 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __HAS_X_MAILER 0, SIGNATURE_SHORT_DENSE 0, __MIME_TEXT_ONLY 0' X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Bug in RFC 3261 Reason-Phrase BNF Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org 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 RFC 3261 defines the grammar for Reason-Phrase as follows: Reason-Phrase = *(reserved / unreserved / escaped / UTF8-NONASCII / UTF8-CONT / SP / HTAB) I believe the inclusion of UTF8-CONT here is wrong: the UTF8-NONASCII production includes all valid multi-byte UTF-8 strings, including all contexts in which UTF8-CONT characters can appear. Allowing spurious extra UTF8-CONT characters in reason phrases, outside the context of UTF8-NONASCII, leads to invalid UTF-8 strings. The grammar header header-value (a generic value from an extension-header) is similarly wrong: header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) as TEXT-UTF8char also already includes UTF8-CONT. (If the idea is to allow any non-ASCII character, so as to e.g. allow extensions using non-unicode encodings, a different grammar would be needed. This one doesn't do that.) Another note on UTF-8: RFC 3629 (STD 63) gives a BNF grammar describing UTF-8 which is stricter than the one given in RFC 3261. Specifically, the grammar explicitly forbids overlong encodings, e.g. using C0 80 to encode a null byte. (This sort of thing can have security consequences, because an attacker can use it to sneak forbidden characters past your parser.) It also forbids encoding the UTF-16 surrogate pairs, or any character greater than U+0x10FFFF. So any future revision of the SIP spec ought to change its UTF-8 BNF to copy or cite the one in 3629. -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 6 04:34:13 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27369 for ; Thu, 6 May 2004 04:34:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLeEE-0006rB-Qc for sip-archive@odin.ietf.org; Thu, 06 May 2004 04:27:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i468Rchx026356 for sip-archive@odin.ietf.org; Thu, 6 May 2004 04:27:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLe7t-0004q1-Mj; Thu, 06 May 2004 04:21:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLe3m-0002sE-BS for sip@optimus.ietf.org; Thu, 06 May 2004 04:16:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26516 for ; Thu, 6 May 2004 04:16:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLe3j-0007TY-Ky for sip@ietf.org; Thu, 06 May 2004 04:16:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLe2f-00074k-00 for sip@ietf.org; Thu, 06 May 2004 04:15:42 -0400 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BLe1h-0006JW-00; Thu, 06 May 2004 04:14:42 -0400 Received: from huawei08hiby56 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HXA005PH9HHG2@mta0.huawei.com>; Thu, 06 May 2004 16:12:54 +0800 (CST) Date: Thu, 06 May 2004 13:48:54 +0530 From: Prasanna Subject: RE: [Sip] Bug in RFC3261 ? In-reply-to: <2038BCC78B1AD641891A0D1AE133DBB701797A31@esebe019.ntc.nokia.com> To: hisham.khartabil@nokia.com, Ben.Gatewood@didata.com.au, sebastien.prouvost@francetelecom.com Cc: sip@ietf.org, sip-admin@ietf.org Message-id: <000001c43342$c67a79f0$e905120a@huawei08hiby56> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,EXCUSE_16 autolearn=no version=2.60 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 There is a basic confusion... 8.1.3.3 mentions that the "UAC" should discard the message. But is it the "transaction layer" that is discarding the message or the = "TU" (which is the UA core in this case) discarding the message. If the transaction discards it, Hisham's flow is okay, the timers will = fire. But what if the UA core discards. Assuming the UPDATE----200 exchange, In this case, the transaction would have assumed the 200 response to be = fine and moved to the "completed" state. There is no Timer F in this case anyway. Worse will be case if the exchange is INVITE---180----200, And 200 has to be discarded. The moment transaction deemed the 200 to = be okay, it will terminate. Even if what 8.1.3.3 mentions is for the transaction, how about the validation of the Table 2 / Table 3 requirements. What if there is 423 without Min-Expires or a 200 for INVITE without Contact? Should the complete validation be done by the transaction layer? Cheers, Prasanna -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of hisham.khartabil@nokia.com Sent: Wednesday, May 05, 2004 1:42 PM To: Ben.Gatewood@didata.com.au; sebastien.prouvost@francetelecom.com Cc: sip@ietf.org; sip-admin@ietf.org Subject: RE: [Sip] Bug in RFC3261 ? Well, you were pointing at the right sections. 17.1.1.2 and 17.1.2.2 = specify that when Timer B (for INVITE) and Timer F (for non-INVITE) fire, "the client transaction SHOULD inform the TU about the timeout, and then it SHOULD enter the "Terminated" state" Hisham -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext Ben.Gatewood@didata.com.au Sent: 05.May.2004 03:02 To: PROUVOST S=E9bastien FTRD/DAC/ISS Cc: sip@ietf.org; sip-admin@ietf.org Subject: Re: [Sip] Bug in RFC3261 ? Hi S=E9bastien,=20 I just re-read your question and realised it's more complicated than I thought :-)=20 Hmmm......I'm not sure what it should do either.=20 I'm sure someone smarter than me will be along shortly though :-)=20 B Ben Gatewood Dimension Data SIP Wookie Level 1 10 Dorcas Street South Melbourne +61 3 9626 0735 +61 419 885 762 ben.gatewood@didata.com.au=20 Ben.Gatewood@didata.com.au=20 Sent by: sip-admin@ietf.org=20 05/05/2004 08:33 AM=20 =20 To: PROUVOST S=E9bastien FTRD/DAC/ISS =20 cc: sip@ietf.org, sip-admin@ietf.org=20 Subject: Re: [Sip] Bug in RFC3261 ? Hi S=E9bastien,=20 There are procedures and timers for this situation in 3261. Have a look = at Section 17.1.1.2 and 17.1.2.2.=20 Basically the UA should wait 64*T1 (Timer 1). T1, by default, should be 500ms so your UA should wait 32 seconds for a valid response.=20 HTH,=20 B Ben Gatewood Dimension Data SIP Wookie Level 1 10 Dorcas Street South Melbourne +61 3 9626 0735 +61 419 885 762 ben.gatewood@didata.com.au=20 PROUVOST S=E9bastien FTRD/DAC/ISS = Sent by: sip-admin@ietf.org=20 04/05/2004 07:49 PM =20 To: =20 cc: =20 Subject: [Sip] Bug in RFC3261 ? Hi,=20 In RFC 3261, it is written (section 8.1.3.3 for UAC Core procedures) : = "If more than one Via header field value is present in a response, the UAC SHOULD discard the message."=20 However if the UAC Core layer discards the response and if this response = was the only one sent (for example a 200 OK to an UPDATE), then this leads = to a situation when the transaction is terminated (the transaction layer = received the response and passed it to the UA Core) but the UA Core is still = waiting for a response (it discarded the 200 OK because of the presence of two = Via header field values and so is still waiting for the response).=20 I believe there shall be procedures that tells the UAC Core when to stop waiting for the response. Or am I misunderstanding something ?=20 Thanks for your clarifications,=20 S=E9bastien Prouvost=20 France Telecom R&D=20 *************************************************************************= *** ** - NOTICE FROM DIMENSION DATA AUSTRALIA This message is confidential, and may contain proprietary or legally privileged information. If you have received this email in error, please notify the sender and delete it immediately. Internet communications are not secure. You should scan this message and = any attachments for viruses. Under no circumstances do we accept liability = for any loss or damage which may result from your receipt of this message or = any attachments. *************************************************************************= *** **=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 Thu May 6 05:56:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02048 for ; Thu, 6 May 2004 05:56: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 1BLfZh-0007p7-Pa for sip-archive@odin.ietf.org; Thu, 06 May 2004 05:53:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i469rrqR030073 for sip-archive@odin.ietf.org; Thu, 6 May 2004 05:53:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLfT5-0004yH-L1; Thu, 06 May 2004 05:47:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLfJm-0001J5-HW for sip@optimus.ietf.org; Thu, 06 May 2004 05:37: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 FAA01091 for ; Thu, 6 May 2004 05:37:23 -0400 (EDT) From: kowsalya@npd.hcltech.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLfJj-0006yw-0S for sip@ietf.org; Thu, 06 May 2004 05:37:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLfHl-0006Q1-00 for sip@ietf.org; Thu, 06 May 2004 05:35:22 -0400 Received: from [202.54.64.17] (helo=hclnpd.hcltech.com) by ietf-mx with esmtp (Exim 4.12) id 1BLfFp-0005Xn-00; Thu, 06 May 2004 05:33:21 -0400 Received: from pilex.hclt-ntl.co.in ([192.168.19.34]) by hclnpd.hcltech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KK5RYFV3; Thu, 6 May 2004 15:02:02 +0530 Received: by PILEX with Internet Mail Service (5.5.2653.19) id ; Thu, 6 May 2004 15:05:39 +0530 Message-ID: <50D40047DC73D611BDA60050BAC4EDD9010C9D91@PILEX> To: prasanna@huawei.com, hisham.khartabil@nokia.com, Ben.Gatewood@didata.com.au, sebastien.prouvost@francetelecom.com Cc: sip@ietf.org, sip-admin@ietf.org Subject: RE: [Sip] Bug in RFC3261 ? Date: Thu, 6 May 2004 15:05:38 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 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 Prasanna, The number of via headers cannot and should not be validated by the transaction layer. Ideally, the transaction layer should not know whether the message is for the proxy TU or the UA TU. In the former, more than one via header will be present. Thanks Kowsalya > -----Original Message----- > From: Prasanna [mailto:prasanna@huawei.com] > Sent: Thursday, May 06, 2004 1:49 PM > To: hisham.khartabil@nokia.com; Ben.Gatewood@didata.com.au; > sebastien.prouvost@francetelecom.com > Cc: sip@ietf.org; sip-admin@ietf.org > Subject: RE: [Sip] Bug in RFC3261 ? >=20 >=20 > There is a basic confusion... > 8.1.3.3 mentions that the "UAC" should discard the message. > But is it the "transaction layer" that is discarding the=20 > message or the "TU" > (which is the UA core in this case) discarding the message. > If the transaction discards it, Hisham's flow is okay, the=20 > timers will fire. > But what if the UA core discards. Assuming the UPDATE----200=20 > exchange, > In this case, the transaction would have assumed the 200=20 > response to be fine > and moved to the "completed" state. There is no Timer F in this case > anyway. > Worse will be case if the exchange is INVITE---180----200, > And 200 has to be discarded. The moment transaction deemed=20 > the 200 to be > okay, it will terminate. >=20 >=20 > Even if what 8.1.3.3 mentions is for the transaction, how about the > validation of the Table 2 / Table 3 requirements. > What if there is 423 without Min-Expires or a 200 for INVITE without > Contact? >=20 > Should the complete validation be done by the transaction layer? >=20 > Cheers, > Prasanna >=20 > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of > hisham.khartabil@nokia.com > Sent: Wednesday, May 05, 2004 1:42 PM > To: Ben.Gatewood@didata.com.au; sebastien.prouvost@francetelecom.com > Cc: sip@ietf.org; sip-admin@ietf.org > Subject: RE: [Sip] Bug in RFC3261 ? >=20 >=20 > Well, you were pointing at the right sections. 17.1.1.2 and=20 > 17.1.2.2 specify > that when Timer B (for INVITE) and Timer F (for non-INVITE) fire, = "the > client transaction SHOULD inform the TU about the > timeout, and then it SHOULD enter the "Terminated" state" >=20 > Hisham > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext > Ben.Gatewood@didata.com.au > Sent: 05.May.2004 03:02 > To: PROUVOST S=E9bastien FTRD/DAC/ISS > Cc: sip@ietf.org; sip-admin@ietf.org > Subject: Re: [Sip] Bug in RFC3261 ? >=20 >=20 >=20 > Hi S=E9bastien,=20 >=20 > I just re-read your question and realised it's more complicated than = I > thought :-)=20 >=20 > Hmmm......I'm not sure what it should do either.=20 >=20 > I'm sure someone smarter than me will be along shortly though :-)=20 >=20 > B >=20 > Ben Gatewood > Dimension Data > SIP Wookie > Level 1 10 Dorcas Street South Melbourne > +61 3 9626 0735 > +61 419 885 762 > ben.gatewood@didata.com.au=20 >=20 >=20 > Ben.Gatewood@didata.com.au=20 > Sent by: sip-admin@ietf.org=20 > 05/05/2004 08:33 AM=20 > =20 > To: PROUVOST S=E9bastien FTRD/DAC/ISS > =20 > cc: sip@ietf.org, sip-admin@ietf.org=20 > Subject: Re: [Sip] Bug in RFC3261 ? >=20 >=20 >=20 >=20 > Hi S=E9bastien,=20 >=20 > There are procedures and timers for this situation in 3261.=20 > Have a look at > Section 17.1.1.2 and 17.1.2.2.=20 >=20 > Basically the UA should wait 64*T1 (Timer 1). T1, by default,=20 > should be > 500ms so your UA should wait 32 seconds for a valid response.=20 >=20 > HTH,=20 >=20 > B >=20 > Ben Gatewood > Dimension Data > SIP Wookie > Level 1 10 Dorcas Street South Melbourne > +61 3 9626 0735 > +61 419 885 762 > ben.gatewood@didata.com.au=20 >=20 > PROUVOST S=E9bastien FTRD/DAC/ISS=20 > =20 > Sent by: sip-admin@ietf.org=20 > 04/05/2004 07:49 PM =20 > To: =20 > cc: =20 > Subject: [Sip] Bug in RFC3261 ? >=20 >=20 >=20 >=20 > Hi,=20 > In RFC 3261, it is written (section 8.1.3.3 for UAC Core=20 > procedures) : "If > more than one Via header field value is present in a response, the = UAC > SHOULD discard the message."=20 > However if the UAC Core layer discards the response and if=20 > this response was > the only one sent (for example a 200 OK to an UPDATE), then=20 > this leads to a > situation when the transaction is terminated (the transaction=20 > layer received > the response and passed it to the UA Core) but the UA Core is=20 > still waiting > for a response (it discarded the 200 OK because of the=20 > presence of two Via > header field values and so is still waiting for the response).=20 > I believe there shall be procedures that tells the UAC Core=20 > when to stop > waiting for the response. Or am I misunderstanding something ?=20 > Thanks for your clarifications,=20 > S=E9bastien Prouvost=20 > France Telecom R&D=20 >=20 >=20 > ************************************************************** > ************** > ** > - NOTICE FROM DIMENSION DATA AUSTRALIA > This message is confidential, and may contain proprietary or legally > privileged information. If you have received this email in=20 > error, please > notify the sender and delete it immediately. >=20 > Internet communications are not secure. You should scan this=20 > message and any > attachments for viruses. Under no circumstances do we accept=20 > liability for > any loss or damage which may result from your receipt of this=20 > message or any > attachments. > ************************************************************** > ************** > **=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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 6 06:23:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03678 for ; Thu, 6 May 2004 06:23: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 1BLfzy-0003Mj-QR for sip-archive@odin.ietf.org; Thu, 06 May 2004 06:21:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46AL2C9012937 for sip-archive@odin.ietf.org; Thu, 6 May 2004 06:21:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLfsE-0007d6-G0; Thu, 06 May 2004 06:13:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLfny-0005Kg-KR for sip@optimus.ietf.org; Thu, 06 May 2004 06:08: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 GAA02658 for ; Thu, 6 May 2004 06:08:34 -0400 (EDT) From: kowsalya@npd.hcltech.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLfnu-0003pI-T0 for sip@ietf.org; Thu, 06 May 2004 06:08:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLfmw-0003Sg-00 for sip@ietf.org; Thu, 06 May 2004 06:07:35 -0400 Received: from [202.54.64.17] (helo=hclnpd.hcltech.com) by ietf-mx with esmtp (Exim 4.12) id 1BLfme-00036C-00; Thu, 06 May 2004 06:07:16 -0400 Received: from pilex.hclt-ntl.co.in ([192.168.19.34]) by hclnpd.hcltech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KK5RYGAZ; Thu, 6 May 2004 15:35:58 +0530 Received: by PILEX with Internet Mail Service (5.5.2653.19) id ; Thu, 6 May 2004 15:39:34 +0530 Message-ID: <50D40047DC73D611BDA60050BAC4EDD9010C9D98@PILEX> To: kowsalya@npd.hcltech.com, prasanna@huawei.com, hisham.khartabil@nokia.com, Ben.Gatewood@didata.com.au, sebastien.prouvost@francetelecom.com Cc: sip@ietf.org, sip-admin@ietf.org Subject: RE: [Sip] Bug in RFC3261 ? Date: Thu, 6 May 2004 15:39:33 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 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 actually feel this is more a question of whether to accept non conforming peers. If the implementation should be strict it can simply terminate the associated dialog, otherwise accept the response and face it. I don't think RFC can provide any guidelines on these situations. > -----Original Message----- > From: kowsalya@npd.hcltech.com [mailto:kowsalya@npd.hcltech.com] > Sent: Thursday, May 06, 2004 3:06 PM > To: prasanna@huawei.com; hisham.khartabil@nokia.com; > Ben.Gatewood@didata.com.au; sebastien.prouvost@francetelecom.com > Cc: sip@ietf.org; sip-admin@ietf.org > Subject: RE: [Sip] Bug in RFC3261 ? >=20 >=20 > Hi Prasanna, >=20 > The number of via headers cannot and should not > be validated by the transaction layer. Ideally, > the transaction layer should not know whether > the message is for the proxy TU or the UA TU. > In the former, more than one via header will > be present. >=20 > Thanks > Kowsalya >=20 > > -----Original Message----- > > From: Prasanna [mailto:prasanna@huawei.com] > > Sent: Thursday, May 06, 2004 1:49 PM > > To: hisham.khartabil@nokia.com; Ben.Gatewood@didata.com.au; > > sebastien.prouvost@francetelecom.com > > Cc: sip@ietf.org; sip-admin@ietf.org > > Subject: RE: [Sip] Bug in RFC3261 ? > >=20 > >=20 > > There is a basic confusion... > > 8.1.3.3 mentions that the "UAC" should discard the message. > > But is it the "transaction layer" that is discarding the=20 > > message or the "TU" > > (which is the UA core in this case) discarding the message. > > If the transaction discards it, Hisham's flow is okay, the=20 > > timers will fire. > > But what if the UA core discards. Assuming the UPDATE----200=20 > > exchange, > > In this case, the transaction would have assumed the 200=20 > > response to be fine > > and moved to the "completed" state. There is no Timer F in=20 > this case > > anyway. > > Worse will be case if the exchange is INVITE---180----200, > > And 200 has to be discarded. The moment transaction deemed=20 > > the 200 to be > > okay, it will terminate. > >=20 > >=20 > > Even if what 8.1.3.3 mentions is for the transaction, how about the > > validation of the Table 2 / Table 3 requirements. > > What if there is 423 without Min-Expires or a 200 for INVITE = without > > Contact? > >=20 > > Should the complete validation be done by the transaction layer? > >=20 > > Cheers, > > Prasanna > >=20 > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of > > hisham.khartabil@nokia.com > > Sent: Wednesday, May 05, 2004 1:42 PM > > To: Ben.Gatewood@didata.com.au; = sebastien.prouvost@francetelecom.com > > Cc: sip@ietf.org; sip-admin@ietf.org > > Subject: RE: [Sip] Bug in RFC3261 ? > >=20 > >=20 > > Well, you were pointing at the right sections. 17.1.1.2 and=20 > > 17.1.2.2 specify > > that when Timer B (for INVITE) and Timer F (for non-INVITE)=20 > fire, "the > > client transaction SHOULD inform the TU about the > > timeout, and then it SHOULD enter the "Terminated" state" > >=20 > > Hisham > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of = ext > > Ben.Gatewood@didata.com.au > > Sent: 05.May.2004 03:02 > > To: PROUVOST S=E9bastien FTRD/DAC/ISS > > Cc: sip@ietf.org; sip-admin@ietf.org > > Subject: Re: [Sip] Bug in RFC3261 ? > >=20 > >=20 > >=20 > > Hi S=E9bastien,=20 > >=20 > > I just re-read your question and realised it's more=20 > complicated than I > > thought :-)=20 > >=20 > > Hmmm......I'm not sure what it should do either.=20 > >=20 > > I'm sure someone smarter than me will be along shortly though :-)=20 > >=20 > > B > >=20 > > Ben Gatewood > > Dimension Data > > SIP Wookie > > Level 1 10 Dorcas Street South Melbourne > > +61 3 9626 0735 > > +61 419 885 762 > > ben.gatewood@didata.com.au=20 > >=20 > >=20 > > Ben.Gatewood@didata.com.au=20 > > Sent by: sip-admin@ietf.org=20 > > 05/05/2004 08:33 AM=20 > > =20 > > To: PROUVOST S=E9bastien FTRD/DAC/ISS > > =20 > > cc: sip@ietf.org, sip-admin@ietf.org=20 > > Subject: Re: [Sip] Bug in RFC3261 ? > >=20 > >=20 > >=20 > >=20 > > Hi S=E9bastien,=20 > >=20 > > There are procedures and timers for this situation in 3261.=20 > > Have a look at > > Section 17.1.1.2 and 17.1.2.2.=20 > >=20 > > Basically the UA should wait 64*T1 (Timer 1). T1, by default,=20 > > should be > > 500ms so your UA should wait 32 seconds for a valid response.=20 > >=20 > > HTH,=20 > >=20 > > B > >=20 > > Ben Gatewood > > Dimension Data > > SIP Wookie > > Level 1 10 Dorcas Street South Melbourne > > +61 3 9626 0735 > > +61 419 885 762 > > ben.gatewood@didata.com.au=20 > >=20 > > PROUVOST S=E9bastien FTRD/DAC/ISS=20 > > =20 > > Sent by: sip-admin@ietf.org=20 > > 04/05/2004 07:49 PM =20 > > To: =20 > > cc: =20 > > Subject: [Sip] Bug in RFC3261 ? > >=20 > >=20 > >=20 > >=20 > > Hi,=20 > > In RFC 3261, it is written (section 8.1.3.3 for UAC Core=20 > > procedures) : "If > > more than one Via header field value is present in a=20 > response, the UAC > > SHOULD discard the message."=20 > > However if the UAC Core layer discards the response and if=20 > > this response was > > the only one sent (for example a 200 OK to an UPDATE), then=20 > > this leads to a > > situation when the transaction is terminated (the transaction=20 > > layer received > > the response and passed it to the UA Core) but the UA Core is=20 > > still waiting > > for a response (it discarded the 200 OK because of the=20 > > presence of two Via > > header field values and so is still waiting for the response).=20 > > I believe there shall be procedures that tells the UAC Core=20 > > when to stop > > waiting for the response. Or am I misunderstanding something ?=20 > > Thanks for your clarifications,=20 > > S=E9bastien Prouvost=20 > > France Telecom R&D=20 > >=20 > >=20 > > ************************************************************** > > ************** > > ** > > - NOTICE FROM DIMENSION DATA AUSTRALIA > > This message is confidential, and may contain proprietary or = legally > > privileged information. If you have received this email in=20 > > error, please > > notify the sender and delete it immediately. > >=20 > > Internet communications are not secure. You should scan this=20 > > message and any > > attachments for viruses. Under no circumstances do we accept=20 > > liability for > > any loss or damage which may result from your receipt of this=20 > > message or any > > attachments. > > ************************************************************** > > ************** > > **=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 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Thu May 6 06:58:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05454 for ; Thu, 6 May 2004 06:58: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 1BLgPf-0005b2-Fo for sip-archive@odin.ietf.org; Thu, 06 May 2004 06:47:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46AlZwm021513 for sip-archive@odin.ietf.org; Thu, 6 May 2004 06:47:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLgJN-0001yF-5l; Thu, 06 May 2004 06:41:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLgF4-0000ia-5l for sip@optimus.ietf.org; Thu, 06 May 2004 06:36: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 GAA04470 for ; Thu, 6 May 2004 06:36:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLgF0-0007Mc-59 for sip@ietf.org; Thu, 06 May 2004 06:36:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLgE9-0006yz-00 for sip@ietf.org; Thu, 06 May 2004 06:35:42 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1BLgDH-0006aG-00; Thu, 06 May 2004 06:34:48 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id i46AYgxn028515; Thu, 6 May 2004 03:34:42 -0700 (MST) Received: from zin09exm01.corp.mot.com (zin09exm01.corp.mot.com [10.232.100.1]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i46AYEUL000956; Thu, 6 May 2004 05:34:37 -0500 Received: by zin09exm01.corp.mot.com with Internet Mail Service (5.5.2657.72) id ; Thu, 6 May 2004 16:04:12 +0530 Message-ID: From: Chadha Retesh-A19894 To: kowsalya@npd.hcltech.com, prasanna@huawei.com, hisham.khartabil@nokia.com, Ben.Gatewood@didata.com.au, sebastien.prouvost@francetelecom.com Cc: sip@ietf.org, sip-admin@ietf.org Subject: RE: [Sip] Bug in RFC3261 ? Date: Thu, 6 May 2004 16:04:11 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ftpbox.mot.com id i46AYgxn028515 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Similar is the following scenario --- 200 ok to an INVITE matching the transaction (same branch in top via head= er), but not matching the dialog parameters (from tag, call-tag, etc). In this case, the INVITE transaction will be terminated with an erroneou= s 200 ok. Now, if the correct 200 response comes, it will be considered a= s a retransmission and ignored. In the above and all such cases, I feel uac should take a call on being s= trict or not. If it needs to consider such responses as invalid, it shoul= d terminate the call, and take the same action as it would have taken for= a non-successful response. Regards Retesh -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of kowsaly= a@npd.hcltech.com Sent: Thursday, May 06, 2004 3:40 PM To: kowsalya@npd.hcltech.com; prasanna@huawei.com; hisham.khartabil@nokia= .com; Ben.Gatewood@didata.com.au; sebastien.prouvost@francetelecom.com Cc: sip@ietf.org; sip-admin@ietf.org Subject: RE: [Sip] Bug in RFC3261 ? I actually feel this is more a question of whether to accept non conforming peers. If the implementation should be strict it can simply terminate the associated dialog, otherwise accept the response and face it. I don't think RFC can provide any guidelines on these situations. > -----Original Message----- > From: kowsalya@npd.hcltech.com [mailto:kowsalya@npd.hcltech.com] > Sent: Thursday, May 06, 2004 3:06 PM > To: prasanna@huawei.com; hisham.khartabil@nokia.com; > Ben.Gatewood@didata.com.au; sebastien.prouvost@francetelecom.com > Cc: sip@ietf.org; sip-admin@ietf.org > Subject: RE: [Sip] Bug in RFC3261 ? >=20 >=20 > Hi Prasanna, >=20 > The number of via headers cannot and should not > be validated by the transaction layer. Ideally, > the transaction layer should not know whether > the message is for the proxy TU or the UA TU. > In the former, more than one via header will > be present. >=20 > Thanks > Kowsalya >=20 > > -----Original Message----- > > From: Prasanna [mailto:prasanna@huawei.com] > > Sent: Thursday, May 06, 2004 1:49 PM > > To: hisham.khartabil@nokia.com; Ben.Gatewood@didata.com.au; > > sebastien.prouvost@francetelecom.com > > Cc: sip@ietf.org; sip-admin@ietf.org > > Subject: RE: [Sip] Bug in RFC3261 ? > >=20 > >=20 > > There is a basic confusion... > > 8.1.3.3 mentions that the "UAC" should discard the message. > > But is it the "transaction layer" that is discarding the=20 > > message or the "TU" > > (which is the UA core in this case) discarding the message. > > If the transaction discards it, Hisham's flow is okay, the=20 > > timers will fire. > > But what if the UA core discards. Assuming the UPDATE----200=20 > > exchange, > > In this case, the transaction would have assumed the 200=20 > > response to be fine > > and moved to the "completed" state. There is no Timer F in=20 > this case > > anyway. > > Worse will be case if the exchange is INVITE---180----200, > > And 200 has to be discarded. The moment transaction deemed=20 > > the 200 to be > > okay, it will terminate. > >=20 > >=20 > > Even if what 8.1.3.3 mentions is for the transaction, how about the > > validation of the Table 2 / Table 3 requirements. > > What if there is 423 without Min-Expires or a 200 for INVITE without > > Contact? > >=20 > > Should the complete validation be done by the transaction layer? > >=20 > > Cheers, > > Prasanna > >=20 > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of > > hisham.khartabil@nokia.com > > Sent: Wednesday, May 05, 2004 1:42 PM > > To: Ben.Gatewood@didata.com.au; sebastien.prouvost@francetelecom.com > > Cc: sip@ietf.org; sip-admin@ietf.org > > Subject: RE: [Sip] Bug in RFC3261 ? > >=20 > >=20 > > Well, you were pointing at the right sections. 17.1.1.2 and=20 > > 17.1.2.2 specify > > that when Timer B (for INVITE) and Timer F (for non-INVITE)=20 > fire, "the > > client transaction SHOULD inform the TU about the > > timeout, and then it SHOULD enter the "Terminated" state" > >=20 > > Hisham > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext > > Ben.Gatewood@didata.com.au > > Sent: 05.May.2004 03:02 > > To: PROUVOST S=E9bastien FTRD/DAC/ISS > > Cc: sip@ietf.org; sip-admin@ietf.org > > Subject: Re: [Sip] Bug in RFC3261 ? > >=20 > >=20 > >=20 > > Hi S=E9bastien,=20 > >=20 > > I just re-read your question and realised it's more=20 > complicated than I > > thought :-)=20 > >=20 > > Hmmm......I'm not sure what it should do either.=20 > >=20 > > I'm sure someone smarter than me will be along shortly though :-)=20 > >=20 > > B > >=20 > > Ben Gatewood > > Dimension Data > > SIP Wookie > > Level 1 10 Dorcas Street South Melbourne > > +61 3 9626 0735 > > +61 419 885 762 > > ben.gatewood@didata.com.au=20 > >=20 > >=20 > > Ben.Gatewood@didata.com.au=20 > > Sent by: sip-admin@ietf.org=20 > > 05/05/2004 08:33 AM=20 > > =20 > > To: PROUVOST S=E9bastien FTRD/DAC/ISS > > =20 > > cc: sip@ietf.org, sip-admin@ietf.org=20 > > Subject: Re: [Sip] Bug in RFC3261 ? > >=20 > >=20 > >=20 > >=20 > > Hi S=E9bastien,=20 > >=20 > > There are procedures and timers for this situation in 3261.=20 > > Have a look at > > Section 17.1.1.2 and 17.1.2.2.=20 > >=20 > > Basically the UA should wait 64*T1 (Timer 1). T1, by default,=20 > > should be > > 500ms so your UA should wait 32 seconds for a valid response.=20 > >=20 > > HTH,=20 > >=20 > > B > >=20 > > Ben Gatewood > > Dimension Data > > SIP Wookie > > Level 1 10 Dorcas Street South Melbourne > > +61 3 9626 0735 > > +61 419 885 762 > > ben.gatewood@didata.com.au=20 > >=20 > > PROUVOST S=E9bastien FTRD/DAC/ISS=20 > > =20 > > Sent by: sip-admin@ietf.org=20 > > 04/05/2004 07:49 PM =20 > > To: =20 > > cc: =20 > > Subject: [Sip] Bug in RFC3261 ? > >=20 > >=20 > >=20 > >=20 > > Hi,=20 > > In RFC 3261, it is written (section 8.1.3.3 for UAC Core=20 > > procedures) : "If > > more than one Via header field value is present in a=20 > response, the UAC > > SHOULD discard the message."=20 > > However if the UAC Core layer discards the response and if=20 > > this response was > > the only one sent (for example a 200 OK to an UPDATE), then=20 > > this leads to a > > situation when the transaction is terminated (the transaction=20 > > layer received > > the response and passed it to the UA Core) but the UA Core is=20 > > still waiting > > for a response (it discarded the 200 OK because of the=20 > > presence of two Via > > header field values and so is still waiting for the response).=20 > > I believe there shall be procedures that tells the UAC Core=20 > > when to stop > > waiting for the response. Or am I misunderstanding something ?=20 > > Thanks for your clarifications,=20 > > S=E9bastien Prouvost=20 > > France Telecom R&D=20 > >=20 > >=20 > > ************************************************************** > > ************** > > ** > > - NOTICE FROM DIMENSION DATA AUSTRALIA > > This message is confidential, and may contain proprietary or legally > > privileged information. If you have received this email in=20 > > error, please > > notify the sender and delete it immediately. > >=20 > > Internet communications are not secure. You should scan this=20 > > message and any > > attachments for viruses. Under no circumstances do we accept=20 > > liability for > > any loss or damage which may result from your receipt of this=20 > > message or any > > attachments. > > ************************************************************** > > ************** > > **=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 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 6 07:12:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06172 for ; Thu, 6 May 2004 07:12: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 1BLgl8-0005Um-A5 for sip-archive@odin.ietf.org; Thu, 06 May 2004 07:09:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46B9keg021104 for sip-archive@odin.ietf.org; Thu, 6 May 2004 07:09:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLgfa-00032V-O1; Thu, 06 May 2004 07: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 1BLgcg-0001Ds-0B for sip@optimus.ietf.org; Thu, 06 May 2004 07:01: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 HAA05588 for ; Thu, 6 May 2004 07:00:57 -0400 (EDT) From: ranjit.avasarala@wipro.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLgcb-0001GT-Nc for sip@ietf.org; Thu, 06 May 2004 07:00:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLgbS-0000nK-00 for sip@ietf.org; Thu, 06 May 2004 06:59:47 -0400 Received: from wiproecmx1.wipro.com ([164.164.31.5]) by ietf-mx with esmtp (Exim 4.12) id 1BLgaS-0007nP-00; Thu, 06 May 2004 06:58:47 -0400 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx1.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i46AvObp007660; Thu, 6 May 2004 16:27:25 +0530 (IST) Received: from blr-ec-bh3.wipro.com ([10.200.50.93]) by ec-vwall-wd with InterScan Messaging Security Suite; Thu, 06 May 2004 16:27:22 +0530 Received: from blr-ec-msg03.wipro.com ([10.200.52.99]) by blr-ec-bh3.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 6 May 2004 16:27:21 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Bug in RFC3261 ? Date: Thu, 6 May 2004 16:27:21 +0530 Message-ID: Thread-Topic: [Sip] Bug in RFC3261 ? Thread-Index: AcQzV4fzLIPevrKaQ7uWNYWeJJm4YQAAI7CA To: , , , , , Cc: , X-OriginalArrivalTime: 06 May 2004 10:57:21.0974 (UTC) FILETIME=[E83E1D60:01C43358] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,EXCUSE_16,NO_REAL_NAME autolearn=no version=2.60 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 Regards Ranjit -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Chadha = Retesh-A19894 Sent: Thursday, May 06, 2004 4:04 PM To: kowsalya@npd.hcltech.com; prasanna@huawei.com; = hisham.khartabil@nokia.com; Ben.Gatewood@didata.com.au; = sebastien.prouvost@francetelecom.com Cc: sip@ietf.org; sip-admin@ietf.org Subject: RE: [Sip] Bug in RFC3261 ? Similar is the following scenario --- 200 ok to an INVITE matching the transaction (same branch in top via = header), but not matching the dialog parameters (from tag, call-tag, = etc). In this case, the INVITE transaction will be terminated with an = erroneous 200 ok. Now, if the correct 200 response comes, it will be = considered as a retransmission and ignored. [Ranjit] I think if the 200 OK received is not matching the dialog = parameters, it is as good as not receiving the 200 OK. So UAC could = retransmit INVITE.=20 In the above and all such cases, I feel uac should take a call on being = strict or not. If it needs to consider such responses as invalid, it = should terminate the call, and take the same action as it would have = taken for a non-successful response. Regards Retesh -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of = kowsalya@npd.hcltech.com Sent: Thursday, May 06, 2004 3:40 PM To: kowsalya@npd.hcltech.com; prasanna@huawei.com; = hisham.khartabil@nokia.com; Ben.Gatewood@didata.com.au; = sebastien.prouvost@francetelecom.com Cc: sip@ietf.org; sip-admin@ietf.org Subject: RE: [Sip] Bug in RFC3261 ? I actually feel this is more a question of whether to accept non conforming peers. If the implementation should be strict it can simply terminate the associated dialog, otherwise accept the response and face it. I don't think RFC can provide any guidelines on these situations. > -----Original Message----- > From: kowsalya@npd.hcltech.com [mailto:kowsalya@npd.hcltech.com] > Sent: Thursday, May 06, 2004 3:06 PM > To: prasanna@huawei.com; hisham.khartabil@nokia.com;=20 > Ben.Gatewood@didata.com.au; sebastien.prouvost@francetelecom.com > Cc: sip@ietf.org; sip-admin@ietf.org > Subject: RE: [Sip] Bug in RFC3261 ? >=20 >=20 > Hi Prasanna, >=20 > The number of via headers cannot and should not > be validated by the transaction layer. Ideally, > the transaction layer should not know whether > the message is for the proxy TU or the UA TU. > In the former, more than one via header will > be present. >=20 > Thanks > Kowsalya >=20 > > -----Original Message----- > > From: Prasanna [mailto:prasanna@huawei.com] > > Sent: Thursday, May 06, 2004 1:49 PM > > To: hisham.khartabil@nokia.com; Ben.Gatewood@didata.com.au;=20 > > sebastien.prouvost@francetelecom.com > > Cc: sip@ietf.org; sip-admin@ietf.org > > Subject: RE: [Sip] Bug in RFC3261 ? > >=20 > >=20 > > There is a basic confusion... > > 8.1.3.3 mentions that the "UAC" should discard the message. But is=20 > > it the "transaction layer" that is discarding the message or the=20 > > "TU" (which is the UA core in this case) discarding the message. > > If the transaction discards it, Hisham's flow is okay, the=20 > > timers will fire. > > But what if the UA core discards. Assuming the UPDATE----200=20 > > exchange, > > In this case, the transaction would have assumed the 200=20 > > response to be fine > > and moved to the "completed" state. There is no Timer F in=20 > this case > > anyway. > > Worse will be case if the exchange is INVITE---180----200, And 200=20 > > has to be discarded. The moment transaction deemed the 200 to be > > okay, it will terminate. > >=20 > >=20 > > Even if what 8.1.3.3 mentions is for the transaction, how about the=20 > > validation of the Table 2 / Table 3 requirements. What if there is=20 > > 423 without Min-Expires or a 200 for INVITE without Contact? > >=20 > > Should the complete validation be done by the transaction layer? > >=20 > > Cheers, > > Prasanna > >=20 > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of=20 > > hisham.khartabil@nokia.com > > Sent: Wednesday, May 05, 2004 1:42 PM > > To: Ben.Gatewood@didata.com.au; sebastien.prouvost@francetelecom.com > > Cc: sip@ietf.org; sip-admin@ietf.org > > Subject: RE: [Sip] Bug in RFC3261 ? > >=20 > >=20 > > Well, you were pointing at the right sections. 17.1.1.2 and > > 17.1.2.2 specify > > that when Timer B (for INVITE) and Timer F (for non-INVITE)=20 > fire, "the > > client transaction SHOULD inform the TU about the > > timeout, and then it SHOULD enter the "Terminated" state" > >=20 > > Hisham > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext = > > Ben.Gatewood@didata.com.au > > Sent: 05.May.2004 03:02 > > To: PROUVOST S=E9bastien FTRD/DAC/ISS > > Cc: sip@ietf.org; sip-admin@ietf.org > > Subject: Re: [Sip] Bug in RFC3261 ? > >=20 > >=20 > >=20 > > Hi S=E9bastien, > >=20 > > I just re-read your question and realised it's more > complicated than I > > thought :-) > >=20 > > Hmmm......I'm not sure what it should do either. > >=20 > > I'm sure someone smarter than me will be along shortly though :-) > >=20 > > B > >=20 > > Ben Gatewood > > Dimension Data > > SIP Wookie > > Level 1 10 Dorcas Street South Melbourne > > +61 3 9626 0735 > > +61 419 885 762 > > ben.gatewood@didata.com.au > >=20 > >=20 > > Ben.Gatewood@didata.com.au > > Sent by: sip-admin@ietf.org=20 > > 05/05/2004 08:33 AM=20 > > =20 > > To: PROUVOST S=E9bastien FTRD/DAC/ISS > > =20 > > cc: sip@ietf.org, sip-admin@ietf.org=20 > > Subject: Re: [Sip] Bug in RFC3261 ? > >=20 > >=20 > >=20 > >=20 > > Hi S=E9bastien, > >=20 > > There are procedures and timers for this situation in 3261. > > Have a look at > > Section 17.1.1.2 and 17.1.2.2.=20 > >=20 > > Basically the UA should wait 64*T1 (Timer 1). T1, by default, > > should be > > 500ms so your UA should wait 32 seconds for a valid response.=20 > >=20 > > HTH, > >=20 > > B > >=20 > > Ben Gatewood > > Dimension Data > > SIP Wookie > > Level 1 10 Dorcas Street South Melbourne > > +61 3 9626 0735 > > +61 419 885 762 > > ben.gatewood@didata.com.au > >=20 > > PROUVOST S=E9bastien FTRD/DAC/ISS > > =20 > > Sent by: sip-admin@ietf.org=20 > > 04/05/2004 07:49 PM =20 > > To: =20 > > cc: =20 > > Subject: [Sip] Bug in RFC3261 ? > >=20 > >=20 > >=20 > >=20 > > Hi, > > In RFC 3261, it is written (section 8.1.3.3 for UAC Core=20 > > procedures) : "If > > more than one Via header field value is present in a=20 > response, the UAC > > SHOULD discard the message." > > However if the UAC Core layer discards the response and if=20 > > this response was > > the only one sent (for example a 200 OK to an UPDATE), then=20 > > this leads to a > > situation when the transaction is terminated (the transaction=20 > > layer received > > the response and passed it to the UA Core) but the UA Core is=20 > > still waiting > > for a response (it discarded the 200 OK because of the=20 > > presence of two Via > > header field values and so is still waiting for the response).=20 > > I believe there shall be procedures that tells the UAC Core=20 > > when to stop > > waiting for the response. Or am I misunderstanding something ?=20 > > Thanks for your clarifications,=20 > > S=E9bastien Prouvost=20 > > France Telecom R&D=20 > >=20 > >=20 > > ************************************************************** > > ************** > > ** > > - NOTICE FROM DIMENSION DATA AUSTRALIA > > This message is confidential, and may contain proprietary or legally = > > privileged information. If you have received this email in error,=20 > > please notify the sender and delete it immediately. > >=20 > > Internet communications are not secure. You should scan this > > message and any > > attachments for viruses. Under no circumstances do we accept=20 > > liability for > > any loss or damage which may result from your receipt of this=20 > > message or any > > attachments. > > ************************************************************** > > ************** > > **=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=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > 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=20 > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 May 6 07:42:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07379 for ; Thu, 6 May 2004 07:42:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLhAy-0005vz-MW for sip-archive@odin.ietf.org; Thu, 06 May 2004 07:36:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46BaSbP022812 for sip-archive@odin.ietf.org; Thu, 6 May 2004 07:36:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLh2p-0003Vr-19; Thu, 06 May 2004 07:28:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLgxi-00015z-J2 for sip@optimus.ietf.org; Thu, 06 May 2004 07: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 HAA06511 for ; Thu, 6 May 2004 07:22:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLgxh-0002FA-WB for sip@ietf.org; Thu, 06 May 2004 07:22:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLgwi-0001rg-00 for sip@ietf.org; Thu, 06 May 2004 07:21:46 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1BLgw8-0001Tn-00; Thu, 06 May 2004 07:21:08 -0400 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id i46BL8xn014616; Thu, 6 May 2004 04:21:08 -0700 (MST) Received: from zin09exm01.corp.mot.com (zin09exm01.corp.mot.com [10.232.100.1]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i46BKvUL028517; Thu, 6 May 2004 06:21:03 -0500 Received: by zin09exm01.corp.mot.com with Internet Mail Service (5.5.2657.72) id ; Thu, 6 May 2004 16:50:57 +0530 Message-ID: From: Chadha Retesh-A19894 To: ranjit.avasarala@wipro.com, kowsalya@npd.hcltech.com, prasanna@huawei.com, hisham.khartabil@nokia.com, Ben.Gatewood@didata.com.au, sebastien.prouvost@francetelecom.com Cc: sip@ietf.org, sip-admin@ietf.org Subject: RE: [Sip] Bug in RFC3261 ? Date: Thu, 6 May 2004 16:50:56 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ftpbox.mot.com id i46BL8xn014616 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,EXCUSE_16 autolearn=no version=2.60 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 think it will retransmit INVITE only if it's a non-reliable transport. Regards Retesh -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of ranjit.= avasarala@wipro.com Sent: Thursday, May 06, 2004 4:27 PM To: Retesh Chadha; kowsalya@npd.hcltech.com; prasanna@huawei.com; hisham.= khartabil@nokia.com; Ben.Gatewood@didata.com.au; sebastien.prouvost@franc= etelecom.com Cc: sip@ietf.org; sip-admin@ietf.org Subject: RE: [Sip] Bug in RFC3261 ? Hi Regards Ranjit -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Chadha = Retesh-A19894 Sent: Thursday, May 06, 2004 4:04 PM To: kowsalya@npd.hcltech.com; prasanna@huawei.com; hisham.khartabil@nokia= .com; Ben.Gatewood@didata.com.au; sebastien.prouvost@francetelecom.com Cc: sip@ietf.org; sip-admin@ietf.org Subject: RE: [Sip] Bug in RFC3261 ? Similar is the following scenario --- 200 ok to an INVITE matching the transaction (same branch in top via head= er), but not matching the dialog parameters (from tag, call-tag, etc). In= this case, the INVITE transaction will be terminated with an erroneous = 200 ok. Now, if the correct 200 response comes, it will be considered as = a retransmission and ignored. [Ranjit] I think if the 200 OK received is not matching the dialog parame= ters, it is as good as not receiving the 200 OK. So UAC could retransmit = INVITE.=20 In the above and all such cases, I feel uac should take a call on being s= trict or not. If it needs to consider such responses as invalid, it shoul= d terminate the call, and take the same action as it would have taken for= a non-successful response. Regards Retesh -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of kowsaly= a@npd.hcltech.com Sent: Thursday, May 06, 2004 3:40 PM To: kowsalya@npd.hcltech.com; prasanna@huawei.com; hisham.khartabil@nokia= .com; Ben.Gatewood@didata.com.au; sebastien.prouvost@francetelecom.com Cc: sip@ietf.org; sip-admin@ietf.org Subject: RE: [Sip] Bug in RFC3261 ? I actually feel this is more a question of whether to accept non conforming peers. If the implementation should be strict it can simply terminate the associated dialog, otherwise accept the response and face it. I don't think RFC can provide any guidelines on these situations. > -----Original Message----- > From: kowsalya@npd.hcltech.com [mailto:kowsalya@npd.hcltech.com] > Sent: Thursday, May 06, 2004 3:06 PM > To: prasanna@huawei.com; hisham.khartabil@nokia.com;=20 > Ben.Gatewood@didata.com.au; sebastien.prouvost@francetelecom.com > Cc: sip@ietf.org; sip-admin@ietf.org > Subject: RE: [Sip] Bug in RFC3261 ? >=20 >=20 > Hi Prasanna, >=20 > The number of via headers cannot and should not > be validated by the transaction layer. Ideally, > the transaction layer should not know whether > the message is for the proxy TU or the UA TU. > In the former, more than one via header will > be present. >=20 > Thanks > Kowsalya >=20 > > -----Original Message----- > > From: Prasanna [mailto:prasanna@huawei.com] > > Sent: Thursday, May 06, 2004 1:49 PM > > To: hisham.khartabil@nokia.com; Ben.Gatewood@didata.com.au;=20 > > sebastien.prouvost@francetelecom.com > > Cc: sip@ietf.org; sip-admin@ietf.org > > Subject: RE: [Sip] Bug in RFC3261 ? > >=20 > >=20 > > There is a basic confusion... > > 8.1.3.3 mentions that the "UAC" should discard the message. But is=20 > > it the "transaction layer" that is discarding the message or the=20 > > "TU" (which is the UA core in this case) discarding the message. > > If the transaction discards it, Hisham's flow is okay, the=20 > > timers will fire. > > But what if the UA core discards. Assuming the UPDATE----200=20 > > exchange, > > In this case, the transaction would have assumed the 200=20 > > response to be fine > > and moved to the "completed" state. There is no Timer F in=20 > this case > > anyway. > > Worse will be case if the exchange is INVITE---180----200, And 200=20 > > has to be discarded. The moment transaction deemed the 200 to be > > okay, it will terminate. > >=20 > >=20 > > Even if what 8.1.3.3 mentions is for the transaction, how about the=20 > > validation of the Table 2 / Table 3 requirements. What if there is=20 > > 423 without Min-Expires or a 200 for INVITE without Contact? > >=20 > > Should the complete validation be done by the transaction layer? > >=20 > > Cheers, > > Prasanna > >=20 > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of=20 > > hisham.khartabil@nokia.com > > Sent: Wednesday, May 05, 2004 1:42 PM > > To: Ben.Gatewood@didata.com.au; sebastien.prouvost@francetelecom.com > > Cc: sip@ietf.org; sip-admin@ietf.org > > Subject: RE: [Sip] Bug in RFC3261 ? > >=20 > >=20 > > Well, you were pointing at the right sections. 17.1.1.2 and > > 17.1.2.2 specify > > that when Timer B (for INVITE) and Timer F (for non-INVITE)=20 > fire, "the > > client transaction SHOULD inform the TU about the > > timeout, and then it SHOULD enter the "Terminated" state" > >=20 > > Hisham > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext=20 > > Ben.Gatewood@didata.com.au > > Sent: 05.May.2004 03:02 > > To: PROUVOST S=E9bastien FTRD/DAC/ISS > > Cc: sip@ietf.org; sip-admin@ietf.org > > Subject: Re: [Sip] Bug in RFC3261 ? > >=20 > >=20 > >=20 > > Hi S=E9bastien, > >=20 > > I just re-read your question and realised it's more > complicated than I > > thought :-) > >=20 > > Hmmm......I'm not sure what it should do either. > >=20 > > I'm sure someone smarter than me will be along shortly though :-) > >=20 > > B > >=20 > > Ben Gatewood > > Dimension Data > > SIP Wookie > > Level 1 10 Dorcas Street South Melbourne > > +61 3 9626 0735 > > +61 419 885 762 > > ben.gatewood@didata.com.au > >=20 > >=20 > > Ben.Gatewood@didata.com.au > > Sent by: sip-admin@ietf.org=20 > > 05/05/2004 08:33 AM=20 > > =20 > > To: PROUVOST S=E9bastien FTRD/DAC/ISS > > =20 > > cc: sip@ietf.org, sip-admin@ietf.org=20 > > Subject: Re: [Sip] Bug in RFC3261 ? > >=20 > >=20 > >=20 > >=20 > > Hi S=E9bastien, > >=20 > > There are procedures and timers for this situation in 3261. > > Have a look at > > Section 17.1.1.2 and 17.1.2.2.=20 > >=20 > > Basically the UA should wait 64*T1 (Timer 1). T1, by default, > > should be > > 500ms so your UA should wait 32 seconds for a valid response.=20 > >=20 > > HTH, > >=20 > > B > >=20 > > Ben Gatewood > > Dimension Data > > SIP Wookie > > Level 1 10 Dorcas Street South Melbourne > > +61 3 9626 0735 > > +61 419 885 762 > > ben.gatewood@didata.com.au > >=20 > > PROUVOST S=E9bastien FTRD/DAC/ISS > > =20 > > Sent by: sip-admin@ietf.org=20 > > 04/05/2004 07:49 PM =20 > > To: =20 > > cc: =20 > > Subject: [Sip] Bug in RFC3261 ? > >=20 > >=20 > >=20 > >=20 > > Hi, > > In RFC 3261, it is written (section 8.1.3.3 for UAC Core=20 > > procedures) : "If > > more than one Via header field value is present in a=20 > response, the UAC > > SHOULD discard the message." > > However if the UAC Core layer discards the response and if=20 > > this response was > > the only one sent (for example a 200 OK to an UPDATE), then=20 > > this leads to a > > situation when the transaction is terminated (the transaction=20 > > layer received > > the response and passed it to the UA Core) but the UA Core is=20 > > still waiting > > for a response (it discarded the 200 OK because of the=20 > > presence of two Via > > header field values and so is still waiting for the response).=20 > > I believe there shall be procedures that tells the UAC Core=20 > > when to stop > > waiting for the response. Or am I misunderstanding something ?=20 > > Thanks for your clarifications,=20 > > S=E9bastien Prouvost=20 > > France Telecom R&D=20 > >=20 > >=20 > > ************************************************************** > > ************** > > ** > > - NOTICE FROM DIMENSION DATA AUSTRALIA > > This message is confidential, and may contain proprietary or legally=20 > > privileged information. If you have received this email in error,=20 > > please notify the sender and delete it immediately. > >=20 > > Internet communications are not secure. You should scan this > > message and any > > attachments for viruses. Under no circumstances do we accept=20 > > liability for > > any loss or damage which may result from your receipt of this=20 > > message or any > > attachments. > > ************************************************************** > > ************** > > **=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=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > 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=20 > 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 sip= ping@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 sip= ping@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 Thu May 6 10:28:26 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16584 for ; Thu, 6 May 2004 10:28:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLjiw-0003ph-NB for sip-archive@odin.ietf.org; Thu, 06 May 2004 10:19:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46EJg40014734 for sip-archive@odin.ietf.org; Thu, 6 May 2004 10:19:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLjZb-0006MB-8K; Thu, 06 May 2004 10:10:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLjSZ-0001af-1S for sip@optimus.ietf.org; Thu, 06 May 2004 10:02:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14062 for ; Thu, 6 May 2004 10:02:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLjSW-0004ZO-S9 for sip@ietf.org; Thu, 06 May 2004 10:02:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLjRX-00048Z-00 for sip@ietf.org; Thu, 06 May 2004 10:01:44 -0400 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1BLjQW-0003Hi-00 for sip@ietf.org; Thu, 06 May 2004 10:00:40 -0400 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i46E02j19899 for ; Thu, 6 May 2004 09:00:02 -0500 (CDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 6 May 2004 09:00:00 -0500 Message-ID: From: "Chaidez, Fidencio (Fidencio)" To: sip@ietf.org Date: Thu, 6 May 2004 08:59:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Sip] Comment on draft-ietf-sip-sctp-04 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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 recall several months ago a question was raised in relation to following statement in the "SCTP for SIP" draft (draft-ietf-sip-sctp-xx): "[A] SIP entity SHOULD send every SIP message (request or response) over stream zero with the unordered flag set" The question back then was whether there were any uses of SIP which may require ordered delivery, and referred as an example to the use of SIP in ISUP interworking cases (now described in RFCs 3398 and 3372). The draft-ietf-sip-sctp does already identify one type of application (in which an extra layer for compression and/or encryption is supported, such as with TLS) for which ordered delivery may be required. >From my perspective, the ISUP interworking case, particularly the "SIP bridging" application described in RFC 3372, would also benefit significantly from the use of SCTP's ordered delivery. There may yet be other applications that would benefit similarly from ordered delivery. The question is whether draft-ietf-sip-sctp should soften the statement above pertaining to the use of "stream zero with the unordered flag set". One possible change (which I would be in favor of) would be to explicitly allow the use of either ordered or unordered delivery service for the sending of SIP messages. The reference to TLS-style applications already in the draft could be left there as examples of applications that may require ordered delivery. Fidencio Chaidez _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 6 13:29:49 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04979 for ; Thu, 6 May 2004 13:29:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLmSk-0006cp-DH for sip-archive@odin.ietf.org; Thu, 06 May 2004 13:15:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46HFARc025443 for sip-archive@odin.ietf.org; Thu, 6 May 2004 13:15:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLlrB-0007sX-Iw; Thu, 06 May 2004 12:36:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLl6W-0006Gs-Rs for sip@optimus.ietf.org; Thu, 06 May 2004 11:48: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 LAA21764 for ; Thu, 6 May 2004 11:48:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLl6V-0003Rg-Gw for sip@ietf.org; Thu, 06 May 2004 11:48:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLl5U-0002xx-00 for sip@ietf.org; Thu, 06 May 2004 11:47:05 -0400 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BLl4X-00023r-00; Thu, 06 May 2004 11:46:09 -0400 Received: from huawei08hiby56 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HXA00DRIUDV9R@mta0.huawei.com>; Thu, 06 May 2004 23:44:22 +0800 (CST) Date: Thu, 06 May 2004 21:20:21 +0530 From: Prasanna Subject: RE: [Sip] Bug in RFC3261 ? In-reply-to: To: "'Chadha Retesh-A19894'" , ranjit.avasarala@wipro.com, kowsalya@npd.hcltech.com, hisham.khartabil@nokia.com, Ben.Gatewood@didata.com.au, sebastien.prouvost@francetelecom.com Cc: sip@ietf.org, sip-admin@ietf.org Message-id: <002a01c43381$d7c2c480$e905120a@huawei08hiby56> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,EXCUSE_16 autolearn=no version=2.60 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, In this case there is no question of retransmission as the moment a 200 for INVITE is received, the transaction terminates. And as = suggested in the original response, the transaction has accepted these messages, so = there will be no question of retransmission whatso ever. Regards, Prasanna -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Chadha Retesh-A19894 Sent: Thursday, May 06, 2004 4:51 PM To: ranjit.avasarala@wipro.com; kowsalya@npd.hcltech.com; prasanna@huawei.com; hisham.khartabil@nokia.com; = Ben.Gatewood@didata.com.au; sebastien.prouvost@francetelecom.com Cc: sip@ietf.org; sip-admin@ietf.org Subject: RE: [Sip] Bug in RFC3261 ? I think it will retransmit INVITE only if it's a non-reliable transport. Regards Retesh -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of ranjit.avasarala@wipro.com Sent: Thursday, May 06, 2004 4:27 PM To: Retesh Chadha; kowsalya@npd.hcltech.com; prasanna@huawei.com; hisham.khartabil@nokia.com; Ben.Gatewood@didata.com.au; sebastien.prouvost@francetelecom.com Cc: sip@ietf.org; sip-admin@ietf.org Subject: RE: [Sip] Bug in RFC3261 ? Hi Regards Ranjit -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Chadha Retesh-A19894 Sent: Thursday, May 06, 2004 4:04 PM To: kowsalya@npd.hcltech.com; prasanna@huawei.com; hisham.khartabil@nokia.com; Ben.Gatewood@didata.com.au; sebastien.prouvost@francetelecom.com Cc: sip@ietf.org; sip-admin@ietf.org Subject: RE: [Sip] Bug in RFC3261 ? Similar is the following scenario --- 200 ok to an INVITE matching the transaction (same branch in top via header), but not matching the dialog parameters (from tag, call-tag, = etc). In this case, the INVITE transaction will be terminated with an = erroneous 200 ok. Now, if the correct 200 response comes, it will be considered as = a retransmission and ignored. [Ranjit] I think if the 200 OK received is not matching the dialog parameters, it is as good as not receiving the 200 OK. So UAC could retransmit INVITE.=20 In the above and all such cases, I feel uac should take a call on being strict or not. If it needs to consider such responses as invalid, it = should terminate the call, and take the same action as it would have taken for = a non-successful response. Regards Retesh -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of kowsalya@npd.hcltech.com Sent: Thursday, May 06, 2004 3:40 PM To: kowsalya@npd.hcltech.com; prasanna@huawei.com; hisham.khartabil@nokia.com; Ben.Gatewood@didata.com.au; sebastien.prouvost@francetelecom.com Cc: sip@ietf.org; sip-admin@ietf.org Subject: RE: [Sip] Bug in RFC3261 ? I actually feel this is more a question of whether to accept non conforming peers. If the implementation should be strict it can simply terminate the associated dialog, otherwise accept the response and face it. I don't think RFC can provide any guidelines on these situations. > -----Original Message----- > From: kowsalya@npd.hcltech.com [mailto:kowsalya@npd.hcltech.com] > Sent: Thursday, May 06, 2004 3:06 PM > To: prasanna@huawei.com; hisham.khartabil@nokia.com; > Ben.Gatewood@didata.com.au; sebastien.prouvost@francetelecom.com > Cc: sip@ietf.org; sip-admin@ietf.org > Subject: RE: [Sip] Bug in RFC3261 ? >=20 >=20 > Hi Prasanna, >=20 > The number of via headers cannot and should not > be validated by the transaction layer. Ideally, > the transaction layer should not know whether > the message is for the proxy TU or the UA TU. > In the former, more than one via header will > be present. >=20 > Thanks > Kowsalya >=20 > > -----Original Message----- > > From: Prasanna [mailto:prasanna@huawei.com] > > Sent: Thursday, May 06, 2004 1:49 PM > > To: hisham.khartabil@nokia.com; Ben.Gatewood@didata.com.au; > > sebastien.prouvost@francetelecom.com > > Cc: sip@ietf.org; sip-admin@ietf.org > > Subject: RE: [Sip] Bug in RFC3261 ? > >=20 > >=20 > > There is a basic confusion... > > 8.1.3.3 mentions that the "UAC" should discard the message. But is > > it the "transaction layer" that is discarding the message or the=20 > > "TU" (which is the UA core in this case) discarding the message. > > If the transaction discards it, Hisham's flow is okay, the=20 > > timers will fire. > > But what if the UA core discards. Assuming the UPDATE----200=20 > > exchange, > > In this case, the transaction would have assumed the 200=20 > > response to be fine > > and moved to the "completed" state. There is no Timer F in=20 > this case > > anyway. > > Worse will be case if the exchange is INVITE---180----200, And 200 > > has to be discarded. The moment transaction deemed the 200 to be > > okay, it will terminate. > >=20 > >=20 > > Even if what 8.1.3.3 mentions is for the transaction, how about the > > validation of the Table 2 / Table 3 requirements. What if there is=20 > > 423 without Min-Expires or a 200 for INVITE without Contact? > >=20 > > Should the complete validation be done by the transaction layer? > >=20 > > Cheers, > > Prasanna > >=20 > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of > > hisham.khartabil@nokia.com > > Sent: Wednesday, May 05, 2004 1:42 PM > > To: Ben.Gatewood@didata.com.au; sebastien.prouvost@francetelecom.com > > Cc: sip@ietf.org; sip-admin@ietf.org > > Subject: RE: [Sip] Bug in RFC3261 ? > >=20 > >=20 > > Well, you were pointing at the right sections. 17.1.1.2 and 17.1.2.2 = > > specify that when Timer B (for INVITE) and Timer F (for non-INVITE) > fire, "the > > client transaction SHOULD inform the TU about the > > timeout, and then it SHOULD enter the "Terminated" state" > >=20 > > Hisham > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext > > Ben.Gatewood@didata.com.au > > Sent: 05.May.2004 03:02 > > To: PROUVOST S=E9bastien FTRD/DAC/ISS > > Cc: sip@ietf.org; sip-admin@ietf.org > > Subject: Re: [Sip] Bug in RFC3261 ? > >=20 > >=20 > >=20 > > Hi S=E9bastien, > >=20 > > I just re-read your question and realised it's more > complicated than I > > thought :-) > >=20 > > Hmmm......I'm not sure what it should do either. > >=20 > > I'm sure someone smarter than me will be along shortly though :-) > >=20 > > B > >=20 > > Ben Gatewood > > Dimension Data > > SIP Wookie > > Level 1 10 Dorcas Street South Melbourne > > +61 3 9626 0735 > > +61 419 885 762 > > ben.gatewood@didata.com.au > >=20 > >=20 > > Ben.Gatewood@didata.com.au > > Sent by: sip-admin@ietf.org > > 05/05/2004 08:33 AM=20 > > =20 > > To: PROUVOST S=E9bastien FTRD/DAC/ISS > > =20 > > cc: sip@ietf.org, sip-admin@ietf.org=20 > > Subject: Re: [Sip] Bug in RFC3261 ? > >=20 > >=20 > >=20 > >=20 > > Hi S=E9bastien, > >=20 > > There are procedures and timers for this situation in 3261. Have a=20 > > look at Section 17.1.1.2 and 17.1.2.2. > >=20 > > Basically the UA should wait 64*T1 (Timer 1). T1, by default, should = > > be 500ms so your UA should wait 32 seconds for a valid response. > >=20 > > HTH, > >=20 > > B > >=20 > > Ben Gatewood > > Dimension Data > > SIP Wookie > > Level 1 10 Dorcas Street South Melbourne > > +61 3 9626 0735 > > +61 419 885 762 > > ben.gatewood@didata.com.au > >=20 > > PROUVOST S=E9bastien FTRD/DAC/ISS=20 > > > > Sent by: sip-admin@ietf.org=20 > > 04/05/2004 07:49 PM =20 > > To: =20 > > cc: =20 > > Subject: [Sip] Bug in RFC3261 ? > >=20 > >=20 > >=20 > >=20 > > Hi, > > In RFC 3261, it is written (section 8.1.3.3 for UAC Core > > procedures) : "If > > more than one Via header field value is present in a=20 > response, the UAC > > SHOULD discard the message." > > However if the UAC Core layer discards the response and if > > this response was > > the only one sent (for example a 200 OK to an UPDATE), then=20 > > this leads to a > > situation when the transaction is terminated (the transaction=20 > > layer received > > the response and passed it to the UA Core) but the UA Core is=20 > > still waiting > > for a response (it discarded the 200 OK because of the=20 > > presence of two Via > > header field values and so is still waiting for the response).=20 > > I believe there shall be procedures that tells the UAC Core=20 > > when to stop > > waiting for the response. Or am I misunderstanding something ?=20 > > Thanks for your clarifications,=20 > > S=E9bastien Prouvost=20 > > France Telecom R&D=20 > >=20 > >=20 > > ************************************************************** > > ************** > > ** > > - NOTICE FROM DIMENSION DATA AUSTRALIA > > This message is confidential, and may contain proprietary or legally > > privileged information. If you have received this email in error,=20 > > please notify the sender and delete it immediately. > >=20 > > Internet communications are not secure. You should scan this message = > > and any attachments for viruses. Under no circumstances do we accept > > liability for > > any loss or damage which may result from your receipt of this=20 > > message or any > > attachments. > > ************************************************************** > > ************** > > **=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=20 > > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu May 6 13:30:48 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05210 for ; Thu, 6 May 2004 13:30: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 1BLmVi-0000fR-9s for sip-archive@odin.ietf.org; Thu, 06 May 2004 13:18:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46HIEN8002557 for sip-archive@odin.ietf.org; Thu, 6 May 2004 13:18:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLls2-0008Th-QG; Thu, 06 May 2004 12:37:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLlDD-00022z-Fq for sip@optimus.ietf.org; Thu, 06 May 2004 11:55:03 -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 LAA22382 for ; Thu, 6 May 2004 11:55:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLlDB-0006nj-TA for sip@ietf.org; Thu, 06 May 2004 11:55:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLlC0-0006H0-00 for sip@ietf.org; Thu, 06 May 2004 11:53:49 -0400 Received: from mta1.huawei.com ([61.144.161.40] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BLlAm-0005NU-00; Thu, 06 May 2004 11:52:32 -0400 Received: from huawei08hiby56 (huawei.com [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HXA00HFATZV80@mta1.huawei.com>; Thu, 06 May 2004 23:35:57 +0800 (CST) Date: Thu, 06 May 2004 21:21:08 +0530 From: Prasanna Subject: RE: [Sip] Bug in RFC3261 ? In-reply-to: <50D40047DC73D611BDA60050BAC4EDD9010C9D91@PILEX> To: kowsalya@npd.hcltech.com, hisham.khartabil@nokia.com, Ben.Gatewood@didata.com.au, sebastien.prouvost@francetelecom.com Cc: sip@ietf.org, sip-admin@ietf.org Message-id: <002b01c43381$f36ef730$e905120a@huawei08hiby56> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,EXCUSE_16 autolearn=no version=2.60 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 Yeah Kowsalya you are right... Sorry folks for such a silly response... Cheers, Prasanna -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of kowsalya@npd.hcltech.com Sent: Thursday, May 06, 2004 3:06 PM To: prasanna@huawei.com; hisham.khartabil@nokia.com; Ben.Gatewood@didata.com.au; sebastien.prouvost@francetelecom.com Cc: sip@ietf.org; sip-admin@ietf.org Subject: RE: [Sip] Bug in RFC3261 ? Hi Prasanna, The number of via headers cannot and should not be validated by the transaction layer. Ideally, the transaction layer should not know whether the message is for the proxy TU or the UA TU. In the former, more than one via header will be present. Thanks Kowsalya > -----Original Message----- > From: Prasanna [mailto:prasanna@huawei.com] > Sent: Thursday, May 06, 2004 1:49 PM > To: hisham.khartabil@nokia.com; Ben.Gatewood@didata.com.au;=20 > sebastien.prouvost@francetelecom.com > Cc: sip@ietf.org; sip-admin@ietf.org > Subject: RE: [Sip] Bug in RFC3261 ? >=20 >=20 > There is a basic confusion... > 8.1.3.3 mentions that the "UAC" should discard the message. But is it=20 > the "transaction layer" that is discarding the message or the "TU" > (which is the UA core in this case) discarding the message. > If the transaction discards it, Hisham's flow is okay, the=20 > timers will fire. > But what if the UA core discards. Assuming the UPDATE----200=20 > exchange, > In this case, the transaction would have assumed the 200=20 > response to be fine > and moved to the "completed" state. There is no Timer F in this case > anyway. > Worse will be case if the exchange is INVITE---180----200, > And 200 has to be discarded. The moment transaction deemed=20 > the 200 to be > okay, it will terminate. >=20 >=20 > Even if what 8.1.3.3 mentions is for the transaction, how about the=20 > validation of the Table 2 / Table 3 requirements. What if there is 423 = > without Min-Expires or a 200 for INVITE without Contact? >=20 > Should the complete validation be done by the transaction layer? >=20 > Cheers, > Prasanna >=20 > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of=20 > hisham.khartabil@nokia.com > Sent: Wednesday, May 05, 2004 1:42 PM > To: Ben.Gatewood@didata.com.au; sebastien.prouvost@francetelecom.com > Cc: sip@ietf.org; sip-admin@ietf.org > Subject: RE: [Sip] Bug in RFC3261 ? >=20 >=20 > Well, you were pointing at the right sections. 17.1.1.2 and > 17.1.2.2 specify > that when Timer B (for INVITE) and Timer F (for non-INVITE) fire, "the > client transaction SHOULD inform the TU about the > timeout, and then it SHOULD enter the "Terminated" state" >=20 > Hisham > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext=20 > Ben.Gatewood@didata.com.au > Sent: 05.May.2004 03:02 > To: PROUVOST S=E9bastien FTRD/DAC/ISS > Cc: sip@ietf.org; sip-admin@ietf.org > Subject: Re: [Sip] Bug in RFC3261 ? >=20 >=20 >=20 > Hi S=E9bastien, >=20 > I just re-read your question and realised it's more complicated than I = > thought :-) >=20 > Hmmm......I'm not sure what it should do either. >=20 > I'm sure someone smarter than me will be along shortly though :-) >=20 > B >=20 > Ben Gatewood > Dimension Data > SIP Wookie > Level 1 10 Dorcas Street South Melbourne > +61 3 9626 0735 > +61 419 885 762 > ben.gatewood@didata.com.au >=20 >=20 > Ben.Gatewood@didata.com.au > Sent by: sip-admin@ietf.org=20 > 05/05/2004 08:33 AM=20 > =20 > To: PROUVOST S=E9bastien FTRD/DAC/ISS > =20 > cc: sip@ietf.org, sip-admin@ietf.org=20 > Subject: Re: [Sip] Bug in RFC3261 ? >=20 >=20 >=20 >=20 > Hi S=E9bastien, >=20 > There are procedures and timers for this situation in 3261. > Have a look at > Section 17.1.1.2 and 17.1.2.2.=20 >=20 > Basically the UA should wait 64*T1 (Timer 1). T1, by default, > should be > 500ms so your UA should wait 32 seconds for a valid response.=20 >=20 > HTH, >=20 > B >=20 > Ben Gatewood > Dimension Data > SIP Wookie > Level 1 10 Dorcas Street South Melbourne > +61 3 9626 0735 > +61 419 885 762 > ben.gatewood@didata.com.au >=20 > PROUVOST S=E9bastien FTRD/DAC/ISS > =20 > Sent by: sip-admin@ietf.org=20 > 04/05/2004 07:49 PM =20 > To: =20 > cc: =20 > Subject: [Sip] Bug in RFC3261 ? >=20 >=20 >=20 >=20 > Hi, > In RFC 3261, it is written (section 8.1.3.3 for UAC Core=20 > procedures) : "If > more than one Via header field value is present in a response, the UAC > SHOULD discard the message."=20 > However if the UAC Core layer discards the response and if=20 > this response was > the only one sent (for example a 200 OK to an UPDATE), then=20 > this leads to a > situation when the transaction is terminated (the transaction=20 > layer received > the response and passed it to the UA Core) but the UA Core is=20 > still waiting > for a response (it discarded the 200 OK because of the=20 > presence of two Via > header field values and so is still waiting for the response).=20 > I believe there shall be procedures that tells the UAC Core=20 > when to stop > waiting for the response. Or am I misunderstanding something ?=20 > Thanks for your clarifications,=20 > S=E9bastien Prouvost=20 > France Telecom R&D=20 >=20 >=20 > ************************************************************** > ************** > ** > - NOTICE FROM DIMENSION DATA AUSTRALIA > This message is confidential, and may contain proprietary or legally=20 > privileged information. If you have received this email in error,=20 > please notify the sender and delete it immediately. >=20 > Internet communications are not secure. You should scan this > message and any > attachments for viruses. Under no circumstances do we accept=20 > liability for > any loss or damage which may result from your receipt of this=20 > message or any > attachments. > ************************************************************** > ************** > **=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=20 > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 7 04:21:02 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07380 for ; Fri, 7 May 2004 04:21: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 1BM0Tn-0004D3-2g for sip-archive@odin.ietf.org; Fri, 07 May 2004 04:13:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i478DAJX016182 for sip-archive@odin.ietf.org; Fri, 7 May 2004 04:13:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM0J2-0007i4-B1; Fri, 07 May 2004 04: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 1BLI7g-0002A2-L9 for sip@optimus.ietf.org; Wed, 05 May 2004 04:51: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 EAA00866 for ; Wed, 5 May 2004 04:51:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLI7d-0003qP-FU for sip@ietf.org; Wed, 05 May 2004 04:51:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLI6e-0003et-00 for sip@ietf.org; Wed, 05 May 2004 04:50:22 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx with esmtp (Exim 4.12) id 1BLI5g-0003Rr-00; Wed, 05 May 2004 04:49:20 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 5 May 2004 10:49:20 +0200 Content-class: urn:content-classes:message Subject: RE : [Sip] Bug in RFC3261 ? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4327D.DAEA70BD" Date: Wed, 5 May 2004 10:49:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: Thread-Topic: [Sip] Bug in RFC3261 ? Thread-Index: AcQyNezx/egRPTdQRUmZJzLUfwOJqgAQmWlgAADQn4A= From: =?iso-8859-1?Q?PROUVOST_S=E9bastien_FTRD/DAC/ISS?= To: , Cc: , X-OriginalArrivalTime: 05 May 2004 08:49:20.0399 (UTC) FILETIME=[DB4109F0:01C4327D] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,EXCUSE_16,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,HTML_TAG_EXISTS_TBODY autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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_01C4327D.DAEA70BD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This does not really correspond to what I am saying. What I am saying is = the following:=20 =20 - I send a request (UPDATE for example) - I receive a 200 OK for this request. At this point the transaction = enters the state "Completed" and then "Terminated". Then the transaction = is destroyed and no more transaction layer timer is running for this = transaction. - The 200 OK is passed to the UAC Core layer. But this 200 OK contains = two Via headers. Section 8.1.3.3 (that handles UAC Core procedures) says = : "If more than one Via header field value is present in a response, the = UAC SHOULD discard the message."" So the UAC Core discards the message. = But the UAC Core is still waiting for a response (although the = corresponding transaction is terminated from the transaction layer point = of view).=20 =20 When does the UAC Core stop waiting for a response ? =20 S=E9bastien. =20 -----Message d'origine----- De : hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]=20 Envoy=E9 : mercredi 5 mai 2004 10:12 =C0 : Ben.Gatewood@didata.com.au; PROUVOST S=E9bastien FTRD/DAC/ISS Cc : sip@ietf.org; sip-admin@ietf.org Objet : RE: [Sip] Bug in RFC3261 ? Well, you were pointing at the right sections. 17.1.1.2 and 17.1.2.2 = specify that when Timer B (for INVITE) and Timer F (for non-INVITE) = fire, "the client transaction SHOULD inform the TU about the timeout, and then it SHOULD enter the "Terminated" state" =20 Hisham -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext = Ben.Gatewood@didata.com.au Sent: 05.May.2004 03:02 To: PROUVOST S=E9bastien FTRD/DAC/ISS Cc: sip@ietf.org; sip-admin@ietf.org Subject: Re: [Sip] Bug in RFC3261 ? Hi S=E9bastien,=20 I just re-read your question and realised it's more complicated than I = thought :-)=20 Hmmm......I'm not sure what it should do either.=20 I'm sure someone smarter than me will be along shortly though :-)=20 B Ben Gatewood Dimension Data SIP Wookie Level 1 10 Dorcas Street South Melbourne +61 3 9626 0735 +61 419 885 762 ben.gatewood@didata.com.au=20 Ben.Gatewood@didata.com.au=20 Sent by: sip-admin@ietf.org=20 05/05/2004 08:33 AM=20 =20 To: PROUVOST S=E9bastien FTRD/DAC/ISS = =20 cc: sip@ietf.org, sip-admin@ietf.org=20 Subject: Re: [Sip] Bug in RFC3261 ?=09 Hi S=E9bastien,=20 There are procedures and timers for this situation in 3261. Have a look = at Section 17.1.1.2 and 17.1.2.2.=20 Basically the UA should wait 64*T1 (Timer 1). T1, by default, should be = 500ms so your UA should wait 32 seconds for a valid response.=20 HTH,=20 B Ben Gatewood Dimension Data SIP Wookie Level 1 10 Dorcas Street South Melbourne +61 3 9626 0735 +61 419 885 762 ben.gatewood@didata.com.au=20 PROUVOST S=E9bastien FTRD/DAC/ISS = =20 Sent by: sip-admin@ietf.org=20 04/05/2004 07:49 PM=20 =20 To: =20 cc: =20 Subject: [Sip] Bug in RFC3261 ?=09 Hi,=20 In RFC 3261, it is written (section 8.1.3.3 for UAC Core procedures) : = "If more than one Via header field value is present in a response, the = UAC SHOULD discard the message."=20 However if the UAC Core layer discards the response and if this response = was the only one sent (for example a 200 OK to an UPDATE), then this = leads to a situation when the transaction is terminated (the transaction = layer received the response and passed it to the UA Core) but the UA = Core is still waiting for a response (it discarded the 200 OK because of = the presence of two Via header field values and so is still waiting for = the response).=20 I believe there shall be procedures that tells the UAC Core when to stop = waiting for the response. Or am I misunderstanding something ?=20 Thanks for your clarifications,=20 S=E9bastien Prouvost=20 France Telecom R&D=20 *************************************************************************= ***** - NOTICE FROM DIMENSION DATA AUSTRALIA This message is confidential, and may contain proprietary or legally = privileged information. If you have received this email in error, please = notify the sender and delete it immediately. Internet communications are not secure. You should scan this message and = any attachments for viruses. Under no circumstances do we accept = liability for any loss or damage which may result from your receipt of = this message or any attachments. *************************************************************************= *****=20 ------_=_NextPart_001_01C4327D.DAEA70BD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
This=20 does not really correspond to what I am saying. What I am saying is the=20 following:
 
- I send a request (UPDATE for = example)
- I=20 receive a 200 OK for this request. At this point the transaction enters = the=20 state "Completed" and then "Terminated". Then the transaction is = destroyed and=20 no more transaction layer timer is running for this=20 transaction.
- The=20 200 OK is passed to the UAC Core layer. But this 200 OK contains two Via = headers. Section 8.1.3.3 (that handles UAC Core procedures) says : "If more than one Via header field = value is=20 present in a response, the UAC SHOULD discard the message."" So = the UAC=20 Core discards the message. But the UAC Core is still waiting for a = response=20 (although the corresponding transaction is terminated from the = transaction layer=20 point of view).
 
When=20 does the UAC Core stop waiting for a response ?
 
S=E9bastien.
 
-----Message d'origine-----
De :=20 hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]=20
Envoy=E9 : mercredi 5 mai 2004 = 10:12
=C0 :=20 Ben.Gatewood@didata.com.au; PROUVOST S=E9bastien=20 FTRD/DAC/ISS
Cc : sip@ietf.org;=20 sip-admin@ietf.org
Objet : RE: [Sip] Bug in RFC3261=20 ?

Well, you were pointing at the right sections. 17.1.1.2 and = 17.1.2.2=20 specify that when Timer B (for INVITE) and Timer F (for non-INVITE) = fire,=20 "the client transaction SHOULD inform = the TU about=20 the
   timeout, and then it SHOULD enter the "Terminated" = state"
 
Hisham
-----Original Message-----
From: = sip-admin@ietf.org=20 [mailto:sip-admin@ietf.org]On Behalf Of ext=20 Ben.Gatewood@didata.com.au
Sent: 05.May.2004 = 03:02
To:=20 PROUVOST S=E9bastien FTRD/DAC/ISS
Cc: sip@ietf.org;=20 sip-admin@ietf.org
Subject: Re: [Sip] Bug in RFC3261=20 ?


Hi = S=E9bastien,=20

I just re-read your = question and=20 realised it's more complicated than I thought :-) =

Hmmm......I'm not sure what it should do=20 either.

I'm sure = someone smarter=20 than me will be along shortly though :-)

B

Ben Gatewood
Dimension = Data
SIP=20 Wookie
Level 1 10 Dorcas Street South Melbourne
+61 3 9626 = 0735
+61=20 419 885 762
ben.gatewood@didata.com.au


Ben.Gatewood@didata.com.au
Sent by: sip-admin@ietf.org=20

05/05/2004 08:33 AM =

       =20
    =    =20 To:        PROUVOST S=E9bastien = FTRD/DAC/ISS=20 <sebastien.prouvost@francetelecom.com>
        cc: =    =20    sip@ietf.org, sip-admin@ietf.org
        = Subject:  =20      Re: [Sip] Bug in RFC3261=20 ?




Hi S=E9bastien,=20

There are procedures = and timers=20 for this situation in 3261. Have a look at Section 17.1.1.2 and = 17.1.2.2.=20

Basically the UA should wait 64*T1 (Timer 1). T1, by = default,=20 should be 500ms so your UA should wait 32 seconds for a valid=20 response. =

HTH,=20

B

Ben=20 Gatewood
Dimension Data
SIP Wookie
Level 1 10 Dorcas Street = South=20 Melbourne
+61 3 9626 0735
+61 419 885=20 762
ben.gatewood@didata.com.au=20

PROUVOST = S=E9bastien=20 FTRD/DAC/ISS=20 <sebastien.prouvost@francetelecom.com>
Sent by: sip-admin@ietf.org

04/05/2004 07:49 = PM

    =    =20
    =    To:=20        <sip@ietf.org>
       cc:     =  =20   =
      =  Subject:  =20      [Sip] Bug in RFC3261=20 ?




Hi, =
In RFC=20 3261, it is written (section 8.1.3.3 for UAC Core procedures) : "If = more=20 than one Via header field value is present in a response, the UAC = SHOULD=20 discard the message." =

However if the UAC Core layer = discards=20 the response and if this response was the only one sent (for example = a 200=20 OK to an UPDATE), then this leads to a situation when the = transaction is=20 terminated (the transaction layer received the response and passed = it to the=20 UA Core) but the UA Core is still waiting for a response (it = discarded the=20 200 OK because of the presence of two Via header field values and so = is=20 still waiting for the response).=20

I believe there shall be = procedures that=20 tells the UAC Core when to stop waiting for the response. Or am I=20 misunderstanding something ?=20

Thanks for your=20 clarifications, =

S=E9bastien Prouvost
France=20 Telecom R&D =



********************************************************= **********************
-=20 NOTICE FROM DIMENSION DATA AUSTRALIA
This message is = confidential, and=20 may contain proprietary or legally privileged information. If you = have=20 received this email in error, please notify the sender and delete it = immediately.

Internet communications are not secure. You = should scan=20 this message and any attachments for viruses. Under no circumstances = do we=20 accept liability for any loss or damage which may result from your = receipt=20 of this message or any=20 = attachments.
*********************************************************= *********************=20

------_=_NextPart_001_01C4327D.DAEA70BD-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 7 04:21:43 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07477 for ; Fri, 7 May 2004 04:21: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 1BM0Xx-0005yY-B8 for sip-archive@odin.ietf.org; Fri, 07 May 2004 04:17:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i478HTVS022966 for sip-archive@odin.ietf.org; Fri, 7 May 2004 04:17:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM0J9-0007ih-Bp; Fri, 07 May 2004 04:02:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLkB4-0006U8-Fy for sip@optimus.ietf.org; Thu, 06 May 2004 10:48: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 KAA17788 for ; Thu, 6 May 2004 10:48:42 -0400 (EDT) From: Ervin.Beres@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLkB2-0000th-2j for sip@ietf.org; Thu, 06 May 2004 10:48:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLkA3-0000Us-00 for sip@ietf.org; Thu, 06 May 2004 10:47:44 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BLk97-000054-00 for sip@ietf.org; Thu, 06 May 2004 10:46:45 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i46Ekik25683 for ; Thu, 6 May 2004 17:46:44 +0300 (EET DST) X-Scanned: Thu, 6 May 2004 17:46:42 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i46Ekg2s001005 for ; Thu, 6 May 2004 17:46:42 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00EWVueF; Thu, 06 May 2004 17:46:40 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i46EkUH20199 for ; Thu, 6 May 2004 17:46:30 +0300 (EET DST) Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 6 May 2004 17:46:29 +0300 Received: from buebe002.NOE.Nokia.com ([10.211.0.51]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 6 May 2004 17:46:29 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [Sip] Caller-Preferences: "no-fork" directive and addresses with equal q-value Date: Thu, 6 May 2004 16:46:28 +0200 Message-ID: Thread-Topic: [Sip] Caller-Preferences: "no-fork" directive and addresses with equal q-value Thread-Index: AcQzeOnDCkmCYuMPQMWIHi/pgA3FOQ== To: X-OriginalArrivalTime: 06 May 2004 14:46:29.0763 (UTC) FILETIME=[EA903D30:01C43378] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 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, I've tried to find from the Draft(/RFC) without success that how a server is supposed to work when it receives a request with "no-fork" but it has addresses with equal q value. I mean in what cases can it happen that the server does not accept the "no-fork" directive? Generally, what is the best way for gateway type of UAs to indicate that no forking should happen as e.g. parallel early media may confuse the user? Does it help if Proxy-Require is set to indicate that pref extension need to be supported? Thanks in advance. BR, -Ervin _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 7 05:10:56 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07388 for ; Fri, 7 May 2004 04:21: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 1BM0Ut-0004gC-O5 for sip-archive@odin.ietf.org; Fri, 07 May 2004 04:14:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i478EJ8c017988 for sip-archive@odin.ietf.org; Fri, 7 May 2004 04:14:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM0J6-0007iU-SX; Fri, 07 May 2004 04:02:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLJBO-0004I5-Lz for sip@optimus.ietf.org; Wed, 05 May 2004 05:59: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 FAA03385 for ; Wed, 5 May 2004 05:59:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLJBK-0001NE-Vz for sip@ietf.org; Wed, 05 May 2004 05:59:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLJ7C-0000lC-00 for sip@ietf.org; Wed, 05 May 2004 05:55:00 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BLJ5X-0000KC-03; Wed, 05 May 2004 05:53:15 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BLIus-0007JN-65; Wed, 05 May 2004 05:42:14 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 5 May 2004 11:42:11 +0200 Content-class: urn:content-classes:message Subject: RE : RE : [Sip] Bug in RFC3261 ? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43285.3D1D238E" X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Wed, 5 May 2004 11:42:10 +0200 Message-ID: Thread-Topic: RE : [Sip] Bug in RFC3261 ? Thread-Index: AcQyNezx/egRPTdQRUmZJzLUfwOJqgAQmWlgAADQn4AAAO/6wAABCX7w From: =?iso-8859-1?Q?PROUVOST_S=E9bastien_FTRD/DAC/ISS?= To: , Cc: , X-OriginalArrivalTime: 05 May 2004 09:42:11.0554 (UTC) FILETIME=[3D68E420:01C43285] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,EXCUSE_16,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,HTML_TAG_EXISTS_TBODY autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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_01C43285.3D1D238E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am not sure this is the right behavior ... What if it gets the same = answer ? It sends again the same request ? Shouldn't the behavior of the UAC Core receiving such an answer be = specified ?=20 S=E9bastien. -----Message d'origine----- De : hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]=20 Envoy=E9 : mercredi 5 mai 2004 11:03 =C0 : PROUVOST S=E9bastien FTRD/DAC/ISS; Ben.Gatewood@didata.com.au Cc : sip@ietf.org; sip-admin@ietf.org Objet : RE: RE : [Sip] Bug in RFC3261 ? OK, now I get your question. =20 UAC core does not wait. What it can do is issue the request again. =20 /Hisham -----Original Message----- From: ext PROUVOST S=E9bastien FTRD/DAC/ISS = [mailto:sebastien.prouvost@francetelecom.com] Sent: 05.May.2004 11:49 To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); Ben.Gatewood@didata.com.au Cc: sip@ietf.org; sip-admin@ietf.org Subject: RE : [Sip] Bug in RFC3261 ? This does not really correspond to what I am saying. What I am saying is = the following:=20 =20 - I send a request (UPDATE for example) - I receive a 200 OK for this request. At this point the transaction = enters the state "Completed" and then "Terminated". Then the transaction = is destroyed and no more transaction layer timer is running for this = transaction. - The 200 OK is passed to the UAC Core layer. But this 200 OK contains = two Via headers. Section 8.1.3.3 (that handles UAC Core procedures) says = : "If more than one Via header field value is present in a response, the = UAC SHOULD discard the message."" So the UAC Core discards the message. = But the UAC Core is still waiting for a response (although the = corresponding transaction is terminated from the transaction layer point = of view).=20 =20 When does the UAC Core stop waiting for a response ? =20 S=E9bastien. =20 -----Message d'origine----- De : hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]=20 Envoy=E9 : mercredi 5 mai 2004 10:12 =C0 : Ben.Gatewood@didata.com.au; PROUVOST S=E9bastien FTRD/DAC/ISS Cc : sip@ietf.org; sip-admin@ietf.org Objet : RE: [Sip] Bug in RFC3261 ? Well, you were pointing at the right sections. 17.1.1.2 and 17.1.2.2 = specify that when Timer B (for INVITE) and Timer F (for non-INVITE) = fire, "the client transaction SHOULD inform the TU about the timeout, and then it SHOULD enter the "Terminated" state" =20 Hisham -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext = Ben.Gatewood@didata.com.au Sent: 05.May.2004 03:02 To: PROUVOST S=E9bastien FTRD/DAC/ISS Cc: sip@ietf.org; sip-admin@ietf.org Subject: Re: [Sip] Bug in RFC3261 ? Hi S=E9bastien,=20 I just re-read your question and realised it's more complicated than I = thought :-)=20 Hmmm......I'm not sure what it should do either.=20 I'm sure someone smarter than me will be along shortly though :-)=20 B Ben Gatewood Dimension Data SIP Wookie Level 1 10 Dorcas Street South Melbourne +61 3 9626 0735 +61 419 885 762 ben.gatewood@didata.com.au=20 Ben.Gatewood@didata.com.au=20 Sent by: sip-admin@ietf.org=20 05/05/2004 08:33 AM=20 =20 To: PROUVOST S=E9bastien FTRD/DAC/ISS = =20 cc: sip@ietf.org, sip-admin@ietf.org=20 Subject: Re: [Sip] Bug in RFC3261 ?=09 Hi S=E9bastien,=20 There are procedures and timers for this situation in 3261. Have a look = at Section 17.1.1.2 and 17.1.2.2.=20 Basically the UA should wait 64*T1 (Timer 1). T1, by default, should be = 500ms so your UA should wait 32 seconds for a valid response.=20 HTH,=20 B Ben Gatewood Dimension Data SIP Wookie Level 1 10 Dorcas Street South Melbourne +61 3 9626 0735 +61 419 885 762 ben.gatewood@didata.com.au=20 PROUVOST S=E9bastien FTRD/DAC/ISS = =20 Sent by: sip-admin@ietf.org=20 04/05/2004 07:49 PM=20 =20 To: =20 cc: =20 Subject: [Sip] Bug in RFC3261 ?=09 Hi,=20 In RFC 3261, it is written (section 8.1.3.3 for UAC Core procedures) : = "If more than one Via header field value is present in a response, the = UAC SHOULD discard the message."=20 However if the UAC Core layer discards the response and if this response = was the only one sent (for example a 200 OK to an UPDATE), then this = leads to a situation when the transaction is terminated (the transaction = layer received the response and passed it to the UA Core) but the UA = Core is still waiting for a response (it discarded the 200 OK because of = the presence of two Via header field values and so is still waiting for = the response).=20 I believe there shall be procedures that tells the UAC Core when to stop = waiting for the response. Or am I misunderstanding something ?=20 Thanks for your clarifications,=20 S=E9bastien Prouvost=20 France Telecom R&D=20 *************************************************************************= ***** - NOTICE FROM DIMENSION DATA AUSTRALIA This message is confidential, and may contain proprietary or legally = privileged information. If you have received this email in error, please = notify the sender and delete it immediately. Internet communications are not secure. You should scan this message and = any attachments for viruses. Under no circumstances do we accept = liability for any loss or damage which may result from your receipt of = this message or any attachments. *************************************************************************= *****=20 ------_=_NextPart_001_01C43285.3D1D238E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
I am=20 not sure this is the right behavior ... What if it gets the same answer = ? It=20 sends again the same request ?
Shouldn't the behavior of the UAC Core receiving such an answer = be=20 specified ? 

S=E9bastien.
-----Message d'origine-----
De :=20 hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]=20
Envoy=E9 : mercredi 5 mai 2004 = 11:03
=C0 : PROUVOST=20 S=E9bastien FTRD/DAC/ISS; = Ben.Gatewood@didata.com.au
Cc :=20 sip@ietf.org; sip-admin@ietf.org
Objet : RE: RE : [Sip] = Bug in=20 RFC3261 ?

OK,=20 now I get your question.
 
UAC=20 core does not wait. What it can do is issue the request=20 again.
 
/Hisham
-----Original Message-----
From: ext PROUVOST = S=E9bastien=20 FTRD/DAC/ISS = [mailto:sebastien.prouvost@francetelecom.com]
Sent:=20 05.May.2004 11:49
To: Khartabil Hisham = (Nokia-TP-MSW/Helsinki);=20 Ben.Gatewood@didata.com.au
Cc: sip@ietf.org;=20 sip-admin@ietf.org
Subject: RE : [Sip] Bug in RFC3261=20 ?

This does not really correspond to what I am saying. What I = am saying=20 is the following:
 
- I send a request (UPDATE for = example)
-=20 I receive a 200 OK for this request. At this point the transaction = enters=20 the state "Completed" and then "Terminated". Then the transaction is = destroyed and no more transaction layer timer is running = for this=20 transaction.
-=20 The 200 OK is passed to the UAC Core layer. But this 200 OK contains = two Via=20 headers. Section 8.1.3.3 (that handles UAC Core procedures) says : = "If more than one Via header = field value is=20 present in a response, the UAC SHOULD discard the message."" = So the=20 UAC Core discards the message. But the UAC Core is still waiting for = a=20 response (although the corresponding transaction is terminated from = the=20 transaction layer point of view).
 
When does the UAC Core stop waiting for a response=20 ?
 
S=E9bastien.
 
-----Message = d'origine-----
De :=20 hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]=20
Envoy=E9 : mercredi 5 mai 2004 = 10:12
=C0 :=20 Ben.Gatewood@didata.com.au; PROUVOST S=E9bastien=20 FTRD/DAC/ISS
Cc : sip@ietf.org;=20 sip-admin@ietf.org
Objet : RE: [Sip] Bug in RFC3261 = ?

Well, you were pointing at the right sections. 17.1.1.2 = and=20 17.1.2.2 specify that when Timer B (for INVITE) and Timer F (for=20 non-INVITE) fire, "the client = transaction=20 SHOULD inform the TU about the
   timeout, and then = it SHOULD=20 enter the "Terminated" state"
 
Hisham
-----Original Message-----
From: = sip-admin@ietf.org=20 [mailto:sip-admin@ietf.org]On Behalf Of ext=20 Ben.Gatewood@didata.com.au
Sent: 05.May.2004=20 03:02
To: PROUVOST S=E9bastien = FTRD/DAC/ISS
Cc:=20 sip@ietf.org; sip-admin@ietf.org
Subject: Re: [Sip] = Bug in=20 RFC3261 ?


Hi=20 S=E9bastien,

I = just re-read=20 your question and realised it's more complicated than I thought=20 :-)

Hmmm......I'm not sure=20 what it should do either.

I'm sure someone smarter than me will be along shortly = though=20 :-)

B

Ben = Gatewood
Dimension Data
SIP Wookie
Level 1 10 Dorcas = Street=20 South Melbourne
+61 3 9626 0735
+61 419 885=20 762
ben.gatewood@didata.com.au


Ben.Gatewood@didata.com.au =
Sent by: = sip-admin@ietf.org=20

05/05/2004 08:33 = AM=20

       =20
    =  =20   To:        PROUVOST S=E9bastien = FTRD/DAC/ISS = <sebastien.prouvost@francetelecom.com>=20
      =   cc:=20        sip@ietf.org, = sip-admin@ietf.org=20
      =  =20 Subject:        Re: [Sip] Bug in = RFC3261=20 ?




Hi S=E9bastien,=20

There are = procedures and=20 timers for this situation in 3261. Have a look at Section = 17.1.1.2 and=20 17.1.2.2.

Basically the UA should wait = 64*T1 (Timer 1).=20 T1, by default, should be 500ms so your UA should wait 32 = seconds for a=20 valid response.=20

HTH,

B

Ben Gatewood
Dimension Data
SIP=20 Wookie
Level 1 10 Dorcas Street South Melbourne
+61 3 9626 = 0735
+61 419 885 = 762
ben.gatewood@didata.com.au

PROUVOST S=E9bastien=20 FTRD/DAC/ISS=20 = <sebastien.prouvost@francetelecom.com>
Sent by: sip-admin@ietf.org

04/05/2004 07:49 = PM

    =  =20  
  =  =20    To:      =20  <sip@ietf.org>
   =20    cc:        
       Subject:   =  =20    [Sip] Bug in RFC3261=20 ?




Hi,
In RFC=20 3261, it is written (section 8.1.3.3 for UAC Core procedures) : = "If more=20 than one Via header field value is present in a response, the = UAC SHOULD=20 discard the message."

However if the UAC Core = layer=20 discards the response and if this response was the only one sent = (for=20 example a 200 OK to an UPDATE), then this leads to a situation = when the=20 transaction is terminated (the transaction layer received the = response=20 and passed it to the UA Core) but the UA Core is still waiting = for a=20 response (it discarded the 200 OK because of the presence of two = Via=20 header field values and so is still waiting for the=20 response). =

I believe there shall be = procedures=20 that tells the UAC Core when to stop waiting for the response. = Or am I=20 misunderstanding something ?=20

Thanks for your=20 clarifications, =

S=E9bastien Prouvost
France=20 Telecom R&D =



********************************************************= **********************
-=20 NOTICE FROM DIMENSION DATA AUSTRALIA
This message is = confidential,=20 and may contain proprietary or legally privileged information. = If you=20 have received this email in error, please notify the sender and = delete=20 it immediately.

Internet communications are not secure. = You=20 should scan this message and any attachments for viruses. Under = no=20 circumstances do we accept liability for any loss or damage = which may=20 result from your receipt of this message or any=20 = attachments.
*********************************************************= *********************=20

=

= ------_=_NextPart_001_01C43285.3D1D238E-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 7 05:49:38 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11239 for ; Fri, 7 May 2004 05:49: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 1BM1tW-00009f-9H for sip-archive@odin.ietf.org; Fri, 07 May 2004 05:43:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i479hoJu000481 for sip-archive@odin.ietf.org; Fri, 7 May 2004 05:43:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM1ez-00044P-53; Fri, 07 May 2004 05:28:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM0fm-0000C0-5l for sip@optimus.ietf.org; Fri, 07 May 2004 04:25: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 EAA07979 for ; Fri, 7 May 2004 04:25:31 -0400 (EDT) From: nataraju.alilaghatta@wipro.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM0fj-00009M-6R for sip@ietf.org; Fri, 07 May 2004 04:25:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM0ek-0007VV-00 for sip@ietf.org; Fri, 07 May 2004 04:24:32 -0400 Received: from wiproecmx1.wipro.com ([164.164.31.5]) by ietf-mx with esmtp (Exim 4.12) id 1BM0dd-0006bm-00; Fri, 07 May 2004 04:23:22 -0400 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx1.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i478Mibp026565; Fri, 7 May 2004 13:52:44 +0530 (IST) Received: from blr-ec-bh2.wipro.com ([10.200.50.92]) by ec-vwall-wd with InterScan Messaging Security Suite; Fri, 07 May 2004 13:52:43 +0530 Received: from blr-ec-msg04.wipro.com ([10.200.53.99]) by blr-ec-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 7 May 2004 13:52:43 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4340C.77A80E4D" Subject: RE: RE : [Sip] Bug in RFC3261 ? Date: Fri, 7 May 2004 13:52:42 +0530 Message-ID: <10C4348A1BA43A4FA8D5B767E052CEAD012FAFF7@blr-ec-msg04.wipro.com> Thread-Topic: RE : [Sip] Bug in RFC3261 ? Thread-Index: AcQyNezx/egRPTdQRUmZJzLUfwOJqgAQmWlgAADQn4AAZAzzcA== To: , , Cc: , X-OriginalArrivalTime: 07 May 2004 08:22:43.0008 (UTC) FILETIME=[77F60400:01C4340C] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,EXCUSE_16,HTML_50_60, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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_01C4340C.77A80E4D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 Thanks & Regards, Nataraju A.B. -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of = PROUVOST S=E9bastien FTRD/DAC/ISS Sent: Wednesday, May 05, 2004 2:19 PM To: hisham.khartabil@nokia.com; Ben.Gatewood@didata.com.au Cc: sip@ietf.org; sip-admin@ietf.org Subject: RE : [Sip] Bug in RFC3261 ? =20 This does not really correspond to what I am saying. What I am saying is = the following:=20 =20 - I send a request (UPDATE for example) - I receive a 200 OK for this request. At this point the transaction = enters the state "Completed" and then "Terminated". Then the transaction = is destroyed and no more transaction layer timer is running for this = transaction. - The 200 OK is passed to the UAC Core layer. But this 200 OK contains = two Via headers. Section 8.1.3.3 (that handles UAC Core procedures) says = : "If more than one Via header field value is present in a response, the = UAC SHOULD discard the message."" So the UAC Core discards the message. = But the UAC Core is still waiting for a response (although the = corresponding transaction is terminated from the transaction layer point = of view).=20 =20 When does the UAC Core stop waiting for a response ? =20 [Nataraju] when UAC core receives a response with more than one VIA = header means intermediate entity did not remove the VIA header. Or some = intermediate entities might have maliciously added the via header. Hence = the UAC will discard the response =20 S=E9bastien. =20 -----Message d'origine----- De : hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]=20 Envoy=E9 : mercredi 5 mai 2004 10:12 =C0 : Ben.Gatewood@didata.com.au; PROUVOST S=E9bastien FTRD/DAC/ISS Cc : sip@ietf.org; sip-admin@ietf.org Objet : RE: [Sip] Bug in RFC3261 ? Well, you were pointing at the right sections. 17.1.1.2 and 17.1.2.2 = specify that when Timer B (for INVITE) and Timer F (for non-INVITE) = fire, "the client transaction SHOULD inform the TU about the timeout, and then it SHOULD enter the "Terminated" state" =20 Hisham -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext = Ben.Gatewood@didata.com.au Sent: 05.May.2004 03:02 To: PROUVOST S=E9bastien FTRD/DAC/ISS Cc: sip@ietf.org; sip-admin@ietf.org Subject: Re: [Sip] Bug in RFC3261 ? Hi S=E9bastien,=20 I just re-read your question and realised it's more complicated than I = thought :-)=20 Hmmm......I'm not sure what it should do either.=20 I'm sure someone smarter than me will be along shortly though :-)=20 B Ben Gatewood Dimension Data SIP Wookie Level 1 10 Dorcas Street South Melbourne +61 3 9626 0735 +61 419 885 762 ben.gatewood@didata.com.au=20 =20 Ben.Gatewood@didata.com.au=20 Sent by: sip-admin@ietf.org=20 05/05/2004 08:33 AM=20 =20 To: PROUVOST S=E9bastien FTRD/DAC/ISS = =20 cc: sip@ietf.org, sip-admin@ietf.org=20 Subject: Re: [Sip] Bug in RFC3261 ? Hi S=E9bastien,=20 There are procedures and timers for this situation in 3261. Have a look = at Section 17.1.1.2 and 17.1.2.2.=20 Basically the UA should wait 64*T1 (Timer 1). T1, by default, should be = 500ms so your UA should wait 32 seconds for a valid response.=20 HTH,=20 B Ben Gatewood Dimension Data SIP Wookie Level 1 10 Dorcas Street South Melbourne +61 3 9626 0735 +61 419 885 762 ben.gatewood@didata.com.au=20 =20 PROUVOST S=E9bastien FTRD/DAC/ISS = Sent by: sip-admin@ietf.org=20 04/05/2004 07:49 PM=20 =20 To: =20 cc: =20 Subject: [Sip] Bug in RFC3261 ? Hi,=20 In RFC 3261, it is written (section 8.1.3.3 for UAC Core procedures) : = "If more than one Via header field value is present in a response, the = UAC SHOULD discard the message."=20 However if the UAC Core layer discards the response and if this response = was the only one sent (for example a 200 OK to an UPDATE), then this = leads to a situation when the transaction is terminated (the transaction = layer received the response and passed it to the UA Core) but the UA = Core is still waiting for a response (it discarded the 200 OK because of = the presence of two Via header field values and so is still waiting for = the response).=20 I believe there shall be procedures that tells the UAC Core when to stop = waiting for the response. Or am I misunderstanding something ?=20 Thanks for your clarifications,=20 S=E9bastien Prouvost=20 France Telecom R&D=20 *************************************************************************= ***** - NOTICE FROM DIMENSION DATA AUSTRALIA This message is confidential, and may contain proprietary or legally = privileged information. If you have received this email in error, please = notify the sender and delete it immediately. Internet communications are not secure. You should scan this message and = any attachments for viruses. Under no circumstances do we accept = liability for any loss or damage which may result from your receipt of = this message or any attachments. *************************************************************************= *****=20 ------_=_NextPart_001_01C4340C.77A80E4D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message

 

 

Thanks & Regards,

Nataraju A.B.

-----Original = Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On = Behalf Of PROUVOST S=E9bastien FTRD/DAC/ISS
Sent: Wednesday, May 05, 2004 2:19 = PM
To: = hisham.khartabil@nokia.com; Ben.Gatewood@didata.com.au
Cc: sip@ietf.org; sip-admin@ietf.org
Subject: RE : [Sip] Bug = in RFC3261 ?

 

This does not = really correspond to what I am saying. What I am saying is the following: =

 

- I send a = request (UPDATE for example)

- I receive a = 200 OK for this request. At this point the transaction enters the state "Completed" and then "Terminated". Then the = transaction is destroyed and no more transaction layer timer is running for = this transaction.

- The 200 OK is = passed to the UAC Core layer. But this 200 OK contains two Via headers. Section = 8.1.3.3 (that handles UAC Core procedures) says : "If more than one Via header field value is present in = a response, the UAC SHOULD discard the message."" So the UAC Core discards the message. But the UAC = Core is still waiting for a response (although the corresponding transaction is terminated from the transaction layer point of view).

 

When does the = UAC Core stop waiting for a response ?

 

=A0[Nataraju] when UAC core receives a response with more than = one VIA header means intermediate entity did not remove the VIA header. Or some intermediate entities might have maliciously added the via header. Hence = the UAC will discard the response

 

S=E9bastien.

 

-----Message d'origine-----
De : hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
Envoy=E9 : mercredi = 5 mai 2004 10:12
=C0 : Ben.Gatewood@didata.com.au; PROUVOST S=E9bastien FTRD/DAC/ISS
Cc : sip@ietf.org; sip-admin@ietf.org
Objet : RE: [Sip] = Bug in RFC3261 ?

Well, you were = pointing at the right sections. 17.1.1.2 and 17.1.2.2 specify that when Timer B = (for INVITE) and Timer F (for non-INVITE) fire, "the client transaction SHOULD inform the TU about the
   timeout, and then it SHOULD enter the = "Terminated" state"

 

Hisham

-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf = Of ext Ben.Gatewood@didata.com.au
Sent: 05.May.2004 = 03:02
To: PROUVOST S=E9bastien FTRD/DAC/ISS
Cc: sip@ietf.org; sip-admin@ietf.org
Subject: Re: [Sip] Bug in = RFC3261 ?


Hi S=E9bastien,

I just re-read your question and realised it's more complicated than I = thought :-)

Hmmm......I'm not sure what it should do either.

I'm sure someone smarter than me will be along shortly though = :-)

B

Ben Gatewood
Dimension Data
SIP Wookie
Level 1 10 Dorcas Street South Melbourne
+61 3 9626 0735
+61 419 885 762
ben.gatewood@didata.com.au

 

Ben.Gatewood@didata.com.au=
Sent by: sip-admin@ietf.org

05/05/2004 08:33 AM

       
        To:        PROUVOST = S=E9bastien FTRD/DAC/ISS = <sebastien.prouvost@francetelecom.com>
        cc:        sip@ietf.org, sip-admin@ietf.org
        Subject:        Re: [Sip] Bug = in RFC3261 ?





Hi S=E9bastien,

There are procedures and timers for this situation in 3261. Have a look = at Section 17.1.1.2 and 17.1.2.2.

Basically the UA should wait 64*T1 (Timer 1). T1, by default, should be = 500ms so your UA should wait 32 seconds for a valid response. =

HTH,

B

Ben Gatewood
Dimension Data
SIP Wookie
Level 1 10 Dorcas Street South Melbourne
+61 3 9626 0735
+61 419 885 762
ben.gatewood@didata.com.au

 

PROUVOST S=E9bastien FTRD/DAC/ISS = <sebastien.prouvost@francetelecom.com>
Sent by: sip-admin@ietf.org

04/05/2004 07:49 PM

       
       To:       =  <sip@ietf.org>
       cc:       =  
       Subject:        [Sip] = Bug in RFC3261 ?





Hi,
In RFC 3261, it is written (section 8.1.3.3 for UAC Core procedures) : = "If more than one Via header field value is present in a response, the UAC = SHOULD discard the message."

However if the UAC = Core layer discards the response and if this response was the only one sent = (for example a 200 OK to an UPDATE), then this leads to a situation when the transaction is terminated (the transaction layer received the response = and passed it to the UA Core) but the UA Core is still waiting for a = response (it discarded the 200 OK because of the presence of two Via header field = values and so is still waiting for the response).

I believe there = shall be procedures that tells the UAC Core when to stop waiting for the = response. Or am I misunderstanding something ?

Thanks for your clarifications,

S=E9bastien Prouvost
France Telecom R&D



*************************************************************************= *****
- NOTICE FROM DIMENSION DATA AUSTRALIA
This message is confidential, and may contain proprietary or legally = privileged information. If you have received this email in error, please notify the = sender and delete it immediately.

Internet communications are not secure. You should scan this message and = any attachments for viruses. Under no circumstances do we accept liability = for any loss or damage which may result from your receipt of this message or any attachments.
*************************************************************************= *****

------_=_NextPart_001_01C4340C.77A80E4D-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 7 05:49:38 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11254 for ; Fri, 7 May 2004 05:49: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 1BM1ud-0000jL-LN for sip-archive@odin.ietf.org; Fri, 07 May 2004 05:44:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i479ixGp002766 for sip-archive@odin.ietf.org; Fri, 7 May 2004 05:44:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM1f9-0004AR-PJ; Fri, 07 May 2004 05:28:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM0jo-00027W-Ec for sip@optimus.ietf.org; Fri, 07 May 2004 04:29: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 EAA08243 for ; Fri, 7 May 2004 04:29:41 -0400 (EDT) From: Ervin.Beres@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM0jl-0001sc-H0 for sip@ietf.org; Fri, 07 May 2004 04:29:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM0ix-0001Sj-00 for sip@ietf.org; Fri, 07 May 2004 04:28:52 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BM0i8-00011h-00 for sip@ietf.org; Fri, 07 May 2004 04:28:00 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i478Rnv06627 for ; Fri, 7 May 2004 11:27:49 +0300 (EET DST) X-Scanned: Fri, 7 May 2004 11:27:45 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i478RjdI012093 for ; Fri, 7 May 2004 11:27:45 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00cs4Z3l; Fri, 07 May 2004 11:27:44 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i478RZH09027 for ; Fri, 7 May 2004 11:27:35 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 7 May 2004 11:27:07 +0300 Received: from buebe002.NOE.Nokia.com ([10.211.0.51]) by esebe023.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 7 May 2004 11:27:07 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [Sip] Caller-Preferences: "no-fork" directive and addresses with equal q-value Date: Fri, 7 May 2004 10:27:06 +0200 Message-ID: Thread-Topic: [Sip] Caller-Preferences: "no-fork" directive and addresses with equal q-value Thread-Index: AcQ0Cn5WFDhBFg/8QLipTN022MjYhw== To: X-OriginalArrivalTime: 07 May 2004 08:27:07.0457 (UTC) FILETIME=[1595BB10:01C4340D] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 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, I've looked to the Draft(/RFC) but could not really figure out how a server is supposed to work when it receives a request with "no-fork" but it has addresses with equal q value. I mean in what cases can it happen that the server does not accept the "no-fork" directive and forks the request? Generally, what is the best way for gateway type of UAs to indicate that no forking should happen as e.g. parallel early media may confuse the user? Does it have any effect to proxies supporting caller preferences if Proxy-Require is set to indicate that pref extension need to be supported? Thanks in advance. BR, -Ervin _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 7 10:44:56 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27472 for ; Fri, 7 May 2004 10:44: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 1BM6Ix-0005po-Kx for sip-archive@odin.ietf.org; Fri, 07 May 2004 10:26:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i47EQNfw022428 for sip-archive@odin.ietf.org; Fri, 7 May 2004 10:26:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM5vT-0000n2-9Y; Fri, 07 May 2004 10:02:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BM36D-0001sF-1u for sip@optimus.ietf.org; Fri, 07 May 2004 07:01: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 HAA15362 for ; Fri, 7 May 2004 07:00:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BM368-0001xx-PR for sip@ietf.org; Fri, 07 May 2004 07:00:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BM34z-0001YY-00 for sip@ietf.org; Fri, 07 May 2004 06:59:46 -0400 Received: from viap106.atea.be ([194.78.143.106] helo=hrtades9.atea.be) by ietf-mx with esmtp (Exim 4.12) id 1BM34Q-00018e-00 for sip@ietf.org; Fri, 07 May 2004 06:59:10 -0400 Received: from hrtades10.atea.be (siemens.atea.be [139.10.143.141]) by hrtades9.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JMT2YM41; Fri, 7 May 2004 12:58:40 +0200 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id ; Fri, 7 May 2004 12:58:40 +0200 Message-ID: <6B546A602AD2D211BFF00008C7A428890A940FA3@hrtades2.atea.be> From: Huybrighs Joseph To: "'sip@ietf.org'" Date: Fri, 7 May 2004 12:58:38 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Sip] SIP Transfer Failure Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Both draft-ietf-sipping-cc-transfer-02 and draft-ietf-sipping-service-examples-06 not really describe how the Transferor, after having invoked transfer, can be re-invited in case the transfer failed (e.g. the Transfer-Target failed to answer, wrong address in case of a blind transfer, etc.). Consider the following scenario: A establishes a dialog with B. B transfers to C. The dialog between A and C terminates with a 4xx. Solution from draft: B A C | (D1) REFER/202 | | |----------------------->| INVITE/18x | | |----------------->| | | 4xx | | (D1) NOTIFY (4xx)/200 |<-----------------| |<-----------------------| | | (D1) BYE/200 | | |----------------------->| | | | | | (D1) re-INVITE/200 | | |----------------------->| | | RTP | | |<---------------------->| | The proposal puts the responsibility to re-connect A and B on the Transferor. This works fine in case the Transferor still has an established dialog with the Transferee and an active User Interface that keeps track of what happened with the transfer request. Depending on the type of device the Transferor is using, this will not always be the case. E.g. if the Transferor is using a simple POTS phone, the transfer might have been initiated by going on hook during the consultation call with C. To get the Transferor back to the Transferee we will have to ring the Transferor's phone. This is not obvious with the proposed solution. Alternative Solution: B A C | (D1) REFER/202 | | |----------------------->| INVITE/18x | | |----------------->| | | 4xx | | (D1) NOTIFY (4xx)/200 |<-----------------| |<-----------------------| | | (D1) BYE/200 | | |----------------------->| | | | | | (D2) INVITE/18x/200 | | |<-----------------------| | | RTP | | |<---------------------->| | I would think that re-connecting the Transferor back to the Transferee is a feature that has to be controlled by the Transferee. This is indicated in the above diagram by the A party sending an new INVITE request to B resulting in the creation of a new dialog (D2). The original dialog (D1) can then be terminated when a final response is passed through the NOTIFY request. It also nicely solves ringing the Transferor when he or she would have gone on-hook before the transfer request finished. E.g. the A party being the initiator of the new 'call' would get ring-back tone if it is a POTS phone. Does this make sense? Jos Huybrighs Siemens _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 10 16:29:58 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01700 for ; Mon, 10 May 2004 16:29:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNHL2-0003sv-Rz for sip-archive@odin.ietf.org; Mon, 10 May 2004 16:25:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4AKPOI2014839 for sip-archive@odin.ietf.org; Mon, 10 May 2004 16:25:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNH96-0001Wa-7D; Mon, 10 May 2004 16:13:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNH1y-0000Rx-Rx for sip@optimus.ietf.org; Mon, 10 May 2004 16:05:43 -0400 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00263 for ; Mon, 10 May 2004 16:05:39 -0400 (EDT) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1BNGuT-0006wf-Qh; Mon, 10 May 2004 15:57:57 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , sip mailing list , sip chair , sip chair Message-Id: Date: Mon, 10 May 2004 15:57:57 -0400 Subject: [Sip] Protocol Action: 'SIP Authenticated Identity Body (AIB) Format' 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 following document: - 'SIP Authenticated Identity Body (AIB) Format ' 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 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. An important usage of the Authenticated Identity Body is seen in conjunction with SIP's Referred-By mechanism. Working Group Summary The working group strongly supported the advancement of AIB. Protocol Quality There were review comments for this document during WG discussion. There were no dissenting comments during Working Group Last Call or IETF Last Call. The document was reviewed for the IESG by Eric Rescorla and 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 Mon May 10 18:08:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10476 for ; Mon, 10 May 2004 18:08: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 1BNIoA-0006cA-KN for sip-archive@odin.ietf.org; Mon, 10 May 2004 17:59:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ALxYDM025427 for sip-archive@odin.ietf.org; Mon, 10 May 2004 17:59:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNIbK-00041w-Nh; Mon, 10 May 2004 17:46:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNINo-0000ZY-T9 for sip@optimus.ietf.org; Mon, 10 May 2004 17:32: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 RAA07895 for ; Mon, 10 May 2004 17:32:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNINm-0007Is-G5 for sip@ietf.org; Mon, 10 May 2004 17:32:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNIMr-0006tM-00 for sip@ietf.org; Mon, 10 May 2004 17:31:22 -0400 Received: from vtg-um-e2k2.cisco.com ([171.70.93.54] helo=vtg-um-e2k2.sj21ad.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BNIL9-00068g-00 for sip@ietf.org; Mon, 10 May 2004 17:29:35 -0400 Received: from cisco.com ([10.32.130.86]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 10 May 2004 14:29:05 -0700 Message-ID: <409FF43A.30709@cisco.com> Date: Mon, 10 May 2004 14:29:30 -0700 From: Manjunath Bangalore User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org CC: "Prabhu, Prashanth" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 May 2004 21:29:05.0103 (UTC) FILETIME=[D1EB9DF0:01C436D5] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Propogating URI parameters end to end Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org 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, Consider a case where a SIP UA initiates a request (Ex: INVITE), wherein the Request URI contains some user-defined URI parameters that are to meant to be understood by the eventual UA terminating the request - Example: INVITE callee@targetdomain.com; end_user_param=foo How do we ensure that the user-defined URI parameter accompanying the Request-URI is propogated to the terminating UA? With a read of RFC 3261, I see in Sec 16.5, that when the request lands on the Proxy that is responsible for the domain in the Request-URI, one of the ways it can generate a target set is by doing a lookup using a Location Service, Ex: A SIP Registrar. Before a lookup is done, the Request-URI is required to be canonicalized, and during this process, any URI parameters are dropped when contructing an index for the lookup. While this canonicalization makes sense for the purpose of the location service lookup, before the INVITE is forwarded to the URI returned by the Location service, wouldn't it be right to append the original URI parameters to it, in order to preserve them. On a related note, the GRUU draft requires a Proxy in a target domain to pass the "grid" URI parameter(grid=foo) that is received alongside the Request-URI. Unless I am missing something, are there any issues with adding a statement to RFC 3261, that explicitly states that any URI parameters present in the Request-URI must be forwarded. Thanks, -Manjax _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 10 18:42:15 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13460 for ; Mon, 10 May 2004 18:42:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNJOq-00061k-DI for sip-archive@odin.ietf.org; Mon, 10 May 2004 18:37:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4AMbSSp023163 for sip-archive@odin.ietf.org; Mon, 10 May 2004 18:37:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNJB0-0002uL-Ru; Mon, 10 May 2004 18:23:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNJ1L-0006Bp-2X for sip@optimus.ietf.org; Mon, 10 May 2004 18:13:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11146 for ; Mon, 10 May 2004 18:13:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNJ1I-0006HU-8v for sip@ietf.org; Mon, 10 May 2004 18:13:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNJ0H-0005w6-00 for sip@ietf.org; Mon, 10 May 2004 18:12:06 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BNIzH-0005GO-00 for sip@ietf.org; Mon, 10 May 2004 18:11:03 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 10 May 2004 15:12:20 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4AMAHYu006190; Mon, 10 May 2004 18:10:18 -0400 (EDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIH09547; Mon, 10 May 2004 18:10:18 -0400 (EDT) Message-ID: <409FFDCC.1030700@cisco.com> Date: Mon, 10 May 2004 18:10:20 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manjunath Bangalore CC: sip@ietf.org, "Prabhu, Prashanth" Subject: Re: [Sip] Propogating URI parameters end to end References: <409FF43A.30709@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 Manjax, Yes, this came up regarding the handling of GRUU. As things stand with 3261, you can't expect the parameters to be propagated. Extra requirements were added to the GRUU draft to ensure that the grid parameter is propagated. I suppose a change could be made to 3261 to require propagating parameters in general, but it isn't entirely clear that this would always be the right thing to do. It is also not always possible, because the contacts that the proxy translates to needn't be sip URIs. For other kinds there is no guarantee that parameters are supported at all, or if so that propagating sip uri parameters would be the right thing to do. This is one of the problems I have with using a uri parameter for referencing uri lists in the exploder drafts. I am inclined to leave things as they are - assuming that the parameter must have meaning to the owner of the address it is attached to. If the meaning of one or more parameters extends to propagating them to some derived address then fine, but that isn't a general mechanism. Paul Manjunath Bangalore wrote: > Hi, > > Consider a case where a SIP UA initiates a request (Ex: INVITE), > wherein the Request URI contains some user-defined URI parameters that > are to meant to be understood by the eventual UA terminating the request > - Example: > > INVITE callee@targetdomain.com; end_user_param=foo > > How do we ensure that the user-defined URI parameter accompanying the > Request-URI is propogated to the terminating UA? > > With a read of RFC 3261, I see in Sec 16.5, that when the request lands > on the Proxy that is responsible for the domain in the Request-URI, one > of the ways it can generate a target set is by doing a lookup using a > Location Service, Ex: A SIP Registrar. Before a lookup is done, the > Request-URI is required to be canonicalized, and during this process, > any URI parameters are dropped when contructing an index for the lookup. > While this canonicalization makes sense for the purpose of the location > service lookup, before the INVITE is forwarded to the URI returned by > the Location service, wouldn't it be right to append the original URI > parameters to it, in order to preserve them. > > On a related note, the GRUU draft requires a Proxy in a target domain to > pass the "grid" URI parameter(grid=foo) that is received alongside the > Request-URI. > > Unless I am missing something, are there any issues with adding a > statement to RFC 3261, that explicitly states that any URI parameters > present in the Request-URI must be forwarded. > > Thanks, > -Manjax > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 May 11 01:29:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03002 for ; Tue, 11 May 2004 01:29: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 1BNPnr-0004xW-Fv for sip-archive@odin.ietf.org; Tue, 11 May 2004 01:27:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4B5RhMl019043 for sip-archive@odin.ietf.org; Tue, 11 May 2004 01:27:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNPfW-0003It-ST; Tue, 11 May 2004 01:19:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNPaH-0001xn-0q for sip@optimus.ietf.org; Tue, 11 May 2004 01:13: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 BAA02205 for ; Tue, 11 May 2004 01:13:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNPaE-0004gr-4H for sip@ietf.org; Tue, 11 May 2004 01:13:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNPZK-0004L9-00 for sip@ietf.org; Tue, 11 May 2004 01:12:43 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BNPYn-0003yI-00 for sip@ietf.org; Tue, 11 May 2004 01:12:09 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 10 May 2004 22:11:59 -0700 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.10/8.12.6) with ESMTP id i4B5BcjO008487; Mon, 10 May 2004 22:11:38 -0700 (PDT) Received: from cisco.com (sjc-vpn3-276.cisco.com [10.21.65.20]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ATB26686; Mon, 10 May 2004 22:10:50 -0700 (PDT) Message-ID: <40A06089.2010802@cisco.com> Date: Mon, 10 May 2004 22:11:37 -0700 From: Manjunath Bangalore User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: sip@ietf.org, "Prabhu, Prashanth" Subject: Re: [Sip] Propogating URI parameters end to end References: <409FF43A.30709@cisco.com> <409FFDCC.1030700@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Paul, Thanks for the response In the light of this, would allowing use of user-defined URI parameters accompanying the Request-URI serve any purpose at all? -Manjax Paul Kyzivat wrote: > Manjax, > > Yes, this came up regarding the handling of GRUU. As things stand with > 3261, you can't expect the parameters to be propagated. Extra > requirements were added to the GRUU draft to ensure that the grid > parameter is propagated. > > I suppose a change could be made to 3261 to require propagating > parameters in general, but it isn't entirely clear that this would > always be the right thing to do. It is also not always possible, > because the contacts that the proxy translates to needn't be sip URIs. > For other kinds there is no guarantee that parameters are supported at > all, or if so that propagating sip uri parameters would be the right > thing to do. > > This is one of the problems I have with using a uri parameter for > referencing uri lists in the exploder drafts. > > I am inclined to leave things as they are - assuming that the > parameter must have meaning to the owner of the address it is attached > to. If the meaning of one or more parameters extends to propagating > them to some derived address then fine, but that isn't a general > mechanism. > > Paul > > Manjunath Bangalore wrote: > >> Hi, >> >> Consider a case where a SIP UA initiates a request (Ex: INVITE), >> wherein the Request URI contains some user-defined URI parameters >> that are to meant to be understood by the eventual UA terminating the >> request - Example: >> >> INVITE callee@targetdomain.com; end_user_param=foo >> >> How do we ensure that the user-defined URI parameter accompanying the >> Request-URI is propogated to the terminating UA? >> >> With a read of RFC 3261, I see in Sec 16.5, that when the request >> lands on the Proxy that is responsible for the domain in the >> Request-URI, one of the ways it can generate a target set is by >> doing a lookup using a Location Service, Ex: A SIP Registrar. Before >> a lookup is done, the Request-URI is required to be canonicalized, >> and during this process, any URI parameters are dropped when >> contructing an index for the lookup. While this canonicalization >> makes sense for the purpose of the location service lookup, before >> the INVITE is forwarded to the URI returned by the Location service, >> wouldn't it be right to append the original URI parameters to it, in >> order to preserve them. >> >> On a related note, the GRUU draft requires a Proxy in a target domain >> to pass the "grid" URI parameter(grid=foo) that is received alongside >> the Request-URI. >> >> Unless I am missing something, are there any issues with adding a >> statement to RFC 3261, that explicitly states that any URI parameters >> present in the Request-URI must be forwarded. >> >> Thanks, >> -Manjax >> >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP 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 May 11 02:54:26 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06822 for ; Tue, 11 May 2004 02:54:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNR5f-0003gO-QI for sip-archive@odin.ietf.org; Tue, 11 May 2004 02:50:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4B6oBYv014089 for sip-archive@odin.ietf.org; Tue, 11 May 2004 02:50:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNQvr-0001iu-Lg; Tue, 11 May 2004 02:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNQrT-0000XC-On for sip@optimus.ietf.org; Tue, 11 May 2004 02:35:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05882 for ; Tue, 11 May 2004 02:35:28 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNQrP-0003BU-V1 for sip@ietf.org; Tue, 11 May 2004 02:35:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNQqW-0002qF-00 for sip@ietf.org; Tue, 11 May 2004 02:34:32 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BNQpj-0002VM-00 for sip@ietf.org; Tue, 11 May 2004 02:33:43 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4B6Xdv19357 for ; Tue, 11 May 2004 09:33:39 +0300 (EET DST) X-Scanned: Tue, 11 May 2004 09:33:37 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i4B6XbXT028092 for ; Tue, 11 May 2004 09:33:37 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00t2RnYg; Tue, 11 May 2004 09:33:36 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4B6XVH25524 for ; Tue, 11 May 2004 09:33:31 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 11 May 2004 09:33:30 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 May 2004 09:33:30 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797A94@esebe019.ntc.nokia.com> Thread-Topic: Deadline for internet drafts submission before interim Thread-Index: AcQ3Id/jP+z1IZsrSHWzzMI+cf/EYw== To: X-OriginalArrivalTime: 11 May 2004 06:33:30.0480 (UTC) FILETIME=[E0009700:01C43721] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Sip] Deadline for internet drafts submission before interim Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org 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 Deadline for submitting internet drafts for discussion at the = interim meeting is Monday 17th May. This hopefully gives attendees = enough time to read the IDs to enable them to engage in discussions. Regards, Hisham (on behalf of the SIMPLE, SIP, SIPPING and XCON WG chairs) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 11 03:15:57 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07650 for ; Tue, 11 May 2004 03:15: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 1BNRNn-0008GL-CU for sip-archive@odin.ietf.org; Tue, 11 May 2004 03:08:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4B78tle031661 for sip-archive@odin.ietf.org; Tue, 11 May 2004 03:08:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNR9U-0004xm-PJ; Tue, 11 May 2004 02:54:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNR1C-00031G-Pm for sip@optimus.ietf.org; Tue, 11 May 2004 02:45: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 CAA06368 for ; Tue, 11 May 2004 02:45:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNR18-0006tL-Sz for sip@ietf.org; Tue, 11 May 2004 02:45:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNR0C-0006Wq-00 for sip@ietf.org; Tue, 11 May 2004 02:44:34 -0400 Received: from [80.74.106.125] (helo=rvil-mail.RADVISION.com) by ietf-mx with esmtp (Exim 4.12) id 1BNQzG-0005oC-00 for sip@ietf.org; Tue, 11 May 2004 02:43:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Session Timer - Terminology is no clear Date: Tue, 11 May 2004 09:45:18 +0300 Message-ID: <10DA2C035FE3BC4FA8D73EC55FC43D9B047A76@rvil-mail.radvision.com> Thread-Topic: [Sip] Session Timer - Terminology is no clear Thread-Index: AcQysZPHJBWSZ9QSShO9Kw2xyJ2kgQEaxC3Q From: "Sarit Galanos" To: "Paul Kyzivat" Cc: , "Jonathan Rosenberg" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Paul, Thanks for you answer. >From your answer I understand that 7.1 talks about the first time the = UAC tries to set a session timer=20 (in an initial dialog or an established dialog), and 7.4 defines the = behavior of the UAC incase the request=20 was rejected with 422. Further refreshes are identical to the initial refresh. I'm still not clear about the relationship between the Session Expires = and the Min SE. Lets say a UAC wants to set them both. According to 7.1: "If a Min-SE header is included in the initial session refresh request, the value of the Session-Expires MUST be equal to the value in Min-SE." Proxies on the way must follow the following rule regarding the Session = Expires: "Any proxy servicing this request can lower this value, but is not allowed to decrease it below the value specified = in the Min-SE header field." But then how can a proxy lower the Min-SE if it is always equal to the = Session Expires? And when both Session Expires and Min-SE will be present but will = include different values? Thanks for you help, Sarit. -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Wednesday, May 05, 2004 5:57 PM To: Sarit Galanos Cc: sip@ietf.org; Jonathan Rosenberg Subject: Re: [Sip] Session Timer - Terminology is no clear Sarit, I just went back and reread the text. I agree it is confusing. Stepping back a moment, lets look at what kind of session refresh=20 requests can be either INVITE or UPDATE. INVITE could also be=20 establishing a dialog, or it could be within an existing dialog. UPDATE=20 can only be within an existing dialog. (I note that this draft is now behind the times in that it doesn't=20 address other dialog establishing requests. It would make perfect sense=20 to want to use session timer within a dialog established with a=20 SUBSCRIBE. But that is a subject for another time.) Session timers intimately connected to dialogs. But some of the action=20 may happen before a dialog is established. The behavior before and after = a dialog is established is intertwined in the text. It is probably worth = looking at separately: Suppose the UAC is sending a new INVITE that will hopefully establish a=20 dialog. And the UAC wants to use session timer, so it inserts a=20 Supported: timer. It may also insert Session-Expires and/or Min-SE. This could fail with a 422, indicating that the Session-Expires inserted = by the UAC or some proxy on the path was too small for the UAS or some=20 proxy on the path. This clearly doesn't affect dialog state, because there isn't any dialog = yet. So it can only affect pending call state in the UAC - altering how=20 further attempts to establish the call are done. The invite could have forked, and some other fork could have succeeded.=20 In that case this is moot. But if all the forks fail, then the UAC may=20 attempt to recover, retrying the invite. To have this try come out=20 differently, it follows 7.4 and inserts a Min-SE that is the max of all=20 those it received in 422 responses. The UAC may also include a=20 Session-Expires in the retry, constrained by the Min-SE value.=20 Presumably it would do this iff it had included one in the initial = request. Doing that ensures that proxies along all fork paths will use=20 Session-Expires values large enough to be acceptable to all candidate=20 forked UASs, so that there should be no 422 responses on the 2nd try. Of = course there may be other problems, but eventually this will hopefully=20 result in one or more responses that establish dialogs. And each dialog=20 then may or may not have a session timer in operation according to the=20 response. Each dialog is then an independent entity for purposes of=20 session timer. It is possible that a dialog would be established without a session=20 timer, and then later, an initial session refresh could be sent within=20 the dialog. That isn't a very interesting case, so I will ignore it for = now. Once in a dialog with a session timer, one of the participants might=20 send an INVITE or UPDATE. This could be because the time to refresh the=20 session timer has come, or it could be for some entirely unrelated=20 reason. It doesn't matter, because the rules must be followed if the=20 message is sent, regardless of reason. Parts of 7.4 apply to this case. The key requirement here has to do with = Min-SE: The value of the Min-SE header field present in a session refresh request MUST be the largest value amongst all Min-SE header field values ... received in session refresh requests, on the same dialog, if a dialog has been established. ... A result of this rule is that the maximum value of the Min-SE is effectively 'cleared' once the dialog is established, and from that point on, only the values from proxies known to be on the proxy path will end up being used. The point here is that the Min-SE in the initial request might have been = larger than necessary due to the needs of servers on forks not taken.=20 Now that a dialog has been established, the goal is to constrain the=20 session-expires value only by the needs of the currently involved = parties. In the simple case where there was no forking, and the initial request=20 succeeded in establishing a dialog, the Min-SE value used in the=20 "subsequent session refresh request" would normally be the same value=20 received in the response to the initial session refresh request. The rules about the relationship of the Session-Expires to the Min-SE=20 are a separate story. The UAC is never required to insert a=20 Session-Expires at all. The session timer mechanism is really for the=20 benefit of the proxies along the path rather than the UAC and UAS. (The=20 UAC and UAS are free to send INVITE or UPDATE any time they want to test = the liveness of the other end. They don't need session timer for this.)=20 So there is no particular benefit in the UAC providing a value other=20 than to express a preference as the refresher or not. So in general it=20 would be silly for a UAC to insert a Session-Expires into an initial=20 session refresh request. Once a session timer has been established, it will presumably be a=20 normal case to want to preserve it for the life of the dialog, even as=20 other things change in the dialog. I really don't know why 7.4 says the UAC SHOULD include Session-Expires. = If it just included Min-SE the right thing would happen, and other=20 options would be preserved for the other participants in the dialog. One = reason to include it is to specify the uac/uas parameter, but the UAS=20 for the request could handle that. If the Session-Expires header is=20 included, its syntax requires that delta-time be provided. The=20 requirement that this equal Min-SE guarantees that the value can't be=20 altered anywhere in the path. This means that once a time value has been = established it won't ever change. Possibly the recommentation to include Session-Expires in this case was=20 motivated by a desire for the session timer not to be accidentally lost=20 from the call. But I think a rule on the UAS is sufficient for that. So=20 I think I would be inclined to violate the SHOULD, and omit the=20 Session-Expires in this case. I may have forgotten something about the rationale here. Maybe Jonathan=20 will comment on this. Paul Sarit Galanos wrote: > Hi Paul, > Thanks for you answer. > I'm still not clear about the following: > The draft includes two different sections: > 7.1 Generating an Initial Session Refresh Request > 7.4 Generating Subsequent Session Refresh Requests > Each section includes different rules regarding the session timer. > When should I apply the behavior of 7.1 and when should I use 7.4? >=20 > Thanks, > Sarit. >=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, May 03, 2004 5:06 PM > To: Sarit Galanos > Cc: sip@ietf.org > Subject: Re: [Sip] Session Timer - Terminology is no clear >=20 >=20 > The language in this is at times obscure. I think in part this results = > from the age of the document. (It has been in progress for years, I=20 > think since before 2543bis. So terminology has changed around it.) >=20 > Part of the problem is that it is written as if a reINVITE or UPDATE = is=20 > done solely for the purpose of session timer refresh. But in reality=20 > things are not that simple. >=20 > A reINVITE or an UPDATE does a bunch of stuff. If session-timer is=20 > supported then refreshing, or cancelling, a session timer is one of = the=20 > things it does. Any time a reINVITE or UPDATE is sent, it will affect=20 > the session timer one way or another, whether that was the primary=20 > intent in sending the message, or not. >=20 > There also isn't anything special about the "first" refresh. The = request=20 > that first establishes a dialog also establishes some kind of session=20 > timer state - either leaving it disabled, or running. Every subsequent = > reINVITE, UPDATE (and reSUBSCRIBE too) does the same thing -=20 > restablishes a new session timer or else leaves the dialog with none.=20 > There is no need to consider what the previous state was - the new = state=20 > is not affected by that. >=20 > All that the session timer mechanism does is force a reINVITE or = UPDATE=20 > to happen by a particular time if one hasn't happened for any other = reason. >=20 > Paul >=20 > Sarit Galanos wrote: >=20 >>Hi, >>The session timer draft uses the term "Initial Session Refresh = Request". >> >>The draft defines that=20 >> "Session Refresh Request: An INVITE or UPDATE request = within a dialog." >> >>>From that I understand that "Initial Session Refresh Request" is the = first re-Invite or Update inside that dialog. >> >>But, If the dialog was established with session timer parameters and = after the first INVITE-200-ACK session time is already active, >>why is there a difference between the initial refresh and further = refreshes. >>Or is that the "Initial Session Refresh Request" is the first request = that has session timer parameters >>and it can also be the initial INVITE? >> >>Thanks, >>Sarit >> >> >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 11 04:11:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10453 for ; Tue, 11 May 2004 04:11: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 1BNSDr-0003oU-91 for sip-archive@odin.ietf.org; Tue, 11 May 2004 04:02:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4B82haC014633 for sip-archive@odin.ietf.org; Tue, 11 May 2004 04:02:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNS0d-0001AX-CP; Tue, 11 May 2004 03:49:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNRll-0005Kx-CS for sip@optimus.ietf.org; Tue, 11 May 2004 03:33: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 DAA08611 for ; Tue, 11 May 2004 03:33:39 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNRlj-0001HS-0M for sip@ietf.org; Tue, 11 May 2004 03:33:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNRkq-0000tS-00 for sip@ietf.org; Tue, 11 May 2004 03:32:45 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BNRjx-0000UP-00 for sip@ietf.org; Tue, 11 May 2004 03:31:50 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4B7Urv02796; Tue, 11 May 2004 10:30:54 +0300 (EET DST) X-Scanned: Tue, 11 May 2004 10:30:47 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i4B7UlVC022739; Tue, 11 May 2004 10:30:47 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00AOTSEZ; Tue, 11 May 2004 10:30:45 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4B7UdH06538; Tue, 11 May 2004 10:30:39 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 11 May 2004 10:30:33 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 11 May 2004 10:30:34 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 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] Propogating URI parameters end to end Date: Tue, 11 May 2004 10:30:31 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797A9B@esebe019.ntc.nokia.com> Thread-Topic: [Sip] Propogating URI parameters end to end Thread-Index: AcQ231PYgxR8nLN+QLCSV+gZiNQqxQASkEuQ To: , Cc: , X-OriginalArrivalTime: 11 May 2004 07:30:34.0053 (UTC) FILETIME=[D89C5F50:01C43729] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 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 A new header, or ever better, a body part would be more appropriate, = IMO, to propagate peer-to-peer specific indicators. Regards, Hisham > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext > Paul Kyzivat > Sent: 11.May.2004 01:10 > To: Manjunath Bangalore > Cc: sip@ietf.org; Prabhu, Prashanth > Subject: Re: [Sip] Propogating URI parameters end to end >=20 >=20 > Manjax, >=20 > Yes, this came up regarding the handling of GRUU. As things=20 > stand with=20 > 3261, you can't expect the parameters to be propagated. Extra=20 > requirements were added to the GRUU draft to ensure that the grid=20 > parameter is propagated. >=20 > I suppose a change could be made to 3261 to require propagating=20 > parameters in general, but it isn't entirely clear that this would=20 > always be the right thing to do. It is also not always=20 > possible, because=20 > the contacts that the proxy translates to needn't be sip=20 > URIs. For other=20 > kinds there is no guarantee that parameters are supported at=20 > all, or if=20 > so that propagating sip uri parameters would be the right thing to do. >=20 > This is one of the problems I have with using a uri parameter for=20 > referencing uri lists in the exploder drafts. >=20 > I am inclined to leave things as they are - assuming that the=20 > parameter=20 > must have meaning to the owner of the address it is attached=20 > to. If the=20 > meaning of one or more parameters extends to propagating them to some=20 > derived address then fine, but that isn't a general mechanism. >=20 > Paul >=20 > Manjunath Bangalore wrote: > > Hi, > >=20 > > Consider a case where a SIP UA initiates a request (Ex: INVITE),=20 > > wherein the Request URI contains some user-defined URI=20 > parameters that=20 > > are to meant to be understood by the eventual UA=20 > terminating the request=20 > > - Example: > >=20 > > INVITE callee@targetdomain.com; end_user_param=3Dfoo > >=20 > > How do we ensure that the user-defined URI parameter=20 > accompanying the=20 > > Request-URI is propogated to the terminating UA? > >=20 > > With a read of RFC 3261, I see in Sec 16.5, that when the=20 > request lands=20 > > on the Proxy that is responsible for the domain in the=20 > Request-URI, one=20 > > of the ways it can generate a target set is by doing a=20 > lookup using a=20 > > Location Service, Ex: A SIP Registrar. Before a lookup is done, the=20 > > Request-URI is required to be canonicalized, and during=20 > this process,=20 > > any URI parameters are dropped when contructing an index=20 > for the lookup.=20 > > While this canonicalization makes sense for the purpose of=20 > the location=20 > > service lookup, before the INVITE is forwarded to the URI=20 > returned by=20 > > the Location service, wouldn't it be right to append the=20 > original URI=20 > > parameters to it, in order to preserve them. > >=20 > > On a related note, the GRUU draft requires a Proxy in a=20 > target domain to=20 > > pass the "grid" URI parameter(grid=3Dfoo) that is received=20 > alongside the=20 > > Request-URI. > >=20 > > Unless I am missing something, are there any issues with adding a=20 > > statement to RFC 3261, that explicitly states that any URI=20 > parameters=20 > > present in the Request-URI must be forwarded. > >=20 > > Thanks, > > -Manjax > >=20 > >=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 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Tue May 11 05:25:04 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14282 for ; Tue, 11 May 2004 05:25:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNTQ6-0006zf-RT for sip-archive@odin.ietf.org; Tue, 11 May 2004 05:19:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4B9JQFv026883 for sip-archive@odin.ietf.org; Tue, 11 May 2004 05:19:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNTFF-0003zu-Fq; Tue, 11 May 2004 05:08:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNSzD-0008LQ-Bz for sip@optimus.ietf.org; Tue, 11 May 2004 04:51:39 -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 EAA12809 for ; Tue, 11 May 2004 04:51:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNSzA-00072A-8T for sip@ietf.org; Tue, 11 May 2004 04:51:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNSxH-0006g4-00 for sip@ietf.org; Tue, 11 May 2004 04:49:40 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx with esmtp (Exim 4.12) id 1BNSwQ-0006KK-00 for sip@ietf.org; Tue, 11 May 2004 04:48:47 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 11 May 2004 10:48:47 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43734.C5E6D824" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Tue, 11 May 2004 10:48:47 +0200 Message-ID: <3418F3471F1CA4409901547349FFAE2E016FA32E@ftrdmel2.rd.francetelecom.fr> Thread-Topic: Subscription to Event packages Thread-Index: AcQ3NMTj01LXh2DjSeC+PjVCjvqSxQ== From: "ANTONINI Pierre-Antoine FTRD/DMR/LON" To: X-OriginalArrivalTime: 11 May 2004 08:48:47.0276 (UTC) FILETIME=[C5FD5EC0:01C43734] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Subject: [Sip] Subscription to Event packages Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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_01C43734.C5E6D824 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Dear all, Does anyone know if it is possible to subscribe to different event packages using only one SIP SUBSCRIBE message? According to the RFC 3265, I think it is not acceptable but I am just wondering whether we could have two values in the Event header. Many Regards, Pierre-Antoine Antonini Telecom Engineer France Telecom R&D UK Ltd Chiswick Park, Building 3, Chiswick High Road, London W4 5YA 0044 (0) 2088495864 mailto: pierreantoine.antonini@rd.francetelecom.com ------_=_NextPart_001_01C43734.C5E6D824 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subscription to Event packages

Dear all,
Does anyone know if it is possible to = subscribe to different event packages using only one SIP SUBSCRIBE = message? According to the RFC 3265, I think it is not acceptable but I = am just wondering whether we could have two values in the Event = header.

Many Regards,

Pierre-Antoine = Antonini
Telecom = Engineer
France Telecom = R&D UK Ltd
Chiswick Park, = Building 3,
Chiswick High = Road,
London W4 = 5YA
0044 (0) = 2088495864
mailto: = pierreantoine.antonini@rd.francetelecom.com

------_=_NextPart_001_01C43734.C5E6D824-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 11 12:57:14 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08316 for ; Tue, 11 May 2004 12:57: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 1BNaGd-0000YW-Qz for sip-archive@odin.ietf.org; Tue, 11 May 2004 12:38:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BGc7NH002125 for sip-archive@odin.ietf.org; Tue, 11 May 2004 12:38:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNa7q-0007B0-2t; Tue, 11 May 2004 12:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNZqL-0002eM-UH for sip@optimus.ietf.org; Tue, 11 May 2004 12:10: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 MAA05690 for ; Tue, 11 May 2004 12:10:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNZqK-0001KD-MW for sip@ietf.org; Tue, 11 May 2004 12:10:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNZpI-0000uW-00 for sip@ietf.org; Tue, 11 May 2004 12:09:53 -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 1BNZoC-00006F-00 for sip@ietf.org; Tue, 11 May 2004 12:08:44 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 11 May 2004 08:14:07 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i4BG8BSu027514; Tue, 11 May 2004 09:08:11 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIJ22494; Tue, 11 May 2004 12:08:10 -0400 (EDT) Message-ID: <40A0FA6A.9000808@cisco.com> Date: Tue, 11 May 2004 12:08:10 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manjunath Bangalore CC: sip@ietf.org, "Prabhu, Prashanth" Subject: Re: [Sip] Propogating URI parameters end to end References: <409FF43A.30709@cisco.com> <409FFDCC.1030700@cisco.com> <40A06089.2010802@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 Manjunath Bangalore wrote: > Paul, > > Thanks for the response > > In the light of this, would allowing use of user-defined URI parameters > accompanying the Request-URI serve any purpose at all? Depends on what you mean by "user defined". I presume you just mean "not defined by IETF" or something like that. Such a parameter is fine for communicating something from the UAC to the server responsible for the URI it is attached to. In the case of AORs that are managed by proxies and registrars, it is the proxy that is responsible for the AOR. So a parameter that is intended for consumption by that proxy is appropriate. The communication is between the UAC and the proxy, but not the UAS. A parameter intended for consumption by an endpoint could be loaded in a contact address and registered to an AOR. Then, any request addressed to that AOR, when relayed to that particular registered contact, would contain the parameter that was registered. In that case it is a means of communication between the UAS and the proxy/registrar, but not the UAC. It is when intending to communication info from the UAC to the UAS via a proxy that the uri parameter is not helpful. Paul > -Manjax > > Paul Kyzivat wrote: > >> Manjax, >> >> Yes, this came up regarding the handling of GRUU. As things stand with >> 3261, you can't expect the parameters to be propagated. Extra >> requirements were added to the GRUU draft to ensure that the grid >> parameter is propagated. >> >> I suppose a change could be made to 3261 to require propagating >> parameters in general, but it isn't entirely clear that this would >> always be the right thing to do. It is also not always possible, >> because the contacts that the proxy translates to needn't be sip URIs. >> For other kinds there is no guarantee that parameters are supported at >> all, or if so that propagating sip uri parameters would be the right >> thing to do. >> >> This is one of the problems I have with using a uri parameter for >> referencing uri lists in the exploder drafts. >> >> I am inclined to leave things as they are - assuming that the >> parameter must have meaning to the owner of the address it is attached >> to. If the meaning of one or more parameters extends to propagating >> them to some derived address then fine, but that isn't a general >> mechanism. >> >> Paul >> >> Manjunath Bangalore wrote: >> >>> Hi, >>> >>> Consider a case where a SIP UA initiates a request (Ex: INVITE), >>> wherein the Request URI contains some user-defined URI parameters >>> that are to meant to be understood by the eventual UA terminating the >>> request - Example: >>> >>> INVITE callee@targetdomain.com; end_user_param=foo >>> >>> How do we ensure that the user-defined URI parameter accompanying the >>> Request-URI is propogated to the terminating UA? >>> >>> With a read of RFC 3261, I see in Sec 16.5, that when the request >>> lands on the Proxy that is responsible for the domain in the >>> Request-URI, one of the ways it can generate a target set is by >>> doing a lookup using a Location Service, Ex: A SIP Registrar. Before >>> a lookup is done, the Request-URI is required to be canonicalized, >>> and during this process, any URI parameters are dropped when >>> contructing an index for the lookup. While this canonicalization >>> makes sense for the purpose of the location service lookup, before >>> the INVITE is forwarded to the URI returned by the Location service, >>> wouldn't it be right to append the original URI parameters to it, in >>> order to preserve them. >>> >>> On a related note, the GRUU draft requires a Proxy in a target domain >>> to pass the "grid" URI parameter(grid=foo) that is received alongside >>> the Request-URI. >>> >>> Unless I am missing something, are there any issues with adding a >>> statement to RFC 3261, that explicitly states that any URI parameters >>> present in the Request-URI must be forwarded. >>> >>> Thanks, >>> -Manjax >>> >>> >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP 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 May 11 12:59:26 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08520 for ; Tue, 11 May 2004 12:59:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNaSn-00037K-Uo for sip-archive@odin.ietf.org; Tue, 11 May 2004 12:50:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BGofnf011983 for sip-archive@odin.ietf.org; Tue, 11 May 2004 12:50:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNaDi-00088f-A2; Tue, 11 May 2004 12:35:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNa6p-0006pP-6b for sip@optimus.ietf.org; Tue, 11 May 2004 12:27:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06776 for ; Tue, 11 May 2004 12:27:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNa6n-0000s7-He for sip@ietf.org; Tue, 11 May 2004 12:27:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNa5t-0000SY-00 for sip@ietf.org; Tue, 11 May 2004 12:27:02 -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 1BNa50-0007QX-00 for sip@ietf.org; Tue, 11 May 2004 12:26:06 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 11 May 2004 08:31:30 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4BGPXC1004701; Tue, 11 May 2004 09:25:34 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIJ23956; Tue, 11 May 2004 12:25:32 -0400 (EDT) Message-ID: <40A0FE7C.5020808@cisco.com> Date: Tue, 11 May 2004 12:25:32 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sarit Galanos CC: sip@ietf.org, Jonathan Rosenberg Subject: Re: [Sip] Session Timer - Terminology is no clear References: <10DA2C035FE3BC4FA8D73EC55FC43D9B047A76@rvil-mail.radvision.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 Sarit Galanos wrote: > Hi Paul, > Thanks for you answer. >>From your answer I understand that 7.1 talks about the first time the UAC tries to set a session timer > (in an initial dialog or an established dialog), and 7.4 defines the behavior of the UAC incase the request > was rejected with 422. > Further refreshes are identical to the initial refresh. > > I'm still not clear about the relationship between the Session Expires and the Min SE. Is it clear that the point of having both is to support negotiation of both an upper bound and a lower bound on the refresh interval? The upper bound is needed for the session timer to be useful. (An infinite bound is like no session timer.) Different servers along the path may vary in their needs. The lower bound is there to bound the load placed on all the nodes involved, in generating/processing all the messaging generated. > Lets say a UAC wants to set them both. Why would the UAC want to set the Session-Expires value? There is no real reason why it should. The value is for the benefit of proxies along the path, not the UAC. But while there is no good reason for the UAC to set it, there is no good reason to forbid it either. > According to 7.1: > "If a Min-SE header is included > in the initial session refresh request, the value of the > Session-Expires MUST be equal to the value in Min-SE." I don't really understand why this restriction is here. > Proxies on the way must follow the following rule regarding the Session Expires: > > "Any proxy servicing this request can lower this > value, but is not allowed to decrease it below the value specified in > the Min-SE header field." > > But then how can a proxy lower the Min-SE if it is always equal to the Session Expires? Well, obviously if the UAC set the value according to the above rule, then there is no negotiation. The value is fully determined by the UAC and nobody else along the path has any say in it, other than to refuse the request. > And when both Session Expires and Min-SE will be present but will include different values? The most reasonable use case is for the UAC to include Supported:timer, and optionally (if it wants to avoid being overloaded) a Min-SE value. But *don't* include a Session-Expires header. Then, *if* at least one proxy along the path needs a session timer, the first one will insert the Session-Expires header, and others that care can adjust it (down). Done this way, the values are negotiated among those who care, and no timer is established if nobody needs one. Paul > Thanks for you help, > Sarit. > > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, May 05, 2004 5:57 PM > To: Sarit Galanos > Cc: sip@ietf.org; Jonathan Rosenberg > Subject: Re: [Sip] Session Timer - Terminology is no clear > > > Sarit, > > I just went back and reread the text. I agree it is confusing. > > Stepping back a moment, lets look at what kind of session refresh > requests can be either INVITE or UPDATE. INVITE could also be > establishing a dialog, or it could be within an existing dialog. UPDATE > can only be within an existing dialog. > > (I note that this draft is now behind the times in that it doesn't > address other dialog establishing requests. It would make perfect sense > to want to use session timer within a dialog established with a > SUBSCRIBE. But that is a subject for another time.) > > Session timers intimately connected to dialogs. But some of the action > may happen before a dialog is established. The behavior before and after > a dialog is established is intertwined in the text. It is probably worth > looking at separately: > > Suppose the UAC is sending a new INVITE that will hopefully establish a > dialog. And the UAC wants to use session timer, so it inserts a > Supported: timer. It may also insert Session-Expires and/or Min-SE. > > This could fail with a 422, indicating that the Session-Expires inserted > by the UAC or some proxy on the path was too small for the UAS or some > proxy on the path. > > This clearly doesn't affect dialog state, because there isn't any dialog > yet. So it can only affect pending call state in the UAC - altering how > further attempts to establish the call are done. > > The invite could have forked, and some other fork could have succeeded. > In that case this is moot. But if all the forks fail, then the UAC may > attempt to recover, retrying the invite. To have this try come out > differently, it follows 7.4 and inserts a Min-SE that is the max of all > those it received in 422 responses. The UAC may also include a > Session-Expires in the retry, constrained by the Min-SE value. > Presumably it would do this iff it had included one in the initial request. > > Doing that ensures that proxies along all fork paths will use > Session-Expires values large enough to be acceptable to all candidate > forked UASs, so that there should be no 422 responses on the 2nd try. Of > course there may be other problems, but eventually this will hopefully > result in one or more responses that establish dialogs. And each dialog > then may or may not have a session timer in operation according to the > response. Each dialog is then an independent entity for purposes of > session timer. > > It is possible that a dialog would be established without a session > timer, and then later, an initial session refresh could be sent within > the dialog. That isn't a very interesting case, so I will ignore it for now. > > Once in a dialog with a session timer, one of the participants might > send an INVITE or UPDATE. This could be because the time to refresh the > session timer has come, or it could be for some entirely unrelated > reason. It doesn't matter, because the rules must be followed if the > message is sent, regardless of reason. > > Parts of 7.4 apply to this case. The key requirement here has to do with > Min-SE: > > The value of the Min-SE header field present in a session refresh > request MUST be the largest value amongst all Min-SE header field > values ... received in session refresh > requests, on the same dialog, if a dialog has been established. > ... > A result of this rule is that the maximum value of the Min-SE is > effectively 'cleared' once the dialog is established, and from that > point on, only the values from proxies known to be on the proxy path > will end up being used. > > The point here is that the Min-SE in the initial request might have been > larger than necessary due to the needs of servers on forks not taken. > Now that a dialog has been established, the goal is to constrain the > session-expires value only by the needs of the currently involved parties. > > In the simple case where there was no forking, and the initial request > succeeded in establishing a dialog, the Min-SE value used in the > "subsequent session refresh request" would normally be the same value > received in the response to the initial session refresh request. > > The rules about the relationship of the Session-Expires to the Min-SE > are a separate story. The UAC is never required to insert a > Session-Expires at all. The session timer mechanism is really for the > benefit of the proxies along the path rather than the UAC and UAS. (The > UAC and UAS are free to send INVITE or UPDATE any time they want to test > the liveness of the other end. They don't need session timer for this.) > So there is no particular benefit in the UAC providing a value other > than to express a preference as the refresher or not. So in general it > would be silly for a UAC to insert a Session-Expires into an initial > session refresh request. > > Once a session timer has been established, it will presumably be a > normal case to want to preserve it for the life of the dialog, even as > other things change in the dialog. > > I really don't know why 7.4 says the UAC SHOULD include Session-Expires. > If it just included Min-SE the right thing would happen, and other > options would be preserved for the other participants in the dialog. One > reason to include it is to specify the uac/uas parameter, but the UAS > for the request could handle that. If the Session-Expires header is > included, its syntax requires that delta-time be provided. The > requirement that this equal Min-SE guarantees that the value can't be > altered anywhere in the path. This means that once a time value has been > established it won't ever change. > > Possibly the recommentation to include Session-Expires in this case was > motivated by a desire for the session timer not to be accidentally lost > from the call. But I think a rule on the UAS is sufficient for that. So > I think I would be inclined to violate the SHOULD, and omit the > Session-Expires in this case. > > I may have forgotten something about the rationale here. Maybe Jonathan > will comment on this. > > Paul > > Sarit Galanos wrote: > >>Hi Paul, >>Thanks for you answer. >>I'm still not clear about the following: >>The draft includes two different sections: >>7.1 Generating an Initial Session Refresh Request >>7.4 Generating Subsequent Session Refresh Requests >>Each section includes different rules regarding the session timer. >>When should I apply the behavior of 7.1 and when should I use 7.4? >> >>Thanks, >>Sarit. >> >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: Monday, May 03, 2004 5:06 PM >>To: Sarit Galanos >>Cc: sip@ietf.org >>Subject: Re: [Sip] Session Timer - Terminology is no clear >> >> >>The language in this is at times obscure. I think in part this results >>from the age of the document. (It has been in progress for years, I >>think since before 2543bis. So terminology has changed around it.) >> >>Part of the problem is that it is written as if a reINVITE or UPDATE is >>done solely for the purpose of session timer refresh. But in reality >>things are not that simple. >> >>A reINVITE or an UPDATE does a bunch of stuff. If session-timer is >>supported then refreshing, or cancelling, a session timer is one of the >>things it does. Any time a reINVITE or UPDATE is sent, it will affect >>the session timer one way or another, whether that was the primary >>intent in sending the message, or not. >> >>There also isn't anything special about the "first" refresh. The request >>that first establishes a dialog also establishes some kind of session >>timer state - either leaving it disabled, or running. Every subsequent >>reINVITE, UPDATE (and reSUBSCRIBE too) does the same thing - >>restablishes a new session timer or else leaves the dialog with none. >>There is no need to consider what the previous state was - the new state >>is not affected by that. >> >>All that the session timer mechanism does is force a reINVITE or UPDATE >>to happen by a particular time if one hasn't happened for any other reason. >> >> Paul >> >>Sarit Galanos wrote: >> >> >>>Hi, >>>The session timer draft uses the term "Initial Session Refresh Request". >>> >>>The draft defines that >>> "Session Refresh Request: An INVITE or UPDATE request within a dialog." >>> >>>>From that I understand that "Initial Session Refresh Request" is the first re-Invite or Update inside that dialog. >>> >>>But, If the dialog was established with session timer parameters and after the first INVITE-200-ACK session time is already active, >>>why is there a difference between the initial refresh and further refreshes. >>>Or is that the "Initial Session Refresh Request" is the first request that has session timer parameters >>>and it can also be the initial INVITE? >>> >>>Thanks, >>>Sarit >>> >>> >>> >>> >>>_______________________________________________ >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>This list is for NEW development of the core SIP 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 May 11 21:14:56 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11737 for ; Tue, 11 May 2004 21:14: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 1BNiG7-0003Zi-If for sip-archive@odin.ietf.org; Tue, 11 May 2004 21:10:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C1A794013734 for sip-archive@odin.ietf.org; Tue, 11 May 2004 21:10:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNi7K-0001Kb-RH; Tue, 11 May 2004 21:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNi04-0000I2-LW for sip@optimus.ietf.org; Tue, 11 May 2004 20:53: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 UAA10843 for ; Tue, 11 May 2004 20:53:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNi02-0005kn-8D for sip@ietf.org; Tue, 11 May 2004 20:53:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNhz5-0005Iu-00 for sip@ietf.org; Tue, 11 May 2004 20:52:31 -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 1BNhyB-0004RJ-00 for sip@ietf.org; Tue, 11 May 2004 20:51:35 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 11 May 2004 16:57:03 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i4C0p3Su029652; Tue, 11 May 2004 17:51:04 -0700 (PDT) Received: from [24.234.192.148] (sjc-vpn1-218.cisco.com [10.21.96.218]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AOW10724; Tue, 11 May 2004 17:51:02 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Tue, 11 May 2004 11:59:20 -0700 Subject: Re: [Sip] Propogating URI parameters end to end From: Cullen Jennings To: , Manjunath S Bangalore CC: , , Paul H Kyzivat Message-ID: In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797A9B@esebe019.ntc.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit It's an interesting thing. In the case of the netann draft, and some other things, we as the WG seem to take the opinion that SIP can do service invocation and the way to pass parameters to the services is using URL parameters. New headers for specific services have been discouraged. I actually think this is a pretty good idea. Yet here we have a clear problem with doing service invocation using the request URI. I don't see any harm of in fixing this. I think I would be in favor of suggesting that, unless a proxy has a reason to remove parameters in a retarget, it should leave them alone. Alternatively, we could take the position that parameters should not be used, we should get rid of them and use headers instead. But we should pick one of the other not block both either from happening. Cullen On 5/11/04 12:30 AM, "hisham.khartabil@nokia.com" wrote: > A new header, or ever better, a body part would be more appropriate, IMO, to > propagate peer-to-peer specific indicators. > > Regards, > Hisham > >> -----Original Message----- >> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext >> Paul Kyzivat >> Sent: 11.May.2004 01:10 >> To: Manjunath Bangalore >> Cc: sip@ietf.org; Prabhu, Prashanth >> Subject: Re: [Sip] Propogating URI parameters end to end >> >> >> Manjax, >> >> Yes, this came up regarding the handling of GRUU. As things >> stand with >> 3261, you can't expect the parameters to be propagated. Extra >> requirements were added to the GRUU draft to ensure that the grid >> parameter is propagated. >> >> I suppose a change could be made to 3261 to require propagating >> parameters in general, but it isn't entirely clear that this would >> always be the right thing to do. It is also not always >> possible, because >> the contacts that the proxy translates to needn't be sip >> URIs. For other >> kinds there is no guarantee that parameters are supported at >> all, or if >> so that propagating sip uri parameters would be the right thing to do. >> >> This is one of the problems I have with using a uri parameter for >> referencing uri lists in the exploder drafts. >> >> I am inclined to leave things as they are - assuming that the >> parameter >> must have meaning to the owner of the address it is attached >> to. If the >> meaning of one or more parameters extends to propagating them to some >> derived address then fine, but that isn't a general mechanism. >> >> Paul >> >> Manjunath Bangalore wrote: >>> Hi, >>> >>> Consider a case where a SIP UA initiates a request (Ex: INVITE), >>> wherein the Request URI contains some user-defined URI >> parameters that >>> are to meant to be understood by the eventual UA >> terminating the request >>> - Example: >>> >>> INVITE callee@targetdomain.com; end_user_param=foo >>> >>> How do we ensure that the user-defined URI parameter >> accompanying the >>> Request-URI is propogated to the terminating UA? >>> >>> With a read of RFC 3261, I see in Sec 16.5, that when the >> request lands >>> on the Proxy that is responsible for the domain in the >> Request-URI, one >>> of the ways it can generate a target set is by doing a >> lookup using a >>> Location Service, Ex: A SIP Registrar. Before a lookup is done, the >>> Request-URI is required to be canonicalized, and during >> this process, >>> any URI parameters are dropped when contructing an index >> for the lookup. >>> While this canonicalization makes sense for the purpose of >> the location >>> service lookup, before the INVITE is forwarded to the URI >> returned by >>> the Location service, wouldn't it be right to append the >> original URI >>> parameters to it, in order to preserve them. >>> >>> On a related note, the GRUU draft requires a Proxy in a >> target domain to >>> pass the "grid" URI parameter(grid=foo) that is received >> alongside the >>> Request-URI. >>> >>> Unless I am missing something, are there any issues with adding a >>> statement to RFC 3261, that explicitly states that any URI >> parameters >>> present in the Request-URI must be forwarded. >>> >>> Thanks, >>> -Manjax >>> >>> >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed May 12 02:19:42 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15163 for ; Wed, 12 May 2004 02:19: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 1BNmyD-0003SG-TA for sip-archive@odin.ietf.org; Wed, 12 May 2004 02:12:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C6BvNI013112 for sip-archive@odin.ietf.org; Wed, 12 May 2004 02:11:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNmoi-0007Df-5O; Wed, 12 May 2004 02:02:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNmkK-0005es-TS for sip@optimus.ietf.org; Wed, 12 May 2004 01:57: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 BAA23414 for ; Wed, 12 May 2004 01:57:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNmkH-0005su-JA for sip@ietf.org; Wed, 12 May 2004 01:57:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNmjR-0005Sk-00 for sip@ietf.org; Wed, 12 May 2004 01:56:41 -0400 Received: from thymine29.gprs.suomen2g.fi ([62.78.126.29] helo=localhost) by ietf-mx with esmtp (Exim 4.12) id 1BNmir-0004oV-00 for sip@ietf.org; Wed, 12 May 2004 01:56:08 -0400 Received: from jh by localhost with local (Exim 3.35 #1 (Debian)) id 1BNmhD-0000FE-00; Wed, 12 May 2004 08:54:23 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16545.48143.520109.392753@tutpro.com> Date: Wed, 12 May 2004 08:54:23 +0300 To: Cullen Jennings Cc: , Manjunath S Bangalore , , , Paul H Kyzivat Subject: Re: [Sip] Propogating URI parameters end to end In-Reply-To: References: <2038BCC78B1AD641891A0D1AE133DBB701797A9B@esebe019.ntc.nokia.com> X-Mailer: VM 7.17 under Emacs 21.2.1 From: Juha Heinanen X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Cullen Jennings writes: > Alternatively, we could take the position that parameters should not be > used, we should get rid of them and use headers instead. But we should pick > one of the other not block both either from happening. request uri is used for the purpose of routing the request. any parameters that don't aid for that purpose should not be included in request uri. also, as long as all routing related information possibly needed by the next hop is preserved, proxies should be allowed to rewrite the whole request uri. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed May 12 02:35:44 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07133 for ; Wed, 12 May 2004 02:35: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 1BNnCh-0000cn-Ny for sip-archive@odin.ietf.org; Wed, 12 May 2004 02:26:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C6Qtj0002333 for sip-archive@odin.ietf.org; Wed, 12 May 2004 02:26:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNn67-0006Xn-TO; Wed, 12 May 2004 02:20:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNmzm-0004Bz-9l for sip@optimus.ietf.org; Wed, 12 May 2004 02:13: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 CAA07379 for ; Wed, 12 May 2004 02:13:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNmzi-000596-Kz for sip@ietf.org; Wed, 12 May 2004 02:13:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNmyj-0004i8-00 for sip@ietf.org; Wed, 12 May 2004 02:12:29 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BNmxa-0003r9-00 for sip@ietf.org; Wed, 12 May 2004 02:11:18 -0400 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i4C6B8us029384; Wed, 12 May 2004 02:11:08 -0400 (EDT) Message-ID: <40A1BFDC.2020604@dynamicsoft.com> Date: Wed, 12 May 2004 02:10:36 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ervin.Beres@nokia.com CC: sip@ietf.org Subject: Re: [Sip] Caller-Preferences: "no-fork" directive and addresses with equal q-value References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Ervin.Beres@nokia.com wrote: > Hello, > > I've looked to the Draft(/RFC) but could not really figure out > how a server is supposed to work when it receives a request > with "no-fork" but it has addresses with equal q value. In this case it would be a matter of local policy. Pick one. > I mean > in what cases can it happen that the server does not accept the > "no-fork" directive and forks the request? Also a matter of local policy; the directive is a suggestion from the user that they prefer the call not to fork. > > Generally, what is the best way for gateway type of UAs to > indicate that no forking should happen as e.g. parallel early > media may confuse the user? Does it have any effect to proxies > supporting caller preferences if Proxy-Require is set to indicate > that pref extension need to be supported? Proxy-Require doesn't guarantee that the directive is honored; it just guarantees that caller preferences is understood. There is no way using caller prefs to fail a request because a proxy decides it wants to fork. -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 May 12 02:59:52 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11481 for ; Wed, 12 May 2004 02:59: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 1BNnUA-0006Fy-43 for sip-archive@odin.ietf.org; Wed, 12 May 2004 02:45:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C6iwF4024037 for sip-archive@odin.ietf.org; Wed, 12 May 2004 02:44:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNnLY-0003Uw-40; Wed, 12 May 2004 02:36:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNnBm-0000OB-DI for sip@optimus.ietf.org; Wed, 12 May 2004 02:25:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24331 for ; Wed, 12 May 2004 02:25:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNnBi-0002ar-K2 for sip@ietf.org; Wed, 12 May 2004 02:25:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNnAf-0002A2-00 for sip@ietf.org; Wed, 12 May 2004 02:24:50 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BNn9p-0001aA-00 for sip@ietf.org; Wed, 12 May 2004 02:23:57 -0400 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i4C6NUus029388; Wed, 12 May 2004 02:23:30 -0400 (EDT) Message-ID: <40A1C2C2.1000101@dynamicsoft.com> Date: Wed, 12 May 2004 02:22:58 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: sip@ietf.org, Manjunath S Bangalore , pprabhu@cisco.com, hisham.khartabil@nokia.com, Paul H Kyzivat Subject: Re: [Sip] Propogating URI parameters end to end References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 URI parameters are, by definition, qualifiers for the uri. As such, the only thing you can know for certain is that the entity which interprets that URI (the one identified by the domain part of the URI) can understand and make sense of the URI parameters. If a server translates the URI and forwards it somewhere totally different, those parameters may not make sense. Its possible that they do make sense to the downstream entity, but such a determination is the responsibility of the owner of the URI - its part of the location service. Its not something the protocol can mandate, unlesss we start defining certain types of resources (as we did in the case of gruu). If you want to convey information to the ultimate recipient, and that information makes sense regardless of who or what the ultimate recipient is, then that information doesnt belong as a URI parameter, it belongs as a header. In the case of service invocation, I believe that the service invocation parmeters are specific to the resource identified in the URI, and so using URI parameters makes some sense. This gives people some heartburn, since they have this model in their head of having a media server use REGISTER to tell a proxy how to route calls to it, and the proxy would drop the URI parameters in such a translation. However, in this case, REGISTER is an entirely inappropriate technique for populating the location service. Rather, the proxy should be provisioned with a mapping that makes sense for the media server, including which URI parameters to retain. -Jonathan R. Cullen Jennings wrote: > It's an interesting thing. In the case of the netann draft, and some other > things, we as the WG seem to take the opinion that SIP can do service > invocation and the way to pass parameters to the services is using URL > parameters. New headers for specific services have been discouraged. > I actually think this is a pretty good idea. > > Yet here we have a clear problem with doing service invocation using the > request URI. I don't see any harm of in fixing this. I think I would be in > favor of suggesting that, unless a proxy has a reason to remove parameters > in a retarget, it should leave them alone. > > Alternatively, we could take the position that parameters should not be > used, we should get rid of them and use headers instead. But we should pick > one of the other not block both either from happening. > > Cullen > > > > On 5/11/04 12:30 AM, "hisham.khartabil@nokia.com" > wrote: > > >>A new header, or ever better, a body part would be more appropriate, IMO, to >>propagate peer-to-peer specific indicators. >> >>Regards, >>Hisham >> >> >>>-----Original Message----- >>>From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext >>>Paul Kyzivat >>>Sent: 11.May.2004 01:10 >>>To: Manjunath Bangalore >>>Cc: sip@ietf.org; Prabhu, Prashanth >>>Subject: Re: [Sip] Propogating URI parameters end to end >>> >>> >>>Manjax, >>> >>>Yes, this came up regarding the handling of GRUU. As things >>>stand with >>>3261, you can't expect the parameters to be propagated. Extra >>>requirements were added to the GRUU draft to ensure that the grid >>>parameter is propagated. >>> >>>I suppose a change could be made to 3261 to require propagating >>>parameters in general, but it isn't entirely clear that this would >>>always be the right thing to do. It is also not always >>>possible, because >>>the contacts that the proxy translates to needn't be sip >>>URIs. For other >>>kinds there is no guarantee that parameters are supported at >>>all, or if >>>so that propagating sip uri parameters would be the right thing to do. >>> >>>This is one of the problems I have with using a uri parameter for >>>referencing uri lists in the exploder drafts. >>> >>>I am inclined to leave things as they are - assuming that the >>>parameter >>>must have meaning to the owner of the address it is attached >>>to. If the >>>meaning of one or more parameters extends to propagating them to some >>>derived address then fine, but that isn't a general mechanism. >>> >>>Paul >>> >>>Manjunath Bangalore wrote: >>> >>>>Hi, >>>> >>>>Consider a case where a SIP UA initiates a request (Ex: INVITE), >>>>wherein the Request URI contains some user-defined URI >>> >>>parameters that >>> >>>>are to meant to be understood by the eventual UA >>> >>>terminating the request >>> >>>>- Example: >>>> >>>>INVITE callee@targetdomain.com; end_user_param=foo >>>> >>>>How do we ensure that the user-defined URI parameter >>> >>>accompanying the >>> >>>>Request-URI is propogated to the terminating UA? >>>> >>>>With a read of RFC 3261, I see in Sec 16.5, that when the >>> >>>request lands >>> >>>>on the Proxy that is responsible for the domain in the >>> >>>Request-URI, one >>> >>>>of the ways it can generate a target set is by doing a >>> >>>lookup using a >>> >>>>Location Service, Ex: A SIP Registrar. Before a lookup is done, the >>>>Request-URI is required to be canonicalized, and during >>> >>>this process, >>> >>>>any URI parameters are dropped when contructing an index >>> >>>for the lookup. >>> >>>>While this canonicalization makes sense for the purpose of >>> >>>the location >>> >>>>service lookup, before the INVITE is forwarded to the URI >>> >>>returned by >>> >>>>the Location service, wouldn't it be right to append the >>> >>>original URI >>> >>>>parameters to it, in order to preserve them. >>>> >>>>On a related note, the GRUU draft requires a Proxy in a >>> >>>target domain to >>> >>>>pass the "grid" URI parameter(grid=foo) that is received >>> >>>alongside the >>> >>>>Request-URI. >>>> >>>>Unless I am missing something, are there any issues with adding a >>>>statement to RFC 3261, that explicitly states that any URI >>> >>>parameters >>> >>>>present in the Request-URI must be forwarded. >>>> >>>>Thanks, >>>>-Manjax >>>> >>>> >>>> >>>> >>>>_______________________________________________ >>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>This list is for NEW development of the core SIP Protocol >>>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>>Use sipping@ietf.org for new developments on the application of sip >>>> >>> >>> >>>_______________________________________________ >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>This list is for NEW development of the core SIP Protocol >>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>Use sipping@ietf.org for new developments on the application of sip >>> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 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 May 12 03:01:51 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11616 for ; Wed, 12 May 2004 03:01: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 1BNngc-0000mh-5e for sip-archive@odin.ietf.org; Wed, 12 May 2004 02:57:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C6voDM002947 for sip-archive@odin.ietf.org; Wed, 12 May 2004 02:57:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNnMV-0003nd-3j; Wed, 12 May 2004 02:37:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNnKf-00035r-J1 for sip@optimus.ietf.org; Wed, 12 May 2004 02:35: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 CAA06363 for ; Wed, 12 May 2004 02:35:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNnKb-0007B4-TR for sip@ietf.org; Wed, 12 May 2004 02:35:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNnIm-0006DC-00 for sip@ietf.org; Wed, 12 May 2004 02:33:12 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BNnHh-0005Nw-00 for sip@ietf.org; Wed, 12 May 2004 02:32:05 -0400 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i4C6Vtus029400 for ; Wed, 12 May 2004 02:31:55 -0400 (EDT) Message-ID: <40A1C4BB.6010403@dynamicsoft.com> Date: Wed, 12 May 2004 02:31:23 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] GRUU issue 1: no instance ID Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org 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 received a private request for a feature addition to gruu which requires discussion. The request was that it be possible for the gruu mechanism to work without instance IDs. In such a case, the gruu would be bound to the registered contact for the duration of its registration. This is identical to the way gruu worked in previous revisions of the draft. I am reluctant to have two separate mechanisms in the gruu specification. However, there is a way to achieve this effect. The approach is to have the client provide an isntance ID, but instead of using a long-lived instance ID for the UA, the instance ID equals the contact URI. If the client does this, the gruu will have the property of routing to that particular contact, and be defined for the duration that the contact is registered. Such an approach requires that the phone generate unique Contacts. A large random number will do, I *think*. Do people think its worth adding text to describe this option for creating an instance ID? 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 May 12 03:15:22 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12506 for ; Wed, 12 May 2004 03:15:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNnry-0004uj-Gp for sip-archive@odin.ietf.org; Wed, 12 May 2004 03:09:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C79Y4h018880 for sip-archive@odin.ietf.org; Wed, 12 May 2004 03:09:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNnio-0001mo-B9; Wed, 12 May 2004 03:00:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNnOB-0004hf-LW for sip@optimus.ietf.org; Wed, 12 May 2004 02:38:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10125 for ; Wed, 12 May 2004 02:38:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNnO7-0001La-8V for sip@ietf.org; Wed, 12 May 2004 02:38:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNnNP-0000u6-00 for sip@ietf.org; Wed, 12 May 2004 02:37:59 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BNnMb-0000EF-00 for sip@ietf.org; Wed, 12 May 2004 02:37:09 -0400 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i4C6b0us029404 for ; Wed, 12 May 2004 02:37:00 -0400 (EDT) Message-ID: <40A1C5EC.7080403@dynamicsoft.com> Date: Wed, 12 May 2004 02:36:28 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] GRUU issue 2: providing a gruu to the server Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I received a private email suggesting a feature be added to the gruu spec, which I believe requires discussion. The suggestion is that it should be possible for the client to suggest a gruu to the server in a contact. The motivation that was given was to deal with failures in a proxy server - the client could effectively help in persistence of the gruu across failures. We have, in fact, discussed this in the past, and decided NOT to do it. It introduces a lot of complexity. What happens if the suggested gruu exists in the server? Can there be race conditions where different servers in a cluster receive registrations for the same instance ID but different gruu (I believe this can happen)? I think its really fundamental that a gruu be generated and provided by the server only. In the case of a proxy failure, if you don't compute the gruu algorithmically, you will be required to store the instance ID to gruu mapping. This mapping would need to be replicated to backup servers for availability purposes. I dont see that as a big deal. Many of the carrier grade SIP servers I know of already replicate registration data, and so this isnt introducing any new burden on the server. As such, I would like to keep what we have today. Comments? -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 May 12 03:15:43 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12533 for ; Wed, 12 May 2004 03:15: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 1BNnsw-0005Ir-O9 for sip-archive@odin.ietf.org; Wed, 12 May 2004 03:10:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C7AYj9020319 for sip-archive@odin.ietf.org; Wed, 12 May 2004 03:10:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNnj0-0001qQ-Ow; Wed, 12 May 2004 03:00:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNnT8-000615-EV for sip@optimus.ietf.org; Wed, 12 May 2004 02:43:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10452 for ; Wed, 12 May 2004 02:43:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNnT4-0003bY-M9 for sip@ietf.org; Wed, 12 May 2004 02:43:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNnS3-00038r-00 for sip@ietf.org; Wed, 12 May 2004 02:42:47 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BNnRS-0002g5-00 for sip@ietf.org; Wed, 12 May 2004 02:42:10 -0400 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i4C6g0us029407 for ; Wed, 12 May 2004 02:42:00 -0400 (EDT) Message-ID: <40A1C718.5090907@dynamicsoft.com> Date: Wed, 12 May 2004 02:41:28 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] GRUU issue 3: big gruu's Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org 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 Currently, the spec suggests an algorithm for using AES encryption to generate a GRUU algorithmically, and to store the mapping from the gruu to the instance iD/AOR within the encrypted GRUU. This works, but results in really long GRUUs - 129 characters, in fact. This was seen as an issue for wireless. I'll note that, with a stateful sigcomp implementation, it would be compressed out after being sent once, since it won't change for a particular UA. Note that this algorithm for computing the gruu is nor mandatory - its an implementation suggestion. However, given the large gruus is produces, do people have heartburn with the mechanism? If so, does anyone have a better idea? 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 May 12 03:59:26 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14855 for ; Wed, 12 May 2004 03:59:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNoW6-0006t1-RK for sip-archive@odin.ietf.org; Wed, 12 May 2004 03:51:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C7p2LG026343 for sip-archive@odin.ietf.org; Wed, 12 May 2004 03:51:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNoOQ-0004qp-7Z; Wed, 12 May 2004 03:43:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNoLf-0004DK-EH for sip@optimus.ietf.org; Wed, 12 May 2004 03:40: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 DAA13679 for ; Wed, 12 May 2004 03:40:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNoLd-0006uz-0P for sip@ietf.org; Wed, 12 May 2004 03:40:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNoKO-0006Kj-00 for sip@ietf.org; Wed, 12 May 2004 03:38:57 -0400 Received: from natnoddy.rzone.de ([81.169.145.166]) by ietf-mx with esmtp (Exim 4.12) id 1BNoJM-0005mD-00 for sip@ietf.org; Wed, 12 May 2004 03:37:52 -0400 Received: from sip (pD9E79675.dip.t-dialin.net [217.231.150.117]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i4C7bJWd004925; Wed, 12 May 2004 09:37:19 +0200 (MEST) From: "Christian Stredicke" To: "'Jonathan Rosenberg'" , Subject: RE: [Sip] GRUU issue 3: big gruu's Date: Wed, 12 May 2004 09:37:06 +0200 Message-ID: <06f001c437f3$f65b5da0$0b01a8c0@sip> 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 In-Reply-To: <40A1C718.5090907@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Of course, you can always take only a piece of the encrypted string and = code it more efficiently than with hex numbers. These encryption algorithms should generate evenly distributed probabilities across all bits so that this approach is valid, even if it reduces the security. I personally think that a 20-character string like "3Hf4hJji04fh6yDfd3" which gives roughly 120 bits of security should practically be pretty = much ok. CS > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of = Jonathan > Rosenberg > Sent: Wednesday, May 12, 2004 8:41 AM > To: sip@ietf.org > Subject: [Sip] GRUU issue 3: big gruu's >=20 > Currently, the spec suggests an algorithm for using AES encryption to > generate a GRUU algorithmically, and to store the mapping from the = gruu > to the instance iD/AOR within the encrypted GRUU. This works, but > results in really long GRUUs - 129 characters, in fact. This was seen = as > an issue for wireless. I'll note that, with a stateful sigcomp > implementation, it would be compressed out after being sent once, = since > it won't change for a particular UA. >=20 > Note that this algorithm for computing the gruu is nor mandatory - its > an implementation suggestion. However, given the large gruus is > produces, do people have heartburn with the mechanism? If so, does > anyone have a better idea? >=20 > 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 >=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 May 12 08:35:16 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28160 for ; Wed, 12 May 2004 08:35: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 1BNstX-0006Ws-DP for sip-archive@odin.ietf.org; Wed, 12 May 2004 08:31:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CCVV0R025099 for sip-archive@odin.ietf.org; Wed, 12 May 2004 08:31:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNsmI-00053E-QA; Wed, 12 May 2004 08:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNskN-0004jI-Mv for sip@optimus.ietf.org; Wed, 12 May 2004 08:22:03 -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 IAA27635 for ; Wed, 12 May 2004 08:22:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNskM-0003R7-Fj for sip@ietf.org; Wed, 12 May 2004 08:22:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNsjW-0002ut-00 for sip@ietf.org; Wed, 12 May 2004 08:21:11 -0400 Received: from mtagate5.de.ibm.com ([195.212.29.154]) by ietf-mx with esmtp (Exim 4.12) id 1BNsig-00025h-00 for sip@ietf.org; Wed, 12 May 2004 08:20:19 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.12.10/8.12.10) with ESMTP id i4CCJZYO078942; Wed, 12 May 2004 12:19:35 GMT Received: from d12ml102.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i4CCIJaO155302; Wed, 12 May 2004 14:18:19 +0200 In-Reply-To: <40A1C5EC.7080403@dynamicsoft.com> To: Jonathan Rosenberg Cc: sip@ietf.org MIME-Version: 1.0 Subject: Re: [Sip] GRUU issue 2: providing a gruu to the server X-Mailer: Lotus Notes Build V65_07292003 July 29, 2003 Message-ID: From: Avshalom Houri Date: Wed, 12 May 2004 15:18:15 +0300 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.0.2CF2|July 23, 2003) at 12/05/2004 15:18:19, Serialize complete at 12/05/2004 15:18:19 Content-Type: multipart/alternative; boundary="=_alternative 00439620C2256E92_=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 00439620C2256E92_= Content-Type: text/plain; charset="US-ASCII" Agree that is should remain in the server only. It is too complex to enable clients to suggest a gruu. In addition to the issues that you mention how can the server verify that the gruu belongs to the claiming client? Avshalom Jonathan Rosenberg Sent by: sip-admin@ietf.org 12/05/2004 09:36 AM To sip@ietf.org cc Subject [Sip] GRUU issue 2: providing a gruu to the server I received a private email suggesting a feature be added to the gruu spec, which I believe requires discussion. The suggestion is that it should be possible for the client to suggest a gruu to the server in a contact. The motivation that was given was to deal with failures in a proxy server - the client could effectively help in persistence of the gruu across failures. We have, in fact, discussed this in the past, and decided NOT to do it. It introduces a lot of complexity. What happens if the suggested gruu exists in the server? Can there be race conditions where different servers in a cluster receive registrations for the same instance ID but different gruu (I believe this can happen)? I think its really fundamental that a gruu be generated and provided by the server only. In the case of a proxy failure, if you don't compute the gruu algorithmically, you will be required to store the instance ID to gruu mapping. This mapping would need to be replicated to backup servers for availability purposes. I dont see that as a big deal. Many of the carrier grade SIP servers I know of already replicate registration data, and so this isnt introducing any new burden on the server. As such, I would like to keep what we have today. Comments? -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 --=_alternative 00439620C2256E92_= Content-Type: text/html; charset="US-ASCII"
Agree that is should remain in the server only. It is too complex to enable clients to suggest a gruu.
In addition to the issues that you mention how can the server verify that the gruu belongs to the claiming client?

Avshalom





Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Sent by: sip-admin@ietf.org

12/05/2004 09:36 AM

To
sip@ietf.org
cc
Subject
[Sip] GRUU issue 2: providing a gruu to the server





I received a private email suggesting a feature be added to the gruu
spec, which I believe requires discussion.

The suggestion is that it should be possible for the client to suggest a
gruu to the server in a contact. The motivation that was given was to
deal with failures in a proxy server - the client could effectively help
in persistence of the gruu across failures.

We have, in fact, discussed this in the past, and decided NOT to do it.
It introduces a lot of complexity. What happens if the suggested gruu
exists in the server? Can there be race conditions where different
servers in a cluster receive registrations for the same instance ID but
different gruu (I believe this can happen)?

I think its really fundamental that a gruu be generated and provided by
the server only.

In the case of a proxy failure, if you don't compute the gruu
algorithmically, you will be required to store the instance ID to gruu
mapping. This mapping would need to be replicated to backup servers for
availability purposes. I dont see that as a big deal. Many of the
carrier grade SIP servers I know of already replicate registration data,
and so this isnt introducing any new burden on the server.

As such, I would like to keep what we have today.

Comments?

-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
--=_alternative 00439620C2256E92_=-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 12 12:21:43 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22968 for ; Wed, 12 May 2004 12:21: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 1BNw8u-0008Vw-Ox for sip-archive@odin.ietf.org; Wed, 12 May 2004 11:59:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CFxaqB032729 for sip-archive@odin.ietf.org; Wed, 12 May 2004 11:59:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNvPH-0003cF-U4; Wed, 12 May 2004 11:12:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNuVF-0004Gv-29 for sip@optimus.ietf.org; Wed, 12 May 2004 10:14:33 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06993; Wed, 12 May 2004 10:14:29 -0400 (EDT) Message-Id: <200405121414.KAA06993@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: sip@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 12 May 2004 10:14:29 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-authid-body-03.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : SIP Authenticated Identity Body (AIB) Format Author(s) : J. Peterson Filename : draft-ietf-sip-authid-body-03.txt Pages : 13 Date : 2004-5-6 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-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-authid-body-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-authid-body-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-5-12103652.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-authid-body-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-authid-body-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-12103652.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 May 12 12:29:24 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23398 for ; Wed, 12 May 2004 12:29:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNwGi-00048W-Rq for sip-archive@odin.ietf.org; Wed, 12 May 2004 12:07:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CG7e8Y015898 for sip-archive@odin.ietf.org; Wed, 12 May 2004 12:07:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNvYx-00086U-Rv; Wed, 12 May 2004 11:22:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNvJ9-0008At-8l for sip@optimus.ietf.org; Wed, 12 May 2004 11:06: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 LAA14286 for ; Wed, 12 May 2004 11:06:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNvJ6-0005LF-Mq for sip@ietf.org; Wed, 12 May 2004 11:06:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNvFA-0003mr-00 for sip@ietf.org; Wed, 12 May 2004 11:02:01 -0400 Received: from [80.74.106.125] (helo=rvil-mail.RADVISION.com) by ietf-mx with esmtp (Exim 4.12) id 1BNvBP-00026L-00 for sip@ietf.org; Wed, 12 May 2004 10:58:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] changes in session timer Date: Wed, 12 May 2004 17:59:50 +0300 Message-ID: <707E78BD6DA3054AAE4362314A57568233EF66@rvil-mail.radvision.com> Thread-Topic: [Sip] changes in session timer Thread-Index: AcP7Y0mHlC9Z32auQQiyi8bKLRpe3g8zgcRg From: "Asher Shiratzky" To: "Jonathan Rosenberg" , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Jonathan, Still the latest session-timer draft you mention does not appears in the relevant places. What is the formal status of the 14th version? Thanks, Asher Shiratzky -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Wednesday, February 25, 2004 7:45 AM To: sip@ietf.org Subject: [Sip] changes in session timer Folks, I submitted a revision of the session timer, based on comments received=20 from IESG and subsequent list discussion. For some reason, this=20 submission was not processed by the I-D editor (I'm working to correct=20 that). In the mean time, you can pick it up at: http://www.jdrosen.net/papers/draft-ietf-sip-session-timer-14.txt There are a few significant changes: * Formerly, if a session refresh timed out, the UA waited until 1/3 of=20 the session interval remained before sending a BYE. This contradicts=20 RFC3261 which basically says to send a BYE immediately. Session timer=20 now references that behavior. * There is now an absolute minimum session timer of 90 seconds. This is=20 basically enough time for completion of a SIP BYE transaction after half of the session has expired. The Min-SE header field now has a default=20 value of 90 seconds when not present. This will preclude usage of=20 session timer for really fine grained refreshes, say on the order of 5=20 to 10 seconds. I fear that some people may be trying to do some kind of=20 nat traversal or something with session timer - this would rule that out formally (it was never the intended usage). * The default for session-expires, when not present, used to be=20 "infinity". However, thats not really right. Really, it means=20 "undefined", and session expiration is then up to local policy of the=20 proxy. Using infinity would mean that a proxy could never clean up state. Please comment ASAP if you have any problems with these changes. We'd=20 like to get session timer moving along. -Jonathan R. --=20 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 May 12 16:32:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09346 for ; Wed, 12 May 2004 16:32: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 1BO0KH-0008Ea-HO for sip-archive@odin.ietf.org; Wed, 12 May 2004 16:27:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CKRbxV031648 for sip-archive@odin.ietf.org; Wed, 12 May 2004 16:27:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNzzO-0003LX-5t; Wed, 12 May 2004 16: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 1BNzuC-0001cJ-Pk for sip@optimus.ietf.org; Wed, 12 May 2004 16:00: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 QAA07632 for ; Wed, 12 May 2004 16:00:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNzuB-0003GD-7Q for sip@ietf.org; Wed, 12 May 2004 16:00:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNztC-0002k2-00 for sip@ietf.org; Wed, 12 May 2004 15:59:38 -0400 Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx with esmtp (Exim 4.12) id 1BNzs3-0001ho-00 for sip@ietf.org; Wed, 12 May 2004 15:58:27 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i4CJvpFq009928; Wed, 12 May 2004 14:57:51 -0500 (CDT) Message-ID: <40A281BD.8070107@alcatel.com> Date: Wed, 12 May 2004 14:57:49 -0500 From: Alex Audu Reply-To: alex.audu@alcatel.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] GRUU issue 2: providing a gruu to the server References: <40A1C5EC.7080403@dynamicsoft.com> In-Reply-To: <40A1C5EC.7080403@dynamicsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I agree with leaving things the way they currently are. There are better and well known ways of having a server survive an outage ( including redundancy, and persisting critical data). Regards, Alex. Jonathan Rosenberg wrote: > I received a private email suggesting a feature be added to the gruu > spec, which I believe requires discussion. > > The suggestion is that it should be possible for the client to suggest > a gruu to the server in a contact. The motivation that was given was > to deal with failures in a proxy server - the client could effectively > help in persistence of the gruu across failures. > > We have, in fact, discussed this in the past, and decided NOT to do > it. It introduces a lot of complexity. What happens if the suggested > gruu exists in the server? Can there be race conditions where > different servers in a cluster receive registrations for the same > instance ID but different gruu (I believe this can happen)? > > I think its really fundamental that a gruu be generated and provided > by the server only. > > In the case of a proxy failure, if you don't compute the gruu > algorithmically, you will be required to store the instance ID to gruu > mapping. This mapping would need to be replicated to backup servers > for availability purposes. I dont see that as a big deal. Many of the > carrier grade SIP servers I know of already replicate registration > data, and so this isnt introducing any new burden on the server. > > As such, I would like to keep what we have today. > > Comments? > > -Jonathan R. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Thu May 13 10:23:54 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15372 for ; Thu, 13 May 2004 10:23: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 1BOH59-0001Ll-Hw for sip-archive@odin.ietf.org; Thu, 13 May 2004 10:21:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DEL767005187 for sip-archive@odin.ietf.org; Thu, 13 May 2004 10:21:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOGuR-0005Th-63; Thu, 13 May 2004 10:10:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOGiz-0006qp-HH for sip@optimus.ietf.org; Thu, 13 May 2004 09:58: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 JAA13183 for ; Thu, 13 May 2004 09:58:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOGix-00025k-GC for sip@ietf.org; Thu, 13 May 2004 09:58:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOGi1-0001Ww-00 for sip@ietf.org; Thu, 13 May 2004 09:57:14 -0400 Received: from mail.deccanetworld.com ([203.196.146.50] helo=gatekeeper.deccanetworld.com) by ietf-mx with esmtp (Exim 4.12) id 1BOGhC-0000zO-00 for sip@ietf.org; Thu, 13 May 2004 09:56:27 -0400 Received: from gatekeeper.deccanetworld.com (localhost [127.0.0.1]) by gatekeeper.deccanetworld.com (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id i4DDlm0w032695 for ; Thu, 13 May 2004 19:17:48 +0530 Received: from mail.deccanetworld.com (server.deccanetworld.com [192.168.1.32]) by gatekeeper.deccanetworld.com (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id i4DDll2U032630 for ; Thu, 13 May 2004 19:17:48 +0530 Received: (from root@localhost) by mail.deccanetworld.com (8.11.0/8.11.0) id i4DECL406757 for sip@ietf.org; Thu, 13 May 2004 19:42:21 +0530 Received: from gvvivek (bharathi.software [192.168.1.224] (may be forged)) by mail.deccanetworld.com (8.11.0/8.11.0) with SMTP id i4DECL206715 for ; Thu, 13 May 2004 19:42:21 +0530 Message-ID: <022401c438f2$0acf37d0$e001a8c0@gvvivek> From: "Vishnu Yadav" To: Date: Thu, 13 May 2004 19:26:08 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0221_01C43920.2482B8E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,EXCUSE_16,HTML_MESSAGE autolearn=no version=2.60 Subject: [Sip] sip application server for FAX Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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_0221_01C43920.2482B8E0 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable I am implementing an application server which can distinguish Fax, = Modem, Voice and can passthrough all these. Can u suggest me the = reference docs such as drafts/RFCs if any... Thanx in advance ********************************DISCLAIMER********************************** This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege of Deccanet Designs Ltd. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from retaining, using, copying, altering or disclosing the contents of this message. **************************************************************************** ------=_NextPart_000_0221_01C43920.2482B8E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am implementing an application server = which can=20 distinguish Fax, Modem, Voice and can passthrough all these. Can u = suggest me=20 the reference docs such as drafts/RFCs if any...
Thanx in = advance

********************************DISCLAIMER**********************************

This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege of Deccanet Designs Ltd.
If you have received this message in error, please notify the originator
immediately. If you are not the intended recipient, you are notified that
you are strictly prohibited from retaining, using, copying, altering or
disclosing the contents of this message.

****************************************************************************
------=_NextPart_000_0221_01C43920.2482B8E0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 14 01:50:54 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14441 for ; Fri, 14 May 2004 01:50: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 1BOVYE-0004LH-JQ for sip-archive@odin.ietf.org; Fri, 14 May 2004 01:48:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E5m6i2016630 for sip-archive@odin.ietf.org; Fri, 14 May 2004 01:48:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOVOU-0002bF-Ic; Fri, 14 May 2004 01: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 1BOVMW-0001uU-Rn for sip@optimus.ietf.org; Fri, 14 May 2004 01:36: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 BAA13578 for ; Fri, 14 May 2004 01:35:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOVMT-0000aa-Lw for sip@ietf.org; Fri, 14 May 2004 01:35:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOVKo-0007OQ-00 for sip@ietf.org; Fri, 14 May 2004 01:34:14 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BOVIJ-00060e-00 for sip@ietf.org; Fri, 14 May 2004 01:31:39 -0400 Received: from dynamicsoft.com ([63.113.46.48]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i4E5VRbo001309; Fri, 14 May 2004 01:31:28 -0400 (EDT) Message-ID: <40A4598C.8040205@dynamicsoft.com> Date: Fri, 14 May 2004 01:30:52 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ANTONINI Pierre-Antoine FTRD/DMR/LON CC: sip@ietf.org Subject: Re: [Sip] Subscription to Event packages References: <3418F3471F1CA4409901547349FFAE2E016FA32E@ftrdmel2.rd.francetelecom.fr> In-Reply-To: <3418F3471F1CA4409901547349FFAE2E016FA32E@ftrdmel2.rd.francetelecom.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit It is not allowed. -Jonathan R. ANTONINI Pierre-Antoine FTRD/DMR/LON wrote: > Dear all, > Does anyone know if it is possible to subscribe to different event > packages using only one SIP SUBSCRIBE message? According to the RFC > 3265, I think it is not acceptable but I am just wondering whether we > could have two values in the Event header. > > Many Regards, > > *Pierre-Antoine Antonini* > Telecom Engineer > France Telecom R&D UK Ltd > Chiswick Park, Building 3, > Chiswick High Road, > London W4 5YA > 0044 (0) 2088495864 > mailto: pierreantoine.antonini@rd.francetelecom.com > -- 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 Fri May 14 04:40:28 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07399 for ; Fri, 14 May 2004 04:40:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOYCi-0006fi-UN for sip-archive@odin.ietf.org; Fri, 14 May 2004 04:38:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E8c4i8025580 for sip-archive@odin.ietf.org; Fri, 14 May 2004 04:38:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOY5v-0004rf-DI; Fri, 14 May 2004 04: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 1BN3LA-0006AI-Kr for sip@optimus.ietf.org; Mon, 10 May 2004 01:28: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 BAA10360 for ; Mon, 10 May 2004 01:28:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BN3L7-0000oH-JT for sip@ietf.org; Mon, 10 May 2004 01:28:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN3KB-0000Vz-00 for sip@ietf.org; Mon, 10 May 2004 01:27:35 -0400 Received: from bonn.shuttle.de ([194.95.249.247]) by ietf-mx with esmtp (Exim 4.12) id 1BN3JV-0000DS-00 for sip@ietf.org; Mon, 10 May 2004 01:26:53 -0400 Received: from uranus (p12.b.shuttle.de [194.95.246.12]) by bonn.shuttle.de (Postfix) with ESMTP id 814FF6C1AA for ; Mon, 10 May 2004 07:26:52 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" From: Thomas Ackermann To: sip@ietf.org Subject: [Sip] NOTIFY on call transfer procedure Date: Mon, 10 May 2004 07:02:31 +0200 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200405100702.31928.t.ackermann@cats.mol.shuttle.de> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 all, can anybody tell me why the transfer procedure needs NOTIFY message with application/sipfrag message body? Why not simply keep the REFER transaction open by sending: - a provisional response instead of the 202/Accepted and - a final 200/OK response instead of NOTIFY(200 OK) ? Just like the INVITE transaction with all its intermediate responses. Or even more simple: The Transferee sends the BYE by itself instead of asking the Transferor to terminate the call? Do you know the reason why the NOTIFY transaction has been added to call transfer procedure? Thanks for your help, Thomas _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 14 05:10:30 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08765 for ; Fri, 14 May 2004 05:10: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 1BOYbD-00068J-3c for sip-archive@odin.ietf.org; Fri, 14 May 2004 05:03:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E93Nrc023557 for sip-archive@odin.ietf.org; Fri, 14 May 2004 05:03:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOYW6-0004yw-Lc; Fri, 14 May 2004 04:58:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOYVA-0004iQ-MF for sip@optimus.ietf.org; Fri, 14 May 2004 04:57:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08189 for ; Fri, 14 May 2004 04:57:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOYV7-0000Ml-GW for sip@ietf.org; Fri, 14 May 2004 04:57:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOYTz-0007er-00 for sip@ietf.org; Fri, 14 May 2004 04:55:56 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1BOYT2-00078F-00 for sip@ietf.org; Fri, 14 May 2004 04:54:56 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id i4E8svbj001410 for ; Fri, 14 May 2004 01:54:57 -0700 (MST) Received: from zin09exm01.corp.mot.com (zin09exm01.corp.mot.com [10.232.100.1]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i4E8sqZ4009290 for ; Fri, 14 May 2004 03:54:54 -0500 Received: by zin09exm01.corp.mot.com with Internet Mail Service (5.5.2657.72) id ; Fri, 14 May 2004 14:24:51 +0530 Message-ID: From: Chadha Retesh-A19894 To: Thomas Ackermann , sip@ietf.org Subject: RE: [Sip] NOTIFY on call transfer procedure Date: Fri, 14 May 2004 14:24:50 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , NOTIFY is needed to notify the UA that the media shuffle between 2 parties is successful. 202 reponse to REFER can't be sent after success of media shuffle, since media shuffle can take more than 32 seconds(default transaction timeout value). BYE also doesn't make sense, as it will just signify termination of call, but not if call-transfer was success or not. There can be inconsistent state in this case, if the Transferee terminates the calls while transfer is in progress. Regards Retesh -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Thomas Ackermann Sent: Monday, May 10, 2004 10:33 AM To: sip@ietf.org Subject: [Sip] NOTIFY on call transfer procedure Hi all, can anybody tell me why the transfer procedure needs NOTIFY message with application/sipfrag message body? Why not simply keep the REFER transaction open by sending: - a provisional response instead of the 202/Accepted and - a final 200/OK response instead of NOTIFY(200 OK) ? Just like the INVITE transaction with all its intermediate responses. Or even more simple: The Transferee sends the BYE by itself instead of asking the Transferor to terminate the call? Do you know the reason why the NOTIFY transaction has been added to call transfer procedure? Thanks for your help, Thomas _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 May 17 07:07:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13458 for ; Mon, 17 May 2004 07:07: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 1BPfvl-0001Im-UK for sip-archive@odin.ietf.org; Mon, 17 May 2004 07:05:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HB5DhI004960 for sip-archive@odin.ietf.org; Mon, 17 May 2004 07:05:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPfql-0000cJ-Bp; Mon, 17 May 2004 07: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 1BPfnu-0000Ip-OE for sip@optimus.ietf.org; Mon, 17 May 2004 06:57: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 GAA12995 for ; Mon, 17 May 2004 06:57:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPfnq-0005HU-HF for sip@ietf.org; Mon, 17 May 2004 06:57:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPfn1-0004yB-00 for sip@ietf.org; Mon, 17 May 2004 06:56:11 -0400 Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx with esmtp (Exim 4.12) id 1BPflx-0004eG-00 for sip@ietf.org; Mon, 17 May 2004 06:55:05 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.eng.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id i4HAnJfB009939 for ; Mon, 17 May 2004 06:49:21 -0400 (EDT) Received: by nhmail2.eng.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 May 2004 06:48:03 -0400 Message-ID: From: Eric Burger To: "'sip@ietf.org'" Subject: Re: [Sip] Propogating URI parameter end to end Date: Mon, 17 May 2004 06:48:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , How can a proxy POSSIBLY know what the next proxy's requirements will be? This argument suggests that the proxy MUST retain URI parameters, as the next proxy MIGHT need them. What is the harm in keeping the URI parameters? If it is a security issue or a local proxy-proxy issue, why not put the URI parameters in the To: URI? Juha Heinanen said: Cullen Jennings writes: > Alternatively, we could take the position that parameters should not be > used, we should get rid of them and use headers instead. But we should pick > one of the other not block both either from happening. request uri is used for the purpose of routing the request. any parameters that don't aid for that purpose should not be included in request uri. also, as long as all routing related information possibly needed by the next hop is preserved, proxies should be allowed to rewrite the whole request uri. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon May 17 09:20:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20976 for ; Mon, 17 May 2004 09:20:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPhza-0003Vm-S4 for sip-archive@odin.ietf.org; Mon, 17 May 2004 09:17:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HDHIo1013499 for sip-archive@odin.ietf.org; Mon, 17 May 2004 09:17:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPhrc-0002TH-5D; Mon, 17 May 2004 09:09:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPhjp-00018Z-IU for sip@optimus.ietf.org; Mon, 17 May 2004 09:01: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 JAA20072 for ; Mon, 17 May 2004 09:00:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPhjo-0006f2-2v for sip@ietf.org; Mon, 17 May 2004 09:01:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPhio-0006Im-00 for sip@ietf.org; Mon, 17 May 2004 08:59:59 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BPhhk-0005dU-00 for sip@ietf.org; Mon, 17 May 2004 08:58:52 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 17 May 2004 05:56:54 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i4HCwJjO001071; Mon, 17 May 2004 05:58:19 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIN13244; Mon, 17 May 2004 08:58:17 -0400 (EDT) Message-ID: <40A8B6F0.6060406@cisco.com> Date: Mon, 17 May 2004 08:58:24 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Burger CC: "'sip@ietf.org'" Subject: Re: [Sip] Propogating URI parameter end to end References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 Eric Burger wrote: > How can a proxy POSSIBLY know what the next proxy's requirements will be? > This argument suggests that the proxy MUST retain URI parameters, as the > next proxy MIGHT need them. They are *uri* parameters - they affect the uri, not the *request*. So any automatic transference of them from one uri to another seems wrong. If it is the right thing to do for sip uri parameters, then it ought to be the right thing to do for tel uri parameters too, as in: INVITE tel:12345;phone-context=foo.com => INVITE sip:fred.smith@foo.com;phone-context=foo.com Does that seem right? I don't think so. Also, what happens when going the other way: INVITE sip:john.jones@bar.com;xyzzy=mumble => INVITE tel:+1-321-555-1234;xyzzy=mumble Another thing: is transference limited to *unknown* parameters, or does it apply to parameters that are understood as well? In other contexts things are generally not removed just becasue they are understood - they are left for others who might also care. But that would lead to nonsense like transferring the user=phone parameter. But transferring only the unknown parameters has similar issues. It means that no future uri parameter can be defined unless transferring it would cause no harm, since that is what proxies defined according to the older specs would do. And of course nobody can rely on the parameters being transferred because 3261 compatible proxies don't do that. Request URI parameters are just not a good place to put information that affects the request end-to-end. They are a good place to put information that affect one hop. > What is the harm in keeping the URI parameters? If it is a security issue > or a local proxy-proxy issue, why not put the URI parameters in the To: URI? Then another class of problems will probably arise - people setting up forwarding will want to use parameters in the forwarding address. But then they will need to rewrite the To address. I think a better solution is just to use another header to carry parameters to a server. If you want to define a uri containing parameters that affect requests generated from that uri, then you can use a header parameter: Paul > Juha Heinanen said: > > Cullen Jennings writes: > > > Alternatively, we could take the position that parameters should not be > > used, we should get rid of them and use headers instead. But we should > pick > > one of the other not block both either from happening. > > request uri is used for the purpose of routing the request. any > parameters that don't aid for that purpose should not be included in > request uri. also, as long as all routing related information possibly > needed by the next hop is preserved, proxies should be allowed to > rewrite the whole request uri. > > -- juha > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon May 17 12:34:15 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03496 for ; Mon, 17 May 2004 12:34:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPkuT-0005UA-QQ for sip-archive@odin.ietf.org; Mon, 17 May 2004 12:24:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HGODLv021087 for sip-archive@odin.ietf.org; Mon, 17 May 2004 12:24:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPkcs-0000fW-NI; Mon, 17 May 2004 12: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 1BOddW-0005HQ-OP for sip@optimus.ietf.org; Fri, 14 May 2004 10:26: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 KAA25264 for ; Fri, 14 May 2004 10:26:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOddU-0003Rv-EG for sip@ietf.org; Fri, 14 May 2004 10:26:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOdcZ-0002x0-00 for sip@ietf.org; Fri, 14 May 2004 10:25:07 -0400 Received: from [202.41.97.50] (helo=u1.doe.ernet.in) by ietf-mx with esmtp (Exim 4.12) id 1BOdbT-0002Oy-00 for sip@ietf.org; Fri, 14 May 2004 10:24:00 -0400 Received: from uucp-relay-delhi.ernet.in (uucp-relay-delhi.ernet.in [202.41.97.134]) by u1.doe.ernet.in (8.12.8/8.12.8) with ESMTP id i4EE89qG017927; Fri, 14 May 2004 19:39:09 +0530 Received: by uucp-relay-delhi.ernet.in (8.9.3+Sun/SMI-4.1-MHS-7.0) id JAA20862; Wed, 12 May 2004 09:44:03 -0500 (GMT) >Received: from cdotd.ernet.in by cdotd.cdotd.ernet.in (SMI-8.6/SMI-SVR4) id JAA00760; Wed, 12 May 2004 09:22:43 -0500 X-Authentication-Warning: relay.cdotd.ernet.in: iscan owned process doing -bs Message-ID: <40A19F06.2CA7818D@cdotd.ernet.in> Date: Wed, 12 May 2004 09:20:30 +0530 From: Rinchen Tundup Organization: C-DOT X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.11.00 9000/785) X-Accept-Language: en MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Apparently-To: Apparently-To: Apparently-To: Received: from cdotd by vikram.eis.ernet.in; Wed, 12 May 2004 09:44 GMT Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=DATE_IN_PAST_06_12, MSGID_FROM_MTA_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] difference between a strict router(2543) and loose router (3261) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello folks, What is the difference between a strict router(2543) and loose router (3261) ? Can any body point me to some call flow standards involving a strict routing proxy as described below ? Lets say i have :- 3261 2543 (or 3261 in strict routing) 3261 UA1---------->Proxy(strict router)---------->UA2 192.168.5.124 192.168.4.171 192.168.5.129 1205481000 1205481001 INVITE arrives at UA2 as :- INVITE sip:1205481001@192.168.5.129 SIP/2.0 Record-Route: My question is how BYE will be formed by UA2 (or UA1) ? for UA2 is it :- BYE sip:1205481000@192.168.5.124 SIP/2.0 Route : or BYE sip:192.168.5.124 SIP/2.0 Route : Route: what is the significance of this kind of BYE with no username in Request URI ? Thanks and -- with greetings, Rinchen Tundup Intelligent Networks _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 17 17:55:06 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05333 for ; Mon, 17 May 2004 17:55:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPpqD-0007dQ-OO for sip-archive@odin.ietf.org; Mon, 17 May 2004 17:40:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HLe8kP029241 for sip-archive@odin.ietf.org; Mon, 17 May 2004 17:40:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPpUL-0003ux-VI; Mon, 17 May 2004 17:17:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPofL-00051N-72 for sip@optimus.ietf.org; Mon, 17 May 2004 16:24:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22988 for ; Mon, 17 May 2004 16:24:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPofJ-0005oq-Dz for sip@ietf.org; Mon, 17 May 2004 16:24:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPodj-00055M-00 for sip@ietf.org; Mon, 17 May 2004 16:23: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 1BPocW-0004WB-00; Mon, 17 May 2004 16:21:56 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 17 May 2004 12:26:54 +0000 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.10/8.12.6) with ESMTP id i4HKLOW9011162; Mon, 17 May 2004 13:21:24 -0700 (PDT) Received: from [128.107.170.98] ([128.107.170.98]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id APA11375; Mon, 17 May 2004 13:21:23 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Jon Peterson From: Cullen Jennings Date: Mon, 17 May 2004 13:21:22 -0700 To: sip@ietf.org, sipping@ietf.org X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] New identity and certs 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 Jon and I have submitted new version of the Identity and Certs drafts. Until they show up in the repository, you can find them at: http://www.employees.org/~fluffy/ietf/draft-ietf-sip-identity-02.txt http://www.employees.org/~fluffy/ietf/draft-jennings-sipping-certs -03.txt These are significant updates from pervious versions. Thanks, Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 17 23:22:29 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25413 for ; Mon, 17 May 2004 23:22: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 1BPv82-0003ae-Qu for sip-archive@odin.ietf.org; Mon, 17 May 2004 23:18:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I3Is4b013733 for sip-archive@odin.ietf.org; Mon, 17 May 2004 23:18:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPv1S-00020t-9i; Mon, 17 May 2004 23:12:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPutT-00087H-QH for sip@optimus.ietf.org; Mon, 17 May 2004 23:03:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24623 for ; Mon, 17 May 2004 23:03:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPutP-0005KN-BO for sip@ietf.org; Mon, 17 May 2004 23:03:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPusW-0004yE-00 for sip@ietf.org; Mon, 17 May 2004 23:02:53 -0400 Received: from mta1.huawei.com ([61.144.161.40] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BPurU-0004DV-00 for sip@ietf.org; Mon, 17 May 2004 23:01:49 -0400 Received: from nbaqi (huawei.com [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HXW007PO1OBQ2@mta1.huawei.com> for sip@ietf.org; Tue, 18 May 2004 10:31:24 +0800 (CST) Date: Tue, 18 May 2004 10:43:24 +0800 From: Karthik M To: sip@ietf.org Message-id: <005e01c43c81$e46664e0$7269460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Mailer: Microsoft Outlook Express 5.50.4927.1200 Content-type: multipart/alternative; boundary="Boundary_(ID_2NCQEpa/HrdrFgKzGOpScA)" X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 Subject: [Sip] Load Balancing In SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_2NCQEpa/HrdrFgKzGOpScA) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hello all, Can anyone provide me links/ideas on general load balancing solutions implemented in sip servers. I want to whether there are any hardware based load balancer similar to HTTP and its functionality. Thanks in advance Karthik M --Boundary_(ID_2NCQEpa/HrdrFgKzGOpScA) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hello all,
    Can anyone provide me links/ideas on general load balancing solutions implemented in sip servers. I want to whether there are any hardware based load balancer similar to HTTP and its functionality.
 
 
Thanks in advance
Karthik M
--Boundary_(ID_2NCQEpa/HrdrFgKzGOpScA)-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 18 02:48:18 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18649 for ; Tue, 18 May 2004 02:48:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPyK7-0002en-Fs for sip-archive@odin.ietf.org; Tue, 18 May 2004 02:43:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I6hZpq010214 for sip-archive@odin.ietf.org; Tue, 18 May 2004 02:43:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPyAx-0008Ul-58; Tue, 18 May 2004 02:34:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPy7E-0007aE-SX for sip@optimus.ietf.org; Tue, 18 May 2004 02:30: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 CAA17599 for ; Tue, 18 May 2004 02:30:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPy7B-0004uv-7B for sip@ietf.org; Tue, 18 May 2004 02:30:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPy63-0004Qv-00 for sip@ietf.org; Tue, 18 May 2004 02:29:03 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 1BPy5F-00042P-00 for sip@ietf.org; Tue, 18 May 2004 02:28:14 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 May 2004 08:28:13 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43CA1.4C052F68" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE : [Sip] Load Balancing In SIP Date: Tue, 18 May 2004 08:28:13 +0200 Message-ID: Thread-Topic: [Sip] Load Balancing In SIP Thread-Index: AcQ8hoiS8GyZ0D2QTneOXWt2DifAbgAGpPpQ From: "MARJOU Xavier FTRD/DAC/LAN" To: X-OriginalArrivalTime: 18 May 2004 06:28:13.0719 (UTC) FILETIME=[4C16F270:01C43CA1] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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_01C43CA1.4C052F68 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 Look at RFC3263 and DNS SRV. =20 Best Regards, Xavier -----Message d'origine----- De : sip-admin@ietf.org [mailto:sip-admin@ietf.org] De la part de = Karthik M Envoy=E9 : mardi 18 mai 2004 04:43 =C0 : sip@ietf.org Objet : [Sip] Load Balancing In SIP Hello all, Can anyone provide me links/ideas on general load balancing = solutions implemented in sip servers. I want to whether there are any = hardware based load balancer similar to HTTP and its functionality. =20 =20 Thanks in advance Karthik M ------_=_NextPart_001_01C43CA1.4C052F68 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi,
 
Look=20 at RFC3263 and DNS SRV.
 
Best=20 Regards,
Xavier
-----Message d'origine-----
De : = sip-admin@ietf.org=20 [mailto:sip-admin@ietf.org] De la part de Karthik=20 M
Envoy=E9 : mardi 18 mai 2004 = 04:43
=C0 :=20 sip@ietf.org
Objet : [Sip] Load Balancing In=20 SIP

Hello all,
    Can anyone provide = me=20 links/ideas on general load balancing solutions implemented in = sip=20 servers. I want to whether there are any hardware based load balancer = similar=20 to HTTP and its functionality.
 
 
Thanks in advance
Karthik = M
------_=_NextPart_001_01C43CA1.4C052F68-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 18 03:15:19 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19971 for ; Tue, 18 May 2004 03:15: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 1BPycO-0007BP-JV for sip-archive@odin.ietf.org; Tue, 18 May 2004 03:02:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I72SY8027599 for sip-archive@odin.ietf.org; Tue, 18 May 2004 03:02:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPyMZ-0003D9-Pt; Tue, 18 May 2004 02:46:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPyGX-00016t-L2 for sip@optimus.ietf.org; Tue, 18 May 2004 02:39:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18256 for ; Tue, 18 May 2004 02:39:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPyGT-000185-PY for sip@ietf.org; Tue, 18 May 2004 02:39:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPyFV-0000kv-00 for sip@ietf.org; Tue, 18 May 2004 02:38:50 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1BPyEX-0000Na-00 for sip@ietf.org; Tue, 18 May 2004 02:37:49 -0400 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i4I6bNl09023; Tue, 18 May 2004 08:37:23 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i4I6bND27475; Tue, 18 May 2004 08:37:23 +0200 (MEST) Received: from mchh246e.mchh.siemens.de (mchh246e.mchh.siemens.de [139.21.200.56]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id IAA04833; Tue, 18 May 2004 08:37:23 +0200 (MET DST) Received: by mchh246e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Tue, 18 May 2004 08:37:23 +0200 Message-ID: <5B788FC2CAFBD6118BAE0030848B025CD7591C@LNN201E> From: Jestin Jean-Francois To: "'Rinchen Tundup'" Cc: sip@ietf.org Subject: RE: [Sip] difference between a strict router(2543) and loose rout er (3261) Date: Tue, 18 May 2004 08:37:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 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 Rinchen, The BYE from UA2(1205481001@192.168.5.129) to the proxy(192.168.4.171) = will be : BYE sip:192.168.4.171 SIP/2.0 Route: ... And then from the proxy to UA1(1205481000@192.168.5.124) : BYE sip:1205481000@192.168.5.124 SIP/2.0 ... Kind regards =20 Jean-Fran=E7ois JESTIN -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of = Rinchen Tundup Sent: mercredi 12 mai 2004 05:51 Subject: [Sip] difference between a strict router(2543) and loose = router (3261) Hello folks, What is the difference between a strict router(2543) and loose router (3261) ? Can any body point me to some call flow standards involving a strict routing proxy as described below ? Lets say i have :- 3261 2543 (or 3261 in strict routing) 3261 UA1---------->Proxy(strict router)---------->UA2 192.168.5.124 192.168.4.171 192.168.5.129 1205481000 1205481001 INVITE arrives at UA2 as :- INVITE sip:1205481001@192.168.5.129 SIP/2.0 Record-Route: My question is how BYE will be formed by UA2 (or UA1) ? for UA2 is it :- BYE sip:1205481000@192.168.5.124 SIP/2.0 Route : or BYE sip:192.168.5.124 SIP/2.0 Route : Route: what is the significance of this kind of BYE with no username in = Request URI ? Thanks and -- with greetings, Rinchen Tundup Intelligent Networks _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 May 18 03:18:16 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20208 for ; Tue, 18 May 2004 03:18:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPyq3-0002V6-RI for sip-archive@odin.ietf.org; Tue, 18 May 2004 03:16:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I7GZjf009604 for sip-archive@odin.ietf.org; Tue, 18 May 2004 03:16:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPydt-0007zt-Tp; Tue, 18 May 2004 03:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPyQ7-000413-2j for sip@optimus.ietf.org; Tue, 18 May 2004 02:49:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18720 for ; Tue, 18 May 2004 02:49:44 -0400 (EDT) From: nataraju.alilaghatta@wipro.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPyQ3-00052y-7L for sip@ietf.org; Tue, 18 May 2004 02:49:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPyP4-0004e2-00 for sip@ietf.org; Tue, 18 May 2004 02:48:43 -0400 Received: from wiproecmx1.wipro.com ([164.164.31.5]) by ietf-mx with esmtp (Exim 4.12) id 1BPyO2-0003tN-00 for sip@ietf.org; Tue, 18 May 2004 02:47:40 -0400 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx1.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i4I6kio9026874 for ; Tue, 18 May 2004 12:16:44 +0530 (IST) Received: from blr-ec-bh2.wipro.com ([10.200.50.92]) by ec-vwall-wd with InterScan Messaging Security Suite; Tue, 18 May 2004 12:16:28 +0530 Received: from blr-ec-msg04.wipro.com ([10.200.53.99]) by blr-ec-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 18 May 2004 12:16:27 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] difference between a strict router(2543) and loose router (3261) Date: Tue, 18 May 2004 12:16:23 +0530 Message-ID: <10C4348A1BA43A4FA8D5B767E052CEAD0137F94A@blr-ec-msg04.wipro.com> Thread-Topic: [Sip] difference between a strict router(2543) and loose router (3261) Thread-Index: AcQ8K2EhFGYCI/zPSqSQNlPX9TXRYgAeIhOQ To: Cc: X-OriginalArrivalTime: 18 May 2004 06:46:27.0261 (UTC) FILETIME=[D7E436D0:01C43CA3] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 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 Just check "section 16.12.1.1 Basic SIP Trapezoid" of Rfc3261 which will clearly mention the processing of Strict and loose routing logic... Thanks & Regards, Nataraju A.B. -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Rinchen Tundup Sent: Wednesday, May 12, 2004 9:21 AM Subject: [Sip] difference between a strict router(2543) and loose router (3261) Hello folks, What is the difference between a strict router(2543) and loose router (3261) ? Can any body point me to some call flow standards involving a strict routing proxy as described below ? Lets say i have :- 3261 2543 (or 3261 in strict routing) 3261 UA1---------->Proxy(strict router)---------->UA2 192.168.5.124 192.168.4.171 192.168.5.129 1205481000 1205481001 INVITE arrives at UA2 as :- INVITE sip:1205481001@192.168.5.129 SIP/2.0 Record-Route: My question is how BYE will be formed by UA2 (or UA1) ? for UA2 is it :- BYE sip:1205481000@192.168.5.124 SIP/2.0 Route : or BYE sip:192.168.5.124 SIP/2.0 Route : Route: what is the significance of this kind of BYE with no username in Request URI ? Thanks and -- with greetings, Rinchen Tundup Intelligent Networks _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 May 18 05:07:37 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26366 for ; Tue, 18 May 2004 05:07: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 1BQ0VJ-0002bc-5I for sip-archive@odin.ietf.org; Tue, 18 May 2004 05:03:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I93G1u010010 for sip-archive@odin.ietf.org; Tue, 18 May 2004 05:03:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ0NM-00017k-9D; Tue, 18 May 2004 04:55:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ0M9-0000hP-Ji for sip@optimus.ietf.org; Tue, 18 May 2004 04:53: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 EAA25629 for ; Tue, 18 May 2004 04:53:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ0M6-0007Sq-HJ for sip@ietf.org; Tue, 18 May 2004 04:53:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ0L7-000753-00 for sip@ietf.org; Tue, 18 May 2004 04:52:46 -0400 Received: from mta1.huawei.com ([61.144.161.40] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BQ0Jw-0006IW-00 for sip@ietf.org; Tue, 18 May 2004 04:51:33 -0400 Received: from nbaqi (huawei.com [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HXW00LURIPDNN@mta1.huawei.com> for sip@ietf.org; Tue, 18 May 2004 16:39:14 +0800 (CST) Date: Tue, 18 May 2004 16:51:14 +0800 From: Karthik M Subject: Re: [Sip] Load Balancing In SIP To: MARJOU Xavier FTRD/DAC/LAN , sip@ietf.org Message-id: <001301c43cb5$4716a4f0$7269460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Mailer: Microsoft Outlook Express 5.50.4927.1200 Content-type: multipart/alternative; boundary="Boundary_(ID_1MX1MOXhw3oDxPy5YbPWwg)" X-Priority: 3 X-MSMail-priority: Normal References: <0HXW00MP8E2XXE@maila.huawei.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_1MX1MOXhw3oDxPy5YbPWwg) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MessageDear Xavier and all, First of all, thanks for your info. I think DNS solution are good only for scalability in equal weighted = servers and they cant dynamically adjust the load on the fly. Also DNS = Updates are to be done by the server which most of the time is not in = our control. High availability is difficult to achieve with the DNS = based LB. So, this may be good for a public proxy kind of scenario but = not for a app server kind of thing. I am looking for more generic solution for LB's, where the LB system = takes care of adusting the load dynamically, do session affinity, = provide high availablility for the LB system. This means that i have = only one outbound proxy (LB system) and whole cluster is hidden behind = that. Expecting your valuable comments on this and details abt any current = implementations( both commerical/open source). Thanks Karthik M ----- Original Message -----=20 From: MARJOU Xavier FTRD/DAC/LAN=20 To: sip@ietf.org=20 Sent: Tuesday, May 18, 2004 2:28 PM Subject: RE : [Sip] Load Balancing In SIP Hi, Look at RFC3263 and DNS SRV. Best Regards, Xavier -----Message d'origine----- De : sip-admin@ietf.org [mailto:sip-admin@ietf.org] De la part de = Karthik M Envoy=E9 : mardi 18 mai 2004 04:43 =C0 : sip@ietf.org Objet : [Sip] Load Balancing In SIP Hello all, Can anyone provide me links/ideas on general load balancing = solutions implemented in sip servers. I want to whether there are any = hardware based load balancer similar to HTTP and its functionality. Thanks in advance Karthik M --Boundary_(ID_1MX1MOXhw3oDxPy5YbPWwg) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message
Dear Xavier and all,
    First of all, thanks = for your=20 info.
    I think DNS solution = are good=20 only for scalability in equal weighted servers and they cant = dynamically=20 adjust the load on the fly. Also DNS Updates are to be done by the = server which=20 most of the time is not in our control. High availability is difficult = to=20 achieve with the DNS based LB. So, = this may=20 be good for a public proxy kind of scenario but not for a app = server kind=20 of thing.
    I am looking for = more generic=20 solution for LB's, where the LB system takes care of adusting the load=20 dynamically, do session affinity, provide high availablility for the LB = system.=20 This means that i have only one outbound proxy (LB system) and whole = cluster is=20 hidden behind that.
    Expecting your = valuable=20 comments on this and details abt any current implementations( both=20 commerical/open source).
 
Thanks
Karthik M
----- Original Message -----
From:=20 MARJOU Xavier=20 FTRD/DAC/LAN
Sent: Tuesday, May 18, 2004 = 2:28 PM
Subject: RE : [Sip] Load = Balancing In=20 SIP

Hi,
 
Look=20 at RFC3263 and DNS SRV.
 
Best=20 Regards,
Xavier
-----Message d'origine-----
De : sip-admin@ietf.org=20 [mailto:sip-admin@ietf.org] De la part de Karthik=20 M
Envoy=E9 : mardi 18 mai 2004 = 04:43
=C0 : sip@ietf.org
Objet : = [Sip]=20 Load Balancing In SIP

Hello all,
    Can anyone = provide me=20 links/ideas on general load balancing solutions implemented in = sip=20 servers. I want to whether there are any hardware based load = balancer=20 similar to HTTP and its functionality.
 
 
Thanks in advance
Karthik=20 M
--Boundary_(ID_1MX1MOXhw3oDxPy5YbPWwg)-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 18 05:19:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27264 for ; Tue, 18 May 2004 05:19: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 1BQ0h2-0005of-6s for sip-archive@odin.ietf.org; Tue, 18 May 2004 05:15:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I9FOMb022358 for sip-archive@odin.ietf.org; Tue, 18 May 2004 05:15:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ0Z1-0003eS-Ae; Tue, 18 May 2004 05:07:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ0R8-0001tQ-DQ for sip@optimus.ietf.org; Tue, 18 May 2004 04:58:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25782 for ; Tue, 18 May 2004 04:58:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ0R5-0001ao-At for sip@ietf.org; Tue, 18 May 2004 04:58:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ0Q7-0001DW-00 for sip@ietf.org; Tue, 18 May 2004 04:57:55 -0400 Received: from mail.deccanetworld.com ([203.196.146.50] helo=gatekeeper.deccanetworld.com) by ietf-mx with esmtp (Exim 4.12) id 1BQ0Pe-0000q7-00 for sip@ietf.org; Tue, 18 May 2004 04:57:26 -0400 Received: from gatekeeper.deccanetworld.com (localhost [127.0.0.1]) by gatekeeper.deccanetworld.com (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id i4I8nFPW026517 for ; Tue, 18 May 2004 14:19:15 +0530 Received: from mail.deccanetworld.com (server.deccanetworld.com [192.168.1.32]) by gatekeeper.deccanetworld.com (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id i4I8nE6i026512 for ; Tue, 18 May 2004 14:19:14 +0530 Received: (from root@localhost) by mail.deccanetworld.com (8.11.0/8.11.0) id i4I9AlI14103 for sip@ietf.org; Tue, 18 May 2004 14:40:47 +0530 Received: from gvvivek (bharathi.software [192.168.1.224] (may be forged)) by mail.deccanetworld.com (8.11.0/8.11.0) with SMTP id i4I9Alq14060 for ; Tue, 18 May 2004 14:40:47 +0530 Message-ID: <00ce01c43cb6$2bbf7aa0$e001a8c0@gvvivek> From: "Vishnu Yadav" To: Date: Tue, 18 May 2004 14:27:38 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CB_01C43CE4.4572FBB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,EXCUSE_16,HTML_20_30, HTML_MESSAGE autolearn=no version=2.60 Subject: [Sip] t field in SDP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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_00CB_01C43CE4.4572FBB0 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable In SDP, the line t=3D ,=20 describes start time & end time of session . 1) If the Stop time is non Zero, and in between the call it demineshes = to zero then what happens? how is the termination of session takes = place? 2) here both the timings are represented in decimal, but what it = signifies.That is if the user wants to set start time as 1 minute then = what value he/she should set for the start time in t . Thanx in advance vishnu yadav ********************************DISCLAIMER********************************** This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege of Deccanet Designs Ltd. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from retaining, using, copying, altering or disclosing the contents of this message. **************************************************************************** ------=_NextPart_000_00CB_01C43CE4.4572FBB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
In SDP, the = line   t=3D<start time>  <stop time>, =
describes start time & end time of = session=20 .
 
1) If the Stop time is non Zero, and in = between the=20 call it demineshes to zero then what happens? how is the termination of = session=20 takes place?
2) here both the timings are = represented in=20 decimal, but what it signifies.That is if the user wants to set start = time as 1=20 minute then what value he/she should set for the start time in = t=20 .
 
Thanx in advance
vishnu yadav

********************************DISCLAIMER**********************************

This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege of Deccanet Designs Ltd.
If you have received this message in error, please notify the originator
immediately. If you are not the intended recipient, you are notified that
you are strictly prohibited from retaining, using, copying, altering or
disclosing the contents of this message.

****************************************************************************
------=_NextPart_000_00CB_01C43CE4.4572FBB0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 18 05:34:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28049 for ; Tue, 18 May 2004 05:34:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ0wb-0001Br-M9 for sip-archive@odin.ietf.org; Tue, 18 May 2004 05:31:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I9VTeb004573 for sip-archive@odin.ietf.org; Tue, 18 May 2004 05:31:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ0lk-0007B1-0H; Tue, 18 May 2004 05:20:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ0j6-00069f-J8 for sip@optimus.ietf.org; Tue, 18 May 2004 05:17: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 FAA26911 for ; Tue, 18 May 2004 05:17:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ0j3-0001Zv-7y for sip@ietf.org; Tue, 18 May 2004 05:17:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ0hu-00017E-00 for sip@ietf.org; Tue, 18 May 2004 05:16:20 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx with esmtp (Exim 4.12) id 1BQ0hC-0000gv-00 for sip@ietf.org; Tue, 18 May 2004 05:15:34 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 May 2004 11:15:32 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43CB8.AB3ACE20" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Sip] Load Balancing In SIP Date: Tue, 18 May 2004 11:15:31 +0200 Message-ID: <3418F3471F1CA4409901547349FFAE2E017EAA82@ftrdmel2.rd.francetelecom.fr> Thread-Topic: [Sip] Load Balancing In SIP Thread-Index: AcQ8trkYeDrjihpCRTqLMbaMwDgpQAAAbwDA From: "ANTONINI Pierre-Antoine FTRD/DMR/LON" To: "Karthik M" , "MARJOU Xavier FTRD/DAC/LAN" , X-OriginalArrivalTime: 18 May 2004 09:15:32.0063 (UTC) FILETIME=[AB68AEF0:01C43CB8] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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_01C43CB8.AB3ACE20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, What about the Ubiquity SIP AS? I think it does the load-balancing you = want... Regards, Pierre-Antoine Antonini -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of = Karthik M Sent: 18 May 2004 09:51 To: MARJOU Xavier FTRD/DAC/LAN; sip@ietf.org Subject: Re: [Sip] Load Balancing In SIP Dear Xavier and all, First of all, thanks for your info. I think DNS solution are good only for scalability in equal weighted = servers and they cant dynamically adjust the load on the fly. Also DNS = Updates are to be done by the server which most of the time is not in = our control. High availability is difficult to achieve with the DNS = based LB. So, this may be good for a public proxy kind of scenario but = not for a app server kind of thing. I am looking for more generic solution for LB's, where the LB system = takes care of adusting the load dynamically, do session affinity, = provide high availablility for the LB system. This means that i have = only one outbound proxy (LB system) and whole cluster is hidden behind = that. Expecting your valuable comments on this and details abt any current = implementations( both commerical/open source). =20 Thanks Karthik M ----- Original Message -----=20 From: MARJOU Xavier = FTRD/DAC/LAN=20 To: sip@ietf.org=20 Sent: Tuesday, May 18, 2004 2:28 PM Subject: RE : [Sip] Load Balancing In SIP Hi, =20 Look at RFC3263 and DNS SRV. =20 Best Regards, Xavier -----Message d'origine----- De : sip-admin@ietf.org [mailto:sip-admin@ietf.org] De la part de = Karthik M Envoy=E9 : mardi 18 mai 2004 04:43 =C0 : sip@ietf.org Objet : [Sip] Load Balancing In SIP Hello all, Can anyone provide me links/ideas on general load balancing = solutions implemented in sip servers. I want to whether there are any = hardware based load balancer similar to HTTP and its functionality. =20 =20 Thanks in advance Karthik M ------_=_NextPart_001_01C43CB8.AB3ACE20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi,
What=20 about the Ubiquity SIP AS? I think it does the load-balancing you=20 want...
Regards,
Pierre-Antoine Antonini
-----Original Message-----
From:=20 sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of = Karthik=20 M
Sent: 18 May 2004 09:51
To: MARJOU Xavier = FTRD/DAC/LAN;=20 sip@ietf.org
Subject: Re: [Sip] Load Balancing In=20 SIP

Dear Xavier and all,
    First of all, = thanks for your=20 info.
    I think DNS = solution are good=20 only for scalability in equal weighted servers and they cant = dynamically=20 adjust the load on the fly. Also DNS Updates are to be done by the = server=20 which most of the time is not in our control. High availability is = difficult=20 to achieve with the DNS based LB. So,=20 this may be good for a public proxy kind of scenario but not = for a=20 app server kind of thing.
    I am looking for = more generic=20 solution for LB's, where the LB system takes care of adusting the load = dynamically, do session affinity, provide high availablility for the = LB=20 system. This means that i have only one outbound proxy (LB system) and = whole=20 cluster is hidden behind that.
    Expecting = your valuable=20 comments on this and details abt any current implementations( both=20 commerical/open source).
 
Thanks
Karthik M
----- Original Message -----
From:=20 MARJOU Xavier=20 FTRD/DAC/LAN
Sent: Tuesday, May 18, 2004 = 2:28=20 PM
Subject: RE : [Sip] Load = Balancing In=20 SIP

Hi,
 
Look at RFC3263 and DNS SRV.
 
Best Regards,
Xavier
-----Message = d'origine-----
De : sip-admin@ietf.org=20 [mailto:sip-admin@ietf.org] De la part de Karthik=20 M
Envoy=E9 : mardi 18 mai 2004 = 04:43
=C0 : sip@ietf.org
Objet : = [Sip]=20 Load Balancing In SIP

Hello all,
    Can anyone = provide me=20 links/ideas on general load balancing solutions = implemented in sip=20 servers. I want to whether there are any hardware based load = balancer=20 similar to HTTP and its functionality.
 
 
Thanks in advance
Karthik=20 M
------_=_NextPart_001_01C43CB8.AB3ACE20-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 18 06:01:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29835 for ; Tue, 18 May 2004 06:01:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ1Jh-0006aE-OE for sip-archive@odin.ietf.org; Tue, 18 May 2004 05:55:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I9tLKV025307 for sip-archive@odin.ietf.org; Tue, 18 May 2004 05:55:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ19k-0004gl-KV; Tue, 18 May 2004 05:45:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ17j-0004CO-LN for sip@optimus.ietf.org; Tue, 18 May 2004 05:42:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28642 for ; Tue, 18 May 2004 05:42:56 -0400 (EDT) From: sreeram.kanumuri@wipro.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ17g-0004hH-4f for sip@ietf.org; Tue, 18 May 2004 05:42:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ16d-0004Gv-00 for sip@ietf.org; Tue, 18 May 2004 05:41:52 -0400 Received: from wiproecmx1.wipro.com ([164.164.31.5]) by ietf-mx with esmtp (Exim 4.12) id 1BQ15b-0003Sj-00 for sip@ietf.org; Tue, 18 May 2004 05:40:48 -0400 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx1.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i4I9dxo9022371 for ; Tue, 18 May 2004 15:09:59 +0530 (IST) Received: from blr-ec-bh1.wipro.com ([10.200.50.91]) by ec-vwall-wd with InterScan Messaging Security Suite; Tue, 18 May 2004 15:09:56 +0530 Received: from blr-ec-msg04.wipro.com ([10.200.53.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 18 May 2004 15:09:56 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43CBC.1310E65F" Subject: RE: [Sip] t field in SDP Date: Tue, 18 May 2004 15:09:54 +0530 Message-ID: <72001BBBF6CB124BA1C40E415914E2130301EA@blr-ec-msg04.wipro.com> Thread-Topic: [Sip] t field in SDP Thread-Index: AcQ8uMlp8QyBiixYSUSsbuFMnQ5E0QAAUz/g To: , X-OriginalArrivalTime: 18 May 2004 09:39:56.0511 (UTC) FILETIME=[1449B6F0:01C43CBC] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,EXCUSE_16,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_RED,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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_01C43CBC.1310E65F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1) If the Stop time is non Zero, and in between the call it demineshes to zero then what happens? how is the termination of session takes place? If the stop time is 0 then the session terminates.that means session becomes inactive. You can take this the case you established a call and RTP is active and it becomes inactive in the middle.than its your application responsibility to observe this and act on terminating the session.=20 =20 2) here both the timings are represented in decimal, but what it signifies.That is if the user wants to set start time as 1 minute then what value he/she should set for the start time in t . These values are decimal representation of NTP time values in seconds. To get the unixtime ,subtract decimal number 2208988800 from that number. =20 -SReeram -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Vishnu Yadav Sent: Tuesday, May 18, 2004 2:28 PM To: sip@ietf.org Subject: [Sip] t field in SDP =09 =09 In SDP, the line t=3D ,=20 describes start time & end time of session . =20 1) If the Stop time is non Zero, and in between the call it demineshes to zero then what happens? how is the termination of session takes place? 2) here both the timings are represented in decimal, but what it signifies.That is if the user wants to set start time as 1 minute then what value he/she should set for the start time in t . =20 Thanx in advance vishnu yadav =09 =09 ********************************DISCLAIMER****************************** **** =09 This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege of Deccanet Designs Ltd. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from retaining, using, copying, altering or disclosing the contents of this message. =09 =09 ************************************************************************ **** ------_=_NextPart_001_01C43CBC.1310E65F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
1) If the Stop time is = non Zero, and=20 in between the call it demineshes to zero then what happens? how is the=20 termination of session takes place?
If the stop = time is 0=20 then the session terminates.that means session becomes=20 inactive.
You can take = this the=20 case you established a call and RTP is active and it becomes inactive in = the=20 middle.than its your application responsibility to observe this and act = on=20 terminating the session. 
 
2) here both the = timings are=20 represented in decimal, but what it signifies.That is if the user wants = to set=20 start time as 1 minute then what value he/she should set for = the start=20 time in t .
These values = are decimal=20 representation of NTP time values in seconds.
To get the = unixtime=20 ,subtract decimal number 2208988800 from that=20 number.
 
-SReeram
-----Original Message-----
From:=20 sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of = Vishnu=20 Yadav
Sent: Tuesday, May 18, 2004 2:28 PM
To:=20 sip@ietf.org
Subject: [Sip] t field in = SDP

In SDP, the = line   t=3D<start time>  <stop = time>,=20
describes start time & end time = of session=20 .
 
1) If the Stop time is non Zero, and = in between=20 the call it demineshes to zero then what happens? how is the = termination of=20 session takes place?
2) here both the timings are = represented in=20 decimal, but what it signifies.That is if the user wants to set start = time as=20 1 minute then what value he/she should set for the start = time in t=20 .
 
Thanx in advance
vishnu yadav
********************************DISCLAIMER*******************************=
***

This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege of Deccanet Designs =
Ltd.
If you have received this message in error, please notify the originator
immediately. If you are not the intended recipient, you are notified =
that
you are strictly prohibited from retaining, using, copying, altering or
disclosing the contents of this message.

*************************************************************************=
***
------_=_NextPart_001_01C43CBC.1310E65F-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 18 06:19:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00672 for ; Tue, 18 May 2004 06:19: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 1BQ1Zy-0002N0-Ni for sip-archive@odin.ietf.org; Tue, 18 May 2004 06:12:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IACAhV009094 for sip-archive@odin.ietf.org; Tue, 18 May 2004 06:12:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ1T4-0000J9-L0; Tue, 18 May 2004 06:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ1PS-0007hc-1W for sip@optimus.ietf.org; Tue, 18 May 2004 06:01: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 GAA29833 for ; Tue, 18 May 2004 06:01:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ1PO-0004W4-BX for sip@ietf.org; Tue, 18 May 2004 06:01:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ1OO-000477-00 for sip@ietf.org; Tue, 18 May 2004 06:00:13 -0400 Received: from mxout1.netvision.net.il ([194.90.9.20]) by ietf-mx with esmtp (Exim 4.12) id 1BQ1Nl-0003ht-00 for sip@ietf.org; Tue, 18 May 2004 05:59:33 -0400 Received: from mailvision.com ([212.143.127.195]) by mxout1.netvision.net.il (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0HXW00F6XMEE8N@mxout1.netvision.net.il> for sip@ietf.org; Tue, 18 May 2004 12:59:03 +0300 (IDT) Date: Tue, 18 May 2004 11:58:53 +0200 From: Diego B Subject: Re: [Sip] Load Balancing In SIP In-reply-to: <3418F3471F1CA4409901547349FFAE2E017EAA82@ftrdmel2.rd.francetelecom.fr> To: ANTONINI Pierre-Antoine FTRD/DMR/LON Cc: Karthik M , MARJOU Xavier FTRD/DAC/LAN , sip@ietf.org Message-id: <40A9DE5D.8060808@mailvision.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) References: <3418F3471F1CA4409901547349FFAE2E017EAA82@ftrdmel2.rd.francetelecom.fr> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL autolearn=no version=2.60 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; Take alook at Vovida solutions www.vovida.org I thing they ahve what you need or very close to it. Diego ANTONINI Pierre-Antoine FTRD/DMR/LON wrote: > Hi, > What about the Ubiquity SIP AS? I think it does the load-balancing = you=20 > want... > Regards, > Pierre-Antoine Antonini >=20 > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf = Of > Karthik M > Sent: 18 May 2004 09:51 > To: MARJOU Xavier FTRD/DAC/LAN; sip@ietf.org > Subject: Re: [Sip] Load Balancing In SIP >=20 > Dear Xavier and all, > First of all, thanks for your info. > I think DNS solution are good only for scalability in equal > weighted servers and they cant dynamically adjust the load on t= he > fly. Also DNS Updates are to be done by the server which most o= f the > time is not in our control. High availability is difficult to > achieve with the DNS based LB. So, this may be good for a publi= c > proxy kind of scenario but not for a app server kind of thing. > I am looking for more generic solution for LB's, where the = LB > system takes care of adusting the load dynamically, do session > affinity, provide high availablility for the LB system. This me= ans > that i have only one outbound proxy (LB system) and whole clust= er is > hidden behind that. > Expecting your valuable comments on this and details abt an= y > current implementations( both commerical/open source). > =20 > Thanks > Karthik M >=20 > ----- Original Message ----- > From: MARJOU Xavier FTRD/DAC/LAN > > To: sip@ietf.org > Sent: Tuesday, May 18, 2004 2:28 PM > Subject: RE : [Sip] Load Balancing In SIP >=20 > Hi, > =20 > Look at RFC3263 and DNS SRV. > =20 > Best Regards, > Xavier >=20 > -----Message d'origine----- > De : sip-admin@ietf.org > [mailto:sip-admin@ietf.org] De la part de Karthik M > Envoy=E9 : mardi 18 mai 2004 04:43 > =C0 : sip@ietf.org > Objet : [Sip] Load Balancing In SIP >=20 > Hello all, > Can anyone provide me links/ideas on general load > balancing solutions implemented in sip servers. I want = to > whether there are any hardware based load balancer simi= lar > to HTTP and its functionality. > =20 > =20 > Thanks in advance > Karthik M --=20 Diego B MailVision Ltd. Tel. : +972-4-8500505 ext 13 e-mail: diegob@mailvision.com web : http://www.mailvision.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 May 18 08:05:20 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07914 for ; Tue, 18 May 2004 08:05: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 1BQ3G4-0005Cg-Dp for sip-archive@odin.ietf.org; Tue, 18 May 2004 07:59:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IBxihe020003 for sip-archive@odin.ietf.org; Tue, 18 May 2004 07:59:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ37e-0002Bz-Ft; Tue, 18 May 2004 07: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 1BQ30y-0000fE-7x for sip@optimus.ietf.org; Tue, 18 May 2004 07:44:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06916 for ; Tue, 18 May 2004 07:44:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ30x-0000p7-D4 for sip@ietf.org; Tue, 18 May 2004 07:44:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ307-0000QG-00 for sip@ietf.org; Tue, 18 May 2004 07:43:16 -0400 Received: from mxout3.netvision.net.il ([194.90.9.24]) by ietf-mx with esmtp (Exim 4.12) id 1BQ2z9-0007Pw-00; Tue, 18 May 2004 07:42:15 -0400 Received: from mailvision.com ([212.143.127.195]) by mxout3.netvision.net.il (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0HXW00G8PR5EPL@mxout3.netvision.net.il>; Tue, 18 May 2004 14:41:39 +0300 (IDT) Date: Tue, 18 May 2004 13:41:38 +0200 From: Diego B To: sip@ietf.org, sipping Cc: Cullen Jennings Message-id: <40A9F672.6090008@mailvision.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Subject: [Sip] SIP Forward, Who pays the bill ? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org 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; My question is regarding billing a forwarded sip call. Lets take the exmple from draft-ietf-sipping-service-examples 2.7 Alice calls Bob, and Bob has all his incomming calls forwarded to the PSTN. Let say that calls from ALice to Bob in the same domain are free (same office, or same ITSP), but calls to the PSTN are not free. Who pays for Alice call to Bob ?? In a normal situacion, Alice knows that the call is for free becuase she is calling Bob's sip number. But the gateweay may create CDR from the From header of the SIP message and at the end of the month Alice may have to pay for the call. I see this kind of examples in several other drafts/RFC related to SIP services and call forward. I belive forward is a very important feature, but this issue may be resolved. The question is if it is a standard way to make Bob pays for the second leg of the call like in PSTN forward. Maybe changing the From header where applicable and adding a new one to "remember" that the call is from, in my example, Alice. The diversion header (Diversion Indication in SIP draft-levy-sip-diversion-07.txt)" may be a solution if the PSTN gateway or the SIP Billing server support it and knows that they have to bill the sip-uri in the diversion header ( this is right ??? ). Regards; -- Diego B MailVision Ltd. Tel. : +972-4-8500505 ext 13 e-mail: diegob@mailvision.com web : http://www.mailvision.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 May 18 08:58:30 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11630 for ; Tue, 18 May 2004 08:58: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 1BQ47k-0007So-1M for sip-archive@odin.ietf.org; Tue, 18 May 2004 08:55:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ICtBNp028691 for sip-archive@odin.ietf.org; Tue, 18 May 2004 08: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 1BQ3qE-0001zq-2w; Tue, 18 May 2004 08:37:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ3lx-0008An-P4 for sip@optimus.ietf.org; Tue, 18 May 2004 08:32: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 IAA09677 for ; Tue, 18 May 2004 08:32:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ3lw-00049f-Io for sip@ietf.org; Tue, 18 May 2004 08:32:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ3kl-0003fI-00 for sip@ietf.org; Tue, 18 May 2004 08:31:28 -0400 Received: from [207.164.160.106] (helo=PLUTO.LEAPSTONE.COM) by ietf-mx with esmtp (Exim 4.12) id 1BQ3jb-0002nY-00; Tue, 18 May 2004 08:30:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: RE: [Sip] SIP Forward, Who pays the bill ? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 May 2004 08:29:54 -0400 Message-ID: <74C307FA4137884EA234B26DE84C00340CD721@PLUTO.LEAPSTONE.COM> Thread-Topic: [Sip] SIP Forward, Who pays the bill ? Thread-Index: AcQ8z38nHoVSng0PTFaWEyGD1i20YwAA4++w From: "Fred Hasle" To: "Diego B" , , "sipping" Cc: "Cullen Jennings" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 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 Diego, My understanding is the Diversion Header will be replaced with the Request History Information (http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-02.txt) Fred. ---- Fred Hasle. Leapstone Systems www.leapstone.com -----Original Message----- From: Diego B [mailto:diegob@mailvision.com]=20 Sent: Tuesday, May 18, 2004 7:42 AM To: sip@ietf.org; sipping Cc: Cullen Jennings Subject: [Sip] SIP Forward, Who pays the bill ? Hi; My question is regarding billing a forwarded sip call. Lets take the exmple from draft-ietf-sipping-service-examples 2.7 Alice calls Bob, and Bob has all his incomming calls forwarded to the PSTN. Let say that calls from ALice to Bob in the same domain are free (same=20 office, or same ITSP), but calls to the PSTN are not free. Who pays for Alice call to Bob ?? In a normal situacion, Alice knows that the call is for free becuase she is calling Bob's sip number. But the gateweay may create CDR from the=20 From header of the SIP message and at the end of the month Alice may=20 have to pay for the call. I see this kind of examples in several other drafts/RFC related to SIP=20 services and call forward. I belive forward is a very important feature, but this issue may be=20 resolved. The question is if it is a standard way to make Bob pays for=20 the second leg of the call like in PSTN forward. Maybe changing the From header where applicable and adding a new one to=20 "remember" that the call is from, in my example, Alice. The diversion header (Diversion Indication in SIP=20 draft-levy-sip-diversion-07.txt)" may be a solution if the PSTN gateway=20 or the SIP Billing server support it and knows that they have to bill=20 the sip-uri in the diversion header ( this is right ??? ). Regards; --=20 Diego B MailVision Ltd. Tel. : +972-4-8500505 ext 13 e-mail: diegob@mailvision.com web : http://www.mailvision.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 Tue May 18 09:24:23 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13335 for ; Tue, 18 May 2004 09:24: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 1BQ4Rl-0005fb-DA for sip-archive@odin.ietf.org; Tue, 18 May 2004 09:15:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IDFrq3021727 for sip-archive@odin.ietf.org; Tue, 18 May 2004 09:15:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ4As-0000dc-TE; Tue, 18 May 2004 08:58:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ45f-0006nH-Um for sip@optimus.ietf.org; Tue, 18 May 2004 08:53:03 -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 IAA11257 for ; Tue, 18 May 2004 08:53:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ45e-0004tA-Ic for sip@ietf.org; Tue, 18 May 2004 08:53:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ44h-0004UJ-00 for sip@ietf.org; Tue, 18 May 2004 08:52:03 -0400 Received: from brazilnut.cc.columbia.edu ([128.59.59.203] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 1BQ43Z-0003xm-00 for sip@ietf.org; Tue, 18 May 2004 08:50:53 -0400 Received: from cs.columbia.edu (pool-138-89-37-220.mad.east.verizon.net [138.89.37.220]) (user=hgs10 mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.12.11/8.12.11) with ESMTP id i4ICojAp007130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 May 2004 08:50:48 -0400 (EDT) Message-ID: <40AA06AB.6040909@cs.columbia.edu> Date: Tue, 18 May 2004 08:50:51 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Karthik M CC: sip@ietf.org Subject: Re: [Sip] Load Balancing In SIP References: <005e01c43c81$e46664e0$7269460a@china.huawei.com> In-Reply-To: <005e01c43c81$e46664e0$7269460a@china.huawei.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit We have a paper describing options for SIP load balancing. Contact Kundan Singh (kns10@cs.columbia.edu) if you're interested in a preprint. Karthik M wrote: > Hello all, > Can anyone provide me links/ideas on general load balancing > solutions implemented in sip servers. I want to whether there are any > hardware based load balancer similar to HTTP and its functionality. > > > Thanks in advance > Karthik M _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 18 09:35:22 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14175 for ; Tue, 18 May 2004 09:35:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ4VA-0007UY-8O for sip-archive@odin.ietf.org; Tue, 18 May 2004 09:19:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IDJOwR028794 for sip-archive@odin.ietf.org; Tue, 18 May 2004 09:19:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ4EM-00021q-5F; Tue, 18 May 2004 09: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 1BQ3es-00049A-94 for sip@optimus.ietf.org; Tue, 18 May 2004 08:25: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 IAA08891 for ; Tue, 18 May 2004 08:25:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ3eq-0000uN-RT for sip@ietf.org; Tue, 18 May 2004 08:25:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ3dk-0000Qk-00 for sip@ietf.org; Tue, 18 May 2004 08:24:12 -0400 Received: from smtp003.bizmail.yahoo.com ([216.136.130.195]) by ietf-mx with smtp (Exim 4.12) id 1BQ3ck-000004-00 for sip@ietf.org; Tue, 18 May 2004 08:23:10 -0400 Received: from unknown (HELO BaruchLaptop) (baruch@kayote.com@208.170.170.247 with login) by smtp003.bizmail.yahoo.com with SMTP; 18 May 2004 12:23:07 -0000 Reply-To: From: "Baruch Sterman" To: "'Diego B'" , , "'sipping'" Cc: "'Cullen Jennings'" Subject: RE: [Sip] SIP Forward, Who pays the bill ? Date: Tue, 18 May 2004 08:22:50 -0400 Message-ID: <003701c43cd2$daee8540$f7aaaad0@BaruchLaptop> 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.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <40A9F672.6090008@mailvision.com> Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit In the systems that we implemented, two cdrs are created: the first for the incoming leg (Alice to Bob's non-forwarded location) and a second for the forward to Bob's forwarded location. Alice would pay for the first leg, and Bob pays for the second. Furthermore, it may be the case that Bob pays for the first leg as well. If, for example, Bob has a toll free number where he pays per minute charges for the inbound leg (in this case, Alice is on the PSTN). Either way, multiple CDRs is the way we came up with to handle this. Care has to be taken that the key to any CDR database is NOT the call-ID, because this is the same across the two CDRs. Baruch -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Diego B Sent: Tuesday, May 18, 2004 7:42 AM To: sip@ietf.org; sipping Cc: Cullen Jennings Subject: [Sip] SIP Forward, Who pays the bill ? Hi; My question is regarding billing a forwarded sip call. Lets take the exmple from draft-ietf-sipping-service-examples 2.7 Alice calls Bob, and Bob has all his incomming calls forwarded to the PSTN. Let say that calls from ALice to Bob in the same domain are free (same office, or same ITSP), but calls to the PSTN are not free. Who pays for Alice call to Bob ?? In a normal situacion, Alice knows that the call is for free becuase she is calling Bob's sip number. But the gateweay may create CDR from the From header of the SIP message and at the end of the month Alice may have to pay for the call. I see this kind of examples in several other drafts/RFC related to SIP services and call forward. I belive forward is a very important feature, but this issue may be resolved. The question is if it is a standard way to make Bob pays for the second leg of the call like in PSTN forward. Maybe changing the From header where applicable and adding a new one to "remember" that the call is from, in my example, Alice. The diversion header (Diversion Indication in SIP draft-levy-sip-diversion-07.txt)" may be a solution if the PSTN gateway or the SIP Billing server support it and knows that they have to bill the sip-uri in the diversion header ( this is right ??? ). Regards; -- Diego B MailVision Ltd. Tel. : +972-4-8500505 ext 13 e-mail: diegob@mailvision.com web : http://www.mailvision.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 Tue May 18 10:29:27 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18457 for ; Tue, 18 May 2004 10:29:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ5WF-00084I-Eg for sip-archive@odin.ietf.org; Tue, 18 May 2004 10:24:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IEOZKU031014 for sip-archive@odin.ietf.org; Tue, 18 May 2004 10:24:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ5DR-0006qD-Sr; Tue, 18 May 2004 10:05:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ5Bf-0004Jb-Qk for sip@optimus.ietf.org; Tue, 18 May 2004 10:03: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 KAA15584 for ; Tue, 18 May 2004 10:03:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ5Bd-0001Rm-Ik for sip@ietf.org; Tue, 18 May 2004 10:03:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ5AY-00013r-00 for sip@ietf.org; Tue, 18 May 2004 10:02:11 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 1BQ59l-0000gT-00 for sip@ietf.org; Tue, 18 May 2004 10:01:21 -0400 Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i4IE1Cbt029551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 May 2004 10:01:13 -0400 (EDT) Message-ID: <40AA1728.4010900@cs.columbia.edu> Date: Tue, 18 May 2004 10:01:12 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Karthik M CC: MARJOU Xavier FTRD/DAC/LAN , sip@ietf.org Subject: Re: [Sip] Load Balancing In SIP References: <0HXW00MP8E2XXE@maila.huawei.com> <001301c43cb5$4716a4f0$7269460a@china.huawei.com> In-Reply-To: <001301c43cb5$4716a4f0$7269460a@china.huawei.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.0.97784, Antispam-Core: 4.6.0.97340, Antispam-Data: 2004.5.17.101026 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report='__MOZILLA_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, __UNUSABLE_MSGID 0, EMAIL_ATTRIBUTION 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit As soon as you have a load balancer, you have introduced another single point of failure. Session affinity can easily be assured by SIP routing means. It seems dangerous to extrapolate the HTTP architecture to SIP - the issues, tools and problems are rather different. Karthik M wrote: > Dear Xavier and all, > First of all, thanks for your info. > I think DNS solution are good only for scalability in equal weighted > servers and they cant dynamically adjust the load on the fly. Also DNS > Updates are to be done by the server which most of the time is not in > our control. High availability is difficult to achieve with the DNS > based LB. So, this may be good for a public proxy kind of scenario but > not for a app server kind of thing. > I am looking for more generic solution for LB's, where the LB system > takes care of adusting the load dynamically, do session affinity, > provide high availablility for the LB system. This means that i have > only one outbound proxy (LB system) and whole cluster is hidden behind that. > Expecting your valuable comments on this and details abt any current > implementations( both commerical/open source). > > Thanks > Karthik M > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 18 10:48:39 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20272 for ; Tue, 18 May 2004 10:48: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 1BQ5lF-0003uy-OF for sip-archive@odin.ietf.org; Tue, 18 May 2004 10:40:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IEe52G015052 for sip-archive@odin.ietf.org; Tue, 18 May 2004 10:40:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ5Yh-0000UO-2T; Tue, 18 May 2004 10:27:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ5O8-0003Mf-9W for sip@optimus.ietf.org; Tue, 18 May 2004 10:16: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 KAA16843 for ; Tue, 18 May 2004 10:16:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ5O6-0006Mp-1f for sip@ietf.org; Tue, 18 May 2004 10:16:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ5N9-0005zr-00 for sip@ietf.org; Tue, 18 May 2004 10:15:12 -0400 Received: from mxout5.netvision.net.il ([194.90.9.29]) by ietf-mx with esmtp (Exim 4.12) id 1BQ5Mg-0005dS-00; Tue, 18 May 2004 10:14:42 -0400 Received: from mailvision.com ([212.143.127.195]) by mxout5.netvision.net.il (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0HXW00HHFY7LQC@mxout5.netvision.net.il>; Tue, 18 May 2004 17:14:11 +0300 (IDT) Date: Tue, 18 May 2004 16:14:09 +0200 From: Diego B Subject: Re: [Sip] SIP Forward, Who pays the bill ? In-reply-to: <003701c43cd2$daee8540$f7aaaad0@BaruchLaptop> To: baruch@kayote.com Cc: sip@ietf.org, "'sipping'" , "'Cullen Jennings'" Message-id: <40AA1A31.3050207@mailvision.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) References: <003701c43cd2$daee8540$f7aaaad0@BaruchLaptop> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL autolearn=no version=2.60 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 Baruch; Thanks for your answer. I belive that you are implementing a proprietary solution to deal with it. I'm looking more to a standarize way to deal with the second-leg issue. I'm agree that Alice has to pay for the first leg and Bob for the second, but if the Proxy that is doing the forward is not a biling entity ( local calls are free, outbound call are not free and billed by an external real-time billing system connected to the GW using RADIUS or similar), the PSTN gateway will have to know that this call may be billed to Bob and not to Alice ( she apears in the From header ). Thanks Baruch Sterman wrote: > In the systems that we implemented, two cdrs are created: the first for > the incoming leg (Alice to Bob's non-forwarded location) and a second > for the forward to Bob's forwarded location. > > Alice would pay for the first leg, and Bob pays for the second. > > Furthermore, it may be the case that Bob pays for the first leg as well. > If, for example, Bob has a toll free number where he pays per minute > charges for the inbound leg (in this case, Alice is on the PSTN). > > Either way, multiple CDRs is the way we came up with to handle this. > Care has to be taken that the key to any CDR database is NOT the > call-ID, because this is the same across the two CDRs. > > Baruch > > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Diego > B > Sent: Tuesday, May 18, 2004 7:42 AM > To: sip@ietf.org; sipping > Cc: Cullen Jennings > Subject: [Sip] SIP Forward, Who pays the bill ? > > Hi; > My question is regarding billing a forwarded sip call. > > Lets take the exmple from draft-ietf-sipping-service-examples > 2.7 > > Alice calls Bob, and Bob has all his incomming calls forwarded to the > PSTN. > > Let say that calls from ALice to Bob in the same domain are free (same > office, or same ITSP), but calls to the PSTN are not free. > > Who pays for Alice call to Bob ?? > In a normal situacion, Alice knows that the call is for free becuase she > > is calling Bob's sip number. But the gateweay may create CDR from the > From header of the SIP message and at the end of the month Alice may > have to pay for the call. > > I see this kind of examples in several other drafts/RFC related to SIP > services and call forward. > > I belive forward is a very important feature, but this issue may be > resolved. The question is if it is a standard way to make Bob pays for > the second leg of the call like in PSTN forward. > > Maybe changing the From header where applicable and adding a new one to > "remember" that the call is from, in my example, Alice. > > The diversion header (Diversion Indication in SIP > draft-levy-sip-diversion-07.txt)" may be a solution if the PSTN gateway > or the SIP Billing server support it and knows that they have to bill > the sip-uri in the diversion header ( this is right ??? ). > > Regards; > > > > > -- Diego B MailVision Ltd. Tel. : +972-4-8500505 ext 13 e-mail: diegob@mailvision.com web : http://www.mailvision.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 May 18 10:50:58 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20553 for ; Tue, 18 May 2004 10:50: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 1BQ5qu-0006c1-2w for sip-archive@odin.ietf.org; Tue, 18 May 2004 10:45:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IEjuQN025371 for sip-archive@odin.ietf.org; Tue, 18 May 2004 10:45:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ5cU-0001sZ-SA; Tue, 18 May 2004 10: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 1BQ5X9-0000BC-09 for sip@optimus.ietf.org; Tue, 18 May 2004 10:25:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17872 for ; Tue, 18 May 2004 10:25:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ5X6-000262-Bo for sip@ietf.org; Tue, 18 May 2004 10:25:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ5WC-0001fm-00 for sip@ietf.org; Tue, 18 May 2004 10:24:33 -0400 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BQ5VB-00014m-00 for sip@ietf.org; Tue, 18 May 2004 10:23:33 -0400 Received: from nbaqi (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HXW0087JYKJLS@mta0.huawei.com> for sip@ietf.org; Tue, 18 May 2004 22:21:56 +0800 (CST) Date: Tue, 18 May 2004 22:24:33 +0800 From: Karthik M Subject: Re: [Sip] Load Balancing In SIP To: sip@ietf.org Cc: ajaym@huawei.com, santoshnath@huawei.com, liyan@huawei.com Message-id: <003101c43ce3$d71951a0$7269460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Mailer: Microsoft Outlook Express 5.50.4927.1200 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-imss-version: 2.5 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:18 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:3 R:3 (0.0000 0.0000) References: <0HXW00MP8E2XXE@maila.huawei.com> <001301c43cb5$4716a4f0$7269460a@china.huawei.com> <40AA1728.4010900@cs.columbia.edu> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Dear Henning schulzrinne, Load balancer in vovida.org does HA thru peer LBs. I think it provides similar feature what i require. the problem with that is there is no dynamic load adjusting based on the server performance.Also i dont like the idea of session data being updated in the peer for every call data. I thought of something like session data to be carried along with the dialog message like JSession in HTTP request (may be its difficult) and send to the peer LB and LB proxy will take care of the identifying the session, dispatching it to the backend server. If you see weblogic application server, they identify the server cluster details using the cookie as shown : sessionid!primary_server_id!secondary_server_id In this case, i can have a standy peer LB which will take care when the primary LB goes down. also the LB details are not in the LB proxy but in the message. so any stateless LB can dyamically discover the servers and dispatch. Let me know if i am wrong somewhere or please provide your ideas. Thansk Karthik ----- Original Message ----- From: "Henning Schulzrinne" To: "Karthik M" Cc: "MARJOU Xavier FTRD/DAC/LAN" ; Sent: Tuesday, May 18, 2004 10:01 PM Subject: Re: [Sip] Load Balancing In SIP > As soon as you have a load balancer, you have introduced another single > point of failure. Session affinity can easily be assured by SIP routing > means. It seems dangerous to extrapolate the HTTP architecture to SIP - > the issues, tools and problems are rather different. > > Karthik M wrote: > > > Dear Xavier and all, > > First of all, thanks for your info. > > I think DNS solution are good only for scalability in equal weighted > > servers and they cant dynamically adjust the load on the fly. Also DNS > > Updates are to be done by the server which most of the time is not in > > our control. High availability is difficult to achieve with the DNS > > based LB. So, this may be good for a public proxy kind of scenario but > > not for a app server kind of thing. > > I am looking for more generic solution for LB's, where the LB system > > takes care of adusting the load dynamically, do session affinity, > > provide high availablility for the LB system. This means that i have > > only one outbound proxy (LB system) and whole cluster is hidden behind that. > > Expecting your valuable comments on this and details abt any current > > implementations( both commerical/open source). > > > > Thanks > > Karthik M > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 19 01:25:05 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14064 for ; Wed, 19 May 2004 01:25:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQJUH-0004bw-MS for sip-archive@odin.ietf.org; Wed, 19 May 2004 01:19:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4J5JTp1017724 for sip-archive@odin.ietf.org; Wed, 19 May 2004 01:19:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQJM9-0003QT-Lx; Wed, 19 May 2004 01:11:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQJDq-00017I-3Q for sip@optimus.ietf.org; Wed, 19 May 2004 01:02: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 BAA12910 for ; Wed, 19 May 2004 01:02:28 -0400 (EDT) From: sayan.chowdhury@wipro.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQJDn-0005m8-9s for sip@ietf.org; Wed, 19 May 2004 01:02:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQJCo-0005e7-00 for sip@ietf.org; Wed, 19 May 2004 01:01:27 -0400 Received: from wiproecmx2.wipro.com ([164.164.31.6]) by ietf-mx with esmtp (Exim 4.12) id 1BQJBy-0005QN-00; Wed, 19 May 2004 01:00:35 -0400 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx2.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i4J4xuMP028373; Wed, 19 May 2004 10:29:58 +0530 (IST) Received: from blr-ec-bh1.wipro.com ([10.200.50.91]) by ec-vwall-wd with InterScan Messaging Security Suite; Wed, 19 May 2004 10:29:56 +0530 Received: from blr-ec-msg04.wipro.com ([10.200.53.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 19 May 2004 10:29:55 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43D5E.1FDF7C01" Subject: RE: [Sip] SIP Forward, Who pays the bill ? Date: Wed, 19 May 2004 10:29:54 +0530 Message-ID: Thread-Topic: [Sip] SIP Forward, Who pays the bill ? Thread-Index: AcQ85ntCQ3lv2SdwTcebQ0ykeNambQAdPKre To: , Cc: , , X-OriginalArrivalTime: 19 May 2004 04:59:55.0657 (UTC) FILETIME=[209C9790:01C43D5E] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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_01C43D5E.1FDF7C01 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxzbyAsIEFsaWNlIG1pZ2h0IGJlIHNlbmRpbmcgdGhlIHJlLWludml0ZSB0byBvbiByZWNlaXB0 IG9mIGEgMzAyIGZyb20gQm9iLiBTbyB0aGUgc2V0IG9mIHByb3hpZXMgaW52bG92ZWQgaW4gdGhl IGZpcnN0IGxlZyBvZiB0aGUgY2FsbCBtYXkgbm90IGJlIGludm9sdmVkIGluIHRoZSBzZWNvbmQg Pw0KU29sdXR1aW9uIHRvIHRoaXMgd2lsbCBiZSBvbiB0aGUgUFNUTiBnYXRld2F5IHNpZGUuDQpU aGUgUFNUTiBnYXRld2F5IHNob3VsZCBsb29rIGZvciBhbmQgYmlsbCBmcm9tIERpdmVyc2lvbi9S ZXF1ZXN0IEhpc3RvcnkvcmVtb3RlIFBhcnQgSGVhZGVyIGluZm9ybWF0aW9uIGluIHByZWZlcmVu Y2UgdG8gdGhlIGZyb20gaGVhZGVyIHdoaWNoIGlzIHVucmVsaWFibGUgYW55IHdheS4NCkhvd2V2 ZXIgLCBJIGRvIG5vdCBrbm93IG9mIGFueSBzdGFuZGFyZHMgd2hpY2ggZXhwbGljaXRseSBtZW50 aW9ucyB0aGF0IC4uDQogDQpSZWdhcmRzICwNClNheWFuDQogDQoNCgktLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLSANCglGcm9tOiBzaXAtYWRtaW5AaWV0Zi5vcmcgb24gYmVoYWxmIG9mIERpZWdv IEIgDQoJU2VudDogVHVlIDUvMTgvMjAwNCA3OjQ0IFBNIA0KCVRvOiBiYXJ1Y2hAa2F5b3RlLmNv bSANCglDYzogc2lwQGlldGYub3JnOyAnc2lwcGluZyc7ICdDdWxsZW4gSmVubmluZ3MnIA0KCVN1 YmplY3Q6IFJlOiBbU2lwXSBTSVAgRm9yd2FyZCwgV2hvIHBheXMgdGhlIGJpbGwgPw0KCQ0KCQ0K DQoJSGkgQmFydWNoOw0KCVRoYW5rcyBmb3IgeW91ciBhbnN3ZXIuDQoJSSBiZWxpdmUgdGhhdCB5 b3UgYXJlIGltcGxlbWVudGluZyBhIHByb3ByaWV0YXJ5IHNvbHV0aW9uIHRvIGRlYWwgd2l0aCBp dC4NCglJJ20gbG9va2luZyBtb3JlIHRvIGEgc3RhbmRhcml6ZSB3YXkgdG8gZGVhbCB3aXRoIHRo ZSBzZWNvbmQtbGVnIGlzc3VlLg0KCQ0KCUknbSBhZ3JlZSB0aGF0IEFsaWNlIGhhcyB0byBwYXkg Zm9yIHRoZSBmaXJzdCBsZWcgYW5kIEJvYiBmb3IgdGhlDQoJc2Vjb25kLCBidXQgaWYgdGhlIFBy b3h5IHRoYXQgaXMgZG9pbmcgdGhlIGZvcndhcmQgaXMgbm90IGEgYmlsaW5nDQoJZW50aXR5ICgg bG9jYWwgY2FsbHMgYXJlIGZyZWUsIG91dGJvdW5kIGNhbGwgYXJlIG5vdCBmcmVlIGFuZCBiaWxs ZWQgYnkNCglhbiBleHRlcm5hbCByZWFsLXRpbWUgYmlsbGluZyBzeXN0ZW0gY29ubmVjdGVkIHRv IHRoZSBHVyB1c2luZyBSQURJVVMgb3INCglzaW1pbGFyKSwgdGhlIFBTVE4gZ2F0ZXdheSB3aWxs IGhhdmUgdG8ga25vdyB0aGF0IHRoaXMgY2FsbCBtYXkgYmUNCgliaWxsZWQgdG8gQm9iIGFuZCBu b3QgdG8gQWxpY2UgKCBzaGUgYXBlYXJzIGluIHRoZSBGcm9tIGhlYWRlciApLg0KCQ0KCVRoYW5r cw0KCQ0KCUJhcnVjaCBTdGVybWFuIHdyb3RlOg0KCQ0KCT4gSW4gdGhlIHN5c3RlbXMgdGhhdCB3 ZSBpbXBsZW1lbnRlZCwgdHdvIGNkcnMgYXJlIGNyZWF0ZWQ6IHRoZSBmaXJzdCBmb3INCgk+IHRo ZSBpbmNvbWluZyBsZWcgKEFsaWNlIHRvIEJvYidzIG5vbi1mb3J3YXJkZWQgbG9jYXRpb24pIGFu ZCBhIHNlY29uZA0KCT4gZm9yIHRoZSBmb3J3YXJkIHRvIEJvYidzIGZvcndhcmRlZCBsb2NhdGlv bi4NCgk+DQoJPiBBbGljZSB3b3VsZCBwYXkgZm9yIHRoZSBmaXJzdCBsZWcsIGFuZCBCb2IgcGF5 cyBmb3IgdGhlIHNlY29uZC4NCgk+DQoJPiBGdXJ0aGVybW9yZSwgaXQgbWF5IGJlIHRoZSBjYXNl IHRoYXQgQm9iIHBheXMgZm9yIHRoZSBmaXJzdCBsZWcgYXMgd2VsbC4NCgk+IElmLCBmb3IgZXhh bXBsZSwgQm9iIGhhcyBhIHRvbGwgZnJlZSBudW1iZXIgd2hlcmUgaGUgcGF5cyBwZXIgbWludXRl DQoJPiBjaGFyZ2VzIGZvciB0aGUgaW5ib3VuZCBsZWcgKGluIHRoaXMgY2FzZSwgQWxpY2UgaXMg b24gdGhlIFBTVE4pLg0KCT4NCgk+IEVpdGhlciB3YXksIG11bHRpcGxlIENEUnMgaXMgdGhlIHdh eSB3ZSBjYW1lIHVwIHdpdGggdG8gaGFuZGxlIHRoaXMuDQoJPiBDYXJlIGhhcyB0byBiZSB0YWtl biB0aGF0IHRoZSBrZXkgdG8gYW55IENEUiBkYXRhYmFzZSBpcyBOT1QgdGhlDQoJPiBjYWxsLUlE LCBiZWNhdXNlIHRoaXMgaXMgdGhlIHNhbWUgYWNyb3NzIHRoZSB0d28gQ0RScy4NCgk+DQoJPiBC YXJ1Y2gNCgk+DQoJPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KCT4gRnJvbTogc2lwLWFk bWluQGlldGYub3JnIFttYWlsdG86c2lwLWFkbWluQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGll Z28NCgk+IEINCgk+IFNlbnQ6IFR1ZXNkYXksIE1heSAxOCwgMjAwNCA3OjQyIEFNDQoJPiBUbzog c2lwQGlldGYub3JnOyBzaXBwaW5nDQoJPiBDYzogQ3VsbGVuIEplbm5pbmdzDQoJPiBTdWJqZWN0 OiBbU2lwXSBTSVAgRm9yd2FyZCwgV2hvIHBheXMgdGhlIGJpbGwgPw0KCT4NCgk+IEhpOw0KCT4g TXkgcXVlc3Rpb24gaXMgcmVnYXJkaW5nIGJpbGxpbmcgYSBmb3J3YXJkZWQgc2lwIGNhbGwuDQoJ Pg0KCT4gTGV0cyB0YWtlIHRoZSBleG1wbGUgZnJvbSBkcmFmdC1pZXRmLXNpcHBpbmctc2Vydmlj ZS1leGFtcGxlcw0KCT4gMi43DQoJPg0KCT4gQWxpY2UgY2FsbHMgQm9iLCBhbmQgQm9iIGhhcyBh bGwgaGlzIGluY29tbWluZyBjYWxscyBmb3J3YXJkZWQgdG8gdGhlDQoJPiBQU1ROLg0KCT4NCgk+ IExldCBzYXkgdGhhdCBjYWxscyBmcm9tIEFMaWNlIHRvIEJvYiBpbiB0aGUgc2FtZSBkb21haW4g YXJlIGZyZWUgKHNhbWUNCgk+IG9mZmljZSwgb3Igc2FtZSBJVFNQKSwgYnV0IGNhbGxzIHRvIHRo ZSBQU1ROIGFyZSBub3QgZnJlZS4NCgk+DQoJPiBXaG8gcGF5cyBmb3IgQWxpY2UgY2FsbCB0byBC b2IgPz8NCgk+IEluIGEgbm9ybWFsIHNpdHVhY2lvbiwgQWxpY2Uga25vd3MgdGhhdCB0aGUgY2Fs bCBpcyBmb3IgZnJlZSBiZWN1YXNlIHNoZQ0KCT4NCgk+IGlzIGNhbGxpbmcgQm9iJ3Mgc2lwIG51 bWJlci4gQnV0IHRoZSBnYXRld2VheSBtYXkgY3JlYXRlIENEUiBmcm9tIHRoZQ0KCT4gIEZyb20g aGVhZGVyIG9mIHRoZSBTSVAgbWVzc2FnZSBhbmQgYXQgdGhlIGVuZCBvZiB0aGUgbW9udGggQWxp Y2UgbWF5DQoJPiBoYXZlIHRvIHBheSBmb3IgdGhlIGNhbGwuDQoJPg0KCT4gSSBzZWUgdGhpcyBr aW5kIG9mIGV4YW1wbGVzIGluIHNldmVyYWwgb3RoZXIgZHJhZnRzL1JGQyByZWxhdGVkIHRvIFNJ UA0KCT4gc2VydmljZXMgYW5kIGNhbGwgZm9yd2FyZC4NCgk+DQoJPiBJIGJlbGl2ZSBmb3J3YXJk IGlzIGEgdmVyeSBpbXBvcnRhbnQgZmVhdHVyZSwgYnV0IHRoaXMgaXNzdWUgbWF5IGJlDQoJPiBy ZXNvbHZlZC4gVGhlIHF1ZXN0aW9uIGlzIGlmIGl0IGlzIGEgc3RhbmRhcmQgd2F5IHRvIG1ha2Ug Qm9iIHBheXMgZm9yDQoJPiB0aGUgc2Vjb25kIGxlZyBvZiB0aGUgY2FsbCBsaWtlIGluIFBTVE4g Zm9yd2FyZC4NCgk+DQoJPiBNYXliZSBjaGFuZ2luZyB0aGUgRnJvbSBoZWFkZXIgd2hlcmUgYXBw bGljYWJsZSBhbmQgYWRkaW5nIGEgbmV3IG9uZSB0bw0KCT4gInJlbWVtYmVyIiB0aGF0IHRoZSBj YWxsIGlzIGZyb20sIGluIG15IGV4YW1wbGUsIEFsaWNlLg0KCT4NCgk+IFRoZSBkaXZlcnNpb24g aGVhZGVyIChEaXZlcnNpb24gSW5kaWNhdGlvbiBpbiBTSVANCgk+IGRyYWZ0LWxldnktc2lwLWRp dmVyc2lvbi0wNy50eHQpIiBtYXkgYmUgYSBzb2x1dGlvbiBpZiB0aGUgUFNUTiBnYXRld2F5DQoJ PiBvciB0aGUgU0lQIEJpbGxpbmcgc2VydmVyIHN1cHBvcnQgaXQgYW5kIGtub3dzIHRoYXQgdGhl eSBoYXZlIHRvIGJpbGwNCgk+IHRoZSBzaXAtdXJpIGluIHRoZSBkaXZlcnNpb24gaGVhZGVyICgg dGhpcyBpcyByaWdodCA/Pz8gKS4NCgk+DQoJPiBSZWdhcmRzOw0KCT4NCgk+DQoJPg0KCT4NCgk+ DQoJDQoJLS0NCglEaWVnbyBCDQoJTWFpbFZpc2lvbiBMdGQuDQoJVGVsLiAgOiDvnr00LTg1MDA1 MDUgZXh0IDEzDQoJZS1tYWlsOiBkaWVnb2JAbWFpbHZpc2lvbi5jb20NCgl3ZWIgICA6IGh0dHA6 Ly93d3cubWFpbHZpc2lvbi5jb20gPGh0dHBzOi8vZ2F0ZXdheS1pbmRpYS53aXByby5jb20vLERh bmFJbmZvPXd3dy5tYWlsdmlzaW9uLmNvbT4gDQoJDQoJDQoJDQoJX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCglTaXAgbWFpbGluZyBsaXN0ICBodHRwczov L3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXAgPGh0dHBzOi8vZ2F0ZXdheS1pbmRp YS53aXByby5jb20vbWFpbG1hbi9saXN0aW5mby9zaXAsRGFuYUluZm89d3d3MS5pZXRmLm9yZyxT U0w+IA0KCVRoaXMgbGlzdCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRoZSBjb3JlIFNJUCBQ cm90b2NvbA0KCVVzZSBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3IgcXVlc3Rp b25zIG9uIGN1cnJlbnQgc2lwDQoJVXNlIHNpcHBpbmdAaWV0Zi5vcmcgZm9yIG5ldyBkZXZlbG9w bWVudHMgb24gdGhlIGFwcGxpY2F0aW9uIG9mIHNpcA0KCQ0KDQo= ------_=_NextPart_001_01C43D5E.1FDF7C01 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPg0KPCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8v RU4iPg0KPEhUTUw+DQo8SEVBRD4NCg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5UPSJN UyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA2LjAuNjUyMS4wIj4NCjxUSVRMRT5SZTogW1NpcF0g U0lQIEZvcndhcmQsIFdobyBwYXlzIHRoZSBiaWxsID88L1RJVExFPg0KPC9IRUFEPg0KPEJPRFkg ZGlyPWx0cj4NCjxESVY+QWxzbyAsIEFsaWNlIG1pZ2h0IGJlIHNlbmRpbmcgdGhlIHJlLWludml0 ZSB0byBvbiByZWNlaXB0IG9mIGEgMzAyIGZyb20gDQpCb2IuIFNvIHRoZSBzZXQgb2YgcHJveGll cyBpbnZsb3ZlZCBpbiB0aGUgZmlyc3QgbGVnIG9mIHRoZSBjYWxsIG1heSBub3QgYmUgDQppbnZv bHZlZCBpbiB0aGUgc2Vjb25kID88L0RJVj4NCjxESVY+U29sdXR1aW9uIHRvIHRoaXMgd2lsbCBi ZSBvbiB0aGUgUFNUTiBnYXRld2F5IHNpZGUuPC9ESVY+DQo8RElWPlRoZSBQU1ROIGdhdGV3YXkg c2hvdWxkIGxvb2sgZm9yIGFuZCBiaWxsIGZyb20gRGl2ZXJzaW9uL1JlcXVlc3QgDQpIaXN0b3J5 L3JlbW90ZSBQYXJ0IEhlYWRlciBpbmZvcm1hdGlvbiBpbiBwcmVmZXJlbmNlIHRvIHRoZSBmcm9t IGhlYWRlciB3aGljaCBpcyANCnVucmVsaWFibGUgYW55IHdheS48L0RJVj4NCjxESVY+SG93ZXZl ciAsIEkgZG8gbm90IGtub3cgb2YgYW55IHN0YW5kYXJkcyB3aGljaCBleHBsaWNpdGx5IG1lbnRp b25zIHRoYXQgDQouLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+UmVnYXJkcyAsPC9E SVY+DQo8RElWPlNheWFuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPEJMT0NLUVVPVEUgZGly PWx0ciBzdHlsZT0iTUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8RElWPjxGT05UIHNpemU9Mj4tLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSA8QlI+PEI+RnJvbTo8L0I+IA0KICBzaXAtYWRtaW5AaWV0 Zi5vcmcmbmJzcDtvbiBiZWhhbGYgb2YmbmJzcDtEaWVnbyBCIDxCUj48Qj5TZW50OjwvQj4gVHVl IA0KICA1LzE4LzIwMDQgNzo0NCBQTSA8QlI+PEI+VG86PC9CPiBiYXJ1Y2hAa2F5b3RlLmNvbSA8 QlI+PEI+Q2M6PC9CPiANCiAgc2lwQGlldGYub3JnOyAnc2lwcGluZyc7ICdDdWxsZW4gSmVubmlu Z3MnIDxCUj48Qj5TdWJqZWN0OjwvQj4gUmU6IFtTaXBdIFNJUCANCiAgRm9yd2FyZCwgV2hvIHBh eXMgdGhlIGJpbGwgPzxCUj48QlI+PC9GT05UPjwvRElWPg0KICA8UD48Rk9OVCBzaXplPTI+SGkg QmFydWNoOzxCUj5UaGFua3MgZm9yIHlvdXIgYW5zd2VyLjxCUj5JIGJlbGl2ZSB0aGF0IHlvdSBh cmUgDQogIGltcGxlbWVudGluZyBhIHByb3ByaWV0YXJ5IHNvbHV0aW9uIHRvIGRlYWwgd2l0aCBp dC48QlI+SSdtIGxvb2tpbmcgbW9yZSB0byBhIA0KICBzdGFuZGFyaXplIHdheSB0byBkZWFsIHdp dGggdGhlIHNlY29uZC1sZWcgaXNzdWUuPEJSPjxCUj5JJ20gYWdyZWUgdGhhdCBBbGljZSANCiAg aGFzIHRvIHBheSBmb3IgdGhlIGZpcnN0IGxlZyBhbmQgQm9iIGZvciB0aGU8QlI+c2Vjb25kLCBi dXQgaWYgdGhlIFByb3h5IHRoYXQgDQogIGlzIGRvaW5nIHRoZSBmb3J3YXJkIGlzIG5vdCBhIGJp bGluZzxCUj5lbnRpdHkgKCBsb2NhbCBjYWxscyBhcmUgZnJlZSwgDQogIG91dGJvdW5kIGNhbGwg YXJlIG5vdCBmcmVlIGFuZCBiaWxsZWQgYnk8QlI+YW4gZXh0ZXJuYWwgcmVhbC10aW1lIGJpbGxp bmcgDQogIHN5c3RlbSBjb25uZWN0ZWQgdG8gdGhlIEdXIHVzaW5nIFJBRElVUyBvcjxCUj5zaW1p bGFyKSwgdGhlIFBTVE4gZ2F0ZXdheSB3aWxsIA0KICBoYXZlIHRvIGtub3cgdGhhdCB0aGlzIGNh bGwgbWF5IGJlPEJSPmJpbGxlZCB0byBCb2IgYW5kIG5vdCB0byBBbGljZSAoIHNoZSANCiAgYXBl YXJzIGluIHRoZSBGcm9tIGhlYWRlciApLjxCUj48QlI+VGhhbmtzPEJSPjxCUj5CYXJ1Y2ggU3Rl cm1hbiANCiAgd3JvdGU6PEJSPjxCUj4mZ3Q7IEluIHRoZSBzeXN0ZW1zIHRoYXQgd2UgaW1wbGVt ZW50ZWQsIHR3byBjZHJzIGFyZSBjcmVhdGVkOiANCiAgdGhlIGZpcnN0IGZvcjxCUj4mZ3Q7IHRo ZSBpbmNvbWluZyBsZWcgKEFsaWNlIHRvIEJvYidzIG5vbi1mb3J3YXJkZWQgbG9jYXRpb24pIA0K ICBhbmQgYSBzZWNvbmQ8QlI+Jmd0OyBmb3IgdGhlIGZvcndhcmQgdG8gQm9iJ3MgZm9yd2FyZGVk IA0KICBsb2NhdGlvbi48QlI+Jmd0OzxCUj4mZ3Q7IEFsaWNlIHdvdWxkIHBheSBmb3IgdGhlIGZp cnN0IGxlZywgYW5kIEJvYiBwYXlzIGZvciANCiAgdGhlIHNlY29uZC48QlI+Jmd0OzxCUj4mZ3Q7 IEZ1cnRoZXJtb3JlLCBpdCBtYXkgYmUgdGhlIGNhc2UgdGhhdCBCb2IgcGF5cyBmb3IgDQogIHRo ZSBmaXJzdCBsZWcgYXMgd2VsbC48QlI+Jmd0OyBJZiwgZm9yIGV4YW1wbGUsIEJvYiBoYXMgYSB0 b2xsIGZyZWUgbnVtYmVyIA0KICB3aGVyZSBoZSBwYXlzIHBlciBtaW51dGU8QlI+Jmd0OyBjaGFy Z2VzIGZvciB0aGUgaW5ib3VuZCBsZWcgKGluIHRoaXMgY2FzZSwgDQogIEFsaWNlIGlzIG9uIHRo ZSBQU1ROKS48QlI+Jmd0OzxCUj4mZ3Q7IEVpdGhlciB3YXksIG11bHRpcGxlIENEUnMgaXMgdGhl IHdheSB3ZSANCiAgY2FtZSB1cCB3aXRoIHRvIGhhbmRsZSB0aGlzLjxCUj4mZ3Q7IENhcmUgaGFz IHRvIGJlIHRha2VuIHRoYXQgdGhlIGtleSB0byBhbnkgDQogIENEUiBkYXRhYmFzZSBpcyBOT1Qg dGhlPEJSPiZndDsgY2FsbC1JRCwgYmVjYXVzZSB0aGlzIGlzIHRoZSBzYW1lIGFjcm9zcyB0aGUg DQogIHR3byBDRFJzLjxCUj4mZ3Q7PEJSPiZndDsgQmFydWNoPEJSPiZndDs8QlI+Jmd0OyAtLS0t LU9yaWdpbmFsIA0KICBNZXNzYWdlLS0tLS08QlI+Jmd0OyBGcm9tOiBzaXAtYWRtaW5AaWV0Zi5v cmcgWzxBIA0KICBocmVmPSJtYWlsdG86c2lwLWFkbWluQGlldGYub3JnIj5tYWlsdG86c2lwLWFk bWluQGlldGYub3JnPC9BPl0gT24gQmVoYWxmIE9mIA0KICBEaWVnbzxCUj4mZ3Q7IEI8QlI+Jmd0 OyBTZW50OiBUdWVzZGF5LCBNYXkgMTgsIDIwMDQgNzo0MiBBTTxCUj4mZ3Q7IFRvOiANCiAgc2lw QGlldGYub3JnOyBzaXBwaW5nPEJSPiZndDsgQ2M6IEN1bGxlbiBKZW5uaW5nczxCUj4mZ3Q7IFN1 YmplY3Q6IFtTaXBdIFNJUCANCiAgRm9yd2FyZCwgV2hvIHBheXMgdGhlIGJpbGwgPzxCUj4mZ3Q7 PEJSPiZndDsgSGk7PEJSPiZndDsgTXkgcXVlc3Rpb24gaXMgDQogIHJlZ2FyZGluZyBiaWxsaW5n IGEgZm9yd2FyZGVkIHNpcCBjYWxsLjxCUj4mZ3Q7PEJSPiZndDsgTGV0cyB0YWtlIHRoZSBleG1w bGUgDQogIGZyb20gZHJhZnQtaWV0Zi1zaXBwaW5nLXNlcnZpY2UtZXhhbXBsZXM8QlI+Jmd0OyAy Ljc8QlI+Jmd0OzxCUj4mZ3Q7IEFsaWNlIA0KICBjYWxscyBCb2IsIGFuZCBCb2IgaGFzIGFsbCBo aXMgaW5jb21taW5nIGNhbGxzIGZvcndhcmRlZCB0byB0aGU8QlI+Jmd0OyANCiAgUFNUTi48QlI+ Jmd0OzxCUj4mZ3Q7IExldCBzYXkgdGhhdCBjYWxscyBmcm9tIEFMaWNlIHRvIEJvYiBpbiB0aGUg c2FtZSBkb21haW4gDQogIGFyZSBmcmVlIChzYW1lPEJSPiZndDsgb2ZmaWNlLCBvciBzYW1lIElU U1ApLCBidXQgY2FsbHMgdG8gdGhlIFBTVE4gYXJlIG5vdCANCiAgZnJlZS48QlI+Jmd0OzxCUj4m Z3Q7IFdobyBwYXlzIGZvciBBbGljZSBjYWxsIHRvIEJvYiA/PzxCUj4mZ3Q7IEluIGEgbm9ybWFs IA0KICBzaXR1YWNpb24sIEFsaWNlIGtub3dzIHRoYXQgdGhlIGNhbGwgaXMgZm9yIGZyZWUgYmVj dWFzZSBzaGU8QlI+Jmd0OzxCUj4mZ3Q7IA0KICBpcyBjYWxsaW5nIEJvYidzIHNpcCBudW1iZXIu IEJ1dCB0aGUgZ2F0ZXdlYXkgbWF5IGNyZWF0ZSBDRFIgZnJvbSANCiAgdGhlPEJSPiZndDsmbmJz cDsgRnJvbSBoZWFkZXIgb2YgdGhlIFNJUCBtZXNzYWdlIGFuZCBhdCB0aGUgZW5kIG9mIHRoZSBt b250aCANCiAgQWxpY2UgbWF5PEJSPiZndDsgaGF2ZSB0byBwYXkgZm9yIHRoZSBjYWxsLjxCUj4m Z3Q7PEJSPiZndDsgSSBzZWUgdGhpcyBraW5kIG9mIA0KICBleGFtcGxlcyBpbiBzZXZlcmFsIG90 aGVyIGRyYWZ0cy9SRkMgcmVsYXRlZCB0byBTSVA8QlI+Jmd0OyBzZXJ2aWNlcyBhbmQgY2FsbCAN CiAgZm9yd2FyZC48QlI+Jmd0OzxCUj4mZ3Q7IEkgYmVsaXZlIGZvcndhcmQgaXMgYSB2ZXJ5IGlt cG9ydGFudCBmZWF0dXJlLCBidXQgDQogIHRoaXMgaXNzdWUgbWF5IGJlPEJSPiZndDsgcmVzb2x2 ZWQuIFRoZSBxdWVzdGlvbiBpcyBpZiBpdCBpcyBhIHN0YW5kYXJkIHdheSB0byANCiAgbWFrZSBC b2IgcGF5cyBmb3I8QlI+Jmd0OyB0aGUgc2Vjb25kIGxlZyBvZiB0aGUgY2FsbCBsaWtlIGluIFBT VE4gDQogIGZvcndhcmQuPEJSPiZndDs8QlI+Jmd0OyBNYXliZSBjaGFuZ2luZyB0aGUgRnJvbSBo ZWFkZXIgd2hlcmUgYXBwbGljYWJsZSBhbmQgDQogIGFkZGluZyBhIG5ldyBvbmUgdG88QlI+Jmd0 OyAicmVtZW1iZXIiIHRoYXQgdGhlIGNhbGwgaXMgZnJvbSwgaW4gbXkgZXhhbXBsZSwgDQogIEFs aWNlLjxCUj4mZ3Q7PEJSPiZndDsgVGhlIGRpdmVyc2lvbiBoZWFkZXIgKERpdmVyc2lvbiBJbmRp Y2F0aW9uIGluIA0KICBTSVA8QlI+Jmd0OyBkcmFmdC1sZXZ5LXNpcC1kaXZlcnNpb24tMDcudHh0 KSIgbWF5IGJlIGEgc29sdXRpb24gaWYgdGhlIFBTVE4gDQogIGdhdGV3YXk8QlI+Jmd0OyBvciB0 aGUgU0lQIEJpbGxpbmcgc2VydmVyIHN1cHBvcnQgaXQgYW5kIGtub3dzIHRoYXQgdGhleSBoYXZl IA0KICB0byBiaWxsPEJSPiZndDsgdGhlIHNpcC11cmkgaW4gdGhlIGRpdmVyc2lvbiBoZWFkZXIg KCB0aGlzIGlzIHJpZ2h0ID8/PyANCiAgKS48QlI+Jmd0OzxCUj4mZ3Q7IA0KICBSZWdhcmRzOzxC Uj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDs8QlI+PEJSPi0tPEJSPkRpZWdv IA0KICBCPEJSPk1haWxWaXNpb24gTHRkLjxCUj5UZWwuJm5ic3A7IDog7569NC04NTAwNTA1IGV4 dCAxMzxCUj5lLW1haWw6IA0KICBkaWVnb2JAbWFpbHZpc2lvbi5jb208QlI+d2ViJm5ic3A7Jm5i c3A7IDogPEEgDQogIGhyZWY9Imh0dHBzOi8vZ2F0ZXdheS1pbmRpYS53aXByby5jb20vLERhbmFJ bmZvPXd3dy5tYWlsdmlzaW9uLmNvbSI+aHR0cDovL3d3dy5tYWlsdmlzaW9uLmNvbTwvQT48QlI+ PEJSPjxCUj48QlI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188QlI+U2lwIA0KICBtYWlsaW5nIGxpc3QmbmJzcDsgPEEgDQogIGhyZWY9Imh0dHBzOi8vZ2F0 ZXdheS1pbmRpYS53aXByby5jb20vbWFpbG1hbi9saXN0aW5mby9zaXAsRGFuYUluZm89d3d3MS5p ZXRmLm9yZyxTU0wiPmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcDwv QT48QlI+VGhpcyANCiAgbGlzdCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRoZSBjb3JlIFNJ UCBQcm90b2NvbDxCUj5Vc2UgDQogIHNpcC1pbXBsZW1lbnRvcnNAY3MuY29sdW1iaWEuZWR1IGZv ciBxdWVzdGlvbnMgb24gY3VycmVudCBzaXA8QlI+VXNlIA0KICBzaXBwaW5nQGlldGYub3JnIGZv ciBuZXcgZGV2ZWxvcG1lbnRzIG9uIHRoZSBhcHBsaWNhdGlvbiBvZiANCnNpcDxCUj48L0ZPTlQ+ PC9QPjwvQkxPQ0tRVU9URT4NCg0KPC9CT0RZPg0KPC9IVE1MPg== ------_=_NextPart_001_01C43D5E.1FDF7C01-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 19 05:51:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25891 for ; Wed, 19 May 2004 05:51: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 1BQNQe-0002Zt-E2 for sip-archive@odin.ietf.org; Wed, 19 May 2004 05:32:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4J9Vwjv009838 for sip-archive@odin.ietf.org; Wed, 19 May 2004 05:31:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQN5R-0007UB-Iv; Wed, 19 May 2004 05:10:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ5Uy-0007TJ-C8 for sip@optimus.ietf.org; Tue, 18 May 2004 10:23: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 KAA17627 for ; Tue, 18 May 2004 10:23:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ5Uw-0001Dq-3z for sip@ietf.org; Tue, 18 May 2004 10:23:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ5U0-0000q2-00 for sip@ietf.org; Tue, 18 May 2004 10:22:17 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BQ5TR-0000SP-00; Tue, 18 May 2004 10:21:41 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i4IELeAh022890; Tue, 18 May 2004 16:21:40 +0200 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 May 2004 16:21:40 +0200 Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.60]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LFSY489V; Tue, 18 May 2004 16:22:16 +0200 Message-ID: <40AA1BF4.2000908@ericsson.com> Date: Tue, 18 May 2004 16:21:40 +0200 X-Sybari-Trust: 5a5e7d8b 08d63d2e 06b283dd 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: IETF AVT WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 May 2004 14:21:40.0449 (UTC) FILETIME=[6FD1F510:01C43CE3] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Sip] Soliciting comments on Offer/Answer procedures Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org 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, Any reply to this mail should be directed to the AVT mailing list. The mail is BCC to MMUSIC, SIP and SIPPING to avoid cross postings. In the RTP payload format for the H.264/AVC video codec, we authors had to write a rather special procedure in the offer/answer. This procedure is there to make the distribution of the video codecs parameter sets work. However we would like to have further review from people knowing SIP and Offer/Answer thoroughly, to ensure that we have not created any problems. Therefore I would be very thankful if you could take a look at: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-h264-06.txt and review the Offer/Answer consideration section (8.2). I wouldn't expect that you will need to read more than some further parts of section 8, and possibly some of the introduction in section 1 for background information. Any comments is desired within two weeks, i.e. before 9th of June. Thanks 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 May 19 07:01:58 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01016 for ; Wed, 19 May 2004 07:01:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQOgB-00039f-6M for sip-archive@odin.ietf.org; Wed, 19 May 2004 06:52:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JAq7x1012128 for sip-archive@odin.ietf.org; Wed, 19 May 2004 06:52:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQOXX-0001y5-0l; Wed, 19 May 2004 06:43:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQOOQ-0000Pr-RJ for sip@optimus.ietf.org; Wed, 19 May 2004 06:33:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29122 for ; Wed, 19 May 2004 06:33:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQOOM-0006J8-Mo for sip@ietf.org; Wed, 19 May 2004 06:33:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQONO-00067d-00 for sip@ietf.org; Wed, 19 May 2004 06:32:43 -0400 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1BQOMS-0005nd-00 for sip@ietf.org; Wed, 19 May 2004 06:31:44 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4JAVBq15771 for ; Wed, 19 May 2004 05:31:12 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 19 May 2004 11:31:10 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00439F08E@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Diego B'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] SIP Forward, Who pays the bill ? Date: Wed, 19 May 2004 11:31:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , To the best of my knowledge, IETF will not implement a charging solution. Nor will it standardise any particular user as paying for the call. What IETF has done, and will continue to do, is standardise the information that should be placed in various headers, such that when that information is transferred into a CDR (CDR format not specified by IETF), it can be used for appropriate billing. You can see a standardised billing model for the IMS specified for 3GPP in 3GPP TS 32.225 (for release 5) and 3GPP TS 32.260 (for release 6). Note that it is entirely possible that your media does not pass through the entities that are generating the CDRs based on signalling, in which case unless some CDRs are collected for the media as well, and some coordination performed, then you will have a model that only charges for the signalling. In your gateway case, I assume that this is not happening. regards Keith > -----Original Message----- > From: Diego B [mailto:diegob@mailvision.com] > Sent: 18 May 2004 15:14 > To: baruch@kayote.com > Cc: sip@ietf.org; 'sipping'; 'Cullen Jennings' > Subject: Re: [Sip] SIP Forward, Who pays the bill ? > > > Hi Baruch; > Thanks for your answer. > I belive that you are implementing a proprietary solution to > deal with it. > I'm looking more to a standarize way to deal with the > second-leg issue. > > I'm agree that Alice has to pay for the first leg and Bob for the > second, but if the Proxy that is doing the forward is not a biling > entity ( local calls are free, outbound call are not free and > billed by > an external real-time billing system connected to the GW > using RADIUS or > similar), the PSTN gateway will have to know that this call may be > billed to Bob and not to Alice ( she apears in the From header ). > > Thanks > > Baruch Sterman wrote: > > > In the systems that we implemented, two cdrs are created: > the first for > > the incoming leg (Alice to Bob's non-forwarded location) > and a second > > for the forward to Bob's forwarded location. > > > > Alice would pay for the first leg, and Bob pays for the second. > > > > Furthermore, it may be the case that Bob pays for the first > leg as well. > > If, for example, Bob has a toll free number where he pays per minute > > charges for the inbound leg (in this case, Alice is on the PSTN). > > > > Either way, multiple CDRs is the way we came up with to handle this. > > Care has to be taken that the key to any CDR database is NOT the > > call-ID, because this is the same across the two CDRs. > > > > Baruch > > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Diego > > B > > Sent: Tuesday, May 18, 2004 7:42 AM > > To: sip@ietf.org; sipping > > Cc: Cullen Jennings > > Subject: [Sip] SIP Forward, Who pays the bill ? > > > > Hi; > > My question is regarding billing a forwarded sip call. > > > > Lets take the exmple from draft-ietf-sipping-service-examples > > 2.7 > > > > Alice calls Bob, and Bob has all his incomming calls > forwarded to the > > PSTN. > > > > Let say that calls from ALice to Bob in the same domain are > free (same > > office, or same ITSP), but calls to the PSTN are not free. > > > > Who pays for Alice call to Bob ?? > > In a normal situacion, Alice knows that the call is for > free becuase she > > > > is calling Bob's sip number. But the gateweay may create > CDR from the > > From header of the SIP message and at the end of the month > Alice may > > have to pay for the call. > > > > I see this kind of examples in several other drafts/RFC > related to SIP > > services and call forward. > > > > I belive forward is a very important feature, but this issue may be > > resolved. The question is if it is a standard way to make > Bob pays for > > the second leg of the call like in PSTN forward. > > > > Maybe changing the From header where applicable and adding > a new one to > > "remember" that the call is from, in my example, Alice. > > > > The diversion header (Diversion Indication in SIP > > draft-levy-sip-diversion-07.txt)" may be a solution if the > PSTN gateway > > or the SIP Billing server support it and knows that they > have to bill > > the sip-uri in the diversion header ( this is right ??? ). > > > > Regards; > > > > > > > > > > > > -- > Diego B > MailVision Ltd. > Tel. : +972-4-8500505 ext 13 > e-mail: diegob@mailvision.com > web : http://www.mailvision.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 May 19 09:05:11 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08293 for ; Wed, 19 May 2004 09:05: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 1BQQWG-0006AQ-OB for sip-archive@odin.ietf.org; Wed, 19 May 2004 08:50:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JCo0Du023630 for sip-archive@odin.ietf.org; Wed, 19 May 2004 08:50:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQQKu-00049I-3a; Wed, 19 May 2004 08:38:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQPGj-00011w-K3 for sip@optimus.ietf.org; Wed, 19 May 2004 07:29:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02443 for ; Wed, 19 May 2004 07:29:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQPGj-0000Gs-00 for sip@ietf.org; Wed, 19 May 2004 07:29:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQPFm-000071-00 for sip@ietf.org; Wed, 19 May 2004 07:28:54 -0400 Received: from isozyme66.gprs.suomen2g.fi ([62.78.107.66] helo=localhost) by ietf-mx with esmtp (Exim 4.12) id 1BQPEu-0007bD-00 for sip@ietf.org; Wed, 19 May 2004 07:28:02 -0400 Received: from jh by localhost with local (Exim 3.35 #1 (Debian)) id 1BQPCG-0000Le-00; Wed, 19 May 2004 14:25:16 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16555.17435.742813.848388@tutpro.com> Date: Wed, 19 May 2004 14:25:15 +0300 To: Paul Kyzivat Cc: Eric Burger , "'sip@ietf.org'" Subject: Re: [Sip] Propogating URI parameter end to end In-Reply-To: <40A8B6F0.6060406@cisco.com> References: <40A8B6F0.6060406@cisco.com> X-Mailer: VM 7.17 under Emacs 21.2.1 From: Juha Heinanen X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Paul Kyzivat writes: > If it is the right thing to do for sip uri parameters, then it ought to > be the right thing to do for tel uri parameters too, as in: > > INVITE tel:12345;phone-context=foo.com > => > INVITE sip:fred.smith@foo.com;phone-context=foo.com > > Does that seem right? I don't think so. the above conversion doesn't make any sense at all. tel uri parameters should go before @ sign. conversion to INVITE sip:fred.smith@foo.com would be ok thought if the proxy somehow knows that 12345 in the given context maps to fred.smith@foo.com. > Also, what happens when going the other way: > > INVITE sip:john.jones@bar.com;xyzzy=mumble > => > INVITE tel:+1-321-555-1234;xyzzy=mumble > again, the example is totally bogus, because you cannot put tel uri params at the of sip uri. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed May 19 09:05:57 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08432 for ; Wed, 19 May 2004 09:05: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 1BQQZW-00070z-8A for sip-archive@odin.ietf.org; Wed, 19 May 2004 08:53:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JCrMgH026887 for sip-archive@odin.ietf.org; Wed, 19 May 2004 08:53:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQQL8-0004Dx-MS; Wed, 19 May 2004 08:38:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQPhx-00007w-Q0 for sip@optimus.ietf.org; Wed, 19 May 2004 07:58: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 HAA04041 for ; Wed, 19 May 2004 07:58:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQPhw-00059Y-R2 for sip@ietf.org; Wed, 19 May 2004 07:58:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQPhF-0004ys-00 for sip@ietf.org; Wed, 19 May 2004 07:57:17 -0400 Received: from isozyme66.gprs.suomen2g.fi ([62.78.107.66] helo=localhost) by ietf-mx with esmtp (Exim 4.12) id 1BQPgW-0004mA-00; Wed, 19 May 2004 07:56:33 -0400 Received: from jh by localhost with local (Exim 3.35 #1 (Debian)) id 1BQPen-0000Rl-00; Wed, 19 May 2004 14:54:45 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16555.19205.382814.474986@tutpro.com> Date: Wed, 19 May 2004 14:54:45 +0300 To: Diego B Cc: sip@ietf.org, sipping , Cullen Jennings Subject: [Sip] SIP Forward, Who pays the bill ? In-Reply-To: <40A9F672.6090008@mailvision.com> References: <40A9F672.6090008@mailvision.com> X-Mailer: VM 7.17 under Emacs 21.2.1 From: Juha Heinanen X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Diego B writes: > The diversion header (Diversion Indication in SIP > draft-levy-sip-diversion-07.txt)" may be a solution if the PSTN gateway > or the SIP Billing server support it and knows that they have to bill > the sip-uri in the diversion header ( this is right ??? ). yes, your proxy can use diversion header or remote-party-id header to make the forwarder to pay for the second leg. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed May 19 10:36:01 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15734 for ; Wed, 19 May 2004 10:36: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 1BQS05-00024a-O4 for sip-archive@odin.ietf.org; Wed, 19 May 2004 10:24:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JEOrC6007969 for sip-archive@odin.ietf.org; Wed, 19 May 2004 10:24:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQRfY-0002cs-Sp; Wed, 19 May 2004 10:03:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQR5n-0005Q2-Ur for sip@optimus.ietf.org; Wed, 19 May 2004 09:26: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 JAA10247 for ; Wed, 19 May 2004 09:26:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQR5m-0004dB-2N for sip@ietf.org; Wed, 19 May 2004 09:26:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQR4n-0004Ze-00 for sip@ietf.org; Wed, 19 May 2004 09:25:41 -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 1BQR3t-0004WB-00 for sip@ietf.org; Wed, 19 May 2004 09:24:45 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 19 May 2004 05:31:41 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i4JDOBaP006301; Wed, 19 May 2004 06:24:12 -0700 (PDT) Received: from cisco.com ([161.44.79.59]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIP17789; Wed, 19 May 2004 09:24:09 -0400 (EDT) Message-ID: <40AB6001.6060504@cisco.com> Date: Wed, 19 May 2004 09:24:17 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juha Heinanen CC: Eric Burger , "'sip@ietf.org'" Subject: Re: [Sip] Propogating URI parameter end to end References: <40A8B6F0.6060406@cisco.com> <16555.17435.742813.848388@tutpro.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 Juha, I think you miss my point. Not all uri's are sip uri's. A tel: uri is indeed a uri, and it even takes parameters in a syntax similar to that used for sip uris. And it doesn't have an @ sign. Other kinds of uris that might be encountered are pres: and im:. So it is possible when passing thru a proxy to have a sip uri coming in and another kind of uri going out, e.g. sip: in, tel: out, OR tel: in, sip: out. Lets consider another case for a moment: tel: in and tel: out. INVITE tel:12345;phone-context=foo.com => INVITE tel:+1-321-551-2345 in this case we certainly wouldn't say the phone-context parameter should be transferred. How about: INVITE sip:12345@foo.com;user=dial-string => INVITE sip:+1-321-551-2345@foo.com;user=phone We don't want the user parameter transferred here. Of course you can make up examples where transferring parameters is what you want, but I don't see a consistent set of rules that always does the right thing. The closest I can come is to say that this should only happen when both the input and output urls are sip (or sips), and only for parameters that have no meaning to the proxy. But "no meaning to the proxy" presents real problems when we start adding features that not all proxies support. Yuck! Also, isn't it a problem if your parameter might be lost because another kind of uri is used somewhere along the way? Paul Juha Heinanen wrote: > Paul Kyzivat writes: > > > If it is the right thing to do for sip uri parameters, then it ought to > > be the right thing to do for tel uri parameters too, as in: > > > > INVITE tel:12345;phone-context=foo.com > > => > > INVITE sip:fred.smith@foo.com;phone-context=foo.com > > > > Does that seem right? I don't think so. > > the above conversion doesn't make any sense at all. tel uri parameters > should go before @ sign. conversion to > > INVITE sip:fred.smith@foo.com > > would be ok thought if the proxy somehow knows that 12345 in the given > context maps to fred.smith@foo.com. > > > Also, what happens when going the other way: > > > > INVITE sip:john.jones@bar.com;xyzzy=mumble > > => > > INVITE tel:+1-321-555-1234;xyzzy=mumble > > > > again, the example is totally bogus, because you cannot put tel uri > params at the of sip uri. > > -- juha > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed May 19 15:30:26 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05856 for ; Wed, 19 May 2004 15:30:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQWAT-0003aK-Mh for sip-archive@odin.ietf.org; Wed, 19 May 2004 14:51:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JIpr12013744 for sip-archive@odin.ietf.org; Wed, 19 May 2004 14:51:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQVn9-0006Q4-Qf; Wed, 19 May 2004 14:27:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQSka-0003yr-DM for sip@optimus.ietf.org; Wed, 19 May 2004 11:12: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 LAA18340 for ; Wed, 19 May 2004 11:12:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQSkY-0004oP-Jv for sip@ietf.org; Wed, 19 May 2004 11:12:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQSjc-0004lM-00 for sip@ietf.org; Wed, 19 May 2004 11:11:56 -0400 Received: from allozyme248.gprs.suomen2g.fi ([62.78.104.248] helo=localhost) by ietf-mx with esmtp (Exim 4.12) id 1BQSjA-0004hK-00 for sip@ietf.org; Wed, 19 May 2004 11:11:30 -0400 Received: from jh by localhost with local (Exim 3.35 #1 (Debian)) id 1BQSgj-0000aE-00; Wed, 19 May 2004 18:08:57 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16555.30857.452962.924677@tutpro.com> Date: Wed, 19 May 2004 18:08:57 +0300 To: Paul Kyzivat Cc: Eric Burger , "'sip@ietf.org'" Subject: Re: [Sip] Propogating URI parameter end to end In-Reply-To: <40AB6001.6060504@cisco.com> References: <40A8B6F0.6060406@cisco.com> <16555.17435.742813.848388@tutpro.com> <40AB6001.6060504@cisco.com> X-Mailer: VM 7.17 under Emacs 21.2.1 From: Juha Heinanen X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Paul Kyzivat writes: > I think you miss my point. Not all uri's are sip uri's. A tel: uri is > indeed a uri, and it even takes parameters in a syntax similar to that > used for sip uris. And it doesn't have an @ sign. paul, i'm very well aware of that, since i just wrote a piece of code that translates a tel uri to sip uri and had to read the specs. if we get back to your original example: > > > INVITE tel:12345;phone-context=foo.com > > > => > > > INVITE sip:fred.smith@foo.com;phone-context=foo.com phone-context=foo.com is obviously a tel uri parameter, since it is included in a tel uri. according to section 19.1.6 Relating SIP URIs and tel URLs of rfc 3261, when you convert a tel uri to sip uri, tel uri params go BEFORE the @ sign. in your example, phone-context suddenly became a sip uri parameter, which it isn't and which made your example syntactically wrong. > Also, isn't it a problem if your parameter might be lost because another > kind of uri is used somewhere along the way? i agree with you on the subject matter. it was just the examples i criticized. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Wed May 19 15:33:00 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05993 for ; Wed, 19 May 2004 15:33: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 1BQWK2-000805-5p for sip-archive@odin.ietf.org; Wed, 19 May 2004 15:01:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JJ1kx5030673 for sip-archive@odin.ietf.org; Wed, 19 May 2004 15:01:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQVnX-0006ZJ-3Y; Wed, 19 May 2004 14:28:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQTTy-0001P7-PB for sip@optimus.ietf.org; Wed, 19 May 2004 11:59:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20011 for ; Wed, 19 May 2004 11:59:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQTTx-00005v-6R for sip@ietf.org; Wed, 19 May 2004 11:59:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQTT0-0007nh-00 for sip@ietf.org; Wed, 19 May 2004 11:58:51 -0400 Received: from [151.39.82.11] (helo=abbeynet.it) by ietf-mx with smtp (Exim 4.12) id 1BQTSG-0007dX-00 for sip@ietf.org; Wed, 19 May 2004 11:58:04 -0400 Received: (qmail 13241 invoked from network); 19 May 2004 15:57:30 -0000 Received: from localhost (HELO localhost.localdomain) (127.0.0.1) by 0 with SMTP; 19 May 2004 15:57:30 -0000 Received: from abbeynet.it (localhost.localdomain [127.0.0.1]) by localhost.localdomain (VaMailArmor-2.0.1.16) id 13229-30B7E341; Wed, 19 May 2004 17:57:30 +0200 Received: (qmail 13225 invoked from network); 19 May 2004 15:57:30 -0000 Received: from giacomo.localnet (HELO gia) (192.168.0.158) by 0 with SMTP; 19 May 2004 15:57:30 -0000 From: "Giacomo Vacca" To: Cc: Subject: R: [Sip] Symmetric response routing -> Or where to return a response to? Date: Wed, 19 May 2004 17:57:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcQ9rYv1ttvuhjNVS8C51e4IQ4YLQAAC5weg In-Reply-To: X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.25.0.3; VDF: 6.25.0.72; host: abbeynet.it) Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 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 "RFC 3581 states that SIP, when used with UDP, returns responses to the IP adress the request came from and to the port number contained in the topmost Via header of that request. This behaviour introduces a "hybrid" way of determining where to return the response to. I am somewhat surprised that the above behaviour is supposed to be SIP's "default" behaviour. The Via header will always contain a host name and may contain a port number. Wouldn't it then be the logical thing to do to return the response to the host address specified in the Via header? " The problem is that a SIP UA may send a message from one port, and wait for the answer to another port (i.e. send REGISTER from IP:4000, while listening for incoming SIP messages in IP:5060). Furthermore, if a UA is behind a NAT, IP and port in the Via header may be unreachable from outside the NAT and so the need is to send the answer to IP and port from wich the request arrived (i.e. Via: sip:ua@10.1.0.0:5060, but the request comes from 217.1.0.0:9000, that is the "hole" in the NAT) Bye Giacomo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip __________ NOD32 1.767 (20040518) Information __________ This message was checked by NOD32 antivirus system. http://www.nod32.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 May 19 17:31:33 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19139 for ; Wed, 19 May 2004 17:31:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQYIh-0000SB-ES for sip-archive@odin.ietf.org; Wed, 19 May 2004 17:08:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JL8VcT001726 for sip-archive@odin.ietf.org; Wed, 19 May 2004 17:08:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQXO3-00039P-6F; Wed, 19 May 2004 16:09:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQWzB-0004Ov-Ln for sip@optimus.ietf.org; Wed, 19 May 2004 15:44:17 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07734; Wed, 19 May 2004 15:44:15 -0400 (EDT) Message-Id: <200405191944.PAA07734@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: sip@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 19 May 2004 15:44:15 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-session-timer-14.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-14.txt Pages : 36 Date : 2004-5-19 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-14.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-session-timer-14.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-14.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: <2004-5-19153709.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-session-timer-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-session-timer-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-19153709.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 May 19 17:32:27 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19219 for ; Wed, 19 May 2004 17:32:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQYRi-0003BA-V7 for sip-archive@odin.ietf.org; Wed, 19 May 2004 17:17:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JLHoBq012150 for sip-archive@odin.ietf.org; Wed, 19 May 2004 17:17:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQXag-0007bL-1N; Wed, 19 May 2004 16:23:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQNcr-0006Cw-FT for sip@optimus.ietf.org; Wed, 19 May 2004 05:44: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 FAA25364 for ; Wed, 19 May 2004 05:44:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQNcn-0005bu-TK for sip@ietf.org; Wed, 19 May 2004 05:44:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQNbq-0005Sm-00 for sip@ietf.org; Wed, 19 May 2004 05:43:34 -0400 Received: from natnoddy.rzone.de ([81.169.145.166]) by ietf-mx with esmtp (Exim 4.12) id 1BQNas-0005GC-00 for sip@ietf.org; Wed, 19 May 2004 05:42:34 -0400 Received: from snom.de (pD9E0D7C2.dip.t-dialin.net [217.224.215.194]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i4J9e62b026587; Wed, 19 May 2004 11:40:06 +0200 (MEST) Message-ID: <40AB2BD4.4040805@snom.de> Date: Wed, 19 May 2004 11:41:40 +0200 From: Harry Behrens User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: sip@ietf.org Subject: Re: [Sip] Load Balancing In SIP References: <005e01c43c81$e46664e0$7269460a@china.huawei.com> <40AA06AB.6040909@cs.columbia.edu> In-Reply-To: <40AA06AB.6040909@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear Henning, I would be quite interested in that paper. Best regards from Berlin, Harry Henning Schulzrinne wrote: > We have a paper describing options for SIP load balancing. Contact > Kundan Singh (kns10@cs.columbia.edu) if you're interested in a preprint. > > Karthik M wrote: > >> Hello all, >> Can anyone provide me links/ideas on general load balancing >> solutions implemented in sip servers. I want to whether there are any >> hardware based load balancer similar to HTTP and its functionality. >> >> >> Thanks in advance >> Karthik M > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 May 19 17:32:36 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19287 for ; Wed, 19 May 2004 17:32: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 1BQYUQ-00045X-EX for sip-archive@odin.ietf.org; Wed, 19 May 2004 17:20:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4JLKcKL015685 for sip-archive@odin.ietf.org; Wed, 19 May 2004 17:20:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQXah-0007bX-Kp; Wed, 19 May 2004 16:23:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQNhl-0007mZ-Vd for sip@optimus.ietf.org; Wed, 19 May 2004 05:49: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 FAA25796 for ; Wed, 19 May 2004 05:49:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQNhi-0006cw-8U for sip@ietf.org; Wed, 19 May 2004 05:49:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQNgq-0006RQ-00 for sip@ietf.org; Wed, 19 May 2004 05:48:46 -0400 Received: from smtp005.bizmail.sc5.yahoo.com ([66.163.175.82]) by ietf-mx with smtp (Exim 4.12) id 1BQNfp-0006EJ-00 for sip@ietf.org; Wed, 19 May 2004 05:47:41 -0400 Received: from unknown (HELO BaruchLaptop) (baruch@kayote.com@208.170.170.247 with login) by smtp005.bizmail.sc5.yahoo.com with SMTP; 19 May 2004 09:47:26 -0000 Reply-To: From: "Baruch Sterman" To: , Cc: , , Subject: RE: [Sip] SIP Forward, Who pays the bill ? Date: Wed, 19 May 2004 05:47:07 -0400 Message-ID: <006d01c43d86$44d46a20$f7aaaad0@BaruchLaptop> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006E_01C43D64.BDC2CA20" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal In-Reply-To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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_006E_01C43D64.BDC2CA20 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Another avenue that can be explored is an explicit header to deal with = this and other accounting issues. I think that the AAA group has = suggested an ACCOUNTING header. We were thinking of a BILLING header. In = that header you would have a username and type. So as the call = progresses you could add to that header. This would also allow to charge = for various services along the way. Imagine the following. Alice calls = Bob, Bob forwards to Charlie who requires an ENUM lookup to find his IP = =E2=80=93 and you are dealing with a psychotic ITSP that *Charges* for = ENUM listing. Inbound Alice -> Bob Billing: Alice, inbound Forward Bob -> Charlie Billing: Alice, inbound; Bob, outbound ITSP looks up Charlie Billing: Alice, inbound; Bob, outbound; = Charlie, serviceX =20 So when the CDR gets written, the rating engine looks through the = Billing header and applies all the relevant charges to the relevant = accounts. Some may be per minute, some may be fixed charges. =20 The problems are first and foremost, security. No one can add to the = billing header unless they are trusted entities within your system, = because money will be charged based on the information there. Second, = care has to be taken to strip off the header when it leaves the trusted = domain =E2=80=93 out to the UA=E2=80=99s for example. You don=E2=80=99t = want people knowing what is going on in your billing system.=20 =20 But the idea here is very flexible and can take into account many things = that we aren=E2=80=99t thinking about now. For example, we may charge = differently one day calls that require NAT treatment on the RTP level = (where the bandwidth cost to the hosting ITSP is not negligible). When = you find that to be the case, just add it to the Billing header. What = about if calls are forwarded multiple times? Keep adding each leg to the = billing header. =20 What does everyone think about this? =20 Baruch =20 -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of = sayan.chowdhury@wipro.com Sent: Wednesday, May 19, 2004 1:00 AM To: diegob@mailvision.com; baruch@kayote.com Cc: sip@ietf.org; sipping@ietf.org; fluffy@cisco.com Subject: RE: [Sip] SIP Forward, Who pays the bill ? =20 Also , Alice might be sending the re-invite to on receipt of a 302 from = Bob. So the set of proxies invloved in the first leg of the call may not = be involved in the second ? Solutuion to this will be on the PSTN gateway side. The PSTN gateway should look for and bill from Diversion/Request = History/remote Part Header information in preference to the from header = which is unreliable any way. However , I do not know of any standards which explicitly mentions that = .. =20 Regards , Sayan =20 -----Original Message-----=20 From: sip-admin@ietf.org on behalf of Diego B=20 Sent: Tue 5/18/2004 7:44 PM=20 To: baruch@kayote.com=20 Cc: sip@ietf.org; 'sipping'; 'Cullen Jennings'=20 Subject: Re: [Sip] SIP Forward, Who pays the bill ? Hi Baruch; Thanks for your answer. I belive that you are implementing a proprietary solution to deal with = it. I'm looking more to a standarize way to deal with the second-leg issue. I'm agree that Alice has to pay for the first leg and Bob for the second, but if the Proxy that is doing the forward is not a biling entity ( local calls are free, outbound call are not free and billed by an external real-time billing system connected to the GW using RADIUS or similar), the PSTN gateway will have to know that this call may be billed to Bob and not to Alice ( she apears in the From header ). Thanks Baruch Sterman wrote: > In the systems that we implemented, two cdrs are created: the first = for > the incoming leg (Alice to Bob's non-forwarded location) and a second > for the forward to Bob's forwarded location. > > Alice would pay for the first leg, and Bob pays for the second. > > Furthermore, it may be the case that Bob pays for the first leg as = well. > If, for example, Bob has a toll free number where he pays per minute > charges for the inbound leg (in this case, Alice is on the PSTN). > > Either way, multiple CDRs is the way we came up with to handle this. > Care has to be taken that the key to any CDR database is NOT the > call-ID, because this is the same across the two CDRs. > > Baruch > > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of = Diego > B > Sent: Tuesday, May 18, 2004 7:42 AM > To: sip@ietf.org; sipping > Cc: Cullen Jennings > Subject: [Sip] SIP Forward, Who pays the bill ? > > Hi; > My question is regarding billing a forwarded sip call. > > Lets take the exmple from draft-ietf-sipping-service-examples > 2.7 > > Alice calls Bob, and Bob has all his incomming calls forwarded to the > PSTN. > > Let say that calls from ALice to Bob in the same domain are free (same > office, or same ITSP), but calls to the PSTN are not free. > > Who pays for Alice call to Bob ?? > In a normal situacion, Alice knows that the call is for free becuase = she > > is calling Bob's sip number. But the gateweay may create CDR from the > From header of the SIP message and at the end of the month Alice may > have to pay for the call. > > I see this kind of examples in several other drafts/RFC related to SIP > services and call forward. > > I belive forward is a very important feature, but this issue may be > resolved. The question is if it is a standard way to make Bob pays for > the second leg of the call like in PSTN forward. > > Maybe changing the From header where applicable and adding a new one = to > "remember" that the call is from, in my example, Alice. > > The diversion header (Diversion Indication in SIP > draft-levy-sip-diversion-07.txt)" may be a solution if the PSTN = gateway > or the SIP Billing server support it and knows that they have to bill > the sip-uri in the diversion header ( this is right ??? ). > > Regards; > > > > > -- Diego B MailVision Ltd. Tel. : =EF=9E=BD4-8500505 ext 13 e-mail: diegob@mailvision.com web : http://www.mailvision.com = =20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip = =20 This list is for NEW development of the core SIP 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_000_006E_01C43D64.BDC2CA20 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Re: [Sip] SIP Forward, Who pays the bill ?

Another avenue that can be explored = is an explicit header to deal with this and other accounting issues. I think = that the AAA group has suggested an ACCOUNTING header. We were thinking of a = BILLING header. In that header you would have a username and type. So as the = call progresses you could add to that header. This would also allow to charge for various services along the way. = Imagine the following. Alice calls Bob, Bob forwards to Charlie who requires an ENUM = lookup to find his IP =E2=80=93 and you are dealing with a psychotic ITSP that = *Charges* for ENUM = listing.

Inbound = Alice -> Bob=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Billing: Alice, inbound

Forward Bob -> Charlie=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Billing: Alice, inbound; Bob, outbound

ITSP looks up Charlie=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Billing: Alice, inbound; Bob, outbound; Charlie, serviceX

 

So when the CDR gets written, the = rating engine looks through the Billing header and applies all the relevant = charges to the relevant accounts. Some may be per minute, some may be fixed = charges.

 

The problems are first and = foremost, security. No one can add to the billing header unless they are trusted = entities within your system, because money will be charged based on the = information there. Second, care has to be taken to strip off the header when it = leaves the trusted domain =E2=80=93 out to the UA=E2=80=99s for example. You don=E2=80=99t want people knowing what is going on in your billing system. =

 

But the idea here is very flexible = and can take into account many things that we aren=E2=80=99t thinking about now. = For example, we may charge differently one day calls that require NAT treatment on = the RTP level (where the bandwidth cost to the hosting ITSP is not negligible). = When you find that to be the case, just add it to the Billing header. What about = if calls are forwarded multiple times? Keep adding each leg to the billing = header.

 

What does everyone think about = this?

 

Baruch

 

-----Original = Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On = Behalf Of sayan.chowdhury@wipro.com
Sent: Wednesday, May 19, = 2004 1:00 AM
To: = diegob@mailvision.com; baruch@kayote.com
Cc: sip@ietf.org; sipping@ietf.org; fluffy@cisco.com
Subject: RE: [Sip] SIP = Forward, Who pays the bill ?

 

Also , Alice = might be sending the re-invite to on receipt of a 302 from Bob. So the set of = proxies invloved in the first leg of the call may not be involved in the second = ?

Solutuion to = this will be on the PSTN gateway side.

The PSTN = gateway should look for and bill from Diversion/Request History/remote Part Header = information in preference to the from header which is unreliable any = way.

However , I do = not know of any standards which explicitly mentions that = ..

 

Regards = ,

Sayan

 

-----Original Message-----
From: = sip-admin@ietf.org on behalf of Diego B
Sent: Tue 5/18/2004 7:44 = PM
To: baruch@kayote.com =
Cc: sip@ietf.org; = 'sipping'; 'Cullen Jennings'
Subject: Re: [Sip] SIP = Forward, Who pays the bill ?

Hi Baruch;
Thanks for your answer.
I belive that you are implementing a proprietary solution to deal with = it.
I'm looking more to a standarize way to deal with the second-leg = issue.

I'm agree that Alice has to pay for the first leg and Bob for the
second, but if the Proxy that is doing the forward is not a biling
entity ( local calls are free, outbound call are not free and billed = by
an external real-time billing system connected to the GW using RADIUS = or
similar), the PSTN gateway will have to know that this call may be
billed to Bob and not to Alice ( she apears in the From header ).

Thanks

Baruch Sterman wrote:

> In the systems that we implemented, two cdrs are created: the first = for
> the incoming leg (Alice to Bob's non-forwarded location) and a = second
> for the forward to Bob's forwarded location.
>
> Alice would pay for the first leg, and Bob pays for the second.
>
> Furthermore, it may be the case that Bob pays for the first leg as = well.
> If, for example, Bob has a toll free number where he pays per = minute
> charges for the inbound leg (in this case, Alice is on the = PSTN).
>
> Either way, multiple CDRs is the way we came up with to handle = this.
> Care has to be taken that the key to any CDR database is NOT = the
> call-ID, because this is the same across the two CDRs.
>
> Baruch
>
> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Diego
> B
> Sent: Tuesday, May 18, 2004 7:42 AM
> To: sip@ietf.org; sipping
> Cc: Cullen Jennings
> Subject: [Sip] SIP Forward, Who pays the bill ?
>
> Hi;
> My question is regarding billing a forwarded sip call.
>
> Lets take the exmple from draft-ietf-sipping-service-examples
> 2.7
>
> Alice calls Bob, and Bob has all his incomming calls forwarded to = the
> PSTN.
>
> Let say that calls from ALice to Bob in the same domain are free = (same
> office, or same ITSP), but calls to the PSTN are not free.
>
> Who pays for Alice call to Bob ??
> In a normal situacion, Alice knows that the call is for free = becuase she
>
> is calling Bob's sip number. But the gateweay may create CDR from = the
>  From header of the SIP message and at the end of the month = Alice may
> have to pay for the call.
>
> I see this kind of examples in several other drafts/RFC related to = SIP
> services and call forward.
>
> I belive forward is a very important feature, but this issue may = be
> resolved. The question is if it is a standard way to make Bob pays = for
> the second leg of the call like in PSTN forward.
>
> Maybe changing the From header where applicable and adding a new = one to
> "remember" that the call is from, in my example, = Alice.
>
> The diversion header (Diversion Indication in SIP
> draft-levy-sip-diversion-07.txt)" may be a solution if the = PSTN gateway
> or the SIP Billing server support it and knows that they have to = bill
> the sip-uri in the diversion header ( this is right ??? ).
>
> Regards;
>
>
>
>
>

--
Diego B
MailVision Ltd.
Tel.  : =EF=9E=BD4-8500505 ext 13
e-mail: diegob@mailvision.com
web   : h= ttp://www.mailvision.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_000_006E_01C43D64.BDC2CA20-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 19 22:22:21 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06191 for ; Wed, 19 May 2004 22:22:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQd7R-0007Nu-BT for sip-archive@odin.ietf.org; Wed, 19 May 2004 22:17:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4K2HD79028383 for sip-archive@odin.ietf.org; Wed, 19 May 2004 22:17:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQcrn-0003yX-Lc; Wed, 19 May 2004 22:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQcjF-00028i-O5 for sip@optimus.ietf.org; Wed, 19 May 2004 21: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 VAA04850 for ; Wed, 19 May 2004 21:52:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQcjC-0005Wp-Km for sip@ietf.org; Wed, 19 May 2004 21:52:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQciD-0005NN-00 for sip@ietf.org; Wed, 19 May 2004 21:51:10 -0400 Received: from almso1.att.com ([192.128.167.69] helo=almso1.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1BQchD-00057b-00; Wed, 19 May 2004 21:50:07 -0400 Received: from attrh0i.attrh.att.com ([135.37.94.54]) by almso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i4K1nLCM026583; Wed, 19 May 2004 21:49:37 -0400 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.9) by attrh0i.attrh.att.com (6.5.032) id 40951C4D002063B7; Wed, 19 May 2004 21:49:22 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.6561.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43E0C.B427AD59" Subject: RE: [Sip] SIP Forward, Who pays the bill ? Date: Wed, 19 May 2004 21:49:35 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A07217374@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [Sip] SIP Forward, Who pays the bill ? Thread-Index: AcQ952Sejgp6iCZISuitb+5TBKGx6gAJM1uA From: "Roy, Radhika R, ALABS" To: , , Cc: , , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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_01C43E0C.B427AD59 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIEJhcnVjaCB0aGF0IEFBQSBncm91cCBpcyB3b3JraW5nIGZvciBhdXRoZW50 aWNhdGlvbiwgYXV0aG9yaXphdGlvbiwgYW5kIGFjY291bnRpbmcgb2YgYXBwbGljYXRpb25zIGlu Y2x1ZGluZyBTSVAsIGFuZCB0aGVyZSBpcyBlbm91Z2ggcm9vbSB0byBidWlsZCBDRFJzL0JpbGxp bmcgYmFzZWQgb24gdGhvc2UgdGhpbmdzLiBTbywgU0lQIFdHIGRvZXMgbm90IG5lZWQgdG8gYmUg d29ycmllZCBmb3IgdGhpcy4NCiANClJhZGhpa2EgUi4gUm95DQpycnJveUBhdHQuY29tDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2lwLWFkbWluQGlldGYub3JnIFttYWlsdG86 c2lwLWFkbWluQGlldGYub3JnXU9uIEJlaGFsZiBPZiBCYXJ1Y2ggU3Rlcm1hbg0KU2VudDogV2Vk bmVzZGF5LCBNYXkgMTksIDIwMDQgNTo0NyBBTQ0KVG86IHNheWFuLmNob3dkaHVyeUB3aXByby5j b207IGRpZWdvYkBtYWlsdmlzaW9uLmNvbQ0KQ2M6IHNpcEBpZXRmLm9yZzsgc2lwcGluZ0BpZXRm Lm9yZzsgZmx1ZmZ5QGNpc2NvLmNvbQ0KU3ViamVjdDogUkU6IFtTaXBdIFNJUCBGb3J3YXJkLCBX aG8gcGF5cyB0aGUgYmlsbCA/DQoNCg0KQW5vdGhlciBhdmVudWUgdGhhdCBjYW4gYmUgZXhwbG9y ZWQgaXMgYW4gZXhwbGljaXQgaGVhZGVyIHRvIGRlYWwgd2l0aCB0aGlzIGFuZCBvdGhlciBhY2Nv dW50aW5nIGlzc3Vlcy4gSSB0aGluayB0aGF0IHRoZSBBQUEgZ3JvdXAgaGFzIHN1Z2dlc3RlZCBh biBBQ0NPVU5USU5HIGhlYWRlci4gV2Ugd2VyZSB0aGlua2luZyBvZiBhIEJJTExJTkcgaGVhZGVy LiBJbiB0aGF0IGhlYWRlciB5b3Ugd291bGQgaGF2ZSBhIHVzZXJuYW1lIGFuZCB0eXBlLiBTbyBh cyB0aGUgY2FsbCBwcm9ncmVzc2VzIHlvdSBjb3VsZCBhZGQgdG8gdGhhdCBoZWFkZXIuIFRoaXMg d291bGQgYWxzbyBhbGxvdyB0byBjaGFyZ2UgZm9yIHZhcmlvdXMgc2VydmljZXMgYWxvbmcgdGhl IHdheS4gSW1hZ2luZSB0aGUgZm9sbG93aW5nLiBBbGljZSBjYWxscyBCb2IsIEJvYiBmb3J3YXJk cyB0byBDaGFybGllIHdobyByZXF1aXJlcyBhbiBFTlVNIGxvb2t1cCB0byBmaW5kIGhpcyBJUCDi gJMgYW5kIHlvdSBhcmUgZGVhbGluZyB3aXRoIGEgcHN5Y2hvdGljIElUU1AgdGhhdCAqQ2hhcmdl cyogZm9yIEVOVU0gbGlzdGluZy4NCkluYm91bmQgQWxpY2UgLT4gQm9iICAgICAgICAgQmlsbGlu ZzogQWxpY2UsIGluYm91bmQNCkZvcndhcmQgQm9iIC0+IENoYXJsaWUgICAgICBCaWxsaW5nOiBB bGljZSwgaW5ib3VuZDsgQm9iLCBvdXRib3VuZA0KSVRTUCBsb29rcyB1cCBDaGFybGllICAgICAg ICBCaWxsaW5nOiBBbGljZSwgaW5ib3VuZDsgQm9iLCBvdXRib3VuZDsgQ2hhcmxpZSwgc2Vydmlj ZVgNCiANClNvIHdoZW4gdGhlIENEUiBnZXRzIHdyaXR0ZW4sIHRoZSByYXRpbmcgZW5naW5lIGxv b2tzIHRocm91Z2ggdGhlIEJpbGxpbmcgaGVhZGVyIGFuZCBhcHBsaWVzIGFsbCB0aGUgcmVsZXZh bnQgY2hhcmdlcyB0byB0aGUgcmVsZXZhbnQgYWNjb3VudHMuIFNvbWUgbWF5IGJlIHBlciBtaW51 dGUsIHNvbWUgbWF5IGJlIGZpeGVkIGNoYXJnZXMuDQogDQpUaGUgcHJvYmxlbXMgYXJlIGZpcnN0 IGFuZCBmb3JlbW9zdCwgc2VjdXJpdHkuIE5vIG9uZSBjYW4gYWRkIHRvIHRoZSBiaWxsaW5nIGhl YWRlciB1bmxlc3MgdGhleSBhcmUgdHJ1c3RlZCBlbnRpdGllcyB3aXRoaW4geW91ciBzeXN0ZW0s IGJlY2F1c2UgbW9uZXkgd2lsbCBiZSBjaGFyZ2VkIGJhc2VkIG9uIHRoZSBpbmZvcm1hdGlvbiB0 aGVyZS4gU2Vjb25kLCBjYXJlIGhhcyB0byBiZSB0YWtlbiB0byBzdHJpcCBvZmYgdGhlIGhlYWRl ciB3aGVuIGl0IGxlYXZlcyB0aGUgdHJ1c3RlZCBkb21haW4g4oCTIG91dCB0byB0aGUgVUHigJlz IGZvciBleGFtcGxlLiBZb3UgZG9u4oCZdCB3YW50IHBlb3BsZSBrbm93aW5nIHdoYXQgaXMgZ29p bmcgb24gaW4geW91ciBiaWxsaW5nIHN5c3RlbS4gDQogDQpCdXQgdGhlIGlkZWEgaGVyZSBpcyB2 ZXJ5IGZsZXhpYmxlIGFuZCBjYW4gdGFrZSBpbnRvIGFjY291bnQgbWFueSB0aGluZ3MgdGhhdCB3 ZSBhcmVu4oCZdCB0aGlua2luZyBhYm91dCBub3cuIEZvciBleGFtcGxlLCB3ZSBtYXkgY2hhcmdl IGRpZmZlcmVudGx5IG9uZSBkYXkgY2FsbHMgdGhhdCByZXF1aXJlIE5BVCB0cmVhdG1lbnQgb24g dGhlIFJUUCBsZXZlbCAod2hlcmUgdGhlIGJhbmR3aWR0aCBjb3N0IHRvIHRoZSBob3N0aW5nIElU U1AgaXMgbm90IG5lZ2xpZ2libGUpLiBXaGVuIHlvdSBmaW5kIHRoYXQgdG8gYmUgdGhlIGNhc2Us IGp1c3QgYWRkIGl0IHRvIHRoZSBCaWxsaW5nIGhlYWRlci4gV2hhdCBhYm91dCBpZiBjYWxscyBh cmUgZm9yd2FyZGVkIG11bHRpcGxlIHRpbWVzPyBLZWVwIGFkZGluZyBlYWNoIGxlZyB0byB0aGUg YmlsbGluZyBoZWFkZXIuDQogDQpXaGF0IGRvZXMgZXZlcnlvbmUgdGhpbmsgYWJvdXQgdGhpcz8N CiANCkJhcnVjaA0KIA0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNpcC1hZG1p bkBpZXRmLm9yZyBbbWFpbHRvOnNpcC1hZG1pbkBpZXRmLm9yZ10gT24gQmVoYWxmIE9mIHNheWFu LmNob3dkaHVyeUB3aXByby5jb20NClNlbnQ6IFdlZG5lc2RheSwgTWF5IDE5LCAyMDA0IDE6MDAg QU0NClRvOiBkaWVnb2JAbWFpbHZpc2lvbi5jb207IGJhcnVjaEBrYXlvdGUuY29tDQpDYzogc2lw QGlldGYub3JnOyBzaXBwaW5nQGlldGYub3JnOyBmbHVmZnlAY2lzY28uY29tDQpTdWJqZWN0OiBS RTogW1NpcF0gU0lQIEZvcndhcmQsIFdobyBwYXlzIHRoZSBiaWxsID8NCiANCkFsc28gLCBBbGlj ZSBtaWdodCBiZSBzZW5kaW5nIHRoZSByZS1pbnZpdGUgdG8gb24gcmVjZWlwdCBvZiBhIDMwMiBm cm9tIEJvYi4gU28gdGhlIHNldCBvZiBwcm94aWVzIGludmxvdmVkIGluIHRoZSBmaXJzdCBsZWcg b2YgdGhlIGNhbGwgbWF5IG5vdCBiZSBpbnZvbHZlZCBpbiB0aGUgc2Vjb25kID8NClNvbHV0dWlv biB0byB0aGlzIHdpbGwgYmUgb24gdGhlIFBTVE4gZ2F0ZXdheSBzaWRlLg0KVGhlIFBTVE4gZ2F0 ZXdheSBzaG91bGQgbG9vayBmb3IgYW5kIGJpbGwgZnJvbSBEaXZlcnNpb24vUmVxdWVzdCBIaXN0 b3J5L3JlbW90ZSBQYXJ0IEhlYWRlciBpbmZvcm1hdGlvbiBpbiBwcmVmZXJlbmNlIHRvIHRoZSBm cm9tIGhlYWRlciB3aGljaCBpcyB1bnJlbGlhYmxlIGFueSB3YXkuDQpIb3dldmVyICwgSSBkbyBu b3Qga25vdyBvZiBhbnkgc3RhbmRhcmRzIHdoaWNoIGV4cGxpY2l0bHkgbWVudGlvbnMgdGhhdCAu Lg0KIA0KUmVnYXJkcyAsDQpTYXlhbg0KIA0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQpG cm9tOiBzaXAtYWRtaW5AaWV0Zi5vcmcgb24gYmVoYWxmIG9mIERpZWdvIEIgDQpTZW50OiBUdWUg NS8xOC8yMDA0IDc6NDQgUE0gDQpUbzogYmFydWNoQGtheW90ZS5jb20gDQpDYzogc2lwQGlldGYu b3JnOyAnc2lwcGluZyc7ICdDdWxsZW4gSmVubmluZ3MnIA0KU3ViamVjdDogUmU6IFtTaXBdIFNJ UCBGb3J3YXJkLCBXaG8gcGF5cyB0aGUgYmlsbCA/DQpIaSBCYXJ1Y2g7DQpUaGFua3MgZm9yIHlv dXIgYW5zd2VyLg0KSSBiZWxpdmUgdGhhdCB5b3UgYXJlIGltcGxlbWVudGluZyBhIHByb3ByaWV0 YXJ5IHNvbHV0aW9uIHRvIGRlYWwgd2l0aCBpdC4NCkknbSBsb29raW5nIG1vcmUgdG8gYSBzdGFu ZGFyaXplIHdheSB0byBkZWFsIHdpdGggdGhlIHNlY29uZC1sZWcgaXNzdWUuDQoNCkknbSBhZ3Jl ZSB0aGF0IEFsaWNlIGhhcyB0byBwYXkgZm9yIHRoZSBmaXJzdCBsZWcgYW5kIEJvYiBmb3IgdGhl DQpzZWNvbmQsIGJ1dCBpZiB0aGUgUHJveHkgdGhhdCBpcyBkb2luZyB0aGUgZm9yd2FyZCBpcyBu b3QgYSBiaWxpbmcNCmVudGl0eSAoIGxvY2FsIGNhbGxzIGFyZSBmcmVlLCBvdXRib3VuZCBjYWxs IGFyZSBub3QgZnJlZSBhbmQgYmlsbGVkIGJ5DQphbiBleHRlcm5hbCByZWFsLXRpbWUgYmlsbGlu ZyBzeXN0ZW0gY29ubmVjdGVkIHRvIHRoZSBHVyB1c2luZyBSQURJVVMgb3INCnNpbWlsYXIpLCB0 aGUgUFNUTiBnYXRld2F5IHdpbGwgaGF2ZSB0byBrbm93IHRoYXQgdGhpcyBjYWxsIG1heSBiZQ0K YmlsbGVkIHRvIEJvYiBhbmQgbm90IHRvIEFsaWNlICggc2hlIGFwZWFycyBpbiB0aGUgRnJvbSBo ZWFkZXIgKS4NCg0KVGhhbmtzDQoNCkJhcnVjaCBTdGVybWFuIHdyb3RlOg0KDQo+IEluIHRoZSBz eXN0ZW1zIHRoYXQgd2UgaW1wbGVtZW50ZWQsIHR3byBjZHJzIGFyZSBjcmVhdGVkOiB0aGUgZmly c3QgZm9yDQo+IHRoZSBpbmNvbWluZyBsZWcgKEFsaWNlIHRvIEJvYidzIG5vbi1mb3J3YXJkZWQg bG9jYXRpb24pIGFuZCBhIHNlY29uZA0KPiBmb3IgdGhlIGZvcndhcmQgdG8gQm9iJ3MgZm9yd2Fy ZGVkIGxvY2F0aW9uLg0KPg0KPiBBbGljZSB3b3VsZCBwYXkgZm9yIHRoZSBmaXJzdCBsZWcsIGFu ZCBCb2IgcGF5cyBmb3IgdGhlIHNlY29uZC4NCj4NCj4gRnVydGhlcm1vcmUsIGl0IG1heSBiZSB0 aGUgY2FzZSB0aGF0IEJvYiBwYXlzIGZvciB0aGUgZmlyc3QgbGVnIGFzIHdlbGwuDQo+IElmLCBm b3IgZXhhbXBsZSwgQm9iIGhhcyBhIHRvbGwgZnJlZSBudW1iZXIgd2hlcmUgaGUgcGF5cyBwZXIg bWludXRlDQo+IGNoYXJnZXMgZm9yIHRoZSBpbmJvdW5kIGxlZyAoaW4gdGhpcyBjYXNlLCBBbGlj ZSBpcyBvbiB0aGUgUFNUTikuDQo+DQo+IEVpdGhlciB3YXksIG11bHRpcGxlIENEUnMgaXMgdGhl IHdheSB3ZSBjYW1lIHVwIHdpdGggdG8gaGFuZGxlIHRoaXMuDQo+IENhcmUgaGFzIHRvIGJlIHRh a2VuIHRoYXQgdGhlIGtleSB0byBhbnkgQ0RSIGRhdGFiYXNlIGlzIE5PVCB0aGUNCj4gY2FsbC1J RCwgYmVjYXVzZSB0aGlzIGlzIHRoZSBzYW1lIGFjcm9zcyB0aGUgdHdvIENEUnMuDQo+DQo+IEJh cnVjaA0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBzaXAtYWRtaW5A aWV0Zi5vcmcgWyBtYWlsdG86c2lwLWFkbWluQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGllZ28N Cj4gQg0KPiBTZW50OiBUdWVzZGF5LCBNYXkgMTgsIDIwMDQgNzo0MiBBTQ0KPiBUbzogc2lwQGll dGYub3JnOyBzaXBwaW5nDQo+IENjOiBDdWxsZW4gSmVubmluZ3MNCj4gU3ViamVjdDogW1NpcF0g U0lQIEZvcndhcmQsIFdobyBwYXlzIHRoZSBiaWxsID8NCj4NCj4gSGk7DQo+IE15IHF1ZXN0aW9u IGlzIHJlZ2FyZGluZyBiaWxsaW5nIGEgZm9yd2FyZGVkIHNpcCBjYWxsLg0KPg0KPiBMZXRzIHRh a2UgdGhlIGV4bXBsZSBmcm9tIGRyYWZ0LWlldGYtc2lwcGluZy1zZXJ2aWNlLWV4YW1wbGVzDQo+ IDIuNw0KPg0KPiBBbGljZSBjYWxscyBCb2IsIGFuZCBCb2IgaGFzIGFsbCBoaXMgaW5jb21taW5n IGNhbGxzIGZvcndhcmRlZCB0byB0aGUNCj4gUFNUTi4NCj4NCj4gTGV0IHNheSB0aGF0IGNhbGxz IGZyb20gQUxpY2UgdG8gQm9iIGluIHRoZSBzYW1lIGRvbWFpbiBhcmUgZnJlZSAoc2FtZQ0KPiBv ZmZpY2UsIG9yIHNhbWUgSVRTUCksIGJ1dCBjYWxscyB0byB0aGUgUFNUTiBhcmUgbm90IGZyZWUu DQo+DQo+IFdobyBwYXlzIGZvciBBbGljZSBjYWxsIHRvIEJvYiA/Pw0KPiBJbiBhIG5vcm1hbCBz aXR1YWNpb24sIEFsaWNlIGtub3dzIHRoYXQgdGhlIGNhbGwgaXMgZm9yIGZyZWUgYmVjdWFzZSBz aGUNCj4NCj4gaXMgY2FsbGluZyBCb2IncyBzaXAgbnVtYmVyLiBCdXQgdGhlIGdhdGV3ZWF5IG1h eSBjcmVhdGUgQ0RSIGZyb20gdGhlDQo+ICBGcm9tIGhlYWRlciBvZiB0aGUgU0lQIG1lc3NhZ2Ug YW5kIGF0IHRoZSBlbmQgb2YgdGhlIG1vbnRoIEFsaWNlIG1heQ0KPiBoYXZlIHRvIHBheSBmb3Ig dGhlIGNhbGwuDQo+DQo+IEkgc2VlIHRoaXMga2luZCBvZiBleGFtcGxlcyBpbiBzZXZlcmFsIG90 aGVyIGRyYWZ0cy9SRkMgcmVsYXRlZCB0byBTSVANCj4gc2VydmljZXMgYW5kIGNhbGwgZm9yd2Fy ZC4NCj4NCj4gSSBiZWxpdmUgZm9yd2FyZCBpcyBhIHZlcnkgaW1wb3J0YW50IGZlYXR1cmUsIGJ1 dCB0aGlzIGlzc3VlIG1heSBiZQ0KPiByZXNvbHZlZC4gVGhlIHF1ZXN0aW9uIGlzIGlmIGl0IGlz IGEgc3RhbmRhcmQgd2F5IHRvIG1ha2UgQm9iIHBheXMgZm9yDQo+IHRoZSBzZWNvbmQgbGVnIG9m IHRoZSBjYWxsIGxpa2UgaW4gUFNUTiBmb3J3YXJkLg0KPg0KPiBNYXliZSBjaGFuZ2luZyB0aGUg RnJvbSBoZWFkZXIgd2hlcmUgYXBwbGljYWJsZSBhbmQgYWRkaW5nIGEgbmV3IG9uZSB0bw0KPiAi cmVtZW1iZXIiIHRoYXQgdGhlIGNhbGwgaXMgZnJvbSwgaW4gbXkgZXhhbXBsZSwgQWxpY2UuDQo+ DQo+IFRoZSBkaXZlcnNpb24gaGVhZGVyIChEaXZlcnNpb24gSW5kaWNhdGlvbiBpbiBTSVANCj4g ZHJhZnQtbGV2eS1zaXAtZGl2ZXJzaW9uLTA3LnR4dCkiIG1heSBiZSBhIHNvbHV0aW9uIGlmIHRo ZSBQU1ROIGdhdGV3YXkNCj4gb3IgdGhlIFNJUCBCaWxsaW5nIHNlcnZlciBzdXBwb3J0IGl0IGFu ZCBrbm93cyB0aGF0IHRoZXkgaGF2ZSB0byBiaWxsDQo+IHRoZSBzaXAtdXJpIGluIHRoZSBkaXZl cnNpb24gaGVhZGVyICggdGhpcyBpcyByaWdodCA/Pz8gKS4NCj4NCj4gUmVnYXJkczsNCj4NCj4N Cj4NCj4NCj4NCg0KLS0NCkRpZWdvIEINCk1haWxWaXNpb24gTHRkLg0KVGVsLiAgOiDvnr00LTg1 MDA1MDUgZXh0IDEzDQplLW1haWw6IGRpZWdvYkBtYWlsdmlzaW9uLmNvbQ0Kd2ViICAgOiBodHRw Oi8vd3d3Lm1haWx2aXNpb24uY29tIDxodHRwczovL2dhdGV3YXktaW5kaWEud2lwcm8uY29tLyxE YW5hSW5mbz13d3cubWFpbHZpc2lvbi5jb20+IA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NClNpcCBtYWlsaW5nIGxpc3QgIGh0dHBzOi8vd3d3 MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcCA8aHR0cHM6Ly9nYXRld2F5LWluZGlhLndp cHJvLmNvbS9tYWlsbWFuL2xpc3RpbmZvL3NpcCxEYW5hSW5mbz13d3cxLmlldGYub3JnLFNTTD4g DQpUaGlzIGxpc3QgaXMgZm9yIE5FVyBkZXZlbG9wbWVudCBvZiB0aGUgY29yZSBTSVAgUHJvdG9j b2wNClVzZSBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3IgcXVlc3Rpb25zIG9u IGN1cnJlbnQgc2lwDQpVc2Ugc2lwcGluZ0BpZXRmLm9yZyBmb3IgbmV3IGRldmVsb3BtZW50cyBv biB0aGUgYXBwbGljYXRpb24gb2Ygc2lwDQo= ------_=_NextPart_001_01C43E0C.B427AD59 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4bWxu czpvID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4bWxuczp3 ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6c3QxID0g DQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIj48SEVBRD4NCjxN RVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9odG1sOyBjaGFyc2V0 PXV0Zi04Ij4NCjxUSVRMRT5SZTogW1NpcF0gU0lQIEZvcndhcmQsIFdobyBwYXlzIHRoZSBiaWxs ID88L1RJVExFPg0KDQo8TUVUQSBjb250ZW50PVdvcmQuRG9jdW1lbnQgbmFtZT1Qcm9nSWQ+DQo8 TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0MDAiIG5hbWU9R0VORVJBVE9SPg0KPE1F VEEgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTAiIG5hbWU9T3JpZ2luYXRvcj48TElOSyANCmhy ZWY9ImNpZDpmaWxlbGlzdC54bWxAMDFDNDNENjQuQjgyQzk1NTAiIHJlbD1GaWxlLUxpc3Q+PG86 U21hcnRUYWdUeXBlIA0KbmFtZT0iQ2l0eSIgDQpuYW1lc3BhY2V1cmk9InVybjpzY2hlbWFzLW1p Y3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncyI+PC9vOlNtYXJ0VGFnVHlwZT48bzpTbWFydFRh Z1R5cGUgDQpuYW1lPSJwbGFjZSIgDQpuYW1lc3BhY2V1cmk9InVybjpzY2hlbWFzLW1pY3Jvc29m dC1jb206b2ZmaWNlOnNtYXJ0dGFncyI+PC9vOlNtYXJ0VGFnVHlwZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCiA8bzpPZmZpY2VEb2N1bWVudFNldHRpbmdzPg0KICA8bzpEb05vdFJlbHlPbkNT Uy8+DQogPC9vOk9mZmljZURvY3VtZW50U2V0dGluZ3M+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8dzpXb3JkRG9jdW1lbnQ+DQogIDx3OlNwZWxsaW5nU3Rh dGU+Q2xlYW48L3c6U3BlbGxpbmdTdGF0ZT4NCiAgPHc6R3JhbW1hclN0YXRlPkNsZWFuPC93Okdy YW1tYXJTdGF0ZT4NCiAgPHc6RG9jdW1lbnRLaW5kPkRvY3VtZW50RW1haWw8L3c6RG9jdW1lbnRL aW5kPg0KICA8dzpFbnZlbG9wZVZpcy8+DQogIDx3OkNvbXBhdGliaWxpdHk+DQogICA8dzpBcHBs eUJyZWFraW5nUnVsZXMvPg0KICA8L3c6Q29tcGF0aWJpbGl0eT4NCiAgPHc6QnJvd3NlckxldmVs Pk1pY3Jvc29mdEludGVybmV0RXhwbG9yZXI0PC93OkJyb3dzZXJMZXZlbD4NCiA8L3c6V29yZERv Y3VtZW50Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiAhbXNvXT4NCjxTVFlMRT5zdDFcOiog ew0KCUJFSEFWSU9SOiB1cmwoI2RlZmF1bHQjaWVvb3VpKQ0KfQ0KPC9TVFlMRT4NCjwhW2VuZGlm XS0tPg0KPFNUWUxFPkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBCYXRhbmc7DQp9DQpAZm9u dC1mYWNlIHsNCglmb250LWZhbWlseTogVGFob21hOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1m YW1pbHk6IEBCYXRhbmc7DQp9DQpAcGFnZSBTZWN0aW9uMSB7c2l6ZTogNjEyLjBwdCA3OTIuMHB0 OyBtYXJnaW46IDcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDsgbXNvLWhlYWRlci1tYXJnaW46 IDM2LjBwdDsgbXNvLWZvb3Rlci1tYXJnaW46IDM2LjBwdDsgbXNvLXBhcGVyLXNvdXJjZTogMDsg fQ0KUC5Nc29Ob3JtYWwgew0KCUZPTlQtU0laRTogMTJwdDsgTUFSR0lOOiAwbW0gMG1tIDBwdDsg Rk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBtc28tc3R5bGUtcGFyZW50OiAiIjsgbXNv LXBhZ2luYXRpb246IHdpZG93LW9ycGhhbjsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICJUaW1l cyBOZXcgUm9tYW4iDQp9DQpMSS5Nc29Ob3JtYWwgew0KCUZPTlQtU0laRTogMTJwdDsgTUFSR0lO OiAwbW0gMG1tIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBtc28tc3R5bGUt cGFyZW50OiAiIjsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbjsgbXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6ICJUaW1lcyBOZXcgUm9tYW4iDQp9DQpESVYuTXNvTm9ybWFsIHsNCglGT05ULVNJ WkU6IDEycHQ7IE1BUkdJTjogMG1tIDBtbSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJv bWFuIjsgbXNvLXN0eWxlLXBhcmVudDogIiI7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1vcnBoYW47 IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAiVGltZXMgTmV3IFJvbWFuIg0KfQ0KQTpsaW5rIHsN CglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmU7IHRleHQtdW5kZXJsaW5l OiBzaW5nbGUNCn0NClNQQU4uTXNvSHlwZXJsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNP UkFUSU9OOiB1bmRlcmxpbmU7IHRleHQtdW5kZXJsaW5lOiBzaW5nbGUNCn0NCkE6dmlzaXRlZCB7 DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lOyB0ZXh0LXVuZGVybGlu ZTogc2luZ2xlDQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjogYmx1ZTsg VEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmU7IHRleHQtdW5kZXJsaW5lOiBzaW5nbGUNCn0NClAg ew0KCUZPTlQtU0laRTogMTJwdDsgTUFSR0lOLUxFRlQ6IDBtbTsgTUFSR0lOLVJJR0hUOiAwbW07 IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9y cGhhbjsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICJUaW1lcyBOZXcgUm9tYW4iOyBtc28tbWFy Z2luLXRvcC1hbHQ6IGF1dG87IG1zby1tYXJnaW4tYm90dG9tLWFsdDogYXV0bw0KfQ0KU1BBTi5F bWFpbFN0eWxlMTggew0KCUNPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWw7IG1zby1zdHls ZS10eXBlOiBwZXJzb25hbC1yZXBseTsgbXNvLXN0eWxlLW5vc2hvdzogeWVzOyBtc28tYW5zaS1m b250LXNpemU6IDEwLjBwdDsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQ7IG1zby1hc2NpaS1m b250LWZhbWlseTogQXJpYWw7IG1zby1oYW5zaS1mb250LWZhbWlseTogQXJpYWw7IG1zby1iaWRp LWZvbnQtZmFtaWx5OiBBcmlhbA0KfQ0KU1BBTi5TcGVsbEUgew0KCW1zby1zdHlsZS1uYW1lOiAi IjsgbXNvLXNwbC1lOiB5ZXMNCn0NClNQQU4uR3JhbUUgew0KCW1zby1zdHlsZS1uYW1lOiAiIjsg bXNvLWdyYW0tZTogeWVzDQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNlY3Rpb24xDQp9DQo8 L1NUWUxFPg0KPCEtLVtpZiBndGUgbXNvIDEwXT4NCjxzdHlsZT4NCiAvKiBTdHlsZSBEZWZpbml0 aW9ucyAqLyANCiB0YWJsZS5Nc29Ob3JtYWxUYWJsZQ0KCXttc28tc3R5bGUtbmFtZToiVGFibGUg Tm9ybWFsIjsNCgltc28tdHN0eWxlLXJvd2JhbmQtc2l6ZTowOw0KCW1zby10c3R5bGUtY29sYmFu ZC1zaXplOjA7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXBhcmVudDoiIjsN Cgltc28tcGFkZGluZy1hbHQ6MG1tIDUuNHB0IDBtbSA1LjRwdDsNCgltc28tcGFyYS1tYXJnaW46 MG1tOw0KCW1zby1wYXJhLW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3 aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIjt9DQo8L3N0eWxlPg0KPCFbZW5kaWZdLS0+PC9IRUFEPg0KPEJPRFkgbGFuZz1FTi1V UyBzdHlsZT0idGFiLWludGVydmFsOiAzNi4wcHQiIHZMaW5rPWJsdWUgbGluaz1ibHVlPg0KPERJ Vj48U1BBTiBjbGFzcz0zODc1NzQ1MDEtMjAwNTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0j MDAwMGZmIHNpemU9Mj5JIA0KYWdyZWUgd2l0aCBCYXJ1Y2ggdGhhdCBBQUEgZ3JvdXAgaXMgd29y a2luZyBmb3IgYXV0aGVudGljYXRpb24sIGF1dGhvcml6YXRpb24sIA0KYW5kIGFjY291bnRpbmcm bmJzcDtvZiBhcHBsaWNhdGlvbnMgaW5jbHVkaW5nIFNJUCwgYW5kIHRoZXJlIGlzIGVub3VnaCBy b29tIHRvIA0KYnVpbGQgQ0RScy9CaWxsaW5nIGJhc2VkIG9uIHRob3NlIHRoaW5ncy4gU28sIFNJ UCBXRyBkb2VzIG5vdCBuZWVkIHRvIGJlIHdvcnJpZWQgDQpmb3IgdGhpcy48L0ZPTlQ+PC9TUEFO PjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz0zODc1NzQ1MDEtMjAwNTIwMDQ+PEZPTlQgZmFjZT1B cmlhbCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8 RElWPjxTUEFOIGNsYXNzPTM4NzU3NDUwMS0yMDA1MjAwND48Rk9OVCBmYWNlPUFyaWFsIGNvbG9y PSMwMDAwZmYgDQpzaXplPTI+UmFkaGlrYSBSLiBSb3k8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJ Vj48U1BBTiBjbGFzcz0zODc1NzQ1MDEtMjAwNTIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0j MDAwMGZmIHNpemU9Mj48QSANCmhyZWY9Im1haWx0bzpycnJveUBhdHQuY29tIj5ycnJveUBhdHQu Y29tPC9BPjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8QkxPQ0tRVU9URSBkaXI9bHRyIHN0eWxlPSJN QVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVYgY2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgZGly PWx0ciBhbGlnbj1sZWZ0PjxGT05UIGZhY2U9VGFob21hIA0KICBzaXplPTI+LS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS08QlI+PEI+RnJvbTo8L0I+IHNpcC1hZG1pbkBpZXRmLm9yZyANCiAgW21h aWx0bzpzaXAtYWRtaW5AaWV0Zi5vcmddPEI+T24gQmVoYWxmIE9mIDwvQj5CYXJ1Y2ggU3Rlcm1h bjxCUj48Qj5TZW50OjwvQj4gDQogIFdlZG5lc2RheSwgTWF5IDE5LCAyMDA0IDU6NDcgQU08QlI+ PEI+VG86PC9CPiBzYXlhbi5jaG93ZGh1cnlAd2lwcm8uY29tOyANCiAgZGllZ29iQG1haWx2aXNp b24uY29tPEJSPjxCPkNjOjwvQj4gc2lwQGlldGYub3JnOyBzaXBwaW5nQGlldGYub3JnOyANCiAg Zmx1ZmZ5QGNpc2NvLmNvbTxCUj48Qj5TdWJqZWN0OjwvQj4gUkU6IFtTaXBdIFNJUCBGb3J3YXJk LCBXaG8gcGF5cyB0aGUgYmlsbCANCiAgPzxCUj48QlI+PC9GT05UPjwvRElWPg0KICA8RElWIGNs YXNzPVNlY3Rpb24xPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xv cj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5h dnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+QW5vdGhlciBhdmVudWUgdGhhdCANCiAgY2FuIGJlIGV4 cGxvcmVkIGlzIGFuIGV4cGxpY2l0IGhlYWRlciB0byBkZWFsIHdpdGggdGhpcyBhbmQgb3RoZXIg YWNjb3VudGluZyANCiAgaXNzdWVzLiBJIHRoaW5rIHRoYXQgdGhlIEFBQSBncm91cCBoYXMgc3Vn Z2VzdGVkIGFuIEFDQ09VTlRJTkcgaGVhZGVyLiBXZSB3ZXJlIA0KICB0aGlua2luZyBvZiBhIEJJ TExJTkcgaGVhZGVyLiBJbiB0aGF0IGhlYWRlciB5b3Ugd291bGQgaGF2ZSBhIHVzZXJuYW1lIGFu ZCANCiAgdHlwZS4gU28gYXMgdGhlIGNhbGwgcHJvZ3Jlc3NlcyB5b3UgY291bGQgYWRkIHRvIHRo YXQgaGVhZGVyLiBUaGlzIHdvdWxkIGFsc28gDQogIGFsbG93IDxTUEFOIGNsYXNzPUdyYW1FPnRv IGNoYXJnZTwvU1BBTj4gZm9yIHZhcmlvdXMgc2VydmljZXMgYWxvbmcgdGhlIHdheS4gDQogIElt YWdpbmUgdGhlIGZvbGxvd2luZy4gPC9TUEFOPjwvRk9OVD48c3QxOkNpdHk+PHN0MTpwbGFjZT48 Rk9OVCBmYWNlPUFyaWFsIA0KICBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZP TlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+QWxpY2U8L1NQ QU4+PC9GT05UPjwvc3QxOnBsYWNlPjwvc3QxOkNpdHk+PEZPTlQgDQogIGZhY2U9QXJpYWwgY29s b3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBu YXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPiBjYWxscyBCb2IsIEJvYiANCiAgZm9yd2FyZHMgdG8g Q2hhcmxpZSB3aG8gcmVxdWlyZXMgYW4gRU5VTSBsb29rdXAgdG8gZmluZCBoaXMgSVAg4oCTIGFu ZCB5b3UgYXJlIA0KICBkZWFsaW5nIHdpdGggYSBwc3ljaG90aWMgSVRTUCB0aGF0ICo8Qj48U1BB TiANCiAgc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5DaGFyZ2VzPC9TUEFOPjwvQj4qIGZvciBF TlVNIA0KICBsaXN0aW5nLjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNz PU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5J bmJvdW5kIA0KICA8L1NQQU4+PC9GT05UPjxzdDE6Q2l0eT48c3QxOnBsYWNlPjxGT05UIGZhY2U9 QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7 IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPkFsaWNlPC9TUEFOPjwvRk9OVD48L3N0 MTpwbGFjZT48L3N0MTpDaXR5PjxGT05UIA0KICBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0y PjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1J TFk6IEFyaWFsIj4gLSZndDsgQm9iPFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQ QU4+QmlsbGluZzogPC9TUEFOPjwvRk9OVD48c3QxOkNpdHk+PHN0MTpwbGFjZT48Rk9OVCBmYWNl PUFyaWFsIGNvbG9yPW5hdnkgDQogIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTog MTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+QWxpY2U8L1NQQU4+PC9GT05U Pjwvc3QxOnBsYWNlPjwvc3QxOkNpdHk+PEZPTlQgDQogIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBz aXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05U LUZBTUlMWTogQXJpYWwiPiwgDQogIGluYm91bmQ8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9Q Pg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9 Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFN SUxZOiBBcmlhbCI+Rm9yd2FyZCBCb2IgLSZndDsgDQogIENoYXJsaWU8U1BBTiBzdHlsZT0ibXNv LXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9TUEFO PkJpbGxpbmc6IDwvU1BBTj48L0ZPTlQ+PHN0MTpDaXR5PjxzdDE6cGxhY2U+PEZPTlQgZmFjZT1B cmlhbCBjb2xvcj1uYXZ5IA0KICBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPkFsaWNlPC9TUEFOPjwvRk9OVD48 L3N0MTpwbGFjZT48L3N0MTpDaXR5PjxGT05UIA0KICBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6 ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1G QU1JTFk6IEFyaWFsIj4sIGluYm91bmQ7IEJvYiwgDQogIG91dGJvdW5kPG86cD48L286cD48L1NQ QU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29s b3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBu YXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPklUU1AgbG9va3MgdXAgDQogIENoYXJsaWU8U1BBTiAN CiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgDQogIDwvU1BBTj5CaWxsaW5nOiA8L1NQQU4+PC9GT05UPjxzdDE6Q2l0 eT48c3QxOnBsYWNlPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSANCiAgc2l6ZT0yPjxTUEFO IA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFy aWFsIj5BbGljZTwvU1BBTj48L0ZPTlQ+PC9zdDE6cGxhY2U+PC9zdDE6Q2l0eT48Rk9OVCANCiAg ZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTog MTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+LCBpbmJvdW5kOyBCb2IsIA0K ICBvdXRib3VuZDsgQ2hhcmxpZSwgPFNQQU4gDQogIGNsYXNzPVNwZWxsRT5zZXJ2aWNlWDwvU1BB Tj48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZP TlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PG86cD4mbmJzcDs8L286 cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJp YWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENP TE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPlNvIHdoZW4gdGhlIENEUiBnZXRzIA0KICB3 cml0dGVuLCB0aGUgcmF0aW5nIGVuZ2luZSBsb29rcyB0aHJvdWdoIHRoZSBCaWxsaW5nIGhlYWRl ciBhbmQgYXBwbGllcyBhbGwgDQogIHRoZSByZWxldmFudCBjaGFyZ2VzIHRvIHRoZSByZWxldmFu dCBhY2NvdW50cy4gU29tZSBtYXkgYmUgcGVyIG1pbnV0ZSwgc29tZSANCiAgbWF5IGJlIGZpeGVk IGNoYXJnZXMuPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9y bWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBm YWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5UaGUgcHJvYmxlbXMgYXJlIA0K ICBmaXJzdCBhbmQgZm9yZW1vc3QsIHNlY3VyaXR5LiBObyBvbmUgY2FuIGFkZCB0byB0aGUgYmls bGluZyBoZWFkZXIgdW5sZXNzIHRoZXkgDQogIGFyZSB0cnVzdGVkIGVudGl0aWVzIHdpdGhpbiB5 b3VyIHN5c3RlbSwgYmVjYXVzZSBtb25leSB3aWxsIGJlIGNoYXJnZWQgYmFzZWQgDQogIG9uIHRo ZSBpbmZvcm1hdGlvbiB0aGVyZS4gU2Vjb25kLCBjYXJlIGhhcyB0byBiZSB0YWtlbiB0byBzdHJp cCBvZmYgdGhlIGhlYWRlciANCiAgd2hlbiBpdCBsZWF2ZXMgdGhlIHRydXN0ZWQgZG9tYWluIOKA kyBvdXQgdG8gdGhlIDxTUEFOIGNsYXNzPVNwZWxsRT5VQeKAmXM8L1NQQU4+IA0KICBmb3IgZXhh bXBsZS4gWW91IGRvbuKAmXQgd2FudCBwZW9wbGUga25vd2luZyB3aGF0IGlzIGdvaW5nIG9uIGlu IHlvdXIgYmlsbGluZyANCiAgc3lzdGVtLiA8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0K ICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48 U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZ OiBBcmlhbCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9 TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPkJ1 dCB0aGUgaWRlYSBoZXJlIGlzIA0KICB2ZXJ5IGZsZXhpYmxlIGFuZCBjYW4gdGFrZSBpbnRvIGFj Y291bnQgbWFueSB0aGluZ3MgdGhhdCB3ZSBhcmVu4oCZdCB0aGlua2luZyANCiAgYWJvdXQgbm93 LiBGb3IgZXhhbXBsZSwgd2UgbWF5IGNoYXJnZSBkaWZmZXJlbnRseSBvbmUgZGF5IGNhbGxzIHRo YXQgcmVxdWlyZSANCiAgTkFUIHRyZWF0bWVudCBvbiB0aGUgUlRQIGxldmVsICh3aGVyZSB0aGUg YmFuZHdpZHRoIGNvc3QgdG8gdGhlIGhvc3RpbmcgSVRTUCANCiAgaXMgbm90IG5lZ2xpZ2libGUp LiBXaGVuIHlvdSBmaW5kIHRoYXQgdG8gYmUgdGhlIGNhc2UsIGp1c3QgYWRkIGl0IHRvIHRoZSAN CiAgQmlsbGluZyBoZWFkZXIuIFdoYXQgYWJvdXQgaWYgY2FsbHMgYXJlIGZvcndhcmRlZCBtdWx0 aXBsZSB0aW1lcz8gS2VlcCBhZGRpbmcgDQogIGVhY2ggbGVnIHRvIHRoZSBiaWxsaW5nIGhlYWRl ci48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZP TlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PG86cD4mbmJzcDs8L286 cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJp YWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENP TE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPldoYXQgZG9lcyBldmVyeW9uZSANCiAgdGhp bmsgYWJvdXQgdGhpcz88bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1N c29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PG86 cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxG T05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPkJhcnVjaDxvOnA+PC9v OnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFy aWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBD T0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48 L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTi1MRUZUOiAzNnB0 Ij48Rk9OVCBmYWNlPVRhaG9tYSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQ7IEZPTlQtRkFNSUxZOiBUYWhvbWEiPi0tLS0tT3JpZ2luYWwgDQogIE1lc3NhZ2UtLS0tLTxC Uj48Qj48U1BBTiBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQiPkZyb206PC9TUEFOPjwvQj4gDQog IHNpcC1hZG1pbkBpZXRmLm9yZyBbbWFpbHRvOnNpcC1hZG1pbkBpZXRmLm9yZ10gPEI+PFNQQU4g DQogIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+T24gQmVoYWxmIE9mIA0KICA8L1NQQU4+PC9C PnNheWFuLmNob3dkaHVyeUB3aXByby5jb208QlI+PEI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVdF SUdIVDogYm9sZCI+U2VudDo8L1NQQU4+PC9CPiBXZWRuZXNkYXksIE1heSAxOSwgMjAwNCAxOjAw IA0KICBBTTxCUj48Qj48U1BBTiBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQiPlRvOjwvU1BBTj48 L0I+IGRpZWdvYkBtYWlsdmlzaW9uLmNvbTsgDQogIGJhcnVjaEBrYXlvdGUuY29tPEJSPjxCPjxT UEFOIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+Q2M6PC9TUEFOPjwvQj4gDQogIHNpcEBpZXRm Lm9yZzsgc2lwcGluZ0BpZXRmLm9yZzsgZmx1ZmZ5QGNpc2NvLmNvbTxCUj48Qj48U1BBTiANCiAg c3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5TdWJqZWN0OjwvU1BBTj48L0I+IFJFOiBbU2lwXSBT SVAgRm9yd2FyZCwgV2hvIHBheXMgDQogIHRoZSBiaWxsID88L1NQQU4+PC9GT05UPjwvUD4NCiAg PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tTEVGVDogMzZwdCI+PEZPTlQgZmFjZT0i VGltZXMgTmV3IFJvbWFuIiANCiAgc2l6ZT0zPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEycHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxESVY+DQogIDxQIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM2cHQiPjxGT05UIGZhY2U9IlRpbWVzIE5l dyBSb21hbiIgDQogIHNpemU9Mz48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij5BbHNvICwg QWxpY2UgbWlnaHQgYmUgc2VuZGluZyB0aGUgDQogIHJlLWludml0ZSB0byBvbiByZWNlaXB0IG9m IGEgMzAyIGZyb20gQm9iLiBTbyB0aGUgc2V0IG9mIHByb3hpZXMgaW52bG92ZWQgaW4gDQogIHRo ZSBmaXJzdCBsZWcgb2YgdGhlIGNhbGwgbWF5IG5vdCBiZSBpbnZvbHZlZCBpbiB0aGUgc2Vjb25k IA0KICA/PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tTEVGVDogMzZwdCI+PEZPTlQgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIiANCiAgc2l6ZT0zPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPlNv bHV0dWlvbiB0byB0aGlzIHdpbGwgYmUgb24gdGhlIFBTVE4gDQogIGdhdGV3YXkgc2lkZS48bzpw PjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9Ik1BUkdJTi1MRUZUOiAzNnB0Ij48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iIA0KICBzaXplPTM+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+VGhlIFBTVE4gZ2F0 ZXdheSBzaG91bGQgbG9vayBmb3IgYW5kIGJpbGwgDQogIGZyb20gRGl2ZXJzaW9uL1JlcXVlc3Qg SGlzdG9yeS9yZW1vdGUgUGFydCBIZWFkZXIgaW5mb3JtYXRpb24gaW4gcHJlZmVyZW5jZSB0byAN CiAgdGhlIGZyb20gaGVhZGVyIHdoaWNoIGlzIHVucmVsaWFibGUgYW55IA0Kd2F5LjxvOnA+PC9v OnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM2cHQiPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIg DQogIHNpemU9Mz48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij5Ib3dldmVyICwgSSBkbyBu b3Qga25vdyBvZiBhbnkgc3RhbmRhcmRzIA0KICB3aGljaCBleHBsaWNpdGx5IG1lbnRpb25zIHRo YXQgLi48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTi1MRUZUOiAzNnB0Ij48Rk9OVCBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iIA0KICBzaXplPTM+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+Jm5i c3A7PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tTEVGVDogMzZwdCI+PEZPTlQgZmFjZT0iVGltZXMg TmV3IFJvbWFuIiANCiAgc2l6ZT0zPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPlJlZ2Fy ZHMgDQogICw8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8RElWPg0KICA8 UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTi1MRUZUOiAzNnB0Ij48Rk9OVCBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iIA0KICBzaXplPTM+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+ U2F5YW48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTi1MRUZUOiAzNnB0Ij48Rk9OVCBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iIA0KICBzaXplPTM+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+Jm5i c3A7PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgPEJMT0NLUVVPVEUgc3R5 bGU9Ik1BUkdJTi1UT1A6IDVwdDsgTUFSR0lOLUJPVFRPTTogNXB0OyBNQVJHSU4tUklHSFQ6IDBt bSI+DQogICAgPERJVj4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogICAgc3R5bGU9Ik1BUkdJ Ti1CT1RUT006IDEycHQ7IE1BUkdJTi1MRUZUOiAzNnB0OyBNQVJHSU4tUklHSFQ6IDBtbTsgbXNv LW1hcmdpbi10b3AtYWx0OiAwbW0iPjxGT05UIA0KICAgIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIg c2l6ZT0yPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPi0tLS0tT3JpZ2luYWwgDQogICAg TWVzc2FnZS0tLS0tIDxCUj48Qj48U1BBTiBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQiPkZyb206 PC9TUEFOPjwvQj4gDQogICAgc2lwLWFkbWluQGlldGYub3JnJm5ic3A7b24gYmVoYWxmIG9mJm5i c3A7RGllZ28gQiA8QlI+PEI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5T ZW50OjwvU1BBTj48L0I+IFR1ZSA1LzE4LzIwMDQgNzo0NCBQTSANCiAgICA8QlI+PEI+PFNQQU4g c3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5Ubzo8L1NQQU4+PC9CPiBiYXJ1Y2hAa2F5b3RlLmNv bSANCiAgICA8QlI+PEI+PFNQQU4gc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5DYzo8L1NQQU4+ PC9CPiBzaXBAaWV0Zi5vcmc7IA0KICAgICdzaXBwaW5nJzsgJ0N1bGxlbiBKZW5uaW5ncycgPEJS PjxCPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+U3ViamVjdDo8L1NQQU4+ PC9CPiBSZTogW1NpcF0gU0lQIEZvcndhcmQsIFdobyANCiAgICBwYXlzIHRoZSBiaWxsID88L1NQ QU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICAgIDxQIHN0eWxlPSJNQVJHSU4tTEVG VDogMzZwdCI+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTI+PFNQQU4gDQogICAg c3R5bGU9IkZPTlQtU0laRTogMTBwdCI+SGkgQmFydWNoOzxCUj5UaGFua3MgZm9yIHlvdXIgYW5z d2VyLjxCUj5JIGJlbGl2ZSANCiAgICB0aGF0IHlvdSBhcmUgaW1wbGVtZW50aW5nIGEgcHJvcHJp ZXRhcnkgc29sdXRpb24gdG8gZGVhbCB3aXRoIGl0LjxCUj5JJ20gDQogICAgbG9va2luZyBtb3Jl IHRvIGEgc3RhbmRhcml6ZSB3YXkgdG8gZGVhbCB3aXRoIHRoZSBzZWNvbmQtbGVnIA0KICAgIGlz c3VlLjxCUj48QlI+SSdtIGFncmVlIHRoYXQgQWxpY2UgaGFzIHRvIHBheSBmb3IgdGhlIGZpcnN0 IGxlZyBhbmQgQm9iIGZvciANCiAgICB0aGU8QlI+c2Vjb25kLCBidXQgaWYgdGhlIFByb3h5IHRo YXQgaXMgZG9pbmcgdGhlIGZvcndhcmQgaXMgbm90IGEgDQogICAgYmlsaW5nPEJSPmVudGl0eSAo IGxvY2FsIGNhbGxzIGFyZSBmcmVlLCBvdXRib3VuZCBjYWxsIGFyZSBub3QgZnJlZSBhbmQgDQog ICAgYmlsbGVkIGJ5PEJSPmFuIGV4dGVybmFsIHJlYWwtdGltZSBiaWxsaW5nIHN5c3RlbSBjb25u ZWN0ZWQgdG8gdGhlIEdXIHVzaW5nIA0KICAgIFJBRElVUyBvcjxCUj5zaW1pbGFyKSwgdGhlIFBT VE4gZ2F0ZXdheSB3aWxsIGhhdmUgdG8ga25vdyB0aGF0IHRoaXMgY2FsbCBtYXkgDQogICAgYmU8 QlI+YmlsbGVkIHRvIEJvYiBhbmQgbm90IHRvIEFsaWNlICggc2hlIGFwZWFycyBpbiB0aGUgRnJv bSBoZWFkZXIgDQogICAgKS48QlI+PEJSPlRoYW5rczxCUj48QlI+QmFydWNoIFN0ZXJtYW4gd3Jv dGU6PEJSPjxCUj4mZ3Q7IEluIHRoZSBzeXN0ZW1zIA0KICAgIHRoYXQgd2UgaW1wbGVtZW50ZWQs IHR3byBjZHJzIGFyZSBjcmVhdGVkOiB0aGUgZmlyc3QgZm9yPEJSPiZndDsgdGhlIA0KICAgIGlu Y29taW5nIGxlZyAoQWxpY2UgdG8gQm9iJ3Mgbm9uLWZvcndhcmRlZCBsb2NhdGlvbikgYW5kIGEg c2Vjb25kPEJSPiZndDsgDQogICAgZm9yIHRoZSBmb3J3YXJkIHRvIEJvYidzIGZvcndhcmRlZCBs b2NhdGlvbi48QlI+Jmd0OzxCUj4mZ3Q7IEFsaWNlIHdvdWxkIHBheSANCiAgICBmb3IgdGhlIGZp cnN0IGxlZywgYW5kIEJvYiBwYXlzIGZvciB0aGUgc2Vjb25kLjxCUj4mZ3Q7PEJSPiZndDsgRnVy dGhlcm1vcmUsIA0KICAgIGl0IG1heSBiZSB0aGUgY2FzZSB0aGF0IEJvYiBwYXlzIGZvciB0aGUg Zmlyc3QgbGVnIGFzIHdlbGwuPEJSPiZndDsgSWYsIGZvciANCiAgICBleGFtcGxlLCBCb2IgaGFz IGEgdG9sbCBmcmVlIG51bWJlciB3aGVyZSBoZSBwYXlzIHBlciBtaW51dGU8QlI+Jmd0OyBjaGFy Z2VzIA0KICAgIGZvciB0aGUgaW5ib3VuZCBsZWcgKGluIHRoaXMgY2FzZSwgQWxpY2UgaXMgb24g dGhlIFBTVE4pLjxCUj4mZ3Q7PEJSPiZndDsgDQogICAgRWl0aGVyIHdheSwgbXVsdGlwbGUgQ0RS cyBpcyB0aGUgd2F5IHdlIGNhbWUgdXAgd2l0aCB0byBoYW5kbGUgdGhpcy48QlI+Jmd0OyANCiAg ICBDYXJlIGhhcyB0byBiZSB0YWtlbiB0aGF0IHRoZSBrZXkgdG8gYW55IENEUiBkYXRhYmFzZSBp cyBOT1QgdGhlPEJSPiZndDsgDQogICAgY2FsbC1JRCwgYmVjYXVzZSB0aGlzIGlzIHRoZSBzYW1l IGFjcm9zcyB0aGUgdHdvIENEUnMuPEJSPiZndDs8QlI+Jmd0OyANCiAgICBCYXJ1Y2g8QlI+Jmd0 OzxCUj4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPEJSPiZndDsgRnJvbTogDQogICAg c2lwLWFkbWluQGlldGYub3JnIFs8QSANCiAgICBocmVmPSJtYWlsdG86c2lwLWFkbWluQGlldGYu b3JnIj5tYWlsdG86c2lwLWFkbWluQGlldGYub3JnPC9BPl0gT24gQmVoYWxmIE9mIA0KICAgIERp ZWdvPEJSPiZndDsgQjxCUj4mZ3Q7IFNlbnQ6IFR1ZXNkYXksIE1heSAxOCwgMjAwNCA3OjQyIEFN PEJSPiZndDsgVG86IA0KICAgIHNpcEBpZXRmLm9yZzsgc2lwcGluZzxCUj4mZ3Q7IENjOiBDdWxs ZW4gSmVubmluZ3M8QlI+Jmd0OyBTdWJqZWN0OiBbU2lwXSBTSVAgDQogICAgRm9yd2FyZCwgV2hv IHBheXMgdGhlIGJpbGwgPzxCUj4mZ3Q7PEJSPiZndDsgSGk7PEJSPiZndDsgTXkgcXVlc3Rpb24g aXMgDQogICAgcmVnYXJkaW5nIGJpbGxpbmcgYSBmb3J3YXJkZWQgc2lwIGNhbGwuPEJSPiZndDs8 QlI+Jmd0OyBMZXRzIHRha2UgdGhlIGV4bXBsZSANCiAgICBmcm9tIGRyYWZ0LWlldGYtc2lwcGlu Zy1zZXJ2aWNlLWV4YW1wbGVzPEJSPiZndDsgMi43PEJSPiZndDs8QlI+Jmd0OyBBbGljZSANCiAg ICBjYWxscyBCb2IsIGFuZCBCb2IgaGFzIGFsbCBoaXMgaW5jb21taW5nIGNhbGxzIGZvcndhcmRl ZCB0byB0aGU8QlI+Jmd0OyANCiAgICBQU1ROLjxCUj4mZ3Q7PEJSPiZndDsgTGV0IHNheSB0aGF0 IGNhbGxzIGZyb20gQUxpY2UgdG8gQm9iIGluIHRoZSBzYW1lIA0KICAgIGRvbWFpbiBhcmUgZnJl ZSAoc2FtZTxCUj4mZ3Q7IG9mZmljZSwgb3Igc2FtZSBJVFNQKSwgYnV0IGNhbGxzIHRvIHRoZSBQ U1ROIA0KICAgIGFyZSBub3QgZnJlZS48QlI+Jmd0OzxCUj4mZ3Q7IFdobyBwYXlzIGZvciBBbGlj ZSBjYWxsIHRvIEJvYiA/PzxCUj4mZ3Q7IEluIGEgDQogICAgbm9ybWFsIHNpdHVhY2lvbiwgQWxp Y2Uga25vd3MgdGhhdCB0aGUgY2FsbCBpcyBmb3IgZnJlZSBiZWN1YXNlIA0KICAgIHNoZTxCUj4m Z3Q7PEJSPiZndDsgaXMgY2FsbGluZyBCb2IncyBzaXAgbnVtYmVyLiBCdXQgdGhlIGdhdGV3ZWF5 IG1heSBjcmVhdGUgDQogICAgQ0RSIGZyb20gdGhlPEJSPiZndDsmbmJzcDsgRnJvbSBoZWFkZXIg b2YgdGhlIFNJUCBtZXNzYWdlIGFuZCBhdCB0aGUgZW5kIG9mIA0KICAgIHRoZSBtb250aCBBbGlj ZSBtYXk8QlI+Jmd0OyBoYXZlIHRvIHBheSBmb3IgdGhlIGNhbGwuPEJSPiZndDs8QlI+Jmd0OyBJ IHNlZSANCiAgICB0aGlzIGtpbmQgb2YgZXhhbXBsZXMgaW4gc2V2ZXJhbCBvdGhlciBkcmFmdHMv UkZDIHJlbGF0ZWQgdG8gU0lQPEJSPiZndDsgDQogICAgc2VydmljZXMgYW5kIGNhbGwgZm9yd2Fy ZC48QlI+Jmd0OzxCUj4mZ3Q7IEkgYmVsaXZlIGZvcndhcmQgaXMgYSB2ZXJ5IA0KICAgIGltcG9y dGFudCBmZWF0dXJlLCBidXQgdGhpcyBpc3N1ZSBtYXkgYmU8QlI+Jmd0OyByZXNvbHZlZC4gVGhl IHF1ZXN0aW9uIGlzIA0KICAgIGlmIGl0IGlzIGEgc3RhbmRhcmQgd2F5IHRvIG1ha2UgQm9iIHBh eXMgZm9yPEJSPiZndDsgdGhlIHNlY29uZCBsZWcgb2YgdGhlIA0KICAgIGNhbGwgbGlrZSBpbiBQ U1ROIGZvcndhcmQuPEJSPiZndDs8QlI+Jmd0OyBNYXliZSBjaGFuZ2luZyB0aGUgRnJvbSBoZWFk ZXIgDQogICAgd2hlcmUgYXBwbGljYWJsZSBhbmQgYWRkaW5nIGEgbmV3IG9uZSB0bzxCUj4mZ3Q7 ICJyZW1lbWJlciIgdGhhdCB0aGUgY2FsbCBpcyANCiAgICBmcm9tLCBpbiBteSBleGFtcGxlLCBB bGljZS48QlI+Jmd0OzxCUj4mZ3Q7IFRoZSBkaXZlcnNpb24gaGVhZGVyIChEaXZlcnNpb24gDQog ICAgSW5kaWNhdGlvbiBpbiBTSVA8QlI+Jmd0OyBkcmFmdC1sZXZ5LXNpcC1kaXZlcnNpb24tMDcu dHh0KSIgbWF5IGJlIGEgDQogICAgc29sdXRpb24gaWYgdGhlIFBTVE4gZ2F0ZXdheTxCUj4mZ3Q7 IG9yIHRoZSBTSVAgQmlsbGluZyBzZXJ2ZXIgc3VwcG9ydCBpdCANCiAgICBhbmQga25vd3MgdGhh dCB0aGV5IGhhdmUgdG8gYmlsbDxCUj4mZ3Q7IHRoZSBzaXAtdXJpIGluIHRoZSBkaXZlcnNpb24g aGVhZGVyIA0KICAgICggdGhpcyBpcyByaWdodCA/Pz8gKS48QlI+Jmd0OzxCUj4mZ3Q7IA0KICAg IFJlZ2FyZHM7PEJSPiZndDs8QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OzxCUj48QlI+ LS08QlI+RGllZ28gDQogICAgQjxCUj5NYWlsVmlzaW9uIEx0ZC48QlI+VGVsLiZuYnNwOyA6IO+e vTQtODUwMDUwNSBleHQgMTM8L1NQQU4+PC9GT05UPjxGT05UIA0KICAgIGZhY2U9QmF0YW5nIHNp emU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQmF0 YW5nOyBtc28tYmlkaS1mb250LWZhbWlseTogQmF0YW5nIj48QlI+PC9TUEFOPjwvRk9OVD48Rk9O VCANCiAgICBzaXplPTI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+ZS1tYWlsOiANCiAg ICBkaWVnb2JAbWFpbHZpc2lvbi5jb208L1NQQU4+PC9GT05UPjxGT05UIGZhY2U9QmF0YW5nIHNp emU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQmF0 YW5nOyBtc28tYmlkaS1mb250LWZhbWlseTogQmF0YW5nIj48QlI+PC9TUEFOPjwvRk9OVD48Rk9O VCANCiAgICBzaXplPTI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+d2ViJm5ic3A7Jm5i c3A7IDogPEEgDQogICAgaHJlZj0iaHR0cHM6Ly9nYXRld2F5LWluZGlhLndpcHJvLmNvbS8sRGFu YUluZm89d3d3Lm1haWx2aXNpb24uY29tIj5odHRwOi8vd3d3Lm1haWx2aXNpb24uY29tPC9BPjxC Uj48QlI+PEJSPjxCUj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxCUj5TaXAgDQogICAgbWFpbGluZyBsaXN0Jm5ic3A7IDxBIA0KICAgIGhyZWY9Imh0dHBz Oi8vZ2F0ZXdheS1pbmRpYS53aXByby5jb20vbWFpbG1hbi9saXN0aW5mby9zaXAsRGFuYUluZm89 d3d3MS5pZXRmLm9yZyxTU0wiPmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NpcDwvQT48QlI+VGhpcyANCiAgICBsaXN0IGlzIGZvciBORVcgZGV2ZWxvcG1lbnQgb2YgdGhl IGNvcmUgU0lQIFByb3RvY29sPEJSPlVzZSANCiAgICBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVt YmlhLmVkdSBmb3IgcXVlc3Rpb25zIG9uIGN1cnJlbnQgc2lwPEJSPlVzZSANCiAgICBzaXBwaW5n QGlldGYub3JnIGZvciBuZXcgZGV2ZWxvcG1lbnRzIG9uIHRoZSBhcHBsaWNhdGlvbiBvZiANCiAg ICBzaXA8L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvQkxPQ0tRVU9URT48L0RJVj48L0JM T0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== ------_=_NextPart_001_01C43E0C.B427AD59-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 20 01:20:15 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14394 for ; Thu, 20 May 2004 01:20:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQfsL-0007g1-UX for sip-archive@odin.ietf.org; Thu, 20 May 2004 01:13:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4K5DnM9029510 for sip-archive@odin.ietf.org; Thu, 20 May 2004 01:13:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQflo-0005PE-Jw; Thu, 20 May 2004 01:07:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQfiS-0004gR-Py for sip@optimus.ietf.org; Thu, 20 May 2004 01:03: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 BAA13869 for ; Thu, 20 May 2004 01:03:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQfiP-00032t-Rr for sip@ietf.org; Thu, 20 May 2004 01:03:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQfhQ-0002sK-00 for sip@ietf.org; Thu, 20 May 2004 01:02:33 -0400 Received: from [203.196.146.243] (helo=Mistralsoftware.com) by ietf-mx with esmtp (Exim 4.12) id 1BQfgj-0002gU-00 for sip@ietf.org; Thu, 20 May 2004 01:01:50 -0400 Received: from mistralsoftware.com ([192.168.13.126]) (authenticated user gautham@mistralsoftware.com) by mistralsoftware.com (mistralsoftware.com [192.168.10.12]) (MDaemon.PRO.v7.0.1.R) with ESMTP id md50000175832.msg for ; Thu, 20 May 2004 10:31:52 +0530 Message-ID: <40AC39C8.4080602@mistralsoftware.com> Date: Thu, 20 May 2004 10:23:28 +0530 From: gautham User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: frank.derks@philips.com CC: sip@ietf.org Subject: Re: [Sip] Symmetric response routing -> Or where to return a response to? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: gautham@mistralsoftware.com X-Spam-Processed: mistralsoftware.com, Thu, 20 May 2004 10:31:52 +0530 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.13.126 X-Return-Path: gautham@mistralsoftware.com X-MDaemon-Deliver-To: sip@ietf.org X-MDAV-Processed: mistralsoftware.com, Thu, 20 May 2004 10:31:55 +0530 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, In SIP, responses are required to traverse the same set of entities traversed by the request in the reverse order. This is so that these entities can give up any transaction state that they may have for purposes of retransmission etc. It is to aid this that resposnses are sent to the IP address the request came from. The source port is not used since it would typically be an ephemeral port and so that the client/server can listen on a single port for both requests and responses. Section 18.2.2 of 3261 gives the procedures for selecting where to send responses. The 'maddr' parameter is used if it is present. If not, the 'received' parameter is used. This is the second choice. The 'received' parameter which contains the source IP address is added by the UAS if the 'via' in the request contains a host name or if it contains an IP address different from the source IP address. If sending to either of these fails, or there is no 'received' parameter, the steps given in 3263 need to be followed. Hope this helps. Regards, A. N. Gautham frank.derks@philips.com wrote: >RFC 3581 states that SIP, when used with UDP, returns responses to the IP >adress >the request came from and to the port number contained in the topmost Via >header >of that request. This behaviour introduces a "hybrid" way of determining >where >to return the response to. > >I am somewhat surprised that the above behaviour is supposed to be SIP's >"default" >behaviour. The Via header will always contain a host name and may contain >a port >number. Wouldn't it then be the logical thing to do to return the response >to the >host address specified in the Via header? > >Furthermore, it may well be the case that the Via header does not contain >a port >number.What should the behaviour be in such a case? Should the response be >sent >to the default port (5060 if SIP is used) or should it be sent to the >source port >in the UDP header of the request? > >Cheers, > >Frank > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP 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 May 20 17:42:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27995 for ; Thu, 20 May 2004 17:42: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 1BQv4L-0005gd-3H for sip-archive@odin.ietf.org; Thu, 20 May 2004 17:27:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KLRDEt021834 for sip-archive@odin.ietf.org; Thu, 20 May 2004 17:27:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQunx-0007gn-7P; Thu, 20 May 2004 17:10:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQuEV-0006mx-TP for sip@optimus.ietf.org; Thu, 20 May 2004 16:33: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 QAA19654 for ; Thu, 20 May 2004 16:33:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQuET-0000uI-VK for sip@ietf.org; Thu, 20 May 2004 16:33:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQuDU-0000mE-00 for sip@ietf.org; Thu, 20 May 2004 16:32:37 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BQuCh-0000e3-00 for sip@ietf.org; Thu, 20 May 2004 16:31:47 -0400 Received: from dynamicsoft.com ([63.113.46.118]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i4KKVXbo005981; Thu, 20 May 2004 16:31:34 -0400 (EDT) Message-ID: <40AD1588.5060308@dynamicsoft.com> Date: Thu, 20 May 2004 16:31:04 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: frank.derks@philips.com CC: sip@ietf.org Subject: Re: [Sip] Symmetric response routing -> Or where to return a response to? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 frank.derks@philips.com wrote: > RFC 3581 states that SIP, when used with UDP, returns responses to the IP > adress > the request came from and to the port number contained in the topmost Via > header > of that request. This behaviour introduces a "hybrid" way of determining > where > to return the response to. > > I am somewhat surprised that the above behaviour is supposed to be SIP's > "default" > behaviour. The Via header will always contain a host name and may contain > a port > number. Wouldn't it then be the logical thing to do to return the response > to the > host address specified in the Via header? The protocol was designed this way to allow listening for requests and responses on a single port, while at the same time using ephemeral ports for sending, so that ICMP errors could be collected. It was done before NATs, and specifically NAT-PT, were the plague that they are now. > > Furthermore, it may well be the case that the Via header does not contain > a port > number.What should the behaviour be in such a case? Should the response be > sent > to the default port (5060 if SIP is used) or should it be sent to the > source port > in the UDP header of the request? 5060. Also note that TCP behavior is as expected, and that responses are sent over the connection the request came in on, and will thus traverse NAT fine. -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 May 20 17:43:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28120 for ; Thu, 20 May 2004 17:43: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 1BQv8D-0006tF-N1 for sip-archive@odin.ietf.org; Thu, 20 May 2004 17:31:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KLVDaW026481 for sip-archive@odin.ietf.org; Thu, 20 May 2004 17:31:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQuog-0007s0-A1; Thu, 20 May 2004 17: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 1BQuLn-0002fM-9A for sip@optimus.ietf.org; Thu, 20 May 2004 16:41:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20584 for ; Thu, 20 May 2004 16:41:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQuLl-0001vp-2Q for sip@ietf.org; Thu, 20 May 2004 16:41:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQuKO-0001hn-00 for sip@ietf.org; Thu, 20 May 2004 16:39:45 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BQuJ4-0001Qe-00; Thu, 20 May 2004 16:38:22 -0400 Received: from dynamicsoft.com ([63.113.46.118]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i4KKatbo005987; Thu, 20 May 2004 16:36:55 -0400 (EDT) Message-ID: <40AD16CA.7050407@dynamicsoft.com> Date: Thu, 20 May 2004 16:36:26 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roy, Radhika R, ALABS" CC: baruch@kayote.com, sayan.chowdhury@wipro.com, diegob@mailvision.com, sip@ietf.org, sipping@ietf.org, fluffy@cisco.com Subject: Re: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? References: <34DA635B184A644DA4588E260EC0A25A07217374@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <34DA635B184A644DA4588E260EC0A25A07217374@ACCLUST02EVS1.ugd.att.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.dynamicsoft.com id i4KKatbo005987 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 To be clear, Baruch is proposing a new SIP header, which the SIP WG=20 would need to worry about. I do not think such a thing is needed. As Keith pointed out, our=20 philosophy to date (and this is a broader IETF thing too), is to make=20 sure that you can *account* for what has happened. That is, that the=20 protocols contain sufficient information to record what transpired in a=20 call/transaction/dialog or whatever. Then, its someone elses problem=20 (for example, 3gpp) to specify how the appropriate information is=20 collected, what billing model is used, and how a CDR is generated. Not=20 to say that these things arent important, they're just not the SIP=20 working group's problem. -Jonathan R. Roy, Radhika R, ALABS wrote: > I agree with Baruch that AAA group is working for authentication,=20 > authorization, and accounting of applications including SIP, and there=20 > is enough room to build CDRs/Billing based on those things. So, SIP WG=20 > does not need to be worried for this. > =20 > Radhika R. Roy > rrroy@att.com >=20 > -----Original Message----- > *From:* sip-admin@ietf.org [mailto:sip-admin@ietf.org]*On Behalf Of > *Baruch Sterman > *Sent:* Wednesday, May 19, 2004 5:47 AM > *To:* sayan.chowdhury@wipro.com; diegob@mailvision.com > *Cc:* sip@ietf.org; sipping@ietf.org; fluffy@cisco.com > *Subject:* RE: [Sip] SIP Forward, Who pays the bill ? >=20 > Another avenue that can be explored is an explicit header to deal > with this and other accounting issues. I think that the AAA group > has suggested an ACCOUNTING header. We were thinking of a BILLING > header. In that header you would have a username and type. So as th= e > call progresses you could add to that header. This would also allow > to charge for various services along the way. Imagine the following. > Alice calls Bob, Bob forwards to Charlie who requires an ENUM looku= p > to find his IP =E2=80=93 and you are dealing with a psychotic ITSP = that > **Charges** for ENUM listing. >=20 > Inbound Alice -> Bob Billing: Alice, inbound >=20 > Forward Bob -> Charlie Billing: Alice, inbound; Bob, outbound >=20 > ITSP looks up Charlie Billing: Alice, inbound; Bob, outbound= ; > Charlie, serviceX >=20 > =20 >=20 > So when the CDR gets written, the rating engine looks through the > Billing header and applies all the relevant charges to the relevant > accounts. Some may be per minute, some may be fixed charges. >=20 > =20 >=20 > The problems are first and foremost, security. No one can add to th= e > billing header unless they are trusted entities within your system, > because money will be charged based on the information there. > Second, care has to be taken to strip off the header when it leaves > the trusted domain =E2=80=93 out to the UA=E2=80=99s for example. Y= ou don=E2=80=99t want > people knowing what is going on in your billing system. >=20 > =20 >=20 > But the idea here is very flexible and can take into account many > things that we aren=E2=80=99t thinking about now. For example, we m= ay charge > differently one day calls that require NAT treatment on the RTP > level (where the bandwidth cost to the hosting ITSP is not > negligible). When you find that to be the case, just add it to the > Billing header. What about if calls are forwarded multiple times? > Keep adding each leg to the billing header. >=20 > =20 >=20 > What does everyone think about this? >=20 > =20 >=20 > Baruch >=20 > =20 >=20 > -----Original Message----- > *From:* sip-admin@ietf.org [mailto:sip-admin@ietf.org] *On Behalf O= f > *sayan.chowdhury@wipro.com > *Sent:* Wednesday, May 19, 2004 1:00 AM > *To:* diegob@mailvision.com; baruch@kayote.com > *Cc:* sip@ietf.org; sipping@ietf.org; fluffy@cisco.com > *Subject:* RE: [Sip] SIP Forward, Who pays the bill ? >=20 > =20 >=20 > Also , Alice might be sending the re-invite to on receipt of a 302 > from Bob. So the set of proxies invloved in the first leg of the > call may not be involved in the second ? >=20 > Solutuion to this will be on the PSTN gateway side. >=20 > The PSTN gateway should look for and bill from Diversion/Request > History/remote Part Header information in preference to the from > header which is unreliable any way. >=20 > However , I do not know of any standards which explicitly mentions > that .. >=20 > =20 >=20 > Regards , >=20 > Sayan >=20 > =20 >=20 > -----Original Message----- > *From:* sip-admin@ietf.org on behalf of Diego B > *Sent:* Tue 5/18/2004 7:44 PM > *To:* baruch@kayote.com > *Cc:* sip@ietf.org; 'sipping'; 'Cullen Jennings' > *Subject:* Re: [Sip] SIP Forward, Who pays the bill ? >=20 > Hi Baruch; > Thanks for your answer. > I belive that you are implementing a proprietary solution to > deal with it. > I'm looking more to a standarize way to deal with the second-le= g > issue. >=20 > I'm agree that Alice has to pay for the first leg and Bob for t= he > second, but if the Proxy that is doing the forward is not a bil= ing > entity ( local calls are free, outbound call are not free and > billed by > an external real-time billing system connected to the GW using > RADIUS or > similar), the PSTN gateway will have to know that this call may= be > billed to Bob and not to Alice ( she apears in the From header = ). >=20 > Thanks >=20 > Baruch Sterman wrote: >=20 >> In the systems that we implemented, two cdrs are created: the > first for >> the incoming leg (Alice to Bob's non-forwarded location) and a > second >> for the forward to Bob's forwarded location. >> >> Alice would pay for the first leg, and Bob pays for the second. >> >> Furthermore, it may be the case that Bob pays for the first > leg as well. >> If, for example, Bob has a toll free number where he pays per > minute >> charges for the inbound leg (in this case, Alice is on the PSTN). >> >> Either way, multiple CDRs is the way we came up with to handle > this. >> Care has to be taken that the key to any CDR database is NOT the >> call-ID, because this is the same across the two CDRs. >> >> Baruch >> >> -----Original Message----- >> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf > Of Diego >> B >> Sent: Tuesday, May 18, 2004 7:42 AM >> To: sip@ietf.org; sipping >> Cc: Cullen Jennings >> Subject: [Sip] SIP Forward, Who pays the bill ? >> >> Hi; >> My question is regarding billing a forwarded sip call. >> >> Lets take the exmple from draft-ietf-sipping-service-examples >> 2.7 >> >> Alice calls Bob, and Bob has all his incomming calls forwarded > to the >> PSTN. >> >> Let say that calls from ALice to Bob in the same domain are > free (same >> office, or same ITSP), but calls to the PSTN are not free. >> >> Who pays for Alice call to Bob ?? >> In a normal situacion, Alice knows that the call is for free > becuase she >> >> is calling Bob's sip number. But the gateweay may create CDR > from the >> From header of the SIP message and at the end of the month > Alice may >> have to pay for the call. >> >> I see this kind of examples in several other drafts/RFC > related to SIP >> services and call forward. >> >> I belive forward is a very important feature, but this issue > may be >> resolved. The question is if it is a standard way to make Bob > pays for >> the second leg of the call like in PSTN forward. >> >> Maybe changing the From header where applicable and adding a > new one to >> "remember" that the call is from, in my example, Alice. >> >> The diversion header (Diversion Indication in SIP >> draft-levy-sip-diversion-07.txt)" may be a solution if the > PSTN gateway >> or the SIP Billing server support it and knows that they have > to bill >> the sip-uri in the diversion header ( this is right ??? ). >> >> Regards; >> >> >> >> >> >=20 > -- > Diego B > MailVision Ltd. > Tel. : =EF=9E=BD4-8500505 ext 13 > e-mail: diegob@mailvision.com > web : http://www.mailvision.com > >=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 s= ip > Use sipping@ietf.org for new developments on the application of= sip >=20 --=20 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 May 20 17:48:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28405 for ; Thu, 20 May 2004 17:48:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQvDZ-0000vi-6a for sip-archive@odin.ietf.org; Thu, 20 May 2004 17:36:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4KLaj00003484 for sip-archive@odin.ietf.org; Thu, 20 May 2004 17:36:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQuyb-0002aX-Na; Thu, 20 May 2004 17:21:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQuOZ-00044k-Ko for sip@optimus.ietf.org; Thu, 20 May 2004 16:44: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 QAA20910 for ; Thu, 20 May 2004 16:43:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQuO8-0002KI-75 for sip@ietf.org; Thu, 20 May 2004 16:43:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQuMy-00028N-00 for sip@ietf.org; Thu, 20 May 2004 16:42:25 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1BQuLj-0001rG-00 for sip@ietf.org; Thu, 20 May 2004 16:41:07 -0400 Received: from dynamicsoft.com ([63.113.46.118]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i4KKembo005990; Thu, 20 May 2004 16:40:48 -0400 (EDT) Message-ID: <40AD17B3.2010501@dynamicsoft.com> Date: Thu, 20 May 2004 16:40:19 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sreeram.kanumuri@wipro.com CC: vishnuyadav@deccanetworld.com, sip@ietf.org Subject: Re: [Sip] t field in SDP References: <72001BBBF6CB124BA1C40E415914E2130301EA@blr-ec-msg04.wipro.com> In-Reply-To: <72001BBBF6CB124BA1C40E415914E2130301EA@blr-ec-msg04.wipro.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,EXCUSE_16 autolearn=no version=2.60 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 advice is to not use anything but 0 0. The t parameter was defined initially for loosely coupled multicast conferences, where the only signaling was the SDP, and it needed to indicate when you should join and leave the multicast group. For traditional SIP calls, it has little meaning, since the SIP signaling indicates the start and stop (INVITE created on start, BYE sent on stop). RFC 3264 recommends (at SHOULD strength) setting it to 0 0. I doubt that anything else will interoperate, since I suspect almost all implementations completely ignore this field, expecting it to be 0 0. -Jonathan R. sreeram.kanumuri@wipro.com wrote: > 1) If the Stop time is non Zero, and in between the call it demineshes > to zero then what happens? how is the termination of session takes place? > If the stop time is 0 then the session terminates.that means session > becomes inactive. > You can take this the case you established a call and RTP is active and > it becomes inactive in the middle.than its your application > responsibility to observe this and act on terminating the session. > > 2) here both the timings are represented in decimal, but what it > signifies.That is if the user wants to set start time as 1 minute then > what value he/she should set for the start time in t . > These values are decimal representation of NTP time values in seconds. > To get the unixtime ,subtract decimal number 2208988800 from that number. > > -SReeram > > -----Original Message----- > *From:* sip-admin@ietf.org [mailto:sip-admin@ietf.org] *On Behalf Of > *Vishnu Yadav > *Sent:* Tuesday, May 18, 2004 2:28 PM > *To:* sip@ietf.org > *Subject:* [Sip] t field in SDP > > In SDP, the line t= , > describes start time & end time of session . > > 1) If the Stop time is non Zero, and in between the call it > demineshes to zero then what happens? how is the termination of > session takes place? > 2) here both the timings are represented in decimal, but what it > signifies.That is if the user wants to set start time as 1 minute > then what value he/she should set for the start time in t . > > Thanx in advance > vishnu yadav > > ********************************DISCLAIMER********************************** > > This e-mail and any attachment is for authorised use by the intended > recipient(s) only. It may contain proprietary material, confidential > information and/or be subject to legal privilege of Deccanet Designs Ltd. > If you have received this message in error, please notify the originator > immediately. If you are not the intended recipient, you are notified that > you are strictly prohibited from retaining, using, copying, altering or > disclosing the contents of this message. > > **************************************************************************** -- 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 May 20 23:56:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17790 for ; Thu, 20 May 2004 23:56: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 1BR0y9-0003zD-TV for sip-archive@odin.ietf.org; Thu, 20 May 2004 23:45:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4L3jDwA015321 for sip-archive@odin.ietf.org; Thu, 20 May 2004 23:45:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR0tN-0002mx-2h; Thu, 20 May 2004 23:40:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR0pc-0001aM-9Z for sip@optimus.ietf.org; Thu, 20 May 2004 23:36: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 XAA16782 for ; Thu, 20 May 2004 23:36:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR0pa-0007jx-6r for sip@ietf.org; Thu, 20 May 2004 23:36:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR0ob-0007df-00 for sip@ietf.org; Thu, 20 May 2004 23:35:22 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BR0o5-0007VU-00; Thu, 20 May 2004 23:34:49 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 20 May 2004 20:32:52 -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.10/8.12.6) with ESMTP id i4L3YHf9008880; Thu, 20 May 2004 20:34:17 -0700 (PDT) Received: from [10.0.1.3] (sjc-vpn3-1222.cisco.com [10.21.68.198]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id APD35066; Thu, 20 May 2004 20:34:15 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 20 May 2004 20:33:12 -0700 Subject: Re: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? From: Cullen Jennings To: Jonathan Rosenberg , "Roy, Radhika R, ALABS" CC: , , , , Message-ID: In-Reply-To: <40AD16CA.7050407@dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 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 Agree but wanted to add one little wrinkle that has been frustrating. In SIP, things like the call-id are often used to help figure out what has happened to the call. However, these are often selected by the UA with very little constraints on them. Most SIP systems allow call-id to be infinitely long, but most radius billing systems and databases used for correlation of billing records use fields with some fixed maximum length. Implementers should be aware of attacks based on this. Allowing the user (instead of the network) to pick the identifier used to correlate billing information is no= t the most desirable things from a security point of view. Cullen On 5/20/04 1:36 PM, "Jonathan Rosenberg" wrote: > To be clear, Baruch is proposing a new SIP header, which the SIP WG > would need to worry about. >=20 > I do not think such a thing is needed. As Keith pointed out, our > philosophy to date (and this is a broader IETF thing too), is to make > sure that you can *account* for what has happened. That is, that the > protocols contain sufficient information to record what transpired in a > call/transaction/dialog or whatever. Then, its someone elses problem > (for example, 3gpp) to specify how the appropriate information is > collected, what billing model is used, and how a CDR is generated. Not > to say that these things arent important, they're just not the SIP > working group's problem. >=20 > -Jonathan R. >=20 > Roy, Radhika R, ALABS wrote: >=20 >> I agree with Baruch that AAA group is working for authentication, >> authorization, and accounting of applications including SIP, and there >> is enough room to build CDRs/Billing based on those things. So, SIP WG >> does not need to be worried for this. >> =20 >> Radhika R. Roy >> rrroy@att.com >>=20 >> -----Original Message----- >> *From:* sip-admin@ietf.org [mailto:sip-admin@ietf.org]*On Behalf Of >> *Baruch Sterman >> *Sent:* Wednesday, May 19, 2004 5:47 AM >> *To:* sayan.chowdhury@wipro.com; diegob@mailvision.com >> *Cc:* sip@ietf.org; sipping@ietf.org; fluffy@cisco.com >> *Subject:* RE: [Sip] SIP Forward, Who pays the bill ? >>=20 >> Another avenue that can be explored is an explicit header to deal >> with this and other accounting issues. I think that the AAA group >> has suggested an ACCOUNTING header. We were thinking of a BILLING >> header. In that header you would have a username and type. So as the >> call progresses you could add to that header. This would also allow >> to charge for various services along the way. Imagine the following. >> Alice calls Bob, Bob forwards to Charlie who requires an ENUM lookup >> to find his IP =AD and you are dealing with a psychotic ITSP that >> **Charges** for ENUM listing. >>=20 >> Inbound Alice -> Bob Billing: Alice, inbound >>=20 >> Forward Bob -> Charlie Billing: Alice, inbound; Bob, outbound >>=20 >> ITSP looks up Charlie Billing: Alice, inbound; Bob, outbound; >> Charlie, serviceX >>=20 >> =20 >>=20 >> So when the CDR gets written, the rating engine looks through the >> Billing header and applies all the relevant charges to the relevant >> accounts. Some may be per minute, some may be fixed charges. >>=20 >> =20 >>=20 >> The problems are first and foremost, security. No one can add to the >> billing header unless they are trusted entities within your system, >> because money will be charged based on the information there. >> Second, care has to be taken to strip off the header when it leaves >> the trusted domain =AD out to the UA=B9s for example. You don=B9t want >> people knowing what is going on in your billing system. >>=20 >> =20 >>=20 >> But the idea here is very flexible and can take into account many >> things that we aren=B9t thinking about now. For example, we may charge >> differently one day calls that require NAT treatment on the RTP >> level (where the bandwidth cost to the hosting ITSP is not >> negligible). When you find that to be the case, just add it to the >> Billing header. What about if calls are forwarded multiple times? >> Keep adding each leg to the billing header. >>=20 >> =20 >>=20 >> What does everyone think about this? >>=20 >> =20 >>=20 >> Baruch >>=20 >> =20 >>=20 >> -----Original Message----- >> *From:* sip-admin@ietf.org [mailto:sip-admin@ietf.org] *On Behalf Of >> *sayan.chowdhury@wipro.com >> *Sent:* Wednesday, May 19, 2004 1:00 AM >> *To:* diegob@mailvision.com; baruch@kayote.com >> *Cc:* sip@ietf.org; sipping@ietf.org; fluffy@cisco.com >> *Subject:* RE: [Sip] SIP Forward, Who pays the bill ? >>=20 >> =20 >>=20 >> Also , Alice might be sending the re-invite to on receipt of a 302 >> from Bob. So the set of proxies invloved in the first leg of the >> call may not be involved in the second ? >>=20 >> Solutuion to this will be on the PSTN gateway side. >>=20 >> The PSTN gateway should look for and bill from Diversion/Request >> History/remote Part Header information in preference to the from >> header which is unreliable any way. >>=20 >> However , I do not know of any standards which explicitly mentions >> that .. >>=20 >> =20 >>=20 >> Regards , >>=20 >> Sayan >>=20 >> =20 >>=20 >> -----Original Message----- >> *From:* sip-admin@ietf.org on behalf of Diego B >> *Sent:* Tue 5/18/2004 7:44 PM >> *To:* baruch@kayote.com >> *Cc:* sip@ietf.org; 'sipping'; 'Cullen Jennings' >> *Subject:* Re: [Sip] SIP Forward, Who pays the bill ? >>=20 >> Hi Baruch; >> Thanks for your answer. >> I belive that you are implementing a proprietary solution to >> deal with it. >> I'm looking more to a standarize way to deal with the second-leg >> issue. >>=20 >> I'm agree that Alice has to pay for the first leg and Bob for th= e >> second, but if the Proxy that is doing the forward is not a bili= ng >> entity ( local calls are free, outbound call are not free and >> billed by >> an external real-time billing system connected to the GW using >> RADIUS or >> similar), the PSTN gateway will have to know that this call may = be >> billed to Bob and not to Alice ( she apears in the From header )= . >>=20 >> Thanks >>=20 >> Baruch Sterman wrote: >>=20 >>> In the systems that we implemented, two cdrs are created: the >> first for >>> the incoming leg (Alice to Bob's non-forwarded location) and a >> second >>> for the forward to Bob's forwarded location. >>>=20 >>> Alice would pay for the first leg, and Bob pays for the second. >>>=20 >>> Furthermore, it may be the case that Bob pays for the first >> leg as well. >>> If, for example, Bob has a toll free number where he pays per >> minute >>> charges for the inbound leg (in this case, Alice is on the PSTN). >>>=20 >>> Either way, multiple CDRs is the way we came up with to handle >> this. >>> Care has to be taken that the key to any CDR database is NOT the >>> call-ID, because this is the same across the two CDRs. >>>=20 >>> Baruch >>>=20 >>> -----Original Message----- >>> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf >> Of Diego >>> B >>> Sent: Tuesday, May 18, 2004 7:42 AM >>> To: sip@ietf.org; sipping >>> Cc: Cullen Jennings >>> Subject: [Sip] SIP Forward, Who pays the bill ? >>>=20 >>> Hi; >>> My question is regarding billing a forwarded sip call. >>>=20 >>> Lets take the exmple from draft-ietf-sipping-service-examples >>> 2.7 >>>=20 >>> Alice calls Bob, and Bob has all his incomming calls forwarded >> to the >>> PSTN. >>>=20 >>> Let say that calls from ALice to Bob in the same domain are >> free (same >>> office, or same ITSP), but calls to the PSTN are not free. >>>=20 >>> Who pays for Alice call to Bob ?? >>> In a normal situacion, Alice knows that the call is for free >> becuase she >>>=20 >>> is calling Bob's sip number. But the gateweay may create CDR >> from the >>> From header of the SIP message and at the end of the month >> Alice may >>> have to pay for the call. >>>=20 >>> I see this kind of examples in several other drafts/RFC >> related to SIP >>> services and call forward. >>>=20 >>> I belive forward is a very important feature, but this issue >> may be >>> resolved. The question is if it is a standard way to make Bob >> pays for >>> the second leg of the call like in PSTN forward. >>>=20 >>> Maybe changing the From header where applicable and adding a >> new one to >>> "remember" that the call is from, in my example, Alice. >>>=20 >>> The diversion header (Diversion Indication in SIP >>> draft-levy-sip-diversion-07.txt)" may be a solution if the >> PSTN gateway >>> or the SIP Billing server support it and knows that they have >> to bill >>> the sip-uri in the diversion header ( this is right ??? ). >>>=20 >>> Regards; >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> -- >> Diego B >> MailVision Ltd. >> Tel. : ?4-8500505 ext 13 >> e-mail: diegob@mailvision.com >> web : http://www.mailvision.com >> >>=20 >>=20 >>=20 >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> =20 >> > SSL> >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current si= p >> 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 Fri May 21 04:05:38 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13595 for ; Fri, 21 May 2004 04:05: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 1BR4zT-00014S-8E for sip-archive@odin.ietf.org; Fri, 21 May 2004 04:02:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4L82pid004116 for sip-archive@odin.ietf.org; Fri, 21 May 2004 04:02:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR4s2-0007Q2-CL; Fri, 21 May 2004 03:55:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR4hc-00055E-Ab for sip@optimus.ietf.org; Fri, 21 May 2004 03:44: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 DAA12873 for ; Fri, 21 May 2004 03:44:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR4hZ-0007F2-SG for sip@ietf.org; Fri, 21 May 2004 03:44:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR4gZ-000752-00 for sip@ietf.org; Fri, 21 May 2004 03:43:20 -0400 Received: from mail.deccanetworld.com ([203.196.146.50] helo=gatekeeper.deccanetworld.com) by ietf-mx with esmtp (Exim 4.12) id 1BR4fZ-0006uh-00 for sip@ietf.org; Fri, 21 May 2004 03:42:17 -0400 Received: from gatekeeper.deccanetworld.com (localhost [127.0.0.1]) by gatekeeper.deccanetworld.com (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id i4L7WZ15011013 for ; Fri, 21 May 2004 13:02:35 +0530 Received: from mail.deccanetworld.com (server.deccanetworld.com [192.168.1.32]) by gatekeeper.deccanetworld.com (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id i4L7WY6i010789 for ; Fri, 21 May 2004 13:02:34 +0530 Received: (from root@localhost) by mail.deccanetworld.com (8.11.0/8.11.0) id i4L7sS211548 for sip@ietf.org; Fri, 21 May 2004 13:24:28 +0530 Received: from gvvivek (bharathi.software [192.168.1.224] (may be forged)) by mail.deccanetworld.com (8.11.0/8.11.0) with SMTP id i4L7sSq11504 for ; Fri, 21 May 2004 13:24:28 +0530 Message-ID: <00ae01c43f06$fa4954c0$e001a8c0@gvvivek> From: "Vishnu Yadav" To: Date: Fri, 21 May 2004 13:11:07 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AB_01C43F35.13FA64D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,EXCUSE_16,HTML_20_30, HTML_MESSAGE autolearn=no version=2.60 Subject: [Sip] 2XX, in resonse to MESSAGE; MUST NOT contain Contact header fld, WHY ? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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_00AB_01C43F35.13FA64D0 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable 2xx, sent by UAS in response to MESSAGE request must not contain Contact = header in it. Why is it so ?=20 Thanx Vishnu Yadav ********************************DISCLAIMER********************************** This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege of Deccanet Designs Ltd. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from retaining, using, copying, altering or disclosing the contents of this message. **************************************************************************** ------=_NextPart_000_00AB_01C43F35.13FA64D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
2xx, sent by UAS in response = to MESSAGE=20 request must not contain Contact header in it. Why is it so ? =
 
Thanx
Vishnu Yadav

********************************DISCLAIMER**********************************

This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege of Deccanet Designs Ltd.
If you have received this message in error, please notify the originator
immediately. If you are not the intended recipient, you are notified that
you are strictly prohibited from retaining, using, copying, altering or
disclosing the contents of this message.

****************************************************************************
------=_NextPart_000_00AB_01C43F35.13FA64D0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 21 04:57:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16409 for ; Fri, 21 May 2004 04:57: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 1BR5c1-0002DG-Gw for sip-archive@odin.ietf.org; Fri, 21 May 2004 04:42:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4L8gfk6008478 for sip-archive@odin.ietf.org; Fri, 21 May 2004 04:42:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR5Rj-0007y5-Bj; Fri, 21 May 2004 04:32:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR5KD-00065H-2K for sip@optimus.ietf.org; Fri, 21 May 2004 04:24: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 EAA14398 for ; Fri, 21 May 2004 04:24:14 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR5KA-0004au-8b for sip@ietf.org; Fri, 21 May 2004 04:24:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR5JB-0004Ro-00 for sip@ietf.org; Fri, 21 May 2004 04:23:14 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BR5IC-0004E1-00 for sip@ietf.org; Fri, 21 May 2004 04:22:15 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4L8LvE05541 for ; Fri, 21 May 2004 11:21:57 +0300 (EET DST) X-Scanned: Fri, 21 May 2004 11:21:51 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i4L8LpcG031765 for ; Fri, 21 May 2004 11:21:51 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00cA9cb1; Fri, 21 May 2004 11:21:50 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4L8LoH27085 for ; Fri, 21 May 2004 11:21:50 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 21 May 2004 11:21:32 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 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] RE: Joint Interim Meeting Mon May 24 - Wed May 26 Date: Fri, 21 May 2004 11:21:31 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797B59@esebe019.ntc.nokia.com> Thread-Topic: Joint Interim Meeting Mon May 24 - Wed May 26 Thread-Index: AcQcABBH+m96wbjLR7CKc21Y58VQWgFJNj1gAAx9IoAHbWm3YA== To: X-OriginalArrivalTime: 21 May 2004 08:21:32.0648 (UTC) FILETIME=[9FCE6E80:01C43F0C] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,BIZ_TLD,NO_REAL_NAME autolearn=no version=2.60 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 You can now find the list of attendees from the following link: http://www.softarmor.com/simple/meets/interim2004/Attendance.html Thanks, Hisham > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext > hisham.khartabil@nokia.com > Sent: 13.April.2004 15:58 > To: sip@ietf.org > Subject: RE: [Sip] RE: Joint Interim Meeting Mon May 24 - Wed May 26 >=20 >=20 > It was pointed out to me that the Group Code for booking was=20 > incorrect. Here is the correct Group Code: NOKNOKA. >=20 > Apologies for the inconvenience. > Hisham >=20 > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext > > hisham.khartabil@nokia.com > > Sent: 13.April.2004 10:00 > > To: rohan@cisco.com; sip@ietf.org > > Cc: dean.willis@softarmor.com; mankin@psg.com; rjsparks@nostrum.com; > > jon.peterson@neustar.biz; hardie@qualcomm.com; > > Gonzalo.Camarillo@ericsson.com; alan.johnston@wcom.com; > > adam@dynamicsoft.com > > Subject: [Sip] RE: Joint Interim Meeting Mon May 24 - Wed May 26 > >=20 > >=20 > > Here is the hotel information: > >=20 > > Renaissance Boston Hotel Bedford > > 44 Middlesex Turnpike Bedford, MA 01730 USA > > Phone: 1 781-275-5500 Fax: 1 781-275-3042 > >=20 > > http://marriott.com/property/propertyPage.mi?marshaCode=3DBOSSB > >=20 > > There are 50 rooms booked for this event at the rate of $99=20 > > per night (from Sunday 23rd until Wednesday 26th). These=20 > > rooms will be held until 3th May, so please reserve your room=20 > > on or before that date. > >=20 > > You can reserve online or by telephone using the Group Code: NONOKA > >=20 > > Also, please use the links that Rohan provided to confirm=20 > > your attendance. This will aid us in determining the catering=20 > > requirements. Here is the link again: > >=20 > > mailto:rohan@cisco.com?Cc=3Dhisham.khartabil@nokia.com&Subject=3D[ > > interim]yes > >=20 > > Thanks, > > Hisham > >=20 > > > -----Original Message----- > > > From: ext Rohan Mahy [mailto:rohan@cisco.com] > > > Sent: 06.April.2004 20:54 > > > To: 'sip@ietf.org' > > > Cc: Dean Willis; Khartabil Hisham (Nokia-TP-MSW/Helsinki); Allison > > > Mankin; Robert Sparks; John Peterson; Ted Hardie; Gonzalo=20 > Camarillo; > > > Rohan Mahy; Alan Johnston; Adam Roach > > > Subject: Joint Interim Meeting Mon May 24 - Wed May 26 > > >=20 > > >=20 > > > Hello All, > > >=20 > > > Please mark your calendars. > > >=20 > > > I'd like to announce a joint interim of the SIP, SIPPING,=20 > > > SIMPLE, and =20 > > > XCON WGs. > > > Nokia has generously agreed to host the event either at their=20 > > > offices =20 > > > near Boston or in a neighboring hotel during the week of May 24. > > >=20 > > > Please reserve the following dates for the WGs that you are=20 > > > interested =20 > > > in: > > > Monday May 24 SIP and SIPPING tentatively 9 am start > > > Tuesday May 25 SIMPLE All day > > > Wednesday May 26 XCON tentatively finish at 4pm so folks=20 > > can catch =20 > > > flights. > > > (the actual agenda is subject to change, including the dates=20 > > > of various =20 > > > WG meetings). > > >=20 > > > There will be no fee, however please let Hisham and myself=20 > > > know if you =20 > > > are planning to attend by clicking on the Yes or Maybe=20 > links below: > > >=20 > > > mailto:rohan@cisco.com?=20 > > > Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim]yes > > > mailto:rohan@cisco.com?=20 > > > Cc=3Dhisham.khartabil@nokia.com&Subject=3D[interim]maybe > > >=20 > > > Wireless will be provided. As usual, I will be making=20 > > > T-shirts. If you =20 > > > are interested in buying one, please send your shirt size to me. > > >=20 > > > More details on the agenda and hotel accommodations will be=20 > > > forthcoming =20 > > > shortly. > > >=20 > > > thanks, > > > -rohan > > >=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 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Fri May 21 04:59:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16563 for ; Fri, 21 May 2004 04:59: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 1BR5lC-0004pL-DU for sip-archive@odin.ietf.org; Fri, 21 May 2004 04:52:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4L8qAH0018549 for sip-archive@odin.ietf.org; Fri, 21 May 2004 04:52:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR5YU-0001DF-Gt; Fri, 21 May 2004 04:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR5QE-0007cd-78 for sip@optimus.ietf.org; Fri, 21 May 2004 04:30: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 EAA14785 for ; Fri, 21 May 2004 04:30:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR5QB-0005Ua-8K for sip@ietf.org; Fri, 21 May 2004 04:30:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR5PG-0005MO-00 for sip@ietf.org; Fri, 21 May 2004 04:29:32 -0400 Received: from mxout3.netvision.net.il ([194.90.9.24]) by ietf-mx with esmtp (Exim 4.12) id 1BR5Ow-0005Dx-00; Fri, 21 May 2004 04:29:10 -0400 Received: from mailvision.com ([212.143.127.193]) by mxout3.netvision.net.il (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0HY200KC227PRH@mxout3.netvision.net.il>; Fri, 21 May 2004 11:28:40 +0300 (IDT) Date: Fri, 21 May 2004 10:28:37 +0200 From: Diego B Subject: Re: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? In-reply-to: <40AD16CA.7050407@dynamicsoft.com> To: Jonathan Rosenberg Cc: "Roy, Radhika R, ALABS" , baruch@kayote.com, sayan.chowdhury@wipro.com, sip@ietf.org, sipping@ietf.org, fluffy@cisco.com Message-id: <40ADBDB5.8030307@mailvision.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: QUOTED-PRINTABLE X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) References: <34DA635B184A644DA4588E260EC0A25A07217374@ACCLUST02EVS1.ugd.att.com> <40AD16CA.7050407@dynamicsoft.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL autolearn=no version=2.60 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; Agreed, but my first question was exactly that, if there is a standar= d=20 way or standard Headers, to store information about a "forward" call. In a normal situation, no one will touch the From header and "normall= y" PSTN gateway copy the user-info from the From SIP-URI to the PSTN "B= =20 number", and this is normally used to create the CDR. I'm not trying to solve the CDR creation issue or how to bill a forwa= rd=20 call, but I'm looking to a standard way to store forward information = so=20 one day this information will be used correctly to create CDRs/billin= g. In a close environment, I can use whatever method to recognize a= =20 forward situation. But SIP is about inter operability and integration= =20 and AFAIK there are some drafts but nothing specific to inform of a c= all=20 forward situation, I don't know the status of Diversion header, but t= his=20 can be a solution if standardized. Thanks Jonathan Rosenberg wrote: > To be clear, Baruch is proposing a new SIP header, which the SIP WG= =20 > would need to worry about. >=20 > I do not think such a thing is needed. As Keith pointed out, our= =20 > philosophy to date (and this is a broader IETF thing too), is to ma= ke=20 > sure that you can *account* for what has happened. That is, that th= e=20 > protocols contain sufficient information to record what transpired = in a=20 > call/transaction/dialog or whatever. Then, its someone elses proble= m=20 > (for example, 3gpp) to specify how the appropriate information is= =20 > collected, what billing model is used, and how a CDR is generated. = Not=20 > to say that these things arent important, they're just not the SIP= =20 > working group's problem. >=20 > -Jonathan R. >=20 > Roy, Radhika R, ALABS wrote: >=20 >> I agree with Baruch that AAA group is working for authentication,= =20 >> authorization, and accounting of applications including SIP, and t= here=20 >> is enough room to build CDRs/Billing based on those things. So, SI= P WG=20 >> does not need to be worried for this. >> =20 >> Radhika R. Roy >> rrroy@att.com >> >> -----Original Message----- >> *From:* sip-admin@ietf.org [mailto:sip-admin@ietf.org]*On Beha= lf Of >> *Baruch Sterman >> *Sent:* Wednesday, May 19, 2004 5:47 AM >> *To:* sayan.chowdhury@wipro.com; diegob@mailvision.com >> *Cc:* sip@ietf.org; sipping@ietf.org; fluffy@cisco.com >> *Subject:* RE: [Sip] SIP Forward, Who pays the bill ? >> >> Another avenue that can be explored is an explicit header to d= eal >> with this and other accounting issues. I think that the AAA gr= oup >> has suggested an ACCOUNTING header. We were thinking of a BILL= ING >> header. In that header you would have a username and type. So = as the >> call progresses you could add to that header. This would also = allow >> to charge for various services along the way. Imagine the foll= owing. >> Alice calls Bob, Bob forwards to Charlie who requires an ENUM = lookup >> to find his IP =E2=80=93 and you are dealing with a psychotic = ITSP that >> **Charges** for ENUM listing. >> >> Inbound Alice -> Bob Billing: Alice, inbound >> >> Forward Bob -> Charlie Billing: Alice, inbound; Bob, outb= ound >> >> ITSP looks up Charlie Billing: Alice, inbound; Bob, out= bound; >> Charlie, serviceX >> >> =20 >> So when the CDR gets written, the rating engine looks through = the >> Billing header and applies all the relevant charges to the rel= evant >> accounts. Some may be per minute, some may be fixed charges. >> >> =20 >> The problems are first and foremost, security. No one can add = to the >> billing header unless they are trusted entities within your sy= stem, >> because money will be charged based on the information there. >> Second, care has to be taken to strip off the header when it l= eaves >> the trusted domain =E2=80=93 out to the UA=E2=80=99s for examp= le. You don=E2=80=99t want >> people knowing what is going on in your billing system. >> >> =20 >> But the idea here is very flexible and can take into account m= any >> things that we aren=E2=80=99t thinking about now. For example,= we may charge >> differently one day calls that require NAT treatment on the RT= P >> level (where the bandwidth cost to the hosting ITSP is not >> negligible). When you find that to be the case, just add it to= the >> Billing header. What about if calls are forwarded multiple tim= es? >> Keep adding each leg to the billing header. >> >> =20 >> What does everyone think about this? >> >> =20 >> Baruch >> >> =20 >> -----Original Message----- >> *From:* sip-admin@ietf.org [mailto:sip-admin@ietf.org] *On Beh= alf Of >> *sayan.chowdhury@wipro.com >> *Sent:* Wednesday, May 19, 2004 1:00 AM >> *To:* diegob@mailvision.com; baruch@kayote.com >> *Cc:* sip@ietf.org; sipping@ietf.org; fluffy@cisco.com >> *Subject:* RE: [Sip] SIP Forward, Who pays the bill ? >> >> =20 >> Also , Alice might be sending the re-invite to on receipt of a= 302 >> from Bob. So the set of proxies invloved in the first leg of t= he >> call may not be involved in the second ? >> >> Solutuion to this will be on the PSTN gateway side. >> >> The PSTN gateway should look for and bill from Diversion/Reque= st >> History/remote Part Header information in preference to the fr= om >> header which is unreliable any way. >> >> However , I do not know of any standards which explicitly ment= ions >> that .. >> >> =20 >> Regards , >> >> Sayan >> >> =20 >> -----Original Message----- >> *From:* sip-admin@ietf.org on behalf of Diego B >> *Sent:* Tue 5/18/2004 7:44 PM >> *To:* baruch@kayote.com >> *Cc:* sip@ietf.org; 'sipping'; 'Cullen Jennings' >> *Subject:* Re: [Sip] SIP Forward, Who pays the bill ? >> >> Hi Baruch; >> Thanks for your answer. >> I belive that you are implementing a proprietary solution = to >> deal with it. >> I'm looking more to a standarize way to deal with the seco= nd-leg >> issue. >> >> I'm agree that Alice has to pay for the first leg and Bob = for the >> second, but if the Proxy that is doing the forward is not = a=20 >> biling >> entity ( local calls are free, outbound call are not free = and >> billed by >> an external real-time billing system connected to the GW u= sing >> RADIUS or >> similar), the PSTN gateway will have to know that this cal= l=20 >> may be >> billed to Bob and not to Alice ( she apears in the From he= ader ). >> >> Thanks >> >> Baruch Sterman wrote: >> >>> In the systems that we implemented, two cdrs are created: the >> >> first for >> >>> the incoming leg (Alice to Bob's non-forwarded location) and a >> >> second >> >>> for the forward to Bob's forwarded location. >>> >>> Alice would pay for the first leg, and Bob pays for the second. >>> >>> Furthermore, it may be the case that Bob pays for the first >> >> leg as well. >> >>> If, for example, Bob has a toll free number where he pays per >> >> minute >> >>> charges for the inbound leg (in this case, Alice is on the PSTN)= . >>> >>> Either way, multiple CDRs is the way we came up with to handle >> >> this. >> >>> Care has to be taken that the key to any CDR database is NOT the >>> call-ID, because this is the same across the two CDRs. >>> >>> Baruch >>> >>> -----Original Message----- >>> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf >> >> Of Diego >> >>> B >>> Sent: Tuesday, May 18, 2004 7:42 AM >>> To: sip@ietf.org; sipping >>> Cc: Cullen Jennings >>> Subject: [Sip] SIP Forward, Who pays the bill ? >>> >>> Hi; >>> My question is regarding billing a forwarded sip call. >>> >>> Lets take the exmple from draft-ietf-sipping-service-examples >>> 2.7 >>> >>> Alice calls Bob, and Bob has all his incomming calls forwarded >> >> to the >> >>> PSTN. >>> >>> Let say that calls from ALice to Bob in the same domain are >> >> free (same >> >>> office, or same ITSP), but calls to the PSTN are not free. >>> >>> Who pays for Alice call to Bob ?? >>> In a normal situacion, Alice knows that the call is for free >> >> becuase she >> >>> >>> is calling Bob's sip number. But the gateweay may create CDR >> >> from the >> >>> From header of the SIP message and at the end of the month >> >> Alice may >> >>> have to pay for the call. >>> >>> I see this kind of examples in several other drafts/RFC >> >> related to SIP >> >>> services and call forward. >>> >>> I belive forward is a very important feature, but this issue >> >> may be >> >>> resolved. The question is if it is a standard way to make Bob >> >> pays for >> >>> the second leg of the call like in PSTN forward. >>> >>> Maybe changing the From header where applicable and adding a >> >> new one to >> >>> "remember" that the call is from, in my example, Alice. >>> >>> The diversion header (Diversion Indication in SIP >>> draft-levy-sip-diversion-07.txt)" may be a solution if the >> >> PSTN gateway >> >>> or the SIP Billing server support it and knows that they have >> >> to bill >> >>> the sip-uri in the diversion header ( this is right ??? ). >>> >>> Regards; >>> >>> >>> >>> >>> >> >> -- >> Diego B >> MailVision Ltd. >> Tel. : =EF=9E=BD4-8500505 ext 13 >> e-mail: diegob@mailvision.com >> web : http://www.mailvision.com >> >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/s= ip >> =20 >> =20 >> >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on curr= ent sip >> Use sipping@ietf.org for new developments on the applicati= on=20 >> of sip >> >=20 --=20 Diego B MailVision Ltd. Tel. : +972-4-8500505 ext 13 e-mail: diegob@mailvision.com web : http://www.mailvision.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 Fri May 21 05:36:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18732 for ; Fri, 21 May 2004 05:36: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 1BR6FX-00059a-92 for sip-archive@odin.ietf.org; Fri, 21 May 2004 05:23:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4L9NS6f019734 for sip-archive@odin.ietf.org; Fri, 21 May 2004 05:23:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR66M-0002jk-Ob; Fri, 21 May 2004 05:14:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR5t8-0007Qi-JS for sip@optimus.ietf.org; Fri, 21 May 2004 05:00: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 FAA16602 for ; Fri, 21 May 2004 05:00:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR5t5-0002R4-Aj for sip@ietf.org; Fri, 21 May 2004 05:00:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR5s6-0002FC-00 for sip@ietf.org; Fri, 21 May 2004 04:59:19 -0400 Received: from vivo190.gprs.suomen2g.fi ([62.78.127.190] helo=localhost) by ietf-mx with esmtp (Exim 4.12) id 1BR5r9-0001x2-00; Fri, 21 May 2004 04:58:20 -0400 Received: from jh by localhost with local (Exim 3.35 #1 (Debian)) id 1BR5oI-0000OE-00; Fri, 21 May 2004 11:55:22 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16557.50170.649315.622928@tutpro.com> Date: Fri, 21 May 2004 11:55:22 +0300 To: Diego B Cc: Jonathan Rosenberg , "Roy, Radhika R, ALABS" , baruch@kayote.com, sayan.chowdhury@wipro.com, sip@ietf.org, sipping@ietf.org, fluffy@cisco.com Subject: Re: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? In-Reply-To: <40ADBDB5.8030307@mailvision.com> References: <34DA635B184A644DA4588E260EC0A25A07217374@ACCLUST02EVS1.ugd.att.com> <40AD16CA.7050407@dynamicsoft.com> <40ADBDB5.8030307@mailvision.com> X-Mailer: VM 7.17 under Emacs 21.2.1 From: Juha Heinanen X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Diego B writes: > In a close environment, I can use whatever method to recognize a > forward situation. But SIP is about inter operability and integration > and AFAIK there are some drafts but nothing specific to inform of a call > forward situation, I don't know the status of Diversion header, but this > can be a solution if standardized. both rpid and diversion headers have become de-facto industry ways to achieve that you want. may be one day some ietf standardized way to do the same becomes widely implemented, at which point you can support this new thing too. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Fri May 21 05:56:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19898 for ; Fri, 21 May 2004 05: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 1BR6Zd-0002tI-Sw for sip-archive@odin.ietf.org; Fri, 21 May 2004 05:44:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4L9iG2b011061 for sip-archive@odin.ietf.org; Fri, 21 May 2004 05:44:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR6Sq-0000gp-Ja; Fri, 21 May 2004 05:37:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR6IR-0005tL-O7 for sip@optimus.ietf.org; Fri, 21 May 2004 05:26:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18150 for ; Fri, 21 May 2004 05:26:27 -0400 (EDT) From: ranjit.avasarala@wipro.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR6IO-0006QD-8G for sip@ietf.org; Fri, 21 May 2004 05:26:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR6HW-0006HX-00 for sip@ietf.org; Fri, 21 May 2004 05:25:35 -0400 Received: from wiproecmx2.wipro.com ([164.164.31.6]) by ietf-mx with esmtp (Exim 4.12) id 1BR6Gk-00060H-00 for sip@ietf.org; Fri, 21 May 2004 05:24:47 -0400 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx2.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i4L9OCTu028582 for ; Fri, 21 May 2004 14:54:13 +0530 (IST) Received: from blr-ec-bh1.wipro.com ([10.200.50.91]) by ec-vwall-wd with InterScan Messaging Security Suite; Fri, 21 May 2004 14:54:12 +0530 Received: from blr-ec-msg03.wipro.com ([10.200.52.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 21 May 2004 14:54:11 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43F15.60497C35" Subject: RE: [Sip] 2XX, in resonse to MESSAGE; MUST NOT contain Contact header fld, WHY ? Date: Fri, 21 May 2004 14:54:11 +0530 Message-ID: Thread-Topic: [Sip] 2XX, in resonse to MESSAGE; MUST NOT contain Contact header fld, WHY ? Thread-Index: AcQ/CdV4OEQydqURTFyYcKYnjCokbAACtdFw To: , X-OriginalArrivalTime: 21 May 2004 09:24:11.0702 (UTC) FILETIME=[60608D60:01C43F15] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,EXCUSE_16,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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_01C43F15.60497C35 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi I feel since the 200 OK for the MESSAGE does not indicate that the message is actually read, there is no need for the receipient to insert Contact header in 200 OK. so since MESSAGE does not establish any dialog, there is no chat like scenrio where the sender again sends message.=20 =20 Any comments ? =20 Regards=20 Ranjit=20 -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Vishnu Yadav Sent: Friday, May 21, 2004 1:11 PM To: sip@ietf.org Subject: [Sip] 2XX, in resonse to MESSAGE; MUST NOT contain Contact header fld, WHY ? 2xx, sent by UAS in response to MESSAGE request must not contain Contact header in it. Why is it so ?=20 =20 Thanx Vishnu Yadav ********************************DISCLAIMER****************************** **** This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege of Deccanet Designs Ltd. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from retaining, using, copying, altering or disclosing the contents of this message. ************************************************************************ **** ------_=_NextPart_001_01C43F15.60497C35 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi
    I feel since the 200 OK for the MESSAGE does = not=20 indicate that the message is actually read, there is no need for the = receipient=20 to insert Contact header in 200 OK.
so=20 since MESSAGE does not establish any dialog, there is no chat like = scenrio where=20 the sender again sends message.
 
Any comments ?
 
Regards
Ranjit
-----Original Message-----
From:=20 sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of = Vishnu=20 Yadav
Sent: Friday, May 21, 2004 1:11 PM
To:=20 sip@ietf.org
Subject: [Sip] 2XX, in resonse to MESSAGE; MUST = NOT=20 contain Contact header fld, WHY ?

2xx, sent by UAS in response = to MESSAGE=20 request must not contain Contact header in it. Why is it so ? =
 
Thanx
Vishnu Yadav
********************************DISCLAIMER*******************************=
***

This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege of Deccanet Designs =
Ltd.
If you have received this message in error, please notify the originator
immediately. If you are not the intended recipient, you are notified =
that
you are strictly prohibited from retaining, using, copying, altering or
disclosing the contents of this message.

*************************************************************************=
***
------_=_NextPart_001_01C43F15.60497C35-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 21 06:22:30 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21740 for ; Fri, 21 May 2004 06:22: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 1BR72E-0002Ih-9W for sip-archive@odin.ietf.org; Fri, 21 May 2004 06:13:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LADo1E008833 for sip-archive@odin.ietf.org; Fri, 21 May 2004 06:13:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR6ro-0006rJ-OO; Fri, 21 May 2004 06:03:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR6mJ-0005M6-6r for sip@optimus.ietf.org; Fri, 21 May 2004 05:57:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19946 for ; Fri, 21 May 2004 05:57:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR6mF-0003KA-IB for sip@ietf.org; Fri, 21 May 2004 05:57:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR6lK-0003Bu-00 for sip@ietf.org; Fri, 21 May 2004 05:56:22 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BR6kZ-00033D-00 for sip@ietf.org; Fri, 21 May 2004 05:55:35 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4L9ssS08424; Fri, 21 May 2004 12:54:54 +0300 (EET DST) X-Scanned: Fri, 21 May 2004 12:54:45 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i4L9sji0026207; Fri, 21 May 2004 12:54:45 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00etQXa8; Fri, 21 May 2004 12:54:43 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4L9shH13880; Fri, 21 May 2004 12:54:43 +0300 (EET DST) Received: from [172.21.81.135] ([172.21.81.135]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 21 May 2004 12:54:33 +0300 Message-ID: <40ADD1D9.5090701@nokia.com> Date: Fri, 21 May 2004 12:54:33 +0300 From: Aki Niemi Organization: Nokia-M/Espoo User-Agent: Mozilla Thunderbird 0.6 (X11/20040502) X-Accept-Language: en MIME-Version: 1.0 To: "ext ranjit.avasarala@wipro.com" CC: vishnuyadav@deccanetworld.com, sip@ietf.org Subject: Re: [Sip] 2XX, in resonse to MESSAGE; MUST NOT contain Contact header fld, WHY ? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 May 2004 09:54:33.0712 (UTC) FILETIME=[9E613700:01C43F19] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,EXCUSE_16 autolearn=no version=2.60 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, ext ranjit.avasarala@wipro.com wrote: > Hi > I feel since the 200 OK for the MESSAGE does not indicate that the > message is actually read, there is no need for the receipient to insert > Contact header in 200 OK. I don't see what these things have to do with each other... > so since MESSAGE does not establish any dialog, there is no chat like > scenrio where the sender again sends message. This is pretty much the reason for the restriction. As you say, the MESSAGE method does not establish a dialog, or any pseudo-session for that matter. MESSAGEs are always sent to the AoR, and the MUST NOT is there to discourage anyone even trying to do messaging sessions using the MESSAGE method and Contact addresses. draft-ietf-message-sessions-06 describes the right way to do message sessions. Cheers, Aki > > Any comments ? > > Regards > Ranjit > > -----Original Message----- > *From:* sip-admin@ietf.org [mailto:sip-admin@ietf.org] *On Behalf Of > *Vishnu Yadav > *Sent:* Friday, May 21, 2004 1:11 PM > *To:* sip@ietf.org > *Subject:* [Sip] 2XX, in resonse to MESSAGE; MUST NOT contain > Contact header fld, WHY ? > > 2xx, sent by UAS in response to MESSAGE request must not contain > Contact header in it. Why is it so ? > > Thanx > Vishnu Yadav > > ********************************DISCLAIMER********************************** > > This e-mail and any attachment is for authorised use by the intended > recipient(s) only. It may contain proprietary material, confidential > information and/or be subject to legal privilege of Deccanet Designs Ltd. > If you have received this message in error, please notify the originator > immediately. If you are not the intended recipient, you are notified that > you are strictly prohibited from retaining, using, copying, altering or > disclosing the contents of 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 Fri May 21 08:46:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27944 for ; Fri, 21 May 2004 08:46: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 1BR9DL-000138-Gh for sip-archive@odin.ietf.org; Fri, 21 May 2004 08:33:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LCXRZL004035 for sip-archive@odin.ietf.org; Fri, 21 May 2004 08:33:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR94E-0007V1-8i; Fri, 21 May 2004 08:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR7u6-0000Bo-PW for sip@optimus.ietf.org; Fri, 21 May 2004 07:09: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 HAA24108 for ; Fri, 21 May 2004 07:09:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR7u2-0000lP-9u for sip@ietf.org; Fri, 21 May 2004 07:09:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR7t2-0000ay-00 for sip@ietf.org; Fri, 21 May 2004 07:08:25 -0400 Received: from ckmso2.att.com ([209.219.209.75] helo=ckmso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1BR7s6-0000HN-00; Fri, 21 May 2004 07:07:26 -0400 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i4LB5r47014070; Fri, 21 May 2004 07:06:58 -0400 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.13) by attrh5i.attrh.att.com (6.5.032) id 40A791690013C64A; Fri, 21 May 2004 07:06:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6561.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? Date: Fri, 21 May 2004 06:06:40 -0500 Message-ID: <28F05913385EAC43AF019413F674A01708145CA4@OCCLUST04EVS1.ugd.att.com> Thread-Topic: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? Thread-Index: AcQ/ELfgjhrsEC3hQJqIimMvFw1S/gAEn9iw From: "Dolly, Martin C, ALABS" To: "Diego B" , "Jonathan Rosenberg" Cc: "Roy, Radhika R, ALABS" , , , , , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 QSBtZWNoYW5pc20gZm9yIHJlbGF5aW5nIGNhbGwgZm9yd2FyZGluZyBpbmZvcm1hdGlvbiBpcyBu ZWVkZWQsIGFuZCBJIGFncmVlIHRoYXQgdGhlIGRpdmVyc2lvbiBkcmFmdCBpcyBhIHZpYWJsZSBz b2x1dGlvbi4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNpcC1hZG1pbkBp ZXRmLm9yZyBbbWFpbHRvOnNpcC1hZG1pbkBpZXRmLm9yZ11PbiBCZWhhbGYgT2YgRGllZ28gQg0K U2VudDogRnJpZGF5LCBNYXkgMjEsIDIwMDQgNDoyOSBBTQ0KVG86IEpvbmF0aGFuIFJvc2VuYmVy Zw0KQ2M6IFJveSwgUmFkaGlrYSBSLCBBTEFCUzsgYmFydWNoQGtheW90ZS5jb207IHNheWFuLmNo b3dkaHVyeUB3aXByby5jb207DQpzaXBAaWV0Zi5vcmc7IHNpcHBpbmdAaWV0Zi5vcmc7IGZsdWZm eUBjaXNjby5jb20NClN1YmplY3Q6IFJlOiBbU2lwcGluZ10gUkU6IFtTaXBdIFNJUCBGb3J3YXJk LCBXaG8gcGF5cyB0aGUgYmlsbCA/DQoNCg0KSGk7DQoNCkFncmVlZCwgYnV0IG15IGZpcnN0IHF1 ZXN0aW9uIHdhcyBleGFjdGx5IHRoYXQsIGlmIHRoZXJlIGlzIGEgc3RhbmRhcmQgDQp3YXkgb3Ig c3RhbmRhcmQgSGVhZGVycywgdG8gc3RvcmUgaW5mb3JtYXRpb24gYWJvdXQgYSAiZm9yd2FyZCIg Y2FsbC4NCg0KSW4gYSBub3JtYWwgc2l0dWF0aW9uLCBubyBvbmUgd2lsbCB0b3VjaCB0aGUgRnJv bSBoZWFkZXIgYW5kICJub3JtYWxseSINClBTVE4gZ2F0ZXdheSBjb3B5IHRoZSB1c2VyLWluZm8g ZnJvbSB0aGUgRnJvbSBTSVAtVVJJIHRvIHRoZSBQU1ROICJCIA0KbnVtYmVyIiwgYW5kIHRoaXMg aXMgbm9ybWFsbHkgdXNlZCB0byBjcmVhdGUgdGhlIENEUi4NCg0KSSdtIG5vdCB0cnlpbmcgdG8g c29sdmUgdGhlIENEUiBjcmVhdGlvbiBpc3N1ZSBvciBob3cgdG8gYmlsbCBhIGZvcndhcmQgDQpj YWxsLCBidXQgSSdtIGxvb2tpbmcgdG8gYSBzdGFuZGFyZCB3YXkgdG8gc3RvcmUgZm9yd2FyZCBp bmZvcm1hdGlvbiBzbyANCm9uZSBkYXkgdGhpcyBpbmZvcm1hdGlvbiB3aWxsIGJlIHVzZWQgY29y cmVjdGx5IHRvIGNyZWF0ZSBDRFJzL2JpbGxpbmcuDQoNCkluIGEgY2xvc2UgZW52aXJvbm1lbnQs IEkgY2FuIHVzZSB3aGF0ZXZlciBtZXRob2QgdG8gIHJlY29nbml6ZSBhIA0KZm9yd2FyZCBzaXR1 YXRpb24uIEJ1dCBTSVAgaXMgYWJvdXQgaW50ZXIgb3BlcmFiaWxpdHkgYW5kIGludGVncmF0aW9u IA0KYW5kIEFGQUlLIHRoZXJlIGFyZSBzb21lIGRyYWZ0cyBidXQgbm90aGluZyBzcGVjaWZpYyB0 byBpbmZvcm0gb2YgYSBjYWxsIA0KZm9yd2FyZCBzaXR1YXRpb24sIEkgZG9uJ3Qga25vdyB0aGUg c3RhdHVzIG9mIERpdmVyc2lvbiBoZWFkZXIsIGJ1dCB0aGlzIA0KY2FuIGJlIGEgc29sdXRpb24g aWYgc3RhbmRhcmRpemVkLg0KDQpUaGFua3MNCg0KSm9uYXRoYW4gUm9zZW5iZXJnIHdyb3RlOg0K PiBUbyBiZSBjbGVhciwgQmFydWNoIGlzIHByb3Bvc2luZyBhIG5ldyBTSVAgaGVhZGVyLCB3aGlj aCB0aGUgU0lQIFdHIA0KPiB3b3VsZCBuZWVkIHRvIHdvcnJ5IGFib3V0Lg0KPiANCj4gSSBkbyBu b3QgdGhpbmsgc3VjaCBhIHRoaW5nIGlzIG5lZWRlZC4gQXMgS2VpdGggcG9pbnRlZCBvdXQsIG91 ciANCj4gcGhpbG9zb3BoeSB0byBkYXRlIChhbmQgdGhpcyBpcyBhIGJyb2FkZXIgSUVURiB0aGlu ZyB0b28pLCBpcyB0byBtYWtlIA0KPiBzdXJlIHRoYXQgeW91IGNhbiAqYWNjb3VudCogZm9yIHdo YXQgaGFzIGhhcHBlbmVkLiBUaGF0IGlzLCB0aGF0IHRoZSANCj4gcHJvdG9jb2xzIGNvbnRhaW4g c3VmZmljaWVudCBpbmZvcm1hdGlvbiB0byByZWNvcmQgd2hhdCB0cmFuc3BpcmVkIGluIGEgDQo+ IGNhbGwvdHJhbnNhY3Rpb24vZGlhbG9nIG9yIHdoYXRldmVyLiBUaGVuLCBpdHMgc29tZW9uZSBl bHNlcyBwcm9ibGVtIA0KPiAoZm9yIGV4YW1wbGUsIDNncHApIHRvIHNwZWNpZnkgaG93IHRoZSBh cHByb3ByaWF0ZSBpbmZvcm1hdGlvbiBpcyANCj4gY29sbGVjdGVkLCB3aGF0IGJpbGxpbmcgbW9k ZWwgaXMgdXNlZCwgYW5kIGhvdyBhIENEUiBpcyBnZW5lcmF0ZWQuIE5vdCANCj4gdG8gc2F5IHRo YXQgdGhlc2UgdGhpbmdzIGFyZW50IGltcG9ydGFudCwgdGhleSdyZSBqdXN0IG5vdCB0aGUgU0lQ IA0KPiB3b3JraW5nIGdyb3VwJ3MgcHJvYmxlbS4NCj4gDQo+IC1Kb25hdGhhbiBSLg0KPiANCg== _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 21 11:45:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09923 for ; Fri, 21 May 2004 11:45: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 1BRBwm-0002Aj-Js for sip-archive@odin.ietf.org; Fri, 21 May 2004 11:28:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LFSWqK008349 for sip-archive@odin.ietf.org; Fri, 21 May 2004 11:28:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRBrS-0000Ev-Fv; Fri, 21 May 2004 11:23:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRBdY-0005hn-W8 for sip@optimus.ietf.org; Fri, 21 May 2004 11:08: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 LAA07735 for ; Fri, 21 May 2004 11:08:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRBdW-0002he-7E for sip@ietf.org; Fri, 21 May 2004 11:08:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRBcY-0002Uu-00 for sip@ietf.org; Fri, 21 May 2004 11:07:39 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1BRBbd-00024q-00; Fri, 21 May 2004 11:06:41 -0400 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.10/8.12.6) with ESMTP id i4LF66fS028734; Fri, 21 May 2004 08:06:07 -0700 (PDT) Received: from [10.0.1.3] (sjc-vpn4-1193.cisco.com [10.21.84.168]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id APD60862; Fri, 21 May 2004 08:06:05 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Fri, 21 May 2004 08:06:03 -0700 Subject: Re: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? From: Cullen Jennings To: "Dolly, Martin C, ALABS" , Diego B , Jonathan Rosenberg CC: "Roy, Radhika R, ALABS" , , , , Message-ID: In-Reply-To: <28F05913385EAC43AF019413F674A01708145CA4@OCCLUST04EVS1.ugd.att.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 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 topic of what mechanism you use to know about this forwarding information has been a long topic with much discussion. Right now, the WG has selected the history mechanism (which grew out of the diversion work) work as a WG item. The RPID work has become RFC 3325. Given the long history of this, I highly recommend that if you think there is a reason that history will not meet your needs, get that out very soon so that the history work can be modified. I would be amazingly surprised to see diversion standardized. Cullen On 5/21/04 4:06 AM, "Dolly, Martin C, ALABS" wrote: > A mechanism for relaying call forwarding information is needed, and I agree > that the diversion draft is a viable solution. > > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Diego B > Sent: Friday, May 21, 2004 4:29 AM > To: Jonathan Rosenberg > Cc: Roy, Radhika R, ALABS; baruch@kayote.com; sayan.chowdhury@wipro.com; > sip@ietf.org; sipping@ietf.org; fluffy@cisco.com > Subject: Re: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? > > > Hi; > > Agreed, but my first question was exactly that, if there is a standard > way or standard Headers, to store information about a "forward" call. > > In a normal situation, no one will touch the From header and "normally" > PSTN gateway copy the user-info from the From SIP-URI to the PSTN "B > number", and this is normally used to create the CDR. > > I'm not trying to solve the CDR creation issue or how to bill a forward > call, but I'm looking to a standard way to store forward information so > one day this information will be used correctly to create CDRs/billing. > > In a close environment, I can use whatever method to recognize a > forward situation. But SIP is about inter operability and integration > and AFAIK there are some drafts but nothing specific to inform of a call > forward situation, I don't know the status of Diversion header, but this > can be a solution if standardized. > > Thanks > > Jonathan Rosenberg wrote: >> To be clear, Baruch is proposing a new SIP header, which the SIP WG >> would need to worry about. >> >> I do not think such a thing is needed. As Keith pointed out, our >> philosophy to date (and this is a broader IETF thing too), is to make >> sure that you can *account* for what has happened. That is, that the >> protocols contain sufficient information to record what transpired in a >> call/transaction/dialog or whatever. Then, its someone elses problem >> (for example, 3gpp) to specify how the appropriate information is >> collected, what billing model is used, and how a CDR is generated. Not >> to say that these things arent important, they're just not the SIP >> working group's problem. >> >> -Jonathan R. >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Sat May 22 08:10:04 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02733 for ; Sat, 22 May 2004 08:10:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRV8z-0005A6-Qr for sip-archive@odin.ietf.org; Sat, 22 May 2004 07:58:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4MBwPkJ019843 for sip-archive@odin.ietf.org; Sat, 22 May 2004 07:58:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRV2o-0003ua-Cs; Sat, 22 May 2004 07:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRUxC-00037H-Hp for sip@optimus.ietf.org; Sat, 22 May 2004 07:46: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 HAA01327 for ; Sat, 22 May 2004 07:46:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRUxB-0003jw-DH for sip@ietf.org; Sat, 22 May 2004 07:46:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRUwC-0003YG-00 for sip@ietf.org; Sat, 22 May 2004 07:45:13 -0400 Received: from mail.deccanetworld.com ([203.196.146.50] helo=gatekeeper.deccanetworld.com) by ietf-mx with esmtp (Exim 4.12) id 1BRUvE-0003Fq-00; Sat, 22 May 2004 07:44:14 -0400 Received: from gatekeeper.deccanetworld.com (localhost [127.0.0.1]) by gatekeeper.deccanetworld.com (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id i4MBWmn1019846; Sat, 22 May 2004 17:02:48 +0530 Received: from mail.deccanetworld.com (server.deccanetworld.com [192.168.1.32]) by gatekeeper.deccanetworld.com (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id i4MBWl6i019609; Sat, 22 May 2004 17:02:47 +0530 Received: (from root@localhost) by mail.deccanetworld.com (8.11.0/8.11.0) id i4MBsnV13436; Sat, 22 May 2004 17:24:49 +0530 Received: from gvvivek (bharathi.software [192.168.1.224] (may be forged)) by mail.deccanetworld.com (8.11.0/8.11.0) with SMTP id i4MBsnr13394; Sat, 22 May 2004 17:24:49 +0530 Message-ID: <00c801c43ff1$b5233c30$e001a8c0@gvvivek> From: "Vishnu Yadav" To: Cc: Date: Sat, 22 May 2004 17:11:23 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C5_01C4401F.CED44C40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,EXCUSE_16,HTML_20_30, HTML_MESSAGE autolearn=no version=2.60 Subject: [Sip] can any1 send me some docs or references on Instant Mssging on SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_00C5_01C4401F.CED44C40 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable HI can any one send me some docs or refrnces on Instant Mssging on SIP this should be using MSRP , that is session-mode IM not the page mode Thanx ********************************DISCLAIMER********************************** This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege of Deccanet Designs Ltd. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from retaining, using, copying, altering or disclosing the contents of this message. **************************************************************************** ------=_NextPart_000_00C5_01C4401F.CED44C40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 HI
can any one send me=20 some docs or refrnces on Instant Mssging on SIP

this should be using MSRP , that = is=20 session-mode IM not the page mode

Thanx

 

********************************DISCLAIMER**********************************

This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege of Deccanet Designs Ltd.
If you have received this message in error, please notify the originator
immediately. If you are not the intended recipient, you are notified that
you are strictly prohibited from retaining, using, copying, altering or
disclosing the contents of this message.

****************************************************************************
------=_NextPart_000_00C5_01C4401F.CED44C40-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 Sat May 22 16:34:12 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25502 for ; Sat, 22 May 2004 16:34:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRdAZ-0003rE-MQ for sip-archive@odin.ietf.org; Sat, 22 May 2004 16:32:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4MKWZrT014828 for sip-archive@odin.ietf.org; Sat, 22 May 2004 16:32:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRczR-0001FV-F8; Sat, 22 May 2004 16:21:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRcvL-0000aq-Cw for sip@optimus.ietf.org; Sat, 22 May 2004 16:16:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24999 for ; Sat, 22 May 2004 16:16:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRcvJ-0004Tc-O4 for sip@ietf.org; Sat, 22 May 2004 16:16:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRcuN-0004HC-00 for sip@ietf.org; Sat, 22 May 2004 16:15:52 -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 1BRctE-0003ss-00 for sip@ietf.org; Sat, 22 May 2004 16:14:41 -0400 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.10/8.12.6) with ESMTP id i4MKE4f9000028; Sat, 22 May 2004 13:14:04 -0700 (PDT) Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ATK62489; Sat, 22 May 2004 13:13:17 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v613) To: "'sip@ietf.org'" Message-Id: Content-Type: multipart/alternative; boundary=Apple-Mail-15--424362643 Cc: Rohan Mahy From: Rohan Mahy Date: Sat, 22 May 2004 13:16:59 -0700 X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,BIZ_TLD,HTML_MESSAGE autolearn=no version=2.60 Subject: [Sip] Fwd: SIMPLE/SIP/SIPPING/XCON Working Groups Joint Interim Meeting Announcement Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --Apple-Mail-15--424362643 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit FYI: A lot of folks didn't see this. thx, -r Begin forwarded message: > From: > Date: April 21, 2004 11:29:18 PM PDT > To: > Cc: , , > , , > , , , > , > Subject: SIMPLE/SIP/SIPPING/XCON Working Groups Joint Interim Meeting > Announcement > > An joint interim meeting for the SIMPLE, SIP, SIPPING and XCON working > groups will be help from Monday 24th May until Wednesday 26th May in > Boston, Massachusetts. > > Location: > Renaissance Boston Hotel Bedford > 44 Middlesex Turnpike Bedford, MA 01730 USA > Phone: 1 781-275-5500 Fax: 1 781-275-3042 > > http://marriott.com/property/propertyPage.mi?marshaCode=BOSSB > > Agenda: > > MONDAY - SIMPLE > > 9:00-12:00 - MSRP/MSRP Relays > 12:00-13:00 - Lunch > 13:00-16:00 - XCAP > 16:00-16:30 - Filtering > 16:30-17:00 - Partial Publish > 17:00-17:30 - Advanced Messaging > > TUESDAY - SIP/SIPPING > > 9:00-10:30 - KPML > 10:30-11:00 - GRUU > 11:00-12:00 - Session Policies > 12:00-13:00 - Lunch > 13:00-14:30 - Session Policies Cont. > 14:30-15:30 - Exploders > time permitting: > 15:30-16:15 - Connected Party > 16:15-17:00 - Application Interaction > 17:00-17:30 - Dialog Package > 17:30-18:00 - Connection Re-use > > WEDNESDAY - XCON > > 9:00-11:00 - Floor Control > 11:00-12:00 - CPCP > 12:00-13:00 - Lunch > 13:00-14:00 - CPCP Cont. > 14:00-16:00 - MPCP > > The chairs would like to thank Nokia for sponsoring the event. --Apple-Mail-15--424362643 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit FYI: A lot of folks didn't see this. thx, -r Begin forwarded message: Helvetica0000,0000,0000From: Helvetica< 0000,0000,0000Date: April 21, 2004 11:29:18 PM PDT 0000,0000,0000To: < 0000,0000,0000Cc: <, <, <, <, <, <, <, <, < 0000,0000,0000Subject: SIMPLE/SIP/SIPPING/XCON Working Groups Joint Interim Meeting Announcement An joint interim meeting for the SIMPLE, SIP, SIPPING and XCON working groups will be help from Monday 24th May until Wednesday 26th May in Boston, Massachusetts. Location: Renaissance Boston Hotel Bedford 44 Middlesex Turnpike Bedford, MA 01730 USA Phone: 1 781-275-5500 Fax: 1 781-275-3042 http://marriott.com/property/propertyPage.mi?marshaCode=BOSSB Agenda: MONDAY - SIMPLE 9:00-12:00 - MSRP/MSRP Relays 12:00-13:00 - Lunch 13:00-16:00 - XCAP 16:00-16:30 - Filtering 16:30-17:00 - Partial Publish 17:00-17:30 - Advanced Messaging TUESDAY - SIP/SIPPING 9:00-10:30 - KPML 10:30-11:00 - GRUU 11:00-12:00 - Session Policies 12:00-13:00 - Lunch 13:00-14:30 - Session Policies Cont. 14:30-15:30 - Exploders time permitting: 15:30-16:15 - Connected Party 16:15-17:00 - Application Interaction 17:00-17:30 - Dialog Package 17:30-18:00 - Connection Re-use WEDNESDAY - XCON 9:00-11:00 - Floor Control 11:00-12:00 - CPCP 12:00-13:00 - Lunch 13:00-14:00 - CPCP Cont. 14:00-16:00 - MPCP The chairs would like to thank Nokia for sponsoring the event. --Apple-Mail-15--424362643-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 24 06:24:51 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24687 for ; Mon, 24 May 2004 06:24: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 1BSCRm-00062z-JY for sip-archive@odin.ietf.org; Mon, 24 May 2004 06:12:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OACgs0023246 for sip-archive@odin.ietf.org; Mon, 24 May 2004 06:12:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSCEb-0003mn-2e; Mon, 24 May 2004 05:59:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSC90-0002vi-DY for sip@optimus.ietf.org; Mon, 24 May 2004 05:53: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 FAA23267 for ; Mon, 24 May 2004 05:53:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSC8w-0000E2-Np for sip@ietf.org; Mon, 24 May 2004 05:53:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSC80-0007jb-00 for sip@ietf.org; Mon, 24 May 2004 05:52:17 -0400 Received: from usjk1002.kddi.com ([211.4.169.18]) by ietf-mx with esmtp (Exim 4.12) id 1BSC7L-0007Dr-00; Mon, 24 May 2004 05:51:36 -0400 Received: from usjk1006.kddi.com (usjk1006 [10.96.2.3]) by usjk1002.kddi.com with ESMTP id i4O9p4N06978; Mon, 24 May 2004 18:51:04 +0900 (JST) Received: from usjk1009.kddi.com (localhost [127.0.0.1]) by usjk1006.kddi.com with ESMTP id i4O9p4V05639; Mon, 24 May 2004 18:51:04 +0900 (JST) Received: from KDDI-0403PC0002 ([10.100.94.32]) by usjk1009.kddi.com (InterMail vM.5.01.02.00 201-253-116-121-20001201) with ESMTP id <20040524095104.GBIK1060.usjk1009.kddi.com@KDDI-0403PC0002>; Mon, 24 May 2004 18:51:04 +0900 To: fluffy@cisco.com, mdolly@att.com, diegob@mailvision.com, jdrosen@dynamicsoft.com Cc: rrroy@att.com, baruch@kayote.com, sayan.chowdhury@wipro.com, sip@ietf.org, sipping@ietf.org Subject: Re: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? From: Takuya Sawada References: <28F05913385EAC43AF019413F674A01708145CA4@OCCLUST04EVS1.ugd.att.com> In-Reply-To: Message-Id: <200405241851.JAC46755.EBUB-TVBX@kddi.com> X-Mailer: Winbiff [Version 2.42 PL2] X-Accept-Language: ja,en Date: Mon, 24 May 2004 18:51:04 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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, History-Info is the way to go in IETF. I agree with it. However, one of the missing pieces in History-Info, I think, is the mappings of redirection information from/to ISUP/ISDN network. In diversion draft, draft-levy-sip-diversion-07, section 10, elaborated on this topics with the examples. Does anyone have a clear idea about ISUP/ISDN and History-Info mapping? Does anyone have a plan to elaborate how interworking can be achieved? draft-elwell-sipping-redirection-reason may provide redirect reason mappings. But it may also need redirection counter or address presentation mappings when we require a certain level of transparency on call forwarding services. This interworking topic may be out of scope of IETF SIP WG and should be handled in other standard bodies like ITU-T or 3GPP. But I want to be sure that History-Info can offer the capabilities which can cover the mappings from/to ISUP/ISDN call forwarding services. * For example, can we all agree with that redirection counter corresponds with the depth of the dotted index in the last History-Info header? We may allow pruning of the tree because in ISUP only the first and the last redirection infomation can be conveyed. and so on... Regards, Takuya P.S. draft-levy-sip-diversion-07.txt has been deleted even before the expiration date. Does anyone know why? (07-version was published in January 2004, which means it will expire in July) > > The topic of what mechanism you use to know about this forwarding > information has been a long topic with much discussion. Right now, the WG > has selected the history mechanism (which grew out of the diversion work) > work as a WG item. The RPID work has become RFC 3325. Given the long history > of this, I highly recommend that if you think there is a reason that history > will not meet your needs, get that out very soon so that the history work > can be modified. > > I would be amazingly surprised to see diversion standardized. > > Cullen > > > > On 5/21/04 4:06 AM, "Dolly, Martin C, ALABS" wrote: > > > A mechanism for relaying call forwarding information is needed, and I agree > > that the diversion draft is a viable solution. > > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Diego B > > Sent: Friday, May 21, 2004 4:29 AM > > To: Jonathan Rosenberg > > Cc: Roy, Radhika R, ALABS; baruch@kayote.com; sayan.chowdhury@wipro.com; > > sip@ietf.org; sipping@ietf.org; fluffy@cisco.com > > Subject: Re: [Sipping] RE: [Sip] SIP Forward, Who pays the bill ? > > > > > > Hi; > > > > Agreed, but my first question was exactly that, if there is a standard > > way or standard Headers, to store information about a "forward" call. > > > > In a normal situation, no one will touch the From header and "normally" > > PSTN gateway copy the user-info from the From SIP-URI to the PSTN "B > > number", and this is normally used to create the CDR. > > > > I'm not trying to solve the CDR creation issue or how to bill a forward > > call, but I'm looking to a standard way to store forward information so > > one day this information will be used correctly to create CDRs/billing. > > > > In a close environment, I can use whatever method to recognize a > > forward situation. But SIP is about inter operability and integration > > and AFAIK there are some drafts but nothing specific to inform of a call > > forward situation, I don't know the status of Diversion header, but this > > can be a solution if standardized. > > > > Thanks > > > > Jonathan Rosenberg wrote: > >> To be clear, Baruch is proposing a new SIP header, which the SIP WG > >> would need to worry about. > >> > >> I do not think such a thing is needed. As Keith pointed out, our > >> philosophy to date (and this is a broader IETF thing too), is to make > >> sure that you can *account* for what has happened. That is, that the > >> protocols contain sufficient information to record what transpired in a > >> call/transaction/dialog or whatever. Then, its someone elses problem > >> (for example, 3gpp) to specify how the appropriate information is > >> collected, what billing model is used, and how a CDR is generated. Not > >> to say that these things arent important, they're just not the SIP > >> working group's problem. > >> > >> -Jonathan R. > >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -------- Takuya Sawada KDDI Corporation (KDDI) Garden Air Tower, 3-10-10, Iidabashi, Chiyoda-ku, Tokyo 102-8460, Japan Tel: +81-3-6678-2997 Fax: +81-3-6678-0286 tu-sawada@kddi.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon May 24 06:25:29 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24740 for ; Mon, 24 May 2004 06:25:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSCZP-00076M-W4 for sip-archive@odin.ietf.org; Mon, 24 May 2004 06:20:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OAKZOK027293 for sip-archive@odin.ietf.org; Mon, 24 May 2004 06:20:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSCEe-0003nA-4D; Mon, 24 May 2004 05:59:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSC91-0002wv-V0 for sip@optimus.ietf.org; Mon, 24 May 2004 05:53: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 FAA23273 for ; Mon, 24 May 2004 05:53:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSC8y-0000EC-9x for sip@ietf.org; Mon, 24 May 2004 05:53:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSC82-0007jq-00 for sip@ietf.org; Mon, 24 May 2004 05:52:19 -0400 Received: from usjk1004.kddi.com ([211.4.169.26]) by ietf-mx with esmtp (Exim 4.12) id 1BSC7R-0007Qw-00 for sip@ietf.org; Mon, 24 May 2004 05:51:42 -0400 Received: from usjk1035.kddi.com ([10.96.2.25]) by usjk1004.kddi.com with ESMTP id i4O9pCU05005; Mon, 24 May 2004 18:51:12 +0900 (JST) Received: from usjk1009.kddi.com (localhost [127.0.0.1]) by usjk1035.kddi.com with ESMTP id i4O9pCi13128; Mon, 24 May 2004 18:51:12 +0900 (JST) Received: from KDDI-0403PC0002 ([10.100.94.32]) by usjk1009.kddi.com (InterMail vM.5.01.02.00 201-253-116-121-20001201) with ESMTP id <20040524095111.GBIY1060.usjk1009.kddi.com@KDDI-0403PC0002>; Mon, 24 May 2004 18:51:11 +0900 To: mary.barnes@nortelnetworks.com, sip@ietf.org From: Takuya Sawada Message-Id: <200405241851.FDC56636.X-UVEBTBB@kddi.com> X-Mailer: Winbiff [Version 2.42 PL2] X-Accept-Language: ja,en Date: Mon, 24 May 2004 18:51:12 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Sip] Question on Histrory-Info: the basic rules for adding the index Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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, In the summarized basic rules for adding the index in section 4.3.3.1 of History-Info draft, item 2 says; > 2. If the Request-URI indicates a resource that this proxy is not > responsible for, then the lowest/last digit of the index is > incremented (i.e. a new level is not created). For example, if the > index in the History-Info header of the received request was 1.2, > then the index in the History-Info header field added by this proxy > would be 1.3. In RFC 3261, section 16.5, on determining request targets at SIP proxy; > If the domain of the Request-URI indicates a domain this element is > not responsible for, the Request-URI MUST be placed into the target > set as the only target, > A proxy can only change the Request-URI of a request during > forwarding if it is responsible for that URI. If the proxy is not > responsible for that URI, it will not recurse on 3xx or 416 > responses as described below. Note that Request-URI in the above sentense is after preprocessing at the proxy. I think that If the Request-URI indicates a resource that the proxy is not responsible for, the Request-URI will not change. Retargeting on receiving 3xx will not ocuur, neither. Why do you need to record the history of Request-URI at the proxy which is not responsible for the Request-URI? I think the basic rules item 1 is enough and simpler solution. Then, for example, the sequence in section 4.5 can be seen as the following; UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 | | | | | | | |--INVITE -->| | | | | | | |-INVITE->| | | | | Supported: Histinfo History-Info: ;index=1, ; index=1.1 | | | | | | | | | |-INVITE>| | | | History-Info: ;index=1, ; index=1.1, ; index=1.1.1 | | | | | | | | | |-----INVITE ---->| | | History-Info: ;index=1, ; index=1.1, ; index=1.1.2 | | | | | | | | | |-------INVITE------------>| | History-Info: ;index=1, ; index=1.1, ; index=1.1.3 /* All Responses from the INVITEs indicate non-success/non- availability*/ | | | | | | | | |<-480 ---| | | | | History-Info: ;index=1, ; index=1.1, ;index=1.1.1, ; index=1.1.2, ; index=1.1.3 | | | | | | | /* Upon receipt of the response, P1 determines another route for the INVITE, but finds that it matches some routes already attempted (e.g. UA2 and UA3, thus the INVITE is only forwarded to UA5, where the session is successfully established */ | | | | | | | | |----------------INVITE --------------------->| History-Info: ;index=1, ; index=1.1, ;index=1.1.1, ; index=1.1.2, ; index=1.1.3 ;index=1.2 | | | | | | | | |<-----200 OK---------------------------------| |<--200 OK---| | | | | | | | | | | | | |--ACK --------------------------------------------------->| Regards, Takuya -------- Takuya Sawada KDDI Corporation (KDDI) Garden Air Tower, 3-10-10, Iidabashi, Chiyoda-ku, Tokyo 102-8460, Japan Tel: +81-3-6678-2997 Fax: +81-3-6678-0286 tu-sawada@kddi.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon May 24 09:07:15 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03506 for ; Mon, 24 May 2004 09:07: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 1BSExE-0003MM-DP for sip-archive@odin.ietf.org; Mon, 24 May 2004 08:53:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OCrK9O012912 for sip-archive@odin.ietf.org; Mon, 24 May 2004 08: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 1BSEnM-0001mO-Tg; Mon, 24 May 2004 08:43:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSEdB-0008Fe-UJ for sip@optimus.ietf.org; Mon, 24 May 2004 08:32: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 IAA01890 for ; Mon, 24 May 2004 08:32:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSEdA-0004w4-Ob for sip@ietf.org; Mon, 24 May 2004 08:32:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSEc8-0004dS-00 for sip@ietf.org; Mon, 24 May 2004 08:31:32 -0400 Received: from mail.deccanetworld.com ([203.196.146.50] helo=gatekeeper.deccanetworld.com) by ietf-mx with esmtp (Exim 4.12) id 1BSEbk-0004Kw-00; Mon, 24 May 2004 08:31:09 -0400 Received: from gatekeeper.deccanetworld.com (localhost [127.0.0.1]) by gatekeeper.deccanetworld.com (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id i4OCMILS011053; Mon, 24 May 2004 17:52:18 +0530 Received: from mail.deccanetworld.com (server.deccanetworld.com [192.168.1.32]) by gatekeeper.deccanetworld.com (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id i4OCMH6i011047; Mon, 24 May 2004 17:52:17 +0530 Received: (from root@localhost) by mail.deccanetworld.com (8.11.0/8.11.0) id i4OCiXL04558; Mon, 24 May 2004 18:14:33 +0530 Received: from gvvivek (bharathi.software [192.168.1.224] (may be forged)) by mail.deccanetworld.com (8.11.0/8.11.0) with SMTP id i4OCiW804516; Mon, 24 May 2004 18:14:32 +0530 Message-ID: <018101c4418a$f746c880$e001a8c0@gvvivek> From: "Vishnu Yadav" To: Cc: Date: Mon, 24 May 2004 18:00:58 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_017E_01C441B9.10E980B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,EXCUSE_16,HTML_20_30, HTML_MESSAGE autolearn=no version=2.60 Subject: [Sip] confrencing in SIP Instant messaging using MSRP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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_017E_01C441B9.10E980B0 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable 1. Do we need to use JOIN header to join an existing SIP message = session.OR any other method is used for it. 2. What is the method for exiting out from a SIP message conference. Pls can u refer me some docs on this. thanx in advance vishnu yadav ********************************DISCLAIMER********************************** This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege of Deccanet Designs Ltd. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from retaining, using, copying, altering or disclosing the contents of this message. **************************************************************************** ------=_NextPart_000_017E_01C441B9.10E980B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
1. Do we need to use JOIN header to = join an=20 existing SIP message session.OR any = other method=20 is used for it.
2. What is the method for exiting out = from a SIP=20 message conference.
 
Pls can u refer me some docs on = this.
 
thanx in advance
vishnu yadav

********************************DISCLAIMER**********************************

This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege of Deccanet Designs Ltd.
If you have received this message in error, please notify the originator
immediately. If you are not the intended recipient, you are notified that
you are strictly prohibited from retaining, using, copying, altering or
disclosing the contents of this message.

****************************************************************************
------=_NextPart_000_017E_01C441B9.10E980B0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 24 10:03:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07374 for ; Mon, 24 May 2004 10:03:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSFvc-0003RS-05 for sip-archive@odin.ietf.org; Mon, 24 May 2004 09:55:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ODthPu013227 for sip-archive@odin.ietf.org; Mon, 24 May 2004 09:55:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSFjJ-0001ta-Gq; Mon, 24 May 2004 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 1BSFdl-0000y3-CU for sip@optimus.ietf.org; Mon, 24 May 2004 09:37: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 JAA05404 for ; Mon, 24 May 2004 09:37:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSFdj-0004YM-Gd for sip@ietf.org; Mon, 24 May 2004 09:37:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSFck-0004VN-00 for sip@ietf.org; Mon, 24 May 2004 09:36:15 -0400 Received: from [151.39.82.11] (helo=abbeynet.it) by ietf-mx with smtp (Exim 4.12) id 1BSFbl-0004SF-00 for sip@ietf.org; Mon, 24 May 2004 09:35:13 -0400 Received: (qmail 5869 invoked from network); 24 May 2004 13:34:41 -0000 Received: from localhost (HELO localhost.localdomain) (127.0.0.1) by 0 with SMTP; 24 May 2004 13:34:41 -0000 Received: from abbeynet.it (localhost.localdomain [127.0.0.1]) by localhost.localdomain (VaMailArmor-2.0.1.16) id 05861-58B02F2C; Mon, 24 May 2004 15:34:40 +0200 Received: (qmail 5859 invoked from network); 24 May 2004 13:34:40 -0000 Received: from giacomo.localnet (HELO gia) (192.168.0.158) by 0 with SMTP; 24 May 2004 13:34:40 -0000 From: "Giacomo Vacca" To: Date: Mon, 24 May 2004 15:34:40 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C441A4.A132A7B0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcRBk92WdZmvoYr9Twuf+JqI5elr2w== X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.25.0.3; VDF: 6.25.0.74; host: abbeynet.it) Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_70_80,HTML_MESSAGE, MISSING_OUTLOOK_NAME autolearn=no version=2.60 Subject: [Sip] Record-Route URI with user name Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C441A4.A132A7B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, is it compliant with RFC 3261 to add a Record-Route header containing a URI with user name? For example: UA1 --> SER Proxy --> UA2 UA1 send: INVITE ua2@serdomain UA2 receives: INVITE ua2@ua2host Record-Route: ua1@ua1host. If the answer is Yes: How must UA2 consider that Record-Route? Thank you. Giacomo ------=_NextPart_000_0003_01C441A4.A132A7B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
is it = compliant with=20 RFC 3261 to add a Record-Route header containing a URI with user=20 name?
 
For=20 example:
UA1 = --> SER Proxy=20 --> UA2
 
 
UA1=20 send:
INVITE = ua2@serdomain
 
UA2=20 receives:
INVITE = ua2@ua2host
Record-Route: ua1@ua1host.
 
 
If the = answer is=20 Yes: How must UA2 consider that Record-Route?
 
Thank=20 you.
Giacomo
 
 
------=_NextPart_000_0003_01C441A4.A132A7B0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 24 10:21:48 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09439 for ; Mon, 24 May 2004 10:21: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 1BSGAv-0006E4-QQ for sip-archive@odin.ietf.org; Mon, 24 May 2004 10:11:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OEBXk9023863 for sip-archive@odin.ietf.org; Mon, 24 May 2004 10:11:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSFvx-0003ek-6l; Mon, 24 May 2004 09:56:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSFjy-0001xH-3n for sip@optimus.ietf.org; Mon, 24 May 2004 09:43: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 JAA05789 for ; Mon, 24 May 2004 09:43:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSFjw-00057z-9F for sip@ietf.org; Mon, 24 May 2004 09:43:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSFiT-0004yb-00 for sip@ietf.org; Mon, 24 May 2004 09:42:10 -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 1BSFhS-0004ol-00; Mon, 24 May 2004 09:41:06 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i4ODeVfB023042; Mon, 24 May 2004 06:40:33 -0700 (PDT) Received: from cisco.com (che-vpn-cluster-2-74.cisco.com [10.86.242.74]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIS76225; Mon, 24 May 2004 09:40:30 -0400 (EDT) Message-ID: <40B1FB4E.3050808@cisco.com> Date: Mon, 24 May 2004 09:40:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vishnu Yadav CC: sip@ietf.org, sip-request@ietf.org Subject: Re: [Sip] confrencing in SIP Instant messaging using MSRP References: <018101c4418a$f746c880$e001a8c0@gvvivek> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 Vishnu Yadav wrote: > 1. Do we need to use JOIN header to join an existing SIP message > session.OR any other method is used for it. > 2. What is the method for exiting out from a SIP message conference. > > Pls can u refer me some docs on this. Are you familiar with the conferencing framework? Conferencing IM using MSRP is essentially the same as conferencing voice using RTP. The conferencing framework and related drafts spell out how to do that. Join is one mechanism for joining an existing conference, but it is not the only way. The part that isn't spelled out yet is how an MSRP mixer should work. But this is pretty easy to imagine. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From exim@www1.ietf.org Mon May 24 11:02:18 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11963 for ; Mon, 24 May 2004 11:02:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSGqp-000475-Fj for sip-archive@odin.ietf.org; Mon, 24 May 2004 10:54:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OEspiV015811 for sip-archive@odin.ietf.org; Mon, 24 May 2004 10:54:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSGVl-00014i-GF; Mon, 24 May 2004 10: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 1BSGKT-0007kA-TK for sip@optimus.ietf.org; Mon, 24 May 2004 10:21: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 KAA09408 for ; Mon, 24 May 2004 10:21:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSGKR-0000P7-IG for sip@ietf.org; Mon, 24 May 2004 10:21:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSGJS-0000KD-00 for sip@ietf.org; Mon, 24 May 2004 10:20:24 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1BSGIY-0000CD-00 for sip@ietf.org; Mon, 24 May 2004 10:19:26 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i4OEIqp24121; Mon, 24 May 2004 10:18:52 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 May 2004 10:17:45 -0400 Message-ID: From: "Mary Barnes" To: "'Takuya Sawada'" , sip@ietf.org Date: Mon, 24 May 2004 10:17:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44199.DBD5058D" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 Subject: [Sip] RE: Question on Histrory-Info: the basic rules for adding the ind ex Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: 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_01C44199.DBD5058D Content-Type: text/plain The intent of capturing the URI in step 2 is to ensure that the URI is captured prior to retargeting (i.e. the History-Info URI in the most recent entry is that of the Request when it is forwarded). This ensures that the retargeted-from is automatically captured when retargeting occurs. If you go back to past discussions, we originally were capturing 2 URIs, the retargeted-from and retargeted-to for each instance of retargeting. However, that resulted in duplicate information and thus was less efficient. I think your concern arises in viewing History-Info only as a mechanism to capture redirections, however, the intent also was that it captured the entire History of the flow of a Request. Regards, Mary. -----Original Message----- From: Takuya Sawada [mailto:tu-sawada@kddi.com] Sent: Monday, May 24, 2004 4:51 AM To: Barnes, Mary [NGC:B601:EXCH]; sip@ietf.org Subject: Question on Histrory-Info: the basic rules for adding the index Hi, In the summarized basic rules for adding the index in section 4.3.3.1 of History-Info draft, item 2 says; > 2. If the Request-URI indicates a resource that this proxy is not > responsible for, then the lowest/last digit of the index is > incremented (i.e. a new level is not created). For example, if the > index in the History-Info header of the received request was 1.2, > then the index in the History-Info header field added by this proxy > would be 1.3. In RFC 3261, section 16.5, on determining request targets at SIP proxy; > If the domain of the Request-URI indicates a domain this element is > not responsible for, the Request-URI MUST be placed into the target > set as the only target, > A proxy can only change the Request-URI of a request during > forwarding if it is responsible for that URI. If the proxy is not > responsible for that URI, it will not recurse on 3xx or 416 > responses as described below. Note that Request-URI in the above sentense is after preprocessing at the proxy. I think that If the Request-URI indicates a resource that the proxy is not responsible for, the Request-URI will not change. Retargeting on receiving 3xx will not ocuur, neither. Why do you need to record the history of Request-URI at the proxy which is not responsible for the Request-URI? I think the basic rules item 1 is enough and simpler solution. Then, for example, the sequence in section 4.5 can be seen as the following; UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 | | | | | | | |--INVITE -->| | | | | | | |-INVITE->| | | | | Supported: Histinfo History-Info: ;index=1, ; index=1.1 | | | | | | | | | |-INVITE>| | | | History-Info: ;index=1, ; index=1.1, ; index=1.1.1 | | | | | | | | | |-----INVITE ---->| | | History-Info: ;index=1, ; index=1.1, ; index=1.1.2 | | | | | | | | | |-------INVITE------------>| | History-Info: ;index=1, ; index=1.1, ; index=1.1.3 /* All Responses from the INVITEs indicate non-success/non- availability*/ | | | | | | | | |<-480 ---| | | | | History-Info: ;index=1, ; index=1.1, ;index=1.1.1, ; index=1.1.2, ; index=1.1.3 | | | | | | | /* Upon receipt of the response, P1 determines another route for the INVITE, but finds that it matches some routes already attempted (e.g. UA2 and UA3, thus the INVITE is only forwarded to UA5, where the session is successfully established */ | | | | | | | | |----------------INVITE --------------------->| History-Info: ;index=1, ; index=1.1, ;index=1.1.1, ; index=1.1.2, ; index=1.1.3 ;index=1.2 | | | | | | | | |<-----200 OK---------------------------------| |<--200 OK---| | | | | | | | | | | | | |--ACK --------------------------------------------------->| Regards, Takuya -------- Takuya Sawada KDDI Corporation (KDDI) Garden Air Tower, 3-10-10, Iidabashi, Chiyoda-ku, Tokyo 102-8460, Japan Tel: +81-3-6678-2997 Fax: +81-3-6678-0286 tu-sawada@kddi.com ------_=_NextPart_001_01C44199.DBD5058D Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Question on Histrory-Info: the basic rules for adding the = index

The intent of capturing the URI in step 2 is to = ensure that the URI is captured prior to retargeting (i.e. the = History-Info URI in the most recent entry is that of the Request when = it is forwarded). This ensures that the retargeted-from is = automatically captured when retargeting occurs.  If you go back to = past discussions, we originally were capturing 2 URIs, the = retargeted-from and retargeted-to for each instance of = retargeting.  However, that resulted in duplicate information and = thus was less efficient.  

I think your concern arises in viewing History-Info = only as a mechanism to capture redirections, however, the intent also = was that it captured the entire History of the flow of a = Request.

Regards,
Mary.

-----Original Message-----
From: Takuya Sawada [mailto:tu-sawada@kddi.com] =
Sent: Monday, May 24, 2004 4:51 AM
To: Barnes, Mary [NGC:B601:EXCH]; = sip@ietf.org
Subject: Question on Histrory-Info: the basic rules = for adding the index


Hi,

In the summarized basic rules for adding the index in = section 4.3.3.1 of History-Info draft, item 2 says;

>     2. If the Request-URI = indicates a resource that this proxy is not
>     responsible for, then = the lowest/last digit of the index is
>     incremented (i.e. a new = level is not created).  For example, if the
>     index in the = History-Info header of the received request was 1.2,
>     then the index in the = History-Info header field added by this proxy
>     would be 1.3.

In RFC 3261, section 16.5, on determining request = targets at SIP proxy;

>    If the domain of the = Request-URI indicates a domain this element is
>    not responsible for, the = Request-URI MUST be placed into the target
>    set as the only = target,
<snip>
>       A proxy can = only change the Request-URI of a request during
>       forwarding = if it is responsible for that URI.  If the proxy is not
>       responsible = for that URI, it will not recurse on 3xx or 416
>       responses = as described below.

Note that Request-URI in the above sentense is after = preprocessing at the proxy.
I think that If the Request-URI indicates a resource = that the proxy is not responsible for, the Request-URI will not change. = Retargeting on receiving 3xx will not ocuur, neither. Why do you need = to record the history of Request-URI at the proxy which is not = responsible for the Request-URI?

I think the basic rules item 1 is enough and simpler = solution.

Then, for example, the sequence in section 4.5 can be = seen as the following;

   = UA1        Proxy1  = Proxy2     UA2      = UA3      UA4      UA5 =
          &nb= sp;    
   = |            = |         = |        = |        = |        = |        |
   |--INVITE = -->|         = |        = |        = |        = |        |
   = |            = |-INVITE->|        = |        = |        = |        |
          &nb= sp;      Supported: Histinfo
          &nb= sp;      History-Info: = <sip:Bob@P1>;index=3D1,
          &nb= sp;           &nb= sp;        <sip:Bob@P2>; = index=3D1.1
   = |            = |         = |        = |        = |        = |        |
   = |            = |         = |-INVITE>|        = |        = |        |
          &nb= sp;       History-Info: = <sip:Bob@P1>;index=3D1, 
          &nb= sp;           &nb= sp;         <sip:Bob@P2>; = index=3D1.1,
          &nb= sp;           &nb= sp;         = <sip:User2@UA2>; index=3D1.1.1
   = |            = |         = |        = |        = |        = |        |
   = |            = |         |-----INVITE = ---->|        = |        |
          &nb= sp;       History-Info: = <sip:Bob@P1>;index=3D1, 
         = ;            = ;           = <sip:Bob@P2 >; index=3D1.1,
          &nb= sp;           &nb= sp;         = <sip:User3@UA3>; index=3D1.1.2
   = |            = |         = |        = |        = |        = |        |
   = |            = |         = |-------INVITE------------>|       = ; | 
          &nb= sp;       History-Info: = <sip:Bob@P1>;index=3D1, 
          &nb= sp;           &nb= sp;         <sip:Bob@P2 = >; index=3D1.1,
          &nb= sp;           &nb= sp;         <sip:User4@UA4 = >; index=3D1.1.3

   /* All Responses from the INVITEs = indicate non-success/non-
   availability*/  
  = |            = |         = |        = |        = |        = |        |
  = |            = |<-480 ---|        = |        = |        = |        |
          &nb= sp;    History-Info: <sip:Bob@P1>;index=3D1,  =
          &nb= sp;       <sip:Bob@P2>; = index=3D1.1,  
          &nb= sp;       <sip:User2@UA2?Reason:SIP;\ =
          &nb= sp;        = cause=3D408;text=3D"RequestTimeout">;index=3D1.1.1, &n= bsp;           &n= bsp;   
          &nb= sp;       <sip:User3@UA3?Reason:SIP; = \       
          &nb= sp;        = cause=3D487;text=3D"Request Terminated">; index=3D1.1.2, =
          &nb= sp;       = <sip:User4@UA4?Reason:SIP;\       =  
          &nb= sp;        = cause=3D603;text=3D"Decline">; index=3D1.1.3
  = |            = |         = |        = |        = |        = |        |
 /* Upon receipt of the response, P1 determines = another route for the
  INVITE, but finds that it matches some routes = already attempted 
 (e.g. UA2 and UA3, thus the INVITE is only = forwarded to UA5, where 
  the session is successfully established  = */
  = |            = |         = |        = |        = |        = |        |
  = |            = |----------------INVITE --------------------->|
          &nb= sp;     History-Info: <sip:Bob@P1>;index=3D1, =
          &nb= sp;        <sip:Bob@P2>; = index=3D1.1, 
          &nb= sp;        = <sip:User2@UA2?Reason:SIP;cause=3D408;\
          &nb= sp;         = text=3D"RequestTimeout">;index=3D1.1.1,   &n= bsp;           &n= bsp;     
          &nb= sp;        = <sip:User3@UA3?Reason:SIP;cause=3D487;\
          &nb= sp;         = text=3D"Request Terminated">; index=3D1.1.2,
          &nb= sp;        = <sip:User4@UA4?Reason:SIP;cause=3D603;\
          &nb= sp;         = text=3D"Decline">; index=3D1.1.3
          &nb= sp;       = <sip:User5@UA5>;index=3D1.2 
  = |            = |         = |        = |        = |        = |        |
  = |            = |<-----200 OK---------------------------------|
  |<--200 = OK---|         = |        = |        = |        = |        |
  = |            = |         = |        = |        = |        = |        | 
  |--ACK = --------------------------------------------------->|

Regards,
Takuya

--------
Takuya Sawada
KDDI Corporation (KDDI)
Garden Air Tower, 3-10-10, Iidabashi,
Chiyoda-ku, Tokyo 102-8460, Japan
Tel: +81-3-6678-2997
Fax: +81-3-6678-0286
tu-sawada@kddi.com

------_=_NextPart_001_01C44199.DBD5058D-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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 May 24 12:41:52 2004 Received: from optimus.ietf.org ([132.151.1.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18621 for ; Mon, 24 May 2004 12:41: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 1BSITI-0008IZ-MI for sip-archive@odin.ietf.org; Mon, 24 May 2004 12:38:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OGcetI031882 for sip-archive@odin.ietf.org; Mon, 24 May 2004 12:38:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSIIe-0005ra-Ml for sip-web-archive@optimus.ietf.org; Mon, 24 May 2004 12:27:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18028 for ; Mon, 24 May 2004 12:27:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSIId-0004ep-2C for sip-web-archive@ietf.org; Mon, 24 May 2004 12:27:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSIHg-0004XE-00 for sip-web-archive@ietf.org; Mon, 24 May 2004 12:26:40 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BSIHF-0004RJ-00 for sip-web-archive@ietf.org; Mon, 24 May 2004 12:26:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSHwI-00014n-Jw for sip-web-archive@ietf.org; Mon, 24 May 2004 12:04:34 -0400 Date: Mon, 24 May 2004 12:04:34 -0400 Message-ID: <20040524160434.4138.90706.Mailman@www1.ietf.org> Subject: Welcome to the "Sip" mailing list From: sip-request@ietf.org To: sip-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Welcome to the Sip@ietf.org mailing list! To post to this list, send your email to: sip@ietf.org General information about the mailing list is at: https://www1.ietf.org/mailman/listinfo/sip ************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ************************************************************************** If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: https://www1.ietf.org/mailman/options/sip/sip-web-archive%40ietf.org You can also make such adjustments via email by sending a message to: Sip-request@ietf.org with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: toufat If you forget your password, don't worry, you will receive a monthly reminder telling you what all your ietf.org mailing list passwords are, and how to unsubscribe or change your options. There is also a button on your options page that will email your current password to you. You may also have your password mailed to you automatically off of the Web page noted above.